Re: Plasma QtComponents IRC meeting: summary

2011-10-20 Thread Giorgos Tsiapaliwkas
Sorry for my late response.

I came in contact with Dimitri and he told that there are no plans for QML
at the moment.
http://sourceforge.net/mailarchive/forum.php?thread_name=CAODYyLbKZ4Gm8XVnHeg0RfcR%2BfNFwwd-JX%3DdtNv8y22PH1ZuZQ%40mail.gmail.comforum_name=doxygen-users

So what are we going to do?

-- 
Tsiapaliwkas Giorgos (terietor)
KDE Developer

terietor.gr
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: Plasma QtComponents IRC meeting: summary

2011-10-20 Thread Marco Martin
On Thursday 20 October 2011, Giorgos Tsiapaliwkas wrote:
 Sorry for my late response.
 
 I came in contact with Dimitri and he told that there are no plans for QML
 at the moment.
 http://sourceforge.net/mailarchive/forum.php?thread_name=CAODYyLbKZ4Gm8XVnH
 eg0RfcR%2BfNFwwd-JX%3DdtNv8y22PH1ZuZQ%40mail.gmail.comforum_name=doxygen-u
 sers
 
 So what are we going to do?

comment them as it was supported.
commented sources are better than nothing at all ;)

maybe in the end we'll end up writing some perl monster, whatever

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: Plasma QtComponents IRC meeting: summary

2011-10-20 Thread Aleix Pol
Can't we use whatever Qt is using already?

Aleix

On Thu, Oct 20, 2011 at 9:25 PM, Marco Martin notm...@gmail.com wrote:

 On Thursday 20 October 2011, Giorgos Tsiapaliwkas wrote:
  Sorry for my late response.
 
  I came in contact with Dimitri and he told that there are no plans for
 QML
  at the moment.
 
 http://sourceforge.net/mailarchive/forum.php?thread_name=CAODYyLbKZ4Gm8XVnH
  eg0RfcR%2BfNFwwd-JX%3DdtNv8y22PH1ZuZQ%40mail.gmail.com
 forum_name=doxygen-u
  sers
 
  So what are we going to do?

 comment them as it was supported.
 commented sources are better than nothing at all ;)

 maybe in the end we'll end up writing some perl monster, whatever

 Cheers,
 Marco Martin
 ___
 Plasma-devel mailing list
 Plasma-devel@kde.org
 https://mail.kde.org/mailman/listinfo/plasma-devel

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Plasma QtComponents IRC meeting: summary

2011-10-13 Thread 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@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 
(~quas...@cl-86-125-150-199.cablelink.mures.rdsnet.ro).
[20:22] notmart so, very short introduction, components are 

Re: Plasma QtComponents IRC meeting: summary

2011-10-13 Thread Martin Gräßlin
On Thursday 13 October 2011 23:00:36 Marco Martin wrote:
 * 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?
let's do the documentation in doxygen style and let's try to get QML support 
into doxygen.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel