Do you like the tab group splitting behavior?
I don't like it. I expect that when I create a new tab group, the
currently open tab is the only tab over there, and it's no longer in the
original group. Instead, my open tabs are duplicated. I don't think I
ever want this. What do you guys think? Is it just me?
请先登录再写评论。
Its not just you. its a feature I would use (only ocasionally -- but
still) if it worked as you have described. Maybe someone could fix this
with a plugin?
And once the product is released I will probably take a look at writing my
own version of close unchanged tabs -- I want it to close unchanged but
only if I haven't pinned it -- Why the *!/% did JB implement pinning for
tabs if not that? That (pinning) and the tab splitting are features that
JB have come sooo close to nailing -- but haven't.
On Mon, 06 Jun 2005 21:14:57 -0700, Keith Lea <keith@cs.oswego.edu> wrote:
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Keith
It's funny: last night, before going to bed, I prepared a request that's
just about that. Feel free to vote, and comment:
"enable "Move Editor to opposite tab group" when there is none yet.."
http://www.jetbrains.net/jira/browse/IDEA-2515
Alain
For someone who has been using emacs and JEdit along with IDEA for a long time, the split behavior in IDEA leaves a lot to be desired. It will be super-cool if IDEA can support split behavior similar to emacs or JEdit.
As far as duplicating all the tabs goes, I think I am ok with it since implicitly that is the same behavior in both emacs and JEdit. It's just that the tab row(s) takes way too much real estate especally when there are splits.
I've had an open feature request for "Close all but pinned" for a while. Trust me, if it was possible to do via a plugin, I'd have done it already.
Agreed on the splitting, too.
--Dave Griffith
Dave Griffith wrote:
A quick search of JIRA shows that all enhancements around making the
pinning feature useful are in BACKLOG.
It seems like such a small thing to implement (say in comparison to
something like JSP support)
Oh well. I guess "useful tab pinning" will be a major feature in IDEA 6.0.
+1
Keith Lea wrote:
I can't stand the way it works now. If I have 10 open files, and I want to see one split, I have to have them ALL duplicated on the split. Then I have to close all the duplicates... Argh!
I was convinced that Jetbrains would NEVER implement something like this, so I wasted 30 minutes looking for a configuration setting I missed. Alas, no.
Please change it!
Grant Smith wrote:
>Then I have to close all the duplicates... Argh!
same here :/
Karol
As an experiment, I've chust changed the behaviour so that only selected file will be opened in the new split window.
As for the second part of the request (remove the file from the "old" splitter) - it is arguable. One may want to create a split on
the same file and edit different spots of it. If IDEA removed the file from the previous split this would be inconvenient.
--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"
"Keith Lea" <keith@cs.oswego.edu> wrote in message news:d83700$isc$1@is.intellij.net...
>I don't like it. I expect that when I create a new tab group, the currently open tab is the only tab over there, and it's no longer
>in the original group. Instead, my open tabs are duplicated. I don't think I ever want this. What do you guys think? Is it just me?
Agreed. Selected file should remain in both groups.
Since you have to specify the file to "split", how about providing two menu selections for splitting? One that "removes the file from the 'old' splitter" and a second menu selection that does not. That should make everyone happy..
Ralph Saunders wrote:
Something like
--> "Move file to (new) horizontal group"
--> "Show file in (new) horizontal group"
The "move to" action is still implemented but greyed out, if no opposite
group exists...
Johannes Schneider
I see your point. What you have proposed gets us 90% there. Worst case
is we have to CTRL-click a tab to kill one window. It beats doing that
to 10 windows.
Good Job.
Eugene Zhuravlev (JetBrains) wrote:
>As an experiment, I've chust changed the behaviour so that only selected file will be opened in the new split window.
>As for the second part of the request (remove the file from the "old" splitter) - it is arguable. One may want to create a split on
>the same file and edit different spots of it. If IDEA removed the file from the previous split this would be inconvenient.
>
>
>That should make everyone happy...
Except for new users, who will be confused, and those concerned with ergonomics, who will wonder why an already overly-full context menu is being crapped up with a choice that doesn't much matter.
--Dave Griffith
What about adding small drag-handle, just next to the scrollbar arrow
(see MS Office apps)?
When the user starts dragging, the handle turns to splitter.
When we release it, if it's not too close to the edge it creates a new
tabgroup with copies of all the windows. When we want to close the
group, we just drag the splitter to the end of the screen and all
windows from the closed tabgroup are merged into the main.
If this is implemented, then we could have the 'open this window as new
tabgroup' action in the context menu, which would create a single file
tabgroup.
What about adding small drag-handle, just next to the scrollbar arrow
(see MS Office apps)?
When the user starts dragging, the handle turns to splitter.
When we release it, if it's not too close to the edge it creates a new
tabgroup with copies of all the windows. When we want to close the
group, we just drag the splitter to the end of the screen and all
windows from the closed tabgroup are merged into the main.
If this is implemented, then we could have the 'open this window as new
tabgroup' action in the context menu, which would create a single file
tabgroup.
dimitar wrote:
Along similar lines, how about this behaviour:
- If you drag a tab from the top of the editor to the middle, it creates
a ghost splitter (to preview the placement of the split). When you
release somewhere away from the top edge, it creates the real splitter
(a -- type splitter). The single file that you dragged is moved to the
new tab group.
- If you do the same drag, but hold down Shift, the splitter becomes a |
type slitter.
- If you do the same drag, but hold down Ctrl, the file is copied to
the new tab group (not literally copied of course, just in the sense
that the same file remains in the old tab group as well).
- Of course, holding Shift and Ctrl together while dragging copies the
file to a new side-by-side tab group with a | type splitter.
- Dragging other files to another group moves that file (or 'copies' if
Ctrl is held down).
These behaviours could be available also from the menu, of course. Maybe
a sub-menu if the commands become too many.
--
Rob Harwood
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"
Dave Griffith wrote:
>>That should make everyone happy...
I agree. I don't support any suggestion to add to the context menus.
This is how IDEA used to do it. I don't know why they changed to this
new confusing way.
dimitar wrote:
Drag and drop, what a concept. That would be excellent for those of us who prefer to do
things visually with the mouse.
I would only add that you should be able to drag from on tab group to another or from the
project/commander/favorites tool windows to anywhere that you can drag a tab to for the same
effect.
Tim
That is the perfect solution. If you split the window, the current file
moves to the new group. If you want to see 2 parts of the same file
(sometimes very useful), grab the handles.
Keith Lea wrote:
>
>
>> What about adding small drag-handle, just next to the scrollbar arrow
>> (see MS Office apps)?
>>
>> When the user starts dragging, the handle turns to splitter.
>> When we release it, if it's not too close to the edge it creates a
>> new tabgroup with copies of all the windows. When we want to close
>> the group, we just drag the splitter to the end of the screen and
>> all windows from the closed tabgroup are merged into the main.
>>
>> If this is implemented, then we could have the 'open this window as
>> new tabgroup' action in the context menu, which would create a single
>> file tabgroup.
>>
>>
Keith Lea wrote:
There is a subtle difference - in MS Office (and many other windows
apps) the splitter is not visible until you actually split the window. I
was mildly annoyed by the always-visible splitter in IDEA 4.5.
Also, if this is implemented, we have 2 gestures - context menu and
split-handle (not a splitter).
I would suggest the keyboard modifiers to be:
Ctrl - copy the tab to the new split-group instead of moving.
Ctrl+Shift - if creating new splitter copy all tabs
Alt - change the splitter orientation (also when dragging already
existing splitter).
The other important feature would be to move all tabs to the next
tabgroup when closing the splitter (we should also have the option to
close all files in a tabgroup.)
Dragging single tabs between groups would be nice, but not a priority
for me.
How would you suggest solving the problem? My suggestion was aimed at giving the user the option to have it the way they want. I really don't care how it is implemented, as long as the end user has the control to have the IDE act the way they want it to act.
Ralph Saunders wrote:
In my experience, one trick for good usability is to avoid giving
control over fine points of behavior, to the user. We need to decide on
one way, and then we'll all learn to love it.
That is bull. The best thing about Idea is that everyone can have it the way they want it. Your answer sounds a lot like the stuff that came out of the UI discussions. The UI started out without producing source code, even though may people wanted source for some VERY good reasons. The initial response was just like your response "You'll learn to love it". I guess that is why JetBrains changed it so that the user has the option, because everyone "learned to love it so well".
I disagree that the best thing about idea is customization. I barely
customize mine from the base installation defaults. I think the best
thing about idea is all the productivity features like intentions,
inspections, refactorings, and the way many technically complex things
can be done with fewer than 3 keypresses or mouse clicks. For me,
customization does not factor into these barely at all.
I think there are many cases where customization is important, like the
UI designer, and code style. However, I think UI features are the lowest
candidates for customization, and this includes tab splitting.
Ralph Saunders wrote:
Well, there are already thoushands of options the user can currently sen in Idea, soI fail to see how one more choice would make the IDE confusing or less ergonomically friendly. That makes no sense. I also can't understand how you can say that having a choice doesn't matter. If it didn't matter, then this thread would be empty, which it is not.
I don't care if it ends up being an option on a popup menu, that was just a suggested implementation. The real issue is to make sure that Idea remains "the IDE that works the way you do".
Ralph Saunders wrote:
Let's make new users spend 3 hours per day messing with configuration
settings.
I think you should read the essay by Red Hat's Havoc Pennington at
http://www106.pair.com/rhp/free-software-ui.html - specifically, scroll
down to "The Question of Preferences" - it applies just as well to all
software as to free software.
Let's just force them to do it our way since we know waht's best for everybody. Idea is the only IDE that doesn't force it's users to think and work it's way and the way they do it is by making the behavior configurable. What's more it is usable out of the box and as you use it you can customize it to your way of coding. If a user spends 3 hours every day setting configuration options, they have much bigger problems than an IDE that is too flexible.
Your argument is rediculous.
I don't want to argue with you, I think you would feel better if you
read that article.
Ralph Saunders wrote: