Planet KDE

Syndicate content
Planet KDE -
Updated: 1 hour 3 min ago

Marble Maps forking for SailfishOS

Wed, 2015-11-25 14:39

Marble, the swiss army knife for maps and globes, developed in the KDE community, this year has got an app variant added that is concentrating on maps and that is designed for today’s typical mobile devices with touch UI, called Marble Maps. It currently is in Beta state. Read “Announcing Marble Maps for Android Open Beta” for more info.

At this year’s Randa meeting for a few days I joined the people working on having KDE software run on Android. After all there are gazillions of such systems out there, and it only makes sense to have existing FLOS software, such as KDE ones, also run there, as a matter of dealing with realities. With the developers of Marble, KAlgebra and GCompris around, some experience could be shared, and I compiled what I learned into a small Hello KWorld example.

As a Marble fanboy, Marble Maps was my obvious toy project here when learning more about building Qt5-based software for Android. I had no Android device available, but a Jolla phone with SailfishOS. That one also has support for running Android apps, so I still could use it to test my self-built Marble Maps Android packages.

Now, it felt strange to run a Qt5-based application via Android emulation layer on an OS like SailfishOS which itself is using Qt5 and then some usual “Linux” software stack/middleware. Should it not simply run directly there?

So last week finally I gave it a try to build and to run Marble Maps natively on SailfishOS. And was presented with a problem: SailfishOS in the latest version is (still) at Qt 5.2 (with QML upgraded to 5.3 it seems) and, more important, has no QtQuick Controls. Which are used in Marble Maps for all controls. At least all the Marble C++ code was building fine after 2 small fixes, so that part was looking promising.

An option might have been to build a custom version of QtQuick Controls. But that somehow smelled like problems waiting. And I also was tempted to try to do some native UX to gather more experience with QtQuick and the SailfishOS ideas. So I forked the Marble Maps code and started to write a SailfishOS variant, using its Silica UI components. The code for Marble Maps is mainly the UI layer one, written in QML, with the actual business logic nicely in the shared Marble libs and components, so it is not that much logic which is duplicated here. Still it is not “Write once and run everywhere”. It’s up for discussion how much native multi-platform apps should go. For now I will play more with it.

Right now Marble Maps for SailfishOS almost has all current features of the “normal” Marble Maps implemented, modulo some small bugs:

These days sadly many people hearing “marble” and “sailfishos” might rather think of “tombstone”, bad timing here. But until that OS is pushing up the water lilies I will play more with it, after all I can use the code on a working device of mine.

If you want to use the code on a device of yours, find first RPMs on and the code in branch “sfos” in my Marble repo clone, see src/apps/marble-maps-sailfishos/ for the app code. Once it’s stable enough the code will be proposed for inclusion in the official Marble repo.

Also looking forward to see the “normal” Marble Maps and other Marble-based apps soon on Plasma Mobile hopefully.
And anyone looking into an Ubuntu Touch version? Would that work with stock Marble Maps, thanks to QtQuick Controls, or would more native UX be needed there as well?

Categories: FLOSS Project Planets

Area51 updates (KDE on FreeBSD)

Wed, 2015-11-25 07:59

The area51 repository continues to update, even as the official ports tree for FreeBSD sticks with KDE4. Since the KDE-FreeBSD team is also responsible for the official ports, that basically means that not everything has been shaken out yet, and that the team doesn’t feel that it can provide a really good Frameworks5 / Plasma5 / Applications installation .. yet. I’ve been playing with ideas for a default desktop wallpaper (the upstream default gives me a headache; I’d really like to combine Flying Konqui by Timothée Giet with bubbles made from the BSD logo.

That said, Plasma5 and some Applications work very nicely on FreeBSD. They also produce plenty of .core files, so it’s not all wonderful, but it’s a usable desktop by all means (and of course, all your KDE4 and GNOME applications continue to work). I tried to install a Qt5-only (+Frameworks, of course) desktop and discovered a long-standing bug in gsettings, as well.

The KDevelop-KF5 beta is available as a port from area51 as well. There’s an interesting potential bug there, too: it uses LLVM 3.5 libraries while the Mesa libraries use LLVM 3.6 in the software renderer. So if you have a machine without hardware GL, you can end up with two LLVM libraries runtime-linked into an application, which means crashy-time. This is the first time that upgrading my graphics card has fixed my IDE.

Categories: FLOSS Project Planets

Krita 2.9 Animation Edition Beta released!

Wed, 2015-11-25 01:18

Today we are happy to announce the long awaited beta-version of Krita with Animation and Instant Preview support! Based on Krita 2.9, you can now try out the implementation of the big 2015 kickstarter features!

What’s new in this version? From the user point of view Krita didn’t change much. There are three new dockers: Animation, Timeline and Onion Skins, which let you control everything about your animation frames and one new menu item View->Instant Preview Mode (previously known as Level of Detail) allowing painting on huge canvases. For both features, you need a system that supports OpenGL 3.0 or higher.

For people who previously installed Krita, to get Instant Preview to show up on the view menu, delete the krita.rc(not kritarc) file in your resource folder(which can be accessed quickly via Settings->Manage Resources->Open Resource Folder) and restart Krita. Or just use the hotkey Shift+L.

But under these visually tiny changes hides a heap of work done to the Krita kernel code. We almost rewritten it to allow most of the rendering processes run in the background. So now all animated frames and view cache planes are calculated in the moments of time when the user is idle (thinks, or chooses a new awesome brush). Thanks to these changes now it is possible to efficiently work with huge images and play a sequence of complex multi-layered frames in real time (the frames are recalculated in the background and are uploaded to you GPU directly from the cache).

So, finally, welcome Krita 2.9 Animation Edition Beta! (Note the version number! The final release will be based on Krita 3.0, this version is created from the 2.9 stable release, but it is still beta. We welcome your feedback!

Video tutorial from Timothee Giet:

A short video introduction into Krita animation features is available here.

Packages for Ubuntu:

You can get them through Krita Lime repositories. Just choose ‘krita-animation-testing’ package:

sudo add-apt-repository ppa:dimula73/krita sudo apt-get update sudo apt-get install krita-animation-testing Packages for Windows:

Two packages are available: 64-bit, 32-bit:

You can download the zip files and just unpack them, for instance on your desktop and run. You might get a warning that the Visual Studio 2012 Runtime DLL is missing: you can download the missing dll here. You do not need to uninstall any other version of Krita before giving these packages a try!

User manuals and tutorials:
Categories: FLOSS Project Planets

A clockwork carrot

Tue, 2015-11-24 17:32

This weekend I had the opportunity to travel to the yearly LiMux sprint to spend some time with my fellow kubuntu devs and talk about the potential issues we’re facing with the CI system and improving the Debian CI system to be more robust.

Some of the more important issues that were discussed included figuring out a way to improve file tracking in packages, so that the CI can detect file conflicts without having to actually install all the packages. Another important topic that was bought up was using the packagekit and appstream with Muon. This is apparently being held back on account of Ubuntu Touch, but is slated to be resolved soon. Once the necessary packagekit packages are updated, we can play around with the idea of perhaps shipping a muon using the packagekit backend on the next Kubuntu release.

As usual, the LiMux folks are a great bunch to hang out with, and I happened to notice something on the wall of their office while lunching with them. It was a clock. Not just a regular clock though, a timey wimey clock. I’ll let a picture do more of the talking here :


Timey Wimey clock


Told you. Timey Wimey.

I got quite the headache looking at the clock, but my fascination with it stuck. So once I was back home, I hacked up the regular Plasma 5 analog clock and made it timey-wimey too ;)

You can download and install the clock from here. Clocks and Carrots, a weekend well spent I say. As usual, you can find me and the other kubuntu devs in #kubuntu-devel on IRC or on in case you want to reach out to us about Kubuntu, Clocks or Carrots.

Categories: FLOSS Project Planets

Krita 2.9 Animation Edition beta

Tue, 2015-11-24 16:23

I’m very happy to tell you, finally, a version of Krita supporting basic animation features is released ! (Check it here)

This is still in early stage, based on latest 2.9 version, with lot of additional features to come later from version 3.

If you want to have fun with it, here is a little introduction tutorial to get started, with some text and a video to illustrate it.

-Load the animation workspace to quickly activate the timeline and animation dockers.

-The timeline only has the selected layer. To keep a layer always visible on it, click on the plus icon and select the corresponding option (Show in timeline to keep the selected layer, or Add existing layer and select one in the list …)

-To make a layer animated, create a new frame on it (with the right-click option on the timeline, or with the button on the animation docker). Now the icon to activate the onion skins on it becomes visible (the light bulb icon), activate it to can see previous and next frames.

-The content of a frame is visible in the next frames until you create a new one.

-After drawing the first frame, go further in the timeline and do any action to edit the image (draw, erase, delete all, use transform tool, …). It creates a new frame with the content corresponding to the action you made.

-If you prefer to only create new frames manually, disable the auto-frame-mode with the corresponding button in the animation docker (the film with a pen icon).

-To move a frame in time, just drag and drop it to a new time position

-To duplicate a frame, press Control while you drag and drop it to a new time position.

-In the animation docker, you can define the start and end of the animation (to define the frames to use for export, and for the playback loop). You can also define the speed of the playback with the Frame rate value (frames per second) and the Play speed (multiplier or the frame rate).

-In the Onion Skins docker, you can change the opacity for each of the 10 previous and next frames. You can also select a color overlay to distinguish previous and next frames. You can act on the global onion skins opacity with the 0 slider.

-To change the opacity of several onion skins at the same time, press Shift while clicking across the sliders.

-To export your animation, use the menu entry File – Export animation, and select the image format you want for the image sequence.

Have fun animating in Krita, and don’t forget to report any issue you find to help improve the final version

Categories: FLOSS Project Planets

digiKam Recipes 4.9.7 Released

Tue, 2015-11-24 05:40

A new release of digiKam Recipes is ready for your perusal. This version features the new Use Exposure Indicators recipe along with the updated Find the Shutter Count Value with digiKam recipe. Astute readers will also notice the new cover. That's all there is to it this time around.

Continue reading

read more

Categories: FLOSS Project Planets

Game Art Quest Kickstarter!

Mon, 2015-11-23 11:21

Today an exciting new crowdfunding campaign kicks off! Nathan Lovato, the author of Game Design Quest, wants to create a new series of video tutorials on creating 2D game art with Krita. Nathan is doing this on his own, but the Krita project, through the Krita Foundation, really wants this to happen! Over to Nathan, introducing his campaign:

“There are few learning resources dedicated to 2d game art. With Krita? Close to none. That is why I started working on Game Art Quest. This training will show you the techniques and concepts game artists use in their daily work. If you want to become a better artist, this one is for you.”

“We are developing this project together with the Krita Foundation. This is an opportunity for Krita to reach new users and to sparkle the interest of the press. However, for this project to come to life, we need your help. A high quality training series requires months of full-time work to create. That is why we are crowdfunding it on Kickstarter.”

“But who the heck am I to teach you game art? I’m Nathan, a professional game designer and tutor. I am the author of Game Design Quest, a YouTube channel filled with tutorials about game creation. Every Thursday, I release a new video. And I’ve done so since the start of the year, on top of my regular work. Over the months, my passion for open source technologies grew stronger. I discovered Krita 2.9 and felt really impressed by it. Krita deserves more attention.”

“Long story short, Game Art Quest is live on Kickstarter. And its existence depends on you!”

“Even if you can’t afford to pledge, share the word on social networks! This would help immensely. Also, this campaign is not only supporting the production of the premium series. It will allow me to keep offering you free tutorials for the months to come. And for the whole duration of the campaign, you’re getting 2 tutorials every single week!”

Check out Nathan’s campaign:


Categories: FLOSS Project Planets

Looking at the security of Plasma/Wayland

Mon, 2015-11-23 05:13

Our beta release of Plasma 5.5 includes a Wayland session file which allows to start in a Plasma on Wayland session directly from a login manager supporting Wayland session. This is a good point in time to look at the security of our Plasma on Wayland session.

Situation on X11

X11 is not secure and has severe conceptual issues like

  • any client connected to the X server (either remote or local) can read all input events
  • any client can get information about when another window rendered and get the content of the window
  • any client can change any X attribute of any other window
  • any window can position itself
  • many more issues

This can be used to create very interesting attacks. It’s one of the reasons why I for example think it’s a very bad idea to start the file manager as root on the same X server. I’m quite certain that if I wanted to I could exploit this relatively easily just through what X provides.

The insecurity of X11 also influenced the security design of applications running on X11. It’s pointless to think about preventing potential attacks if you could get the same by just using core X11 functionality. For example KWin’s scripting functionality allows to interact with the X11 windows. In general one could say that’s dangerous as it allows untrusted code to change aspects of the managed windows, but it’s nothing you could not get with plain X11.

Improvements on Wayland

Wayland removes the threats from the X11 world. The protocols are designed in a secure way. A client cannot in any way interact with windows from other clients. This implies:

  • reading of key events for other windows is not possible
  • getting window content of other windows is not possible

In addition the protocols do not allow to e.g. position windows themselves, or raise themselves, change stacking order and so on.

Security removed in Plasma

But lots of these security restrictions do not work for us in Plasma. Our desktop shell need to be able to get information of other windows (e.g. Tasks applet), be able to mark a panel as a panel (above other windows) and need to be able to position windows itself.

Given that we removed some of the security aspects again and introduced a few custom protocols to provide window management facilities and also to allow Plasma windows to position themselves. At the moment we have no security restrictions on that yet which gives this functionality to all clients.

We will address this in a future release. There are multiple ways how this could be addressed, e.g. using the Wayland security module library or use systemd in some way to restrict access. Overall I think it will require rethinking security on a Linux user session in general, more on that later on.

Security added in Plasma compared to X11

The most important change on the security front of the desktop session is a secure screen locker. With Plasma 5.5 on Wayland we are able to provide that and address some long standing issues from X11. The screen locks even if a context menu is open or anything else grabbing input. The compositor knows that the screen is locked and knows which window is the screen locker. This is a huge change compared to X11: the XServer has no concept of a screen locker. Our compositor can now do the right thing when the screen is locked:

  • don’t render other windows
  • ensure input events are only handled in the lock screen
  • prevent access to screen grabbing functionality while screen is locked

As a matter of fact the Wayland protocol itself doesn’t know anything about screen locking either. This is now something we added directly to KWin and doesn’t need any additional custom Wayland interfaces.

How to break the security?

Now imagine you want to write a key logger in a Plasma/Wayland world. How would you do it? I asked myself this question recently, thought about it, found a possible solution and had a key logger in less than 10 minutes: ouch.

Of course there is no way to get a client to act as a key logger. The Wayland protocol is designed in a secure way and also our protocol additions do not weaken that. So the key to get a key logger is to attack KWin.

So what can an attacker do with KWin if he owns it? Well pretty much anything. KWin internally has a very straight forward trust model: everything is trusted and everything can access anything. There is not much to do about that, this is kind of how binaries work.

For example as a Qt application each loaded plugin has access to the QCoreApplication::instance. From there one could just use Qt’s meta object inspection to e.g. get to the InputRedirection model and connect to the internal signal on each key press:

<code>void ExamplePlugin::installKeyLogger() { const auto children = QCoreApplication::instance()-&gt;children(); for (auto it = children.begin(); it != children.end(); ++it) { const QMetaObject *meta = (*it)-&gt;metaObject(); if (qstrcmp(meta-&gt;className(), "KWin::InputRedirection") != 0) { continue; } connect(*it, SIGNAL(keyStateChanged(quint32,InputRedirection::KeyboardKeyState)), this, SLOT(keyPressed(quint32)), Qt::DirectConnection); } } void ExamplePlugin::keyPressed(quint32 key) { qDebug() &lt;&lt; "!!!! Key: " &lt;&lt; key; } </code>

But Martin, why don’t you just remove the signal, why should any other aspect of KWin see the key events? Because this is just the example of the most trivial exploit. Of course it’s not the only one. If you have enough time and money you could write more sophisticated ones. For example look at this scenario:

KWin uses logind to open restricted files like the input event files or the DRM node. For this KWin registers as the session controller in logind. Now a binary plugin could just send a DBus call to logind to also open the input event files and read all events. Or open the DRM node and take over rendering from KWin. There is nothing logind could do about it: how should it be able to distinguish a valid from an invalid request coming from KWin?

How to secure again?

As we can see the threat is in loading plugins. So all we need to do is ensure that KWin doesn’t load any plugins from not trusted locations (that is not from any user owned locations). This is easy enough for QML plugins where we have the complete control. In fact it’s easy to ensure for any of KWin’s own plugins. We can restrict the location of all of them.

And even more: by default a system is setup in a way that no binary plugins are loaded from user’s home. So yeah, no problem after all? Well, unfortunately not. During session startup various scripts are sourced which can override the environment variables to influence the loading of plugins. And this allows to also use the well known LD_PRELOAD hack. My naive approach to circumvent this issue didn’t work out at all as I had to learn that already the session startup and the PAM interaction source scripts. So your session might be owned very early.

An approach to black list (unset) env variables is futile. There are too many libraries KWin relies on which in turn load plugins through custom env variables. Most obvious examples are Qt and Mesa. But there are probably many more. If we forget to unset one variable the protection is broken.

A different approach would be to white list some known secure env variables to be passed to KWin. But this also requires that at the point where we want to do the restriction the session is not already completely broken. This in turn means that neither PAM nor the session manager may load any variables into the session before starting the session startup. And that’s unfortunately outside what we can do in our session startup.

So for Plasma 5.5 I think there is nothing we can do to get this secure, which is fine given that the Wayland session is still under development. For Plasma 5.6 we need to rethink the approach completely and that might involve changing the startup overall. We need to have a secure and controlled startup process. Only once KWin is started we can think about sourcing env variables from user locations.

So how big is the threat? By default it’s of course secure. Only if there is already a malicious program running in the system there is a chance of installing a key logger in this way. If one is able to exploit e.g. a browser in a way that it can store an env variable script in one of the locations, you are owned. Or if someone is able to get physical access to your unencrypted hard disk, there is a threat. There are easy workarounds for a user: make all locations from where scripts are sourced during session startup non-writable and non-executable, best change ownership to root and encrypt your home location.

Overall it means that Plasma 5.5 on Wayland is not yet able to provide the security I would have liked to have, but it’s still a huge improvement over X11. And I’m quite certain that we will be able to solve this.

Categories: FLOSS Project Planets

Interview with Christopher Stewart

Mon, 2015-11-23 03:22
Could you tell us something about yourself?

My name is Christopher, and I am an illustrator living in Northern California. When I’m not in a 2d mindset I like to sculpt with Zbrush and Maya. Some of my interests include Antarctica, Hapkido and racing planes of the 1930s.

Do you paint professionally, as a hobby artist, or both?

I have been working professionally for quite some time. I have worked for clients such as Ubisoft, Shaquille O’Neal and Universal Studios. I’m always looking for new and interesting work.

What genre(s) do you work in?

SF, Fantasy, and Comic Book/ Sequential art. This is where the foundation of my work lies – these genres have always been an inspiration to me ever since I was a kid.

Whose work inspires you most — who are your role models as an artist?

Wow, what a tough question! So many great artists out there.. Brom- definitely, N.C. Wyeth, George Perez, and Alphose Mucha. Recently I have revisited the background stylists of Disney with their immersive environments.

How and when did you get to try digital painting for the first time?

About 9 years ago. Until then my work was predominantly traditional. I wanted to try new mediums, and I thought digital painting would be a great area to explore.

What makes you choose digital over traditional painting?

Time and space.

Alterations and color adjustments can be done quickly for a given digital piece.

The physicality of traditional medium has different challenges, and usually the solution will take longer to accomplish with traditional mediums in general.

Digital painting doesn’t take up a lot of space, a few decent sized stretched canvases..

How did you find out about Krita?

I had tried Painter X and CS and they were unsatisfying, so I was looking for a paint program. Krita was recommended by a long-time friend who liked the program, and I was hooked.

What was your first impression?

It was very intuitive. It had a UI that I had very few difficulties with.

What do you love about Krita?

I really really liked the responsiveness of the brushes. With other applications I was experiencing a “flatness” from the tablet I use to the results I wanted on screen, Krita’s brushes just feel more supple. The ability to customize the interface and brushes was also a huge plus.

What do you think needs improvement in Krita? Is there anything that really annoys you?

I haven’t been using Krita very long (less than 6 months) but I would like to be able to save and import/export color history as a file within an open Krita document.

What sets Krita apart from the other tools that you use?

When a company makes an application as powerful as Krita available for free, it’s a statement about how confident they are that artists will love it. And judging from the enthusiastic and knowledgeable people in the forums, they not only love it they want others to be able to love it and use it too. Developing and experienced artists need to evaluate new tools easily. Access to those tools should never be so prohibitively costly as to turn them away. Krita doesn’t get in the way of talent being explored, it supports it.

What techniques and brushes do you prefer to use?

I use a lot of the default brushes especially the Bristle brushes, a semi transparent texture to add to a plein air look as a final layer. I use some of David Revoy’s brushes, specifically the Splatter brushes. I recently made a new custom brush that I tried out on my most recent illustration.

Where can people see more of your work?

My website is You can reach me there!

Anything else you’d like to share?

Thank you so much for the interview and a special thanks to the developers and community that make Krita work!

Categories: FLOSS Project Planets

Linux-Stammtisch Munich

Sun, 2015-11-22 16:47

For all Ceph interested people in Germany, especially Bavaria: There will be a Linux-Stammtisch next week on 24.11.2015 in Munich. I will present about "Ceph - Overview, Experiences and Outlook". If you are interested, the meeting starts at 19:00 (CET) at the Paulaner Bräuhaus. You find more information and can register here.

There will be also a talk held by Andreas Pöschl from BMW. The topic is: "Erfahrungen bei der Integration von Open Stack in eine Enterprise-Umgebung". And for sure there will be time for networking and beer after the talks and discussion.

Categories: FLOSS Project Planets

Muon 5.5 and Carrots

Sun, 2015-11-22 11:11

Jonathan Riddell, Leader of Flies, kept holding me until I write a blog post, so here is one.

After 2 days of obscenely unsubsidized drinking and vicious discussions about carrots, the KDE and Kubuntu developers here at the developer sprint in Munich decided to release the Debian package manager Muon in version 5.5.0.

A very prominent thing to take away from this sprint is “oops”. I am not sure that is good, but oh well.

Hearts and kisses!

Categories: FLOSS Project Planets

Divide and Conquer

Sat, 2015-11-21 22:54

To start: Why the name of this post is Divide and Conquer?

Well… A few weeks back, I receive a feedback about the main class of the Br-Print project. This main class was friendly called a God Class. The God Class complex is when a class knows too much and does too much. Well, when a problem on this project is shown to me, starts to bug’s me. So I start the Divide and Conquer branch. Breaking the main class in others minor classes, to increase the level of abstraction and make the code more easy to read.

Today I push to the git this new version. With 5 new classes to manage specific controls on the code. Also solved a few layout issues, remove a lot of unnecessary code and simplify others parts.

With this challenge and Tomaz feedbacks and some tips from the internet, I could learn much more about Qt programming, OOP and about my limits.

Several times I had thoughts that I couldn’t do something. And today, when opened the statistics of this blog, I realize that I’m proud about my work. Proud about the places he has achieved.

Are 7 months working on this project, and I don’t figured out that the extension would be this great! Germany, United Kingdom, Switzerland, Belgium, USA. These are some of the countries that are accessing this page. Sometimes I really don’t believe! =D

The propose of this post is show my gratitude to all of you. To all people around the world that who are believing in this project!

If you wants to know more please reach us on our Facebook Page , because there we post photos and more info about this project!
Well, if you want to contribute or test the Br-Print3D just click here to go to the GitHub.

My best regards!


Ps.: If exists some error about my english write, sorry about that. =D

Categories: FLOSS Project Planets

Your input, please: naming of action icons (tables, vectorpaths, animation, text, …)

Sat, 2015-11-21 05:14

Developing an application where you use or need icons for actions around tables, vectorpaths, animations, text formatting? Looking forward to use Breeze-styled icons, shared with other applications? Then please read on, this is especially for you:

The Breeze iconset currently gets further icons, as needed by the different Calligra apps and plugins. And that are many icons.

Given these icons are then in the public namespace (without any Calligra-specific prefix) and ideally also can be reused by any apps, we need to ensure there are no icon name collisions and also that semantics in the naming are properly done. The XDG Icon Naming Specification currently is leaving a lot of room and surely one day can also get more feedback by the names we start to use here.

Please have a look at the overview of proposed icon names:
(shows also old custom icons used in Calligra and old custom names).

And then please tell (e.g. by commenting on this post or by replying to the email on ML kde-devel ) where you see chances for improvements. The quicker you comment, the better, because this is WIP and might soon create facts.

While there are naming proposals already for most icons, there are a few in need for any naming proposal at all. So listing them here explicitely once again (see details in the overview page):

  • borderpainter
  • black
  • highlight
  • special_paste

Andreas from the VDG has already started to do and commit first such icons in Breeze style to the repo of Breeze icons, see links below to get an idea what is coming up.
There have been done already quite some Breeze-style icons for LibreOffice. Just, LibreOffice for legacy reason has their own internal icon naming and resource system, so the Breeze icons as created for LibreOffice are not in the normal Breeze iconset and not following the XDG Icon Naming Specification. But by that there is some iconic language existing and SVG code to reuse. Still, this is a big amount of work to be done, so we Calligra developers are very happy that Andreas has started to tackle this!

Initial commits:
Calligra escape directions
Calligra connection line types
Calligra path editing related icons
Calligra Borders for multiple cells icons
Adde dmissing action icons to icons-dark

PS: Anyone a good idea how to embed external SVG files in Community Wiki pages? Using link as plain text only works with PNG files (and once the url ends with “.png”), but not SVG ones.

Categories: FLOSS Project Planets

The force is with us!(So Close!)

Fri, 2015-11-20 20:03

Well… just remaining feel days until the official launch of our pre-alpha canditade at kde side, we wanna show some results of our tests as “made with Br-Print Stuff :] t to test manobrability and confiability on several situations including emergencies once we simulate fail of some components of the printer just to see if it can go printing same after a buffering problem or after an accidental turn off bed temp or hotend temp.

The pre alpha version just depends of several bug corrections just like Deadlocks after some simple actions, it may be a compiler problem so we are just investigating now.

Here we have a lot of long runs *(prints with more than 4 hours) hope that you enjoy it ! The material used is ABS  provided by our sponsor, “Filamentos 3D Brasil“, thanks a lot fot the stuff and support guys!

Other Stuff:

If you wanna have at home some great stuff printed by us or better created and printed by us, just contact us on FaceBook =] , the money of course WILL be use for continue the development , the bills just won’t wait .

Next post it may be deployed here so YOU can test and help it be better and better! Cheers!



Categories: FLOSS Project Planets

Desktops DevRoom @ FOSDEM 2016: Have you submitted your talk yet?

Fri, 2015-11-20 08:50

FOSDEM 2016 is going to be great (again!) and you still have the chance to be one of the stars.

Have you submitted your talk to the Desktops DevRoom yet?


Remember: we will only accept proposals until December 6th. After that, the Organization Team will get busy and vote and choose the talks.

Here is the full Call for Participation, in case you need to check the details on how to submit:

FOSDEM Desktops DevRoom 2016 Call for Participation

Topics include anything related to the Desktop: desktop environments, software development for desktop/cross-platform, applications, UI, etc

Categories: FLOSS Project Planets

