Closed nguy closed 8 years ago
This is a real problem, and it is also a problem in one of my inspirations (GIMP). I have to see how they are working that out.
Potentially this? http://pyqt.sourceforge.net/Docs/PyQt4/qwidget.html#raise
I tried the above with no luck (possibly due to my use of MacOS). Seems to be an outstanding problem and after a bit of web searching it looks to be OS dependent as well.
Added the raise_()
method to the menu component. And to test on FileNavigator. On my mac I see it momentarily come to the foreground, but then become buried again.
@nguy as this is system dependent, could you make a video showing this problem in your system? I think I know what you mean, but I would like to be sure that your experence is the same as mine.
I shared a short video in your email.
Interesting how IOS externalize the menu bar. If you pay attention the menu does blink for a moment in the upper corner where it should be. That mean it's IOS that is interfering in the Qt work, we have to avoid that.
Yep, you are correct. This is why I indicated that it is an OS-dependent issue. I don't know if there is a solution for this behavior.
have you seen this page "http://doc.qt.io/qt-5/osx-issues.html"?
in script
app.setAttribute(QtCore.Qt.AA_MacPluginApplication, True)
Think this could be put in at startup as a check with a conditional statement identifying MacOSX?
first of all, did it work?
Yes, this does work to put the menu on the menu window. To implement, we'd have to install an OS check. I feel like this should be automatic in the background.
The issue remains how to bring the menu window to the front for operation.
To test and internet search returns the following code:
import os
import platform
if os.name == 'posix':
if platform.system().lower() == 'darwin':
print("You are using MacOSX")
My guess would be that we could put a script in artview.core
that returns isMac boolean. If true then the code above is run. We then just need to keep this in every script. Unless you see an easier way.
I see you already created it, but I wouldn't make such a function.
We already have a function to start the app, in artview/view.py start
. I would add the test in that function and start using it in the scripts.
also, I don't understand the test (what does darwin has to do with it?). Do you have any explanation why it works?
what do you mean with "The issue remains how to bring the menu window to the front for operation."
This PR doesn't need to be implemented. Just a first shot.
I like the idea of having this test somewhere other than core.py
.
As for the test: os.name returns posix for any unix-based system, therefore a secondary test is required to see what the system platform is called. 'Darwin' is returned for the Mac unix system, 'linux' is returned for linux unix systems.
Updated PR code.
This remaining issue is that displays still cover the menu mostly. Having the File, Modes on the Menu window helps, but it can still be buried inadvertently pretty easily. This is the part I'm not sure can be fixed easily.
ou yes, this is a difficult one. The answer to that would be imploring the tab system so we don't need separated windows.
I'm still on the fence of whether to move the displays toward tabs. You successfully did this already with the "simple plot". One advantage of this would be that ARTview might be able to be used more easily on mobile devices then...
I'm thinking of doing something similar to kate (KDE "simple" text editor). It has Tabs and at the same time the option successively divide the display horizontally or vertically, so that multiple tabs can be displayed at the same time.
I'll be interested to see this. Split windows can be really nice to work with.
The original scope does not seem possible at this time. PR #136 takes care of menu on MacOSX now appearing in the MainMenu window.
I notice on my machine, sometimes the menu window gets lost. For most people this won't be a big issue, but we may want to consider if there is a way to bring the window to the front somehow. A menu link or something?