Friday, September 21, 2007

Super editor zoom - proof of concept.

David Clegg mentions in this post a new super secret, "super zoom" feature.  First of all the reason this "feature" isn't on by default is that it was implemented as a very quick hack to more or less simply be a proof of concept for the team to play with.  As such, it is riddled with problems that if you start using it you may encounter.  It is actually somewhat ironic that this comes up now because for the last couple of days I've been looking at this feature and how it should actually be implemented.

The way it is currently implemented is to simply hide/show the dock sites on the editor form.  This causes a couple of major issues.  First of all, when in the zoomed mode, you cannot easily get back to the other views without unzooming first (and you must to use the mouse for this operation).  Zoom the editor, then select View|Project Manager... nothing happens.  That is because the form is visible, but the site into which it is docked is not.  Try switching desktop states, by starting the debugger or manually from the desktop state dropdown... then it gets really interesting.  Again, it was only for some internal research and a proof of concept.

Similar to my post about adding auto-save and recovery of files to the IDE, I'll go through and outline the behavior I'd expect this feature to adhere to.  As I mentioned in the previous paragraph, this feature takes the somewhat naive approach of hiding and showing the dock sites.

The first modification to this code is to iterate through all the dock sites on the editor form and then go through all the docked clients within each side and hide them individually.  This will allow the docking system to properly track their state.  It will also allow you to still selectively re-show specific views.  Selecting View|Project Manager will now properly display the Project Manager view in its properly docked position.   The next change is how the "unzoom" is handled.  As there can be several views that are not visible when the view is zoomed, you want to make sure they remain hidden when unzoomed unless they were explicitly shown while zoomed.  Another requirement is that for all "unpinned" views, they should remain unpinned and accessible.  So there could still be a thin strip on the sides and bottom where the views can still pop up.  Finally, any large desktop changes, such as switching states, loading a new project with a saved desktop, etc should cancel the zoom state.

I'm sure the next question on everyone's mind is why wasn't this feature just finished and done right for RAD Studio?  The simple truth is that it fell too low on the priority list to make it into the product.  Things like this are always going to happen where good intentions just sometimes don't make it because of the reality of the schedule and other priorities.  Another side effect of this is that we can also get some direct feedback from the field as to the overall usefulness of the concept (irrespective of the implementation) before devoting actual resources to it.  By all means, follow the instructions from David and play with it.  Even given its limitations and shortcomings there is enough there to get the idea of what it would do.

10 comments:

  1. On another hidden feature, sync edit params, I've just discovered in CRS2007 they don't work as well as they did in BDS2006. The parameters are filled in but sync edit is no triggered. Is this by design? I was actually quite surprised to find no official checkbox to turn this useful feature on/off.

    ReplyDelete
  2. Allen,

    What is the job description for chief scientist in CodeGear?

    I know you have implemented many awesome features into IDE (specially the Open Tools API) and this may be your base of continued interest in IDE, but I always thought that the chief scientist did the compiler/language stuff.

    How are technical areas distributed between teams in CodeGear?
    I'd always wanted to know the winner organization formula of the late Borland for creating something as sophisticated as Delphi :)

    ReplyDelete
  3. One editor feature that would be VERY useful is split screen. I can't tell you how many times I've wanted to view a procedure and a call, or a procedure and a declaration in the same file. I used to have this In Another Environment and it was used a lot. If it's made its way into D2007 I haven't found it yet. Clues?

    ReplyDelete
  4. K A,

    Why force me into a box ;-)? There are talented engineers already in charge of the implementation and design of the compiler. Make no mistake, I am certainly involved in the design of the language, as I'm also involved in the design and evolution of the RTL and VCL. The IDE happens to live at the crossroads of all the other technologies we do. The IDE is also how you, the developer, interact with these same things. I like to keep my hands dirty with those things I feel I can contribute to the most. I'm afraid I'd just be in the way if I were to start poking at the compiler... I think I'd be kindly asked to stop helping :-). I like to think my opinion matters, but I will defer many decisions to those that are most able to make them. Micro-manager, I am not.

    Allen.

    ReplyDelete
  5. Dan,

    I agree. However there are a couple schools of thought on that one. There is the VS/Word approach, which just allows the one file to have two separate views, either horizontally or vertically. Then there is the "legacy" Borland/CodeGear technique that allows nearly unlimited nesting levels of splitting that forms a mosaic of editor panes. Each pane can also contain [I]any[/I] file. This doesn't work very well for the tabbed metaphor we're using.

    The former is far easier to implement and probably works "as people expect." Whereas the latter is a lesser known implementation and could be far more difficult to both implement and explain how to use.

    Allen.

    ReplyDelete
  6. Why not have something like the debug layout. Make two new layouts called "Zoom" and "SuperZoom" which can be selected from the layout combo as well as being triggered by a short cut. Thus the user can define what is visible in these layouts and you only have to implement the same logic as for the debug layouts (i.e. activate with a key code, restore the former when pressed again).

    Suggestion: let the user define hot keys for any layout.

    May be it requires to fix this error first:

    Report No: 47453 (RAID: 252136) Status: Open
    Dock Tabs appear at wrong position
    http://qc.codegear.com/wc/qcmain.aspx?d=47453

    ReplyDelete
  7. Allen,

    Implementation details aside, the IDE needs the single file split screen. Dunno how else to say that. What's more, it needs to be simple to use and not hidden in 15 layers of Alt-Ctrl-Shift-Key options. Put a splitter bar at the top, like has existed in VB IDE's for years. It's useful. Later, if you want to sync or something that's fine but don't let any of that get in the way of simple two view file editing. One view window, one edit window, switch between them.

    Simplify simplify simplify. While you're at it, have 'em make the block tab work off the tab if multiple lines are highlighted instead of Ctrl-Shift-I (I think that's what it is). Did I say simplify?

    Just an opinion.

    Dan

    ReplyDelete
  8. Dan,

    I am certainly in favor of the single file split screen approach. In practice this is far more the common use case than the old-style BRIEF technique of "editor pane" hell...

    Allen.

    ReplyDelete
  9. Allen,

    I've missed a simple, single-file split view since I first started using Delphi, so I agree with everything Dan has said. Though I think he neglected to mention "simplify" ;-)

    Cheers
    Ian

    ReplyDelete
  10. I confess I'm guilty of overusing BRIEF editor panes myself but going to 1 is a deeper cut than we need .

    Simple usage is critical in all the IDE functions if you expect to attract new blood. You can make the more obscure stuff available for the zealots as more complex actions and they'll still use them.

    Never hide Simple. Put it out front where everybody can find it!

    I'm looking forward to seeing a baby splitter bar show up in the editor Real Soon Now.

    Dan

    ReplyDelete

Please keep your comments related to the post on which you are commenting. No spam, personal attacks, or general nastiness. I will be watching and will delete comments I find irrelevant, offensive and unnecessary.