Hi all,
so, the meeting about qtcomponents is over, some of the points that were
discussed, and i want to raise in the mailing list as well:
(please remember to include both plasma-devel@ and active@)
* regarding the "standard api", our set is more complete that it seemed from a
first glance: harmattan components are ~90% extensions, and we want almost
just the bare stuff i think
* location of the repository: they are at the moment in kde-runtime, master,
what I would like, and everybody agrees, is that would be quite better
separing all "qml related" so the whole declarativeimports folder plus
libkdeclarative in a separate repository just as has been done with
kactivities. it could pose problems for release/packaging? (Sebas, what do you
can say on it with your release team hat on? ;)
* the current components api will have to be validated against the "standard-
ish" api and the missing ones added. good news, there is a validator:
https://qt.gitorious.org/qt-components/qt-
components/trees/master/tests/apicheck
validation *must* be done before 4.8, for the release even if the set is not
complete, i have no objection, is very very useful and can replace ~99% of c++
widgets arelady
* missing components and stealig(ehm, getting inspiration;) from existing
ones. the most complete and better written set seems the ones for Symbian
(always on https://qt.gitorious.org/qt-components) we already have around half
of its ones, about still 10 very important (like Page), others not so much
(like Window, that thing probably should *not* be present when doing widgets,
only apps)
The harmattan ones have hundreds of extension classes, probably not too useful
for us, the code quality seems significantly worse compared to the symbian
ones.
* Jens also wrote some components on his own, hope some could arrive from
there as well
* Question: if we end up copying code from it: they have a BSD license, can
they end up mixed with LGPL licensed files? since there is no linking involved
there *shouldn't* be significant problems, but i need a more informed opinion
;)
* API documentation: this will be badly needed: Giorgos volunteered to give an
hand on it, problem is that doxygen can't understand QML: the first step is to
have good comments anyways, a custom tool could be needed? could it be hooked
to api.kde.org?
* device specific: some components will make sense only on the desktop, some
only on touchscreens, almost all of them will have to modify their behavior
(even just for not having mouseover events for instance)
this means that at some point two separate series will have to be maintained,
doubling the effort. the optimum would be having the device specific set
having only the different ones, falling back to the generic one for the common
ones, but qml doesn't permit this.
* Proposal is: have the desktop version (almost) complete, then install it on
a different place then the other import base path, then via c++ it would be
decided if importing this or the tablet specific one, so the line
import org.kde.plasma.components
won't have to be changed at all, less (to zero) adaption of plasmoids between
platforms.
so those are enough points already to start a good discussion ;)
to me the most urgent is the repository location one, since it influences the
next release.
Cheers,
Marco Martin
unfiltered complete log:
[20:16] ok, so, what is this meeting about, our series of
qtcomponents..
[20:16] a key thing if we want to move most of our plasmoids to qml
[20:17] --> dpalacio has joined this channel (~itsuki@186.87.74.125).
[20:17] how many of you played with qml, or even better a bit of
familiarity with qtcomponents?
[20:17] <-- dpalacio has left this server (Client Quit).
[20:17] <-- d_palacio has left this server (Ping timeout: 248 seconds).
[20:17] i know about qml
[20:17] played with qml, read articles about qtcomponents, and the
QTBUG for qtcomponents
[20:17] * annma is learning QML but did not play with QtComponents yet
[20:17] i had worked a bit on one of the components in summer
[20:17] * terietor same as annma
[20:18] so what's the status of dakerfp
[20:18] ..'s work
[20:18] created some demo apps in qt-documentation of qml
[20:18] I've written custom QML widgets for my music app (on MeeGo
devices) and want to contribute to some bigger project
[20:19] i've worked with plasma components on gsoc
[20:19] worked on meego's a symbian's component's
[20:19] and wrote other custom widgets for apps
[20:20] dakerfp: what branch they're in?
[20:20] viranch: the plasma components?
[20:21] viranch: they are now in master
[20:21] (and where put them is another point of the meeting agenda)
[20:21] hmm
[20:22] --> mokush has joined this channel
(~quas...@cl-86-125-150-199.cablelink.mures.rdsnet.ro).
[20:22] so, very short introduction, components are mostly drop in
replacement for the old concept of widgets, like buttons, sliders, textareas
and whatnot
[20:23] they're w