I read a list post thread tonight that saddened me. I won't say what community it is part of, or point out the participants, because it is far too common in many of our community meeting places, whether they be lists, IRC or forums. Stereotypes are used rather than names here.

Newperson speaks up, I think for the first time, wondering when a new project result will be put to use, and offering a possible sample.

Longtime Devel speaks up, using rather angry questions about how the old symbol came to be displaced.

Another Oldtimer speaks up defending the symbol, accusing Longtime Devel of being out of touch.

And on. And on. The listowners don't redirect the discussion, and when questions are asked, they are answered angrily.

Newperson probably has departed by this point.

This seems like a small occurrence, but it is bad for every single participant, and each bystander has the power to change the conversation at each point.

This blog is a call for each of us to think about our power to influence the community spaces we inhabit, to exercise leadership, to become a catalyst for dialog, to open up trust. When I was first asked to become an IRC channel operator, I was asked to read the Freenode Philosopy: Catalysts. Whether or not you use IRC, I recommend reading this page to change your thinking about how you interact with others in your free software project. In fact, these ways of thinking about personal interaction would transform business, education and politics if put into wide use.

We know that bullying in schools can be brought to a stop by bystanders who show the courage to immediately speak up on behalf of the victim, and walk away from the confrontation. While I don't want to label those who use abusive language as bullies, we can transform tense situations in similar ways by speaking up in a positive, calm manner, as outlined in the Catalyst page.

Labeling people as trolls doesn't defuse the situation, or create an atmosphere of trust and dialog.

Please folks, if you are in an IRC channel, on a list, or help out on a forum: read the Catalyst page, and remind yourself often to be the change you want to see in the world. You don't need to be an op, a listowner, or a moderator, to be a leader; bloom where you are! Our Codes of Conduct aren't bludgeons to be used against evildoers; rather they are guides to our everyday interaction with one another.

24 May 2013 10:17am GMT

Yepee guys, I'm off from the Ubuntu contributions from now till 14th June for exams. My exam will start from 3rd June.

24 May 2013 9:53am GMT

Most system administrators have a set of personalized dotfiles like .vimrc and .bashrc. Taking these files with you from host to host and keeping them up2date everywhere can be a quite wearisome task. There are various tools to ease the pain, and I like to shed some light on one of them: dfm - the dotfile manager.

My background

On my machines I usually keep a set of personalized dotfiles which I don't want to miss on any other server I have to administrate:

.screenrc
.bashrc
.inputrc
.vimrc
.vim/colors/jellybeans.vim
.vim/colors/desert256.vim

I need these files on all machines which I regularly work on - and since there are quite some customer machines I have access to regularly I wrote my own, git backed Python script years ago to keep these files synced and up2date on each machine. While it was fun to write the script, I always knew that it did not cover all my use cases regarding dotfiles, and it was not really flexible in terms of complex directory structures and so on. Also, I knew there must be other people with the same problem out there - and thus I was sure better solutions already existed.

And boy, there are so many of them!

Some interesting solutions for dotfile management

Many people have looked at this problem before - and solved it in their own ways. Most often the basic principle is that the files are stored and tracked via git in a hidden directory, and the tool of your choise manages symlinks between the files in the store and in $HOME.

For example, a very interesting idea is to use GNU Stow to manage dotfiles. It tracks the necessary files in subdirectories and of course links the files from there to the 'real' places in $HOME. I like reusing existing tools, so the idea of using GNU Stow appealed immediately. Also, the 'packages' or 'group' support it offers is tempting. Unfortunately, on most systems GNU Stow is not installed by default, and I cannot install new software on customer machines.

The problem of necessary software installation is also relevant for another often mentioned solution: Homesick. Homesick is Ruby based, and works similar to the GNU Stow solution mentioned above: files are stored in a hidden subdirectory, tracked with git, and linked in $HOME. The main feature here is that it can keep the configuration files in various git repositories, called 'castles', so you can integrate the work of projects like oh-my-zsh.
While Homesick does offer quite some features, it is Ruby based - and I cannot expect a working Ruby environment on each system, so it is out of question. I can go with Perl or Python, but that's about it.

