This year I’ve been accepted as a Google Summer of Code student. My project goal is to port some plasma widgets (luna, fifteen puzzle, timer, calculator and notes) and the calendar to QML.
This GSoC project is rather important for several reasons, including:
- QML will play an important role in Qt5
- Using QML will allow to switch easily to QML Scene Graph
- QML makes development and maintenance easier
- QML plasma widgets much less likely crash the plasma shell
I would like to underline that a plasma widget is ported when there are no regressions so no one will notice the difference (anyway I hope they will behave better).
I’ve been working on this GSoC project for nearly a month now and the port of some widgets is almost complete (there are some missing pieces that needs to be addressed but I think they will be ready soon).
Anyway at the Akademy I will talk more about this GSoC project (Sat. 30 at 10.15/Room 2) 🙂
Congratulations for your QML-porting project and good luck for your talk at the Akademy.
That looks very nice – very similar 🙂
However, i do see one big issue for you that you’ve probably not solved yet. The current time in KDE in the panel is drawn in a very special way.. The nicest way to do that in QML is with shaders and effects that become possible in Qt 5. The current clock (in the panel) uses some custom plasma drawing class.
As for the calender. How do you plan on filling the calender? Will you calculate all the grid stuff (as in which days to show in which month) in C++, prepare the data and send ready made data to QML that simply displays it in a Grid? If so, i can save you some trouble since I’ve already done exactly that. If you want i can give you the code for that. What it’s missing is showing events on the calender. So now it really is just a grid that displays numbers. Here is how it looks:
http://ompldr.org/vZWgwcg (the most clean version)
http://ompldr.org/vZWgwdA (the “year” view of a single month, looks cool if you add all 12 months. Like so: http://ompldr.org/vZGR0Yg)
It’s freely adjustable and all data is being fed ready from C++. C++ sends all data for a full month including a few days before and after. QML prints what it wants to have.
yes, I know how it works: I’ve worked on that code at the time of KDE 4.0/4.1 😉 Anyway I don’t plan to work on it during this Google Summer of Code so it will not be a problem in the short term.
I plan to discuss calendar implementation details with my mentor during the akademy 🙂 Is your code dealing with localtization? When I wrote the first calendar implementation I spent a lot of time trying to manage it.
Well, my code is using the QDate* classes. I haven’t add localization support and since Qt doesn’t have that by default i guess i just don’t have support for localization :p
Now that i think of it a bit more.. What exactly do you mean by localization? As in displaying “localized” events or something? The calender itself is only displaying numbers in a given month and those are the same worldwide right? I mean, every country has a 12 month calender with either 30 or 31 days (Ferrari being the exception with 28 or 29). Or am i completely wrong now? I’m not that knowledgeable about calendars. 🙂
Davide might be referring to the different calendar systems, see
> I mean, every country has a 12 month calender with either 30 or 31 days
Take a look to the islamic calendar for example.
Ahh, like so.
Nope, my code certainly doesn’t support that. I’m only using QDate ^_^
I think you’re fine using KCalendarSystem 🙂 Till the point where Qt itself implements ICU http://site.icu-project.org/ which is probably for Qt 5.1 Then the KCalendarSystem should imho be deprecated and the Qt based solution should be used. Just take that into account since the Calendar stuff in KDE/Qt land is about to change for the better.
I’m not quite sure yet what i’m going to do with my calendar experiments. I was planning in recreating the KDE calendar stuff from Kontact since it’s hopelessly outdated. The issue i have is that QML has a lot to be desired when it comes to making a calendar/agenda. For instance selecting multiple rows to make an appointment.. I really have to do a lot of hacky stuff to get remotely close to something working. QML 2 will be better, but still far from sufficient. Drag and drop is also a bit of dark magic.. Even in QML 2 as far as i can tell.
> QML plasma widgets much less likely crash the plasma shell
The same had been said about other interpreted widgets (e.g. Python), yet I see very many crash reports from Python widgets, with a backtrace which make it possible to debug the issue.
IMpossible, of course 🙂
I understand, but crashing the whole shell with buggy C++ code is still the simplest way. JS is still the best way to avoid crashes and I don’t think that we can do better than this.
“Timer widgets comparison (left: C++ version, right: QML version). Do you see any difference?
Yeah, there is a glaring difference. Obviously, from the top corner, the pixel 60 down and 120 to the right is 1.3% darker 😉
Seriously, though, great work. It looks excellent so far.
Like Christoph points out, buggy QML code *does* exist, especially buggy JS code in QML plasmoids, and the backtrace does not help. I have written some myself. I have also seen QML plasmoids using 4.8 API which does not exist in 4.7 make Plasma 4.7.x crash.
For Luna, maybe you can have a look at http://kde-apps.org/content/show.php/Luna+QML?content=140204
That kind of problems will be solved with newer versions of Qt. 🙂
Anyway I’ll take a look to that luna plasma widget 🙂