Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000646OLVUser Interfacepublic2012-08-11 00:112012-08-15 16:22
Assigned ToFred 
PlatformLinuxOSDebianOS VersionSid/Unstable
Product Version0.0.3-SNAPSHOT 
Target Version0.0.3Fixed in Version0.0.3 
Summary0000646: Focus controller must go AND focus must work normally

On lxde/eee pc, new windows end up in focus, but behind the main window.

On windowmaker/mac mini/deb both windows shimmer in some wild dodgy loop.

Mac is unaffected due to stiffer more regimented windowing strategies.

Windows may be similarly unaffected.

Main point: such a class should not be required and is bad taste. I don't even know what sort of issue you were/are trying to solve with it. Something FS related, perhaps. Whatever you're doing is bad and a huge regression. Find a cleaner/less broken way.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
User avatar (0001847)
BenFenner (developer)
2012-08-11 01:33
edited on: 2012-08-11 01:38

It's been gone for at least a couple commits in on the master branch.

It was designed to bring keyboard focus back to the app after losing if from going full screen. It is no longer necessary now that I've re-worked the full screen transition a little bit. I stripped it out.

User avatar (0001849)
Fred (administrator)
2012-08-11 10:47


Git seems to disagree, though it seems to contain 90% comments.

Something is very broken in this department, whether it's that class, or not :-)
User avatar (0001852)
BenFenner (developer)
2012-08-11 13:46

It's possible that removing it has caused the harm. ;-)
We'll get to the bottom of it.

However, since we plan on having very little or rare cases when a new window will be spawned, it might be a non-issue with the new UI.
User avatar (0001853)
Fred (administrator)
2012-08-11 14:17

True enough, however it's a regression for now, and in future, when we do open a window (settings etc) we don't want it to "pop back up" (LOL).
User avatar (0001854)
BenFenner (developer)
2012-08-11 14:46
edited on: 2012-08-11 14:46

For the record, the correct behavior would be for the newly opened window to show in front of the main app, and get focus.

Because I'm not sure that type of behavior is compatible/supported with Full Screen. If you think of it used more often for video games and such, they don't open new windows. They only get that single window to work with.

User avatar (0001855)
Fred (administrator)
2012-08-11 15:26

What have new windows and fullscreen got to do with each other? If in fullscreen, either grey out new window options, or better, drop out of fullscreen first, then open new. Or just let whatever happens happen.

The correct behaviour, for the record, is whatever the window manager is configured to do. You have little/no choice on winblows. Ditto on mac. On Linux we can make it do whatever the fuck we want! :-o And you should not be fucking with those choices artificially without good reason.

Opening a new window should behave well by default and is not a good reason. It should not require any fucking with to work correctly, irrespective of whatever correct happens to be for a particular user and environment.
User avatar (0001856)
BenFenner (developer)
2012-08-11 15:33
edited on: 2012-08-11 15:34

Grey out new window options: A possibility

Drop out of full screen and then open the new window: Maybe a better possibility

Just let whatever happens, happen: I do believe that is what is happening now and causing this odd behavior

Even on Windows it is a bit odd. The file chooser menu behaving the most oddly. =]

User avatar (0001857)
Fred (administrator)
2012-08-11 15:43

That's not what's happening now, it's what was happening before. Now it's broken because shit is getting fucked with that should be left alone most of the time.

This all started when you noticed that focus wasn't kept when exiting fullscreen.

Drop out is definitely the best option *for fullscreen*, however my issues with this are when NOT in fullscreen mode... it's broken THEN, IE, normal small window mode. I'll look at fs mode again once normal behaviour is restored during normal non-fs use.
User avatar (0001858)
BenFenner (developer)
2012-08-11 16:07
edited on: 2012-08-11 16:16

I don't think you're following the timeline properly.

Some point around 6 months ago I put in the hackish keyboard focus controller to return focus to the main app window after going full screen so that toggling full screen with the keyboard worked with no mouse intervention. (Is that when you're saying the problem started?)

...6 months pass...

You mention the bug finder saw something in the focus controller code. I fixed the code. This eliminated multiple calls to requestKeyboardFocus() that weren't needed, eliminated the stupid freezing on the Mac when in full screen and trying to open a new window (now possible with the new buttons), and tested out fine.

Then something happened I'm not sure of, which stopped the keyboard focus from returning to the app when going full screen. (Maybe the old tests I did weren't against a fresh clean build? And the issue came up with my previous change? I'm not sure.)
I noticed this when working on the new style of key bindings. Actually, I think this resulted from the new style of key bindings!
I dug into the full screen code deeper and found the real source of all the trouble, which was a call to removeNotify() (used to make all the windows undisplayable, so that some window decorations could be removed). The call to removeNotify() was replaced with the more benign call to dispose() which also makes everything undisplayable, but does not cause havoc with the keyboard focus.

After that worked, I removed all functionality of the keyboard focus controller. The shell of it is still there, but it does nothing. It is planned to be removed completely very soon.

Given that, I can only report that while things may be broken now, it should have nothing to do with the keyboard focus controller hack (which has been fully gutted). Things are "being left alone" from where I'm standing.

User avatar (0001859)
Fred (administrator)
2012-08-11 16:17


                scaleAndColorViewMenuItem.addActionListener(new ActionListener() {
                        public void actionPerformed(final ActionEvent e) {
                                prefFrame.setAlwaysOnTop(true); //Used to bring panel to top
User avatar (0001860)
BenFenner (developer)
2012-08-11 16:24
edited on: 2012-08-11 16:28

Oh you can't blame or credit Gufi's original code to me. That code is as old as the preference and option frames themselves, which were already there when I started. It was there when you initially implemented full screen too.

It very well may be where the issue is, or where the fix should go, but that has nothing to do with my stupid hackish focus controller. That's Gufi's code. Which is pretty boilerplate at that.

You could save yourself some time and effort by just waiting until I get in on Monday and can actually tackle the problem. I'm just letting you know that you're placing the blame on the wrong code and/or on the wrong person. :D

User avatar (0001861)
Fred (administrator)
2012-08-11 16:27

Title updated. I wasn't saying it was yours. I was just saying that it was there.
User avatar (0001862)
BenFenner (developer)
2012-08-11 16:31
edited on: 2012-08-11 16:41

Opening a new window was never possible before the buttons.

This is why we're chasing bugs we never saw before. In that way, I don't believe it is a regression?

It should be a simple matter to solve.

I still don't have any clue as to what the "correct" behavior of a new window should be when in full screen. You say it should not be fucked with. I agree, but it would be very nice to know exactly what should be happening when you don't fuck with it. I won't know if I've removed all the fucking until I see some reference behavior.

We need to find out what the correct reference behavior is. Not so I can code it in, but so I can know when I'm done "uncoding" hacks.

User avatar (0001863)
Fred (administrator)
2012-08-11 16:45

Gotta go, but that's bs too. Option pane was there long before the new buttons. They should just pull up the same code the previous methods did. Back in several hours.
User avatar (0001864)
BenFenner (developer)
2012-08-11 17:13
edited on: 2012-08-11 17:17

Options pane was never possible to open while in full screen mode before the new buttons made it possible. How could you possibly do it? You couldn't.

The options pane could be opened before you enter FS mode and then worked with even in full screen mode, but it couldn't be opened during full screen mode before the new buttons.

And they do use the same code to open whether in FS mode or not. *sigh*

User avatar (0001865)
Fred (administrator)
2012-08-11 21:39

I. don't. care. about. full. screen.

It is fucking up in normal mode.

This issue is entirely unrelated to fullscreen.

I can not be more clear than this.
User avatar (0001866)
BenFenner (developer)
2012-08-11 22:26
edited on: 2012-08-11 22:27

I can't even begin to imagine why that would be happening. That's why I assumed it was a full screen issue. =/

User avatar (0001867)
Fred (administrator)
2012-08-11 22:29

I did.

In the original issue body.

In [^]

In [^]

And finally again in [^]

User avatar (0001894)
BenFenner (developer)
2012-08-15 16:17

All fixed in git hash: 498144f963862359fd4cea42231f7f065086c687

Main app window and sub-window keyboard focus and display is left up to the OS to control. This also removes the last vestigages of the KeyboardFocusController class. Also opening or reloading a file while in full screen mode with the buttons forces an exit of full screen mode.
User avatar (0001895)
Fred (administrator)
2012-08-15 16:22

Hooray! :-)

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker