submenu "Changes ->" and STS

Andy, other STS users,

would it be possible to put STS context menu options back to the
position as they were in D5? In X6 it is now very time consuming to use
certain STS functionality because STS menu options are hidden under the
Changes submenu. For instance, I very often use "Browse method editions"
  just to revert to an old version of the method. To do this now, I have
to go trough a submenu. The same goes for "Compare with..." menu option.
Previously it was much easier to find out what was changed in the class
then it is now. Also, now it is almost a must that I implement multi
selection support for versioning packages, because going trough submenu
for versioning packages takes almost twice as much time as it did before.

Nowadays screens are big and having one or two more menu options is not
a big deal. Also, if I am not mistaken, in other dialects (Envy, Store,
Team/V, ...) these options are on a top level of context menus too.

I may be biased regarding STS ;-) so I am interested what other STS
users think.

Best regards,

David Gorisek

David Gorisek wrote:
> I may be biased regarding STS ;-) so I am interested what other STS
> users think.
I'll second your opinion.

CU,

Udo

David Gorisek escribió:
> Andy, other STS users,

> would it be possible to put STS context menu options back to the
> position as they were in D5?
 > [SNIP]
> Nowadays screens are big and having one or two more menu options is not
> a big deal. Also, if I am not mistaken, in other dialects (Envy, Store,
> Team/V, ...) these options are on a top level of context menus too.

VA/Envy has it. I also want it in root of the context menu. Perhaps
between two separators.

Best regards.

--
Esteban.

David, Others

This is all very well but let me first explain why we moved them:

1) We wanted the menubar menu and context menu to be the same. I know
that strictly speaking this isn't necessarily appropriate since the
menu bars can often contain functions that aren't specifically targeted
to one type of object. However, with the Class and Method menubar
pulldowns it seems pretty clear that these are targeted towards classes
and methods respectively.

The reason for wanting them to be the same is merely an ease of
maintenance issue coupled with the fact that I was getting fed up of
some options being in the context menu and not in the menubar and vice
versa.

2) With the introduction of STS we now have two disparate change
control mechanisms; STS and the old Source Browser/Method History
stuff. It seemed logical to group these all under the umbrella of
"Changes". I think if we move the STS menu commands back into the top
level we will also have to do this to those for the other mechanism too.

3) If all these commands (five in the class menu and three in the
method menu) are moved back up to the top levels in both the menubar
and the context menus then the logical heading of "changes" is lost and
the user is left wondering more what these things do. That's okay, but
I think that the menu commands for both STS and the old change
mechanism would have to be grouped in the same section between two
separators. This might be confusing but I think would be better than
having two additional separated sections in the top level menus with
just one or two menu items in each of them.

I'm not sure whether I've made this very clear, but I just wanted to
point out that some thought did go into the rearrangement of the menus;
it was not just done on a whim.

Personally, I'd rather leave them like they are and add some
accelerator keys for instant access (assuming that there are any left
that haven't been snaffled either by us or by scintilla). However, I'm
willing to listen to any depositions by other STS users providing you
bear in mind that there are two forces at work, ease of use for
experienced users and ease of understanding for newbies.

Best Regards

--
Andy Bower
Dolphin Support
www.object-arts.com

I agree with David. It is faster to have some of STS options in a
"direct link".

Regards Bruno

Andy Bower wrote:

> 2) With the introduction of STS we now have two disparate change
> control mechanisms; STS and the old Source Browser/Method History
> stuff. It seemed logical to group these all under the umbrella of
> "Changes". I think if we move the STS menu commands back into the top
> level we will also have to do this to those for the other mechanism too.

Actually you now have three change control / externalisation mechanisms:
package files, pax directories, and STS.  Logically, all three should be in
separate sub-menus, or all three should be grouped together in the same
sub-menu.   But if one of them is going to be promoted to top-level status,
then I know which of the three I'd prefer to see there -- and (lo!) that's
exactly what I've got.

I admit that my thinking on this might be coloured by the fact that I don't use
the package browser to save/load packages (normally), nor to drive STS
(ever)...

One small change that I think would make things slightly better without
compromising the other "forces" would be to split the "Changes" sub-menu up
into two menus, for "STS" and "PAX", and put the STS menu /first/.  The STS
menu (and so I suppose the PAX menu) could both do to be moved nearer to the
top of the parent menu.

    -- chris