While being in Maemo Summit or in Qt Developer Days, did you notice this guy below? Did you ask from him "Have you been working with multitouch-enabled WebKit lately?" Why not? ;-)
Kimi has been working in project called "Starlight" and part of the project is to bring multitouch into WebKit. So while you look at the video below and think "Hmm, just another multitouch photo rotate&scale demo..." please notice that this is all done inside browser with just HTML, CSS & JavaScript! In other words: It's just a normal web page without any black magic.
Starlight has now public website here, more videos available in here, and a developer guide with API & examples here.
Isn't it just convenient that this was published about simultaneously with the information that Maemo 6 will support multitouch... Sure beats my lame N810 multitouch hack! ;-)
Planet maemo: category "feed:ffedab845b17ad5f072a1f90af70d0f9"
We got back to Finland last night from our longish Helsinki->Amsterdam->Munich->Helsinki trip! Full load of excellent presentations, nice discussions with people and a strong feeling that things are proceeding into right direction!
Blogging with real content later, now I just want to thank everyone for participating!
Blogging with real content later, now I just want to thank everyone for participating!
During the weekend I got inspired with the question: What could a tab-widget look like when implemented as a QGraphicsWidget and armed with QGraphicsEffects & Qt Animation framework?
This is the first try:
Without explaining any further what/why/how (except that "mouse" icon is there just to show when button is down), I'd like to ask comments on how would you want tabs to behave? Note that the goal here is to have eye candy and usability, not necessarily long battery life... ;-)
Update: To demo how this looks (and performs) in tablets, I built Qt 4.6 tp1 for N810. With reduced effects (it's after all just N810), the prototype behaves like this:
Graphics:
- Background: Aamos & Eelis
- Icons: Tango http://tango.freedesktop.org
This is the first try:
Without explaining any further what/why/how (except that "mouse" icon is there just to show when button is down), I'd like to ask comments on how would you want tabs to behave? Note that the goal here is to have eye candy and usability, not necessarily long battery life... ;-)
Update: To demo how this looks (and performs) in tablets, I built Qt 4.6 tp1 for N810. With reduced effects (it's after all just N810), the prototype behaves like this:
Graphics:
- Background: Aamos & Eelis
- Icons: Tango http://tango.freedesktop.org
I'm back from vacation, summer went fast as always! Tried to stay away from computers, spending the time with family & friends and enjoying the weather while it lasts... But I did have little coding fun also, testing how well "multitouch" would work in N810 ;-)
Here comes video:
Update: Like all respected magicians, I'll show how this trick works for the ones who didn't already know the behavior of (resistive, single-touch) touchscreens under multiple touches. As thp first commented, it is "using the 'merged' blob position that you get with the single touch screen and interpreting it as the middle of two or more equal-pressure points".
Now here is a video showing the same demo in PC, with "cheat mode" turned on:
So it's mostly useless... but somewhat f-f-f-fun :)
Here comes video:
Update: Like all respected magicians, I'll show how this trick works for the ones who didn't already know the behavior of (resistive, single-touch) touchscreens under multiple touches. As thp first commented, it is "using the 'merged' blob position that you get with the single touch screen and interpreting it as the middle of two or more equal-pressure points".
Now here is a video showing the same demo in PC, with "cheat mode" turned on:
So it's mostly useless... but somewhat f-f-f-fun :)
Carl Worth blogged here about Cairo 2D performance measurements:
Should I be offended and sad as someone as respected as Carl blames my precious GtkPerf? Well of course not! Citing myself from GtkPerf website:
So as seen, I fully agree (and have always agreed) that GtkPerf is not the tool to use for getting real-life application performance measurements. But what it is, is a very easy and fast way to get a view of the GTK+/GDK/Cairo performance of your system.
These days I spend my time mostly with Qt and often benchmark the actual frame rate of the application, which with QGraphicsView-based UI is easily done for the whole view using the paintEvent() callback. And keeping the FPS visible when developing your new flashy UI really helps (at least me!) to spot & fix the performance regressions while they happen.
The last thing Carl says is:
So pointing: When measuring GTK+/Cairo performance trying to get accurate real-world results, please don't use GtkPerf. Instead use the cairo-perf-trace as noted, thanks!
Various attempts at 2D-rendering benchmark suites have appeared and even become popular. Notable examples are x11perf and gtkperf. My claim is that these tools range from useless to actively harmful when the task is understanding performance of real applications.
...
Unfortunately, the workload of things like x11perf and gtkperf rarely come close to simulating practical workloads.
Should I be offended and sad as someone as respected as Carl blames my precious GtkPerf? Well of course not! Citing myself from GtkPerf website:
I know that bencmarking tools (including GtkPerf) can be fooled and don't give real-life results. Yet, I belive that GtkPerf can be helpful to solve for example this kind of things:
...
So as seen, I fully agree (and have always agreed) that GtkPerf is not the tool to use for getting real-life application performance measurements. But what it is, is a very easy and fast way to get a view of the GTK+/GDK/Cairo performance of your system.
These days I spend my time mostly with Qt and often benchmark the actual frame rate of the application, which with QGraphicsView-based UI is easily done for the whole view using the paintEvent() callback. And keeping the FPS visible when developing your new flashy UI really helps (at least me!) to spot & fix the performance regressions while they happen.
The last thing Carl says is:
The punchline is that we now have an easy way to benchmark 2D rendering in actual, real-world applications. If you see someone benchmarking with only toys like x11perf or gtkperf, go ahead and point them to this post, or the the cairo-perf-trace entry in the cairo FAQ, and insist on benchmarks from real applications.
So pointing: When measuring GTK+/Cairo performance trying to get accurate real-world results, please don't use GtkPerf. Instead use the cairo-perf-trace as noted, thanks!
I think offering Qt with LGPL was already a good change towards openness, but now Qt opens some more with public Gitorious repository!
I've been working recently with Qt Animation Framework, trying to learn how to utilize it efficiently. Below is a video showing circular carousel widget which uses the animation framework.
I need to still continue experimenting how to really extend the animation classes and use the whole state machine framework, but so far I'm impressed by the latest 2.2 API version. Originally my biggest concern about this whole "Kinetic" was that it would be too high-level and have suboptimal performance in embedded devices, but luckily that doesn't seem to be the case. Now with Qt 4.5, QGraphicsView starts to be very usable also in N810 and one just needs to know tips & tricks how to utilize it efficiently. Below is the same carousel widget in N810, using the "raster" graphics backend:
FPS up there means how many times QGraphicsView paintEvent() is called, so it drops when more drawing to view is needed, but stays quite healthy & usable anyway. Back to coding!
Special thanks for graphics used goes to:
- Background: Tribe, by Alexander Timonov
- Icons: Kreski-Lines, by Holger Bauer
I need to still continue experimenting how to really extend the animation classes and use the whole state machine framework, but so far I'm impressed by the latest 2.2 API version. Originally my biggest concern about this whole "Kinetic" was that it would be too high-level and have suboptimal performance in embedded devices, but luckily that doesn't seem to be the case. Now with Qt 4.5, QGraphicsView starts to be very usable also in N810 and one just needs to know tips & tricks how to utilize it efficiently. Below is the same carousel widget in N810, using the "raster" graphics backend:
FPS up there means how many times QGraphicsView paintEvent() is called, so it drops when more drawing to view is needed, but stays quite healthy & usable anyway. Back to coding!
Special thanks for graphics used goes to:
- Background: Tribe, by Alexander Timonov
- Icons: Kreski-Lines, by Holger Bauer
The Qt widget contest results have been announced and although segway slipped away this time, we got our 15s of fame with AnalogPad!
But what I want to share here is the story behind our entry:
- Most importantly: Although only my name is mentioned there, it was full teamwork with my brother Kim "The Webkit" Grönholm!
- All started when I got backflash about the competition due after christmas and decided to hack 5-way analog navigator
- I designed and implemented the thing for 2 evenings, it started to look OK but behaved badly...
- Kimi offered to join the fun, although he happened to be in Korea(!) at the same time
- So last 3 days before the due, I spent my evenings with this, sent sources to Kimi and received fresh code for next evening
- I implemented mostly features, Kimi fixed them to work nicely and cleaned the code. Time difference between Finland and Korea didn't matter, it just added extra coolness into this co-operation as we worked kinda in two shifts!
And the rest is history... Project is now in Github and sources are GPLv3, so fork away!
Here is our teamwork results for Qt Software "Pimp My Widgets" Developer Contest:
Hacking was fun as always! Telling more about this later, but now: Happy New Year for you all!!!
Hacking was fun as always! Telling more about this later, but now: Happy New Year for you all!!!
Realized last week that what I need (or want, luckily those match quite nicely these days) to do is a virtual keyboard prototype based on Qt... Got the basic UI in there during the weekend, so what we have now:
Works also in N810 but the performance is lacking, it's not totally fluid.
Plans:
- Have to figure out proper layout(s), wouldn't want to copy directly e.g. from iPhone or N810
- Support gestures and other usability tricks
- After this, make more eye candy, animations etc. Not too much, but to help usability
- Supporting word prediction and hit prediction is totally doable but would need more AI & grammar database integration, so not right now for this UI testing
Anyway: If you got good layout & feature ideas, please share!
Works also in N810 but the performance is lacking, it's not totally fluid.
Plans:
- Have to figure out proper layout(s), wouldn't want to copy directly e.g. from iPhone or N810
- Support gestures and other usability tricks
- After this, make more eye candy, animations etc. Not too much, but to help usability
- Supporting word prediction and hit prediction is totally doable but would need more AI & grammar database integration, so not right now for this UI testing
Anyway: If you got good layout & feature ideas, please share!
I was in Brisbane this week, meeting Tro..Nokia Qt / Qt Extended developers. Weather was kinda variable: Tuesday morning started as very nice and sunny, but before evening it was raining and thundering heavily... Not that there would have been time to enjoy fresh air anyway, we spent it pretty efficiently in office.
Personal outcome of the trip was:
Special thanks goes to Aaron, for good discussions and for having similar UI thoughts as yours truly. Hopefully there is more time to spend next time!
Personal outcome of the trip was:
- Qt (Extended) 4.5 will rock! (Note: first technology preview was just released)
- Future Qt versions will rock even more ;-)
Special thanks goes to Aaron, for good discussions and for having similar UI thoughts as yours truly. Hopefully there is more time to spend next time!
During the weekend I tested briefly QEdje 0.3.0, here are my thoughts:
I have to study some more Edje format and whether QZion is already providing "enough" features for it, please comment if I have missed something obvious here.
- QZion canvas which is used for graphics rendering in QEdje has two implementations: QPainter based and QGraphicsView based, former being currently faster in embedded environments lacking FPU power. QZion API is still very light, containing basic canvas objects (rectangle, image, text) with under 2kLOC / implementation.
- QEdje is the real beef, containing parser for Edje theme files. What I like about Edje format is that it's not based on XML and it still gets compiled into binary mode when deploying, which should minimize the theming performance hit. I tested now only with provided samples, have to check how QEdje handles more complicated Edje themes.
- Thinking why Edje, Evas, E17 etc. haven't become more popular, is the reason technical, just (lack of) community or what?
- My ideas for QEdje developers would be to concentrate more on QGraphicsView backend as it offers more features and should get nice boost with performance improvements in Qt 4.5. Think if inheriting QGraphicsWidgets as QZion objects would offer more than current QGraphicsItems, like layouts and native QWidgets with QGraphicsProxyWidget. IMO Clutter API is currently a good compromize between features and simplicity, so analyze it and copy all suitable ideas into QZion ;-)
I have to study some more Edje format and whether QZion is already providing "enough" features for it, please comment if I have missed something obvious here.