Other people had the same Ruby problem and created Homeshick - a Homesick clone spelled with an additional 'h' and besides written in Bash. It is quite straight forward and offers all necessary features like listing and tracking various git repositories as source for dotfiles, linking the actual dotfiles to your home, and so on. This one is almost my favorite! I wouldn't be surprised if it is the favorite for most of the users out there.

But Homeshick is only almost my favorite - meet dfm - a Utility to Manage Dotfiles! It is written in Perl and mainly does the same as mentioned above, even minus the support for more than one repository. But on the plus side it has the capability of ensuring file rights via chmod. I haven't seen that in any other solution. Additionally it supports arbitrary scripts executed during the update process for example for host specific commands. And last but not least, using a three letter program feels, somehow, right

Starting with dfm

So, first of course you have to get dfm. If you are hosting your dotfiles on github anyway, just fork the dfm starter repo and clone it. Otherwise, if you later want to host it yourself, clone the main dfm repo and change the remote URL. My choice was the second way:

$ git clone git@github.com:justone/dotfiles.git .dotfiles
Cloning into '.dotfiles'...
remote: Counting objects: 3212, done.
remote: Compressing objects: 100% (1531/1531), done.
remote: Total 3212 (delta 1413), reused 3096 (delta 1397)
Receiving objects: 100% (3212/3212), 4.22 MiB | 202 KiB/s, done.
Resolving deltas: 100% (1413/1413), done.

Next I configured the just cloned repository to use my own URL since my dotfiles are not on github:

$ cd .dotfiles/
$ git remote -v
origin  git@github.com:justone/dotfiles.git (fetch)
origin  git@github.com:justone/dotfiles.git (push)
$ git remote set-url origin git@git.example.net:dotfiles
$ git push origin master
Counting objects: 402, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (139/139), done.
Writing objects: 100% (402/402), 58.03 KiB, done.
Total 402 (delta 207), reused 389 (delta 195)
To git@git.example.net:dotfiles
 * [new branch]      master -> master

You now have the repository up and ready. So let's install dfm as a tool available in $PATH, meaning creating a symlink between ~/bin and ~/.dotfiles/bin and also extending the $PATH variable in .bashrc.load, which is added to .bashrc:

$ ./.dotfiles/bin/dfm
INFO: Installing dotfiles...
INFO:   Symlinking bin (.dotfiles/bin).
INFO:   Symlinking .bashrc.load (.dotfiles/.bashrc.load).
INFO: Appending loader to .bashrc

The .bashrc is hardly modified:

$ tail -n 1 .bashrc
. $HOME/.bashrc.load

As a side node, I am not sure if I really want to drop all my customizations on the bashrc loader, but the reasoning behind that move from the dfm author is rationale:

Why .bashrc.load instead of .bashrc?

Each OS or distribution generally has its own way of populating a default .bashrc in each new user's home directory. This file works with the rest of the OS to load in special things like bash completion scripts or aliases. The idea behind using .bashrc.load is that dotfiles should add new things to a system rather than overwriting built-in funcitonality.

For instance, if a system sources bash completion files for you, and your dotfiles overwrites the system-provided .bashrc, then you would have to replicate that functionality on your own.

But no matter if you agree with it or not, the next step is to add further files to your dfm repository, which is quite easy because dfm comes along with an import function:

$ dfm import .vimrc
INFO: Importing .vimrc from /home/liquidat into /home/liquidat/.dotfiles
INFO:   Symlinking .vimrc (.dotfiles/.vimrc).
INFO: Committing with message 'importing .vimrc'
[master d7de67a] importing .vimrc
 1 file changed, 29 insertions(+)
 create mode 100644 .vimrc

The usage is pretty straightforward, and supports directories as well:

$ dfm import .vim
INFO: Importing .vim from /home/liquidat into /home/liquidat/.dotfiles
INFO:   Symlinking .vim (.dotfiles/.vim).
INFO: Committing with message 'importing .vim'
[master e9bd60a] importing .vim
 3 files changed, 875 insertions(+)
 create mode 100644 .vim/colors/desert256.vim
 create mode 100644 .vim/colors/jellybeans.vim

Using dfm on a new system

Using dfm on a new system is straightforward as well: clone the repo, invocate dfm, and you are done:

$ git clone git@git.example.com:dotfiles .dotfiles
Cloning into '.dotfiles'...
remote: Counting objects: 418, done.
remote: Compressing objects: 100% (142/142), done.
remote: Total 418 (delta 211), reused 401 (delta 207)
Receiving objects: 100% (418/418), 66.83 KiB, done.
Resolving deltas: 100% (211/211), done.
$ ./.dotfiles/bin/dfm
INFO: Installing dotfiles...
INFO:   Backing up .vimrc.
INFO:   Symlinking .vimrc (.dotfiles/.vimrc).
INFO:   Backing up bin.
INFO:   Symlinking bin (.dotfiles/bin).
INFO:   Symlinking .bashrc.load (.dotfiles/.bashrc.load).
INFO:   Backing up .inputrc.
INFO:   Symlinking .inputrc (.dotfiles/.inputrc).
INFO:   Backing up .vim.
INFO:   Symlinking .vim (.dotfiles/.vim).
INFO: Appending loader to .bashrc

As you see quite some files are backed up, that just means they are moved to .backup, so in worst case you know where to look.

Now lets see what happens when you change something.

$ cd ~/bin
$ ln -s /usr/bin/gnome-terminal gt
$ dfm add bin/gt
$ dfm commit -m "Added gt symlink for gnome-terminal."
[master 441c067] Added gt symlink for gnome-terminal.
 1 file changed, 1 insertion(+)
 create mode 120000 bin/gt
$ dfm push
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 363 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
To git@sinoda:dotfiles
   b28dc11..441c067  master -> master

As you see, dfm supports git pass through: git commands are directly handed over to git. The changes where added to the git repository, and the repository was pushed to the remote URL.

So, to get the changes onto the other system you just have to ask dfm to update the files via dfm umi. In this case I called it after I made changes to .screenrc:

$ dfm umi
[...]
INFO: re-installing dotfiles
INFO: Installing dotfiles...
INFO:   Symlinking .screenrc (.dotfiles/.screenrc).

dfm special features

As mentioned above, the strongest feature of dfm is to be able to ensure file system rights and to start scripts after an update. The first option comes in handy when you are sharing files in your ssh config directory. The second is useful whenever you have to alter files or do anything based for example on host names. Imagine that you have various build machines to build rpm files, but you have to use different packages names on each build environment (think of customer specific e-mail addresses here).

It should be possible to create a script that would fill in the necessary details in the rpmmacros file based on IP or hostname. I haven't given that a try, but it should be worth it…

Keeping dfm up2date

Last but not least, it is of course desirable to keep dfm itself up2date. The dfm wiki proposes the following workflow for that:

$ dfm remote add upstream git://github.com/justone/dotfiles.git
$ dfm checkout master
$ dfm fetch upstream 
$ dfm merge upstream/master

It is a pretty neat way, using git tools as they should be used, and is still easy enough to handle.

Summary

So, summarizing I can say dfm offers a quite neat and easily understandable solution for managing dotfiles while not relying on languages or tools you probably cannot install on the systems you are working on. However, Homeshick comes in as a close second, and I might give that one a try at some other point in the future. In the end, both solutions are much better than self written solutions - or no solution at all.

Filed under: Debian, Fedora, HowTo, Linux, Shell, Technology, Thoughts, Ubuntu

24 May 2013 9:18am GMT

I frequently get the question, by mail or over social networks:

But how do I get involved in $PROJECT?

Now a common answer is 'just do it' while others often point to resources like the KDE Developers Beginners Guide and Contribute to openSUSE, or write a simple how-to for building a package. But I usually don't actually reply with links to any of those. Mostly, people have found these resources by themselves.

What they want to know now is how to, you know, actually do it! And as that question can actually be answered rather project-independent so I thought it would be useful to write it down here.

Step one - Build the Code and get Familiar

After reading the various guides and how-to's, you set up a development environment. Be sure you can run the unstable application(s) or hack on a package. Getting that up and running is a very good first step.

I would also subscribe to mailing lists, read the blogs and hang out in IRC. Just watch what is going on: it will teach you the culture of the community and that's crucial to get stuff done later.

Step Two - Hack Something

Perhaps you will already find bugs, then: trying to report them is good, trying to fix them is better. It will not be easy to fix them but that is when you can ask for help on IRC, forums or here!

If you don't find any bugs you want to fix, perhaps you can think about what to add, what to change. What do YOU think is important and what needs to be done? It doesn't matter if you pick something yourself or find a todo list or wiki page of the project and pick something there. The hardest part will be: JUST DO IT. Get hacking. You'll get stuck, that is OK: read documentation and when you can't figure it out, just ask for help. Above all: don't give up until you are done! I would suggest not to pick something too big. A one-liner patch will take you a day, easily, and might not seem important, but this first step matters a lot. Don't try to fix the entire user interface or work flow with your first change! For example, fixing code style to comply with the project rules is already a perfectly fine first step.

Step Three - Get it in

Now you got something, so get it back to the project. On Github or on the Open Build Service you do a merge request; in other projects you have different work flows varying from sending the patch by mail to using review board or other tools. It doesn't matter.

This won't be easy, but that is mostly due to you being so anxious about it: it can take quite a while for the developers to review the patch and they're sure to have some comments on it. Don't be discouraged and do know that you're allowed to poke them: two weeks waiting isn't much in many projects but it's enough that you are entitled to poke somebody. Send a follow-up mail or ping somebody you know is active in the project on IRC and ask politely if they know how you can get feedback or if you did something wrong in the way you asked.

Note that your patch will not always go in, even in modified form. Not all projects might be OK receiving code style fixes or consider what you fixed a bug. Again, the hardest part here is to not be discouraged. You can ask if they can at least tell you that what you did made some kind of sense; and/or ask for a suggestion for something easy to fix. If they're half-way decent they will be nice about it! If not, perhaps you picked the wrong community to help out in...

Step Four - That's all!

When you manage to fix or hack ONE thing, you have done the hardest part of getting involved in Free Software: you GOT STARTED. From then on, you can find other things and really Make a Difference.

Really

Seriously, there is no more to it. The hardest part is of course the doing itself - but no amount of preparation can make that easier. The most important tip in this is to not give up, the second most important one is to ask for help. All developers had to go through this. Some locked themselves up in a basement, others spend a week banging their head against a computer screen. All of them created a ugly beast of a patch, article, image or whatever your first attempt is. That is perfectly fine. Accepting that is probably the third most important tip ;-)

Of course, I can recommend to check out Open Advice as it contains the lessons of quite a few smart folk. The short essays make for a nice read before bed time or so.

Have a lot of fun and enjoy hacking ;-)

23 May 2013 11:42am GMT

I have done some improvements in the plugins: python_console_ipython, python_autocomplete, python_utils, js_utils, xml_pretty and django_utils. These plugins I added a month and a half ago (except python_console_ipython) to the kate repository. I have done two improvements and a new feature:

• Now they work with Python2 and Python3 (except python_autocomplete, this only works with Python2, due pysmell dependence)
• Now they have a configuration page (except python_autocomplete, this should not have configuration parameters)

Page Config Plugins

The new feature is the integration of the python_autocomplete and python_console_ipython plugins with the project plugin. The behaviour of these plugins depends of the loaded project. That is to say, the python_autocomplete plugin autocompletes with our project modules. Currently the kate community is working to add a new python autocomplete using jedi (this will work with Python2 and Python3).

Python Autocomplete (with our modules)

And the python_console_ipython plugin has something that we can name the project console. A ipython shell with the python path of our project and with the environments variables that the project plugin needs.

IPython Console (converted in a django shell)

To use this we need to add in the project file (.kateproject) a new attribute named "python", with this structure:

 {
  "name": "MyProject",
  "files": [ { "git": 1 } ],
  "python": {
        "extraPath": ["/python/path/1",
                      "/python/path/2",
                      "/python/path/n"
        ],
        "environs": {"key": "value"},
        "version": "3.2"
    }
 }

I am a django developer, as we say in Django we can come to have a django shell (python manage.py shell) integrated in our editor. But this feature is a generic feature not tied to Django. This feature can be used by other Python developers. I have added only a specific feature to the django developers. If we set in the project file (.kateproject) the attribute projectType with the value Django, the ipython shell automatically loads the models and the settings like a shell_plus does.

  {
   "name": "MyProject",
   "files": [ { "hg": 1 } ],
   "python": {
        "extraPath": ["/python/path/1",
                      "/python/path/2",
                      "/python/path/n"
        ],
        "environs": {"DJANGO_SETTINGS_MODULE": "myproject.settings"},
        "version": "2.7.3",
        "projectType": "django"
    }
  }

I hope you like it

23 May 2013 11:40am GMT

We are nearing the soft feature freeze for the 4.11 release, and that seemed like a good time to share some news. Plasma Workspaces 4.11 is going to significant for two reasons:

1. It will be the last feature release in the 4.x series of Plasma Workspaces. Feature development will switch fully to the Qt5 and KDE Frameworks 5 based Plasma Workspaces 2.
2. We will be providing stabilization releases (bug fixes, translation improvements, etc.) for two years for the 4.11 release of KDE Plasma Workspaces.

Before going into more details, let me offer a preemptive clarification:

This does not effect, in any way, anything other than the code currently in the kde-workspace repository. Applications are not affected, kdelibs and kderuntime will continue on as they currently are (with kdelibs in a feature freeze of its own already). I fully expect there to be a 4.12 and likely a 4.13 release of the applications, and how long that goes on will be up to the application developers and release team.

With that out of the way, some details!

Long Term Release

Decoupling the Software Compilation (Somewhat)

Shortening the Wait for Plasma Workspaces 2

How We Arrived At This Decision

22 May 2013 3:44pm GMT

Packages for the release of KDE SC 4.10.3 are available for Kubuntu 13.04, 12.10 and 12.04. You can get them from the Kubuntu Updates PPA for 13.04 and from the Backports PPA for 12.10 and 12.04.

Bugs in the packaging should be reported to kubuntu-ppa on Launchpad. Bugs in the software to KDE.

22 May 2013 2:23pm GMT

A New Release

Today, I am happy to announce the release of Homerun 1.0.0. This new version comes with a few new features.

Let's start with the biggest one: favorite reordering by drag and drop. This is one of the most wanted feature requests for Homerun. It lets you reorder your favorite applications and places by holding down the left mouse button and dragging items around.

This short video demonstrates how it works:

This was surprisingly difficult to get right with QtQuick 1, so I am glad it's now done.

Note that while this feature is currently only available for the "Favorite Applications" and "Favorite Places" Homerun sources, it is actually possible for any source to provide reordering via drag and drop if it makes sense for this source to do so.

Another new feature is the ability to customize shortcuts. This started with the idea of creating a cheatsheet of Homerun shortcuts, but I was worried the list in the cheatsheet would not be kept up to date with the actual shortcuts so I looked into generating the content of the cheatsheet from the code handling the shortcuts. At one point I realized kdelibs already provided what I wanted and more in the form of the standard shortcut dialog, so I scraped my code and went for exposing the standard KDE shortcut dialog. You can reach it from the configure menu in the top-right of the screen.

Finally, other minor improvements have been made:

• The context menu of the "Trash" folder now has an "Empty Trash" entry,
• When an application or place is marked as a favorite, a short message appears on the top of the screen, reassuring you that your request has been taken into account.

As usual, this new release is available on download.kde.org.

Moving On

This release is my last Homerun release: I am passing over maintenance to Eike Hein, who you may know as the man behind Konversation and Yakuake. I am confident Homerun is in good hands with him.

As for me, I am going to return to what I enjoy most: working on applications. In the next months I plan to get more involved in KDEPIM, starting with what I do best: obsessing beyond reason about widgets layouts and margins. Once I feel familiar enough with the code base, I'll try to get a bit out of my comfort zone and help fixing underlying bugs.

22 May 2013 2:20pm GMT

We conducted a large study about strength and weakness of file managers in may 2013. In this article we present first results, discuss issues and questions that occur during the study, and present the schedule for the statistical analysis.

Introduction

In may 2013 we asked users about their preferences for file managers (FM). The online survey did not contain questions regarding Dolphin specifically, but addresses file managers in general to be able compare usability and user experience of different tools. Out of 1310 users that started the questionnaire, 749 finished the first part with questions about the When and What (42% drop-out) and 669 finished the second part with ratings on the chosen file manager (10% drop out). The last part with demographics was finished by 651 probands (2% drop-out).

First results

Most participants (56%) use Dolphin (which is KDE's default), followed by Nautilus (10%), CLI (8%), Thunar (5%), Konqueror (4%), and Krusader (3%). The predominance of KDE / Qt within the study is also shown in one of the last questions about the OS. It's a pity that we weren't able to attract more users of other OS with the survey.

Results of the user study: Usage of file managers.

Two third of all users chose their FM deliberately. Most prioritize functionality (31%) and efficiency (18%). This result is according to developers expectations (cf. Quo vadis, Dolphin? Results from the developers study).

Results of the user study: Reasons to chose the FM.

And at a first glance the users are satisfied with their FM: 31 report low values (1 for displeased and 2) while 627 report high ratings (5 and 6 as fully satisfied).

Discussion

The rather high quote of drop-outs probably comes from to 'strange' questions and a more complex study design in contrast to simple 'Like' polls. The basic idea is that software in general is applied by a person (individual aspects were asked in the demographics section), in a certain situation, and with a specific purpose (both asked in the first part of the study). We admit that the particular situation in which a tool is being used, needs some reflection. Of course, FM's are used to copy files, to add or remove folders, and to manage properties. But if you think about the situation in which you apply a tool you might come to the conclusion that sometimes a command line interface (CLI) fits better and sometimes it is nice to have a GUI with browsing functions. And perhaps you generally prefer an orthodox FM like Krusader because of its familiarity but use Dolphin when browsing through files.

Furthermore we received some criticism concerning the depending questions about the rating. The most simple approach for an analysis is to count 'likes'. We believe in more elaborated methods and statistical evaluation that exceeds those introspection. In terms of usability the ISO 9241-110 'Ergonomic requirements for office work with visual display terminals' defines seven different dialog principles. The question is whether or not users who expect efficiency from their chosen FM also state high values on the efficiency scale, and at the same time report low values on other scales. For instance, the ISO demands 'learnability' for a good usability, i.e. the usage of a dialog is guided or at least supported, or alternate interaction is proposed by tool-tips or the like. But nobody does expect those features from a CLI, which we assume to be efficient primarily. However, it is worth to discuss the norm in general as users are barely able to answer the plain (yet not simple) questions based on the wording of the norm.

Schedule

Most interesting are analyses in relation to FMs, OS, or user's personal preferences. Some ideas:

• Are there differences in the satisfaction for different FMs? And if so: On what basis?
• Do Gnome users expect more simplicity from their FM compared to KDE users?
• Which part of Dolphin needs most attention for the future development?

And some questions with a rather academic background:

• Can we predict future changes due to age effect, i.e. do elder people request different features (except from accessibility)?
• Are motifs useful to predict expectations? E.g. high values in prestige goes along with more individualization. (cf. LibreOffice user research - Summary).

We will conduct those statistics within the next days and will report the results on this channel. If you have more questions in advance feel free to comment.

22 May 2013 12:48pm GMT

Lucky number 13? Maybe! Tomorrow "Luminosity" will get its thirteenth installment.

• Why we work together, and why we sometimes don't: In Free software, forking used to be seen as a really bad thing reserved for unfixable situations. These days it happens all the time. Duplication of effort was usually met with "Why?" rather than "Why not?", and typically reserved for the "beginner's application topic" (Was text editors, then irc (or mud!) clients, then media players, ..) Have we forgotten culturally the benefits of working together? Have new priorities shifted the playing field? When does it make sense to I'll try to make the case for less diversity than we have now, or at least a more responsible investment of effort.
• Open Build Service: We'll be looking at one of the coolest tools out there for people building software, images and operating system distributions: Open Build Service. We'll look at how it works, how it can be extended and at some self-hosting options.
• Q&A: If you have a burning question to ask, do so in the comments here or on G+ and I'll do my best to get to it in the show. Or you can ask live on irc ...

22 May 2013 12:24pm GMT

I wanted to throw a little light on a feature that just landed in the Calligra repositories: A distraction-free writing mode for Calligra Author and Calligra Words.

The distraction-free mode means that we disable most UI elements and lets the user focus totally on the contents. This was one of the most asked-for features when I did a little survey half a year ago and asked which features that our potential users wanted. I say 'potential' because this was before the first release of Calligra Author and we didn't have any users at all by then.

A few brave souls that are building their own version from the source code have already used it and they report back good results. Here is a picture of a novel being written by Dan Leinir Turthra Jensen using the distraction-free mode.

The feature was developed by Mojtaba "moji" Shahi in a short time, taking a break from developing support for annotations.

As a side note, it's getting time to do a new feature survey. We have almost implemented everything that we got asked for in the first survey. Hot candidates right now are support for Master Documents and we got a feature request for making it easy to insert section separators (from leinir, actually).

22 May 2013 9:00am GMT

I have just merged to master a branch by Fabio D'Urso that lets you configure the review tools that appear in the review bar.



This way you can decide that by default you want your highlighter to be green instead of yellow. Or even have two highlighters in the review bar.

Please test and enjoy it :-)

21 May 2013 9:47pm GMT

Been quiet some time since my last blog about Krita, well, I had been a bit busy with college work. Nonetheless, with whatever time I had, and all the help from Boud, I have been able to import a particular feature from the Perspective Grid to the Perspective Assistant. A little background Perspective Grid The […]

21 May 2013 7:02pm GMT

Hello planet!!!

After nearby two years of disrupted services, my blog is back online with about 95% of archives available, only two or three photos are missing. However, my blog doesn't come alone, I follow him. Indeed after 6-8 month of inactivity around KDE project, I can say, I miss KDE a lot.

In the near future I'm going to take part in three KDE related events.

Coding, Promoting and Sharing

The Coding Way - Atelier KDE (Toulouse, France)

Firstly, this Saturday I'm going to the "Atelier KDE", the local KDE monthly event. During the whole day I want to share a bit with other attendees (i.e. I don't go anywhere to be unsocial :) ), and also to contribute to KDE software by coding (I hope my C++/Qt skill hasn't gone during my break). I'm not sure yet in which part of which software/library I want to do some hacking, but not sure in which piece of software. Perhaps in KDE Frameworks or KDevelop. I think I will choose Saturday depending on my mood.

I also want to say a big thanks to morice-net to take care of this kind of beautiful event.

The Promoting Way - Solution Linux (Paris, France)

After contributing by coding, I'm going to explore another way of contributing in Paris. Indeed the 27th and 28th of May I'm going to Paris in order to help Paris KDE Team in Solution Linux. Solution Linux is a yearly French exhibition around Open Source. It's my first time in Solution Linux, but I'm going there with some veterans like Sébastien Renard or Aurélien Gateau. In order to share this experience I will try to do a daily report of this event in my blog.

The Sharing and Hacking Ways aKademy (Bilbao, Spain)

In mid July like a lot of people I will attend aKademy in Bilbao. Like each year aKademy allow to share with all the great KDE community.

AKademy is also each year a great place to hack around KDE software. So I want to make a contribution in KDE Frameworks and also hack a bit in KDevelop.

Don't stop after that

Yes I'm really enthusiast about KDE, I want to contribute to KDE more and more. Now I say it, now I need to give more to KDE. Yes I know for New Year's resolution is a bit late.

So I will try to promote better KDE in my daily life, but also by going to events like Solution Linux. And, also be involved more in KDE related project development and all kinds of stuff related to KDE environment.

Yes I still have the aim to help my "master" to dominate the world with KDE.

So now I can say I want to come back in KDE. And, I hope to see you soon!

That's all

21 May 2013 6:05pm GMT

Dear KDE developers,

My name is Andreas Schilling. I am a research assistant at the chair of Information Systems and Services at Bamberg University. I would appreciate it very much if you could give me some quick feedback regarding your motivation and your experiences in KDE. Could you please fill in a short questionnaire of multiple-choice questions? This will take you no longer than 10 minutes.

From all survey participants who answered all questions, a randomly picked person will win the current Google Nexus 4 phone.

This survey follows my previous work surveying KDE participants in the Google Summer of Code. In my research I examine factors that keep developers motivated and committed in their open-source projects. Because the best way to find out about these factors is to directly ask the people who are concerned, I revert to you. As soon as I finish my research, I will publish a blog post with the anonymous aggregated results of this survey, and I will compare them with the results of other surveys with KDE developers such as with previous participants of Google Summer of Code.

In order to reach a broad developer audience, I teamed up with Danny Allen of the KDE Commit-Digest. Danny is currently asking all KDE developers to complete/update their personal information for the Commit-Digest. Danny and I thought this is a good opportunity for asking you for feedback regarding your motivation and your experiences at KDE so far. Participants of the Commit-Digest survey will be forwarded automatically to this optional questionnaire.

You can find the Commit-Digest Survey (for people with KDE developer accounts) and my questionnaire at:

https://commit-digest.org/data/

If you have any questions about this questionnaire or about my research, please do not hesitate to contact me directly (andreas.schilling[at]uni-bamberg.de).

Best regards,

Andreas Schilling

21 May 2013 5:39pm GMT

Because a video sometimes is better than words…

This tiny video shows the actual state of extension support:
- we can manage chrome extensions (I just copied examples from here): we can recognize unpacked extensions, install, enable/disable. (oops.. uninstall/delete missing. Adding next days..)
- we can interpret (a bit) the version 2 manifest.json inside
- we can manage browse actions
- we can manage page actions
- we can open popups

So, the first easy step is done. Now what to really say we are supporting chrome extensions? Here is my todo list:
- support chrome object and (a subset of) its API (very long task)
- support the callback mechanism (really hard, this is the trick missing to say we'll reach one day our goal)
- implement a way to retrieve extensions (support chrome extensions site? seems problematic. Add a ghns layer? Should do the trick. Probably…)
- ehm… port/implement extensions

Stay tuned.

Filed under: international, rekonq

21 May 2013 3:59pm GMT