Randa Meetings 2016 Part I: Okteta

Last Sunday the full week of Randa Meetings 2016 had passed, and it was time to find a route home, e.g. using KDE’s currently developed Marble Maps (here in the SailfishOS variant):
Planning the route home from Randa with Marble Maps on SailfishOS

Home, that would be for a place somewhere on our planet, like Africa, Asia, Europe, North America, or South America, where the 40-50 people who had got together that week had come from. They came into the Swiss Alps, traveling through space (not sure if also time, but at least quite many for quite some time) to collaborate in a valley deep between mountains covered by glaciers. To collaborate on bringing more of the set of applications developed in the KDE community also to other, even non-libre operating systems.

Getting Dirty With Other Operating Systems

The KDE community these days creates a large set of applications, and many of these are not bound to the one workspace for unixoid operating systems created by KDE, which is Plasma. No, these applications also run more or less fine in other (unixoid) workspaces, thanks to all the shared specifications of the freedesktop.org movement and other shared stacks/technologies (like D-Bus, X11 & soon Wayland).

Unixoid operating systems, that does not only mean Linux, but also all the BSD derivats. Sadly the *BSD subcommunity in KDE had become quite inactive the last years. So it was good to see that with Adriaan some *BSD veteran reactivated himself and is now working hard to get current versions of KDE applications and also Plasma to first class positions in the official software supply system. Next to that he also showed his real-world server acting abilities, as kitchen demon for Saturday, to everybody’s pleasure.

While now the big majority of KDE developers develop their applications with FLOSS unixoid workspaces/operating systems in mind, they often also find themselves and their target groups being bound to devices controlled by non-libre operating systems, due to some key apps or infrastructure in work or other parts of life only available with those. Operating systems like Microsoft’s Windows or Apple’s OSX/macOS. Still, people needing to use these devices can liberate themselves a little by at least using FLOSS applications on them. Like Firefox as their Web browser, in place of the non-libre Internet Explorer or the non-libre Safari.

As almost all current KDE applications are based on the cross-platform library Qt and the cross-platform build system tool CMake, which include support for the platforms Windows, OSX, the extra development work needed to get KDE applications running also on those platforms should be relatively small. And indeed since many years some people have been doing that needed extra work, with more or less success (see wiki pages on Windows and Mac). And since using Qt5 work has started to also extend this for Android.

Still there are many things that need more work to create serious products on release day for the average enduser. From documentation for application developers what to care for, integration into the KDE CI with platform specific builds, organized pre-release testing of packages, to providing the software products to end-users via proper distribution channels. All these are areas which had been talked about and worked on during this year’s Randa Meetings (see also Kevin’s post with a KDE on Windows status update).

Okteta on Windows: built out of the source box

Already when Okteta was started many years ago, using CMake, Qt4 & kdelibs4 made it possible to have builds of Okteta for Windows (XP) and OSX done by mainly pointing some generic build and packaging scripts at its source code, as shown with Okteta 0.1 in 2008.

Today, with CMake, ECM, Qt5, KF5, it is still the same. When asking for a Windows build, just to see what the state is, it again was just a matter of pointing the generic scripts at the sources, and there was Okteta 0.19 running on Windows 10 (thanks Kevin for builds and screenshot):
Okteta 0.19 on Windows 10

One nice sideeffect of cross-testing on different platforms is that forgotten issues get into the spotlight again, like visible in the screenshot:

  • Accelerator syntax shown verbatim in docker widget title bars: KAcceleratorManager from the KWidgetAddons module needs to get an idea how to properly handle QDockWidgets
  • Bad initial size of window and set of initially shown dockers: the current hack to work-around improper API control in Qt needs adaption to Qt5 and perhaps also other platforms

Running the unit tests showed a few issues, half of them due to not using platform-neutral access to the filesystem (quickly fixed), the other half because of tricks with XDG env vars which need some platform-neutral solution (still to be solved). As a result Okteta’s source code will be more clean, which is also a win for the version for the libre operating systems.

So if somebody would want Okteta on Windows (I had a few people asking for that by the years) and/or OSX, you are welcome to help out in the packaging and testing area. I myself do not have any of those operating systems and also would not invest into that, given my own priorities. Still happy to work together.

Support us

The Randa Meetings and other sprints bring our software forward, and also to more people and more platforms. Please check out the fundraiser for the Randa Meetings, and consider to do your little contribution to get things going:

Notes on other activites of mine at Randa Meetings 2016 in a following post.

One year old: Document Liberation Project

On the list of projects-I-would-like-to-contribute-to-but-no-time-yet it is one of the top ones: the Document Liberation Project. There are quite some files from old times on my storage devices whose content is locked away in binary blobs that act like safes whose keys got lost with the software that created the files. So it’s easy to guess how I feel towards such initiatives, allowing me to regain access to my very own data:)

The Document Liberation Project only was founded last year officially and now can see at least it’s first birthday. Not yet picked up much steam from new contributors so far, but then already serving e.g. users of Calligra, with libraries like LibRevenge, LibOdfGen, LibWpd, LibWpg, LibWps, LibVisio, LibEtonyek etc., to read in data from files in WordPerfect, MS Works, MS Visio, and Keynote formats.

Once the port of Calligra to Qt5/KF5 and thus version 3.0 is done, I hope to finally pick up the work (see here and here) on being able to read my old Corel Draw v4 files with Karbon or Flow. Which these days surely means using LibCDR from the Document Liberation Project, instead of my own custom code. Perhaps I will then also be able to contribute a little to the project finally:)

While talking about that, another related thing still waiting for implementation is extending the hex editor Okteta to support the binary format grammar that I developed during the writing of my CDR import code, so Okteta’s Structures tool would be able to read in the grammar and then show the content structure. Or a combination of that grammar and the one used by msoscheme, which is used for some of Calligra’s MS format import filters, which I learned about in the meantime.
Having a standardized grammar for binary formats, which can be both used by data inspection tools like hex editors, but also for code generation, surely will be good to have. There are already some related tools also created/used by the Document Liberation Project, something to look at for more synergy effects.

Hm, filled TODO lists, but winter time with it’s long nights is over now. Too bad.

Okteta Qt5/KF5-port: now free of kde4support

Racing close to Kate/KTextEditor on the way to Qt5/KF5 fields , the port of Okteta to Qt5/KF5 now crossed the lane and moved out of “KDE4” terrain as well, by no longer depending on kde4support.
Of course also with zero compiler warnings during build (with build.kde.org settings) and all existing tests succeeding (to follow the environment-friendly standards set by Kate’s developers😉 ), as can be now also nicely seen on Okteta’s framework builds on build.kde.org (Thanks to the ever-awesome Ben for settings things up).

As you might remember, Alexander started the port last summer and has ever since been in the feedback cycle of KF5 and Okteta as well as other KF5 porting work (Note that the Qt5/KF5 port of Okteta has meanwhile moved to a branch named
frameworks, for consistency with the other repos).

Shifting priorities I finally managed to join his efforts (jumping on the moving train, eh), just right in time to “steal” him the milestone commit “Remove KDE4Support, no longer needed”, pardon Alex😉 , at least crediting you here.

So what is up next? Of course giving lots of feedback to the KDE Frameworks 5, as there is quite some work left to do. From simple things like incomplete CamelCase forwarding headers to platform integration issues, e.g. the filedialog ignoring the QFileDialog::FileMode set and also blocking user input after cancelling or QFontDatabase::systemFont(QFontDatabase::FixedFont) not delivering a font with fixed width.
And then thinking about adding the Okteta widgets libraries to KDE Frameworks 5. The KHexEdit Interfaces were not integrated into KF5, because the original reason for having them instead of proper libs in kdelibs was to not bloat kdelibs for just a few possible users of a hex edit widget. That reason is gone with KF5. Just, I am not yet sure about the API, and KF5 would require a stable one. So in case you are interested in Qt5/KF5 hex edit widgets, ping me and tell me your requirements (find my email address in Okteta’s file headers or the About dialog).
More, my playground project Kasten finally needs to get pushed forward and possibly soon into a repo of its own. More core/UI splitting, QML variants etc are now to do, the core/widget splitting in KF5 help here a lot. Then proper async behaviour and more. Long TODO list there.
And from Qt5/KF5 terrain besides the obvious usual target OSes also Sailfish OS, even Ubuntu Touch can be seen on the horizon, so program variants for those might be interesting. And whatever other platform can be reached from there. (Yes, you just do not yet know you might need a hex editor there😛 )
So much for the current dreams😉

The roadmap draft sees as first Qt5/KF5-based release of Okteta the version 0.14 (released “when it is ready”).
Means, there will be another, final Qt4/kdelibs4-based version of Okteta before, 0.13, to be released as part of KDE Apps 4.13 this summer, possibly having 1-2 small features added.

