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.
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.
KDE SC and Plasma:why?
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.
What do you want?
Why Plasma can be good on a netbook, on a mediacenter, on a mobile phone?
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
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.
Developers
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).
So, what about the netbook again?
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.
Search and Launch
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.
Netbook: Newspaper
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.
Future
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:
Why netbooks need something different?
Why KDE SC is a good platform on non desktop devices?
What Plasma has to offer there?
What has to offer to users?
What about toys for developers?
What are the components of the Netbook shell and why they are designed the way they are?
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:
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 🙂
Why on some netbooks it runs slow
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.
The actual how to
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:
plasma-netbook -graphicssystem raster
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
~/.kde/share/config/plasma-netbookrc (in some distributions could be ~/.kde4 instead)
And add the following line:
GraphicsSystem=raster
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.
So there is hope for the future?
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
plasma-netbook --opengl
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.
Those days, working hard on bugfixing and polishing for the 4.5 SC release, however caught by the impatience of testing the new shiny features that will be in Qt 4.7, I gave a try on a weird crossover you’ll hear more and more about in the future: QtQuick+Plasma
Now, in playground there are some Plasma bindings for QML almost since the declarative module was announced, but only lately, as it matures for Qt 4.7 inclusion has been possible to expand them to make possible to have a quite good integration between the two technologies.
Work started in February at Tokamak 4, were thanks to the beginning of this integration was possible tohave a working prototype of Plasma Mobile in a single week, starting from zero.
As a test bed for expanding the bindings where something more was still needed, I did a prototype of a plasmoid with the interface a bit more complex than usual, that could be easily used as a full screen application in a mobile environment. Since there is another set of KDE applications for wich a mobile version is being written (all the KDE pim apps) i decided to just shamelessy copy from it, since is one where the visual design has been already done.
The video below shows a simple prototype of a mail client for a mobile device: the basic interaction works, even tough the data is dummy, being a simple demo.
It’s written completely in QML, without a single C++ line of code, and can work both as a fullscreen mobile application as shown there as well as a normal Plasma widget in your desktop
A really important charateristic of this (and of the other future Plasma widgets written it this tecnique) is that exept the item view, it only uses Plasma widgets (widgets as in components like buttons, text fields etc) and animations, this will give some interesting benefits:
Consistent look and feel, either across your desktop or in various apps of your mobile device. Even across different kind of devices, like mobile, netbook and desktop, while having a radically different look to fit the different form factors, the applications will bring a certain level of familiarity and “unity”
The widgets have an consistent and rich api, that can be accessed from both Javascript and C++ pieces of code (or whatever language bindings), when a “QML only” approach is not enough.
The Plasma animations are written in Javascript themselves: they can be “themed” to achieve different feelings on different devices without having to touch code in the applications/plasmoids themselves. In the future will also be possible to do important things like turning them off globally when the battery level is critical or things like that.
great separation of data and visualization achieved trough dataenines: is possible to completely change the ui without ever touching the logic of the program or how the data is fetched, and write the visualization completely in a declarative way, while not being limited in any way in how the dataengine plugin is written.
As said before, to recap it will be possile to write plasmoids completely in QML, or include pieces of QML ui in any kind of plasmoid is already possible to write, being C++, Python, Ruby or even our already existing Javascript bindings.
This demo in the video isn’t going to be a real world application, but it is a really good showcase of what Plasma can offer in this regard, and how is easy to write a pretty rich mobile application that can be adapted across a wide range of devices. So in the future there will be many plasmoids that will rougly follow those lines.
Bits and pieces are still missing, some work remains to do, but for KDE SC 4.6 there will be in libplasma something that will be usable by everybody to build some awesome stuff.
So, it was pretty a long time since the last time I blogged about the KDE Plasma Netbook project… what’s going on on that? you wanna videos?, you’ll get videos 🙂
This doesn’t mean it’s stopped. Au contraire my friends, since 4.4, many of its parts were rethought and redesigned. Some of those changes are quite visible at a UI level, some other are more under the hood, but contribute to give to it a more “finished” look and feel to it.
Alongside KDE SC 4.4 the first version of the Netbook Shell was released, and while it was a really big achievement for us it was still at a really early stage: it had to be released (early and often, they say :)) but now things begin to really get serious.
We made a step back and looked at it, asked ourselves where we want it to go and what purpose it will have to serve (in brief: developer sprints are very, very useful :p)
When we started the project Netbooks were a certain defined thing: underpowered device (low price, weight and power consumption), compact size (high portability) and a very targeted use case: they are mostly Internet devices, or a platform to run very simple applications, so more of a secondary machine for casual use rather that a proper laptop.
In the meantime they have changed, they are more near to a laptop, with bigger (but not actually big) screens and almost normal hard drives.
So, they really have changed so much? yes and no. We can’t afford for this reason to be “less careful” to issues like screen size or power consumption, because despite how it could look, they still continue to be quite different beasts compared to laptops.
Computing power issues aren’t going to go away anytime soon, and even if tomorrow morning netbooks will have a resolution of 1920×1080 or 3 times more, 10 inches are going to remain 10 inches: your eyes don’t zoom.
So, what we will see in this area in the future?
More diversification: bigger screen with Atom and smaller screens with ARM (will it actually happen? I hope so)
More original devices: clamshell notebook-like as usual, opposed to tablet form factors: so two totally different types of user interfaces will be needed, right? Well, the world could be more complex (and interesting) that that.
So, there will be more kinds of devices, some of them will be addressed by Plasma Netbook, some of them by Plasma Mobile.
So, after thinking about it for a moment the natural process is to pass from the tough that this was not as different of our every day computing as we thought to the certainly that the challenges that will be faced will be way more than ever thought.
So, let’s not be so far-fetched and let’s see what are the new shiny things that will ship in KDE Plasma Netbook Shell 4.5.
Faster. Several optimizations have been done on the shell itself and on the Search and Launch activity, (alongside the continuous optimization work it is being done in Qt, especially on the QGraphicsView features we put on a pretty tough stress test:)) Now the general usage and feeling should be a lot snappier and responsive.
Search and Launch. It uses a different way to fetch the data used in the menus, so they should be a lot more accurate now.
Moreover, extensive drag and drop support has been added. This makes it more intuitive to use and more friendly on a touch screen device. On the video below you can see it used on a normal netbook, on the usual 800MHz little tablet with Moblin and on a bigger tablet with an 1GHz Via processor (note here the video driver is the plain old vesa but it’s running pretty decently anyways). 3 completely different devices, same UI, of which some elements are starting to translate very well across all three, some of them still not, and here is where the extremely modular architecture of Plasma comes to its full power. just replace the little elements that interaction wise are device specific.
Last but not least you can see there also that many of the layout and behavior rough edges that were previously in the icon view have been solved.
Newspaper. The main information hub of Plasma-netbook, shown in the video below. As all the Plasma “flickable” scroll areas, uses brand new code (by our very best graphics ninja, actually 😉 to handle the touch and the flicking in a much better way.
Now,to improve both the looks and the usability of it, the widgets appear perfectly aligned in a 2×2 grid (it’s still possible to have as many columns and rows as we want by the way). By interacting on a widget, it will expand to take up to the whole screen height, so offering a “maximized” view of it, that reflects the concept that now your attention is on that particular one (so, trascuring for a while the other ones, albeit still reachable)
the page can behave like this or all the widgets can be “maximized” like before, eliminating all the internal scrolling areas leaving only the big external one. this will probably be the preferred behavior on touch screens.
Other than that, there is the quite important addition of javascript support I talked about in the last entry: it will make personalization (by distributors and in the future directly by users as well) very very easy.
This post is of the boring-with code type, but if you are a distribution packager read till the end, it’s important 🙂
As said by Aaron some days ago, now Plasma can be controlled vith Javascript code.
This is useful for creating the default setup, for quicly controlling the desktop look and feel, to handle updates in the configuration files and even for controlling large deployments.
Setup scripts can also be packaged in the same format as the Javascript based plasmoids, so in the future (probably 4.6 timeframe?) will be possible to distribute and downoad setup for actvities, for instance with get hot new stuff.
Now not only the Plasma Desktop is using it: also the netbook has full scripting support, this will make really easy for distributions to customize the default layout as needed.
It loads 3 packages, one for the Search and launch activity, one for the panel and one for the newspaper. The newspaper is:
var page = new Activity("newspaper")
//not shown by default
page.screen = -1
//properties for the wallpaper
page.wallpaperPlugin = 'image'
page.wallpaperMode = 'SingleImage'
//templateName comes from the desktop file of the package,
//and will be translated
page.name = templateName
page.addWidgetAt("news", 0, 0)
page.addWidgetAt("weather", 1, 0)
page.addWidgetAt("opendesktop", 0, 1)
page.addWidgetAt("knowledgebase", 1, 1)
It adds the default widgets, will be possible to distribute and download different pages. The search and launch instead is the following:
var sal = new Activity("sal")
sal.screen = 0
sal.wallpaperPlugin = 'image'
sal.wallpaperMode = 'SingleImage'
sal.name = templateName
sal.writeConfig("PackageManager", "kpackagekit")
sal.reloadConfig()
The PackageManager bit here is particularly important: a new feature of the Search and Launch activity for 4.5 is a new button in the toolbox, called “Add applications” (complementar to the usual “add widgets”) it will launch the gui for the package manager… now, since it’s highly distribution dependent it will have to be customized. Here uses as default “kpackagekit” this is the name of the desktop file of the application, in OpenSuse that line would become for instance sal.writeConfig(“PackageManager”, “package-manager”) and so on
It’s a small little bit, but it’s an important piece to give it a more integrated and easy experience.
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
