Re: Review Request: Plasmate:now StartPage::createNewProject() creates the plasmateprojectrc and not the StartPage::loadLocalProject()

2011-10-13 Thread Giorgos Tsiapaliwkas


 On Sept. 30, 2011, 12:39 p.m., Aaron J. Seigo wrote:
  startpage.cpp, lines 557-562
  http://git.reviewboard.kde.org/r/102732/diff/1/?file=37467#file37467line557
 
  this should remain, so that opening a project that doesn't have the rc 
  file gets one. best might be to move this code into a method called 
  something like ensureProjectrcFileExists() and then call it from both of 
  these places.

We have an issue.
Look at the commit 3a9061a6437221a3c80b16eaf9948b28dcc70e5a if i do the above 
change then plasmate will not create the .git directory in the right place.

I can thing three solutions,
1.to have two plasmateprojectrc files which will have a different name
2.to scan the entire folder for a .git dir and if none will be found then to 
create the .git dir
3.to add something in the plasmateprojectrc which will act as a flag.


- Giorgos


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102732/#review6960
---


On Sept. 29, 2011, 8:51 a.m., Giorgos Tsiapaliwkas wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/102732/
 ---
 
 (Updated Sept. 29, 2011, 8:51 a.m.)
 
 
 Review request for Plasma.
 
 
 Description
 ---
 
 Hello,
 
 for the moment the .plasmateprojectrc file exists as a mark for the projects 
 created by plasmate.
 We want the file to be created in the creation of the project not in the load 
 of the project,the patch does that.
 
 cheers
 
 
 Diffs
 -
 
   startpage.cpp fc00441 
 
 Diff: http://git.reviewboard.kde.org/r/102732/diff/diff
 
 
 Testing
 ---
 
 workinig
 
 
 Thanks,
 
 Giorgos Tsiapaliwkas
 


___
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