(Instead replying a long mail, I try to summarize here based on my progress.)
Are you looking at OpenBox 3 ? It is totally different from OpenBox 2. It is a much minimal window manager than WindowMaker by default. So my plan now is try to decompose a regular window manager (WindowMaker) into different components. XWindow is actually desiged to do so. In this way, we can have a separated taskbar (dock, clip), pager (workspaces), and a window manager. It makes everything easier to maintain. I attach a AZTaskbar as an example. AZTaskbar basically go through all the xwindow and shows up as buttons. You can use it to change focus and deiconify windows. It is a proto-type to experiment event handling with GNUstep and XWindow. WindowMaker has many legacy codes which is not easy to tackle with. Rewriting WindowMaker is like walking in minefield. :( And you cannot remove WINGs completely before the rewritting is done because it provides some very basic functions (array, dictionary, etc) for WindowMaker. Anyway, I am not complaining WindowMaker. It is just not a good reference if we want to rewrite it with GNUstep. OpenBox doesn't know GNUstep at all. Therefore, it does not fit well with GNUstep. But it is also a good chance to review current implementation of GNUstep regarding to XWindow. There are some glitches in AZTaskbar, which is related to window manager. So my first question is what kind of taskbar we want for Etoile ? Windows taskbar ? MacOS X Dock ? or NeXT App Icon ? I guess it is about time to have a discussion. I prefer not to polish AZTaskbar before we have a conclusion. :) By the way, I hate customization. So please don't say *let the user choose*. It just adds too much overhead on programmer at this stage. As for client/server style, it is just something we can experiment. But we can discuss it later since we have no good implementation of window manager yet. Now, I am trying to write a pager to control workspaces. With a taskbar and a pager on hand, the window manager will be easier to work on. And this is interesting to check out: http://idesk.sourceforge.net/wiki/index.php/Main_Page Have fun !! Yen-Ju On 3/19/06, Quentin Mathé <[EMAIL PROTECTED]> wrote: > Le 17 mars 06 à 08:10, Yen-Ju Chen a écrit : > > > There is a light-weight window manager called OpenBox at > > http://icculus.org/openbox/ > > It seems to work fine with GNUstep applications. > > Is there anyone having problem using OpenBox with GNUstep > > applications ? > > I haven't tested it yet but I'm going to. > > > I am at a point that Alazea need to be rewritten significantly > > and I am still evaluating how to do that. > > In this case, OpenBox may be actually a better choice than > > WindowMaker. > > I am still reading the source codes of OpenBox. > > I'm currently reading them too :-) > > > But as far as I can tell, OpenBox is cleaner than WindowMaker. > > It seems so, but the code base seems to be a bit larger. Probably > because it is more full featured than WindowMaker, or perhaps it is > just a bias due to the fact OpenBox is better componentized. > > OpenBox seems to have interesting features like : > - very flexible built-in theme engine (we could bridge it with > Camaelon or straight out replace it with Camaelon) > - windows snapping and resistance > - full EWMH support > - WindowMaker dock app support (not sure about this feature, I read > about it on OpenBox 2 page) > - very good integration with GNOME and KDE (less important probably > but well) > > > I guess it is because WindowMaker is written before > > the new wm specification emerges from Gnome and KDE. > > > > Although WindowMaker is the official window manager for GNUStep, > > I remembered many people still complain about it. > > I wonder what's the main problems for WindowMaker with GNUstep > > applications ? > > Focus problems time to time with: > - Vertical menu > - Application windows (when you are switching from one app to another > app) > > Too much non-core features like: > - Dock > - Clip > - WPrefs > > No integration with GNUstep notifications and/or events loop > (especially problematic with NSWindow classes, iirc most of > notifications like windowDidMove:, windowDidResize: etc. just don't > work… child windows aren't supported too I think) > > What would be your plan if you decide to take on OpenBox… rewrite > Azalea from scratch by forking OpenBox, merge both in one pass or > progressive Azalea rewrite with OpenBox code ? > > Quentin. > > -- > Quentin Mathé > [EMAIL PROTECTED] > > > _______________________________________________ > Etoile-dev mailing list > [email protected] > https://mail.gna.org/listinfo/etoile-dev >
AZTaskbar.tar.gz
Description: GNU Zip compressed data
_______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
