On Fri, 2006-09-22 at 20:03 +1000, Jeff Waugh wrote: > <quote who="Richard Hughes"> > > > I also think one of the reasons it was not written with gtk+ as a target > > was the "level choice" i.e. does this stuff belong in gtk+, libgnome, > > <insert_project_ridley_module_here> or some other module. > > It's really important we put a lid in this kind of confusion quickly, so we > can breathe life back into coherent platform design and development. It is a > serious problem when some of our best hackers don't feel empowered to design > for a particular target: Seriously, why *wouldn't* GTK+ be the correct place > to solve this *obviously* important use case (how many apps on our desktop > or embedded environments do or should need this functionality - heaps)? > > I'm not giving you stick here, Richard... although reading back I realise it > may sound that way. Mostly, I'm rocking the boat to find out how we can do > platform design and development in a more coherent way. Is the GTK+ team too > scary? Are GNOME platform requirements incompatible with GTK+ at all? Can we > build a better bridge between the projects? How can we break the cycle of > bollocks solutions like libegg and so on? How do we empower platform hackers > to make decisions and Get Things Done?
No stick taken :-) For me, is the dependency issue. Can gtk+ depend on DBUS? If the answer is yes, then the decision is a no-brainer - put libguniqueapp into gtk. If the answer is no[1], then we need something higher in the stack like libgnome, although I agree that it is not the preferred solution. Also, I want stuff to work *now*, not in 18 months time with a gtk+ module that (for me at least) is far on the horizon. The 'temporary' shared module gives us that. Thanks. Richard [1] or maybe, or "we probably need to ifdef stuff just in case..." _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
