Re: [AD] Leveraging the OS' window management

[Laurence Withers <lwithers@xxxxxxxxxx>]

In reply to Vincent Penquerc'h <Vincent.Penquerch@xxxxxxxxxx>:
>I do not see major problems with this.
>There is similar code to deal with input focus among widgets
>in a dialog. This could possibly (I haven't actually thought
>of it) be extended, and a window would be a special kind of
>widget.
>BTW, another annoyance of the dialog manager is the lack of
>structure. A tree would be nice, and would open grounds for
>this kind of window management.

OK, since the GUI *keeps* coming up, here is something I wrote to the
Guibrella list a while ago. Please read it, and think carefully before
replying, if at all. Please don't keep saying "the GUI needs this, that
and the other"; otherwise, it will quickly become a maintenance
nightmare with relatively few users.

------------------------------------------------------------------------

I know this list has been quiet recently, but it seems like quite a good
place to discuss the future of Allegro's GUI. Since we have decided to
break backwards compatibility (probably), this now gives us a chance to
really review what is going on with the GUI.

It seems that we do need a built-in GUI, mainly for the grabber. It is
also useful for things like setup, examples, and tests. So we can't
really just remove it and tell people to use an add-on. I think we
therefore have three main options:

Simplify it
-----------

Since we have to have a GUI, and it is only used by us for basic things,
we could simplify it a good deal. This means removing some widgets we
don't need (d_text_list_proc springs to mind), maybe some of the events
(MSG_IDLE, perhaps others), and generally tidying up the code (removing
things like auto-opening of menus, which has created a lot of
complexity).

Pros: nice clean GUI, obviously primitive so users will use an add-on 
      instead, easy to maintain once written
Cons: needs a rewrite, and lots of people will say `let's extend it'

Leave it alone
--------------

We already have a working GUI system, with loads of bugfixes applied
over the ages, so we could just leave it as it is.

Pros: doesn't require any work, doesn't break API in itself
Cons: we still have the same situation as currently; people complaining
      about its lack of features/useability, jumping through hoops to
      extend it, poor design for a complex GUI system, complex code in
      which bugs still surface

Replace it
----------

We write a general-purpose GUI system which can be extended in a
sensible way, and ship it with Allegro.

Pros: becomes useful for the general population, gives users a simple
      and effective way to implement a GUI, useful for games and
      multimedia applications
Cons: requires much implementation work, yet another GUI.



If left up to me, I would probably replace it, but this isn't my
decision to make. So may I have some input? Please? :-)

------------------------------------------------------------------------

Bye for now,
-- 
Laurence Withers, lwithers@xxxxxxxxxx
                http://www.lwithers.demon.co.uk/

Attachment: signature.asc
Description: PGP signature