All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Gerards <metgerards@student.han.nl>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: vesafb terminal for testing.
Date: Mon, 15 Aug 2005 19:41:23 +0200	[thread overview]
Message-ID: <87r7cvxflo.fsf@student.han.nl> (raw)
In-Reply-To: <200508151919.01579.okuji@enbug.org> (Yoshinori K. Okuji's message of "Mon, 15 Aug 2005 19:19:01 +0200")

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

> On Monday 15 August 2005 18:06, Vladimir Serbinenko wrote:
>> We don't need to make the whole thing absolutely skinnable (just the
>> basic skins)
>> if we make like I proposed (menus like terminals, in modules) because if
>> someone wants to
>> change completely the look he can just write a new menu module.
>
> A pluggable menu might sound good, but it's not so easy to maintain multiple 
> menu interfaces. Ideally, we want to have a single implementation which 
> accepts many parameters. I think it would end up with a kind of stylesheet 
> like CSS in HTML.

It would be nice if GUI's can be distributed as plugins...

Isn't XML often used to describe interfaces?  Perhaps we can use a
structured form of storing data like XML...  But that is just a random
thought. :-)

>> > -mouse handling (??)
>>
>> It must not be difficult: we can just port mouse.com from FreeDos or use
>> any other
>> mouse implementation.
>
> It is actually difficult, because USB mouse support requires interferences 
> with other USB devices. Most modern BIOSes support USB legacy interfaces, 
> such as USB disks and keyboards. It is not easy not to affect them.

It's not easy on the PC.  But AFAIK it should be easy with EFI and
IEEE 1275, but I have not taken a close look yet.

>> Now the most important
>> questions is how
>> to make the *general/basic* things to ensure the maximum flexibility in
>> the future as
>> Yoshinori K. Okuji said in about 6 months we have to block them: don't
>> change them anymore.
>
> Don't take my argument too strictly. It can be in 6 months, in 3 months or in 
> 12 months. In principle, I do not want to feature-freeze GRUB 2 until we are 
> satisfied enough with the design. This opportunity -- redesigning everything 
> -- is really hard to obtain. Note that I had to wait for 3 years to start 
> GRUB 2. So I wouldn't stop thinking how to improve GRUB very soon.

Right.

> Also, as long as changes do not affect compatibility, we can add more features 
> later. Indeed, I have implemented a number of new features even in GRUB 
> Legacy without losing any bit of compatibility (Do you know that 0.97 is 
> completely backward-compatible with 0.4?). It was quite hard sometimes but 
> feasible.

Right, but it would be the best if we think now and design the
interfaces.  We don't need to implement it all and it does not have to
be perfect, it is important to have a good foundation we can build on.

> Anyway, I expect that we will not have to wait too long to see what we want to 
> do with a fancy menu, since Vesa is very fast to implement the code. 
> Hopefully, we will see the first working version in this month or next month. 
> Once it starts working, the discussion will be much easier.

Agreed.

Thanks,
Marco




  reply	other threads:[~2005-08-15 18:14 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-14 11:52 vesafb terminal for testing Vesa Jääskeläinen
2005-08-14 14:48 ` Yoshinori K. Okuji
2005-08-14 15:45   ` Vesa Jääskeläinen
2005-08-14 16:47     ` Vladimir Serbinenko
2005-08-14 19:25       ` Yoshinori K. Okuji
2005-08-15 15:23         ` Vincent Pelletier
2005-08-15 16:06           ` Vladimir Serbinenko
2005-08-15 17:02             ` Marco Gerards
2005-08-15 17:19             ` Yoshinori K. Okuji
2005-08-15 17:41               ` Marco Gerards [this message]
2005-08-15 18:55                 ` Yoshinori K. Okuji
2005-08-15 20:54                   ` Marco Gerards
2005-08-15 21:44               ` Vesa Jääskeläinen
2005-08-16  6:47               ` Vincent Pelletier
2005-08-16 10:20                 ` Marco Gerards
2005-08-15 17:07         ` Marco Gerards
2005-08-16  6:54           ` Vincent Pelletier
2005-08-14 21:48       ` Vesa Jääskeläinen
2005-08-14 22:19         ` Yoshinori K. Okuji
2005-08-15 15:52           ` Vesa Jääskeläinen
2005-08-15 16:13             ` Yoshinori K. Okuji
2005-08-15 15:42         ` Vladimir Serbinenko
2005-08-19  0:48   ` Yoshinori K. Okuji
2005-09-18 21:03     ` Vesa Jääskeläinen
2005-09-19 19:00       ` Yoshinori K. Okuji
2005-09-19 23:11         ` Vesa Jääskeläinen
2005-09-20 17:13           ` Yoshinori K. Okuji
2005-08-15 17:24 ` Marco Gerards
2005-08-15 21:05   ` Vesa Jääskeläinen
2005-08-15 21:21     ` Marco Gerards
2005-08-15 21:39       ` Vesa Jääskeläinen
2005-08-16 10:04         ` Marco Gerards
2005-08-16 18:36           ` Vesa Jääskeläinen

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=87r7cvxflo.fsf@student.han.nl \
    --to=metgerards@student.han.nl \
    --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.