From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.33) id 1Br26Q-0006mE-OZ for mharc-grub-devel@gnu.org; Sat, 31 Jul 2004 18:13:18 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Br26M-0006ke-Kt for grub-devel@gnu.org; Sat, 31 Jul 2004 18:13:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Br26L-0006k1-DQ for grub-devel@gnu.org; Sat, 31 Jul 2004 18:13:13 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Br26L-0006jk-Ah for grub-devel@gnu.org; Sat, 31 Jul 2004 18:13:13 -0400 Received: from [212.43.237.68] (helo=kotoba.storever.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Br22o-000402-32 for grub-devel@gnu.org; Sat, 31 Jul 2004 18:09:34 -0400 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by kotoba.storever.com (Postfix) with ESMTP id 577CFF0D35A3 for ; Sat, 31 Jul 2004 18:09:33 -0400 (EDT) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Sun, 1 Aug 2004 00:09:38 +0200 User-Agent: KMail/1.6.1 References: <200407312032.27650.okuji@enbug.org> <87k6wkdkhf.fsf@marco.marco-g.com> In-Reply-To: <87k6wkdkhf.fsf@marco.marco-g.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408010009.38512.okuji@enbug.org> Subject: Re: usability X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 22:13:15 -0000 On Saturday 31 July 2004 21:50, Marco Gerards wrote: > > - Implement the menu interface with Unicode awared. I have a > > prototype but this is very poor, especially about Unicode handling. > > I address this issue first. > > Could you please inform us what that means for other parts of GRUB 2? > Especially the console and filesystems. If special care should be > taken, I can already keep the issues in mind. As for the console, you need to take it into account that characters are passed as Unicode (UCS-4). I think this has been implemented for i386-pc at some degree, although I might be wrong. I haven't looked at this kind of stuff for a very long time. The i386-pc port has two modes for the console: text and graphics. The text mode just prints a character if it is in ASCII, and tries to map the character code to the IBM PC character map when possible, if not. The graphics mode handles Unicode characters better, using bitmap fonts. But I'm sure that it is not perfect at all (e.g. it lacks support for RTL). As for the filesystems, they should consider that a filename is in UTF-8. So, if a filesystem uses UTF-8 to store path names, you don't have to convert the encoding (this is not true actually, since Unicode is sometimes very ambiguous, like ligatures). In FAT, I think I implemented a conversion between UTF-8 and UCS-2, because Windows uses UCS-2 in FAT filesystems. But this issue may not be very important for filesystems, because people don't usually use any non-ASCII characters in OS image files, and I don't want to include input methods to enter non-ASCII characters in GRUB anyway. We need to discuss more on internationalization... I will post my idea about this later. > If selecting a menu item is not a noop anymore it can be used already > to boot. I can implement this, if you want me to. I'm sorry, but I don't understand what you mean here. > I think including config files is an important feature. I agree, and it is quite easy to implement in GRUB 2, because we can now open multiple files at a time! BTW, if you have any new feature you want in GRUB 2, let me know. I'm thinking these extensions: - File inclusion You can include a file from another. - Labelling entries You can specify a label to an entry. Then, you can do this: default hurd-l4 title --label=hurd-l4 Hurd/L4 root=(hd0,0) ... Or title Hurd/L4 label hurd-l4 root=(hd0,0) ... - Tree interface The menu can be multiple levels, like file managers: Hurd/L4 (You can open/close this entry) Hurd/L4 Test Hurd/L4 Stable Hurd/L4 Debug I'm not sure about this feature. - User-definable shortcuts You can define a keymap for shortcuts: title --key=1 Debian GNU/Hurd ... title --key=2 Debian GNU/Linux ... And even: key 'e' "edit-entry" key 'k' "edit-entry; edit-line --find='kernel'" > I can commit Thomas' patch for the chainloader. I could do the other > two as well, if you don't want to. Please. :) > > - Implement autoload. This should be very easy. > > autoload? Is this the thing we discussed to automatically load > commands? Not only. Currently, GRUB has no way to resolve dependencies automatically, so I want to implement this feature. > > - Make it possible to call a hook when a variable is read/written. > > This would require some consideration about the API design. > > We discussed this a long time ago and it is already implemented. > Perhaps you have forgotten about this. But just have a look at > env.[ch] or ask me when it is not clear. Oops. I forgot it completely. Great, things are better than what I thought. > > - Implement some basic variables and commands (such as root and > > boot). > > Done already. You told me `root' should not be a command, but a > variable. Boot is implemented already. This went into CVS together > with the variable stuff. Ok. Very good. Perhaps I didn't read all mails carefully. I'm sorry. > As you might have noticed I am not that active all the time. I have > several projects I work on and to prevent myself from being bored I > switch projects weekly. That is a good thing. I also do very different things from time to time, depending on my interest. > What would be useful is extending the TODO if you feel important > things are missing. GRUB 2 is quite an active project (people > already know it and are willing to work on it) and chances are high > people want to work on things you put in the TODO. Especially when > it is networking related, from what I have noticed people want to > work on it but don't really know what to do. I see. I will do that. But maybe we want to have Wiki? I think Wiki is very efficient to share some rough ideas, such as a TODO list. What do you think? Okuji