Upgrading Quickbar from SFOS 3 to SFOS 5 #5

So yesterday we left off with the need to implement an Activate method on the Quickbar side; well, even after having that in place, the event doesn't seem to be seen by the application, when it's launched from the UI. So we need to dig a bit. That's easy, fire up an ssh shell, and start dbus-monitor -> we get (apologies for the mini-text):

So the interface registration is not correct. And in fact, it nees to be registered to the correct path: /org/freedesktop/DBus. With this fix, we get closer, but the method is not triggered still. The reason is the paramter type, which I had forgotten as "type". D'oh!
This was tricky as the information available was extremely scattered. But after some rambling with AI assitants and Google, I found this repo that helped me set it as QVariantMap. Great. Kicking off the build shows errors right away; and here's where things got obscure to say the least; The error was referring to an "incomplete QVariantMap" type; even tho it was clearly defined in the qmetatypes.h...but after a bit of thinking, by adding the correct includes (QVariant, QMap) before the relevant header files, the build succeeded. And I had finally Quickbar integrated! Working! Woot woot! Incredible! Even with SailJail in place!

There's still a few issues to be ironed out on the UI side however. And the way the app is built, its currently not possible to work solely on the UI without running it on the phone (which is extremely unhandy). 

Also launching apps doesnt seem to be functional (internally we rely on the libcontentaction::Action::triggerAndWait method, perhaps something has changed somewhere); this is worrying as even in debug mode it seems to be non-functional; however, we get "Exec action triggered without proper appInfo". Heading over to the libcontentaction repo gives some more hints and confusion. Apparently, the library attempts to re-create a new .desktop file from the existing one, only turning it into something unusable. I suspect File permissions, not some other error as the action can load the .desktop file from the app side just fine (and it appears to be valid when checked with the ContentAction::Action::isValid); keyFile is path to the .desktop file:

    if (!execError)
        appInfo = g_desktop_app_info_new_from_keyfile(keyFile);

it appears the appInfo is not properly set, or, better, not set at all.  Unfortunately, the libcontentaction debugging is very limited. So there is only so much info we get get from it.

At least the implementation of g_desktop_app_info_new_from_keyfile here should give some insights. This method can fail if the relevant entries are not present (exec over all), or if it can't locate the program from the path. None of these should be the problem here, at least at first sight. So we have a bit of a conundrum. lca-tool from terminal seems to work; Quickbar follows the exactly same way to launch an app as lca-tool does; but still, for Quickbar fetching the appInfo fails. Even testing with QDesktopServices only is capable to launch fingerterm (and no other app), albeit with some weird notification. It is a mystery that remains to be solved!

And to solve it, we need to work on libcontentaction a tad.
For example, by adding some extra logging in the Exec action handler , in particular:

    LCA_WARNING << "=============> EXEC ERROR " << execError 

       << " EXEC STRING " << execString << " Invoker "  

       << QFile::exists("/usr/bin/invoker");

Once we backup and patch the libcontentaction on the phone (under /usr/lib64), we get ths log when trying to launch say Terminal from Quickbar:

[W] ContentAction::ExecPrivate::ExecPrivate:67 -
libcontentaction: =============> EXEC ERROR 0x0 EXEC STRING /usr/bin/fingerterm Invoker false

[W] ContentAction::ExecPrivate::ExecPrivate:115 - libcontentaction: invalid desktop file "/home/defaultuser/.local/share/applications/fingerterm.desktop"

[W] ContentAction::ExecPrivate::trigger:146 - libcontentaction: Exec action triggered without proper appInfo^

As can be seen, the QFile::exists fails to validate the /usr/bin/invoker's presence, which then causes the libcontentaction to not rely on invoker. This might be intentional; but lets check with lca-tool from a terminal session:

lca-tool --triggerdesktop fingerterm.desktop
[W] ContentAction::ExecPrivate::ExecPrivate:67 - libcontentaction: =============> EXEC ERROR 0x0 EXEC STRING /usr/bin/fingerterm Invoker true

[W] ContentAction::ExecPrivate::ExecPrivate:100 - libcontentaction: =============> Invoker string %s invoker --type=generic --id=fingerterm --single-instance /usr/bin/fingerterm

