Re: GSOC 2012 project: Make plasmate ready for release
On Thursday, March 15, 2012 18:19:17 Giorgos Tsiapaliwkas wrote: I was thinking to add the scp feature into plasmapkg and then plasmate to take it from there. What do you think? that's a nice idea; that way any usage of plasmapkg could do this. neat. -- Aaron J. Seigo 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
Re: GSOC 2012 project: Make plasmate ready for release
On 14 March 2012 15:45, Aaron J. Seigo ase...@kde.org wrote: for kde-workspace/plasma/generic/tools i think it makes sense to put them all into the plasmate repo. the runtime tools need to stay where they are as they are used by 3rd party apps for things like package installation, and plasmate can rely on them being there as well. I was thinking to add the scp feature into plasmapkg and then plasmate to take it from there. What do you think? i would like to see the menus from plasma-prevewier in plasmoidviewer, however. having to restart plasmoidviewer to get different results sucks :) otherwise, +1 I modified the proposal in the wiki. :) the rest of the tasks look excellent and well though out. if you can put a page together on the wiki documenting this that would be great, and i might even blog about it to hopefully drum up some more participation. here is the wiki page, http://community.kde.org/Plasma/GSoC/2012 Feel free to modify the wiki page.:) Regards, Giorgos -- Giorgos Tsiapaliwkas (terietor) KDE Developer terietor.gr ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSOC 2012 project: Make plasmate ready for release
On Thursday, March 8, 2012 21:04:49 Giorgos Tsiapaliwkas wrote: Hello, this is my modified proposal, -Task 1 --Problem 1 Right now plasmate doesn't support all the debugging tools which we offer. Those debugging tools live under kde-workspace/plasma/generic/tools. --Solution 1 a.Move all the debugging tools from kde-workspace/plasma/generic/tools and kde-runtime/plasma/tools into plasmate's repository(maybe we should rename the repository to Plasma SDK) for kde-workspace/plasma/generic/tools i think it makes sense to put them all into the plasmate repo. the runtime tools need to stay where they are as they are used by 3rd party apps for things like package installation, and plasmate can rely on them being there as well. Expected time: this task has to be done by a sysadmin since I don't have that kind of access. nah .. you can do this. you just need to run a git branch history over the plasma-workspace/plasma/generic/tools directory and run those commits into plasmate, then remove the directory from plasma-workspace. c.our debugging tools will still live as standalone applications and also us plasmate's plugins. sounds good. -Task 2 --Problem 2 Plasmate and plasmoidviewer have duplicate code. Also plasma-previewer(the plasmate's code for plasmoid debugging) is more modular than the plasmoidviewer's code. Plasma-previewer is more modular but plasmoidviewer has more features than the plasma-previewer. --Solution 2 Replace plasma-previewer's code with plasmoidviewer's and make plasmoidviewer's code more modular in order to be reused by plasmate. i would like to see the menus from plasma-prevewier in plasmoidviewer, however. having to restart plasmoidviewer to get different results sucks :) otherwise, +1 variable. Plasmoidviewer should provide an option for that (I will add this option). +1 the rest of the tasks look excellent and well though out. if you can put a page together on the wiki documenting this that would be great, and i might even blog about it to hopefully drum up some more participation. -- Aaron J. Seigo 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
Re: GSOC 2012 project: Make plasmate ready for release
Hello, this is my modified proposal, -Task 1 --Problem 1 Right now plasmate doesn't support all the debugging tools which we offer. Those debugging tools live under kde-workspace/plasma/generic/tools. --Solution 1 a.Move all the debugging tools from kde-workspace/plasma/generic/tools and kde-runtime/plasma/tools into plasmate's repository(maybe we should rename the repository to Plasma SDK) Expected time: this task has to be done by a sysadmin since I don't have that kind of access. b.make plasmate use those tools. c.our debugging tools will still live as standalone applications and also us plasmate's plugins. Some of our devs doesn't like plasmate and we shouldn't force them to use it. So having our debugging tools both as standalone application and as plasmate's plugins solves the issue. Regarding the build system I can add the debugging tools and plasmate as option in order not to force some developer to build the entire repository. Expected time: Approximately one week Priority: this is the last one(7) -Task 2 --Problem 2 Plasmate and plasmoidviewer have duplicate code. Also plasma-previewer(the plasmate's code for plasmoid debugging) is more modular than the plasmoidviewer's code. Plasma-previewer is more modular but plasmoidviewer has more features than the plasma-previewer. --Solution 2 Replace plasma-previewer's code with plasmoidviewer's and make plasmoidviewer's code more modular in order to be reused by plasmate. Also a side note here both plasma components for desktop and for active live with the same names. So in order to use the plasma components for active the developer has to change an environment variable. Plasmoidviewer should provide an option for that (I will add this option). Expected time: Approximately one week Priority: pre-last one(6) -Task 3 --Problem 3 There is no plasma tool for us to open our svg images add see the available layers. Since we want to offer a nice sdk our users should be able to browse our svgs easier. --Solution 3 Sreich's svgviewer solves the half of the problem(thank you Sreich) the other half(there is no way to see the available layers of each svg). I will implement this option. Expected time: approximately one week Priority:5 -Task 4 --Problem 4 KConfigXT editor isn't finished. There is still some code which has to be written. --Solution 4 Finish the KConfigXT editor and also make it available as a standalone application. All of our debugging tools shouldn't force our developers to use plasmate. Expected time: approximately 2/3 weeks Priority:4 -Task 5 --Problem 5 Plasmate's editor doesn't support actions.(Like undo/redo,etc) --Solution 5 Make plasmate support those. Expected time: approximately 1 week Priority: 1 -Task 6 --Problem 6 There is no way to install remotely a plasmoid package --Solution6 Create a remote installer, so that you can push a button which copies your plasmoid package onto a device running Plasma (Active) and runs it, so you can try it on a touch screen. That could be done with scp, for example. Expected time: 2/3 weeks Priority: 2 Task 7 Problem 7 If the user is using plasmate there is no way to see the output of print/console.log Solution7 Add a console in plasmate which will contain the output from the debugger like plasmoidviewer. Expected time: 2 weeks Priority:3 P.S.: sorry for my delay to reply but I send the modified proposal only to sebas(bad misclick!) when I had it ready. Regards, Giorgos. -- Giorgos Tsiapaliwkas (terietor) KDE Developer terietor.gr ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSOC 2012 project: Make plasmate ready for release
Hi Giorgos, On Wednesday, February 29, 2012 14:11:24 Giorgos Tsiapaliwkas wrote: this year I want to apply for the GSOC 2012 for the plasma project. My idea for plasma's GSOC 2012 is to make plasmate ready for release. One thing that I'd really like to see, and which would boost the usefulness of Plasmate is a remote installer, so that you can push a button which copies your plasmoid package onto a device running Plasma (Active) and runs it, so you can try it on a touch screen. That could be done with scp, for example. There's another thing which is fairly confusing right now but very basic and expected by every developer: a debugging console, basically a way to see what the print() statements in your code output. That would need to be solved as well (even if in a pretty basic fashion). The good news is that this will be a lot easier with QML2 (which is out of scope for this proposal, but still interesting: http://labs.qt.nokia.com/2012/03/01/debugging-qt-quick-2-console- api/ ). Otherwise, your proposal looks good, well structured and clearly laid out. It might be useful to note priorities for your problems, to mention in which order you want to tackle them. (It can always happen that an items takes longer than expected, in which case you should have a clear strategy of clearing that time.) For example, some of the refactoring tasks are surely nice-to-have, but don't contribute immediately to the goals of making it release-ready / immediately useful. I'd personally move those to the end of the list. I'd be happy to mentor you, btw. :) Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
GSOC 2012 project: Make plasmate ready for release
Hello, this year I want to apply for the GSOC 2012 for the plasma project. My idea for plasma's GSOC 2012 is to make plasmate ready for release. So here it goes, Problem 1 Right now plasmate doesn't support all the debugging tools which we offer. Those debugging tools live under kde-workspace/plasma/generic/tools. Solution 1 a.Move all the debugging tools from kde-workspace/plasma/generic/tools and kde-runtime/plasma/tools into plasmate's repository(maybe we should rename the repository to Plasma SDK) b.make plasmate use those tools. c.our debugging tools will still live as standalone applications and also us plasmate's plugins. Some of our devs doesn't like plasmate and we shouldn't force them to use it. So having our debugging tools both as standalone application and as plasmate's plugins solves the issue. Regarding the build system I can add the debugging tools and plasmate as option in order not to force some developer to build the entire repository. Problem 2 Plasmate and plasmoidviewer have duplicate code. Also plasma-previewer(the plasmate's code for plasmoid debugging) is more modular than the plasmoidviewer's code. Plasma-previewer is more modular but plasmoidviewer has more features than the plasma-previewer. Solution 2 Replace plasma-previewer's code with plasmoidviewer's and make plasmoidviewer's code more modular in order to be reused by plasmate. Also a side note here, both plasma components for desktop and for active live with the same names. So in order to use the plasma components for active the developer has to change an environment variable. Plasmoidviewer should provide an option for that (I will add this option). Problem 3 There is no plasma tool for us to open our svg images add see the available layers. Since we want to offer a nice sdk our users should be able to browse our svgs easier. Solution 3 Sreich's svgviewer solves the half of the problem(thank you Sreich) the other half(there is no way to see the available layers of each svg). I will implement this option. Problem 3 KConfigXT editor isn't finished. There is still some code which has to be written. Solution 3 Finish the KConfigXT editor and also make it available as a standalone application. All of our debugging tools shouldn't force our developers to use plasmate. Problem 4 Plasmate's editor doesn't support actions.(Like undo/redo,etc) Solution 4 Make plasmate support those. We have to add more comments/documentation into the code in order to bring lower the contribution barrier. Is there someone who would like to mentor me for the specific project? Regards, Giorgos. -- Giorgos Tsiapaliwkas (terietor) KDE Developer terietor.gr ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
