kwallet and QCA

[Robert Knight]

> For historic reasons KIO and 
> KWallet landed in this "KDE desktop environment"

Those 'historic reasons' presumably include the licensing issue that Qt is GPL - which,
as I understand it, would not be acceptable for gnome.  If Nokia were prepared to re-license the non-GUI
components of Qt (eg. QtCore, QtNetwork) more permissively that might change.  Of course it would not make
business sense for them to do that for the whole suite.

One alternative is writing the code with glib (using their type system) and then writing a C++ wrapper
which provides a Qt/KDE style interface to give a consistent feel for KDE programmers.  Unfortunately 
that means:

1)  Writing more code in the first place because glib/C is less efficient that Qt in terms of features/lines-of-code
2)  Writing lots of glue code between the two layers, which will have some performance hit.

Regards,
Robert.

On Thu, 2008-06-19 at 13:58 +0200, nf2 wrote:
> Jakob Petsovits wrote:
> > On Saturday, 14. June 2008, nf2 wrote:
> >   
> >> Michael Pyne wrote:
> >>     
> >>> Wait wait wait. You will never understand why developers do not want
> >>> to replace code which is working and well understood with code which
> >>> is untested and has a different interface?
> >>>       
> >> No, i meant this programming language "don't use/like" statement.
> >>     
> >
> > Doing Free Software development is all about loving to write that code.
> > Now if you have to use constructs that are different to others used in that 
> > same piece of code, with different concepts and object hierarchies, then that 
> > increases the disgust about writing such code.
> >
> > For KDE (and Qt) as a platform, pleasing the developers is an important goal, 
> > one that might override other important goals even if those others have 
> > direct advantages in terms of whatever user-visible stuff. Maybe some of that 
> > gap can be closed with bindings like was nicely done for D-Bus, but the 
> > developers need to stay happy with such a solution.
> >
> > They are KDE's most important capital, and if they love writing code for 
> > KDE/Qt then our platform and desktop environment will keep improving.
> > That's why seemingly irrational reasonings like the language one make sense 
> > even though they can't be measured in "hard facts".
> >
> > If you want to get KDE to adopt stuff then you need to find a way to make
> > KDE developers love your stuff. Not lots of end users, not fd.o, not GNOME.
> > Having those as additional backing is nice, but won't be enough.
> >   
> 
> Of course! But i guess those developers want their software to be 
> successful in the "consumer market" also. And for that a lot of 
> compromises need to be made and some paradigms need to be dropped. One 
> is the "desktop environment" paradigm. For historic reasons KIO and 
> KWallet landed in this "KDE desktop environment", only accessible for 
> KDE apps. But as a matter of fact KDE can't be successful without GTK+ 
> and 3rd party applications (and the other way round). People - in the 
> first place - and more than they need beautiful Desktops - need apps 
> apps and more apps - and a single coherent platform to run those apps.
> 
> I think "desktop" (Plasma,...) and even "GUI-toolkit" competition is 
> good, but "desktop environment" competition has been destructive for the 
> goal of competing with commercial operating systems. That's why things 
> like KIO and KWallet (if they are more than language bindings or high 
> level APIs) have to go. Sorry. Also - i believe - the "just written 
> standards" approach of fd.o is too slow. But it was good to get started. 
> The shared services approach is better, and the next logical step is 
> also sharing more in-process libraries and APIs. And for both it's 
> necessary to pick a programming language & lib stack to collaborate, 
> which only in border cases will be the beloved Qt/C++.
> 
> That's how i think, but maybe it's because i'm rating certain goals too 
> high.
> 
> Norbert
> 
>