From: "Yoshinori K. Okuji" <okuji@enbug.org>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: usability
Date: Sun, 1 Aug 2004 00:09:38 +0200 [thread overview]
Message-ID: <200408010009.38512.okuji@enbug.org> (raw)
In-Reply-To: <87k6wkdkhf.fsf@marco.marco-g.com>
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
next prev parent reply other threads:[~2004-07-31 22:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-31 18:32 usability Yoshinori K. Okuji
2004-07-31 19:50 ` usability Marco Gerards
2004-07-31 22:09 ` Yoshinori K. Okuji [this message]
2004-07-31 22:59 ` usability Marco Gerards
2004-08-01 11:00 ` usability Yoshinori K. Okuji
2004-08-01 15:24 ` wiki Yoshinori K. Okuji
2004-08-01 20:40 ` wiki Marco Gerards
2004-08-02 11:41 ` wiki Yoshinori K. Okuji
2004-08-04 11:14 ` wiki Yoshinori K. Okuji
2004-08-02 15:05 ` usability Tomas Ebenlendr
2004-08-04 11:18 ` usability Yoshinori K. Okuji
2004-07-31 22:34 ` usability Yoshinori K. Okuji
2004-08-01 8:40 ` usability Jeroen Dekkers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200408010009.38512.okuji@enbug.org \
--to=okuji@enbug.org \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.