Efficiency Matters!

Thu, 2015-11-19 08:23

It’s every programmer’s worst nightmare. Your beautiful app is running at a snail’s pace, crippled by virtual memory swapping. Even worse, you’ve added one last bitmap resource, and suddenly unrelated chunks of the UX aren’t showing up!

Desktop machines have become powerful enough that programmers rarely worry about performance issues, and today’s embedded systems usually have enough horsepower at their disposal. But in constructing sophisticated user interfaces with more and more elaborate imagery and high-definition backgrounds, we are often sapping one resource that’s always scarce: RAM. That’s especially true for the dedicated video RAM (VRAM) that sits on the GPU.

Holoplot UX – Example of modern user interface that could benefit from compressed textures. (KDAB designed UX, photo courtesy of Holoplot.)

With ever-increasing screen densities, it’s easy to see why VRAM is in such demand. An iPad with a retina display is 2048×1536 pixels, and at 4 bytes per pixel, that’s a whopping 12.5MB of RAM for just a static background image. Toss in a few more large bitmaps, masks, or textures, and you can be consuming dozens or hundreds of megabytes of VRAM, not to mention regular RAM.

“Not me! All my images are compressed JPEGs or PNGs,” you say. Yes, but Qt Quick 2 (QQ2) uncompresses images on loading them, so your svelte, skinny PNGs uncompress into giant blocks of RAM on program start. And those bitmaps take an equivalent bite out of VRAM when they’re displayed. Making one-bit deep masks or using a 16- or 8-bit color depth doesn’t really help, as everything gets expanded out into 32-bit RGBA on loading.

