Subscribe to Planet KDE feed
Planet KDE - http://planetKDE.org/
Updated: 10 min 5 sec ago

GCompris on iPad

Fri, 2016/02/12 - 6:15pm

I am glad to announce that GCompris is now available on the iOS Apple Store for iPad and iPhone users.

The Qt Quick version of GCompris is available on Android since last year and is reaching 50000 installations. We have it on the MacOSX Apple Store and we have a demo version for Windows that will replace the Gtk+ version in the next release. For GNU/Linux users we are urging packagers to include us beside the Gtk+ version, in the mean time we provide an auto installer for x86 and x86_64.

Two years ago I just went out with the insane project of rewriting GCompris in Qt Quick and provide a version to mobile users. Many of you joined the project and made the dream comes true. And we did it, we now have a Free Software for children available on all major desktop and mobile platforms and most important we give users the ability to choose a Free operating system.

We now have a solid software foundation, a vibrant little community and almost completed the Gtk+ port (120 activities ported on 140). There are still many things to do. I would like to see more innovative activities, more educational experiments, better exchange with teachers to make sure each child find an activity that he can enjoy and learn with.

Quoting Winston Churchill, I think we can say that this is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning

Bruno.

 


Vote for Presentations - OpenStack Summit Austin 2016

Thu, 2016/02/11 - 1:50pm
The first OpenStack Summit this year will take place in Austin (TX, US) from April 25-29, 2016. The "Call for Speakers" period ended some days ago and now the community voting for presentation started and will end 17th February, 11:59 PST (18th February 7:59 UTC / 08:59 CEST). 

I've submitted this time one talk this time:
  • "From Hardware to Application - NFV@OpenStack and Ceph" - This talk will provide insight into NFV cloud specific hardware and data center design, preferred setup and requirements to OpenStack and Ceph and also important design implications and requirements for applications and developers on this platform. 

You can vote, if you are interested to see my talk at the summit, every vote is highly welcome. The full abstract can be found at the voting page.

There is a long list of interesting Ceph related talks, simply use the search field on the voting page. I may provide a list in an additional post later as last time.

Season of KDE (3) – KDE Action Restrictions

Thu, 2016/02/11 - 11:58am

To have a working KIOSK tool again, Confine needs to support another key feature of the KIOSK framework: KDE Action Restrictions.

A KDE Application can check if a certain Action is allowed. For example the action logout could be forbidden. So every time the logout action is performed, an application checks, if this action is allowed. Thus a user can still use an application, but certain actions are restricted to him.

These settings are stored in the kdeglobals file, in your KDE profile directory.

For my season of KDE project I had to compile a list of all currently used KDE Action Restrictions. I did a quick search throughout all KDE projects for the use of the KAuthorized framework and published my results in the confine repository. Although Confine is not finished yet, you might found this list beneficial, if you want to configure KIOSK restrictions manually.

Still a lot of KDE applications don’t support KDE Action Restrictions (anymore). For a revival of the whole KIOSK concept it would be highly beneficial, if more application are starting to use KDE Action Restrictions.

Flattr this!

GCompris: Patreon and New Logo

Thu, 2016/02/11 - 2:10am

Hello everyone,

A few days ago, I created a page on Patreon to support my work on making new graphics on GCompris. As you may know, last year I started this project, and could make a good start thanks to a little crowd-funding campaign. However there’s a lot of remaining work to finish the task. A lot of activities need to be updated, and new activities will always need some new design and graphics.

So if you want to support GCompris, you can become my patron for this project.
Before resuming my work on the activities, I took the hard and delicate task to update the logo and the main icon of the application.

Now is a good time to have a new icon, for several reasons.
-The old icon had no real meaning, only legacy (which, for a kid that sees GCompris for the first time, doesn’t mean anything)
-Tux is already the mascot of a completely different kind of software. Having him along with other FLOSS mascots inside some activities is cool, but he doesn’t represent enough GCompris to be in the icon.
-The Qt port is still in progress, and it makes sense to have a new icon for it.
-With the new graphics in the application, GCompris needs a good branding that looks good and makes sense.

Also, as some people said they would like to keep the legacy biplane+tux, I tried. I spent countless hours trying to make something looking good, looked at it from every angles. I really couldn’t find a way, and at some point I was feeling like loosing my time.

