Effective use of menus in Qt applications on Sailfish OS

[Levone1]

I have gotten a few QT apps built and running well om my XZ2c, (SF 4.4), including

• Cantata, (Cantata App Testing)
• QTFM -
  
  
• Tea editor -
  
  
  
  
  

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…

[flypig]

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.

[Levone1]

I knew it - I just decided to take the chance… Sorry, I don’t want to add to disorder.

Thanks

[Levone1]

Btw - I just finished getting Cudatext running…

[thigg]

What exactly do you mean by menu? The menubar with its items (file,edit,…) or something like popups?

[Levone1]

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.

[thigg]

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?

[poetaster]

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.

[poetaster]

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.

[Levone1]

Cudatext would be great - https://github.com/Alexey-T/CudaText_up

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)…

Then there’s Tea - https://github.com/zovt/tea
Lazarus IDE - https://github.com/fpc/Lazarus
Cantata - https://github.com/cdrummond/cantata
QTFM - https://github.com/rodlie/qtfm

[Levone1]

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…

[Levone1]

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

[Mister_Magister]

No idea but for example, the app drawer, that you can pull on every app, is a separate window

[Levone1]

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…

[Mister_Magister]

Well yeah app changes size because app is using ApplicationWindow which is overwritten by jolla and made to rescale when keyboard pops up

[Mister_Magister]

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

[Levone1]

I wonder if there are any actual Jolla people on this forum who mmight be willing to give some insight …