What’s an enterprising Qt Quick 2 programmer to do? Take a tip from our game engine friends, that’s what. Modern video games load and manage hundreds of large, high-quality textures, and they get away with it by using custom compressed textures. The textures are directly loaded off disk and left in a compressed format that the GPU can understand. These formats aren’t JPEG or PNG—they’re highly specialized formats that need a time-consuming conversion process. But the GPU can directly read those formats and uncompress them to the display on-the-fly, meaning that your RAM (and VRAM) only takes the hit for the compressed sizes, not the fully expanded size. That can result in dramatic savings of both RAM and VRAM.

We don’t want to reinvent all Qt’s display machinery, so unless we can convince Qt to compress textures, any possible savings would be academically nice, but practically impossible. Fortunately, through the QOpenGLTexture class (a KDAB contribution, btw), QQ2, provides all the necessary APIs to let us change the underlying behavior to use compressed textures without mucking around in the internals.

Overriding the QSGTexture class class CompressedSGTexture : public QSGTexture { Q_OBJECT public: CompressedSGTexture(const PKMImage &amp;amp;amp;image); ~CompressedSGTexture(); void bind() Q_DECL_OVERRIDE; bool hasAlphaChannel() const Q_DECL_OVERRIDE; bool hasMipmaps() const Q_DECL_OVERRIDE; int textureId() const Q_DECL_OVERRIDE; QSize textureSize() const Q_DECL_OVERRIDE; private: PKMImage m_image; QScopedPointer ⟨QOpenGLTexture⟩ m_texture; };

