Ariya called on who is going to turn the web-based google talk client to a plasmoid, so here i am 🙂
Let’s try with the javascript api:
layout = new LinearLayout(plasmoid); webView = new WebView(); webView.url = "http://talkgadget.google.com/talkgadget/m"; layout.addItem(webView);
And the result is:
You can download it here (warning: trunk required).
The Twitter Microblogging widget is a really useful tiny little utility, unfortunately until now it had severe appearance problems, especially when resizing the thing it did happen that contents could overflow from the applet boundaries.
This was partly due to some problems Qt 4.4 had with QGraphicsLayouts partly to our workarounds to those problems.
In Plasma we’re the childs with the slingshot that terribly enjoy to break stuff, the Qt components that Plasma uses, the QGraphicsView related stuff is a part significantly younger than the other parts of Qt, and we are putting it on a really tough stress test and this, even tough painful at start, it makes the framework mature at a really fast pace.
Now, i’m really impressed with the quantity of bugfixes present in Qt 4.5, so i decided to give the microblogging plasmoid another little quantity of love, and this is the result:
So now the height of individual posts grows and shrinks depending on the text layout inside them and when the size of contents is bigger than the size of the widget it shows (or hides) scrollbars as needed (it’s also kinda touchscreen friendly since it can scroll by dragging the contents themselves). So now works more as it is expected to from day one, that wouldn’t be breaking news per-se, but it demonstrates that the stuff we were uber-early adopters it’s really coming together and show what its real potential was.
What’s more important is that not only the microblogging widget works better now, but it’s also easy to write a new widget like that, since the process produced two new widgets in libplasma (widgets not in the sense of plasmoids, yeah i know it’s confusing:): TextBrowser to be used every time you have to display formatted text simple enough to not require Webkit. The other one is ScrollWidget, where you simply slap another widget in it ant it will automatically decide when cut away a part of the contents and when to show the scrollbars or not.
As I was showing here now Plasma in trunk can also play video/audio files, so what will be there in KDE 4.3? Basically two components:
The first is a media player widget (or applet, or whatever…). It will be the basis for a future media center written totally with Plasma technologies (one of the exciting discussions we had at Tokamak2 🙂 as today it’s in playground and plays video files dropped in plasma, can open arbitrary audio/video files, has some usual control buttons and exposes the standard org.mpris D-bus interface used to control media applications, can be controlled for instance from the now playing widget, as shown here.
The most central component is in libplasma right now and instead is well, a media player widget :p
The difference is that it is a widget in the sense of reusable control to be used in the applets/widgets/plasmoids you write (so, wanna for instance make a youtube browser?:), it uses various components of Phonon, like Videowidget, MediaObject and AudioOutput and has a default set of control buttons that do a nice slide in/slide out on mouse over, and the reallt cool thing is that using it from the javascript bindings is ridicolously easy.
This is a complete plasmoid written in javascript in the minboggling amount of 6 lines of code:
layout = new LinearLayout(plasmoid); video = new VideoWidget(); video.usedControls = DefaultControls; layout.addItem(video); video.url = startupArguments[0]; video.play();
All it does in sequence is: make a layout, make a video widget, enable a default set of buttons, add the widget in the layout, load the argument as the video if any (i.e, the file that was dag and dropped on the desktop), and finally, play.
This thing is in kdebase in the tests folder of the javascript based plasmoids.
Now, switching for a moment in hype-machine mode, think about putting together media content distribution, javascript, plasma, browsers and the not really happy state of these things in Linux right now, really far fetched for now and not for the immediate future, but good things can happen 😀
Yesterday talks were wicked interesting, especially the Alexis talk about the new animation framework was really breathtaking.
Aaanyways, this is kinda a synopsis of what i talked about in my part during
the talk session yesterday at Tokamak, slides
here,
it’s quickly written in few minutes, so the english it’s a total horror,
but i feel it could be kinda interesting anyways 🙂
Pretty much everything you see in Plasma is based on SVG graphics,
this means that you have a really high degree of customizability
controlled by the Plasma theme. This also means that compared to
classical Qt themes the entry barrier is significantly lower, because
of course you have to be a good designer to make one, but not a
programmer, while to do a Qt theme you have to be both and this is a
really really rare thing.
Also, since themes are pure graphics without binary code they are
completely platform independent so they can be distributed trough the
GHNS framework.
Being vector graphics, we can display them without problem from
very little screen to huge monsters when we will have 600dpi screens
that won’t be a problem, specially for the theme elements based on
the FrameSvg concept.
From a programmer point of view using the theme graphics is quite
easy too, because the two main classes that manages Svg themes (Svg
and FrameSvg) are very abstracted, so you won’t have to bother that
the graphics is actually a Svg.
Plasma themes will be installed under your KDE installation prefix
under share/apps/desktopthemes. The filesystem structure inside the
theme has got two main subfolders: widgets, meant for element
drawn on canvas and dialogs, meant for elements that are
actually a top level window. There are two particular and optional
subfolders: the first is locolor, that will have the same two
widgets and dialogs subfolders meant to be used when the theme is
displayed on screens with less than 16 bit color depth.
The other folder is called opaque and has replacements for
the elements that are a top level widget when the desktop effects are
turned off, that’s because in this case we won’t be able to have a
semitransparent window, so we won’t be able to have luxuries like
antialiased borders or drop shadows, if you have a rounded border
there you should use the good old pixelart tecnique from the 80’s.
In order to load an Svg from the current theme is sufficient to
use the setImagePath() function of Plasma::Svg, where you don’t have
to worry neither of the path of the theme or the svg or svgz
extension, so something like “widgets/background” will suffice.
If you are writing a scripted applet you can also include the
graphics alongside the applet code and distribute everything in a
single package, from a javascript applet for instance it will be
sufficient to call the function plasmoid.findSvg(“foo”) and the
proper foo.svg file will be located for you.
That said however now i have to get a bit annoying with some
advices: you should be really really careful when you add custom
graphics in your applet, both when you install it alongside your c++
applet and also when you embed it in the package of your scripted
applet, because your additional graphics must work with as much
themes as possible, and this is an hell lot difficult. You should at
least try it with both a dark and a light theme, but in the end… if
you want to do that, think again 🙂
Usually in your applet won’t have to directly paint Svgs, because
if you just use the default plasma widgets you’ll have the svg
painting done for you, but if you have to draw some svg elements you
have to know two classes: Plasma::Svg and Plasma::FrameSvg.
The mighty machine that manages all the svg painting in Plasma is
the Plasma::svg class, that internally uses the QSvgRenderer class,
but optimizes it as much as possible: in the context of the whole
Plasma application for each svg file we get an unique shared svg
renderer and the rendering result is saved to disk thanks to a
KPixmapCache, that can avoid the creation of renderer to a satisfatry
degree: in the second plasma start won’t be created a single renderer
until you resize something, saving a bit of startup time and some
megs of ram.
The most important functions you are interested if you want to use
a Svg are its several paint functions (overloaded with QPoints or
QRects as parameters) the already mentioned setImagePath() resize()
and various functions to access the svg sub elements like
hasElement(), elementSize() and elementRect().
The other class used in plasma to render Svgs works at a slightly
higher level of abstraction and is Plasma::FrameSvg. Usually widgets
are mostly rectangular things, but even if Svg is scalable that
doesn’t mean the result will look pretty, take a look at the slides
example for instance, where a
default applet background is heavily vertically stretched, so the
horizontal borders become thicker that the vertical ones, and to make
things worse they usually aren’t even an integer number of pixels
making the result to look really blurred.
So, what is there in the default applet background? We can see
there are actually 9 pieces: the corners, the edges and the central
part (called with a great stretch of fantasy center, top, topleft,
topright, left,right,bottom, bottomright and bottomleft). When the
thing will get painted not all elements will be scaled, it’s
important that the corners won’t be never ever scaled, while the
horizontal edges will be scaled only horizontally and similarly the
vertical edges will be scaled only vertically, while the center
element will scale freely.
From a boring code standpoint FrameSvg inherit the Svg class, so
all the stuff that is available in Svg is available in FrameSvg too,
but with the difference that you want to resize the image with
resizeFrame() that uses the method i talked before and you’ll paint
the correctly resize Svg with paintFrame(), while paint() is still
useful to paint single elements in the Svg. Also a single Svg can
contain multiple series of 9 elements, with the names differentiated
by a proper prefix, that can be chosen with the setElementPrefix()
function.
KDE 4.2 has just been released, after many months of hard work by many people.
In this release the huge potentiality of the 4.0 platform is finally going to show up in the end user visible apps, so it’s where the good plans are starting to come together.
/me did just a tiny part, but nevertheless i like considering myself part of that wonderful community, they are wonderful people, congratulations to each one 😀
This is a tiny plasmoid hacked on a boring sunday afternoon in about 20 mins, perhaps a too silly name but i think the effect is kinda fun 🙂
It’s an on-screen magnifying glass with the difference from the usual ones that it doesn’t actually grab the screen, but it just views the Plasma canvas (just another view on the scene, that is), that gives some peculiarities, shown in this video:
All the windows are totally transparent to it, so while is useful to view/magnify just what there is on desktop it can give a quick access on it, when you need both your windows and stuff on desktop (think about a non-fullscreen dashboard, and then think about drag and drop between dolphin and folderview even when you have a maximized window :P)
And the more cute thing is due to the vector nature of the QGraphicsView, you see all the proper vector-based elements like the text to be smoothly scaled and still looking like text, not that usual pixelated/blurry mess that kinda hinders the utility of screen magnifiers as accessibility applications.
It’s amazing what it’s possible to do in plasma with a really limited amount of lines of code (here about 100, perhaps 20 or so could even still be saved:)
The thing now lives in playground and is still really rough, so not definitely 4.2 material, but who feels like can give it a try anyways:)
This looks more like a tweet, but just Merry Christmas people 😀
After many many years, way more of what i would have liked to, today i finished the university, with the defense on my thesis (a weirdo thing about ontologies describing European directives, a PHP+postgresql monster i’m quite proud about after all).
Now even if i will probably continue working in the uni for a (hope not too long) while, it’s really a weeeird sensation knowing that something that took over a quite big chunk of my life it’s actually over.
I hope to be able to continue to hang around and hack on plasma as much as i can, as i feel in the last year KDE became a quite positive part of my life that i’m very happy about 🙂
As long as I will still work for the university it won’t change that much, since i will continue to do pretty much the same thing, and after that, bah, who knows, but for now i don’t want to think about that, just be happy for a bit :p
After seeing total coolness like this and this, i of course decided that Plasma couldn’t lag behind that total ratio of awesomeness.
This is an idea from right the begin of Plasma (we always had the MediaCenter formfactor impatiently waiting to be actually used after all:)
At the begin a thing like what I did today was not possible for two reasons: throwing qwidgets on canvas is possible only from Qt 4.4 and before Phonon was not able to render over widgets. In fact the first version of the Amarok video applet had to embed a window in the applet with the video in, so no correct z ordering, no transforms etc.. but now the good plan come together and is possible to render video even on the walls of a wolfenstein 3d maze (hats off to Matthias Kretz) 😀
The cutie in this video is a plasma applet that embeds a video, it uses the X-Plasma-DropMimeTypes directive in its desktop file, so it’s sufficient to drop a video file on the desktop and the applet is automagically created.
This applet that lives in playground is highly experimental: no config options, no audio, no seeking, just bare working.
But it’s just the beginning, for 4.3 there will be a generic widget usable with few lines of code (even scripted of course) and a basic applet. Yeah i know, 4.2 is still far and the 4.3 teasing is started already, we are soo evil :p
Plasma always had this really cute concept of “formfactor”: in brief different areas where plasmoids can reside have different behaviours, for instance a desktop is planar, i.e. the applets can grow anywhere they want.
The panel on the other hand can have a vertical or horizontal form factor, it means the applets in it can grow only in the vertical or horizontal direction, so an applet with a high quantity of content can’t display everything it would want…
In past releases of KDE4 the right behaviour of applets was still not really finished, so some applets like the device notifier were more kind to the panel, displaying the whole device list on the desktop and an icon+popup on the panel, other applets like the twitter applet hmm not soo good 🙂
Now with KDE 4.2 every standard applet distributed with kdewill fully use the form factor concept, so far we have 3 different classes of applets:
Applets that are just the same or with very little differences in different form factors, like simple icons or the taskbar.
Applets that diminishes their information quantity in horizontal or vertical form factors, here are two examples:
when in the panel the now playing applet just displays the control buttons, and the leave note applet switches to an horizontal layout, so it makes enough room for an horizontal panel.
Some other applets, like the device notifier or kickoff wouldn’t mean that much without some of its contents, so in the panel will be an icon+popup and in the desktop the whole plasmoid will be shown. but what about very big panels, so big that the whole plasmoid could fit and a ginormous icon wouldn’t make so much sense?
When the applet knows that it would fit into the panel, the icon goes away and the whole applet content is displayed, and goes back to an icon when the panel is shrinked again.
Now, since Plasma in KDE 4.2 supports also panels not always on top and autohide panels, you could have for instance a thing that looks like a Quake console with plasmoids in it, just like Konsole for terminals 🙂