After the usual 6 months cycle we made it. KDE Development platform, Plasma Workspace and various applications have reached version 4.5 and have been released. It has been as usual an huge amount of work and sweat, but this is release i think we can be proud of. It’s the point where we see all our little creations reaching maturity, but this is just the beginning.
Work on Plasma Mobile continues.
Bit after bit all the pieces come together: what’s impressing is how much the Plasma framework we have built into years is paying now.
Plasma Mobile still lacked a widget explorer: the particular formfactor really required a custom one since the one used in the desktop has a pretty different usage pattern and is targeted at a really different form factor (here we are targetting -really- small screen sizes).
I was expecting that writing one could take a quite long amount of time, after all getting there the firt time taken a fair amount of work…
I couldn’t have been more wrong. In less than two days I have now a working widget explorer, that works pretty well on small touch screens, using a mix of QML, Plasma Widgets and C++ models
The main interface is a big flicking icon grid, with a side panel that shows detailed informations on the widget (that can be scrolled with the finger as well).
To add a new widget into the screen, just click at the “+” icon positioned where the widget will be. Interaction wise is way simpler than the Plasma Desktop mechanism, because of both precision of the input device (where with device I mean a fat finger :p) and of screen size (where with size i mean actual phisical size, not pixel resolution)
This little video shows it in action on the usual device. ah, and a curiosity, at some point you see the screen switches to an activity with a big numeric keypad.. that’s not a mockup, as Artur announced during Akademy, if it runs on a N900 phone, that can do actual phone calls.
Plasma has a wonderful theming engine, that enables the creation of a really stunning visual appearance, with a great amount of customizability, just look at what is available right now, to not mention that being vector based makes the widget set pretty flexible and able to be used on really different hardware form factors with different sizes and dpi.
But we’re developers and we like to write code, hack on stuff, we often forget to document things, and this is an area that really can get better.
Yesterday I’ve forced myself to look at the quite incomplete and outdate documentation for the Plasma theme system and I’ve looked file by file, element by element and completed and ordered the whole theme.
Now if you have any doubt on the Plasma theme structure, just go to the relevant techbase page, and you’ll find the complete list of every file and every element in every file, updated to the upcoming 4.5 release. this should ease a lot the construction of themes.
It has been a long and painful work, of which developers may really want to avoid it, but it incredibly pays the effort, because it’s a really important part of the elegance we are trying to reach. A complete, pretty and documented framework is what is elegant to a quite relevant part of our audience: developers that are approaching the platform for the first time.
Now we are restructuring the techbase page for Plasma, moving here the pages that makes more sense here, having the two wikis more in focus and comprehensible.
If you are interested, if you are trying to approach the development in Plasma and have difficulties to grok some of the concepts, if you already work on some plasma aspects such as plasmoids, just stop on #plasma on freenode and you can give an hand in the documenting effort, being tutorials, wiki pages or API docs, you’ll learn quite a lot of the internals in the process and will make easier for others to learn.
Sometimes we have to clone ourselves 5 or 6 times to manage to do everything. It’s a kind of magic we rarely succeed, but sometimes we do 🙂
Between Akademy and bugfixes for the SC 4.5 release, I managed to get some work done on the Plasma Mobile front, and a quick video of it can be seen there:
Now there is a new kind of activity for managing widgets there, a new addition to the Desktop (that you normally use on normal computers) and the newspaper (designed for netbooks and big tablets)
This one, that is called mobile desktop, is explicitly tought for very small screens (in phisical size, pixel resolution has nothing to do with size!). It’s based on a big flicking scroll widget, just as the newspaper, because the main method of interaction if a touchscreen, but shows only 2 widgets per screen, (at their minimal size to still make sense)
If you scroll everything around no interaction with the widgets will happen, but if you tap one, it will get maximized, getting a size big enough to be really interacted.
The behaviour of the shell changed a bit as well, since it was quite difficult to hit empty areas to make the whole thing flip, now dragging the panel of the activities, pulls the whole screen, making everything rotate in a 3d way (it has also considerably been optimized for speed)
In the video you can also see the progress of the mobile status indicator summer of code, by Yuen.
Back from 3 days in
This entry was posted in BlaBla and tagged akademy, kde, meego, mobile, real life on .
Memory is starting to be fuzzy already, so, since i promised a blog about the same topics on my talk about the netbook, here it is, mostly because the netbook project (but more important its implications in helping Plasma being ported and be optimized for a long spectrum of devices) has really soft spot in my hearth. We started from the most familiar non-desktop platform: The netbooks, but… Aren’t netbooks just underpowered little laptops? Indeed today are sold like that, with just still XP or Windows 7 preinstalled, but that’s the reason the interest in them is decreased recently. they are just not good general purpose machines. But, they are pretty good as devices that can be used on the move to look at online content such as news, emails or social networks, and ultimately as a communication tool, rather that a content production workstation. We still hear again and again that KDE is to heavy and too bloated to run on any modest hardware. Of course technically the situation can be improved and it will, for instance the platform profiles that are being cooked right now will be able to provide a law fat (as in Kevin words 🙂 you will find information about that in the upcoming future on the planet. n the other hand, complaints are often not completely true, we need better communication about what the advantages of a KDE based solution are, and where the problems are: we pushes the edges of what all the layers of our platform can do, Being Qt, X, or graphics drivers, due to our hard beating the quality of the whole stack is really increasing (and this funningly enough is benefiting non KDE users as well). About Plasma, it’s the primary UI on desktop, can be on completely different devices too? Yes, because the Plasma library was designed with no assumptions on a particular form factor in mind. We started from netbooks to taste the waters, because was the less alien one and because we can provide a rich and complete user experience from day one. Why Plasma can be good on a netbook, on a mediacenter, on a mobile phone? So what users want? they want something useful. Now “useful” can mean different things in different form factors. On a netbook, and even more so on tablets and smartphones, is to be efficient instruments of communication and content fetching, perfect web clients, better than even just a browser. They want to feel in control: the day for instance the facebook interface will change without them being able to choose they will get pissed, with rich clients there is always a slightly bigger degree of choice. They want also something beautiful: between two systems that “just work” they will choose the one they find more aesthetically pleasing, even if it’s not technically the best, it’s irrational but it’s the human nature. They want a powerful framework to build powerful applications as quickly as possible, Plasma offers a series of common components that makes the life of developers as easy as possible. Plasma is heavily based on a strong separation between data and the visualization. Everything in plasma is a plugin the data plugins are Data Everything you see in Plasma is based on Svg, it’s theme engine makes easy to customize a potentially resolution independent widget set while maintaining pixel perfection. Its widget set is based on QGraphicsView, like the other Qt widget sets conceived for the mobile, and is possible to integrate and use it together with them. We have also a flick able scroll widget as well a flick able QtWebkit based one, that is very important, since the future on more and more devices is the touchscreen. Plasmoids (or plasma widget, more generally), everything you see in a Plasma environment is one of those plugins. they can be specific for a certain formfactor, like kickoff or the taskbar, or they can be quite flexible, like the microblogging plasmoid. They are done to work well in the desktop, panel, the netbook newspaper, as standalone little windows invoked from krunner (new from 4.5). First thing:window management: the desktop metaphor doesn’t work very well there… KWin behaves slightly differently there, windows are maximized by default, maximize windows don’t have borders, and the panel is auto hide by default, so quite a lot of pixels are saved for the app The boundary between primary UI and applications becomes blurred when some of the content can be fetched directly from the desktop, so it becomes a normal window like an application. After some usability tests done at Indt last year, what emerged is that Search is more intuitive than browsing trough many items in categories and subcategories. Search and launch uses all the search plugins of KRunner, even if is a completely different UI. There is still a menu, but it’s flat, doesn’t have tree structure, that doesn’t work well on the human brain. Of course uses flicking widgets and has an extensive support of drag and drop, that makes quite convenient to use it a mouse or even a stylus. Also the main widget view for the netbook is based on flicking widgets, this gives an infinite vertical space for our widgets, because the free layout of a desktop isn’t space-efficient enough for a small screen, so a layout that can be “browsed” like exactly an actual newspaper, feels more natural there.
What the future reserves us? We need more widgets, especially PIM related, to make the “newspaper” really useful, a GSoc project is helping in this. Also, the dataengines needs to cache their data for when the network connection is not available, there is a GSoc project working on this too. Last two points, we need to expand on other devices, because I think netbooks won’t stay the way they are today, they will probably not converge with tablets, but for sure be strongly influenced by them, or become something even different. Last but not least, the newspaper concept spawned some unintended at first but really interesting developments: two GSoc projects around Kontact and Skrooge, as well some work on KDevelop to provide a “dashboard” of useful widgets in standard desktop applications. I gave my presentation today at 17:45, it gone pretty well, despite of the Germany argentina match at the same time (Martin’s KWin result plugin helped too eheh 🙂 Those are the slides, i hope to find time to write some more on that I’ll give a talk at Akademy together with Alessandro Diaferia, so the topc can be easily guessable 🙂 We’ll talk about the adaption of Plasma to completely different use cases to its usual dress, that is to be the main user interface of a desktop system. In particular i’ll talk more about the Netbook Shell and Alessandro will talk about the media center project. I’ll leave Alessandro going in more details on the mediacenter, I’ll try instead to answer to some question, some generic, about porting plasma on different devices some specific to the Netbook use case: It will be on Saturday 3 July, 17:45, at the mobile track, stay tuned 😀 Sometimes when times are ready some ideas really want to come up and be used Without calling the examples in the history of science, that is quite a bit exagerated here, in the recent history of computing, at all levels from low level stuff to the UI.
this happened over and over again, because of advancement in hardware that makes something possible, because a certain fraework matured enough, because some projects take inspiration from another one, maybe with changes that may improve over the original one or may get it worse (that’s all about the evolution in nature is btw) or some times they just pop out in the same moment even if one doesn’t really know about each others work. As a result, the evolution follows very similar steps on several quite different platform. I’ve tought about it quite a lot when i seen this video: (no, don’t have other formats since that video isn’t mine) This is a preview video of the user interface intended for the MeeGo distribution to run on tablet devices. The main “primary” UI shows two “pages”, one is a grid of icons with an optional search field that has been seen in several places already, from the very very old mobile devices such as the first Palms to things like The iPhone or the Plasma Netbook Search and Launch interface (where our search functionality is quite more powerful than just searching applications to launch) The second interesting “page” is a space where is possible to have widgets that connects to webservices, list your media files, PIM data etc.. does this ring a bell? This is quite similar to the netbook “Newspaper” ui, there is quite different, instead of being two columns that scrolls vertically, it’s one single row that scrolls horizontally, because when you have only touch as input, it’s indeed a way to use it quite more convenient. Now, what’s interesting, that in prevision of adapting pieces of the netbook ui on devices like tablets, there is an hidden mode in the netbook ui that permits exactly this behaviour. In not suspect times (November 2009) i did shot a screencast that shown also that feature among other things (go to 2:39 to see it): Yes, it’s quite funny to see this video now, since the project came quite a long way in the meantime and so it works way more smootly, but it shows the idea already basically working. In KDE SC 4.5 the newspaper ui as well the other components received quite some love, so now the general usage feels much more smooth, even this hidden just-a-little-experimental feature of the newspaper, so for today I’m leaving you with a brand new video of this kind of interface as is in today’s trunk (and SC 4.5) running on the usual low powered VIA tablet: Oh, almost forgetting, of course: Probably I should had written this little notice uhm, a quite while :), anyways, it’s quite technical but here there are a little hint on how to make the Netbook shell a garzillion times faster, if you’re hit by an unfortunate series of circumstances that makes it run sloooowly 🙂 As shown here, The Plasma Netbook shell can be quite fast on a standard netbook, however many are experiencing it going rather slow. Why? Qt can use different graphics backends to render the graphics, now on X11 systems the default is the one that is called surprisingly enough, X11, that relies heavily on XLib and XRender. Now, this sounds allgreat, but two things tends to happen. If the Xrender acceleration of the video drivers is pretty poor, things tend to slow down. Second, if QPainter hits some code patch that aren’t directly implemented via the X11 graphics system it will have to fall back to another paint system: raster, that is totally software based, so pixmap-to-image conversion (and memory copy) is involved (and is necessary, to not actually lose features depending on what graphics system you’re on), and things slow down. Now, with Intel drivers things seem to not go soo well, especially for items clipping: that’s unfortunately what’s used more heavily in Plasma Netbook 🙂 the newspaper and the search and launch result works as follows: a smaller QGraphicsWidget contains a bigger one, that contains the actual contents that could be the plasmoids of the newspaper for instance. the outer widget has a particular flag that enables clipping, so what overflows from the parent widget won’t be actually drawn. with Intel drivers and the X11 graphics system this seems to be pretty fast until the parent widget is of a certain size, then performance degrades significantly pretty quickly. So the alternative is to use the raster graphicssystem from the start, that is really fast (especially if one think about that is completely software based rendering) there are basically 3 ways to do it: the application can be invoked with the graphicssystem commanline switch, so: But this has to be done every time, or Qt can be configured at build time to use this as default (some distributions such as Gentoo or MeeGo actually do this) but will have the effect on every Qt application. So I’ve added a config file option in Plasma Netbook to use it as default even if Qt has X11 as default: with Plasma Netbook not running, edit the file And add the following line: That’s it 🙂 Here is a video that compares before and after on the usual EeePC 1005ha, with a bright note: the difference isn’t anymore so noticeable like it was used to some months ago, even tough it’s still makes the difference. Two reasons: it’s still quite unstable sometimes, overall with X11 Plasma (and other Kde apps as well) seems to (still) be more stable. But most importat, as said it’s purely software based, so it could be not so gentle on the CPU (so with the battery life). I mean, it’s impressive how much it’s efficient, but will never belike a working gpu based solution. So if you aren’t running on the problem described before, it’s probably better you keep it as is. Absolutely! a still experimental new graphics system is in the works, using this time OpenGL. The whole application (any Qt one actually) can be run completely with OpenGl drawing with the -graphicssystem opengl, or just a QGraphicsView can use it (by using a QGLWidget as viewport). That’s exactly what happens if you start Plasma Netbook with This works in the new born Plasma Mobile too by the way. and is a great hope especially in those two sheels, since GPUs of small devices are designed to be not soo fast, but to be very low power, a bit less than the cpu, actually. Right now, as in KDE SC 4.5 and Qt 4.6/4.7 is still not for everyday use, is still not so stable and there are some graphical glithces (this actually varies from a graphics driver/video card model like crazy) but what is encouraging is that since this feature was introduced (Qt 4.4) it came a very long way, it’s really sooo better than when it was originally out.
More on netbooks, devices and everything
KDE SC and Plasma:why?
What do you want?
because it can give people what they want, both to users that actually get to use it and developers, that want to create the most wonderful application in the world with it.Users
Developers
So, what about the netbook again?
Search and Launch
Netbook: Newspaper
Future
Akademy talk: Slides on the Plasma Netbook project
Akademy talk: The KDE Plasma device spectrum: netbooks and mediacenters
Converging minds
Netbook and performance
Why on some netbooks it runs slow
The actual how to
plasma-netbook -graphicssystem raster
~/.kde/share/config/plasma-netbookrc (in some distributions could be ~/.kde4 instead)
GraphicsSystem=raster
Why isn’t the default?
So there is hope for the future?
plasma-netbook --opengl