Re: Too many editor tabs?

Hi All,

I think that you could have a limit to the number of editor panes open 
at one time. I quite like the way it is set up at the moment, although 
when using the debugger I would like to be able to get it to close the 
panes that I didn't have open before.

David

Paul Byrne wrote:

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