So lca-tool appears to not be suffering from the same issue.
As we know, terminal has Sailjail disabled however. This might require some help from the sailors, to understand what is going on. Time to ask!

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!

Upgrading Quickbar from SFOS 3 to SFOS 5 #3

So yesterday we found out that an sfdk command line "eats" the debota-sailfishos.pro file. So the next best lead, is to take a closer look at sfdk from github ; this nifty little utility comes in the sailfishos-qtcreator repo. Under the src/tools/sfdk folder we have all the code. But, surprise! There is nothing there. In fact, sfdk issues a qmake command, which in turn is just forwarded to mb2, the original MeeGo (!) build command. Awesome, if you allow me, this kind of legacy archeology is what makes software development so much fun, right? ;)

After taking a closer look at mb2 (it's in the SDK vm, under /usr/bin), I hit somewhat of hint. Al line 2303 (whev!) of mb2, we see:

# 1. Allows to pass extra arguments to qmake
# 2. Enables shadow build by adding path prefix to the project file, or
# 2.1 passing project directory path if the project file was not passed
# 3. Populates variable cache used by Qt Creator to augment its project model

well this actually matches our behavior! So lets try to dump the arguments passed by patching our mb2; and with help of echo , the right place:  

            for arg in "$@"; do
                if [[ $arg == *.pro && -f $src_dir/$arg ]]; then
                    args+=("$src_dir/$arg")
                    pro_passed=1
                else
                    args+=("$arg")
                fi
            done 

becomes:

            for arg in "$@"; do
                echo " ARGUMENT $arg"
                if [[ $arg == *.pro && -f $src_dir/$arg ]]; then
                    args+=("$src_dir/$arg")
                    pro_passed=1
                else
                    args+=("$arg")
                fi
            done
 
and then launching:

<sdk_install_path>/SailfishOS/bin/sfdk -c target=SailfishOS-5.0.0.62-aarch64 qmake /home/tone/checkouts/svn/debota/debota-sailfish.pro -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug 

we can see that indeed there's no .pro file there. Also, a bit below in the mb2 file, we can see :

SRC_DIR=$(quote "${OPT_SRC_DIR:-$PWD}") 

which basically sets a SRC_DIR for a wrapper file (apparently issued then by mb2) via heredoc.  But where is our .pro file reference gone? We will need to  check the arguments passed to mb2 for this. And when looking into that, it appears clear that something is off somewhere. In fact, on line 4893 of mb2, we have  

Now this is interesting. The -p is not present on the command line. It seems to be what we are after; but there's a notice about the option being deprecated. In fact, `mb2 --help` yields a confirmation of this. So this indeed can only mean that building a specific project file is deprecated. As SUS as this sounds; it might just be the case. Might want to check it out. So off to github again; from there a git blame sdk-setup/src/mb2 will give us some hints. And indeed it seems the change in question was meant to remove support of the -p command line option. However, while looking up the changes with gitk on the mb2 file, I noticed this:

"project file selection is done by qmake call inside the .spec file" 

qmake takes extra arguments. In fact, after adding (hint from the spectacle mer documentation (!) :

QMakeOptions: debota-sailfish.pro

to the spec file, the build continues, yay! To the next error:

Project ERROR: contentaction5 development package not found 

And this is progress, even tho small! I think I know what the issue is here; the version of the package might have changed. But since it's time to call it a day, its going to be a problem for another time! :) 

Upgrading Quickbar from SFOS 3 to SFOS 5 #2

 

Yesterday we "rebooted"  the source repository, and tried to build Quickbar with the SFOSSDK.  Turns out I forgot that the SDK itself was outdated. (SFOS4 to be exact). So well, the next best thing, of course, is to update the SDK. Firing up the maintenance tool, updating it and then update the SDK was a breeze. I believe between version 4 and 5, Jolla changed ownership (from ROSTELECOM to Jollyboys). The SDK has survived this exceptionally well it seems kudos to Jolla, in comparison to what Harmattan experience was like, this is a thousand times better. 

However, the issue is not solved with the update. So more digging appears to be in order. Taking a closer look at the compiler's build steps (from the "Compiler output" window), we see the building command via sfsdk : 

<sdk_install_path>/SailfishOS/bin/sfdk qmake /home/tone/checkouts/svn/debota/debota-sailfish.pro -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug

it appears to be correct, referencing the right .pro file (debota-sailfish.pro; "debota" is Retoromanic for "fast" in case you were wondering). However, even tho the parameter is correct, down the line, we can see that the real make command:

 /usr/bin/qmake -qt=5 -makefile <lot of stuff we do not care about>  LIBDIR=/usr/lib64 /home/tone/checkouts/svn/debota -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug

appears to be _missing_ the .pro entry. Remember, this issue carried over from SDK Version 3. It's quite interesting to see the behavior has survived. We could cludge this by removing the extra .pro files. But let's see if we can spot what eats the debota-sailfish.pro 

The command before that is (a long one, but we need that to highlight that the .pro file is missing here as well):

qmake -qt=5 -makefile 'QMAKE_CFLAGS_RELEASE=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' 'QMAKE_CFLAGS_DEBUG=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' 'QMAKE_CXXFLAGS_RELEASE=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' 'QMAKE_CXXFLAGS_DEBUG=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' QMAKE_STRIP=: PREFIX=/usr LIBDIR=/usr/lib64
 

I would assume a similar behaviour to be spotted by others among the community. So this is either a known bug with really low priority (for whatever reason), or then its a design choice. Let's see if we can clear this up!

So as a first step (after starting the building engine), QtCreator launches:

$HOME/.config/SailfishSDK/libsfdk/build-target-tools/Sailfish SDK Build Engine/SailfishOS-5.0.0.62-aarch64.default/qmake" /home/tone/checkouts/svn/debota/debota-sailfish.pro -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug 

which is correct and coherent to what we get from the "Projects" section in QtCreator:

$HOME.config/SailfishSDK/libsfdk/build-target-tools/Sailfish SDK Build Engine/SailfishOS-5.0.0.62-aarch64.default/qmake /home/tone/checkouts/svn/debota/debota-sailfish.pro -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug

so QtCreator is off the hook. Let's descend one layer...by adding a set -x to the script file in 

$HOME/.config/SailfishSDK/libsfdk/build-target-tools/Sailfish SDK Build Engine/SailfishOS-5.0.0.62-aarch64.default/qmak 

we can get more info:

+ ARGUMENTS=
+ ARGUMENTS= '/home/tone/checkouts/svn/debota/debota-sailfish.pro'
+ ARGUMENTS= '/home/tone/checkouts/svn/debota/debota-sailfish.pro' '-spec'
+ ARGUMENTS= '/home/tone/checkouts/svn/debota/debota-sailfish.pro' '-spec' 'linux-g++'
+ ARGUMENTS= '/home/tone/checkouts/svn/debota/debota-sailfish.pro' '-spec' 'linux-g++' 'CONFIG+=debug'
+ ARGUMENTS= '/home/tone/checkouts/svn/debota/debota-sailfish.pro' '-spec' 'linux-g++' 'CONFIG+=debug' 'CONFIG+=qml_debug'
+ export MER_SSH_SDK_TOOLS=/home/tone/.config/SailfishSDK/libsfdk/build-target-tools/Sailfish SDK Build Engine/SailfishOS-5.0.0.62-aarch64.default
+ exec /home/tone/dev/SailfishOS/libexec/qtcreator/merssh qmake '/home/tone/checkouts/svn/debota/debota-sailfish.pro' '-spec' 'linux-g++' 'CONFIG+=debug' 'CONFIG+=qml_debug'
+ /home/tone/dev/SailfishOS/bin/sfdk qmake /home/tone/checkouts/svn/debota/debota-sailfish.pro -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug 

and we can see that qmake also is executed with the correct command line. In fact, debota-sailfishos.pro gets passed all the way down to sfdk  .

After this, things get a little weird:

sfdk: [I] Options from environment: -c target=SailfishOS-5.0.0.62-aarch64
error: No source number 0

the first line is correct (the target is the desired one), but the second one is an error - no source number 0. Seems like an off-by-one. Let's forget about it for now, should not be too serious, hopefully.

So what happens next, is that sfdk parses the spec file, makes sure the dependencies specified in it are correctly installed; at this point, the "number 0" error re-appears; and then sfdk proceeds for the building after cd'ing into the build directory (a so-called "staged" build).
The build is started by launching qmake (again), this time to generate the correct target build files (Makefiles):

qmake -qt=5 -makefile 'QMAKE_CFLAGS_RELEASE=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' 'QMAKE_CFLAGS_DEBUG=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' 'QMAKE_CXXFLAGS_RELEASE=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' 'QMAKE_CXXFLAGS_DEBUG=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' QMAKE_STRIP=: PREFIX=/usr LIBDIR=/usr/lib64

 No .pro file is here, but you would assume that's fine, as we are in the staged build directory. and qmake should handle this correctly.

Well, 20 years of experience in the  field as told me one thing (which I call the first "rule" of development):

whenever the world "should" is involved, the assumption made is instantly and irreversably proven to be wrong, and therefore irrelevant.

So something is happening here. Lets fire up the sdk command line.

ssh -o IdentitiesOnly=yes -i <sdkinstallpath>/SailfishOS/vmshare/ssh/private_keys/sdk mersdk@localhost -p 2222

this is the way I would have done it two years (or more) ago. Nowadays, the Jollyboys have streamlined this with the sfdk utility.  So

<sdk_install_path>/SailfishOS/bin/sfdk -c target=SailfishOS-5.0.0.62-aarch64 qmake /home/tone/checkouts/svn/debota/debota-sailfish.pro -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug

will execute the same build commands, and there you have it - this command line eats the .pro file entry.

 sfdk is a compiled binary. So we have to jump over to github to take a look. But this is an exercize for another day, given it's late now!

Upgrading Quickbar from SFOS 3 to SFOS 5

So the new Jolla phone has been announced! Its incredible! 13 years is an insanely long time in the world of Software; it has transformed, re-transformed, re-shuffled, re-painted, re-<enter your favourite "re-" thing here>. What has stayed? Jolla! Out of all things! To honor that, and due to my own masochism; I want to resuscitate Quickbar for the occasion! For the ones who don't know; Quickbar is a simple one-row mini-launcher app, that embeds itself at the bottom of the screen of your SailfishOS phone, tracking the most recently used apps, as well as favorites! It originated in the Meego times, back when Ovi Store was still a thing (yes yes don't worry, Ill skip the nostalgy ;) ).