The first step is to compress the images using a GPU-friendly compression scheme. Unfortunately there are a number of these formats, many are proprietary and not well documented, and they aren’t readily exportable from common image-editing tools like GIMP or Photoshop. Thankfully though, ARM includes, as part of their ARMMali visual technology suite, a freely available and great tool that deals with a number of the most encountered compression formats: the Mali GPU Texture Compression Tool. Using the Mali GPU Texture compression tool to compress some samples images at the highest quality setting took over 30 minutes on a decent machine, so you may want to settle for slightly less than perfection!

Loading compressed NVIDIA GPU PKM files for the texture provider QQuickTextureFactory *CompressedTextureImageProvider::requestTexture(const QString &amp;amp;id, QSize *size, const QSize &amp;amp;requestedSize) { Q_UNUSED(requestedSize); QFile imageFile(QStringLiteral(“:/%1.pkm”).arg(id)); if (! return 0; QByteArray header =; if (header.length() != PKM_HEADER_LENGTH) { qWarning() ⟨⟨ “PKM header too short”; return 0; } PKMImage image; const char *headerData = header.constData(); // Parse the PKM header if (memcmp(headerData, PKM_HEADER_PREAMBLE, PKM_HEADER_PREAMBLE_LENGTH) != 0) { qWarning() ⟨⟨ “Malformed PKM header (missing heading)”; return 0; } headerData += 4; if (memcmp(headerData, PKM_HEADER_VERSION, PKM_HEADER_VERSION_LENGTH) != 0) { qWarning() ⟨⟨ “Malformed PKM header (wrong version)”; return 0; } headerData += 2; #define UCC(x) (reinterpret_cast⟨const uchar *⟩(x)) const quint16 dataType = qFromBigEndian⟨quint16⟩(UCC(headerData)); if (dataType != PKM_ETC2_RGB_NO_MIPMAPS) { qWarning() ⟨⟨ “Malformed PKM header (wrong data type)”; return 0; } headerData += 2; image.effectiveSize.rwidth() = qFromBigEndian⟨quint16⟩(UCC(headerData)); headerData += 2; image.effectiveSize.rheight() = qFromBigEndian⟨quint16⟩(UCC(headerData)); headerData += 2; image.originalSize.rwidth() = qFromBigEndian⟨quint16⟩(UCC(headerData)); headerData += 2; image.originalSize.rheight() = qFromBigEndian⟨quint16⟩(UCC(headerData)); headerData += 2; #undef UCC Q_ASSERT(image.effectiveSize.width() % 4 == 0); Q_ASSERT(image.effectiveSize.height() % 4 == 0); Q_ASSERT(headerData == header.constEnd()); // Read out the payload const qint64 imageDataLength = ((image.effectiveSize.width() / 4) * (image.effectiveSize.height() / 4)) * 8; =; if ( != imageDataLength) { qWarning() ⟨⟨ “Malformed PKM file: payload too short”; return 0; } if (!imageFile.atEnd()) { qWarning() ⟨⟨ “Malformed PKM file: data after the payload”; return 0; } if (size) *size = image.effectiveSize; return new CompressedTextureFactory(image); }

Once you have your images compressed in a GPU-digestible way, the QQ2-related code is pretty straightforward with QOpenGLTexture doing most of the heavy lifting. Here’s sample code (including all the assorted code snippets) with the tweaks you’ll need. Note that this sample code is not a full executing sample and just a proof of concept, so #include <all standard disclaimers> …

To pull off the compressed texture magic, we need a custom image provider (CompressedTextureImageProvider), a custom texture provider (derived from QQuickTextureFactory), and a custom QSGTexture subclass (CompressedSGTexture in the sample code). Although the compressed texture is nearly the same size as the original PNG, the RAM/VRAM savings for a background image during runtime is about 12MB!

Compressed Texture Factory class CompressedTextureFactory : public QQuickTextureFactory { Q_OBJECT public: CompressedTextureFactory(const PKMImage &amp;amp;image); QSGTexture *createTexture(QQuickWindow *window) const Q_DECL_OVERRIDE; QImage image() const Q_DECL_OVERRIDE; int textureByteCount() const Q_DECL_OVERRIDE; QSize textureSize() const Q_DECL_OVERRIDE; private: PKMImage m_image; }; CompressedTextureFactory::CompressedTextureFactory(const PKMImage &amp;amp;image) : m_image(image) { } QSGTexture *CompressedTextureFactory::createTexture(QQuickWindow *window) const { Q_UNUSED(window); return new CompressedSGTexture(m_image); } QImage CompressedTextureFactory::image() const { // FIXME/TODO: we can't easily get a QImage out of compressed texture data; // uncompressing image left as an exercise for the reader. This function // isn't called under normal circumstances... return QImage(); } int CompressedTextureFactory::textureByteCount() const { return; } QSize CompressedTextureFactory::textureSize() const { return m_image.effectiveSize; }

The other big advantage of compressed textures is CPU utilization, especially during program initialization. Everyone appreciates faster program start times, and that’s especially true on constrained devices like tablets, mobiles, or embedded devices. Not only are we skipping the decompression step during the load phase, but we’re also minimizing the size of copies between RAM and VRAM.

Tons less memory and faster execution for a sprinkling of calls and an extra step added to the build process. Not a bad payoff!

About KDAB

KDAB is a consulting company dedicated to Qt and offering a wide variety of services and providing training courses in:

KDAB believes that it is critical for our business to invest into Qt3D and Qt, in general, to keep pushing the technology forward and to ensure it remains competitive.

The post Efficiency Matters! appeared first on KDAB.

Categories: FLOSS Project Planets

Library versioning

Wed, 2015-11-18 16:53

Do you maintain or contribute to a library, especially a KDE library (other than the Frameworks)? If so, I have a question for you.

First, some background. These days, the norm for libraries is to follow some variation of semantic versioning, where the version number follows the scheme x.y.z (eg: 1.4.3) and it should always be safe to upgrade the library to version with a higher y (minor) component as long as the x (major) component is the same. Qt follows this scheme, for example.

This scheme doesn’t really allow for alpha versions of software, though – the alpha releases for the (x+1) major version can be incompatible with both version x and with the final releases of version (x+1). The Semantic Versioning scheme prescribes using versions like x.y.z-alpha1, but this breaks the nicely numeric scheme we had, and not all tools can cope with that.

KDE Frameworks (and, in the past, kdelibs) approached this by defining some arbitrarily high minor version (typically 90+) to indicate pre-releases for the next major release. So the pre-release Frameworks were numbered like 4.90.1.

So where is all of this going? Well, CMake provides a helpful function to write package version information files that allow find_package() calls to only find compatible versions. So if you use the SameMajorVersion scheme, find_package(Foo 4.3) will find Foo 4.3.0 and Foo 4.5.2, but not Foo 4.2.5 or Foo 5.1.1. However, if project Foo uses the “high minor = next version prerelease” scheme, it will also find Foo 4.90.1, which is not compatible with Foo 4.3.

I wrote a SameMajorVersionWithPreleases scheme that would deal with this for Extra CMake Modules, but never committed it because I wasn’t sure if it would get used (KDE Frameworks doesn’t need it because we put KF5 in the package names). My question is: would your project find this useful? In other words, do you contribute to (or know of) a CMake-based project that uses the “high minor = next version prerelease” scheme I described above? If so, please comment!

Categories: FLOSS Project Planets

SQL CRUD: what’s good and what’s crud?

Wed, 2015-11-18 12:59

I maintain a membership database for my canoe club and I implemented the database years ago using a PHP library called Phormation which let me make an index page with simple code like:

query = “SELECT * FROM member WHERE year=2015″
show_table(column1, column2)

and an entry editing page with something like this:

query = “SELECT * FROM member WHERE id=$id”
widgets.append([column1, “name”, Textfield])
widgets.append([column2, “joined”, Date])

and voila I had a basic UI to edit the database.

Now I want to move to a new server but it seems PHP has made a backwards incompatible change between 5.0 and 5.5 and Phormation no longer runs and it’s no longer maintained.

So lazyweb, what’s the best way to make a basic web database editor where you can add some basic widgets for different field types and there’s two tables with a 1:many relationship which both need edited?


Categories: FLOSS Project Planets

Printing Kernel, a new approach in 3D printer control.

Tue, 2015-11-17 19:18

The 3D printer world suffered with instability problems due to Mono framework. Actually, the idea of use a virtual machine, instead of the O.S. interface itself has been proven a mistake, and although it increases portability between machines, has leading to various problems, and most of then are related to unexpected halts, leading to lost of filament and non-controlled memory usage, which makes it difficult to use in a more basic machine, or even in embedded devices.

The approach of KI, the Printing Kernel, is to provide the Br-Print with a basic, but complete, interface to the O.S., witch is easier to implement with the GUI in a way that whose programmers shall not have to deal with the complexity, facilitating portability and increase reliability. Relying on the top of O.S. ports interfaces, its stability is directly linked with the system reliability itself. Working on the user space, the KI is friendly to the system in a way that even if it freezes for some reason, your computer shall not halt, so you’ll be able to react to emergencies. But at the same time, even if the GUI freezes, the printing job may finish, such event was already logged in our tests, and showed to us the strength of the kernel.

So, what do we expect from it? Well, our test has shown that it’s reliable enough to go into a production environment, reducing the filament loss in 15 to 20%, and decreasing the cost of the hardware that can control a 3D printer. We believe that a computer with 2GB of RAM and a Core i3 can run the Br-Print with no problems, and a port of the KI to Raspberry Pi B+ (1st generation) is been tested, and can also be a strong candidate to an IoT 3D printer! Than, said that, let’s kick in!

Categories: FLOSS Project Planets

Screenlocker integration in KWin Wayland

Tue, 2015-11-17 15:30

Since last few weeks I was working on the Lockscreen integration with KWin Wayland session, this is most important bit of the Plasma on Wayland session. Currently in X11 lockscreen is managed by ksmserver (KDE’s session manager). It suffers from various security problems which are mentioned on blog post by Martin Gräßlin. This blog post also mentions that in Wayland lockscreen functionality should be moved in kwin_wayland, so that compositor is aware that screen is locked, what windows are owned by greeter, and what should get input events.

To provide screenlocker integration in kwin_wayland, KWin needs to link to kscreenlocker library. Which was being built as static library in plasma-workspace. To avoid dependency loop kscreenlocker was split into different repository to which ksmserver in plasma-workspace and kwin_wayland can depend upon. Next, kwin_wayland was adjusted to start KSldApp (stands for KScreenlocker Daemon Application). As a result, we had beautiful lockscreen on wayland session!

However, this was not really secure.. one can just Alt+Tab the screenlocker. oops!

Now it was time for adding security constraints to KWin, so security promised earlier is available. Security constraints are,

  • When screen is locked, allow only lockscreen/greeter windows to be shown
  • When screen is locked no other clients/windows should be able to get input events
  • Allow only on-screen input methods like maliit to be shown on lockscreen
  • Do not pass any events to KWin effects or any other clients

For this kwin_wayland needs to know which windows are provided by lockscreen or greeter. For this KSldApp passed the client connection created by it to kwin_wayland. This way kwin can identify the greeter windows to apply various security restrictions. kwin_wayland have InputRedirection class which handles getting input events from the input devices and passes it to various clients, effects or applications based upon their priority. InputRedirection was adjusted to pass keyboard events to just lockscreen and mouse events to lockscreen as well as input methods.

However, things that are not secured/tested are :

  • Touch events
  • Global shortcuts for screenlocker
  • Fallback/emergency screen not yet working

Also currently lockscreen on wayland is not unit tested. I plan to work on this in upcoming days.

This secured screen locker architecture for Plasma on Wayland session will be available for Plasma 5.5 release cycle. This also fixes 11 year old bugs like keyboard/mouse grabs prevent screenlocker from starting. Overall its very nice improvement to Plasma Desktop.


Categories: FLOSS Project Planets