>>>>> "Elan" == Elan Feingold <feingold_at_zko.dec.com> writes:
Elan> When I was thinking about writing a Start bar for fvwm (a la
Elan> Win95's start bar), I thought: `this has got to be a
Elan> module'. But then I realized that it would primarily be
Elan> using (a) Pixmaps from the icons, and (b) Menus. Using its
Elan> own menu code would be wasteful, since 99% of it would be
Elan> identical with fvwm's menus, and I would hate for it to have
Elan> its own pixmaps, when they are in common with fvwm's (unless
Elan> somehow, fvwm told the module about the pixmaps).
The code in fvwm/menu.c can be divided between
1/ code that generates and destroys menus in memory;
2/ code to display menus.
Obviously, only (a part of) 2/ has to be rewritten. If it is possible
for fvwm to pass a complete menu data structure to a module when it is
modified, then 1/ could be kept in fvwm/, along with some additionnal
communication code. If this is not possible, 1/ could be at least
moved to fvwmlib to avoid source duplication, if not code bloat (which
could be avoided with a shared library, but since libfvwm is so
small...)
Then the code of 2/ could be duplicated from fvwm/menus.c. The same
holds for drawing windows, since positionning the title and using
xpm's is not enough to emulate the look and feel of a window manager.
Now, if we can come up with a relatively simple definition of menu
appearance that can be parameterized (for example, in terms of color
and shadow thickness for menus themselves, selected item, separators,
submenu arrows, etc.), then some general code could be written and an
UI would just be a set of parameters (Just have to do 'Read Win95Menus'
to enable it). Thus, no specific code would be hardcoded in fvwm for
these menus.
Elan> I still think it should be a module, but I also think the
Elan> issues remain. The counter argument is that the start bar
Elan> is simply a type of menu just like the pop-ups that exist in
Elan> fvwm today.
The start bar is also, if I am not mistaken, an icon manager that
shows all (iconified ?) applications. It could be programmed as such
(perhaps derived from FvwmIconBox) and call fvwm do displays
menus. Then, if you have a module that can display win95-like menus,
they will be shown as such. Of course, the same module could be both
an icon manager and an UI module.
Elan> As far as Menu styles, the MenuStyle Win95 was simply based
Elan> on the existing MenuStyle Motif, MenuStyle Fvwm. I think
Elan> that once a core amount of functionality has been agreed on
Elan> for fvwm (e.g. title bar & title buttons, borders, pop-up
Elan> menus, etc.), then these should be customizable via Style
Elan> directives. If the code were written in an OO programming
Elan> language, this would be probably easier than it is today,
Elan> and it would allow for a cleaner separation of these styles
Elan> (i.e. class MacTitleBar : public TitleBar) (but this is just
Elan> my opinion :)
Yes, but not every one want a large fvwm binary that can handle 45
different user interfaces. You like win95 look, but assume that
someone wants to add windows 2.0 or even twm ; the code will shortly
become very difficult to maintain. I think that the mwm style has some
reasons to be in the core, since mwm is typically a unix window
manager (except for Geos on PC, but this is a different
problem...). Moreover, fvwm tries to emulate mwm for Motif programs
that expect it to be there. The win95 style is more like an aesthetic
add-on (which I'd really like to see, in fact :-).
The example of Geos is not really innocent. In this OS, all the UI
stuff is located in a module (a geode, in geospeak). If you change this
module, the whole user interface is changed (not only the menus or
window decorations, but all dialogs, scrollbars, etc.). I have not
seen it myself, but a MacIntosh interface and a windows 2.0 interface
have been demonstrated for various versions of Geos.
If this is not too difficult in terms of coding and/or to slow, I'd
like to see fvwm take this direction. But, well, I don't really know C
or Xlib, so I won't do the coding myself. So I guess that people that
do the *real* work should be free to choose what they want to do :-)
Jean-Marc.
--
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Mon Oct 09 1995 - 10:58:53 BST