On Friday 03 July 2009 05:18:13 nf2 wrote:
> On Thu, Jul 2, 2009 at 11:04 PM, Aaron J. Seigo<aseigo@kde.org> wrote:
> > if you want a great example, just consider that GNOME People was proposed
> > as a blocker for Akonadi on fd.o despite People being a complete toy in
> > comparison. why? yep, it's written in glib/vala and so it "trumps" the
> > Qt/C++ option for some people. i really tire of dealing with that kind of
> > situation as it does nothing but work against the goal of a great F/OSS
> > desktop patform. perhaps you can understand why i find your suggestion of
> > standardizing on c and glib to be discouraging and dangerous.
>
> Not sure. At least it *is* a standard. 

Depends on what you consider a standard ;) A GNOME standard maybe? We have 
another standard: QObject

> Every software framework can be
> split into components which can be reused elsewhere. If you want that
> kind of reusability, you need to *decide* on a standard technology to
> define library interfaces. It hurts, contradicts the freedom of the
> developers, but i think it's important. 

When I want to use some lib, I usually include a header file or load a 
module(depending on language), open API docs and that's it. Do I care how 
these bindings work? (unless I'm a GObject zealot? ;) As long as it works, it 
works, no?

A standard bindings approach may not hurt all that much if it's good enough ;) 
But in this case the standard would be something everyone WANTS to use, not 
something everyone is MANDATED to use. However you still haven't provided a 
single good reason why we absolutely must pick GObject.

Actually it would be much better if compiler/VM guys figured this out instead 
of coders having to mess with macros, preprocessors and stuff to get their 
bindings right. Now if gnomers managed to achieve this, it would be quite an 
accomplishment.

Instead they kept bashing the lack off c++ ABI standard and did what? 
Implemented compiler functionality on a macro/sweatshop labor level? And now 
everyone must use this?

> Not for everything, not for
> high level services like Akonadi, but for the really basic platform
> features.
>
> Interestingly - what i'm suggesting - is happening anyway. But not
> through collaboration but through division of labor. Newer platform
> technologies are mainly created by Gnome developers in GObject and C,
> and KDE is using them (wrinkling their nose ;-).

(Lets not forget that those gnome developers are a couple of companies who 
simply wanted a proprietary-friendly license and are understandably invested 
in GObject heavily by now. ;)

First of all let's decide what platform we are talking about? KDE platform or 
Linux-based OS platform? eg KDE uses Phonon because it might just happen that 
alsa&co is not available. KDE uses Solid to interface with bluetooth because 
bluez is linux-only.

For linux-based OS we already have a default platform interface: DCOP^H^H^H^H 
DBUS.

For KDE platform we have a default interface too: #include ""

> Why not follow this direction more actively by re-evaluating technologies
> that already exist in the KDE stack as well? In the long run it might be an
> advantage beeing able to focus on higher layers, where competitive
> innovation really adds value, rather than putting off people with
> unnessecary chaos at the basis.

Right. But you have to consider costs, advantages and long-term perspective.  
Migration means breaking code and compatibility. The foundation must be solid.

Imagine KDE dropping some $KDECODE and adopting $GNOMECODE and then 2 months 
down the road a need for some improvements becomes apparent and gnome refuses 
to because it doesn't fit their plans/ideology/whatever? So we either must port 
back to $KDECODE or find people willing to mess with maintaining GObjects in 
$GNOMECODE fork.

Sanity^H^H^H^H Shared vision is a very important long-term aspect of sharing 
code. At least for code that's used in lots of places.

So please be specific. You don't need to convince anyone here that reusing GOOD 
code is good. But a specific list of libs you want to reuse and a detailed 
cost/benefit analysis(wiki page maybe?) would go a long way to further your 
point.

--Evgeny