Community
Participate
Working Groups
(Eclipse 3.2 and 3.3 on Mac OS X 10.4.9.) If I use eclipse on a large monitor, the quit eclipse and reopen eclipse on a smaller monitor, the workbench opens larger than the smaller monitor. This happens if I use an external monitor with my laptop, and then use it later with the laptop's smaller screen.
Moving to UI since it sets eclipse's initial size based on its previous size. I've seen this on linux as well.
This problem is not particular to OS X.
I had a quick look at this to see if I could fix it. I think the area that needs looking at is WorkbenchWindow.constrainShellSize(), but there is a comment there referencing bug 74762. I'm not sure we can fix this bug (easily) without reintroducing bug 74762. Perhaps a solution is to remember if Eclipse had been maximised in the previous session, and maximise it again when restoring it? Channing
If you want to attach a patch Channing I would be happy to look at it.
(In reply to comment #4) > If you want to attach a patch Channing I would be happy to look at it. > I was wondering if it would be better to have a appearance preference ifor this instead?
We will not be adding new preferences unless absolutely neccessary
(In reply to comment #6) > We will not be adding new preferences unless absolutely neccessary > ok, I'll see what I can do.
There is already code in WorkbenchWindow to restore the workbench to a maximised state - see saveState() and restoreState() references to IWorkbenchConstants.TAG_MAXIMIZED which is want we want I think. I've confirmed that if you manually set WorkbenchWindow.asMaximzedState to true (in the debugger) before quitting the workbench, change the display size and restart eclipse, the state is saved and restored properly and the workbench is maximised as expected. The problem lies in window events. When maximising a window on OS X, the Workbench window is sent a resize event, not a maximise event. The event kind is OS.kEventWindowBoundsChanged which finds its way to WorkbenchWindow.trackShellResize which in turn records the bounds of the shell and sets the field 'asMaximizedState' to false. So the maximised state of the workbench window is not recorded in the saveState() method. Unfortunately, I know nothing about cocoa so it might take me quite a while to figure out how to send the right maximise event. Help appreciated :-) I will repeat this work on windows to see what happens there.
Hi, I have managed to hook up a new event (kEventWindowZoomed) and callbacks in the Carbon implementation of Shell which tells us when the mac zoom button is clicked. But this isn't enough because we still don't know what the zoom state of the shell actually is. (Also kEventWindowBoundsChanged is called before kEventWindowZoomed.) When a shell is created it sets attributes including OS.kWindowFullZoomAttribute which is actually OS.kWindowVerticalZoomAttribute | OS.kWindowHorizontalZoomAttribute. I think I need to read these attributes if possible but cannot see how to do it. Any pointers would be appreciated.
Changing OS from Mac OS to Mac OS X as per bug 185991
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
