usability

usability

[Yoshinori K. Okuji]

Hello,

I have stopped my work on GRUB 2 for a while, but I now would like to 
restart it again.

My initial goal is to make it possible to use GRUB 2 for real purpose 
(e.g. on my computer with which I write this mail). This is the most 
important for me, since it is really tiring to maintain both GRUB 
Legacy and GRUB 2. I don't think this will be feature-rich in near 
future, and I intend to focus on very fundamental things. I will do 
these as the first step:

- 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.

- Support a config file. I can just port the support from GRUB Legacy, 
but I will consider if it could be improved. At least, I want to 
include support for including a portion of a config file from another 
file, and support for specifying a label to a title, so that you can 
use a label instead of a number to specify an entry.

- Implement some loaders on i386-pc for the normal mode (such as linux 
and multiboot). This should be very easy.

- Implement autoload. This should be very easy.

- Make it possible to call a hook when a variable is read/written. This 
would require some consideration about the API design.

- Implement some basic variables and commands (such as root and boot).

Probably I won't be very fast, because it is very hard for me to work in 
weekdays. If you are willing to work on any of them, let me know, so 
that we won't waste time due to duplicated work.

Okuji

Re: usability

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> I have stopped my work on GRUB 2 for a while, but I now would like to 
> restart it again.

Nice!  Welcome back!

> My initial goal is to make it possible to use GRUB 2 for real purpose 
> (e.g. on my computer with which I write this mail). This is the most 
> important for me, since it is really tiring to maintain both GRUB 
> Legacy and GRUB 2. I don't think this will be feature-rich in near 
> future, and I intend to focus on very fundamental things. I will do 
> these as the first step:

This is very important.  The sooner people can use GRUB 2, the sooner
we can expect patches, testers, etc.

> - 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.

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.

> - Support a config file. I can just port the support from GRUB Legacy, 
> but I will consider if it could be improved. At least, I want to 
> include support for including a portion of a config file from another 
> file, and support for specifying a label to a title, so that you can 
> use a label instead of a number to specify an entry.

I think including config files is an important feature.  

> - Implement some loaders on i386-pc for the normal mode (such as linux 
> and multiboot). This should be very easy.

I can commit Thomas' patch for the chainloader.  I could do the other
two as well, if you don't want to.

> - Implement autoload. This should be very easy.

autoload?  Is this the thing we discussed to automatically load
commands?

> - 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.

> - 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.

It seems that you can't remember all things we discussed and that I
have changed.  If there is something not clear, please ask me.  It
would be a waste of time if you would implement things that are there
already, etc.

> Probably I won't be very fast, because it is very hard for me to work in 
> weekdays. If you are willing to work on any of them, let me know, so 
> that we won't waste time due to duplicated work.

Just see what I just said.  Other than that I will focus on making the
PPC port functional and adding filesystems.

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.

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.

Thanks,
Marco

Re: usability

[Yoshinori K. Okuji]

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

Re: usability

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> We need to discuss more on internationalization... I will post my idea 
> about this later.

Please do.  I know very little about this subject and I think that is
true for many people.  I am Dutch and for Dutch (and English) ASCII
(or anything ASCII like) is enough.

So I don't know much about it, when it is used, etc.  But don't take
me wrong, I find this very important.

>> 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.

Ok.  You already implemented a very simple menu.  But when I choose an
option, nothing happens.  It is easy to change it so it actually boots
the option you have chosen.

I know you want to work more on this, but I think it is important to
have something that works in an early stage.  For the Pc and apple
versions we have almost everything that is required.

> BTW, if you have any new feature you want in GRUB 2, let me know. I'm 
> thinking these extensions:

I think I told you my opinion in every case and I will continue to do
so.

> - Labelling entries

What is a label used for?

> - Tree interface
> I'm not sure about this feature.

I like it.  Currently on my development box I have a boot item called
"Network menu" (yeah, stupid name).  When I choose that it loads the
menu.lst from my tftp server.  In that menu.lst some GNU Mach, L4 and
toy kernels are listed.

> - User-definable shortcuts

Nice.

>> I can commit Thomas' patch for the chainloader.  I could do the other
>> two as well, if you don't want to.
>
> Please. :)

Ok.

> Not only. Currently, GRUB has no way to resolve dependencies 
> automatically, so I want to implement this feature.

I think Thomas sent in a patch for this, right?  Could you please
review it?  You have more knowledge about module loading.

>> 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?

This is a very good idea.  Can you set up a wiki?

Thanks,
Marco

Re: usability

[Yoshinori K. Okuji]

On Sunday 01 August 2004 00:59, Marco Gerards wrote:
> Please do.  I know very little about this subject and I think that is
> true for many people.  I am Dutch and for Dutch (and English) ASCII
> (or anything ASCII like) is enough.

Done.

> Ok.  You already implemented a very simple menu.  But when I choose
> an option, nothing happens.  It is easy to change it so it actually
> boots the option you have chosen.

Ah, I understand.

> > - Labelling entries
>
> What is a label used for?

I wrote this example in the previous mail:

default hurd-l4

title --label=hurd-l4 Hurd/L4
root=(hd0,0)
...

Or

title Hurd/L4
label hurd-l4
root=(hd0,0)
...

Labels should be able to be used in everywhere you can specify entry 
numbers, such as default, savedefault and fallback. If this is 
implemented, it could be much easier to modify config files 
automatically by shell scripts.

> I think Thomas sent in a patch for this, right?  Could you please
> review it?  You have more knowledge about module loading.

I think his patch is only for commands. Autoloading filesystem modules 
is not implemented, and I want to have commands in the normal mode to 
load/unload modules with/without resolving dependencies automatically.

BTW, one problem in his patch is that autocmd.lst is maintained 
manually. It is better to generate this file automatically at the 
compilation time.

> This is a very good idea.  Can you set up a wiki?

Do you know any site which we can use freely (and permanently, if 
possible) ?

I can set it up on my server, but I'm afraid that mine is too poor for 
dynamic page rendering, because it is an OpenBrick. This may be a good 
occasion to get an OpenBrick NG, but I have no money to buy a new 
machine at the moment.

One way is to use a hosting service, such as BerliOS or SourceForge. 
BerliOS might be a good option, because it has a builtin wiki 
interface, while you must set it up manually on SourceForge. It is 
unfortunate that Savannah does not have any way to set up a wiki site.

I will talk about this with Savannah hackers.

Okuji

wiki

[Yoshinori K. Okuji]

I installed a wiki into my own server using MoinMoin:

http://enbug.org/grubwiki/

I put this in my site temporarily. Probably I will move this to another 
server.

Okuji

Re: wiki

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> I installed a wiki into my own server using MoinMoin:
>
> http://enbug.org/grubwiki/

It works perfectly for me.  I just assume I have all freedom to do
what I want.  If you don't agree with something, just change it or
bring it up for discussion, ok?  I think that is the best way to work
when using a wiki.

I have added a section for bugs.  I think for know it is best to
maintain bugs in the wiki, instead of in CVS (like we discussed about
earlier).  If you think this is stupid, just remove it.

> I put this in my site temporarily. Probably I will move this to another 
> server.

Ok.

Thanks,
Marco

Re: wiki

[Yoshinori K. Okuji]

On Sunday 01 August 2004 22:40, Marco Gerards wrote:
> It works perfectly for me.  I just assume I have all freedom to do
> what I want.  If you don't agree with something, just change it or
> bring it up for discussion, ok?  I think that is the best way to work
> when using a wiki.

I'm used to wiki, so don't worry.

What I'm afraid of is what happens if many people access it. The machine 
does not have a lot of memory, so it would be too slow to use it.

> I have added a section for bugs.  I think for know it is best to
> maintain bugs in the wiki, instead of in CVS (like we discussed about
> earlier).  If you think this is stupid, just remove it.

It's ok for now. CVS is better, since it is in the well-maintained site 
(Savannah). Wiki is not very good, since it is in my personal site.

Normally, personal sites cannot be trusted, because they can disappear 
or stop long suddenly. For example, if I decide to change my 
appartment, I will have to stop the server, obtain a new internet 
connection, change the ip address in the dns server, and so on. This 
may take one week or more, especially if this movement is across 
countries. If a fast connection is too expensive, I will just give up.

So I'd like to find a more stable place as soon as possible. If you have 
any idea, let me know.

Okuji

Re: wiki

[Yoshinori K. Okuji]

I succeeded to find another place for the wiki:

http://www.autistici.org/grub

It is hosted by Autistici in Italy, and it is faster than my machine 
(probably the network speed rather than the machine itself). So please 
use the new one from now on. I will add a link to the wiki into the 
GRUB web site later.

