dependencies on KJS/KHTML in kdelibs and kdebase-runtime
Aaron J. Seigo
aseigo at kde.org
Tue Sep 28 00:04:04 BST 2010
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
> or should the UI part be replaced by eg
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.
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...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel