nguy / artview

ARM Radar Toolkit Viewer
http://nguy.github.io/artview
BSD 3-Clause "New" or "Revised" License
48 stars 21 forks source link

Menu window #130

Closed nguy closed 8 years ago

nguy commented 8 years ago

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?

gamaanderson commented 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.

nguy commented 8 years ago

Potentially this? http://pyqt.sourceforge.net/Docs/PyQt4/qwidget.html#raise

nguy commented 8 years ago

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.

nguy commented 8 years ago

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.

gamaanderson commented 8 years ago

@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.

nguy commented 8 years ago

I shared a short video in your email.

gamaanderson commented 8 years ago

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.

nguy commented 8 years ago

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.

gamaanderson commented 8 years ago

have you seen this page "http://doc.qt.io/qt-5/osx-issues.html"?

gamaanderson commented 8 years ago

in script app.setAttribute(QtCore.Qt.AA_MacPluginApplication, True)

nguy commented 8 years ago

Think this could be put in at startup as a check with a conditional statement identifying MacOSX?

gamaanderson commented 8 years ago

first of all, did it work?

nguy commented 8 years ago

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.

nguy commented 8 years ago

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.

gamaanderson commented 8 years ago

I see you already created it, but I wouldn't make such a function.

gamaanderson commented 8 years ago

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.

gamaanderson commented 8 years ago

also, I don't understand the test (what does darwin has to do with it?). Do you have any explanation why it works?

gamaanderson commented 8 years ago

what do you mean with "The issue remains how to bring the menu window to the front for operation."

nguy commented 8 years ago

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.

nguy commented 8 years ago

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.

gamaanderson commented 8 years ago

ou yes, this is a difficult one. The answer to that would be imploring the tab system so we don't need separated windows.

nguy commented 8 years ago

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...

gamaanderson commented 8 years ago

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.

nguy commented 8 years ago

I'll be interested to see this. Split windows can be really nice to work with.

nguy commented 8 years ago

The original scope does not seem possible at this time. PR #136 takes care of menu on MacOSX now appearing in the MainMenu window.