But first, a bit of background. Quickbar had transitioned from MeeGo To SailfishOS; the idea back then, in the MeeGo days, was to learn about N9 and Harmattan. And for SFOS, the idea for me was to learn about Wayland, and what not of a better approach, to try to integrate a mini-widget into an operating system with a new model of Window manager (Wayland). However, maintaining Quickbar for SailfishOS has been more complicated than expected, for reasons we (might) re-face down the road. Mostly due to the simple Wayland protocol implemented in lipstick, the SailfishOS compositor; btw as we speak there is talks about redesigning the current approach by detaching the Wayland compositor from the acutal UI, this shows that SailfishOS is never static on everything. I love that, it gives the feeling of a "living" operating system!

So today I start with the basic. Getting back online my old svn (yes, svn!) repository,  checking out the sources. The svn repo was resting on an older diskstation. Luckily I still had the disks, so after plugging them into the usb to serial adapter, it was easy to recover. Getting the repo back online then was as simple as spinning up a docker container with svnserve in it. We are ready to dance!

Checking out the code took a bit since I didnt really remember the password (so had to look it up from old notes), but worked flawlessy. I then spun up SailfishOS Sdk QtCreator, opened the harbor-debota.pro project file, and gave a build and thought "here we go"; and even before I got to the end of that thought, an error popped up:

Project ERROR: gq-gconf development package not found 

Well that's a bummer. But the project was last built on 2020, so what was that, SailfishOS 3? A quick look at the SailfishOS Wikipage  revealed Rokua (3.2.0) and Pallas-Yllästuntturi (3.3.0). Feels like so long ago..Alot has changed since then (including Jolla who shifted to the Jollyboys team in the meantime! And let's not go back to how the world has changed in between...). The funny thing is, this package is _not_ a direct dependency of Quickbar; but of another project lancia (italian for launch), which is the really early and plain name for the app I had used for the harmattan version. Good times, Ovi store times..I heard they rebranded to "Apple store" nowadays. But perhaps it's just an internet meme....Aaaaanyways. 

So to go back on topic, the gq-gconf (where the hell do these names come from) package is something I have (honestly) almost never worked with. I do not recall using it, and there is no information around in SFOS. In fact, in 2026, even Gemini is clueless about it (surprise, but not really, given its information that probably has never been crawled):

(between you and me, I love the "preciseness" of the _alternatives_ that are provided) 

But perhaps the most interesting question here is, how comes the lancia project is built instead of the harbor-debota, the actual Quickbar? There is no connection between the two in any way (except for source file sharing), they sit in the same directory tree, in two separate folders...like this:

     debota \
            harbor-debota
            <more crap here in between we dont care>
            lancia

