Community
Participate
Working Groups
So I appreciate the likely well intentioned UI developments, but apparently many of us are puzzled by the change in how editors are now split and maximized: http://stackoverflow.com/q/11503272/403455 It seems the user experience was not really well thought through with respect to these changes. Might I suggest that this interface be rethought? I'd start by dumping the drag-to-define whether or not panes should be maximized individually or with their neighbors interface. First, the instance of a user splitting an editor in two is the wrong time to be "asking" the user whether or not to maintain both views if he or she decides to maximize the editor someday. To top it off, the visual indication of the user's decision about this is confusing at best. Instead, I propose that you dump the varying green line interface and instead shift the decision to the time when it actually matters--that is, when the user decides to maximize the editor. Maybe the following would work better: There should be a small "editor maximize" button in the upper right corner of the "complete" editor pane. This would always maximize all panes in the editor. There should always be a maximize/minimize pair on each editor split as well that would maximize/minimize that particular split.
Jeff (I'm guessing that's your first name...;-). I think that what you propose is actually quite close to what we have. The idea is that when you have split the 'shared area' (because it's shared between all the perspectives) it makes more sense to maximize the while thing rather than individual editors to support comparisons. Note that on most systems it is a small upper frame (where your screen cap shows it to be quite large, perhaps a GTK upgrade might solve this... I agree that the feedback isn't all that it could be but the complete implementation of the split feedback and behavior is contained in SplitDropAgent which is only 388 lines, perhaps you could patch it to show what you want... ?
Hi Eric, yes it's Jeff, and I'm from Glenview :) I don't think my suggestion was clear enough. I'm saying that when the user is dragging a tab to create a new split, the UI should not be asking users to predict how they plan to maximize the editor in the future. There's a cognitive dissonance there--it's not at all relevant. The user simply wants to view the files side by side. The time for the UI to ask about desired behavior during maximizing is when users ask to maximize. I believe that my proposal accomplishes that. I've attached a chicken-scratched prototype drawing to show you. This is how splits would *always* be displayed--basically a combination of Juno's two "modes". Users would click the outer maximize if they wanted to view all of the panes side by side in full screen mode, but would click the maximize button within individual panes if they wanted a single pane maximized. I have never touched Eclipse's internals; so I'm sure I'm not the best person to start on this.
Created attachment 221436 [details] Chicken scratched mockup
Yes, we had discussed such an arrangement and decided against it as being too confusing... I do have a trick you can try though...if you drag the editor to the left until you get the wider / narrower feedback and *Hold the Ctrl key* you'll notice that the color changes. If you drop in this state you've created a stack *outside* the shared area. The downside is that the stack that's not shared is, of course, not shown in other perspectives.
Ok, so first question is--was there any usability testing done? Try to enter "beginner's mind." http://en.wikipedia.org/wiki/Shoshin It's beyond me how anybody could reasonably conclude that "a vertical green line of varying 1/3, 1/2 split that indicates whether in the future, clicking maximize will result in side-by-side view or a single pane view respectively." is less confusing than "an outer icon for maximize everything and inner icon to maximize one pane." I could see the argument made for screen real estate--not that I'd agree with it, but certainly not that it's more confusing than what Juno is offering right now. Regarding the control-key color change, I tried this and I don't understand what it did. The only effect I observed was that after splitting the window and moving the right-hand tab over to the left-hand pane, the editor was still split--just with an annoying empty pane on the right, which I have no idea how to eliminate :)
(In reply to comment #5) > Ok, so first question is--was there any usability testing done? Try to > enter "beginner's mind." http://en.wikipedia.org/wiki/Shoshin Thanks.
Sure Wim. It was meant in all seriousness. It helps me when designing UIs. Incidentally, after thinking about this some more, I realized there's another problem with the Juno strategy for determining the window maximizing strategy during the split. Suppose a user has split the screen according to the "show me both panes during maximize" strategy, then opened up a bunch of tabs in each pane. After he has committed to the strategy, suppose he wants to show just one. There's no going back without either opening a new window or closing all the tabs in the other pane. P.S., come on, you guys didn't like the colorful bug headline?
OK, here's the scoop. We have no resources so while I would (dearly) love to work on this for a couple of weeks I can't. All the DnD work is identifiably unfinished because it *is* unfinished, it was deemed more important to have Juno functional than polished. That being said the complete implementation of this code is in SplitDropAgent which is a *total* of 389 lines of java (including the feedback). If someone has the time to spend cleaning this up we'll gladly help where we can... Note that if so desired the complete DnD setup is an Addon (DnDAddon). This means that you can very simply remove the existing one and replace it with your own...this is also true of the MinMaxAddon...
Is there any chance of this being worked on? This winds up being quite the productivity loss for me, as I'm constantly toggling between standard and maximized views of the editors.
There is some hope, we've been getting some contributions in this area lately (see bug 430662, thanks Sergey!). While I doubt they'll address all you issues I think that the new feedback (coming in Luna M7) is at least more descriptive of what is actually going to happen. At the end of the day this isn't the hottest issue on our plates so further progress will likely have to come from outside contributions...
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. If the bug is still relevant, please remove the stalebug whiteboard tag.
This is even worse now in 4.13 (2019-09 R) When dragging a tab, then depending on the position a 1/2 split is offered or 1/3. But when the mouse button is released, there is always the same result, no matter the position. (the result is a split with a single set of min/max buttons, not one for each half) Apparently someone changed the behavior (the final result), but not the showed (guide)lines that appear while still holding the mouse button. The choice of holding CTRL while click/dragging is also very bad. It is not intuitive and not discoverable. In the old version one could see during dragging that there are two ways and one could try both and see how they work and differ for each other. For ctrl one must decide to read the docs and then find the specific description (or try different modifier keys all the time to see if the do anything - unrealistic) (also, I dislike the choice of min/max buttons having a separate line, it is a waste of screen space. It would make sense if both sets of buttons were displayed, as in the idea in comment 3)
*** Bug 558251 has been marked as a duplicate of this bug. ***
