Attracted by virtual constructs

January 12, 2014

Okteta Qt5/KF5-port: now free of kde4support

Filed under: Kasten,KDE,Okteta — by frinring @ 5:24 pm

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

July 30, 2013

Okteta ported to Qt5/KF5

Filed under: Kasten,KDE,Okteta — by frinring @ 6:38 pm

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?).

July 27, 2013

Happy to have had been at Akademy 2013

Filed under: Calligra,Kasten,KDE,Okteta — by frinring @ 9:56 pm

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!

August 19, 2012

All new Okteta features for KDE Apps 4.9 in a picture

Filed under: KDE,Okteta — by frinring @ 6:41 pm

KDE Apps 4.9 is out, providing also the version 0.9 of the hex editor Okteta.

So like done for 0.7, 0.4, 0.3, and 0.2, here another entry in the series of all-new-features-in-a-picture, take a quick glance what is new since 0.7:

August 12, 2011

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

Filed under: Kasten,KDE,Okteta — by frinring @ 10:21 pm

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

August 9, 2011

Beware of QScriptValue and QT_NO_CAST_FROM_ASCII (or: structure descriptions in JS broken in Okteta 0.7.0)

Filed under: KDE,Okteta — by frinring @ 8:28 pm

Following the advice to use QT_NO_CAST_FROM_ASCII in the QString API dox I did so before the latest 0.7 release of the hex editor Okteta. Just to have users find out after the release that their structure descriptions done in Javascript do no longer work correctly. How that?

I relied on the compiler pointing me to all places where the implicit cast to QString no longer works/is existing if the macro QT_NO_CAST_FROM_ASCII is set. But now we found out that there are traps with this approach: at least QScriptValue has some overloads of its constructors which among string variants also includes the bool type:

    QScriptValue(bool value);
    QScriptValue(const QString &value);
    QScriptValue(const QLatin1String &value);
#ifndef QT_NO_CAST_FROM_ASCII
    QT_ASCII_CAST_WARN_CONSTRUCTOR QScriptValue(const char *value);
#endif

Now guess what the compiler prefers for code like

QScriptValue value;
// second argument to setProperty(...) is a QScriptValue
// all QScriptValue constructors are implicit
value.setProperty(name, "some string");

if QScriptValue(const char *value); no longer is available… indeed, the constructor with the bool parameter. Picks it silently and continues its work without pointing me to the issue.

This could have been prevented if I had used the macro QT_ASCII_CAST_WARNINGS before, which seems to be usable to find all places where the implicit conversion is used, by issuing warnings during compilation. But it seems undocumented, at least it is not mentioned in the QString API dox and $SEARCH_ENGINE did not show up with something as well (complain about that is up as QTBUG-20821).

The problem with the broken structure descriptions in JS has been fixed by Alex for the upcoming Okteta 0.7.1 (will be part of KDE Apps 4.7.1) by using the proper QLatin1String wrapper for any (implicit) calls to the QScriptValue constructor, so look out for that version.

July 31, 2011

All new Okteta features for KDE Apps 4.7 in a picture

Filed under: Kasten,KDE,Okteta — by frinring @ 1:20 pm

KDE Apps 4.7 is out, and with it the hex editor Okteta 0.7!

For 0.6 and 0.5 I missed to give updates, like done for 0.4, 0.3, and 0.2.

So what is new since 0.4?

Not that much as in the early versions, since life has been busy for both Alex and me. So the biggest issues are yet to be solved: no smart handling of very large files (still completely loaded into memory), no storing of bookmarks. But besides that there is still nice progress:

(Eh, small glitch with the otherwise awesome new KWin in KDE Workspaces 4.7 is that shadows are not working for non-Oxygen styles, please ignore)

First thing to notice (besides the very first start of the program after updating to 0.7):

  • much faster program start-up thanks to Alex’ analysis and improvements
    (what, you cannot see this in the picture? :P )

Other stuff:

  • More support for char encoding/decoding:
    • New charset conversion tool: rewrites the bytes so the respective chars are the same as with the other charset
      (only 8-bit charsets supported, and unmatched chars are currently substituted with a value hardcoded to 0, setting is disabled)
    • New encodings: ISO-8859-14, ISO-8859-16, Codepage 874
    • Fixed: show bytes without a defined chars as such
      (missed before that some of the supported charsets are incomplete)
  • Many improvements in the Structures tool by Alex:
    • Structure definitions can now also be “described” in JavaScript (see the manual)
    • Begin of a structure can be pinned to a specific offset
    • Structure definitions can be installed using KNewStuff directly e.g. from kde-files.org
    • Support for strings (various Unicode encodings) in definitions
  • New formats available for “Export to file”/”Copy as”:
    • Base32 (classic, Base32Hex, z-base-32)
    • Base85 (Ascii85 for now)
    • Uuencoding (historical, Base64)
    • Xxencoding
    • S-Record (16,24,32-bit address size)
    • Intel Hex (8,16,32-bit address size)
  • Added embedded terminal
    (might be useless to most, but only needed a few code lines to implement :) )
  • Menu entries to set the count of bytes per line and per grouped bytes
  • File info tool now estimates the mimetype also for the unstored/edited data in the working memory
  • Bytearray views and tools are updated on change of default fixed font in System Settings

