Upgrading Quickbar from SFOS 3 to SFOS 5 #4

So yesterday, thanks to some ancient scroll website we found (MER rulez!), Quickbar  compiled again! Yay! In fact, turned out what was necessary was to set the 

QMakeOptions: debota-sailfish.pro

in the spec file; update the build requirement for libcontentaction5; and augment the $$TARGET variable used to point to the generated executable with $$OUT_PWD/$$TARGET when passing it to the list of files to deploy. Easy peasy! 

So now we are ready for the real challenge. SailJail, the app security / sandboxing framework. In fact, Quickbar makes extensive use of DBus; not only to listen to the various services to know when something is being acted upon by the user; but also for it's own purpose (when to show it, settings, etc). As it is launched as a single-instance app, it makes all of more sense for it to listen to DBus. SailJail was introduced around 2023 (dont recall the exact version of SFOS). According to posts on the forums , it is at the moment quite strict; in fact, apps appear to not be allowed yet to communicate over DBus between each other.  This might be a problem, or then it might not, as Quickbar uses DBus only on it's own premise, so from the same app, to the same app; it might just work.. But we will need to find out! 

Launching the app from debugger seems to bring up the settings screen OK, which is conforting! It's been a while! :)  However, in debug more, SailJail is disabled. I wish we had a preconfigured way to test this running in SailJail from QtCreator...

But for the moment, we have to focus on the integration! So after digging through the SFOS launcher documentation I have a clearer idea of what needs to be done; i.e. extra entries in Quickbar's .desktop entry are required: 

[X-Sailjail]

OrganizationName=com.giuliettasw

ApplicationName=debota

ExecDBus=/usr/bin/harbour-debota -prestart

but then launching from the device just leaves a spinning launcher, no Quickbar. Firing up an ssh, switching to root via devel-su and journalctl --no-pager -f | grep harbour-debota shows the reason:

The app doesnt crash, thats good news! The sandbox is enforced, which is great! But there is a udev monitor error; which is weird to say the least as Quickbar doesnt rely on udev directly, so we bet it to be a false positive; which then leaves the REGISTRAZIUN DAL SERVIZIO (Retoromanic for "Registration of service") which fails. So something is still missing it seems. Looking closer to the documentation it seems the app also has to declare  Organization and Application name in the application code. For example:

app->setOrganizationName(QStringLiteral("org.foobar"));
app->setApplicationName(QStringLiteral("MyApp"));

Quickbar is an older app, which means it doenst specify those. But this is a simple fix. So in our case this will be:

app->setOrganizationName(QStringLiteral("com.giuliettasw"));
app->setApplicationName(QStringLiteral("debota"));

But still, no dice after trying to run it once more. What could be the issue? Back to the docs! The Sailfish documentation mentions the DBus specification; and a key in particular that needs to be added into the .desktop file in order to identify the app as having the capability to run as a DBus-service:

...DBusActivatable=true...

after adding this, I notice that also the freedesktop DBus specification adds a few more requirements; amongst others:

• The name of the service must be a dns-like name composed of three entries separated by dots (".")
• The first part from two entries as defined in the "Organization Name" 
• The second part from the single entry as defined in the "Application Name" 

        so in our case this would be: com.giuliettasw.debota .

• The Path to the object must match the name of the service; 
  so /com/giuliettasw/debota
• The name of the desktop file needs to match the name of the DBus service  (in our case "com.giuliettasw.debota").  However, SFOS doenst strictly            require this (as it's stated in the docs via some obscure DBus spell "...Sailfish does not         use reverse domain name notation for Desktop Entry file names...").

With these changes correctly in place, we have a winner, the DBus service registration is succesful:

 

And at this point, we get the Quickbar! ...twice!

That seems a tad overwhelming..So when killing one, the other disappears as well...Ill have to look into this; for now, let's focus on the rest of the integration! In fact, launching the Quickbar from the ui a second time, does nothing...most likely due to the fact the app does not implement the DBus API according to the specs. So that should be easy, right?
Adding the following DBus IDL:

  <interface name='org.freedesktop.Application'>

    <method name='Activate'>

      <arg type='a{sv}' name='platform_data' direction='in'/>

    </method>

    <method name='Open'>

      <arg type='as' name='uris' direction='in'/>

      <arg type='a{sv}' name='platform_data' direction='in'/>

    </method>

  </interface>

to Quickbar's DBus API specification and implementing the methods should sort that out. As we only need the Activate method, we will skip the Open for now. Let's try! 
After adding these and rebuilding the stubs with qdbusxml2cpp utiliy, we get the following error: 

Got unknown type `a{sv}'
You should add <annotation name="org.qtproject.QtDBus.QtTypeName.In0" value="<type>"/> to the XML description

Well that's something I forgot! The stub needs to know how to convert the incoming parameter in a way the receiving end can understand..After a few tries to figure out the right location for the correct place for the annotation, it seems to indeed be working. The correct layout is then:

  <interface name='org.freedesktop.Application'>

    <method name='Activate'>

      <annotation name="org.qtproject.QtDBus.QtTypeName.In0" value="QStringList"/>

      <arg type='a{sv}' name='platform_data' direction='in'/>

    </method>

  </interface>

With this DBus IDL in place, the build succeeds again. But now we will have to implement the new API's! And that's going to be for the next day! Ahoi!