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

List:       kde-maemo
Subject:    [Kde-maemo] Fwd:  KDE Platform Mobile
From:       faure () kde ! org (David Faure)
Date:       2010-03-09 9:43:41
Message-ID: 201003091043.42306.faure () kde ! org
[Download RAW message or body]

On Tuesday 09 March 2010, you wrote:
> * We propose adding a CMake variable to choose the platform profile. 
> KDE_PLATFORM_PROFILE would be one of Desktop, Tablet, Mobile.
> [...]
> === BIC concerns ===
> In particular, it would be possible to remove deprecated classes to reduce 
> library size. It might also be worth it to let OEM selectively activate
> that  for their platform even in the Tablet profile.

Doesn't that possibility make KDE_PLATFORM_PROFILE not fine-grained enough?
I mean, if you want a 'user' to be able to say "let's enable removal-of-
deprecated-classes while compiling in Tablet profile", while this is normally 
only done in Mobile profile, how do you do that?
It sounds like this needs an approach like Qt has, where every such 'feature'
is associated to a #define and you can hack a .h file that defines what to 
enable/disable. Then KDE_PLATFORM_PROFILE variable becomes simply a selection 
among three pre-defined .h files.

My point is that for long-term maintainance and evolutions, it would be much
better to see the code (C++ or cmake) say

#ifdef KDE_ENABLE_KDEINIT
 // use kdeinit
#endif
(and defining KDE_ENABLE_KDEINIT in kde-config-desktop.h and kde-config-tablet.h)

than seeing the code say

#if (KDE_PLATFORM_PROFILE == Desktop) || (KDE_PLATFORM_PROFILE == Tablet)
  // use kdeinit
#endif
which breaks as soon as someone decides to introduce a 4th builtin profile.

This is probably what you had in mind already, otherwise I'm just refining the 
idea :-)

And the above is even a bad example probably, not precise enough, should be
#ifdef KDE_USE_KDEINIT_TO_START_APPS
;)

> * On the Mobile profile, in process ioslaves are desirable and it may even
> be  feasible to replace KIO internals by system (Qt) calls. It needs to be
> evaluated, and KIO hacked that way.

I know you want my feedback on this, but I don't have much yet;
it needs reading, experimentation, and thinking.

All I can say is that the "data:" implementation (kio/dataprotocol.cpp and 
kio/dataslave.cpp) might serve as an example of how to implement an in-process 
ioslave (which could then call Qt), even though it might be a bit hackish in 
places. But at least it implements the expected interfaces so the rest of KIO
(jobs, scheduler, etc.) are not affected. Of course if we find cleaner solutions 
along the way that don't require too many internal changes, we can always 
define a cleaner way of having in-process ioslaves (cleaner things tend to 
become "worth it" when there's more than one consumer). Since this runs the 
slave code in-process and in the main thread, existing kioslaves won't be 
usable of course (no blocking operations), it will only be for an in-process 
"slave" implementation that uses QNetworkAccess to implement file:/// and 
ftp:// and http://. Well, for efficiency reasons it probably wants to implement 
file:/// directly; which means somehow sharing code with the real kio_file.

Note: in some cases, kio jobs already implement local operations directly, 
without calling kio_file, for performance reasons. I guess this work will also 
extend that, which will benefit all profiles (although I don't see a way to do 
it all without a slave, it might get a bit too messy in some cases).

OK, so much for "nothing to say" :)

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

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