On Monday, March 12, 2012 01:27:17 Laszlo Papp wrote: > dependencies will also be simpler for the Plasma Active App Store than > Ovi hopefully because we do not hopefully need to bundle the > dependencies up with our packages.
that is correct :) > Then there were general realizations about not having enough manpower > in the project (there are nowadays more and more platforms to port > to), and it would be nice to improve the collaboration with teachers > and students as well in the future. i think having devices with Plasma Active on it will help a lot in this regard. as it becomes a "real product" more people are paying attention to it. > Another smaller, but very important topic to me is that it would be > nice to get a qml frontend for the khns and get hot new stuff > functionality. Unfortunately, it is not a big enough task for a GSoC > student in my opinion, and I have already put many ideas about Gluon > in there, thus it is not gonna happen as part of that session. i think that "done right" it is a more significant proposition than one might consider at first. what would be very nice is to have a general "show the add-ons interface" QML component that make it easy to integrate with the platform. GHNS is just one possible target, while other platform may have specific requirements that differ. imho GHNS is a "KDE desktop platform" component and, as can be seen with things like Ovi or Bodega for our tablet, may not translate well to other device experiences. i do not think this makes sense to expose in the khns library, but rather it would make sense to have a QML component with a reference implementation that uses KHNS but which can be easily swapped out on-device for a different provision mechanism. note that one important / useful feature which khns currently lacks afaics is the ability to define a developer account so that in-app purchases can be associated with a proper developer. additionally, getting a touch UI that works really well is not perhaps as trivial as it may seem at first. the desktop ghns window is not really directly translatable as it is very mouse and keyboard centric. for the average skill level of a gsoc student (at least IME) getting that UI to "good" could easily take a month of effort. > == Implementation side == > > === Packaging ==== > 1) libkdeedu > 2) analitza > 3) kalgebra > 4) kanagram > 5) khangman > > See my private repository on the Community OBS for details (things are > there pretty much the results of this event): > https://build.pub.meego.com/project/packages?project=home%3Adjszapi%3AKDE-De > vel coool... btw, a couple people asked specifically about KDE Edu availability for Plasma Active at CeBIT. there is interest! > 1) Kanagram now has a plasma active subfolder with the initial steps > (metadata desktop file, ui contents, kdeclaratiview, etc). Ui needs to > be developed (qml files will be added into the package/contents/ui > folder), but the proper structure is already in place. > > 2) KHangMan has the same establishment, plus I decoupled the "engine" > and the harmattan relevant code, so the engine I established for > Harmattan is reusable for the Plasma Active frontend in the future. > Same thing as with kanagram, ui needs to be developed, thus not much > happened on that front. as soon as this is "demo-able" we should definitely blog about it and perhaps even use it as an example in a tutorial on Techbase for how to make an app ready for Plasma Active and / or touch in general (in addition to the existing desktop UI, e.g.) -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Active mailing list [email protected] https://mail.kde.org/mailman/listinfo/active