Full of energy from these failures, I started a new icon from scratch. We had a brainstorm topic on the mailing list recently for a new icon, so I had some indications to begin with. It should mean things like education and gaming, be colorful and cute.

I spare you all the iterations, but after pages of sketches, several proposal and lot of constructive discussions on IRC, here is the final result, along with some explanations:

This is the new icon.
The globe is a symbol for the educational part of GCompris. Also luckily, it is still linked in a way to the idea of the plane from the previous icon. Also it is the same G and orange circle that is used as about button in the main menu.
The dice is a symbol for the gaming part of GCompris, and it also represents counting and maths.
I chose the orange color for the globe for several reasons, probably the most important is because it still contains some yellow from the previous icon, but it is warmer. The blue for the dice adds some contrast.

I tweaked it to follow the main guidelines of Breeze-icon-design, I like the look it gives to it.

This is the new logo with the full name.
It started as a clean-up of the previous one, changing the style and colors of the letters to something soft and colored. Then after making the icon, I added the globe to it, thanks to a suggestion on IRC.

This is a “light” version of the logo, without the globe so it fits better inside a line.

I hope everyone will be happy with this new logo and icon. I know lot of old-timers had some affection for the plane and tux logo, but if you read what I said above, you can see that it was a well considered and discussed change, with lot of good reasons to happen.

Again, if you like my work on GCompris, check this link to see how you can support it. Expect a new activity update next month.

Neon and Plasma Relationship

Thu, 2016/02/11 - 12:21am

As we saw neon, a new and fresh Linux distribution was launched last week. This project is incubated by the KDE Community, sharing KDE's hosting and community. Hopefully we'll see neon flourish into an awesome distribution over time.

However, I have seen some potential confusion in an article reaching a conclusion that this might be in some way problematic for other distributions to deploy KDE software. To make sure we're all on the same page I wanted to give a clarifying statement from the Plasma mantainer.

Plasma is and remains distro-agnostic. It's in our interest to help all of our distribution channels. As long as distributions continue to keep up with the dependencies we need and work well with us, we support everyone as best as we can.

KDE Applications 16.04 Schedule finalized

Wed, 2016/02/10 - 9:59pm

It is available at the usual place https://techbase.kde.org/Schedules/Applications/16.04_Release_Schedule.

Dependency freeze is in 4 weeks and Feature Freeze in 6 weeks, so hurry up!

Launching docs.krita.org: the Krita Learning Place!

Wed, 2016/02/10 - 8:03pm

For months, we have been working on something awesome: docs.krita.org! And now it’s the time to share our work with you. Over the past year, we created a comprehensive manual for Krita on KDE’s Userbase website, and now we’ve got a beautiful new home for our work. All the content has been ported to the new learning area — and we want to extend the content further as well as add more Krita tutorials!

The new and updated docs.krita.org is the place for everyone who wants to use Krita. Artists who need a good introduction, painters who want to browse brush packs, or curious sketchers looking for information on what all of the features in Krita do. The perfect place to start when learning anything about Krita. And digital painting in general.

Here are some of the things we’re sure you’ll appreciate:

Better Search Capabilities

live-search

The docs site has its own search functionality now! The search will pick up not just page titles, but also content. This makes it much easier to find what you are looking for! And the live search bar also will give suggestions as you type.

Improved Navigation

page-tree-navigation

All the content is now organized in a page tree display. You can drill down into the specific areas that you are interested in. The navigation turns into a fixed layout to make it easy to reference where you are. And pages include a previous and next page function to help you move around. Breadcrumbs exist above the title as well. Click on them to go up a directory, as usual!

page-navigation

Combined Educational Resources

No more bouncing between different websites for learning. We have moved the User Manual and the FAQ to the learning area. Combined with the live search, it means finding answers to your questions has never been easier! And there’s so much content here already, most common questions are answered, and quite a few esoteric ones as well!

Updated & New Content

We are always trying to update content, but we spent a little more time while working on these updates.

We have a new Unstable section with new features that being worked on right now, like Animation. Then, when a feature is released in a stable version, we will move the documentation out of the Unstable section.

If you start out using Krita, you might have questions like “how to save an image for the web”, or would like to see examples of how to use Krita. There are lots of tutorials spread all over world, created by Krita developers and users. So many that it’s getting difficult to find, and even more, to find them again! For this we created the tutorials section.

And if you’ve used Krita for a while, you’ll have seen that Krita has plenty features that are unusual, or even unique! Photoshop tutorials won’t help you here! So we created a dedicated area where we can tell you how to use Krita’s advanced features, and where they go beyond to what you might have been expecting.

Of course, updating the documentation and education for Krita, and keeping it up-to-date is a work-in-progress. It’ll always be a work in progress! But we are really proud of all these improvements! Learning Krita, or getting the most out of Krita, just got a whole lot easier!

[Short Tip] Use Red Hat Satellite 6 as an inventory resource in Ansible

Tue, 2016/02/09 - 11:54pm

Ansible Logo

Besides static file inventories, Ansible can use custom scripts to dynamically generate inventories or access other sources, for example a CMDB or a system management server – like Red Hat Satellite.
Luckily, Nick Strugnell has already written a custom script to use Satellite as an inventory source in Ansible.

After checking out the git, the hammer.ini needs to be adjusted: at least host, username, password and organization must be adjusted.

Afterwards, the script can be invoked directly to show the available hosts:

$ ansible -i ~/Github/ansible-satellite6/satellite-inventory.py all --list-hosts argon.example.com satellite-server.example.com helium.example.com ...

This works with ansible CLI and playbook calls:

$ ansible-playbook -i ~/Github/ansible-satellite6/satellite-inventory.py apache-setup.yml PLAY [apache setup] *********************************************************** GATHERING FACTS *************************************************************** ...

The script works quite well – as long as the certificate you use on the Satellite server is trusted. Otherwise the value for self.ssl_verify must be set to False. Besides, it is a nice and simple way to access already existing inventory stores. This is important because Ansible is all about integration, and not about “throwing away and making new”.


Filed under: Cloud, Debian & Ubuntu, Fedora & RHEL, Linux, Microsoft, Shell, Short Tip, SUSE, Technology

[Howto] Looking up external directories in Ansible

Tue, 2016/02/09 - 11:07am

Ansible Logo Part of Ansible’s power comes from an easy integration with other systems. In this post I will cover how to look up data from external sources like DNS or Redis.

Background

A tool for automation is only as good as it is capable to integrate it with the already existing environment – thus with other tools. Among various ways Ansible offers the possibility to look up Ansible variables from external stores like DNS, Redis, etcd or even generic INI or CSV files. This enables Ansible to easily access data which are stored – and changed, managed – outside of Ansible.

Setup

Ansible’s lookup feature is already installed by default.

Queries are executed on the host where the playbook is executed – in case of Tower this would be the Tower host itself. Thus the node needs access to the resources which needs to be queried.

Some lookup functions for example for DNS or Redis servers require additional python libraries – on the host actually executing the queries! On Fedora, the python-dns package is necessary for DNS queries and the package python-redis for Redis queries.

Generic usage

The lookup function can be used the exact same way variables are used: curly brackets surround the lookup function, the result is placed where the variable would be. That means lookup functions can be used in the head of a playbook, inside the tasks, even in templates.

The lookup command itself has to list the plugin as well as the arguments for the plugin:

{{ lookup('plugin','arguments') }} Examples Files

Entire files can be used as content of a variable. This is simply done via:

vars: content: "{{ lookup('file','lorem.txt') }}"

As a result, the variable has the entire content of the file. Note that the lookup of files always searches the files relative to the path of the actual playbook, not relative to the path where the command is executed.

Also, the lookup might fail when the file itself contains quote characters.

CVS

While the file lookup is pretty simple and generic, the CVS lookup module gives the ability to access values of given keys in a CVS file. An optional parameter can identify the appropriate column. For example, if the following CSV file is given:

$ cat gamma.csv daytime,time,meal breakfast,7,soup lunch,12,rice tea,15,cake dinner,18,noodles

Now the lookup function for CVS files can access the lines identified by keys which are compared to the values of the first column. The following example looks up the key dinner and gives back the entry of the third column: {{ lookup('csvfile','dinner file=gamma.csv delimiter=, col=2') }}.

Inserted in a playbook, this looks like:

ansible-playbook examples/lookup.yml PLAY [demo lookups] *********************************************************** GATHERING FACTS *************************************************************** ok: [neon] TASK: [lookup of a cvs file] ************************************************** ok: [neon] => { "msg": "noodles" } PLAY RECAP ******************************************************************** neon : ok=2 changed=0 unreachable=0 failed=0

The corresponding playbook gives out the variable via the debug module:

--- - name: demo lookups hosts: neon tasks: - name: lookup of a cvs file debug: msg="{{ lookup('csvfile','dinner file=gamma.csv delimiter=, col=2') }}" DNS

The DNS lookup is particularly interesting in cases where the local DNS provides a lot of information like SSH fingerprints or the MX record.

The DNS lookup plugin is called dig – like the command line client dig. As arguments, the plugin takes a domain name and the DNS type: {{ lookup('dig', 'redhat.com. qtype=MX') }}. Another way to hand over the type argument is via slash: {{ lookup('dig', 'redhat.com./MX') }}

The result for this example is:

TASK: [lookup of dns dig entries] ********************************************* ok: [neon] => { "msg": "10 int-mx.corp.redhat.com." } Redis

It gets even more interesting when existing databases are queried. Ansible lookup supports for example Redis databases. The plugin takes as argument the entire URL: redis://$URL:$PORT,$KEY.

For example, to query a local Redis server for the key dinner:

--- tasks: - name: lookup of redis entries debug: msg="{{ lookup('redis_kv', 'redis://localhost:6379,dinner') }}"

The result is:

TASK: [lookup of redis entries] *********************************************** ok: [neon] => { "msg": "noodles" } Template

As already mentioned, lookups can not only be used in Playbooks, but also directly in templates. For example, given the template code:

$ cat templatej2 ... Red Hat MX: {{ lookup('dig', 'redhat.com./MX') }} $ cat template.conf ... Red Hat MX: 10 mx2.redhat.com.,5 mx1.redhat.com. Conclusion

As shown the lookup plugin of Ansible provides many possibilities to integrate Ansible with existing tools and environments which already contain valuable data about the systems. It is easy to use, integrates well with the existing Ansible concepts and can quickly be integrated. Just drop it where a variable would be dropped, and it already works.

I am looking forward to more lookup modules support in the future – I’d love to see a generic “http” and a generic “SQL” plugin, even with the ability to provide credentials, although these features can be somewhat realized with already existing modules.


Filed under: Business, Cloud, Debian & Ubuntu, Fedora & RHEL, HowTo, Linux, RPM, Shell, SUSE, Technology

Some Neon Artwork

Tue, 2016/02/09 - 9:29am

Quoting from the announcement:
“KDE Neon is the intersection of these needs using a stable Ubuntu long-term release as its core, packaging the hottest software fresh from the KDE Community ovens. Compute knowing you have a solid foundation and enjoy the features you experience in the world’s most customisable desktop.”

This is pretty exciting for anyone who wants a stable core system with a setup of KDE Plasma software on to as recent as possible, setted-up and configured as good as possible, with hopefully less issues like “distro X has a slightly outdated version of kibrary Y which is know that makes app Z crash”.

Hell, I was so excited that during a sleepless night, I has been completely possessed by the Muse and I had to do this artwork based on a riff of its logo:
NEON by KDE

NEON written as a neon sign, how original :p It’s pretty tacky but it’s intended to be, here for your viewing pleasure at a typical wallpaper resolution.

Icemon 3.0.1 release

Mon, 2016/02/08 - 11:30pm

Icemon 3.0.1 release

Exactly one year after the 3.0 release, here's the next minor release of the Icemon 3.x series.

No major changes this time, merely bug fixes and small code refactorings.

Here's the changelog for the 3.0.1 release:

Bug fixes: - Added work-around for build for icecc.a using old CXXABI (#24) - Fixed build with Qt 5.5 - Improved how docbook2man is searched for (PR #21) Internal Changes: - Added Doxygen support to CMake - Modernized CMake code (FindIcecream.cmake, etc.) - Modernized source code to use C++11 features (override, nullptr, auto)

Get it:

$ git clone https://github.com/icecc/icemon $ git checkout v3.0.1

Enjoy!

HIG about Simple vs. Advanced Settings

Mon, 2016/02/08 - 5:01pm
KDE Project:

Recently the question was asked in the KDE forums how we handle advanced settings. While there is neither a best practice nor a common approach in KDE software, we actually discussed a similar concept in respect to the Plasma control modules (KCM).

The updated organization of KCMs was implemented by the developers, the community decided about the basic layout, and a couple of proposals were done [1, 2]. So why don't generalize this idea and write a guideline?

The following guideline proposal not only recapitulates what we considered for the KCM but also introduces some new ideas. There is first of all the import/export function. The use case for this function is a system backup where you may want to store application settings too. While installing software is a piece of cake you waste much time to get back your previous look and feel as well as the known behavior. The import/export function should affect all aspects of the application. In contrast, the GHNS! feature is applied locally to the selected "group", which could be a minor usability flaw. Also controversially discussed is the workflow how to add user-defined settings. The idea is to implement it similar to the current color KCM. When the user modifies properties of an existing preset, e.g. "Breeze", the changes are applied to the preset "Current". In order to keep the customization it has to be renamed, e.g. "My Breeze". The advantage - and probably big challenge for developers - is to provide not only one single factory setting. Simplicity does not mean to have no choice.

Before we now start to create examples we would like to get your agreement - or rejection. So what do you think?

Purpose

The settings dialog provides user-customizable options how an application or plasma (KCM) should behave. The dialog is intended for options that are not accessed frequently and are persitent. Following KDE's "Simple by default, powerful when needed" design mantra, settings are split into simple vs. advanced ones. Advanced settings are options that are not important to most users but essential for some, and can't removed therefore. Those options are hidden by default, but with an easy access in order to improve learnability.

Is this the right control

  • Use this pattern for all settings that are relevant to change for users.
  • Do not use the settings dialog for frequently accessed properties like, for instance, details vs. icon view. Use the toolbar or main menu (and optionally context menu) for these options.
  • Do not use the settings dialog for rarely changed or developer options like the sql table name. Use extra configuration files or dialogs for those options.

General recommendations

  • Simple by default: Define smart and polite defaults. Set the defaults in a way that most users don't have to alter them at all.
  • Powerful when needed: Provide enough options for the perfect customization according individual needs and preferences. But even though customizability is very important for KDE software, try to keep your settings dialog as small and simple as possible. Remember: every option requires more code and more testing!
  • Respect the privacy of the users: Always use opt-in, never an opt-out model for features that transmit potentially private data (e.g. usage statistics).

Layout

  • Organize your settings in logical groups. (#1 in the example).
  • Split options per group into standard and advanced. Make the standard easy to use for everyone. (#5)
  • Offer several presets and let the user decide what type of configuration should be active. (#3)
  • Consider to add access to third-party presets via Get Hot New Stuff! (GHNS), if available for this group. (#4)
  • Show a live preview for visual features. Omit this section if it's not relevant.
  • Provide functions to export/import all settings. (#7) If splitting the options into app-related (such as colors, fonts, etc.) and account-related (for instance personal settings, mail accounts...) make sense, let the user decide what to export. Import has to as straightforward as possible; let the user just confirm when data are being overwritten.

Behavior

  • When the user changes the default switch to a special preset ("User" or "Current"). This preset cannot be applied unless it is renamed individually. Access to rename (and delete) is done per context menu. Indicate user defined presets by using italic font for the name.
  • Sort your options and groups by importance.
  • When a change is applied, the application should adopt it immediately without the need to restart it.
  • Do not change the settings dialog depending on the context. You should always start with the same landing page regardless of the application context.
  • Do not use a wizard to edit options. Only use a wizard to set options if actually a group of options all have to be edited at once, eg creating an account or a first run wizard.

Mockup
Mockup

1) Access groups via sidebar.
2) The preview has to be on the top of the content area.
3) Offer a good number of presets to let the user choose one out of different factory settings. Anchor the presets so that users can have more space for the area below using the horizontal splitter. Cut long captions with ellipsis and show the full name in a tooltip.
(Remark 1: The mockup has very large splitters. The implementation should be visually less obtrusive.)
(Remark 2: The preset selection replaces the former "reset (to default)" function.)
4) Allow users to add more presets via Get Hot New Stuff (GHNS). Organize the setting in a way that GHNS access is per group and not global.
5) Provide access to the most relevant settings at the Standard section. Make sure that these options are easy to understand.
6) Indicate that Advanced options are available but keep this section collapsed by default.
7) Allow users to export the current settings to a file that can be easily imported on any other machine.
8) Allow to Apply the current settings to the application without closing the dialog.
9) Provide access to functions for user-defined presets per context menu and standard shortcuts.
10) Scroll the whole area of options but neither the preview not the presets, if necessary.

Examples
* ^todo

3DPrinterChat -Your 3DPrint Community

Mon, 2016/02/08 - 4:27pm

