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?

49 comments
Comment actions Permalink

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:

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?




--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

0
Comment actions Permalink

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

0
Comment actions Permalink

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.

0
Comment actions Permalink

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

0
Comment actions Permalink

Dave Griffith wrote:

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


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.

0
Comment actions Permalink

+1

Keith Lea wrote:

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?

0
Comment actions Permalink

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!

0
Comment actions Permalink

Grant Smith wrote:
>Then I have to close all the duplicates... Argh!

same here :/

Karol

0
Comment actions Permalink

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?


0
Comment actions Permalink

Agreed. Selected file should remain in both groups.

0
Comment actions Permalink

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..

0
Comment actions Permalink

Ralph Saunders wrote:

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..



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

0
Comment actions Permalink

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.
>

>

0
Comment actions Permalink


>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

0
Comment actions Permalink

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.


0
Comment actions Permalink

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.


0
Comment actions Permalink

dimitar wrote:

What about adding small drag-handle, just next to the scrollbar arrow
(see MS Office apps)?


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!"

0
Comment actions Permalink

Dave Griffith wrote:
>>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


I agree. I don't support any suggestion to add to the context menus.

0
Comment actions Permalink

This is how IDEA used to do it. I don't know why they changed to this
new confusing way.

dimitar 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.

0
Comment actions Permalink

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

0
Comment actions Permalink

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:

This is how IDEA used to do it. I don't know why they changed to this
new confusing way.

>

dimitar 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.
>>
>>

0
Comment actions Permalink

Keith Lea wrote:

This is how IDEA used to do it.


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.

0
Comment actions Permalink

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.

0
Comment actions Permalink

Ralph Saunders wrote:

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.


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.

0
Comment actions Permalink

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".

0
Comment actions Permalink

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:

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".

0
Comment actions Permalink

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".

0
Comment actions Permalink

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.


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.

0
Comment actions Permalink

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.

0
Comment actions Permalink

I don't want to argue with you, I think you would feel better if you
read that article.

Ralph Saunders wrote:

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.

0

Please sign in to leave a comment.