From: "D. Huizenga" <skis AT concentric DOT net>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: New GUI?
Date: Sun, 08 Mar 1998 00:00:22 -0500
Organization: Student
Lines: 123
Message-ID: <350225E6.1E61F4E9@concentric.net>
References: <35011748 DOT 68BB AT cam DOT org>
NNTP-Posting-Host: ts003d18.gps-mi.concentric.net
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

My earlier message didn't seem to make it to the group, so here it goes 
(again). The formatting got off by a little when I took it out of my
sent
box, sorry about that..

Vic wrote:
> 
> Hey, it seems everybody is doing one these days, and so am I :)
> Now, seriously, I got interested in the "who wants win95 look for
> allegro" thread and I started my own 3D looking windoze like GUI.
> Is there any interest in a new one?

Sure, the more the better, right?  Why not make an actual *window
manager*, 
as there are plenty of WIN-95 like GUI's out there already. (Just a
suggestion)

> The reason I did this is, well, I didn't like the others.
> Some of them look nice (like Degui for example) but they are based on
> Allegro. I don't like the allegro GUI cause
> 1: the buttons don't act like bloody buttons! (I mean, they act like a
> checkbox only look different!)

I have a partial solution to this: in BGui, there is a procedure called
d_ex_billbutton_proc which will call a callback function when pressed
instead of just staying down.  The callback function is called with
callback_proc(d->dp3, d->d2).
There is also a button which is SUPPOSED to play a sample when pressed,
and call a callback function with no parameters, but it doesn't play the 
sound properly.

[Perfect spot for a shameless plug for the updated [3.7.98] versions of
BGui, and
 BGrabber, available on my page at
http://www.concentric.net/~skis/bgui.htm.
 All links are now working, and the spelling is still just as bad ;-) ]

> 2: you are trapped inside the dialog.(meaning you say do_dialog() and
> that is it) 

With the release of Allegro 3, it is now possible to continue doing
other things while a dialog is open, using init_dialog, update_dialog,
and
shutdown_dialog.

> The dialog draws directy on screen. If you want to add your
> own thing on the screen you have to add a dialog procedure. etc.

Simple solution (Typed off of the top of my head): 

BITMAP *oldscreen;
BITMAP *memory_bitmap;
memory_bitmap = create_bitmap blah blah blah;
oldscreen = screen;
screen = memory_bitmap;

This is really handy, especially if you have a moving background behind
a dialog.

> So I coded for a couple of hours and I got the bases of a 3D GUI, where
> buttons are buttons, and you just tell it to "update" itself on a
> bitmap, and it will check for mouse and keyboard input, and draw itself.
> The thing is based on a message system, it calls the object's MouseOver,
> MouseDown etc.
> Should I put the sources on the Web?

Go ahead. I'm sure there are a lot of people who would like a more
flexible dialog system. (Me included).  I think a better solution that 
the one you are going for would be to simply write a new d_button_proc
for 
Allegro, and then send it to Shawn to be included in the next release of
Allegro. 
Perhaps we should start a project to write a windowing system for
inclusion in Allegro? 
Any comments on this idea?  

A few suggestions that I have for it:

- Try and keep it as compatible as possible with the current system. For
  instance, maybe have a type called WinSystem, in which you define
windows,
  like dialogs are now, and each element contains a pointer to a dialog.

- Have a variable like alleg_dialog_style to change between different
  drawing routines for the winsystem/dialog. For instance, there could
be a 
  Windows style, Mac style, Atari ST style (That's a must ;-), and a
X-Windows style.

- Instead of using the quick hack posted above, there should be a BITMAP
pointing at
  where to draw the dialog system.

- Instead of having the clunky FG/BG for each element of the dialog,
  have global RGB's that are used for the entire winsystem. 
  This would simplify things a lot (I think).

- Last, but not least, KEEP IT SIMPLE! For clipping the windows
  properly, I like the idea posted on another thread where you call
something like
 
   while(next_rect) {
    set_clip(get_next_rect); 
    draw_window(win);
   }

- Please post any other ideas that you have.

> --
> --> http://www.cam.org/~tudor <--

Hope to see your source there soon! Have you checked out BGui, at my
home page? It's a win-95 like drop in replacement for the DIALOG system. 
I have also posted a version of the Grabber done with it. Things that
aren't 
implemented yet are the menus and radio buttons.

--
Dan Huizenga
Email: Skis AT Concentric DOT net
Home: http://www.concentric.net/~skis
(Not much there right now, except BGui [now there's actually an 
 example program ;-)])