{"id":724,"date":"2009-02-07T12:00:20","date_gmt":"2009-02-07T12:00:20","guid":{"rendered":"http:\/\/www.notmart.org\/index.php\/BlaBla\/TokaTalks"},"modified":"2009-02-07T12:00:20","modified_gmt":"2009-02-07T12:00:20","slug":"tokatalks","status":"publish","type":"post","link":"https:\/\/notmart.org\/blog\/2009\/02\/tokatalks\/","title":{"rendered":"TokaTalks"},"content":{"rendered":"

Yesterday talks were wicked interesting, especially the Alexis talk about the new animation framework was really breathtaking.
\nAaanyways, this is kinda a synopsis of what i talked about in my part during
\nthe talk session yesterday at Tokamak, slides
\nhere<\/a>,
\nit’s quickly written in few minutes, so the english it’s a total horror,
\nbut i feel it could be kinda interesting anyways \ud83d\ude42<\/p>\n

Themes<\/h2>\n

Pretty much everything you see in Plasma is based on SVG graphics,
\nthis means that you have a really high degree of customizability
\ncontrolled by the Plasma theme. This also means that compared to
\nclassical Qt themes the entry barrier is significantly lower, because
\nof course you have to be a good designer to make one, but not a
\nprogrammer, while to do a Qt theme you have to be both and this is a
\nreally really rare thing.<\/p>\n

Also, since themes are pure graphics without binary code they are
\ncompletely platform independent so they can be distributed trough the
\nGHNS framework.<\/p>\n

Being vector graphics, we can display them without problem from
\nvery little screen to huge monsters when we will have 600dpi screens
\nthat won’t be a problem, specially for the theme elements based on
\nthe FrameSvg concept.<\/p>\n

From a programmer point of view using the theme graphics is quite
\neasy too, because the two main classes that manages Svg themes (Svg
\nand FrameSvg) are very abstracted, so you won’t have to bother that
\nthe graphics is actually a Svg.<\/p>\n

Plasma themes will be installed under your KDE installation prefix
\n under share\/apps\/desktopthemes. The filesystem structure inside the
\ntheme has got two main subfolders: widgets<\/em>, meant for element
\ndrawn on canvas and dialogs<\/em>, meant for elements that are
\nactually a top level window. There are two particular and optional
\nsubfolders: the first is locolor<\/em>, that will have the same two
\nwidgets and dialogs subfolders meant to be used when the theme is
\ndisplayed on screens with less than 16 bit color depth.<\/p>\n

The other folder is called opaque<\/em> and has replacements for
\nthe elements that are a top level widget when the desktop effects are
\nturned off, that’s because in this case we won’t be able to have a
\nsemitransparent window, so we won’t be able to have luxuries like
\nantialiased borders or drop shadows, if you have a rounded border
\nthere you should use the good old pixelart tecnique from the 80’s.<\/p>\n

In order to load an Svg from the current theme is sufficient to
\nuse the setImagePath() function of Plasma::Svg, where you don’t have
\nto worry neither of the path of the theme or the svg or svgz
\nextension, so something like “widgets\/background” will suffice.<\/p>\n

If you are writing a scripted applet you can also include the
\ngraphics alongside the applet code and distribute everything in a
\nsingle package, from a javascript applet for instance it will be
\nsufficient to call the function plasmoid.findSvg(“foo”) and the
\nproper foo.svg file will be located for you.<\/p>\n

That said however now i have to get a bit annoying with some
\nadvices: you should be really really careful when you add custom
\ngraphics in your applet, both when you install it alongside your c++
\napplet and also when you embed it in the package of your scripted
\napplet, because your additional graphics must work with as much
\nthemes as possible, and this is an hell lot difficult. You should at
\nleast try it with both a dark and a light theme, but in the end… if
\nyou want to do that, think again \ud83d\ude42<\/p>\n

Boring implementation details<\/h3>\n

Usually in your applet won’t have to directly paint Svgs, because
\nif you just use the default plasma widgets you’ll have the svg
\npainting done for you, but if you have to draw some svg elements you
\nhave to know two classes: Plasma::Svg and Plasma::FrameSvg.<\/p>\n

The mighty machine that manages all the svg painting in Plasma is
\nthe Plasma::svg class, that internally uses the QSvgRenderer class,
\nbut optimizes it as much as possible: in the context of the whole
\nPlasma application for each svg file we get an unique shared svg
\nrenderer and the rendering result is saved to disk thanks to a
\nKPixmapCache, that can avoid the creation of renderer to a satisfatry
\ndegree: in the second plasma start won’t be created a single renderer
\nuntil you resize something, saving a bit of startup time and some
\nmegs of ram.<\/p>\n

The most important functions you are interested if you want to use
\na Svg are its several paint functions (overloaded with QPoints or
\nQRects as parameters) the already mentioned setImagePath() resize()
\nand various functions to access the svg sub elements like
\nhasElement(), elementSize() and elementRect().<\/p>\n

The other class used in plasma to render Svgs works at a slightly
\nhigher level of abstraction and is Plasma::FrameSvg. Usually widgets
\nare mostly rectangular things, but even if Svg is scalable that
\ndoesn’t mean the result will look pretty, take a look at the slides
\nexample for instance, where a
\ndefault applet background is heavily vertically stretched, so the
\nhorizontal borders become thicker that the vertical ones, and to make
\nthings worse they usually aren’t even an integer number of pixels
\nmaking the result to look really blurred.<\/p>\n

So, what is there in the default applet background? We can see
\nthere are actually 9 pieces: the corners, the edges and the central
\npart (called with a great stretch of fantasy center, top, topleft,
\ntopright, left,right,bottom, bottomright and bottomleft). When the
\nthing will get painted not all elements will be scaled, it’s
\nimportant that the corners won’t be never ever scaled, while the
\nhorizontal edges will be scaled only horizontally and similarly the
\nvertical edges will be scaled only vertically, while the center
\nelement will scale freely.<\/p>\n

From a boring code standpoint FrameSvg inherit the Svg class, so
\nall the stuff that is available in Svg is available in FrameSvg too,
\nbut with the difference that you want to resize the image with
\nresizeFrame() that uses the method i talked before and you’ll paint
\nthe correctly resize Svg with paintFrame(), while paint() is still
\nuseful to paint single elements in the Svg. Also a single Svg can
\ncontain multiple series of 9 elements, with the names differentiated
\nby a proper prefix, that can be chosen with the setElementPrefix()
\nfunction.<\/p>\n","protected":false},"excerpt":{"rendered":"

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 […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[2,10,21,40,64],"class_list":["post-724","post","type-post","status-publish","format-standard","hentry","category-blabla","tag-kde","tag-kde4","tag-linux","tag-real-life","tag-tokamak"],"_links":{"self":[{"href":"https:\/\/notmart.org\/blog\/wp-json\/wp\/v2\/posts\/724","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/notmart.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/notmart.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/notmart.org\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/notmart.org\/blog\/wp-json\/wp\/v2\/comments?post=724"}],"version-history":[{"count":0,"href":"https:\/\/notmart.org\/blog\/wp-json\/wp\/v2\/posts\/724\/revisions"}],"wp:attachment":[{"href":"https:\/\/notmart.org\/blog\/wp-json\/wp\/v2\/media?parent=724"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/notmart.org\/blog\/wp-json\/wp\/v2\/categories?post=724"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/notmart.org\/blog\/wp-json\/wp\/v2\/tags?post=724"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}