Re: GNOME ABI review



Hi Havoc,

On Thu, 2003-08-07 at 14:32, Havoc Pennington wrote:
> > >  In my opinion, applet ABI should be stripped of all dependencies and
> > >  become a protocol specification built around XEMBED and some IPC
> > >  mechanism (possibly just X events, but whatever is general).

	Wow - that's what we have currently :-) except that wait - XEMBED is a
mess and screws up badly for sizing, focus handling, oh and the mapping
logic is poor. So - some sort of wrapper is needed around XEMBED - call
it bonobo-plug/socket ;-> then of course some 'general' IPC mechanism -
say CORBA; and we've got something that actually works.

	Oh - and of course, we forget Accessibility. Clearly doing a large
amount of work to replace a working applet interface with something that
a) doesn't work and b) is substantially more complex [ X property IPC !
] and c) isn't accessible(?) doesn't sound to me like a wonderful plan.

	I would humbly suggest that it may be better to switch the existing
'tray' specification to using Controls instead - how are we doing a11y
of tray bits currently ?

> > 	What you are essentially saying is "applet's shouldn't be Bonobo
> > components"[1], right ?
> 
> Yes, I don't believe applets specifically should be. If they are we
> can only implement them with the whole GNOME stack, and we are then
> stuck with lots of app authors using the tray icon spec just to be
> cross-desktop or avoid dependencies. And the tray icon situation is
> fucked as you discovered.

	Lets fix the tray icon situation then.

	Seriously - I'm amazed that a focus of FreeDesktop currently seems to
be to create confusion around bonobo[ui].

	Much as admire the freedesktop.org initiative [ I think Gnome would
easily win on licensing grounds if all else is equal between KDE / Gnome
] - and appreciate your work on it - I think the strategy of trying to
FUD bonobo out of the picture is badly mistaken.

	Of course - the goal of sharing applets is a noble one - it seems a
better approach to me is:

	a) do the un-glamorous hard-work on glib/Qt to get decent 
	   mainloop integration => ORBit2 suddenly works well in KDE.

	b) write a separate, small, _out of process_ plugin to make Qt
	   controls out of existing applets

	Thus; we would end up with the same effect, a whole longer avenue of
integration possibilities, an easier life for the KDE a11y team, and a
better solution all round.

	Then again, we can sit down and start trying to write the full applet
interface - which may look small in IDL terms, but this is because it
uses the PropertyBag, UI handler etc. interfaces - using X properties.

	Of course - in a world where (perhaps) D/BUS provided a robust, well
performing, ABI stable IPC infrastructure, that was not just "flavour of
the month" things might be different - until then it seems premature to
start breaking things.

	This is really as Mark says putting the Dog well before the Horse;
indeed I couldn't concur more thoroughly with:

>         Anyway, to my point. If Bonobo is truly a part of our
> supported developer platform (even if its while we sit around and
> twiddle our thumbs waiting for something better to come along) then
> there is nothing wrong with our desktop making use of the technology.
> Far from being wrong, duplicating functionality that already exists in
> Bonobo makes absolutely no sense and gives the wrong message to users
> of our platform.

	Or in other words - let's not cripple Gnome now - to make the
freedesktop.org task easier somewhere down the road. There are still
people that believe that making Gnome as good as it can be is the best
strategy.

	OTOH - there are lots of great things that freedesktop.org can be
doing; eg. much hassle was made of the fact that:

	 "configuration should be stored in 1 place, and 1 place
	  only: GConf"

	Of course - this is a total non-issue; it doesn't much matter if
configuration cross desktop is stored in 10 different places, as long as
the places are predictable and standardised - such that the various
configuration apps can set both desktops' settings at the same time. [
and remote / management configuration becomes feasible instead of
complex ]. Ergo - standardizing a load of boring paths / keys makes lots
more sense than re-writing libbonoboui.

	But of course - none of this belongs in a discussion on the GNOME ABI.

	Hrm,

		Michael.

-- 
 michael ximian com  <><, Pseudo Engineer, itinerant idiot




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]