Disappearing source

A number of times recently I've been siting there, looking at some source
code in a browser, and it's just disappeared.  I've just realised why - most
of the time I tend to keep my hand on my mouse (stop sniggering at the back
there!) and I must have inadvertently moved it over the tabs that select the
Category/Protocol/Variable.  Because it's sensitive to the mouse position it
switches to the new selection and the current method, and source, is
deselected.

There's probably a switch somewhere that can turn this behaviour off (?) but
I was wondering why it was on by default.  None of the other tabs in the
browser behave in this way.

Ian

Ian Bartholomew wrote:

> A number of times recently I've been siting there, looking at some source
> code in a browser, and it's just disappeared.  I've just realised why -
> most of the time I tend to keep my hand on my mouse (stop sniggering at
> the back there!) and I must have inadvertently moved it over the tabs
> that select the Category/Protocol/Variable.  Because it's sensitive to
> the mouse position it switches to the new selection and the current
> method, and source, is deselected.

I've been wondering why nobody else was commenting on what seems to me to be a
fairly big problem in the UI.  The problem is particularly acute if you have
made any changes to the method source, since then it becomes "dangerous" to
move the mouse around.

Personally. I've switched the CHB back to the default view, instead of the
slidey view, which returns to a more "classic" mode.  But I don't think that
it's enough that there should be an option to turn this behaviour off; it needs
to be re-thought.

BTW, a small but related problem with the slidey category pane is that you
loose the feedback about which category a methods is in since you can't see the
emboldened category names.

    -- chris

> I've been wondering why nobody else was commenting on what seems to me to be a
> fairly big problem in the UI.  The problem is particularly acute if you have
> made any changes to the method source, since then it becomes "dangerous" to
> move the mouse around.

I don't know if I'd say "dangerous", because it does prompt you if you
want to retain changes (though it does prompt twice, which seems like a
bug) - but "pain in the ass" certainly comes to mind.

> Personally. I've switched the CHB back to the default view

Good idea ... thanks :)

> But I don't think that
> it's enough that there should be an option to turn this behaviour off; it needs
> to be re-thought.

Good point.  I'm not sure what the advantages are of the chb slidey view
vs the classic.  For me, since I'm using an IdeaSpace for which I've
increased the extent over the default, unpinning the middle pane to gain
more real estate isn't necessary.  Also, I don't like the tabs being
vertical, it's just harder to read, especially when the IdeaSpace gets
more tabs so that its height is smaller and the vertical tabs suddenly
take up two columns instead of one.  Perhaps there can be an orientation
option for this.

-- Louis

Louis,

>> Personally. I've switched the CHB back to the default view

For the CHB, I would probably do the same.  More below.


> Good point.  I'm not sure what the advantages are of the chb slidey view
> vs the classic.  For me, since I'm using an IdeaSpace for which I've
> increased the extent over the default, unpinning the middle pane to gain
> more real estate isn't necessary.  Also, I don't like the tabs being
> vertical, it's just harder to read, especially when the IdeaSpace gets
> more tabs so that its height is smaller and the vertical tabs suddenly
> take up two columns instead of one.  Perhaps there can be an orientation
> option for this.

I started playing around with this, and found that the center pane's
"pin" ends up moving off of the right side of the display after a few
cycles :(

Perhaps the way to fix it is to have the contracted/unpinned center pane
appear with a modified pin icon in a conspicuous location, and/or offer
a context menu option to re-pin it.  I agree that the mouse-over
behavior is too harsh.  When  the tabs appear in two columns, if you
position the mouse just right, it will oscillate between two of the tabs.

An alternative might be to offer an "expert mode" (probably just another
view) that eliminates the tabs.  I _think_ that seeing the categories,
variables, or protocols would be enough information, with a right click
and menu selection to change between the "tabs".  The class/instance
choice for methods is much more important (therefore deserving pixels
that are always in view) than whether <saveMeFromJava> is a protocol or
a category (the important thing is that it works).

FWIW, my space problems with the CHB are vertical, not horizontal.
IIRC, Digitalk has an option to largely reduce a CHB to a code pane for
just that purpose.  Granted, we were lucky to have 640x480 in those
days, but the idea might remain useful.

I like the operation of the package pane in the slidy SB.  Perhaps being
in the left most position and (more likely) having only one tab makes
life easier for it??  Still, I suspect that a small visual w/ iconic
button vs. the mouse-over-sensitive elements would do the job just as well.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Chris Uppal" <[hidden email]> wrote in message
news:<[hidden email]>...
"Acute" and "dangerous" (whether quoted or not) is a little over dramatic in
my view. The underlying issue that Ian is describing is really that the
browser needlessly loses the method selection when switching filters. This
is unecessary, but if you've made changes then those are not lost because
the browser's normal prompt to retain changes will occur.

>
> Personally. I've switched the CHB back to the default view, instead of the
> slidey view, which returns to a more "classic" mode.

We knew there were some individuals that would immediately do that.

>...But I don't think that
> it's enough that there should be an option to turn this behaviour off; it
> needs
> to be re-thought.

Well this is beta software. There may be usability issues. This is the point
of the beta programme. If there's one thing we've learned about usability
over the years it is that one cannot predict what will and will not work.
Experimentation is necessary, even if many people don't like change. To
overcome a natural dislike of the unfamiliar one sometimes has to persevere
with a new feature in order to make an objective and constructive analysis.
An idea might be fundamentally flawed, or it might have detail issues.

Considering the particular feature of the hot-tracking in the sliding tray
tabs, why does that feature exist? Well it is to switch to the particular
tab you are hovering over that causes the tray to slide out - it would be
somewhat odd if that didn't happen since presumably the reason one hovers
over a particular tab is in order to see the content on that tab. However
the implementation might be better if it only auto-switched to a tab when
unpinned (i.e. on slide out).

>
> BTW, a small but related problem with the slidey category pane is that you
> loose the feedback about which category a methods is in since you can't
> see the
> emboldened category names.

At the risk of stating the bleeding obvious: If you're interested in seeing
the information in the pane (or using it for filtering), then leave it
pinned. If you're not interested then unpin it. If you can't decide, slide
it out and in, or pin and unpin at will. This flexibility doesn't sound like
a "problem" to me.

Regards

Blair

"Ian Bartholomew" <[hidden email]> wrote in message
news:[hidden email]...
I did not see a setting to disable tab auto-selection in
SlideyInneyOuteyThings, but I was able to write a line of code to allow one
to experiment with this.  If you open a few browsers and run the line of
code bellow it will turn off the auto tab selection feature for the open
browsers.  Then you can see how you like it.  I _think_ I prefer it with no
auto-selection, even when unpinned.  Others can see what they like.  This
change can be made more permanent by using standard add-on tool tricks, but
ultimately it may be good to come to a consensus on how this should work in
the default image.

"cdemers 5/23/2005 Evaluate this line to turn off auto-tab selection in all
currently open SlideyInneyOuteyThings.  This ONLY applies to views that are
open when this is run."
SlideyInneyOuteyThing allInstances do: [:each | each tabs hasHotTracking:
false].

Chris

"Christopher J. Demers" <[hidden email]> wrote in
message news:[hidden email]...

> "cdemers 5/23/2005 Evaluate this line to turn off auto-tab selection in
> all currently open SlideyInneyOuteyThings.  This ONLY applies to views
> that are open when this is run."
> SlideyInneyOuteyThing allInstances do: [:each | each tabs hasHotTracking:
> false].

And, if you don't want it to pop out when the mouse is held over it when
unpinned you could rem out the contents of
SlideyInneyOuteyThing<<onMouseHovering: .

Chris