From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1S4XRG-0005He-6n for mharc-grub-devel@gnu.org; Mon, 05 Mar 2012 07:54:54 -0500 Received: from eggs.gnu.org ([208.118.235.92]:53432) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4XR7-0005HS-6i for grub-devel@gnu.org; Mon, 05 Mar 2012 07:54:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4XR5-0002uO-4I for grub-devel@gnu.org; Mon, 05 Mar 2012 07:54:44 -0500 Received: from mail-ey0-f169.google.com ([209.85.215.169]:50405) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4XR4-0002u7-Nr for grub-devel@gnu.org; Mon, 05 Mar 2012 07:54:43 -0500 Received: by eaal1 with SMTP id l1so1438649eaa.0 for ; Mon, 05 Mar 2012 04:54:40 -0800 (PST) Received-SPF: pass (google.com: domain of phcoder@gmail.com designates 10.14.194.134 as permitted sender) client-ip=10.14.194.134; Authentication-Results: mr.google.com; spf=pass (google.com: domain of phcoder@gmail.com designates 10.14.194.134 as permitted sender) smtp.mail=phcoder@gmail.com; dkim=pass header.i=phcoder@gmail.com Received: from mr.google.com ([10.14.194.134]) by 10.14.194.134 with SMTP id m6mr11354866een.4.1330952080661 (num_hops = 1); Mon, 05 Mar 2012 04:54:40 -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=bC2s4LLb0AROeMMLsqF/JXNiwD2Gw9WmuCEbkQ6G8YM=; b=Jf7UKU1TjLlGB+UGiQAxm0QuFp6GQtMb9yOQpvcqAL4xn3hcSspH8+Bk+qZztRMnlK BrvPfCW9t23/c9jbaJ1PPVTpI7CxM6Sw8Q/IY0U3wT85K3yc+nAgY5BnHyf1sLFpVrK9 btvIORUHpMyjysTAbrEyYi2X9PeRCFi111BAXdGGff9DzeSmbjyuGe6cMx5AJmDPCPhM KCStJnRHIPu4PEpNZQ30JMQ7VzyPwb2Y9qxnidlBRXs+99ZFWDFMvxu3c63OTT+yt2P+ KuLsOHrWBoYAyt1tzR0+Q4jfMqaTGfEkUKLTJc0ltlys16xoeuEFSg1xL422ZCwps96M oUlw== Received: by 10.14.194.134 with SMTP id m6mr8622123een.4.1330952080530; Mon, 05 Mar 2012 04:54:40 -0800 (PST) Received: from debian.x201.phnet (15-234.197-178.cust.bluewin.ch. [178.197.234.15]) by mx.google.com with ESMTPS id y14sm61371719eef.10.2012.03.05.04.54.37 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Mar 2012 04:54:39 -0800 (PST) Message-ID: <4F54B78B.9010707@gmail.com> Date: Mon, 05 Mar 2012 13:54:35 +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: Andreas Vogel Subject: Re: Ideas for the future References: <4F541349.7070704@anvo-it.de> <4F541723.6030105@gmail.com> <4F54A094.1000000@anvo-it.de> In-Reply-To: <4F54A094.1000000@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: 209.85.215.169 Cc: The development of GNU GRUB , Colin Watson 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 12:54:53 -0000 (CC'ing Colin because of theme stuff and it overlaps with what he needs for Ubuntu) >>> 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 >> >> BTW, another point which might be addressed in the future: the global >> theme properties like "desktop-image" or "title-text" use minus char >> between words, all other properties are using underline. Not really >> consistent. That's unfortunate that noone noticed it when it was comitted but now we're stuck with it (compatibility) > >>> 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 > I know. But there is a slight advantage using a boolean argument for > such commands: it's a little nicer to deal with them when using variables. > E.g.: > > if [ "feature" = unavail ] ; then > set hidden=1 > else > set hidden=0 > fi > menuentry "Boot memtest86" --hidden $hidden { ... } > > for looks nicer opposed to > > if [ "feature" = unavail ] ; then > set hidden="--hidden" > else > set hidden= > fi > menuentry "Boot memtest86" $hidden { ... } I understand your point but consistency is more important. > When i implemented my patches, i wanted to use both ways: a command line > option with an optional argument. By this we would have had what you > preference and my way too. Regarding optional arguments the option > handling in GRUB is actually broken by design, so this is, > unfortunately, not an option. Again it's unfortunate that noone noticed it when it was committed and now we're stuck with it. > Don't really understand your argument. Of course you'll have problems if > you use a key which is not available on your keyboard. For my example > implementing a help screen which is shown by pressing F1 you can use > another hotkey, e.g.-h. > I don't really see the point against having hidden menuentries, > especially when taking into account that i provided a real life example. If the option isn't hidden the unsupported hotkey is only a minor problem since you can still select the entry explicitly. As a compromise it may be possible to make it hidden only on gfxmenu while keeping it fully visible on normal menu renderer. > >>> 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. > You didn't get the point. Why should any terminal box open when there is > nothing to display? I think you don't get mine: if this message goes to status bar it doesn't go to the terminal and so it doesn't open. > Not at all. Every decent menu system supports disabled menu entries and > serious design guides suggest better to have disabled menu entries than > not to show them at all. If you have a look in Firefox, Thunderbird > (just to mention 2 programs), you'll see that they all use disabled > menu entries. > Btw, I don't really understand your point about braille displays: a > disabled menu entry would look almost the same like an enabled one. Try living a day on 20x1 terminal and tell me what you think about all extra useless info you get. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko