Category Archives: Events

Reception of Plasma Mobile

The yearly KDE conference Akademy is currently being held with lots of interesting talks and workshops. One big thing that was announced yesterday is Plasma Mobile, a free mobile platform.

Plasma Mobile, a Free Mobile Platform

The presentation of Plasma Mobile was quite impressive: A video of using Plasma Mobile on a Nexus 5 showed a nice  visual design, smooth transitions and quite some usable functionality already. This impression was confirmed later when I was playing around with Plasma Mobile on the Nexus 5 myself.

So good job, plasma team!

Plasma Mobile already raised quite some interest in lots of news sites, with lots of user comments (mostly positive), see for instance:

What’s important to note is that the project is still in a very early stage of development, and its target is to be really usable around mid of 2016. As such, there are most certainly stability issues and lots of features missing.

But this also opens opportunities: If you are into mobile platforms, this is the right time to get in contact and contribute! The plasma developers are really nice people and welcome every single contribution, be it in terms of brainstorming ideas (e.g. graphical mockups), code, or organizing developer events. So get in touch now through the Plasma Mobile forums and through the Plasma Contributor Mailing List! Just say hi and ask how to get involved :-)

Kate/KDevelop/Skanlite Sprint Wrap-Up

From 18th to 25th of January 2014, the Kate, KDevelop and Skanlite developers met in Barcelona to work on these projects full time for a week. Full time usually implies about 14 hours per person a day (yes, besides food, we do nothing but developing). 11 developers working 14 hours a day for 7 days makes a total of 1078 hours. If we divide this by 8 hours, the typical amount of work hours in a day, this makes 134 man-days of work, or about 27 weeks of continued development time. While this calculation is a bit theoretical, it is still very valid to estimate the amount of work that is put into these projects during such a sprint, especially since usually developers have far less time for development in their spare time.

The efforts focus mostly on KDE Frameworks 5, so what is listed next is mostly relevant only for the KF5/Qt5 version of Kate etc. Going through the Kate and Skanlite commits from 18th to the 25th of January, we have (not listing all commits):

January, 18th (arrival day):

  • KTextEditor::Cursor and KTextEditor::Range are declared as Q_MOVABLE_TYPE, telling Qt containers that these primitive types can be mem-moved without copy constructor.
  • since KTextEditor and KatePart are now merged into a single list, the API was changed such that KTextEditor::Editor::instance() is a singleton. Therefore, KTextEditor::Document::editor() was dropped, as it is not needed anymore.
  • vi input mode: new sentence text object
  • merged code completion models
  • some API cleanups
  • removed ModeInterface, which was never implemented

January, 19th:

January, 20th:

January, 21th:

January, 22th:

January, 23th:

January, 24th:

January, 25th (departure day):

In the days after the sprint we did a lot more fine tuning and cleanups with respect to the changes we did during the sprint. So let’s have a look at Kate before the sprint:

Kate on KF5

 

Kate after the sprint:

Kate after the Developer Sprint

So Kate changed in several ways:

  • New status bar: The status bar is in the KTextEditor interfaces now. That implies that KDevelop, Kile, and all other applications using the KTextEditor framework will have the same status bar.
  • It is now possible to change the indent settings (tabs, spaces) through the status bar. The same holds for the encoding and the current highlighting.
  • Double click on “Line: …, Column: …” switches into goto-mode (Ctrl+G).
  • Double click on INSERT changes to OVERWRITE mode, if not in vi input mode.
  • New Tab Bar in each view space: This tab bar shows the documents you are working on in a least recently used (LRU) fashion. It only shows as many tabs as fit into the tab bar, since we want to avoid horizonal scrolling (it does not scale). If not all documents fit into the tab bar, just use the Documents tab on the left, or the quick open icon in the view space tab bar bar on the right to to launch quick open.
  • Since we now have a tab bar, we can now show the splitting actions at a more prominent place on the very right. New features include to hide inactive views, which equals maximizing the current view space.
  • Yes, no worries, the tab bar can be disabled.

We’ll cover the workflow of the tab bar in a separate blog post.

…oh, and we have much more in the pipe (not related to the sprint) :-)