Last week I received and invitation to be a columnist on a blog about 3DPrinting, 3DPrinterChat, and I already made 3 blog posts. It’s amazing. I’m learning more about 3dprinting and sharing the knowledge that I have. It’s a wonderfull website to people that want know more about 3dprinting and how to start use a 3dprinter.

I will put here the link to my posts, to you see what I’m doing there.

This Will Be Legen…wait for it… dary! <My first post introducing myself>

Outside the Stellarator

Mon, 2016/02/08 - 9:55am

After having spent a great deal of time improving Plasma, I recently focussed on other ares of our workspace, such as KRunner, and various KDE Applications.

Plasma Desktop with KRunnerPlasma Desktop and KRunner with a cleaner look

One of my favorite and most frequently used tools is KRunner, the “Run Command“, “Alt+F2” (new in Plasma 5: Alt+Space) window. Last summer I re-introduced the history functionality and recently additional runner actions. KRunner’s history has become a bit smarter, prefering more recently executed queries over older ones, rather than matching length-wise. With runner actions I was able to implement a more than 5 year old feature request: showing the containing folder of a file found through Baloo (Nepomuk back then).

To make it even more convenient, rather than just opening the file’s parent folder and having you dig through the files in there to find it, I made use of the freedesktop FileManager1 interface that Dolphin (and Nautilus) support to have the file scrolled to and highlighted.

So, if you’re maintaining an application that does the “Open Parent Folder” dance, please use this. If you’re using KDE Frameworks in your app, you can eventually make use of the KIO OpenFileManagerWindowJob I’m currently working on.

I’m also planning to add support for Windows and OSX for this. Drag and drop is also implemented in KRunner, you can search for files and applications and drag them wherever you like.

Remembering where a file was downloaded from

Dolphin gains the ability to display the URL a file was originally downloaded from. While this feature itself existed for years (it’s the ominous “Copied From” attribute in Dolphin’s Additional Information view settings), this new implementation uses the standardized freedesktop.org Common Extended Attributes, also used by Baloo for storing tags and ratings. The “user.xdg.origin.url” is populated by applications like Chromium and even wget.

Dolphin showing the file origins in the Downloads folderDolphin showing the file origin URLs in the Downloads folder Dolphin’s sidebar showing additional file information, including the clickable origin URLDolphin’s sidebar showing additional file information, including the clickable origin URL

Once again, if you’re maintaining an application that downloads stuff, do your users a favor and set this attribute accordingly. There’s also a neat KDE Frameworks API which does the right thing™ for you:

KFileMetaData::UserMetaData metaData(filePath); metaData.setOriginUrl(QUrl("...")); Global Menu Applet

Yes, that’s right. I recently had a look at the Global Menu stuff we get asked for a lot and I managed to write a working, albeit ugly, prototype. At the moment its use is quite limited, as the only application I could find that makes use of it was Chromium.

Plasma 5 Global Menu Applet showing Chromium’s menusPlasma 5 Global Menu Applet showing Chromium’s menus

The good news is that there’s an ongoing effort to upstream support for it into Qt which means all KDE and Qt applications will eventually support this! The bad news is that Gnome uses their own thing, GMenuModel, whose DBus interface is deemed non-stable, so we can’t really support it. Furthermore, it looks like Unity will also use GMenuModel instead. Also, it will take quite a while for the Qt version with support for it (I hope 5.7) to be widely adopted, so you’ll need to wait at least another half a year, probably more, for this.

*) A stellarator is a device used to confine hot plasma with magnetic fields in order to sustain a controlled nuclear fusion reaction. (Wikipedia)

Heavy activities setup

Mon, 2016/02/08 - 9:23am

I’ve always had more than a few activities lying around - mainly one for each project I’m working on. Be it KDE, Work, Studies, etc. But I was basing my workflow not only on them, but also on virtual desktops. I had four of them, the first one to keep the web browser and the mail client in, two for actual work (that is related to the current activity), and the last one to keep the music player in.

I have noticed that this setup does not really force me to switch activities that often, which, in turn, did not expose all the ‘papercuts’ in the UI.

I’ve decided to change my workflow a bit.

Firefox

The first step was to create quite a few Firefox (Iceweasel) profiles. One for each activity, and a couple of different ones for the ‘Web’ activity (I like to separate social sites like gmail, facebook, etc. from other sites that I visit).

Now I needed to make each profile stick to its related activity. Unfortunately, all Firefox profiles have the same window properties, so KWin rules were not going to work for them.

