dependencies on KJS/KHTML in kdelibs and kdebase-runtime

[Aaron J. Seigo]

On Monday, September 27, 2010, koos vriezen wrote:
> Isn't libplasma about UI too,

not really, no. we provide some UI bits in there specific to making 
QGrahicsView usable when wanting things like push buttons, esp w/regards to 
managed scripting put on top of that. we had to do this because Qt apparently 
doesn't know what it wants/wanted to do with QGraphicsView. i'm hoping QML + 
the new scene graph + QtComponents become the last stop in this crazy train 
ride. if it is, then we can pull those pieces out of libplasma and bump the 
.so # and everyone will be the happier for it. unfortunately, QML is 
unecessarily difficult to work with due to current implementation decisions 
that i feel can be best described as "braindamaged" and the scene graph and 
QtComponents are both still in 'research' status (though making progress 
fwiu). until then, we retain some UI related baggage in libplasma.

but libplasma is much more about a "widget/gadget/app-centric" component model 
(packaging, sharing, installing, finding, selecting, instantiating, managing), 
data and service access, easy non-trivial use of svg data and bits of app 
interaction concepts such as extenders.

all designed to be usable _as-is_ on a phone, on a tablet, on a netbook, on a 
laptop, on a desktop, on a workstation, on a t.v.

it's not complex stuff, but the concepts it embodies make most other similar 
efforts i've looked at (be they "desktop widgets" or "phone apps") look fairly 
naive.

> or should the UI part be replaced by eg
> meegotouch?

by QML and possibly QtComponents, you mean? well, we're working on that.

> 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.

we've been demo'ing plasma shells driven by multitouch via Qt's gesture 
framework for a while. we've been working on small screened devices with both 
Plasma Netbook (/ Tablet) and Plasma Mobile.

i wish in this case i could say, "we should be talking about these things 
more..." but we've been blogging, screencasting, putting stories on the dot 
for what, over a year now about these exactly issues.

where do you look for information about these things? because obviously we're 
not hitting that.

> > 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.

i agree.

in fact, i agree so much that that's what we've been doing.

kontact mobile, plasma mobile to name 2 efforts. yes, the same groups that 
have been working with and bleeding all over QML. the same people who helped 
review the utility of Kinetic and pushed it into real world use cases. the 
same people who have been working on KDE on targets like moblin, maemo and now 
meego. (and wince, in the case of kdepim)
 
> Obviously, with the exception of sensor based applications, all apps
> have a desktop counter part. I'm not blind, ported my app too. Looks

the goal should be that a reasonably well written application that is 
topically relevant to a mobile setting wouldn't need "porting". a new UI 
draped on top, perhaps, and that should be _easy_ to do. 

yes, this is different to how many desktop apps are written today. and some of 
our apps simply aren't topically relevant in a mobile setting. but many would 
be if we think about tablets, fewer if we think about phones.

but for the libraries? they should be repurposable without pain. and this is 
what this thread is about :)

> Given that touch is fairly new compared to the desktop, no doubt
> things diverge further.

i actually think they'll converge rather than diverge, into a nice long device 
spectrum. that's how to aggregate developer effort and how to get users what 
they _really_ want -> the tools they use, travelling about with them.

> Hope to see many ports from KDE, esp. games and education. Interesting
> to follow how these will evolve.

the games already work rather well. the biggest remaining issue with the games 
are remaining menu and dialog based interactions, particularly configuration. 
even that is better in the 4.x releases, though.

then there is gluon that is trying to make strides in this area.

it's actually pretty interesting how much _is_ happening. right now. finding a 
way to bring all that together so that people who are "old time mobile devs" 
are aware of, and maybe even working with, these efforts. reaching such people 
is hard, though, perhaps in part because mobile development is historically so 
walled off and isolated.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100927/5f94e93f/attachment.sig>