Re: cannot SkipTaskbar on this program with QT5

[Bruce Steers <bsteers4@xxxxxxxxx>]

On Fri, 17 May 2024 at 16:24, Bruce Steers <bsteers4@xxxxxxxxx> wrote:

>
>
> On Fri, 17 May 2024 at 15:48, Benoît Minisini <
> benoit.minisini@xxxxxxxxxxxxxxxx> wrote:
>
>> Le 17/05/2024 à 16:37, Benoît Minisini a écrit :
>> > Le 12/05/2024 à 14:31, Bruce Steers a écrit :
>> >>
>> >> So is it a case of...
>> >> If it works with KDE on Manjaro there is no problem?
>> >> 🤔
>> >>
>> >> I have just found that if i add...
>> >>    Me.SkipTaskbar = True
>> >> to Form_Show() then it works as expected.
>> >>
>> >> Even though the IDE has the SkipTaskbar = True set and it's also set
>> >> in Form_Open() it's failing with qt on MATE if i don't add it to
>> >> Form_Show().
>> >>
>> >> Is there code like in gb.dbus.trayicon that uses only
>> >> org.kde.StatusNotifierItem specific functions?
>> >>   that looks to me like it's probably only really guaranteed to work
>> >> on kde.
>> >>
>> >> Should we now say, for a bug free gambas environment you must use KDE
>> >> (and Manjaro)
>> >> (<-- holds up sarcasm sign)
>> >>
>> >> Respects
>> >> BruceS
>> >>
>> >
>> > Apparently it's the weird things you are doing that makes the window
>> > manager mad.
>> >
>> > Your startup class is a form that you hide when it is shown, by calling
>> > the Hide() method in Form_Show(). If you remove that, the window does
>> > not appear in the taskbar.
>> >
>> > The possible reason for this behaviour is that since Qt5, the window
>> > properties must be defined after the window has been shown, otherwise
>> it
>> > does not work. As you hide the window during its show event, maybe it
>> > creates a bad interference.
>> >
>> > I will check again if I can define the window X11 properties before
>> > calling the Qt show method.
>> >
>> > Otherwise, why doing that? Why using an hidden window as startup form?
>> > If you don't want it to be visible, don't define it as startup form so
>> > that it is not automatically shown.
>> >
>> > Regards,
>> >
>>
>
> To be honest it was initially written some time ago and it's various
> startup possibilities just ended up in what i have.
> I can probably revisit the startup and make it better.
> And as bizzare as the structure is it seemed to work. i only just noticed
> a problem on mint/mate/qt.
>
> Looking at it now I'm thinking,, why is my startup class even a Form? it
> should probably just be a startup.module.
>

Ahh after trying to alter it now i realize it was made that way, so the
Tray icon that is created in the startup class can have Menus

The startup FMain.form had the menus but was hidden so i could build the
menus and use them in the TrayIcon1.Menu = "mnuRecents" but it had to be
done in the same class (as far as i know)

It would be useful if i could write something like..
TrayIcon1.Menu = "FList.mnuRecents"

so i could use a menu from another class

I guess i'll have to move the trayicon to the main window form (hidden but
Persistent)

Respects
BruceS