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 🙂

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

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);
    QT_ASCII_CAST_WARN_CONSTRUCTOR QScriptValue(const char *value);

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.