[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: glib in kdesupport: yes or no?
From:       Don Sanders <sanders () kde ! org>
Date:       2003-03-10 5:42:28
[Download RAW message or body]

Hi Havoc,

I am concerned. I am concerned that adopting glib for KDE (CVS) 
development will make developing KDE more difficult.

If glib is adopted and used (by someone else) in code I work on or 
want to work on then I will be required to understand glib in order 
to develop for KDE.

This additional complexity is not something I anticipate in a positive 
way, I don't support inviting other developers to decide that I 
should use glib, and hence this request is not one I can support.

Don.

On Monday 10 March 2003 09:59, Havoc Pennington wrote:
> Hi,
>
> Here is my standard .02 on this issue -
>
> Choice vs. Fragmentation
> ===
>
> FWIW, in my FOSDEM talk and other presentations about
> freedesktop.org I find it useful to describe interoperability as
> follows:
>
>  - the applications should be orthogonal to the user environment
>
> or perhaps another way to put it:
>
>  - choice is good, platform fragmentation is bad
>
> Platform fragmentation exists when a user must choose one bundle of
> apps vs. another bundle of apps - they are forced to use IE, not
> Netscape, when using Windows. Choice exists when a user can choose
> any app.
>
> Or put in terms of developers: fragmentation exists when a
> developer must choose one bundle of users or another bundle of
> users. Choice exists when a developer can choose either Qt or GTK+
> (or Kylix, or whatever) but still get access to all users.
>
> Fragmentation means that if Linux reaches critical mass on the
> desktop with 6 million users (making up a number), then either
> GNOME or KDE must get to 6 million. Choice means that GNOME and KDE
> combined must get to 6 million.
>
> So, I would suggest that it's useful to have both GNOME and KDE
> when having both offers choice, and harmful to have both when that
> means fragmentation.
>
> Not all or nothing
> ===
>
> This is not an all-or-nothing thing. For example, with fontconfig,
> I have the same list of fonts available in both GTK and Qt apps. 
> That's a big win for users, independent of whether or not you solve
> any other problem. Most interoperability or code-sharing
> opportunities are like that; they are a big win by themselves.
>
> It's clear that things like the MIME system, or D-BUS, or shared
> accessibility setup, would similarly be standalone big wins that
> are worth doing by themselves, whether you can do other stuff or
> not.
>
> How to implement
> ===
>
> As both GTK+ and Qt are cross-platform toolkits, and we have
> promising developments such as D-BUS, there's plenty of reason to
> believe that we can avoid fragmentation while still offering
> choice.
>
> Wrappers of wrappers of wrappers are of course silly (I love
> schemes to do things like run GGI over GDK over Qt over SDL...)
> and the solution to that is a hub-and-spoke design rather than a
> "rat's nest" design, here is a picture:
>
>  http://people.redhat.com/~hp/proposal/ratsnest.png
>  http://people.redhat.com/~hp/proposal/hub.png
>  (this is from http://people.redhat.com/~hp/runtime.html)
>
> Those pictures are about a grandiose and star trek shared runtime
> scheme, but the same thing applies to simpler stuff such as
> fontconfig; we have the one fontconfig layer and map Qt, GTK, etc.,
> APIs to that, we don't have mappings between Qt<->GTK font systems
> directly.
>
> Of course for many simple problems a spec is good enough, you don't
> even need shared implementation.
>
> Finite problem
> ===
>
> At this point I think the list of areas where we need to have
> interoperability and shared implementation/specs is fairly finite
> and fairly well-known. I also think there are clear, feasible
> courses of action for every area: MIME system, DND/clipboard types,
> message bus, themes, help system, etc.
>
> The one area I still find very hard to come up with an answer for
> is the kioslave/gnome-vfs mess. Well, the answer is clear (a robust
> shared implementation), it's just Hard. Unfortunately, this is an
> area where I think interoperability is especially important and not
> sharing implementation has high user impact. Sucks.
>
> But if we can solve everything except vfs, I'm confident we'll
> solve the vfs thing someday also.
>
> Docs and specs good
> ===
>
> Over the long term, we need to keep the interface between
> applications and the runtime environment compatible. This means
> they need to be well-specified and well-understood. Most arguments
> that simply standardizing on an implementation is 'faster' hinge on
> the fact that by picking an implementation you can cut corners and
> not really document/specify/discuss things. Well, we shouldn't cut
> those corners anyhow.
>
> Multiple toolkits will always exist
> ===
>
> One reason we shouldn't cut corners is that WINE, VCL (OpenOffice),
> XUL (Mozilla), and all this type of thing will always exist.  Say
> we succeed on the desktop; people are not always going to do native
> ports of apps, they are going to use some Windows compat framework
> like WINE. The large number of apps using GTK/Qt are not going
> away.  Some people will use plain Qt or plain GTK instead of the
> KDE/GNOME layers. There are huge legacy codebases out there that
> use custom toolkits. And even for apps that mostly use the native
> APIs, there are a thousand reasons why they sometimes need to
> reimplement one bit or another.
>
> Or look at Windows - Microsoft has itself reimplemented large bits
> of the toolkit over time. i.e. future progress means you have to be
> able to keep compatibility while evolving the API/implementation.
>
> Basic point is, even if only one of GNOME/KDE existed, you would
> still have this huge need to be able to interoperate with the
> desktop without sharing all its implementation, if only so you
> could evolve over time and be interoperable *with your own stuff*.
> In fact one could argue this is the whole point of COM on Windows.
>
> UI unification?
> ===
>
> To me whether GNOME and KDE should "merge" hinges on the question
> of UI unification. Say you merge the human interface guidelines and
> general approach/goals. Then at that point you may as well start
> merging implementation (say porting GTK+ to Qt or vice-versa).
>
> However, if you don't, there is still value in ensuring that the
> apps interoperate - same help system, font system, MIME system,
> etc. i.e. even if we offer *choice* of user interface, we should
> avoid *fragmentation* of platform.
>
> I don't have a single problem with choice of user interface; no one
> has ever minded that Linux has 30 window managers and 10 shells and
> so on available. Everyone *likes* being able to choose between
> several different mail clients. People *like* choice.
>
> So I don't think it's clearly right or wrong to merge KDE/GNOME. 
> That just comes down to whether the people involved have the same
> UI ideas and want to work on the same code, or don't. It makes
> total sense to me to have different desktop shell thingies for
> different
> tastes/audiences, if they are truly interestingly different.
>
> However, IMHO, it's essential to ensure that we offer choice, not
> fragmentation.
>
> Havoc

[prev in list] [next in list] [prev in thread] [next in thread]