Re: [Kde-pim] Kontact Touch GSOC Project - mentor needed
On Thursday, April 18, 2013 16:28:45 Thomas Pfeiffer wrote: Redoing the UI entirely in QML would mean: - heavily compromise on features, at least for the first iteration during GSoC - reuse the existing models from Kontact Touch for the message and folder lists - refactor the remaining required bits of widget based code for model/view separation. IIRC this will mainly affect the composer, which is still an embedded widget. The first two seem implicitly already present in the proposal, the last one might be a bit underestimated. Redoing the entire Kmail Touch UI in QML would definitely be too big a scope for a GSoC project. What I want to have in the end is something which shows the path ahead and can be built upon. On that note, I think it would be best to do the GSoC as small mergable steps, that can go in one for one. As most of the code is already done in QML, a ton of small patches that go into master one for one would probably be nicer than to create one big branch that has to be merged at some scary point in time. This is of course mostly up to Kevin, I guess, as he'll likely be reviewing most of the code, I just wanted to chime in in case it hasn't been thought of. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: [Kde-pim] Kontact Touch GSOC Project - mentor needed
On Monday, 2013-04-22, Sebastian Kügler wrote: On Thursday, April 18, 2013 16:28:45 Thomas Pfeiffer wrote: Redoing the entire Kmail Touch UI in QML would definitely be too big a scope for a GSoC project. What I want to have in the end is something which shows the path ahead and can be built upon. On that note, I think it would be best to do the GSoC as small mergable steps, that can go in one for one. As most of the code is already done in QML, a ton of small patches that go into master one for one would probably be nicer than to create one big branch that has to be merged at some scary point in time. This is of course mostly up to Kevin, I guess, as he'll likely be reviewing most of the code, I just wanted to chime in in case it hasn't been thought of. The problem with that approach usually is that master gets frozen during the GSoC period. While we could probably make an exception for code that goes into kdepim/mobile (I don't think we official release that), some changes could affect even kdepimlibs and we certainly don't want to risk master branch there. Suggestions welcome though :) Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
GSoC proposal - Network management for PA
Hi, I would like to join to GSoC and I have my own idea. Since we are working on a new plasma network applet I think it would be great to improve this applet for Plasma active because the current applet is not simply usable. I've already talked about it with Lamarque on the solid sprint but I need also some co-mentor from Plasma active (if somebody like this idea). The idea is: *Network applet for Plasma applet written in plasma2:* 1) Customize our applet for Plasma active and use plasma2 2) Write some basic editor in QML instead of using QWidgets and drop support for unnecessary devices and properties 3) Maybe some KCM for Plasma active 4) Add support for activities 5) if you have any other ideas Thanks for your feedback. -- Jan Grulich Red Hat Czech, s.r.o jgrul...@redhat.com ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: [Kde-pim] Kontact Touch GSOC Project - mentor needed
On Monday, April 22, 2013 16:34:44 Kevin Krammer wrote: On Monday, 2013-04-22, Sebastian Kügler wrote: On Thursday, April 18, 2013 16:28:45 Thomas Pfeiffer wrote: Redoing the entire Kmail Touch UI in QML would definitely be too big a scope for a GSoC project. What I want to have in the end is something which shows the path ahead and can be built upon. On that note, I think it would be best to do the GSoC as small mergable steps, that can go in one for one. As most of the code is already done in QML, a ton of small patches that go into master one for one would probably be nicer than to create one big branch that has to be merged at some scary point in time. This is of course mostly up to Kevin, I guess, as he'll likely be reviewing most of the code, I just wanted to chime in in case it hasn't been thought of. The problem with that approach usually is that master gets frozen during the GSoC period. While we could probably make an exception for code that goes into kdepim/mobile (I don't think we official release that), some changes could affect even kdepimlibs and we certainly don't want to risk master branch there. Suggestions welcome though Idea: The go in doesn't have to be master, while master is frozen, the patches could get reviewed into another branch, which gets merged whenever master is unfrozen. The reason why I propose this is because I think it could become quite the monster project, that will take very long to stabilize and achieve feature parity again. A kernel style development process usually prevents that from happening quite effectively. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