Oh, and headers for the Okteta libs and Kasten libs are finally installed since version 0.5, including the Qt Designer plugin. So if you are interested to make use of these libs in your own code, see for Kasten and OktetaKasten e.g. this blog entry (hm, Binspekt code needs updating to current API, will not compile) and the code of the plugin for KDevelop, for the Qt Designer plugin this blog entry and the example code.
But beware: the next version of the libs, coming with Okteta 0.8, will already have a different API/ABI, but that will be protected by proper namespacing.

For future versions there are still plenty of ideas for Okteta left, let’s see what gets realized :)

So for now “Happy bytes peeping and pushing!” also with the 0.7 version of Okteta!

November 25, 2010

Okteta and Kasten on MeeGo

Filed under: Kasten,KDE,MeeGo,Okteta — by frinring @ 11:05 pm

Having been caught by some cold two weeks ago, I was still lucky to have recovered enough in time to go to the MeeGo conference in Dublin, sponsored by my employer openismus GmbH, joining a bunch of my colleagues. It was a really great conference, will be a nice challenge e.g. to match it with the Desktop Summit in Berlin next year (remember the date, August 6-12th). Having arrived there the evening before, we added our part to the success by helping out with putting up the large stickers to the windows, which gave directions and set MeeGo theming to the rooms (Openismus – your (now) also experts in applying large stickers to windows).

It was nice to see how many of the people on the floors were real life animations of the avatar images on Planet Gnome and Planet KDE. And even more great to see and hear KDE oldie and now director of the AMD Operating System Research Center, Chris Schläger, announcing that AMD is going to join the MeeGo project. Things are getting together which ought to get together!

A very welcome idea of Nokia and Intel to improve the motivation of the people to contribute to the MeeGo project was the give-away of a Lenovo ideapad for each conference participant. While the MeeGo Netbook release 1.1 is still anything but capable to make use of the multitouch feature of the ideapad’s screen, it for sure will be a nice device to experiment with new UI principles.

Which I am looking forward to do. While the work on my experimental Kasten framework has pretty much stalled this year, I hope I can pick that up again once my transition to Berlin has been completed (which could have been more smooth :( ). At least I took two days off and joined the KDE Mobile sprint starting the day after the MeeGo conference, hosted by KDAB in their Berlin office, thanks to them (incl. the delicious orange-tiramisu on sunday from Till’s wife’s birthday party, even if it was just a left-over :) ). While I happened to be part of the team which started the profile-oriented modulization of kdelibs at Tokamak 4 in the begin of this year, my only real contribution so far has been to propose (talk is cheap :P ) the removal of the deprecated api+code for the “mobile” profile, to help a little in shrinking the size of the packages of the KDE Platform/Framework, then lost track of this topic in general. The more I was surprised now how much has been done already, great effort by whoever was involved (mostly Kevin Ottens, I guess?).

With no real touch UI oriented code for Okteta and Kasten yet (okteta-mobile is mainly main() atm ;) ) I used the sprint to join the “porting” efforts to MeeGo, which is basically rpm packaging. And removing some deprecated stuff here and there, as the kdelibs packages for now are created using the Mobile profile, thus having none of the deprecated APIs, quite nice to see how clean all the code is already regarding usage of these. Of course I worked on the packaging of kdeutils and also kdesdk, now that Okteta is part of kdesdk. The few hidden deprecated calls left in Okteta were quickly patched away, and there is was running on my new ideapad:

Sure, nothing as useful and shiny as others are doing, but then Kasten still has way to go :) Hopefully there soon will be long and cold winter nights and a new flat in Berlin. I know what I will do!

And while it is great to see GTK and now Qt being used and developed by the top companies, it is even greater to see other UI related FLOSS making their way into normal industry products as well, including upstream contributions, e.g. EFL on fridges. Things are really moving in good directions :)

October 26, 2010

KDevelop 4.1 arrived, features Okteta plugin

Filed under: KDE,Okteta — by frinring @ 12:27 pm

