Hi! * Karl Bowden <[EMAIL PROTECTED]> [20021017 12:17]: > > > > java, Gnome, KDE, Motif, BeOS, X, and TK widget wrappers > > > > > > Let me know if you start work on a Qt port. I haven't yet had time to do > > > it myself but I have looked at doing it once or twice. I saw the word > > > wrappers and not port up above, so I know this may not be what you meant. > > Should the GUI (Cafe) be written in C or C++?
'Use C++ to confuse your enemies; use C to produce stable code.' .. there's GLib ;) > > > > I will do that as soon as some one comes up with a good name for the > > > > project. > > > > > > Um, can't think of anything yet.. but it sounds as if DFB Cafe should be a > > > good working name for now. > > I would also like to see it intergrated enough to make it usable with > set-top boxes, mp3 players, etc. Not only (but primarly) a desktop > enviroment in other words. reinvent the wheel, AGAIN? :) there's KDE and Gnome, both with shortcomings, but both with potential for improvement. I don't want DirectFB to be 'another way to run X', either, but I don't like the notion of another application framework - AGAIN. there are already quite a few out there - so many that it almost seems necessary to create yet-another-abstraction-layer above them to be able to use the features one likes from each framework. 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 .. > > > > Personally I would hate to see DirectFB just become another way to run > > > > X11 apps, and would hate to see any disunity on the DirectFB platform > > > > like between GNOME and KDE. Although I would hope to intergrate most of > > > > the GNOME and KDE functions and widgets into DirectFB. > > > > > > Rather than integrating the widgets, you might want to see what are the > > > best features, (such as DCop and parts from KDE, I am sure Gnome has > > > something worthwhile). After all if it proves so useful in a > > > window-manager, (and can without bias be put into DirectFB) it probably is > > > worth integration. > > Agreed. What has a better archatecher, gnome or qt? Trolltech made the fatal error of not makeing Qt true OpenSource in the first place, thus effectively splitting the developers at a crucial moment in the development of the free Unix world, but .. to be honest: when I start up either KDE or Gnome, KDE usually takes far longer and uses far more memory - which doesn't say anything about the architecture, thou .. both seem to be made to jackalopes by developers out there, which isn't the way to go, I think. "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." -- Antoine de Saint-Exupery I think it's time to take away lots of things, and improve existing things this way. Why load lots of library code into memory when only 12% of the widgets are used? Runtime-loadable widgets come to mind .. Why use something like DCop when a less complex approach would suffice in an actual implementation? Proxy classes/objects come to mind, with runtime-loadable alternatives. I just don't see a place for ANOTHER application framework. People complain about 'no applications' being available, and developers complain about being forced to trade-offs with each application framework. A new application framework would require developers for the application framework, developers for the applications, and users for the applications .. these users either have to install the framework themselves, or you've got to gain enough acceptance to be included in distributions, for which maintainers are needed, ....... and they'd be needed for years, maintenance-wise. I see more promise in improving existing stuff, like making Gnome/GTK more modular so one isn't forced to drag along a rat-tail of never used object with an application (at least in memory), or porting window managers (from ratpoison over windowmaker to sawfish or fvwm) to almost native DirectFB, or just porting single features like Drag-and-Drop when a complete application framework (which would bring this with it) isn't required. Using different approaches for inter-process-communication could mean a step forward (-> smaller footprint, better performance), too. ... integrating this application framework with DirectFB would be even worse, and water down the purpose of DirectFB (Direct Frame Buffer access) .. expecially if you want it to work on SDL, too. Being able to run SDL on DirectFB running on SDL on XDirectFB running on DirectFB on the hardware is perverted enough, thank you ;) I simply prefer "let's make things better" over "let's reinvent the wheel". A library which aides developers and porters with helper functions would be nice, thou. There were intentions of doing one on this list, but the library hasn't started yet, I think mainly because of a missing name? How about 'libdfbee', like the busy bee which does all the work? :) I'd be happy if the project would be started in the DirectFB CVS, so people can start committing code / sending patches to the list. This way, instead of (again) reinventing the wheel for every development on (or port to) DirectFB, code could be shared. My two cents. Count -- 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.