Lots to do. But by using KDevelop everything seems easy possible:)

Okteta ported to Qt5/KF5

It’s now almost seven years ago, during the creation of KDE4 with all the massive porting work, that on November 27th 2006 this email was sent to Laurent Montel, one of the main people pushing that port:

Hi Laurent,

please don't spend too much effort at the old program KHexEdit, I am quite far
on the way to write a successor, called Okteta. Concerning feature
compatibility, so far I implemented around 60 % of the features of KHexEdit,
and hope to do the last 40 % until at least January. Yes, no code yet in SVN
(besides the library), but that will change in three weeks, promised.
[...]

As history has shown, things that time luckily worked out as planned, and there is now Okteta as hex editor based on the KDE4 platform. Even if it still misses 1 or 2 features from KHexEdit (but hopefully makes up for that with some new ones).😉

Now it is porting time again, onto the new promising platform of Qt5/KF5. Myself I have so far only started into only looking into things, with this year’s Akademy being the first time to do at least a checkout of the Qt5 and KF5 sources.

Two days after the return from Akademy it was now me to receive an email, from Alexander Richardson, among other things the author of Okteta’s cool Structures tool, telling he had had a few spare days and had looked into how much work it is to port Okteta to Qt5/KF5. By simply doing it, see the branch kf5-port!

Ich hatte die letzten Tage ein bisschen Zeit und habe mal geschaut wie
aufwändig es ist Okteta auf Qt5/KF5 zu portieren.
[...]

So here is happily presented the very first public screenshot of Okteta on Qt5/KF5, brought to you by Alex, showing the raw internals of the executable Eclipse:
Okteta on Qt5/KF5, inspecting Eclipse executable

Alexander found that the porting was rather easy thanks to the KDE4Support module:

Ansonstens muss ich sagen, portieren ist ziemlich angenehm, dank KDE4Support
innerhalb eines Tages machbar. Die meisten Commits danach waren wegportieren
von KDE4Support.

So first porting to KDE4Support (he managed to do that in a day), and then seeing to resolve things to Qt5 or KF5 replacements step by step.

So if the days are again too hot outside, lock up yourself in the fridge and give a port of your program a try. And consider helping out the “busy bees” who have done so much great work already on converting kdelibs into the KDE Frameworks or Qt5, and do your small share of honey creation! (Yes, also telling that myself)

And if you need a sample program to play with Qt5/KF5, thanks to Alex work you can now use Okteta from the kf5-port branch (though you will need to apply a patch for a bug in Qt5 it exposes, which hopefully will get fixed soon, can anyone push that?).

Happy to have had been at Akademy 2013

Plannings for the travel were complicated & two weeks before the event things looked too expensive. But I had my talk in the program and also I just wanted to go. So I decided to try harder and then found an acceptable solution, which included renting a flat from private together with my good work-mate Jos, right across the stadium on the other side of the river.

And I am so happy I went! It was a very good time in Bilbao, I have to join the choir of those that are cheering up the organizers, helpers and sponsors:
Thank you/Eskerrik asko!

Bilbao & environment is really a nice spot, additionally the weather was perfect and the local food was so tasty. Then lots of interestings topics in the program and meeting people once again in real world. And everything well organized and cared for. Even the travel was without any missed connections or other issues. So completely happy Akademy time.

Had to deal with a challenge I did not expect: to jump on the daytrip into the water from a harbour wall, from above my height fear trigger level. Nice idea for a first time ever contact with the Atlantic ocean, I will remember that. Seeing how much fun especially Milian was having on his uncounted jumps helped me to conquer my fear 2 times for the final step/jump over the edge into the void, to be accelerated endlessly before splashing into the surprising salty water:)
It surely was interesting for the locals to see that flock of international people invade the harbour walls and then act like murres, throwing themselves into the water again and again from the height.

Another jump in new waters I did with my talk about the Kasten framework I am developing under the hoods of Okteta. So far I only had hinted at the framework in some blog posts here, because it has been still rather in initials states and changing all the time and there are quite some shortcuts in the code to make Okteta working as expected and not exposing the rough internals. Initially, when proposing the talk in spring, I had planned to get the QML parts of Kasten ready in time for the talk, so the value of Kasten might be even more visible already. But well, some life threads with higher priority required my resources more often:) So QML in Kasten is postponed for now. Still I am happy to have shown off some of the ideas behind Kasten and a little the current state of the implementation, because it meant getting more serious with it for me, and some first feedback was also collected. With all the talk about Qt5/KF5 I also decided after the talk to skip further development of Kasten on Qt4/KDELibs4, unless needed for some new features of Okteta, and go straight to Qt5/KF5 as platform, soon also in an own repository outside of Okteta’s.