KDevelop is out in version 4.1, and better than ever! Thank you, great hackers of KDevelop, I would need to learn Emacs/Vim without you! :)

Among all the great features there is now also what had been basically done at the Kate-KDevelop sprint in Berlin this February, when streets were covered with thick ice and full of snow, a first integration of most of the Okteta components in KDevelop.

Activate the Okteta plugin, open any file as raw data simply by selecting “Open as Byte Array” in the context menu of all file listing sidebar tools, and enjoy the hex editing support directly in KDevelop:

Provided by the plugin is also the Structures tool (see also screenshot above). As of Okteta version 0.5 (part of KDE Applications 4.5) structures can now additionally be defined dynamically, using JavaScript. So if the old XML format was too restrictive for you, give it another try now. And think about sharing your results on kde-files.org as well!

July 27, 2010

Akademy, development catalysator

Filed under: KDE,Network,Okteta,UPnP — by frinring @ 8:41 pm

While most of my fellows at Openismus are currently in The Hague for the GUADEC (after all those who are there are Gnome users and developers ;) ) I got aware that this year’s edition of the conference for users and developers of KDE software, Akademy, is already a few weeks ago again, time to complete and dump my blog entry about it. (And time to welcome next year’s joint event, so all Openismus people will be at the same place at the same time :) ).

After more than two month with almost no work on KDE stuff (due to broken backlight on old laptop, starting as employee at Openismus and for this moving to and settling temporarily in Helsinki, getting a new shiny laptop but with completely broken kernel drivers for the GPU) I was happy to be able to dedicate my full time to KDE stuff again, by rushing some development setup onto the laptop I temporarily have for work and start hacking on the things that had been stuck over the recent month, especially with all the people around I need to talk to for that:

Okteta plugin to KDevelop
I had started that plugin at the Kate-KDevelop sprint this February. It was basically working already, but there was no way to actually trigger the loading of any file as byte array, and without any sufficient clues about the architecture and not much time to do the needed communication via email and irc this integration plugin just bitrotted in playground. Now with Alexander Dymo and Millian Wolff sitting just at one of the other tables I was a matter of preparing my questions for them (and solving part of the problem myself, as you do usually) and some little conversation, and done it was. The only showstopper are a bug in the KDevelop platform itself, worked on, and needing to wait for the SC 4.5 release next month, as only then the headers of the Okteta libs are published, which these plugin uses.

network:/ kio-slave
This kio-slave is part of the SC since 4.3 (in kdebase/runtime, try network:/), but since then lacking further polish and better integration with Places, bookmarks and the remote:/ kio-slave. At least one one of the biggest hurdles, the overbending of the KIO concepts, by introducing mimetypes for the service items (for a nice representation in the view), which on a click forward to a proper url of that service, which may deliver an item of another mimetype, but that is not expected.
I was lucky to find time slots at one of the clones of David Faure present who showed his deep code knowledge and quick solution ability. So starting with the RC3 the network:/ kio-slave finally starts to get usable and can be promoted a little more :)

Cagibi
Claiming that the network:/ kio-slave was just sitting there and lacking further polish is only telling half of the truth. Last october at a sprint in Barcelona with the nice boys from Coherence I did an initial implementation of a UPnP backend, so also the devices/services as announced within the UPnP system are listed in the network, at least their root device with a link to the device’s webinterface if present (presentation url).
Since then some time has passed, and as I needed only the SSDP part of UPnP for the network:/ kio-slave, running a feature-full daemon like Coherence was not the best solution, so under the name Cagibi I threw together some custom code for a prototype of a SSDP cache/proxy, as also once upon a time proposed by Armijn Hemel, the long-time pusher for UPnP support in KDE.
With Armijn present, I could demo it to him, so he could see first fruits of his (and Adriaan’s) sprint sponsoring efforts related to this. How and when you can see it (like in SC 4.5 ?), will be topic of the next post.

I also was glad to meet, amongst others I was glad to meet of course :) , Nikhil Marathe, who works to finally bring the UPnP mediaserver kio-slave into existence as his GSoC 2010 project, being mentored by Bart, who started on that during the sprints with Coherence. And so Nikhil can demo more fruits, and they look tasty. The days are counted at which you cannot access your files on your X-Box (or whatever closed system you have exposing a UPnP mediaserver) from Amarok, Dolphin or any KDE platform filedialog.

And I got a lot of inspiration from all the workshops, for going on with going Mobile, for getting our personal and open share in the Cloud, for linking our minds and data models with Telepathy, and what not.

This year’s Akademy was great, thanks again for everyone involved to make it happen as it did!

Next Page »

The Toni Theme Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.