Author Topic: Dockable and undockable edit windows.  (Read 10047 times)

chucky666

  • Junior Community Member
  • Posts: 4
  • Hero Points: 0
Re: Dockable and undockable edit windows.
« Reply #15 on: October 21, 2011, 11:23:52 AM »
I would like to have possibility to open separate window off SE main dock windows. I use dual - monitor and want to have two files from one project open simultaneously.

rowbearto

  • Senior Community Member
  • Posts: 2335
  • Hero Points: 132
Re: Dockable and undockable edit windows.
« Reply #16 on: October 22, 2011, 04:42:09 AM »
I second the last post.  Being able to move an editor window outside of docking in SlickEdit for multiple monitors would be very useful - so two different files of the same project could be open in 2 monitors.

BBanzai

  • New Community Member
  • Posts: 1
  • Hero Points: 0
Re: Dockable and undockable edit windows.
« Reply #17 on: December 19, 2011, 06:32:25 PM »
A "Tile Vertical" option under the Window menu.  Also, the ability to re-arrange the window tabs by just dragging the tabs to the desired location.

It would also be nice to be able to drag and dock a file window with any side.

For examples of this concept, the NetBeans IDE has this ability.

rod_gomz

  • Community Member
  • Posts: 80
  • Hero Points: 1
Re: Dockable and undockable edit windows.
« Reply #18 on: December 29, 2011, 07:43:25 PM »
A buffer window in SDI style to take advantage of multiple monitors.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6823
  • Hero Points: 526
Re: Dockable and undockable edit windows.
« Reply #19 on: December 29, 2011, 08:12:06 PM »
A buffer window in SDI style to take advantage of multiple monitors.
Dragging edit windows outside the mdi frame is currently planned for v18.

chucky666

  • Junior Community Member
  • Posts: 4
  • Hero Points: 0
Re: Dockable and undockable edit windows.
« Reply #20 on: March 01, 2012, 05:22:36 PM »
* Support for nested C comments
* Dual monitor support:
   1) When using right-screen editor, code complete mini-window spans through both screens, so part of it is not visible. I consider it as bug. Hint window should be entirely only on one screen.
   2) ability to open windows on separate screens, there could be possibility to open single file twice (one should be read only, and second to write to), each on separate screen.

Zytoblast

  • Community Member
  • Posts: 6
  • Hero Points: 1
Re: Dockable and undockable edit windows.
« Reply #21 on: November 09, 2012, 11:44:51 AM »
Coming back to SE after working over a year with other IDEs, here is what I still miss most:

1. A keyboard shortcut for the "Auto Hide" option of tools windows. Since there can be more than one group of tools, it would be great if each could have an individual shortcut. Currently as a workaround I move some tools onto the 2nd monitor, which unfortunately I cannot group there (see next topic) and I use the fullscreen option to "hide" the tools windows on the 1st monitor (which unfortunately unnecessarily also hides the tools on the 2nd monitor, *sigh*). There is a nice quote from SE's user manual: "Keep your hands on the keyboard - Time is wasted each time you reach for the mouse"...

2. Proper multi-monitor support:
- Grouping of tools on secondary monitors is not possible currently.
- The single biggest weakness of SE (strictly subjective, of course) still is missing support for moving editor windows on a 2nd monitor. (I know of the +new command line workaround, but it's neither convenient, nor does it work very well when working within the same project.) How about an SDI/MDI option? Having read about the improvements in SE2012 ("Much of our energy this year has been spent on reengineering SlickEdit to use a new user interface architecture. This will allow us to more quickly implement new user interface features in forthcoming versions.") I finally have new hope for this feature to be implemented finally :-)

3. A little preview window which shows what buffers you will switch to when you go to the next/prev window (usually Ctrl+Tab / Ctrl+Shift+Tab), so you can tab to the window you are looking for instead of stepping through multiple windows before you finally find the one you want to go to. (Seems to be a "standard" now in other IDEs, like Eclipse, NetBeans, VS, etc. and I got used to it pretty quickly.)

4. Support for ActionScript3/Flex (MXML) would be great. But I know this is not such a general feature as 1-3, so this is strictly an optional wish to not have to switch IDE for mobile App development.

Several other features I would have requested magically appeared in the new versions while I had my foreign affair with other IDEs, most notably Maven and Git support. Thank you!
« Last Edit: November 09, 2012, 12:18:49 PM by Zytoblast »

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6823
  • Hero Points: 526
Re: Dockable and undockable edit windows.
« Reply #22 on: November 13, 2012, 04:47:26 PM »
Yes, we read them ;D We've been looking at Clang. Nothing planned for the next release though. The next release will allow MDI child edit windows to be dragged outside the MDI area for better multi-monitor support. A ctrl-tab preview would be nice.

jwdonahue

  • Community Member
  • Posts: 10
  • Hero Points: 0
Re: Dockable and undockable edit windows.
« Reply #23 on: October 21, 2014, 11:05:37 PM »
Please return to the pre-2013 editor windows on the windows version.  At least make it a configurable option.  I really hate the Visual Studio look and feel.  If you aren't going to offer an alternative, I might as well use Visual Studio and save a lot of money.  Being able to float the windows outside the main window frame would be a nice option, but I don't like that mode for all of my windows and the way they behave when they are docked just sucks.

jorick

  • Senior Community Member
  • Posts: 390
  • Hero Points: 17
Re: Dockable and undockable edit windows.
« Reply #24 on: November 05, 2014, 02:54:39 PM »
I sometimes do a Window->Duplicate to create a second window so that I can work in the top and bottom of the same file at the same time.  I also have 4 monitors so sometimes things get a little misplaced (okay, downright lost).  Right now I'm looking at the CFile.c:2 window and I can't find CFile:1.  It would be nice if I could click on the file in the File Tabs and it would cycle through the various :1 ... :n windows and bring them to the front.

I know about Window->Windows.. and then scroll down to the window I need to find but considering I have an average of 3 duplicated windows open at once in a list of up to 50 files, it's a little tedious.

jorick

  • Senior Community Member
  • Posts: 390
  • Hero Points: 17
Re: Dockable and undockable edit windows.
« Reply #25 on: April 26, 2016, 05:44:07 PM »
I run three tab groups in the SE main window.  Occasionally I'll close a file that's the only file in a tab group so the tab group also closes leaving me with two on the screen.

I would like an option that would leave the tab groups open even if they have no files in them.  Yes, I know that I can create a tab group with either the Window menu or by dragging a file over to the edge of a group.  I just don't like getting a surprise when my tab group disappears.

jwiede

  • Senior Community Member
  • Posts: 112
  • Hero Points: 12
Re: Dockable and undockable edit windows.
« Reply #26 on: June 08, 2016, 12:18:22 AM »
My Wish List:

1. Custom "segregable" (color/grouping/separate-lines/etc) file/buffer tab displays
I often find myself working with similar-named files from multiple projects at once, often comparing differences between the same-named files.  Recent VisualStudio (V13 onwards, IIRC) offers different "types" of tab groups (grouped by end, grouped as separate lines, etc.) and it would be nice if users could segregate open files in a similar manner in SE.  Clarifying, I am not asking here for multiple projects at once (that's a different ask), this is strictly about supporting new means of grouping/segregating file tabs in the file tab display(s).

Ideally, I'd like a system where I could run a set of arbitrary user-set ordered rules against a newly-opened file (or buffer) in order to assign it to different filetab "groups" (or assign different attributes, like color).  Attributes/grouping options would include {left, middle, right} in tab line, tab color, tab text attributes, separate tab lines, and so forth.  Conceptually similar to where Visual Studio is going with tab handling, or where VisualStudio third-party extension "VisualDocs" allows with their custom tab display.

As a stretch goal, allow users to open multiple "file collection" windows/panes across multiple monitors (with distinct sets of filetabs), and allow them to use rules to segregate both window to use and how to configure filetab.

2. Support for "Peek"-type view displaying definition/declaration/etc.
VisualStudio 2015 (V14) has provision now when user wants to see associated definition/declaration, instead of having to open distinct file buffer, it can temporarily pop up an overlay which shows the file containing the relevant definition/declaration, in a scrollable view, but which disappears upon next editing action into main view.  This allows quick perusal of references without causing overpopulation of open files (nor disruption of filetab schema).  Doing so is much more real-estate effective, IMO, than the "open ref file as normal tab, but on right end of tab line, and close on next lookup action used with VisualStudio2013 (IIRC).

3. Elastic Tabstops
See Nick Gravgaard's article and discussion of them here.  This would be _very, very_ useful, esp. if it could properly interoperate with other implementations.

4. Allow multiple open projects/workspaces at once
This was always kind of inevitable, wasn't it?  Unless/until #1 is implemented, perhaps give different projects'/workspaces' files their own tab lines.  Once #1 exists, allow rules to use "project"/"workspace" as differentiator in rule generation.

That's all for now, thanks as always for all the hard work!!

jwiede

  • Senior Community Member
  • Posts: 112
  • Hero Points: 12
Re: Dockable and undockable edit windows.
« Reply #27 on: August 21, 2017, 02:30:49 AM »
My Wish List:

1. Custom "segregable" (color/grouping/separate-lines/etc) file/buffer tab displays
I often find myself working with similar-named files from multiple projects at once, often comparing differences between the same-named files.  Recent VisualStudio (V13 onwards, IIRC) offers different "types" of tab groups (grouped by end, grouped as separate lines, etc.) and it would be nice if users could segregate open files in a similar manner in SE.  Clarifying, I am not asking here for multiple projects at once (that's a different ask), this is strictly about supporting new means of grouping/segregating file tabs in the file tab display(s).

Ideally, I'd like a system where I could run a set of arbitrary user-set ordered rules against a newly-opened file (or buffer) in order to assign it to different filetab "groups" (or assign different attributes, like color).  Attributes/grouping options would include {left, middle, right} in tab line, tab color, tab text attributes, separate tab lines, and so forth.  Conceptually similar to where Visual Studio is going with tab handling, or where VisualStudio third-party extension "VisualDocs" allows with their custom tab display.

As a stretch goal, allow users to open multiple "file collection" windows/panes across multiple monitors (with distinct sets of filetabs), and allow them to use rules to segregate both window to use and how to configure filetab.

2. Support for "Peek"-type view displaying definition/declaration/etc.
VisualStudio 2015 (V14) has provision now when user wants to see associated definition/declaration, instead of having to open distinct file buffer, it can temporarily pop up an overlay which shows the file containing the relevant definition/declaration, in a scrollable view, but which disappears upon next editing action into main view.  This allows quick perusal of references without causing overpopulation of open files (nor disruption of filetab schema).  Doing so is much more real-estate effective, IMO, than the "open ref file as normal tab, but on right end of tab line, and close on next lookup action used with VisualStudio2013 (IIRC).

3. Elastic Tabstops
See Nick Gravgaard's article and discussion of them here.  This would be _very, very_ useful, esp. if it could properly interoperate with other implementations.

4. Allow multiple open projects/workspaces at once
This was always kind of inevitable, wasn't it?  Unless/until #1 is implemented, perhaps give different projects'/workspaces' files their own tab lines.  Once #1 exists, allow rules to use "project"/"workspace" as differentiator in rule generation.

That's all for now, thanks as always for all the hard work!!

Any hope for #2 or #3 coming in V22?

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6823
  • Hero Points: 526
Re: Dockable and undockable edit windows.
« Reply #28 on: September 12, 2017, 03:11:16 PM »
Not planned for v22. #2 neat that you can edit but there's a problems with overloading. After you add a parameter, then you won't get the right symbol in the insert edit window.  SlickEdit's preview tool window is read-only. Maybe the preview tool window should be changed to be read/write. Navigating to a symbol can solve  any overloading issues. SlickEdit is more forgiving in the simple overload case.

jwiede

  • Senior Community Member
  • Posts: 112
  • Hero Points: 12
Re: Dockable and undockable edit windows.
« Reply #29 on: September 22, 2017, 07:02:40 PM »
Not planned for v22. #2 neat that you can edit but there's a problems with overloading. After you add a parameter, then you won't get the right symbol in the insert edit window.  SlickEdit's preview tool window is read-only. Maybe the preview tool window should be changed to be read/write. Navigating to a symbol can solve  any overloading issues. SlickEdit is more forgiving in the simple overload case.

W.r.t. #2, I'm actually okay if the peek view doesn't allow editing in-view, as in if the pop-up view is read-only.  Would that make a difference whether doable in v22?

Any reason why no #3 in v22?  Can we at least get some vertical alignment options for styling (a la Code Alignment)?