INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

macOS - Dialog windows appear behind all other windows (which can be bad)

  • Posts: 1201
  • Thank you received: 555
1 year 1 month ago #89596

Please Log in or Create an account to join the conversation.

  • Posts: 195
  • Thank you received: 28
Thanks Hy - I'm always a step behind. I filed the bug report but it would appear Rob is already on it!
1 year 1 month ago #89597

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
Hello everyone,

Yes I worked on this about a week ago after someone brought it to my attention. I made some changes that should fix a lot of the problems I think.

To give some back story, when I was first working to port KStars to work on MacOS back in 2016/2017, I immediately ran into a huge issue. Unlike on Linux, where child windows appear above their parent windows and don't go behind them when you click the parent window, I found that on MacOS in QT, anything could end up behind the main planetarium window, from Ekos to the FitsViewer to any given Dialog or Alert window. This was a huge show stopper, because in a planetarium program, you often have to click on the Skymap to move to different parts of the sky, click on an object, get object details, or to do various tasks. In fact, often I found that you had to click something in Ekos, then slew the skymap and then do something in Ekos again. The problem was, every time I clicked the skymap, everything else and I do mean everything went behind it. This is a really big problem because in a Planetarium program, the Skymap is meant to be large if not full screen. You don't have to use it this way and not everyone does, but really if a planetarium program can't keep its skymap behind all the other windows, it really can't be used like a Planetarium program. That is a problem.

I thought this would be fairly easy to fix, but I was wrong. There were multiple solutions that I tried and finally the one that mostly worked was to use "Tool Windows" and "Window flags" to keep everything in front of the skymap. There were some side effects of this and it was not the best solution in the world, but it was better than the previous issue. Unfortunately the side effect was that sometimes some windows ended up behind others and that was really annoying. So some of the issues you have observed are actually the original issue of things that go behind everything else. They include the "About KStars" window and the "Port Selector" window that were mentioned a few posts ago. And some issues were a side effect of the solution such as the dialog that was mentioned. I am sorry about these side effects of my solution but you should note that it was much worse before I did that work back in 2017. Most of you never saw how it worked before my changes back then, so you don't know how annoying it was. But believe me I know that I need to eliminate the side effects for usability. So I came back to this problem last week and I will try to fix it to make it work better.

When I revisited the problem last week, I think I finally managed to fix the side effects that were really annoying so that the dialog should not go behind now. I (and Hy) also fixed a couple of windows to which the solution was never applied such as the port selector window. But note that the "About KStars" window is not one that I can apply my solution to since KStars does not include the function that actually makes that dialog appear so we can't edit the window properties at all. Another one like that is the "Configure Notifications" window. We just don't have access to it. But I can certainly make sure my fix is applied to all the others that we can control and I think I can fix it so that side effect with the dialogs doesn't happen anymore.

Thanks for the feedback,

The following user(s) said Thank You: Frederick Ruegsegger
1 year 1 month ago #89599

Please Log in or Create an account to join the conversation.

  • Posts: 33
  • Thank you received: 0
Checking on the status of this. It looks like the merge request is scheduled for v3.6.4 which is end of March?

1 year 5 days ago #90943

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
So there were still a few issues with it and I will have to come back to it. Over the last couple of weeks we had bigger issues to solve, there were some issues with a few drivers and I revised the macros for checking library linking with drivers. Then we had to fix the build on binary factory and fix some recipes to get that working again. So I have been a little sidetracked from this issue. But I do hope to come back to it soon. Now, I have the builds working properly on Binary Factory again which is good news:


So I think if this is all resolved, I should be able to look into the windows issue again.
The following user(s) said Thank You: Frederick Ruegsegger, David Maffitt
1 year 5 days ago #90944

Please Log in or Create an account to join the conversation.

Time to create page: 0.365 seconds