From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1S4Mkn-0007Rv-DC for mharc-grub-devel@gnu.org; Sun, 04 Mar 2012 20:30:21 -0500 Received: from eggs.gnu.org ([208.118.235.92]:38881) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4Mkl-0007RZ-8G for grub-devel@gnu.org; Sun, 04 Mar 2012 20:30:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4Mki-0003GM-SZ for grub-devel@gnu.org; Sun, 04 Mar 2012 20:30:18 -0500 Received: from mail-ee0-f41.google.com ([74.125.83.41]:53302) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4Mki-0003G4-Dk for grub-devel@gnu.org; Sun, 04 Mar 2012 20:30:16 -0500 Received: by eeke53 with SMTP id e53so1339975eek.0 for ; Sun, 04 Mar 2012 17:30:14 -0800 (PST) Received-SPF: pass (google.com: domain of phcoder@gmail.com designates 10.213.114.7 as permitted sender) client-ip=10.213.114.7; Authentication-Results: mr.google.com; spf=pass (google.com: domain of phcoder@gmail.com designates 10.213.114.7 as permitted sender) smtp.mail=phcoder@gmail.com; dkim=pass header.i=phcoder@gmail.com Received: from mr.google.com ([10.213.114.7]) by 10.213.114.7 with SMTP id c7mr2841871ebq.144.1330911014305 (num_hops = 1); Sun, 04 Mar 2012 17:30:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3NtU2USPU6F7ZNR100vY8Pqf3v0M1j7IDI3DNwW6fhQ=; b=h8fB1JD5QS1lKBM9oglP1i79FLgq96Zg6WY8hIuwBDXjQy1wuEhqa8stTTXA3+zOdA nlWHWDnWV6Ejzp3ZUfAIMDBjicKtHN0E12NmRkyxxFLzg4SmQtholCMgzEdWuzZRVYW2 RYfNvZBAOoc6O8vvNJCfTNDIAl1zUYmLi1OIgjJ0c82UUS9FStrqObaO4J9orUY3fkkL h7J6ndI9oAX1hKCDVQGHP1SI5UpqtVvN+HjMGL7eiiwngfkLafQsssuwZdLhKQ1iPpg5 /kJg0LhNFj9bg4IYyvQ2budsFwzRESUStjmrfeCAWEV5AlfkErlRo70bIAje8wvcL58R 7pAw== Received: by 10.213.114.7 with SMTP id c7mr2141074ebq.144.1330911014216; Sun, 04 Mar 2012 17:30:14 -0800 (PST) Received: from debian.x201.phnet (106-191.203-62.cust.bluewin.ch. [62.203.191.106]) by mx.google.com with ESMTPS id v51sm55385338eef.2.2012.03.04.17.30.12 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 04 Mar 2012 17:30:13 -0800 (PST) Message-ID: <4F541723.6030105@gmail.com> Date: Mon, 05 Mar 2012 02:30:11 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: Ideas for the future References: <4F541349.7070704@anvo-it.de> In-Reply-To: <4F541349.7070704@anvo-it.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 74.125.83.41 Cc: Andreas Vogel X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 01:30:21 -0000 On 05.03.2012 02:13, Andreas Vogel wrote: > I took the last few nights to divide my previously submitted huge patch > into logical parts (around 10 patches now). Some of them I've submitted > already. > > So right now it seems to me that it's useless to waste your time (and my > time too) to submit more patches or even to discuss them due to code > freeze and because all time is needed now to prepare release 2.0. > > Even though I fully understand this situation it's really sad that some > of the most wanted features for GRUB will still not be available in the > upcoming release (especially the possibility to have a settings menu). > Personally i can live with that coz I'm using my private patches for my > projects which do need those features. > > Anyway, I don't want that those ideas are lost so let me summarize the > enhancements I have patches for and what i think would be great to have > in the future: > > 1) Environment variable substitution in menus. For normal menu entries > this works already. For submenus this doesn't work as the submenu > entries are not re-evaluated after execution of it's menuentries. > Example: > set lang=us > menuentry 'Boot with lang=$lang' { ... ; linux lang=$lang ; boot } > submenu Settings { > submenu 'Language... (current lang = $lang)' { > menuentry --silent=1 'Set lang US' { set lang=us } > menuentry --silent=1 'Set lang DE' { set lang=de } > } > } Have you seen the argument possibility? > 2) Environment variable substitutions in theme labels. Theme labels > should be able to reference environment variables for display. It > would/could be even great to use environment variables for different > things in themes (fonts, pictures, etc...). That seems pretty vague do you have an idea in mind? > By this it would be possible > to use a quite generic theme.txt file for different resolutions, etc. This is already possible. Use percent notation for desired size and rendering will figure out the actual size basing on constraints. > 3) Enhanced hotkey handling: support ALT, SHIFT and CTRL modifiers. > > 4) menuentry/submenu --hidden 0|1 We don't use 0|1. We just make it argumentless and option toggles the behaviour > Hidden menuentries behave the same like normal menu entries but they are > not visible on the screen. They can only be activated using a hotkey. By > this you can define a help screen using hotkey F1 but no visible menu > entry is needed. The problem is that such entries are not usable if the hotkey in question is unavailable because of terminal limitations. > 5) menuentry --silent 0|1 > When using menuentries which just sets some variables or do some other > (non booting tasks), it's really bothering to see a flickering empty > terminal box just for nothing. When this flag is set, the terminal box > will not be shown by default when the entry is executed. Execution of > submenus should be always silent. Rather than removing messages better move them to some status bar in the theme. > 6) menuentry --enabled 0|1 > It's a good practice to show menuentries even if they are not applicable > in different situations (that's common for all major menu systems). If a > menu entry is disabled, it is shown but it is not operable. E.g. one > might have a general grub config file which supports booting a bunch of > ISO images. When an ISO image is not found and instead of not showing a > menuentry for that, those menuentry could be shown as disabled. This seems like just cluttering the view. Remember that in some applications (e.g. braille) menu has to be very concise. We support even the tiny (40x1) terminal geometries. > As I said before, I have patches which implements all those features and > I'm using these features in projects right now. > > Vladimir, it seems that GRUB is a one man show Some of the times it is, sometimes there are more active devs around. It's somewhat periodic. > and it's really your > baby. Don't get me wrong please, I really appreciate your hard work and > from our conversation I can feel that you're really a genius. Whenever > you have time again for new ideas, new patches and new discussions, let > me know. It's just the wrong time right now for that. > > Andreas > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > -- Regards Vladimir 'φ-coder/phcoder' Serbinenko