But that's really it! This will be the first knot to untie! 

So to go down the rabbit hole (just a bit), we find from the `Makefile` in the build directory : 

        SUBTARGETS    =  \
                    sub-lancia

So indeed the build tools seem to believe there is some kind of dependency between the `lancia` project as well as the harbor-debota one. This is something I havent seen around lately in the Qt World, so it _might_ be just a SFOS thing...Will have to check on the forums! But now it's late, and tomorrow is a working day! Have a good one, and stay tuned for part #2!

ChatGPT #3

In the mean time, ChatGPT V5 has been released, and rolled back!

So I decided to give it another chance, and started the work on a new version of the application. After the first day of work (~2 hours) the result is here : 

https://github.com/tortoisedoc/topmenu

I must say I have mixed feelings. See the notes at the beginning of the prompts file .

On one side, it was fast to start, but it got messy very fast as well. The prompt got unbearably cumbersome to handle, as it grew almost exponentially in text size. As i had to fill out every single detail, even  restarting from scratch didnt bring the same outcome every singl time. So I decided to stay put and go incrementally. facing all sorts of other issues which you can read about from the link above.

Chatgpt #2 - or, how to develop a simple qt/qml app with it

So I have this use-case of planning the food ahead for the week.

I figured a simple note app would do it.

But then I thougth "Screw it, let's ramp it up and go for chatgpt to do it for me!"

So I prepared a repository on github account and opened my prompt, added my requirements:

 

    Write me a Qt5/qml application;

    - that handles a list of foods

    - the user can edit and add / remove to/from the list 

    - items of the list should be able to be grouped 

    - do all low-level code via QT api's

    - add data persistence in XML file 

    - add a button that triggers randomized choice of n elements (user has to input the number) that is then displayed to the user in a separate dialog 

    - add drag-and-drop Write this all down and do a PR to the following github repo: git@github.com:tortoisedoc/topmenu.git

Seems straightforward enough, right? I decided to not ask chatgpt to add all necessary package types (ios, android, SailfishOS) in order to keep it simple..

Chat gpt's reply was very straightforward: 

Got it! I'll structure the application accordingly:

• All low-level operations will use Qt APIs (no STL, just Qt containers and file handling).

• Data will be stored in an XML file for persistence.

• A random selection button will allow users to input a number and get a random set of foods displayed in a dialog.

• Drag-and-drop support for reordering food items.

• Push as a PR to git@github.com:tortoisedoc/topmenu.git.

I'll start implementing this. Stay tuned! 🚀

Surprised by the efficiency of it all, I smiled and was looking forward to gitrepo. However, 20 minutes in, nothing had shown...

 So I inquired about it

 and after another 10 minutes passed; I wondered if there's any technical impediment (arranging github access etc); so I asked:

And here's where I started having the feeling that Chatgpt was just screwing with me:

 

 And in fact, it started sounding like a procrastinated Junior dev:

 

At which point I figured to get busy with othre more pressuring issues.
I returned to the prompt later that day to query the status (there was still no PR on my github repo):

So it seems the hopeful github integration wasnt going to happen.
"Screw it", I thought, and falled back to a more common download approach:

Dang. So I wasked it try 

However, that failed, in that clicking on the download link didnt proof to be usefull

 

so I complaied:

but still no download link. DOH!

 

This is quite disappointing, as I was hoping to get hands on a working sample / prototype.
I am not sure if this is due to the free account; but even if it was, it would be a very bad impression from a product perspective. ChatGPT, why u fail me?

After trying a few more times, I reached my daily limit. And then it hitted me.
The system was procrastinating _on purpose_ to exhaust my daily (free) usage tier, potentially coercing me into a subscription. Very, very, very sneaky dear chatgpt!