Hi again! * Karl Bowden <[EMAIL PROTECTED]> [20021018 13:19]: > On Fri, 2002-10-18 at 10:26, Ian Walters wrote: > > On Thu, 17 Oct 2002 9:30 pm, Andreas Kotes wrote: > > > but this is not the way to go (I think). I think the correct approach > > > ist stripping unnecessary layer after unnecessary layer, and shorten > > > thought (and data!) pathes .. i.e. KDE with QT on XDirectFB on DirectFB > > > is worse than Gnome with GTK-DirectFB on DirectFB .. > > With the unnecessities gone what should we start building first? I am > actually really growing on the idea of getting a cut down ver of gnome > (or gtk?) running and using the system for the non-gui stuff like cut > and paste as mentioned further down.
sounds great :) > Keep the system stuff in a library in DirectFB though? I (for myself) would place any drawing, window(stacking/decoration), input/event and other routines _directly belonging to and only depending on_ DirectFB into libdirectfbee (a project yet to be started on cvs.directfb.org).. By 'only depending on DirectFB' I really mean 'only depending on DirectFB', i.e. preferrably no system calls or something. > Work on a cut down gnome? or just use gtk (the widget set) and the > system for window management and other stuff? In your place, I'd start digging through the gnome/gtk libraries, isolation the (drawing) code which isn't specific to gnome/gtk and extract it. This code should be send as a patch for libdirectfbee, and afterwards, gnome/gtk (or e.g. Qt, for that) should (when compiled for DirectFB, the #ifdef .. #else .. #endif game ..) use these routines instead of the current code. Reduces code size in gnome/gtk and takes care of getting a reasonable code base for libdirectfbee. Then, I'd start segmenting gnome/gtk into single widget, which can be selected to be included into the library at compile (or static link) time. For both of these steps, you should coordinate your efford with the Gnome/GTK developers to avoid double work, or code divergence. > Should DirectFB have a builtin window manager, or be able to run > multiple window managers (it would be nice to have one window manager > with xml style sheets flexable enough to make it run like rat-piosion or > run like enlightenment)? >From my perspective, the windowing stack in DirectFB has the potential to provide a solid base for a window manager, thus libdirectfbee should provide enough helper functions (stacking, focus, decoration, etc, perhaps even themes - would help with Gnome/GTK, too) to make writing a new window manager a ~1000 lines task, or to make porting and existing window manager less time consuming. (Another place where using common drawing routines helps reducing code size/memory footprint). > I like the intergrated nature of enlightenment. If you have a system > library should it include a file-manager (I like the one out of > enlightenment)? > Should it also have Dialog box's like open and save and stuff? Both of these would/should be implemented as widgets, which should have their place in a library providing widgets which can be utilized by applications, not in a library or context where drawing and utility functions of a lower layer are provided. Kind regards Count P.S: I really love it when people show some sense for quoting sanity ;) -- Andreas Kotes - ICQ: 3741366 - The views expressed herein are (only) mine. Unser Leben ist das, wozu unser Denken es macht. -- OpenPGP key 0x8F94C228 Our Life is what our thinking makes it.. Your mind is a weapon! Load it .. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
