If you for example want to delete one of your equipment profiles the warning message stays behind the ekos window and is not visible. That's confusing too.
Would it possible to bring a window up to top if you click in it. I'm using it on MacOS.

Thank you
Andreas

@otti242 On a Mac, if you go to KStars->Preferences->Ekos and check "Independent Window", then restart KStars, it should work for you. I was able to reproduce it and fix it that way.

Ok folks. So it seems it's not an EKOS problem.

Maybe best to list the window managers/desktops it works with.

So far we have
lubuntu
kde
mate
...
Any others?

I am a bit lost by this post. How are you able to say it is not an Ekos problem when there is a MR that changes how it works?

The second part of this, are you listing those distributions that are working after having the MR applied, or before the MR is applied? By working, do you mean working as desired, in that the Ekos window is not always on top, and dialog windows pop over instead of under?

I finally got a chance to look at the code last night. One thing that bothers me is the commented out section of the if statement. @jasem it was commented out by you for some purpose, but it contains the setWindowFlags Qt::Window that the MR looks to set.

Hi
Sorry, no idea what MR is, but I haven't changed anything apart from the Linux distribution which prompted me to write the original post.

To summarise that post:
On Ubuntu 20.04, the EKOS window is stuck on top. I cannot bring kstars forward.

To summarise what I know now:
On lubuntu 20.04, I can bring kstars in front of EKOS; as<em> I</em> want it to work (as the OP).

My conclusion was simply that this behaviour depends not on EKOS but upon which system it is installed.

Cheers and clear skies,
Steve

There is currently code in Ekos that makes itself always on top on certain systems, unless the "Independent Window" checkbox is checked in settings. Currently, on a Mac (but not other systems), checking that box makes the Ekos window NOT always on top. It also seems that whether the Ekos window is always on top is somewhat dependent on the window manager in use. Ubuntu 18.04 doesn't make it always on top, but 20.04 does with some window managers (xfwm for one). Since making changes to the window managers would be a much longer process (and probably wouldn't get included in the 20.04 LTS until the next point release at the earliest), I took a look at modifying the Ekos code to get what we need.

My code change as it is now in the merge request (MR), makes it so it is never an always on top window, regardless of the "Independent Window" checkbox.

I have a question for the group: Is there any reason why you would want Ekos to be always on top, whether or no the "Independent Window" checkbox is checked? I can't think of any for my workflow, but someone might have a need for it.

Hi Steve, Thank you for the clarification. An MR (also called a PR on some systems) is a Merge Request. It is a code change that is proposed by a developer for review by peers before becoming part of the main code base (a merge to master in git terms).

There is an MR created that changes the behaviour of the Ekos window in respect to if it is always on top. This is a change in the Qt5 configuration, a set of libraries that control the graphical interface for the application, and how things are displayed to users.

Different distributions have different versions of Qt installed, and how the windows are handled in those versions of Qt, along with tweaks made by the different distributions can manifest in different behaviours of the visual windows, as you have seen with the list you are compiling.

I just built a local copy of kstars using the change in the MR to see if it works on my system, which consists of Fedora 32, running gnome 3.36 with Qt 5.14. The version of the actual window manager may also matter, for the same reason as Qt.

The permutations of kernel, distribution, X/Wayland (low level display driver things), window manager, and Qt are really too many to all be tested, so the hope is everyone that tests the changes in the MR has a better experience no matter the combination.

Hope this helps
Jim

My diff looks like this:

And has the desired effect for my systems without changing how the MaxOS section looks or works. The proposed MR comment code (not the actual MR) cleans this up even more, and has the same effect.

Yeah, that's similar to the change I posted in the MR comments. But my question still stands, is there a reason to have Ekos always on top at any time, even if it is not an independent window?

I do not know of a reason, but would certainly like to hear one if there is. I think @knro knows, but he's not saying

Did someone mention they'd tested this on MacOs? If so, please let someone know, they're waiting on a positive confirmation on that.

Also think waiting on Win64.