Community
Participate
Working Groups
I've been working on a 'full screen' mode implementation for Eclipse 4. I was hoping to be able to re-purpose another 4 digit defect but the best I can find is bug 171398. This defect is actually a placeholder for any necessary rendering work needed in order to get the functionality going since I expect to release the actual feature through the Eclipse Marketplace...
Created attachment 240513 [details] Project implementing a full-screen mode This is an early implementation of 'CodeFocus'...a full-screen mode for Eclipse 4. To use: Extract the ZIP and import the extracted project into your workspace Run an inner session. Now, Ctrl + '+' will give you a full-screen instance of the current perspective. It's a toggle so if you do it again you're back where you started. This version is perspective based so that we can keep the context ordering correct, allowing commands to work (I'm looking into one that'll do the complete perspective stack but it's not quite there yet... While in this mode you won't have the main menu or Toolbars so you'll have to switch perspectives with Ctrl + F8...(or just hit Ctrl + '+' again). The implementation is straightforward; take everything related to the perpspective and move it all to a 'detached window' created using the newly available mechanism to override the SWT flags...this has to also include any TrimStack MToolControls related to the perspective.
(In reply to Eric Moffatt from comment #1) > Created attachment 240513 [details] > Project implementing a full-screen mode > > > This is an early implementation of 'CodeFocus'...a full-screen mode for > Eclipse 4. Looks nice, but the window should also be maximized. It currently occupies only a part of the screen.
Also I think the original window should be hidden.
Isn't Ctrl + a typical shortcut used to increase font size?
Lars, presumably nothing is stopping the user from doing these things themselves if they make sense (to them). I expect that folks will most likely already have the window maximized but if they don't perhaps they have a reason. If I get around to doing the 'proper' version that works against the whole presentation I'd likely maximize the window as well. As far as hiding the window goes I'm just afraid of regressions, also we'd have to change the perspective switching logic to 'know' that it may have to turn the window visible again. Bear in mind that this is supposed to be an example of how folks can do useful things *without* having to hack on the renderers... Michael, If only we could do that...;-). As the fogie that I am I reset my screen res since it's too painful to adjust all the different fonts manually. If you're say we might like to 'reserve' the '+' keybinding for that use I'm open to suggestion as to an alternate binding...
(In reply to Eric Moffatt from comment #5) > Lars, presumably nothing is stopping the user from doing these things > themselves if they make sense (to them). I expect that folks will most > likely already have the window maximized but if they don't perhaps they have > a reason. I had my window maximized, the new window was not maximized. I agree that the new window should be the same size as the original one but this was not the case for me.
(In reply to Lars Vogel from comment #6) > I had my window maximized, the new window was not maximized. I agree that > the new window should be the same size as the original one but this was not > the case for me. Looks like you are setting the flag to maximize but it seems not be respected. Maybe a bug in the renderer. dw.getTags().add(IPresentationEngine.WINDOW_MAXIMIZED_TAG);
As a shortcut I think we should be using something similar as Ctrl+M (maximize editor). How about Shift+Ctrl+M? Bye the way Eric, I think that is a very cool feature, should be nice to deliver it with the SDK build.
On Windows that would be F11, currently occupied by Debug.
Lars, Could you attach a screen shot of what you see when you hit Ctrl + '+' ? What build and platform are you on ? The expected effect (and what I see) is that you get a new, maximized window with no borders hosting what you had...
Created attachment 240625 [details] Screenshot Here is what I get. I use Ubuntu 13.10.
(In reply to Lars Vogel from comment #11) > Created attachment 240625 [details] > Screenshot > > Here is what I get. I use Ubuntu 13.10. Build is Build id: I20140303-2000
UGH ! This also seems to have issues on the Mac (which are at least known to be only for 'inner' sessions). I'm working now on some problems with using minimized stacks while in the 'super max' state. I'll check on Monday on Linux...
Committed: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=14fb9fb831a20261cb9a2f241dd6093c4ed8b4e9 This does two things: - Removed caches that pre-supposed such things as the window the trim is hosted under (since Ctrl + moves the stacks to the DW). - Adds handling for a new tag MINIMIZED_AND_OPEN that gets set when the minimized stack is visible and whose removal causes the trim stack to close. This allows Ctrl + to 'auto-close' any open trim stacks before proceeding. There is still a small amount of work needed to make the new tag API but this is covered in bug 398837...
Created attachment 240725 [details] New version that explicitly sizes the 'full screen' window Hopefully this will get us closer to working on Linux / Macs...
(In reply to Eric Moffatt from comment #15) > Created attachment 240725 [details] > New version that explicitly sizes the 'full screen' window > > > Hopefully this will get us closer to working on Linux / Macs... Just tested this on Linux and it work fine. Now that I used it, I also agree with Eric it should not maximize the editor, it is fine as it is. Only I still like to have M1+M2+M a shortcut but I guess that is just personal preference.
Even Quick Access works fine, it just looks a bit weird, as this input box is not displayed, but filtering still works.
Maybe also add the Shortcut to restore the menu and toolbar in the Window "Titlebar"
(In reply to Lars Vogel from comment #17) > Even Quick Access works fine, it just looks a bit weird, as this input box > is not displayed, but filtering still works. Quick Access has been fixed, if the SearchField control is not visible we show the old dialog.
What's the state of "Code Focus"? I just tried attachment 240725 [details] with Luna SR1 on Windows 7 with a dual display configuration and got some "interesting" results... Eclipse is maximized to span over both displays, maybe not exactly the ideal result. I'd clearly prefer to have it use only one of the 2 displays.
Fredrik, I've move on so I'm no longer available to update this code. This looks like an excellent opportunity for you to step in by making a patch for the current code that uses only the current monitor. I'm pretty sure if someone starts contributing patches to this then its chances of making it into the Mars release will go up...;-).
Created attachment 248718 [details] Updated version supporting multiple monitors Attaching an updated version of CodeFocus which adds support for mulitple monitors, i.e. only maximizing within the current monitor.
(In reply to Fredrik Attebrant from comment #22) > Created attachment 248718 [details] > Updated version supporting multiple monitors > > Attaching an updated version of CodeFocus which adds support for mulitple > monitors, i.e. only maximizing within the current monitor. Awesome Fredrik, I have a look at it during M5 and try to integrate it into platform. Thanks.
Placed the CodeFocus project on github to make it easier to access and maintain: https://github.com/fredrikattebrant/CodeFocus.git
*** Bug 171398 has been marked as a duplicate of this bug. ***
Moving to 4.6, I'm concerned that introducing this in M7 is a bit late as this might introduce hard to track bugs. We plan to publish this via the marketplace to gather more feedback and if that works fine bring it into Eclipse 4.6 standard.
(In reply to Lars Vogel from comment #26) > Moving to 4.6, I'm concerned that introducing this in M7 is a bit late as > this might introduce hard to track bugs. We plan to publish this via the > marketplace to gather more feedback and if that works fine bring it into > Eclipse 4.6 standard. Just fyi, installed this into Eclipse Neon M1. The combination of the 'native' Ctrl-M with CodeFocus' Ctrl-+ functionality is a nice/simple set of options. And so far, works well. I notice that the native Ctrl-M is available/editable in Prefs -> General -> Keys keymmapping dialog. Afaict, the CodeFocus cmd is *not* editable or even available. Should it be? Or does that require "bringing it into Eclipse 4.6. standard"?
I think the suggest solution is unnecessary complex. I think modifying the visibility of the existing toolbar is easier. I upload a Gerrit review later today so that other people can test.
New Gerrit change created: https://git.eclipse.org/r/57644
Gerrit change https://git.eclipse.org/r/57644 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=f65a456e5e425215ffddf92d3b0c561f91b0a2c2
(In reply to Eclipse Genie from comment #30) > Gerrit change https://git.eclipse.org/r/57644 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=f65a456e5e425215ffddf92d3b0c561f91b0a2c2 Merged so that people can test this easily.
New Gerrit change created: https://git.eclipse.org/r/57665
Gerrit change https://git.eclipse.org/r/57665 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=f00b3e87686791a00fa59460cb01b60c6fd9a76a
New Gerrit change created: https://git.eclipse.org/r/57691
Gerrit change https://git.eclipse.org/r/57691 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=645f0e9a42041f930dfcfcef1973cfe95170ebb9
Took it for a spin on a Mac and it looks good and clean. I'm getting some glitches in where the focus goes, but I'm not sure if that's related to this or some other Neon issue. Noticed a typo in the command text - "Toogle" instead of "Toggle": diff --git a/bundles/org.eclipse.ui/plugin.properties b/bundles/org.eclipse.ui/plugin.properties index 3fcc828..5d5dc8d 100644 --- a/bundles/org.eclipse.ui/plugin.properties +++ b/bundles/org.eclipse.ui/plugin.properties @@ -168,7 +168,7 @@ command.linkWithEditor.name = Toggle Link with Editor command.maximizePart.name = Maximize Active View or Editor command.maximizePart.description = Toggles maximize/restore state of active view or editor -command.windowsHideTrimbars.name = Toogle Visibility of all Toolbars +command.windowsHideTrimbars.name = Toggle Visibility of all Toolbars command.windowsHideTrimbars.description = Toogle the visibility of all toolbars command.minimizePart.name = Minimize Active View or Editor command.minimizePart.description = Minimizes the active view or editor
New Gerrit change created: https://git.eclipse.org/r/57738
(In reply to Fredrik Attebrant from comment #36) > Noticed a typo in the command text - "Toogle" instead of "Toggle": I use to much Google. ;-) Will be fixed with the next review
New Gerrit change created: https://git.eclipse.org/r/57739
Gerrit change https://git.eclipse.org/r/57738 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=c6821a4936274706e86eb9a4f7f93b1aecb7ccfb
Gerrit change https://git.eclipse.org/r/57739 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=4d62aec40e24918d6b8436fa87d89f51a8a504c7
I changed the shortcut to M1+M3+M (Ctrl+Alt+M) as this was not yet taken by JDT. Thanks Fredrik for the testing, focus and keyboard shortcuts seems to have issues but that is not related to this bug. Thanks also to Eric for the original idea, I think this is a big enhancement for every Eclipse user. For the Eclipse 4.5 users I will integrate it shortly into Saneclipse (http://saneclipse.vogella.com/).
(In reply to Lars Vogel from comment #42) > I changed the shortcut to M1+M3+M (Ctrl+Alt+M) as this was not yet taken by > JDT. At least on Mac, M1+M3+M is bound to: "Extract Method..." (refactor Java) Not sure why not use M1+'+'? Is it due to different international keyboards or just that it is so "different" from M1+M?
We are planning to use M1++ to increase the font size.
(In reply to Lars Vogel from comment #44) > We are planning to use M1++ to increase the font size. That still leaves the conflicting keybinding with with "Extract Method..." on Mac.
Can this make it into 4.5.2?
Ctrl+Alt+<X> shortcuts should not be assigned by default, since Ctrl+Alt is equivalent to AltGr on many international keyboards on Windows. E.g. on a German keyboard, Ctrl+Alt+M produces the Greek letter mu: µ. This is broken in master. (In reply to Fredrik Attebrant from comment #46) > Can this make it into 4.5.2? No, 4.5.2 is a maintenance release (no new features).
New Gerrit change created: https://git.eclipse.org/r/58342
Gerrit change https://git.eclipse.org/r/58342 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=5075cdee291c41bc340828b9771c8ee5fd0a8e32
(In reply to Markus Keller from comment #47) > E.g. on a German keyboard, Ctrl+Alt+M produces the Greek letter mu: µ. This is broken > in master. I removed the shortcut, you can again use Ctrl+Alt+M to produce µ on a German keyboard. :-) Could you point me and others for reference to the rule which describes that Ctrl+Alt+<X> shortcuts should not be assigned by default?
How about: http://blogs.msdn.com/b/oldnewthing/archive/2004/03/29/101121.aspx "You may have noticed that Windows doesn't use Ctrl+Alt as a keyboard shortcut anywhere. (Or at least it shouldn't.) If a chorded modifier is needed, it's usually Ctrl+Shift. That's because Ctrl+Alt has special meaning on many keyboards. The combination Ctrl+Alt is also known as AltGr, and it acts as an alternate shift key. For example, consider the German keyboard layout. Notice that there are three keyboard shift states (Normal, Shift, and AltGr), whereas on U.S. keyboards there are only two (Normal and Shift). For example, to type the @ character on a German keyboard, you would type AltGr+Q = Ctrl+Alt+Q. (Some languages, like Swedish, have a fourth state: Shift+AltGr. And then of course, there's the Japanese keyboard...)"
