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

List:       kde-core-devel
Subject:    Re: dependencies on KJS/KHTML in kdelibs and kdebase-runtime
From:       koos vriezen <koos.vriezen () gmail ! com>
Date:       2010-09-27 20:07:44
Message-ID: AANLkTi=7u0xOmiejUhnm==1cV3RZzniVSuhM7x9h4KYH () mail ! gmail ! com
[Download RAW message or body]

2010/9/27 Aaron J. Seigo <aseigo@kde.org>:
> On Saturday, September 25, 2010, koos vriezen wrote:
>> Afaiks, its inevitable for KDE apps going mobile, to fork or port to
>> Qt based libraries completely. Not to mention that kdelibs is more or
>> less targeted as being a complete DE controller.
>
> some of our apps already work just fine, others have been designed with a nice
> UI separation which makes retargetting them easy (as opposed to a fork or
> full-on port) and many of the great things in kdelibs are not "desktop" or
> "mobile" (thinks like configuration storage), others are built with the device
> spectrum in mind already (e.g. libplasma).

Configuration storage may mean that the native backup software misses
these settings. At least a to native backend is needed. Just few lines
of code to wrap KDE's config API around gconf in my case.
Abstracting is nice for porting,. Bringing a complete framework does
add to binary size, memory pressure etc.

Isn't libplasma about UI too, or should the UI part be replaced by eg
meegotouch? Things that come into my mind are differences of
interaction areas sizes, input events (hover and RMB vs tap-and-hold
and touch events) and of course power saving.

> even then, it is innevitable that there will be modifications to kdelibs to
> make it hit certain targets. the hope is that we can minimize the delta by
> making kdelibs itself as close to what is needed as possible.
>
> kdepim (aside from their wild adventurs on wince, which is understandable
> given the constraints there) have been very good about upstreaming changes as
> they can. i'd like to encourage that behaviour and ensure it can continue.
> every place that we can reasonably offer a solution that works out of the box,
> the more upstream participation we will receive in turn.

Yes, and that was why I responded.
IMO better to port a few applications first and then see what can be
shared with kdelibs than trying to make the libs mobile ready first.

> we've even been adjusting the build system in kdelibs to have different build
> profiles that include/exclude different parts of kdelibs to make these efforts
> easier and hopefully more unified downstream.
>
> now we just need to work on the flawed mindset of old time mobile developers
> that "anything developed on a desktop computer certainly can't be worth
> anything on mobile" despite reality showing otherwise. ;)

Hey, just wanted to secure my old time mobile dev status by tempering
the going mobile cheering :)

Obviously, with the exception of sensor based applications, all apps
have a desktop counter part. I'm not blind, ported my app too. Looks
quite different already.
Given that touch is fairly new compared to the desktop, no doubt
things diverge further.
Hope to see many ports from KDE, esp. games and education. Interesting
to follow how these will evolve.


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