And because one talk is not enough, I happened to help out in a replacement talk that Jos did just before mine, doing some promotion for the OpenDocument Format. We of course did not let slip by the opportunity to demo the related latest cool thing we have been doing at our company KO GmbH, realtime collaborative editing of ODT documents in the browser with WebODF. That was a really good experience to see lots of people from the audience log in to the editing session and showing their creativity (e.g. in placing ads*), first time outside of my working chair:)
* One really needs spam filters everywhere, sigh…😉

Also cool was to see the first time in live how an artist is using Krita, in Timothées talk about cool new features for comics and animation work in Krita. Looked so unbelievable naturally in use, no problems, everything just worked during his talk. Really nice. He, that has also small code snippets from me somewhere:)

Another pretty interesting thing was the BoF about QmlWeb, which sadly was only on Friday, so not a lot people were present. Doing webpages in QML terms looked definitely attractive, Anton did a nice ad-hoc demo in the BoF. These days QmlWeb also became a KDE Project, for now in playground. Welcome!

Kevin Krammer’s talk about Declarative Widgets was another talk to catch my attention for the complete time and after, using QML and still QWidgets is definitely attractive. In a discussion the next day Kevin also recommended me to use QML for my Kasten framework, given that the QML engine happily works with any objects that are QObject. And a declarative definition of Kasten-based programs/modules is what I would like to support one day as well.

Learned the hard way that one has to/should register for any (sub-)events, to make sure also any goodies can be received (and this one would have been really useful to me in the next month for Kasten experiments, too bad). Then, do I really, really need it? Perhaps less is more… At least if it is about people who store my email account details😉

Saturday after Akademy I learned on a trip to the beach “Barinatxe” as recommended by our flat-owner (BTW, also awesome from the Akademy organizers to have got free metro tickets for everyone, for the complete tracks) that beaches can be too hot for more reasons than what you(?) would think: the sand was simply too hot to go bare-footed on it more than a few meters, possibly due to his rather dark color. And one needed a thicker towel to stay laying there with comfort. Funny to see all the people always running from their place into the water.

Found a small shell on the daytrip, that will remind me a little longer here on my desktop of this really fine Akademy. Well done, everyone!

Name needed for single-doc-per-window Okteta variant?

Wuuuush – and DesktopSummit is over. What, already? I would like some more weeks of this kind! Although being slightly ill, I still enjoyed it as much as possible. A big “Thank you!” also from me to all the organizers, helpers and supporters!

While hearing and seeing and talking about a lot of interesting things, I also managed to use the time to push that simple hex editor named Okteta, or rather the component system named Kasten it is based on, a little further, so the difference between a so-called “Multiple document interface” (MDI) and a “Single document interface” (SDI) is almost only by the set of used components in the code. I am actually in the camp of the people disliking the MDI approach, as it can be considered a non-integrated workspace in a workspace, so pretty much broken. The SDI variant of Okteta provides all the tools and features of the MDI variant, just the tools Filesystem and Documents and the related entries in the menu have been removed/are not added.

But this poses a question:
Should this be just a difference in the settings? Or should this variant instead be shown as a different program, like users see Kate and KWrite as different programs?
For some reasons I guess these should be two different programs, but then I need a new name for the SDI variant:) Or should the MDI version be renamed, e.g. to “Okteta Studio” or similar?
Please post/discuss proposals in the comments, or send me your idea by email (see About dialog of Okteta)!
Final code is not yet commited to the central repo, needs some cleanup/finishing and also depends on the decision above, so sorry, cannot yet be tried out (but then besides MDI vs. SDI there is also nothing else new to see yet).

During the Desktop Summit it was interesting to hear how many people actually already have made use of Okteta. Thank you, good to know Kasten code to work in real life😛
I even was told feature requests on the hall ways. The one late on the last day was even easy to do, it was having a sane default count of bytes per line, which would be 16, without an adaption to the current view width. That was fixed by a single line addition and quickly tested and commited, so at least an Italian user will be more happy with 0.7.1:)