I’m with Ian and Ferdinand. I use two styles, one for SQL and one for PL/SQL. I
typically set them myself when creating new tabs manually. And I can live with
having the sizings consistent among tabs of either of those types.
So if it’s both fast and easy to get those two styles, then I’ll be happy.
Ian writes:
This sounds like a good compromise to me - when I'm using PL/SQL, I want as
much vertical space as I can get & I'd ideally want a really stripped-down
menu structure there to give me even more space.
Spot on, Ian. With monitors wider and shorter (my old tube had a 1400px
tall screen), vertical real estate is at a premium. A layout like you
describe worked very well for me while recently writing a 1000-line package.
However, when I'm using SQL, I'm not usually that bothered about vertical
space, but I do want the data grid, DBMS output & script output tabs, for
example.
Yes, yes!
How about a [snipped]
Must...not...reply.........must...keep...on...topic...for...Michael...
Rich -- [TeamT]
Disclaimer: I'm not like most people. Pain hurts me.
I’ve had several people ask about still being able to change desktops and
this post is mostly right on the money.
I'm with Ian and Ferdinand. I use two styles, one for SQL and one for PL/SQL. I
typically set them myself when creating new tabs manually. And I can live with
having the sizings consistent among tabs of either of those types.
So if it's both fast and easy to get those two styles, then I'll be happy.
I’ve had several people ask about still being able to change desktops and
this post is mostly right on the money.
I’m with Ian and Ferdinand. I use two styles, one for SQL and one for PL/SQL. I
typically set them myself when creating new tabs manually. And I can live with
having the sizings consistent among tabs of either of those types.
So if it’s both fast and easy to get those two styles, then I’ll be happy.
I’m not sure what you mean by component sets, but if you mean that you want to see breakpoints, watches, and call stack when working with PL/SQL and see the data grid and auto trace when working with scripts then that will be possible just as it currently is. You will just need to change your desktop manually. Nothing will be lost regarding your ability to have different workspaces for pl/sql and another for other work.
Michael
I’ve had several people ask about still being able to change desktops
and this post is mostly right on the money.Ø I use two styles, one for SQL and one for PL/SQL. I typically set
them myself when creating new tabs manually.
Not sure if that is 100% spot on. I use 2 different desktops for SQL
and PL/SQL but never set them manually as they are tied to the tab type
and change automatically.
This would still be possible and you will be one of the few who notice
no ill effects of option 3. There will still be a desktop dropdown on
the toolbar and you can change the desktop at any time manually. The
change from the current behavior is that Toad will not change the
desktop automatically for you when you switch between the 2 tabs below.
The highlighted controls will still be there.
When doing PL/SQL development my typical work flow is to have a SQL tab
open or 2 which I use as a scratch pad for SQL statements I'm working on
for PL/SQL. Then I will have one or more PL/SQL tabs open for my
packages, procedures or functions. Switching between my SQL tab and
PL/SQL tab will get very annoying very quickly if I have to manually
change the desktop between them. I think this is what I'm hearing as a
proposed change.
I could have a second editor open but there will be a lot more mouse
movement going from the windows tab switching between editors and
switching between tabs in the editor to keep from switching desktops in
a single editor. So I don't see the second editor option as an
alternative. With a second editor you run into the problem of which
editor you PL/SQL goes into when you open it from the SB.
I understand your quest(no pun intended) for GUI efficiency but at the
expense of work flow efficiency I'm not seeing the benefit yet. I use
an old p4 XP machine with 3gb of RAM and never thought the editor was
sluggish or a resource hog. On my i7 at home Toad flies and don't even
notice the inefficiency of the editor repainting.
I guess we really need to see this in action in the beta to get a better
feel for these changes.
Ed
[TeamT]
On 9/2/2010 10:12 AM, Michael Staszewski wrote:
I’ve had several people ask about still being able to change desktops
and this post is mostly right on the money.Ø I use two styles, one for SQL and one for PL/SQL. I typically set them
myself when creating new tabs manually.This would still be possible and you will be one of the few who notice
no ill effects of option 3. There will still be a desktop dropdown on
the toolbar and you can change the desktop at any time manually. The
change from the current behavior is that Toad will not change the
desktop automatically for you when you switch between the 2 tabs below.
The highlighted controls will still be there.Ø And I can live with having the sizings consistent among tabs of either
of those types.If you change your desktop the sizing, position, and pinned state of
each desktop panel will be restored as defined in the desktop layout
file. It will function exactly as the current Toad GA does in this
regard. So you can still have a SQL and PL/SQL desktop where the
navigator is shown in one, but not the other and you can easily change
between the 2 desktops at any time and fully restore the desktop as you
have defined it.SQL, PL/SQL, and Text tabs are currently identical. They all can do the
exact same thing. They can all send text to the database, compile
objects, execute scripts, debug, etc. The only difference between them
now is the desktop layout and syntax highlighting. So, in the following
screenshot the 3 highlighted tab styles will be rolled into a single tab
style for your everyday use. The remaining 2 styles remain because Hex
uses a different editor control and RMAN uses rman.exe when you press
“Execute.”I hope this clears some things up.
Michael
Ed writes:
I guess we really need to see this in action in the beta to get a better
feel for these changes.
Ding-Ding-Ding-Ding-Ding!
I'm visual learner. Helps pound cool ideas through this thick skull.
Rich -- [TeamT]
Disclaimer: Thick skull and thin skin -- two great tastes in one!
Not sure if that is 100% spot on.
It is with respect to the proposed changes required for option 3.
never set them manually as they are tied to the tab type and change automatically.
That's what would need to be done with option 3. Option 2 still gains much performance, retains this auto-desktop switching behavior, but tab switching is painfully slow. The current method has to change. When we first went away from the SQL and PL/SQL editors to the current Editor we still supported SQL and PL/SQL workflow via those desktops and an independent feel between tab types. That should have been nipped in the bud early on, but wasn't.
I have to manually change the desktop between them. I think this is what I'm hearing as a proposed change.
Yes, that is what I am proposing.
The GUI update changes weren't really a contributing factor to performance issues, but the issues are noticeable for those users who have dozens of opened tabs. I don't recommend that under any circumstance, but there are those users out there who work in such environments and it should be expected that 40 or more tabs in the Editor should still work efficiently.
I guess we really need to see this in action in the beta to get a better
feel for these changes.
Option 3 will be done for the first beta for next release. Option 2 could be implemented quickly for a comparison view.
Michael
I’m really not keen on option 3 if it means manually switching between desktops
If I may ask, why would anyone have 40 tabs open?
Ian
For the beta I’ll implement a way to toggle between the 2 proposals so
that you can see it in action. If you are in the beta program try it out, if not
it would be nice if you could join to test out the proposed changes and provide
input to avoid any surprises later. The beta participants are probably the
largest contributing group to the direction of the product so it’s nice to
have people in there with differing opinions.
I agree on your 40 tab comment; however, I’ve personally encountered times
in Delphi where I’ve been digging into code and after an hour or so I may
have that many tabs opened. It’s not an easy mode for me to work in, but
often when I’m that deep even a small distraction like remembering to
cleanup unused tabs may disrupt my thoughts. Also, the 40 tabs do not have to be
in the same Editor instance. Resource usage affects Toad as a whole so even
having 4 Editors opened with 10 tabs per Editor will show similar problems as a
single Editor with 40 tabs.
I vote for Option #3.
I’m willing to go to a single desktop layout that affects all Editor tabs.