Can anybody move the contents to the new server?

Okuji

Re: usability

[Tomas Ebenlendr]

> > I think Thomas sent in a patch for this, right?  Could you please
> > review it?  You have more knowledge about module loading.
> 
> I think his patch is only for commands. Autoloading filesystem modules 
> is not implemented, and I want to have commands in the normal mode to 
> load/unload modules with/without resolving dependencies automatically.
> 
> BTW, one problem in his patch is that autocmd.lst is maintained 
> manually. It is better to generate this file automatically at the 
> compilation time.
> 

I wrote something about module loading to wiki. (ModuleLoading, one
click from TodoList (section grub-emu)).

Today, grub-emu contains some modules (compiled in). If there will be
way to run modules from unix, then we can replace function for
registering commands with function which will write module name and
function name to the file autocmd.lst. Other way is sed-like, but then
one must be carefull where the he writes the registration of commands.

-- 
                                 Tomas 'ebi' Ebenlendr
                                 http://get.to/ebik
                                 PF 2004.58661540554

Re: usability

[Yoshinori K. Okuji]

On Monday 02 August 2004 17:05, Tomas Ebenlendr wrote:
> Today, grub-emu contains some modules (compiled in). If there will be
> way to run modules from unix, then we can replace function for
> registering commands with function which will write module name and
> function name to the file autocmd.lst. Other way is sed-like, but
> then one must be carefull where the he writes the registration of
> commands.

Another way is to define the information in the rmk files. Like this:

foo_mod_COMMANDS = foo bar

Then make can generate autocmd.lst.

Okuji

Re: usability

[Yoshinori K. Okuji]

About internationalization:

GRUB 2 has a goal of internationalization. Here, i18n means these things 
(in my definition):

- Messages can be translated

- Non-ASCII characters can be used in config files

- Non-ASCII characters can be displayed

- Non-ASCII characters can be used in file names

The last one might not be important, because you don't use non-ASCII in 
OS image files normally (consider /boot/vmlinuz). But I think 
filesystems should be able to list up file names with non-ASCII 
characters at least, so that the user can see some useful information 
on the screen when she types "ls".

The first one should be realized in the same way as gettext, but it is 
not implemented yet.

The third is possible in my test environment. I tested it with Japanese, 
and worked fine.


When you want i18n, you need to define something about character code 
and encodings. For now, I select Unicode as the standard character code 
and use UTF-8 and UCS-4 as the encodings. I think this is a good idea, 
because Unicode makes things a bit simpler than mixing a lot of code 
(like ISO2022-JP-2). UTF-8 is used in most places, because it has a 
good compatibility with ASCII. UCS-4 is used only in the console stuff 
at the moment. This makes the implementation of a console device 
easier, because you can represent each character in a fixed size (this 
is not completely true, because of ligatures).

Therefore, you must assume that UTF-8 is used when you use strings in 
your code. And, you must not assume that the length of a string is 
equal to the size of the string on the screen. For example, many 
European characters are 2-byte in UTF-8, but they are shown as 1-column 
characters on the screen. So you must distinguish between the length 
and the column size carefully.

In reality, what does the user want to do? I guess she wants to do 
these:

- See messages in her own language

- See titles in the menu in her own language

- Write comments in config files in her own languages

So I'd like to assume that config files are written in UTF-8. Maybe we 
can support other encodings, but this requires some heuristic methods 
or an explicit declaration of an used encoding. I feel that this is too 
much, since people normally do not use UCS-2 or UTF-7 in text files. 
But some people may want to use "legacy" chracter code, such as 
ISO-8859-1 and EUC-JP.

I'm not sure if it is better to translate error messages from commands. 
This should be a bad idea from developers' point of view, but useful 
for ordinary users. More thoughts are needed.

Do you have any idea or question?

Okuji

Re: usability

[Jeroen Dekkers]

At Sun, 1 Aug 2004 00:34:30 +0200,
Yoshinori K. Okuji wrote:
> I'm not sure if it is better to translate error messages from commands. 
> This should be a bad idea from developers' point of view, but useful 
> for ordinary users. More thoughts are needed.

Sometimes users come to #gnu with a make error in their own language
for example. It's pretty hard to know what's wrong. But if we give
every error message a number that is displayed this shouldn't be a
problem. People helping users can just look up what the corresponding
error message is in their own language.

Jeroen Dekkers