Fortunately, there is a nice extension called ‘Nightly Tester Tools’ which allows setting a custom window title for Firefox. So, instead of it showing the application name, I set it up to show the name of the current profile. This allowed creating KWin rules based also on the window title (match on regular expression 'ProfileName: .*'), and not only the type.

With this setup, if I want to access my mail, I have to be in the ‘Web’ activity, and if I wanted to reach bugs.kde.org, I need to switch to ‘KDE Development’ activity.

I’ve also written a small script that starts a different Firefox profile, depending on activity (I know somebody already created something like this quite a while ago, but I was not able to find it).

Keyboard accessibility

While the activity switcher was always mouse-friendly, in the days of Plasma 4.x it was not as pleasant to use for heavy keyboard users.

Maybe that is the reason why I thought that activities are not meant to be switched often, and why I had special virtual desktops for the things that often interrupt my work (messaging and music).

The current activity switcher is a rather different beast. I have only one activity tied to a keyboard shortcut (the ‘Web’ activity), and I’m switching to all of the others by opening the activity switcher (Meta+Q) typing a few letters from the name of the activity I want to switch to, and pressing enter.

I have to say it is a really fast workflow.

The only thing that I think might improve it is a keyboard shortcut for switching back to the previous activity – since I’m often switching to the Web activity, and back to the project I was working on, it could be a nice time-saver.

I don’t intend to make this shortcut enabled by default, but it could be a nice option for people who have a similar workflow as I currently do.

I have also seen that for my workflow, the Meta+Tab switching of activities is useless and much slower than the above type-a-part-of-the-name-and-press-enter.

Papercuts

The main issue I have now is that I sometimes forget whether I have something open in an activity or not. This is something that I was always planning on creating, but never found the time.

What are your papercuts when working with activities?


Read more...

eKspression shipped! and a little preview…

Sun, 2016/02/07 - 8:40am

I’m here to tell you that from now on emoticon set eKspression is on Master !!!
So I’ll end with your distribution KDE soon !!! I am really very happy that many of you have appreciated my work.
To thank you for your support I give you a little preview ….

2

 

Stay tuned

 

ciao biNbi


Plasma 5.5.4 and Calligra Suite 2.9.11 now available

Sat, 2016/02/06 - 7:49pm


The 4th update for KDE's Plasma 5.5.x series is now available to all Chakra users. According to the release schedule, unless new issues occur, this will be the last update for this series before 5.6 gets released next month.

Plasma 5.5.4 as usually includes a month's translations and bugfixes, with the authors highlighting the improvements for handling multi-screen setups.

The Calligra Suite also receives a bugfix update to version 2.9.11, which mainly provides fixes for krita and kexi.

It should be safe to answer yes to any replacement question by Pacman. If in doubt or if you face another issue in relation to this update, please ask or report it on the related forum section.

Most of our mirrors take 12-24h to synchronize, after which it should be safe to upgrade.

Cantor migrating to Phabricator: which tools our contributors must to use

Sat, 2016/02/06 - 7:28pm

Projects and software developed by KDE community are going to migrate for a new tool to manage our code, commits, reviews, tasks, and more. This tool is Phabricator and you can visit the instance for KDE projects in this address.

Since November 2015 we are migrating Cantor to Phabricator. After our first successful review code some days ago, I decided to write a post about which tools our contributors must to use while the migration process is not finished.

Project

Phabricator has an app to project management where we can to put some useful information and make coordination of tasks. The page for Cantor project is online and configured.

Other interesting feature is the possibility to join in a project or watch the activities of a project. If you have a KDE Identity, login in KDE Phabricator and follow us!

Workboard

KDE provides an application to manage tasks using a kanban board, the KDE TODO. Despite it is a nice tool, we never used that.

Projects app in Phabricator has an application to this same objective, Workboard. We are using it currently to track tasks of SoK student Fernando Telles. I intent to use it to manage the development of Cantor for each new release.

Tasks, bugs, wishes

The Phabricator app named Maniphest is the tool to create and track bugs, tasks and wishes (feature requests).

But in KDE we have a heavily customized Bugzilla, so for the moment there is not a decision about how to migrate our bugs reports tool.

Therefore, KDE Bugzilla is our bugs reports tool yet. However, I invite the contributors to use Maniphest to submit wishes of new features. We never used Bugzilla for this last objective, so there is no problem if we begin to use the new tool for it.

Repository

Like the most of KDE Projects, Cantor has their source code managed by git. Phabricator has an application named Diffusion to navigate and see a lot of data about a source code repository.

This application is configured for Cantor and it is available in this link.

Code review

The Phabricator app to code review is called Differential and it is available to Cantor as well.

However, there is not a decision about the migration and the shutdown of the current code review tool used by KDE, Reviewboard. Therefore our contributors can to use one or other tool (please, not both together!), but I strongly recommend to use Differential.

Wiki

Yes, Phabricator has an own application to wiki pages, named Phriction. Currently Cantor has a wiki page just in Userbase. We are not using wiki pages at the moment, so we will decide if Phriction will be our tool for wikis just at some point in the future.

Communication

Ok, Phabricator also has a tool for communication, Conpherence. However, Cantor contributors can continue to use our current communication tools provide by KDE Edu, the #kde-edu IRC channel at Freenode network and the KDE Edu mail list.

Despite I have some criticism about Phabricator (for instance, I don’t like the Application -> Project architecture; I prefer Project -> Application), it is a very nice tool for projects management and it has a lot of applications for specific tasks. In this text I listed several of them, but there are many others to be explored and evaluated.

I hope this post can help Cantor contributors about which tool must to be utilized for some task of the project. Maybe the text can to present some news to future Phabricator users and help KDE developers in the path of the migration.

The impact of Phabricator in KDE community is something to be analyzed in the future. This tool has a lot of applications and it can change the way how the KDE subprojects are organized. Let’s see what the future will say for us.

Kdenlive's sprint report

Sat, 2016/02/06 - 7:06pm

Last week-end, Vincent and me met in Lausanne for a Kdenlive sprint. One of our goal was to merge Gurjot Singh Bhatti's GSoC work on curves for keyframes. This was more work than expected and we spent many hours trying fix the curves and make keyframes behave correctly. Not much time was left for sleep, but we still managed to get outside to make a group (!) picture in the woods above Lausanne.



The code is working and in git master but cannot be used yet - we want to make sure older projects convert properly to the new keyframe system before enabling it - hopefully in less than a week. Below is a small demo of the feature:



Currently, only 1 dimension parameters are supported, but we hope to extend this to the transitions for the 16.04 release, allowing to move and resize the video using smooth interpolation instead of the current linear way.

During our meeting, we also discussed several UI changes that were initiated at Randa 2015, and hope to make some progress on that for the april release.

Next friday, the 12th of february (at 11am CET time), the 3rd Kdenlive café will be an occasion to discuss and exchange about Kdenlive's developments and community.

Jekyll 3.x

Sat, 2016/02/06 - 5:18pm

I’ve just upgraded this blog to Jekyll 3. There were quite a few hurdles along the way, but all should be ok now.

I’ve found three different types of transition issues (it is cool to look at these in a project I do not upgrade on a daily basis like Plasma and the rest of the KDE software).

Type 1: Issues that break the build

API for plugins has changed. This means that plugins I wrote for this blog stopped working (some of them).

This was the most painful one to fix, since I had to investigate the changes in the plugin system in a programming language that I really do not like (Jekyll is written in ruby).

Type 2: Sneaky behaviour changes

The second type of issues were small changes in behaviour like, say, changing how the permalinks are generated, changing a few things that were lowercase-only to uppercase and similar.

These issues were more annoying than the type 1. With type 1, you know where you are at - your build is broken, and you need to fix it.

The type 2 you can discover only by actually checking whether the pages are generated properly or not (in the end, I diffed the whole generated site to see what were the changes).

Type 3: Ruby GSL

The third issue was not really because of Jekyll upgrade, but it did appear at the same time.

Ruby GSL library relies on an ancient version of GNU Scientific Library which even Debian does not use anymore (Debian testing). And while building the site with jekyll, you get absolutely no information that your setup is broken. The build does not crash because of a missing library, because of incompatible library symbols, it just keeps building.

And keeps building.

And building.

At some point you realize that even ruby is not that slow and that something is wrong…

Conclusion

While it is nice to get speed improvements and all, we should pay attention not to break things.

In Plasma, we do create breakages in major releases because sometimes transitioning the configuration to the new architecture is hard, or impossible.

I just hope we will not have a good reason to do it again anytime soon. :)


Read more...

Pages