My main issue is the menu functionality, which seems to not play well with SF, (another app I have going is Lazarus IDE, but the gui is almost unusable because it’s entirely menu-dependent; the others are usable, because most menu options can be set through config files).
I’ve been hoping some QT-pro can give me some pointers, like maybe there’s a way to get the menus to work properly, or maybe we could come up with some qml files that SF would be able to handle…
I’ve moved this post from its previous location to its own topic, since it was flagged as off-topic in the previous thread, which I agree it was, but it nevertheless remains a valid question worthy of discussion.
The typical drop-down menu in a qt app, (e.g. “file”, “edit”, etc.). What hapens is, when I tap on “file”, instead of a menu dropping down, a new window opens, with nothing except that menu:
This would be fine, and sometimes works out, but it’s touchy, and inconsistent. Sometimes the menu won’t show up properly, and if there’s more than one level of menu, it will never make it to the next level - just black screen or something.
I wonder if that menu is a library component of qt which could just be overwritten with a generic component that works better on sailfishos… Maybe something like kirigami?
Since these apps are largely ‘Desktop apps’ they will use window components as are common in desktop window managers.
To get a wrapper around those is at best tricky. I’m not saying one shouldn’t try, but if you take a look at an app with support for multiple paltforms, mobile and desktop (for instance Fahrplan) you will see a good deal of disparate code.
A QT code base that uses QML will be a lot easier to port/adapt. I’ll quote @michfu from the previous thread:
Also it uses qtwidgets instead of qml for the UI, which makes it harder to port.
Can you post which repositories you were working from? And which app has what priority. I’ll look at the source and at least try to guestimate the work required.
Plus, besides the menu issue, the qt5 build also won’t show keyboard on SF, because requires gtk, (I can get gtk build working on SF side by launching in lxc X window)…
Interesting - I was messing around with qtvirtualkeyboard, trying to see if I could get text input working with Cudatext qt5, and I found the same thing - the keyboard opens in a separate window:
So, I guess it’s not necessarily a menu-thing, but something to do with qt code in general. Maybe poking around in jolla-keyboard code will give some insight…
(edit - tried again, and foumd out that flag didn’t have the effect I thought it had…)
@Mister_Magister - do you know how Sailfish gets the Jolla keyboard to show up over the current app and send input, instead of opening a separate window, (I guess Jolla-keyboard source is unavailable)?
Right, but somehow the keyboard pops up and is active in the same window as the current app, and the current app makes space for it. Obviously this isn’t done according to usual qt code, because opening keyboards and menus in other non-SF qt apps that expect that behavior, cause a new window to open on SF. So there’s something specific to SF code that is making it work for the keyboard…
I’ve read up some backlog and if you have issues with menus and stuff popping as new window while native stuff doesn’t, remember that window manager is written by jolla, qml is modified by jolla. Thats why top menu (the global one), app drawer, etc despite being separate windows, just work because they have code written to handle them
