Re: Too many editor tabs?

I don't think we should close anything automatically, the IDE will never 
manage to cover all the diverse ways users use the IDE and you will 
undoubtedly break the use case for some set of users. I'd much prefer to 
see the IDE provide the ability for users to configure actions the way 
they want in order to group windows opened by differenct actions and 
provide easy ways to close the group.

We should also be mindful that as users grow in experience their demands 
on the IDE will change. I'd suggest keeping something simple (like the 
current behavior) as the default and provide configuration options for 
power users. One such set of configurations could be....

Assuming support of undockable windows which is scheduled for NB 6 allow 
the users to have multiple top level editor windows each containing the 
current tab and menu file selection mechanism. Provide the user with the 
option of having debugger opened, find usages and search results etc 
opened into one or more top level editor windows.

For example I might to choose to have all editor panes opened by the 
debugger put into top level editor window A and all other 
'automatically' opened windows opened into top level window B. Then if I 
want to close all the debugger panes I can simply close top level window 
A (I can also iconise it if I want to come back to debugging later). I 
should also be able to drag editor panes between the top level windows 
so if I want to close all the debugger windows except one file of 
interest I can drag that file into the main editor top level window.

It would be handy to be able to edit the window title of the undocked 
editor windows so that you can tell on the OS toolbar what window 
contains what class of editor panes.

Rgds

Paul

Ivan Soleimanipour wrote:

>>Date: Tue, 21 Mar 2006 10:40:42 +0200
>>From: David Strupl <[email protected]>
>>To: [email protected]
>>Subject: Re: [nbui] Too many editor tabs?
>>
>>I am quite strongly for the "history browsing
>>GUI element" instead of "history browsing action". The action will be 
>>never discovered by the user. We need some visual element - but this is 
>>just IMHO.
>>    
>>
>
>I vote for this too.
>    I've noticed thaht many NB developers mostly interact through the 
>    keyboard only while I like pushing buttons and using menus. And
>    I find the purely GUI interaction lacking. I don't think I'm 
>    alone in this.
>So a menu pulldown would be my preference.    
>
>Marians proposal seems a lot like mine :-) with the main difference
>being that I prefer a pulldown menu while he has a GUI list.
>
>    The problem with the list is that you have to _scroll_ both
>    horizontally and vertically and that's evil. A pulldown menu can
>    accomodate width, and doesn't require vertical scrolling. It
>    can align the names so that filename beginnigs are lined up:
>    
>    	          /export/home/ivan/project/a/t.c
>    	                       /home/ivan/ref/g.h
>    	                       /home/ivan/ref/kobbla.h
>    	/export/home/ivan/project/a/subz/suby/quamali.c
>    	
>    You get a strong vertival line allowing you to zero in and
>    quickly patternmatch on the filename.
>
>  
>
>>I like the tabs idea (hmm, I have proposed it ;-) ) but if it is only 
>>pop down (or pop up) somewhere it might be enough.
>>
>>But I insist on debugger, search results and Ctrl-Click (and maybe some 
>>other actions) opening the files in this temp area not to clutter the 
>>"really" opened files area that we have on the top.
>>    
>>
>
>I think the boundry between "real/permanent" and "temp" is way
>too fuzzy such that creating distinct concepts will add to the confusion.
>
>For example ... to place a breakpoint you have to open a file. Is this
>a permanent file or a temporary "debugger" file that gets closed when
>the debug run is over?
>
>As another example ... the standard _IDE_ model of debugging is such
>that there is no debugger or debugging session. You place
>bpts at any time and then "Start under debugger". The lifetime of
>the debugging "mode" corresponds to the lifetime of the program being run.
>
>start IDE ------ run for debug ================ done debugging --- done w/ IDE
>            ^                                                   |
>            |                                                   |
>            +---------------------------------------------------+
>            
>Another model is that you decide to debug something (load a program, 
>or designate a debugge) and then repeatedly run it. Here you
>have a bona-fide debug session with which you can associate a cache
>and other settings. 
>
>
>start IDE ------ load for debug ==== run ====== done debugging --- done w/ IDE
>            ^                     ^         |                   |
>            |                     +---------+                   |
>            +---------------------------------------------------+
>            
>
>Now consider ... if you're going to associate opened files with a debugger.
>In the standard IDE model (the first one) everytime your process stops
>what's going to happen? you're going to close all "debugger" files?
>Only to want to reopen them when you rerun for debugging again?
>
>So Romans (MArtins?) IZ 35586 talks about "temporary" but temporary with
>respect to what?
>  
>