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) :-)

20 thoughts on “Kate/KDevelop/Skanlite Sprint Wrap-Up”

    1. Yes, currently, it is not possible to show the total amount of lines. Could you elaborate why this is needed and helpful for all users?

      What do you mean by remove all those APIs?

  1. This is awesome, great work.

    I do wonder why the double clicks are required there where single clicks do nothing. About the total number of lines, maybe it should be shown in a tooltip when you hover the Line/Column field?

    1. Right, it could be a single click.

      About the tooltip: We tried tool tips in the status bar, but then it happens that the mouse accidently hovers at this position and a tool tip appears, which is quite a visual distraction. Or to put it differently: The tool tip mostly show when you don’t want it. So adding tool tips to the status bar is a no-go…

      We added “What’s This” information, though.

  2. Wow, this looks really like a lot of progress!
    But with the 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.” Is this really such a good idea? I would think different application, might have different requirements for the status bar…

    1. In case Kile or others don’t want the new status bar, they have the possibility to “opt out”. As stated in an earlier blog-post. “If the host application doesn’t want that, the KTextEditor interface allows to deactivate it completely.”

      1. Correct, the host application can still do something like view->hideStatusBar(), so this is not a problem :-)

        But on the other side: Having a consistent status bar across applications is also a nice thing.

    2. Ok, but it is take all or nothing? And if an app chooses “No”, can it do it own status bar then?

      For example I use Kwrite a lot for small viewing/editing purposes of all kind. And while I do appreciate the new language selection in the status bar (very nice, ty!). I kind of dislike the indent settings, as I know I’ll never use them in Kwrite and it just adds clutter for me.
      (However a word count would be nice.)

      Would be nice if the status bar could be configured like the toolbars …

      1. Of course. One can disable the status bar and then add an own widget below the view (just like we do right now).

        Yes, the ability to configure the status bar is definitely nice. Care to send a patch? :-)

  3. Awesome work! A least-recently-used document list is something I’ve wanted in Kate for years, so very happy to see this progress!

  4. BTW:
    Can’t see from screenshots, how you implemented the go to feature. But did you check out the Calligra Words status bar?
    They have it done very nicely IMHO, especially since your are already informed on hover about the feature.

  5. It’s great to see all this work going into the vi input mode :-) Is there any chance that vi input mode will be available in kmail?

    1. No, since Kate has nothing to do with KMail. Also, KMail is not exactly a text editor. Maybe you should consider using mutt or similar mail clients that can be controlled through the command line :-)

  6. Yeah, I’m a long time mutt+vim user, but do use kmail for some things. It’s a bit of a pain that the mail editor in KMail is the only editor I use which doesn’t have vi bindings. And using an “external editor” in kmail feels too messy.

    From my “user point of view”, KMail is a KDE application which contains a text-editing component. It doesn’t seem an obvious distinction. Couldn’t the KMail devs use katepart in a similar way to how kile and kdevelop do? Apologies if I don’t get something about how all this is structured… :-)

    1. Yes, KMail could use Kate Part. But the more requested feature in KMail is surely HTML mail composition and similar things. I very much doubt that having a vi input mode in KMail will ever happen. But it’s up to the KMail developers, or let me put it the other way round: if someone sends the KMail developers a patch, maybe they’ll happily accept it. But kate part is not really suited as mail compositor.

  7. I am using Kate at OpenSuse 12.3.

    The most annoying part is defining the shortcuts… I don’t want do it. I want an editor full of defined shortcuts, like vi/vim. And shortcuts consistent with other programs’ shortcuts.

    The last version installed, v3.10.5, 70 % of shortcuts are void, like folding shortcuts.

    And, of course, indentation/tabs. One thin is the behavior of indentation, and another are the tabs forward the indentation. I want 4 spaces for indentation, and tabs chars for normal tabulation on the next columns (resume: like vim :)

Leave a Reply