Plasma QtComponents IRC meeting: summary

[Marco Martin]

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] <notmart> ok, so, what is this meeting about, our series of 
qtcomponents..
[20:16] <notmart> a key thing if we want to move most of our plasmoids to qml
[20:17] --> dpalacio has joined this channel (~itsuki at 186.87.74.125).
[20:17] <notmart> 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] <chpadhi> i know about qml 
[20:17] <Shaan7> 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] <viranch> i had worked a bit on one of the components in summer
[20:17] * terietor same as annma
[20:18] <viranch> so what's the status of dakerfp
[20:18] <viranch> ..'s work
[20:18] <chpadhi> created some demo apps in qt-documentation of qml 
[20:18] <jnwi> I've written custom QML widgets for my music app (on MeeGo 
devices) and want to contribute to some bigger project
[20:19] <dakerfp> i've worked with plasma components on gsoc
[20:19] <dakerfp> worked on meego's a symbian's component's
[20:19] <dakerfp> and wrote other custom widgets for apps
[20:20] <viranch> dakerfp: what branch they're in?
[20:20] <dakerfp> viranch: the plasma components?
[20:21] <notmart> viranch: they are now in master
[20:21] <notmart> (and where put them is another point of the meeting agenda)
[20:21] <viranch> hmm
[20:22] --> mokush has joined this channel 
(~quassel at cl-86-125-150-199.cablelink.mures.rdsnet.ro).
[20:22] <notmart> so, very short introduction, components are mostly drop in 
replacement for the old concept of widgets, like buttons, sliders, textareas 
and whatnot
[20:23] <notmart> they're written in qml and have a pretty familiar api, a 
button will have a text property, a clicked signal and so on
[20:23] <notmart> some of the components are a bit more complicate beasts, 
(like window) and now if all of them will be needed is another story
[20:23] <notmart> dakerfp: among all, i think you're the one that knows most 
about components, and also what the hell is happening nowdays with them
[20:23] <notmart> so...
[20:24] <notmart> dakerfp: can you give a short overview of what are the 
standard ones, what is considedrd standard and what not?
[20:25] <notmart> the "state of the art" (tm) is in the qtcomponents gitorious 
repo i guess? 
[20:25] <notmart> meego + symbian folders in it?
[20:25] <dakerfp> today the closer we have from a standard we have is an API 
spec
[20:25] <dakerfp> defined here: 
https://bugreports.qt.nokia.com//browse/QTCOMPONENTS-200
[20:26] * Shaan7 has a question
[20:26] <notmart> what strikes me of this list is that is really, really tiny 
compared to the meego components or the desktop ones
[20:26] <notmart> so everything not in here is something randomly added?
[20:27] *** einar77_work is now known as einar77.
[20:27] <notmart> (hmm, symbian seems to have a bit less fancy stuff, maybe is 
a better basis for start)
[20:28] <dakerfp> notmart: yes, is what they call "platform specific" 
properties, methods and signals
[20:28] <viranch> so most of them are done? atleast in beta stage..
[20:28] <dakerfp> there is also a desktop components set
[20:28] <notmart> well, besides having some platform specific methods, they 
have a hundred+ classes ;)
[20:29] <dakerfp> true
[20:30] <viranch> ok, so what's still missing with our components?
[20:30] <-- task_struct has left this server (Remote host closed the 
connection).
[20:30] <dakerfp> we haven't all the components defined in the common API
[20:31] --> mxttie has joined this channel 
(~mattie at 94-225-170-170.access.telenet.be).
[20:31] <notmart> one thing that could be done perhaps is to see what are the 
ones common between the meego and symbian ones (that are just 41)
[20:31] <notmart> so those would be the more likely to be really common
[20:32] --> Kame2 has joined this channel (~manuel at p4FD54012.dip.t-
dialin.net).
[20:32] <-- zephyr has left this server (Ping timeout: 252 seconds).
[20:33] <notmart> now, there are things that we'll need that aren't there 
because destop-ish, like scrollbar, for those we could try to stick to the 
desktop components research project..
[20:33] --> jhk has joined this channel (~jiggy at 14.139.122.114).
[20:33] <notmart> dakerfp: do you know anything if that project has chances to 
become official and not die from one day to the other?
[20:34] * notmart also notes that most of the files there don't have a license 
header at all, and that is baaad and makes not really possible to just copy it 
;)
[20:34] --> task_struct has joined this channel (~Kernel at 95.111.8.217).
[20:34] <dakerfp> notmart: it's very probable that the desktop components 
become part of qt5
[20:35] <terietor> notmart: this is just a copy&paste.correct?
[20:35] <notmart> terietor: of what? ;)
[20:35] <terietor> of the licenses
[20:35] <notmart> dakerfp: that's a good news, since they are probably the 
most interesting ones ;)
[20:36] <dakerfp> notmart: would you like me to call jens to join the meeting?
[20:36] <notmart> terietor: i'm referring to the qt's research project of 
desktop qtcomponents, that don't really have a license
[20:36] <viranch> is this the one being mentioned http://qt.gitorious.org/qt-
components/desktop ?
[20:36] <dakerfp> (the desktop components guy)
[20:36] <notmart> dakerfp: if he can, could be nice ;)
[20:36] <notmart> viranch: yup, exactly that one ;)
[20:37] <terietor> i can send some patches at Qt for the licenses.
[20:37] --> sheytan has joined this channel 
(~sheytan at apr7.neoplus.adsl.tpnet.pl).
[20:37] <notmart> terietor: i thnk atm is mostly a thing to be asked to him, 
since is still his "research" project
[20:38] <dakerfp> luisgabriel: ^
[20:38] <notmart> still to come, quickly going trough the "official" 
components list and see what is still missing
[20:39] <terietor> notmart: ok,someone has to come in contact with him.Who 
will do it?And how?via a just a private mail or via a private mail and a cc to 
plasma-devel??
[20:39] <notmart> i really feel that for some of them we will need to have 
completely different implementations between the desktop widgets and plasma 
active..
[20:39] <annma> will those qt-components be included in Qt 5?
[20:40] --> adwait_sharma has joined this channel (~adwait_sh at 14.96.176.23).
[20:40] <notmart> terietor: sure, that just if we need copies of some of them, 
i would like to not reinvent too much tough
[20:40] <luisgabriel> dakerfp: here i am
[20:40] --> esben has joined this channel (~esben at sneppe.mosehansen.dk).
[20:40] <notmart> would be also interesting to know wether meltemi will use 
them (but even if someone knows couldn't tell eheh), i would be surprised if 
they don't reinvent the wheel tough
[20:41] <terietor> notmart: with the term copies.Do you mean copy&paste?
[20:41] <terietor> in our repos?
[20:41] <notmart> terietor: basically yeah
[20:41] <adwait_sharma> dakerfp:Thanks for telling me about this meet :)
[20:41] --> gdebure has joined this channel 
(~guillaume at 82.143.73.86.rev.sfr.net).
[20:42] <terietor> notmart: why we will have to do something like that and not 
take them from the original repo?
[20:42] <notmart> well, for sure we can't depend from something unreleased 
that can still change too much for a kde release
[20:43] <adwait_sharma> I'm a newbie in Plasma, can someone suggest me any 
project to start with ?
[20:43] <terietor> notmart: i see
[20:44] <dakerfp> adwait_sharma: hi
[20:44] <notmart> adwait_sharma: those we are discussing now, could be a good 
one ;)
[20:44] <adwait_sharma> dakerfp:Hello :)
[20:44] <adwait_sharma> notmart:I'm sorry but i just joined can you give me a 
short description ?
[20:45] <notmart> adwait_sharma: qtcomponents, basically a series of qml files 
that will implement standard widgets such as buttons, scrollbars etc
[20:45] <adwait_sharma> notmart:Great !
[20:45] <terietor> just in case that the desktop components doesn't change so 
much,we will have to "git pull && git merge" very often.Do you agree or am i 
missing something?
[20:46] <dakerfp> terietor: I think it's the best approach
[20:46] <notmart> terietor: well, i don't really want to use them until they 
are ready
[20:46] <notmart> right now what i would like to get done is a series just for 
plasma
[20:46] <terietor> i see
[20:47] <notmart> for desktop plasmoids and/or active applications, that 
already makes the two things quite different enough that could force to do the 
work twice ;)
[20:47] <jnwi> I could use a short description of something else.  Are you 
discussing implementing the exact same API so programs would run unmodified 
under KDE or are you discussing creating an extended API for KDE that's 
nevertheless compatible with the other API?
[20:47] <jnwi> I'm really not familiar with what's going on with KDE
[20:47] <-- WAndre has left this server.
[20:47] <adwait_sharma> notmart:Is it about designing basic components like 
Scrollbar, buttons using Qt ?
[20:48] <dakerfp> adwait_sharma: exactly
[20:48] <adwait_sharma> dakerfp:for which program?
[20:48] <adwait_sharma> or can i give a generalised code?
[20:48] <dakerfp> adwait_sharma: it's an API
[20:49] <adwait_sharma> dakerfp:Means, i can give the generalised API ?
[20:49] <viranch> notmart: so we're dependent on the research guys for now?
[20:49] <notmart> hmm can we continue after and go on with decision points ;)
[20:50] <notmart> viranch: those here: 
https://bugreports.qt.nokia.com/browse/QTCOMPONENTS-200  should be quite 
definitive
[20:50] <adwait_sharma> notmart:Is it for me ? 
[20:51] --> larsivi has joined this channel (~quassel at 188.113.74.106).
[20:51] <notmart> jnwi: we would like to follow that api as much as possible, 
but yet doing widgets that can be used in plasmoids with the plasma style 
without looking alien
[20:52] <viranch> notmart: i mean, are the components stable enough to be used 
widely across plasma? or are we dependent on the research regarding that?
[20:52] <notmart> and for plasma active, would instead be more like a plasma 
themed widget set for whole applications
[20:52] *** seif is now known as mhr2.
[20:52] <notmart> viranch: if we stick to that api, i (hope) when qt5 will 
come we won't be bitten too much ;)
[20:53] <notmart> jnwi: btw you wrote some components for your app right?
[20:53] <jnwi> notmart: ok, thanks
[20:53] <jnwi> yes
[20:53] <notmart> can you introduce briefly what you have done? ;)
[20:54] <-- kde_pepo has left this server (Quit: Konversation terminated!).
[20:54] <jnwi> Yeah.  First of all, I have a central theming object that 
stores certain values.
[20:54] <jnwi> a central concept is touchSize, which is the basic distance 
unit
[20:54] <jnwi> and then my widgets like buttons refer to that
[20:54] <jnwi> so the height of a button would be one touchSize
[20:55] <notmart> so that is to address different dpi, right?
[20:55] <jnwi> I use that instead of mm or pixels because the resolution can 
change the pixel #, and the user can choose how big the button should b
[20:55] <jnwi> e
[20:55] <jnwi> so neither mm or pixels would be correct
[20:56] <jnwi> anywa, that's just to explain where I started from
[20:56] <jnwi> then I created buttons, sliders, a tab view, a list view with 
multiple selection
[20:56] <adwait_sharma> jnwi:Can you suggest me from where should i start?
[20:56] <jnwi> everything is drawn using gradients and rectangles
[20:57] <jnwi> adwait_sharma: start what?
[20:57] <notmart> adwait_sharma: i think we should make at the end of the 
meeting a series of tasks, some even quite simple, you could start with those 
;)
[20:57] <jnwi> I'll dig up a video on how it works, hang on
[20:58] <adwait_sharma> jnwi:notmart, gave me the answer, thanks :)
[20:58] --> kdepepo has joined this channel (~pepo at p5B3B94D4.dip.t-
dialin.net).
[20:58] <adwait_sharma> notmart:Ok, sorry for interuding in the topic
[20:58] <jnwi> 
http://www.youtube.com/watch?feature=player_detailpage&v=De1a1u-MqIk#t=132s
[20:59] * notmart clicks
[21:00] <jnwi> for the more interesting stuff, 
http://www.youtube.com/watch?feature=player_detailpage&v=De1a1u-MqIk#t=269s
[21:00] --> tittiatcoke has joined this channel (~tittiatco at 80.108.147.43).
[21:00] <-- tittiatcoke has left this server (Changing host).
[21:00] --> tittiatcoke has joined this channel 
(~tittiatco at opensuse/member/tittiatcoke).
[21:01] <jnwi> all of that stuff is running on plain qml by the way
[21:01] --> viranch_ has joined this channel (~foo at 115.241.71.100).
[21:01] <jnwi> only the tab view's model is C++
[21:02] <jnwi> and of course all the music playing stuff is C++
[21:02] <jnwi> I meant the widgets are plain QML
[21:03] <jnwi> there's no point watching the whole video
[21:03] <-- wyuka has left this server (Quit: Konversation terminated!).
[21:03] <-- mokush has left this server (Remote host closed the connection).
[21:03] <jnwi> but this is basically what I've done
[21:04] <notmart> yeah, maybe something could be reused, if you are willing to 
work on it.
[21:04] <jnwi> oh and apart from the buttons etc. I also implemented that 
popup that goes away by clicking outside it
[21:04] <jnwi> Yeah, I am, I'd much rather contribute to something bigger
[21:04] <jnwi> What are your plans for KDE on mobile phones anyway?
[21:04] <jnwi> what kind of interface?
[21:04] <notmart> now, we have a bit of infrastructure already there, like the 
theming is done in a different way
[21:05] <notmart> but foor instance that tabbar thing seems interesting
[21:05] <jnwi> yeah, my theming is too simple anyway.  It only supports 
gradients...
[21:05] <-- Shaan7 has left this server (Read error: Connection reset by 
peer).
[21:05] <-- viranch has left this server (Ping timeout: 276 seconds).
[21:05] --> Shaan7 has joined this channel (~shantanu at kde/developer/shantanu).
[21:06] --> Mogger has joined this channel (~Mogger at kde/forum/mogger).
[21:07] <jnwi> Imho many different kinds of apps would benefit from a tabbed 
interface with multiple selection-enabled list views inside them
[21:07] <jnwi> including email clients, etc
[21:07] <jnwi> so if I could contribute to those two widgets and hope that KDE 
apps for phones will use them, I'd be very happy
[21:07] <notmart> we basically use svgs broken in 9 pieces to make rectangle-
ish stuff with borders that don't go bad, kinda like borderimage but a tad 
smarter wit on disk caching and stuff
[21:08] <jnwi> ok
[21:08] --> viranch has joined this channel (~viranch at 106.76.104.190).
[21:08] <notmart> yeah, if they are things a bit more "high level" than the 
ones defined in the api could end up in another modulke...
[21:08] <-- viranch_ has left this server (Quit: Konversation terminated!).
[21:08] <notmart> i was aleready thinging to do some hight level component 
sets with more complicate stuff almost pieces of apps just to take and use
[21:09] <terietor> notmart: are you thinking of changing the current plasma 
svg system?
[21:09] <notmart> terietor: nah, i still think is the best thing since sliced 
bread ;)
[21:09] <jnwi> Is there someone in charge of creating UI guidelines for KDE on 
phones?
[21:09] <terietor> ok :)
[21:10] <notmart> i would like to change quite a bit how svg pieces are 
defined and composed, but that would break all themes, so i prefer stay 
retrocompatible
[21:10] <notmart> jnwi: on phones we still didn't do much serious work ui-wise
[21:11] <notmart> on active, that is still just for tablets right now(will 
hopefully expand) we have an ui designer, yes
[21:11] <jnwi> ok, but who would be the person to talk to in order to start 
defining that kind of thing?
[21:11] <dakerfp> notmart: in fact, the components/custom folder in the 
desktop-compenents are one attempt to that
[21:11] <notmart> jnwi: best thing, is opening a thread on active at kde.org
[21:12] *** mhr2 is now known as mhr4.
[21:12] <jnwi> ok, I can do that if it's appropriate... I haven't got a clue 
about what's going on with anything inside KDE, though
[21:13] <notmart> jnwi: best thing is following irc channels and mailing lists 
to see things more from the inside i think
[21:13] <jnwi> yeah, that's why I was hoping there was a specific person I 
could talk to ;)
[21:14] <jnwi> anyway, if we can get some basic guidelines together, it would 
be fun to start creating the necessary widgets so others can start writing 
apps
[21:14] --> giucam has joined this channel (~giulio at adsl-
ull-17-254.49-151.net24.it).
[21:14] <jnwi> trying to create tab views etc before that might end up as a 
waste of time
[21:14] <notmart> on ui questions, i guess more me,fania,aaron and sebas, at 
least on things more on plasma active
[21:14] <notmart> for the rest of kde, people may vary ;)
[21:15] <jnwi> ok, maybe we could have an irc meeting about those kinds of 
ideas with those people later?
[21:15] <notmart> well, first thing, i would like completing this api: 
https://bugreports.qt.nokia.com/browse/QTCOMPONENTS-200
[21:15] <notmart> jnwi: yep, sure ;)
[21:16] <viranch> And moving the code to..?
[21:16] <notmart> this is another issue that i would like to discuss ;) (but i 
think it will need an out of sync thread in the ml
[21:17] <notmart> i would like to move everything is in declarativeimports in 
an own repository
[21:17] <notmart> like kactivitymanager was moved out a while ago
[21:17] <-- viranch has left this server (Remote host closed the connection).
[21:17] --> viranch has joined this channel (~viranch at 106.76.104.190).
[21:18] <dakerfp> notmart: I also agree
[21:18] <terietor> i think that everyone agrees in the new repo think
[21:18] <notmart> i don't know how much this could mess up with kde releases 
tough since is not seen as so nice to split up repositories too much before 
the frameworks5 release
[21:18] <terietor> notmart: i would like to mention something here.May I>
[21:19] <notmart> go
[21:19] <terietor> in the plasma qml we are missing a doc tool
[21:20] <notmart> eheh, good point ;)
[21:20] <terietor> until now with c++ we where using the doxygen
[21:20] <terietor> but doxygen doesn't support qml
[21:20] <terietor> moreover
[21:20] <notmart> don't think doxygen can be made work with qml, it just 
explodes i guess?
[21:20] <notmart> yeah
[21:20] <terietor> doxygen's comments has to be above the "method/thing"
[21:21] <terietor> in qml this is not practical
[21:21] <terietor> i was looking at the qdoc
[21:21] <terietor> and it is very convenient
[21:21] * terietor please wait for a link
[21:21] <notmart> terietor: seems you found yourself a task :p
[21:22] <terietor> link http://meego.gitorious.org/meego-ux/meego-ux-
components/blobs/master/src/components/common/AppPage.qml
[21:22] <terietor> i would love to do the work
[21:22] <terietor> :)
[21:23] <terietor> but this means that the KDE infrastructure has to be 
modified
[21:23] <notmart> excellent ;)
[21:23] <terietor> for instanse the api.kde.org
[21:23] <notmart> yeah, that will have to be explored as well
[21:24] <terietor> i don't know if the web team and the sysadmin team is 
willing to do some further work on that
[21:24] <notmart> i guess, properly existing commments is a starting point 
tough ;)
[21:25] <terietor> yeap
[21:26] <notmart> also the c++ part would require just doxygen as the rest
[21:26] <terietor> the point is to come in contact with the other KDE 
people,and to learn for sure if doxygen will support qml or not
[21:26] <notmart> since some of them especially the plasmacore stuff is mostly 
c++
[21:27] <terietor> yeap,c++ will stay in doxygen
[21:27] <terietor> there is no doubt in that
[21:27] <notmart> worst case scenario, putting the comments in a format easy 
enough to parse to b e hable to have a custom perl hell ;) but would like 
avoiding that
[21:27] <terietor> so should i send a mail at the kde-devel,plasma-devel,kde-
core?
[21:27] <notmart> yeah, good idea
[21:27] <terietor> ok
[21:28] <terietor> in the worst senario we won't have a web api
[21:28] <notmart> yeah
[21:28] <terietor> one more
[21:29] <terietor> a c++ plasmoid has a settings option
[21:29] <terietor> in which the developer can add some stuff
[21:29] <notmart> the settings dialogs you mean?
[21:29] <terietor> yes
[21:29] <viranch> Bump!
[21:29] <terietor> in the current qml api there is no such thing
[21:30] <terietor> and this is an issue if we want to QMLify the c++ desktop 
plasmoids
[21:30] <notmart> yep, there is just the standard ui file with kconfigxt that 
is really limited
[21:30] <viranch> notmart: aseigo gave a patch for that, right?
[21:30] <notmart> qmlify everything probably is not the #1 priority, but for 
writing new plasmoids sure
[21:31] <notmart> viranch: there was a patch to include global kcms in the 
settings page yeah
[21:31] <notmart> and i would like to see that committed
[21:32] <notmart> (also, i would sooo like to see battery and devicenotifier 
merged for 4.8, i should gave another try this weekend)
[21:32] * viranch will find and try to do it soon enough
[21:32] <viranch> The KCM I mean
[21:32] * terietor doesn't know about this patch
[21:32] <notmart> better *own* config pages are completely another issue
[21:32] <notmart> and for that, the perfect again, will be desktop components
[21:33] <notmart> i don't think is realistic to see them final before qt5 
tough
[21:33] <notmart> so, even without pretty desktop components will have to be 
possible to write config pages in qml, even if they woul look out of place for 
now
[21:33] <notmart> aaaaanyways
[21:33] <viranch> Hmm, I was planning to improve on dev notifier a bit
[21:34] <notmart> this is for the qm scriptengine that is a different issue 
from components
[21:35] <dakerfp> one nice thing to do is to try to use the components in the 
already QMLfyied plasmoids
[21:35] <notmart> once they are set somewhere and can be used as a dependency 
yes
[21:35] <notmart> first thing i wanted to use them for plasma active
[21:35] <dakerfp> ype
[21:35] <dakerfp> *yep
[21:36] <notmart> dakerfp: could we go over the current list of the current 
ones and see really what is missing, i see things more important, things less, 
but at least 20-20 or so could still to be done
[21:36] <terietor> we need blog post which will address the pros of plasma 
components against the plasmawidgets
[21:36] <notmart> and even if they would end up copied and pasted from 
meeg/symbian bohm who cares
[21:36] --> blueck has joined this channel (~bb at p5B36D4A9.dip0.t-
ipconnect.de).
[21:38] <notmart> terietor: also that once is released yes ( i want to 
discourage as much as possible the use of the graphicswidgets components aand 
writing new c++ plasmoids from now on
[21:39] <terietor> notmart: mark them as deprecated when plasma components are 
ready
[21:39] <notmart> dakerfp: i'm taking a look at the symbian components now, it 
seems they follow the specification way more closely (and are only 41)
[21:39] <notmart> could they be taken as (almost) a reference?
[21:39] <notmart> terietor: well they are a qml plugin, not a c++ api, so the 
usual deprecated macro can't work there
[21:41] <terietor> notmart: i was thinking to announce them as deprecated
[21:42] <notmart> yes, sure
[21:44] <-- esben has left this server (Remote host closed the connection).
[21:46] <-- mat69 has left this server (Remote host closed the connection).
[21:47] --> boom1992 has joined this channel (~quassel at i59F5E077.versanet.de).
[21:48] <viranch> So declarativeimports stays in place for now..
[21:49] <-- FL1SK has left this server (Ping timeout: 248 seconds).
[21:49] <notmart> i would like to move it for 4.8, but we'll see if is 
possible
[21:49] <notmart> "there will be a thread for that"(tm)
[21:49] <notmart> dakerfp: ping? ;)
[21:49] <terietor> i think that we should wait Aaron to come back from his 
holidays,and when he comes back to start the thread
[21:50] <notmart> not that ( i know he wants to do it) wanted to hear sebas 
for that that is the release manager, since is in the release phase that can 
make problems
[21:51] <notmart> there are still two things i wanted to discuss before 
calling a wrap
[21:52] <-- mck182 has left this server (Remote host closed the connection).
[21:53] <viranch> Ok..m
[21:53] --> mck182 has joined this channel (~quassel at ip-2-53.hlucinnet.cz).
[21:53] <-- mck182 has left this server (Changing host).
[21:53] --> mck182 has joined this channel (~quassel at kde/developer/mklapetek).
[21:53] <notmart> dakerfp: re-ping? ;)
[21:54] <notmart> aanyways, who offers to check components of the api, one by 
one if they are coomplete, what is missing?
[21:54] <notmart> that's point 1
[21:54] --> yofel_ has joined this channel (~quassel at ubuntu/member/yofel).
[21:54] --> Quintasan_ has joined this channel (~quassel at p5DE7ABC4.dip.t-
dialin.net).
[21:54] <notmart> point 2
[21:54] --> bulldog98_ has joined this channel 
(~quassel at ubuntu/member/bulldog98).
[21:55] <notmart> components for plasma active. some things, like menu will 
have to be really different.
[21:55] <-- bulldog98 has left this server (Read error: Operation timed out).
[21:55] <-- Quintasan has left this server (Read error: Operation timed out).
[21:55] <notmart> other things, little behaviour difference (ie no mouse over 
events)
[21:56] <-- yofel has left this server (Disconnected by services).
[21:56] *** yofel_ is now known as yofel.
[21:57] <notmart> so the decision is wether doing some run time adjustments or 
two completely different sets are needed
[21:57] --> lfranchi-cloud has joined this channel 
(u1289 at amarok/developer/lfranchi).
[21:57] <viranch> I didn't get that
[21:58] <notmart> ok, so basically
[21:58] <notmart> the desktop plasmoids have widgets that while are a bit more 
limited, behave like desktop widgets
[21:59] <notmart> so for instance highlight effect under mouse over, they have 
scrollbars, use qmenus for context
[21:59] <notmart> all of this on a touch device doesn't work
[21:59] <viranch> Oh ok, I think this could be decided by ppl familiar with 
desktop and plasma..
[22:00] <notmart> they won't have any mose over event, hit targets will be 
bigger, scroll indicators instead of scrollbars
[22:00] <notmart> i'm leaning towards doing two different sets
[22:00] <-- pumphaus has left this server (Ping timeout: 244 seconds).
[22:01] <chpadhi> notmart, this cannot be generaliszed , shouldn't it be on 
case to case basis ? 
[22:01] <notmart> finishing before a basic one for the desktop (while keeping 
elements like scroll indicators) and using those for active
[22:02] --> pumphaus has joined this channel 
(~pumphaus at kde/developer/arnorehn).
[22:02] <dakerfp> notmart: pong
[22:02] <notmart> chpadhi: yep, the optimal thing would be falling back 
component by component from a device specific version to a more generic
[22:02] <notmart> but i think qml can fallback only a whole directory
[22:02] <notmart> dakerfp: basically 3 questions ;)
[22:03] <notmart> dakerfp: one: the symbian components seems to adhere almost 
1:1 to the api and not have much more added, am i correct?
[22:03] <dakerfp> notmart: the last time saw it yes
[22:05] <notmart> ok, so we could use those to confront the api i guess
[22:05] <notmart> and eventually take code from there
[22:05] <notmart> uhm i see they are bsd, dunno how much it can be mixed with 
lgpl stuff
[22:06] <notmart> dakerfp: two, we should really try to go component by 
component cheking both the api and checking what are all the ones that we are 
still missing
[22:07] <dakerfp> we had a code to check the compliance of with the api
[22:07] <notmart> ah, that's nice ;)
[22:07] <dakerfp> i'll see if we still have that prototype
[22:07] <notmart> is that available somewhere?
[22:07] <dakerfp> it was a internal protoytype
[22:08] <dakerfp> i'll see if i can get it
[22:08] <-- tittiatcoke has left this server (Quit: Konversation terminated!).
[22:08] <notmart> relaseable or nda? ;)
[22:09] <dakerfp> i'll check this out
[22:09] <notmart> so that would at least help us to validate (if it can be 
found quiclky, the better;)
[22:10] <notmart> then we still have to go trough the pieces and implement the 
missing, hopefully stealing as much as possible from probably symbian
[22:11] <notmart> uh
[22:11] <notmart> symbian has a scroll*bar* component
[22:11] <dakerfp> notmart: https://qt.gitorious.org/qt-components/qt-
components/trees/master/tests/apicheck
[22:11] <dakerfp> it's now opened
[22:11] <notmart> that's nice and unexpected, the api i proposed back in 
dublin last year made it after all
[22:11] <notmart> dakerfp: ok, neat ;)
[22:12] <notmart> i'll try to make it run trough ours tonight if will be an 
easy setup
[22:13] <-- retrova_ has left this channel.
[22:13] <-- unormal has left this server (Ping timeout: 240 seconds).
[22:13] <notmart> dakerfp: the other thing: components for the desktop vs 
components for plasma active/touch
[22:14] <notmart> they will have to be cloned and adapted, no ways around this 
code duplication i guess?
[22:15] <notmart> yay, symbian api has a really private way for private 
properties..
[22:16] <dakerfp> notmart: i think it's too hard to not duplicate
[22:16] <notmart> its code quality it's just so much better than the harmattan 
one that isn't even fun
[22:16] <notmart> kinda the meegotouch vs orbit drama repeating :p
[22:16] <dakerfp> notmart: I'll study the possibility to talk with jens and at 
least use the customs components as a base for the plasma one
[22:17] * notmart was even thinking about every item being a Loader that with 
some hack, loads a qml file from either of two places
[22:17] <notmart> sounds quite sick tough ;)
[22:17] <notmart> dakerfp: those custom components are where atm?
[22:18] <dakerfp> components/custom at qt-components/desktop
[22:18] <notmart> ah, in desktop ok
[22:19] <dakerfp> https://qt.gitorious.org/qt-
components/desktop/trees/master/components/custom
[22:19] * notmart tought there was only the ones using qstyle in it
[22:19] <-- larsivi has left this server (Ping timeout: 240 seconds).
[22:20] * notmart thinks 2 hours as a meeting is painful enough and we can 
call a wrap ;)
[22:20] <notmart> i'll summarize the points on the ml
[22:20] <terietor> i am kind of lost
[22:21] <terietor> is it possible all these components to be parsed and to be 
outputed with the plasma theme?
[22:21] <notmart> uh?
[22:21] <dakerfp> we had a prototype of components using loaders that made a 
lot of sense
[22:21] <terietor> or to be reimplemented like QPushButton and KPushButton
[22:22] <terietor> is that possible?
[22:22] <dakerfp> but in the end we realized that was easier to create new API 
compatible widgets than make them extendable for any platform
[22:23] <notmart> terietor: in qml if you declare an item using another one, 
like Button { extra stuff in there} is *almost* as a subclass, not completely 
unfortunately
[22:23] <terietor> i see
[22:23] <notmart> dakerfp: hmm, so i thnk we will go for one single set for 
everybody at start then when one is complete fork and adapt
[22:23] <terietor> so to summarize
[22:24] <terietor> we will copy&paste whatever is mising and we can to 
complete our plasma components.correct?
[22:24] <notmart> dakerfp: perhaps installing them into 2 different folders 
which priority of import can be altered from c++ would make easy to import a 
set or the other without changing the import *foo* line
[22:24] <-- Kame2 has left this server (Ping timeout: 245 seconds).
[22:25] <notmart> terietor: copy&paste or preferably reimplement, but there is 
not that much missing i think 
[22:25] <notmart> dakerfp: tough i see that custom components really don't 
have much, we already have basically all of them ;)
[22:25] <dakerfp> yep 
[22:26] * terietor do we have any news from the kdev team about qml support 
plugin?
[22:26] <notmart> uh?
[22:26] <dakerfp> ?
[22:26] * terietor notmart is going to kill me....
[22:27] <terietor> until now there is no kde "stuff" to provide 
highligt,completion,code browse for qml
[22:27] *** mhr4 is now known as seif.
[22:27] <notmart> terietor: contributors are hard to find enough, even if 
could be quite fun, if i start to kill them it would be quite of a problem :p
[22:28] <notmart> ah, yeah
[22:28] <terietor> :)
[22:28] <notmart> unfortunately don't know much about it
[22:28] <terietor> i made a small research about that
[22:28] * notmart dislikes all the ides in the world so much that i don't even 
ask myself if a thing like that exists or not ;)
[22:29] <-- jhk has left this server (Read error: Connection reset by peer).
[22:29] <terietor> it is possible to be done but not by us,doc is missing and 
it is required a good knowledge of the api
[22:29] <terietor> notmart: vim?
[22:30] <notmart> just kate, occasionally vim ;)
[22:31] <notmart> yeah, i we shouldn't invest time in that atm
[22:31] <notmart> i mean, would be cool, but not the priority
[22:31] <notmart> if someone in kdevelop wants to do it, i would be happy
[22:31] <sreich> yeah, definitely no point in doing that
[22:31] <sreich> just because it's so early in development
[22:31] * terietor i don't think that a plasma dev would do it
[22:31] <sreich> I mean, the apis are still very young
[22:32] <terietor> so we go on,end the meeting?
[22:33] <notmart> yeah, end meeting i would say, before we melt ;)
[22:34] <notmart> i'm writing some points on the mailing list
[22:34] <notmart> and then discussion can continue there
[22:34] <dakerfp> awesome
[22:34] <viranch> Cool..
[22:35] <viranch> See you all on the ml.. ;)
[22:36] <dakerfp> see you
[22:36] <notmart> btw, remember to keeep all replies both to plasma-
devel at kde.org and active at kde.org
[22:37] <notmart> jnwi: btw, if you could subscribe to one/both of those 
mailing lists would be rocking ;)
[22:37] <jnwi> ok
[22:38] <jnwi> thanks for inviting me to the meeting :)
[22:38] <terietor> cool,we will continue on the mailing list
[22:38] <-- viranch has left this server (Quit: AndroIRC - Android IRC Client 
( http://www.androirc.com )).
[22:39] * terietor loved to have jnwi at the meeting
[22:39] <notmart> so, thanks everybody :)