Consistency

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Consistency

Ian Bartholomew-20
I was just wondering about the way the Class/System browsers select
class/instance methods.  All the other views use tabs but the
class/instance switch uses RadioButtons.

Wouldn't it be more consistent to use tabs for that as well, or is there
some other reason?

Ian


Reply | Threaded
Open this post in threaded view
|

Re: Consistency

Schwab,Wilhelm K
> I was just wondering about the way the Class/System browsers select
> class/instance methods.  All the other views use tabs but the
> class/instance switch uses RadioButtons.
>
> Wouldn't it be more consistent to use tabs for that as well, or is there
> some other reason?

FWIW, I like the tabs - if only because they are a bigger target, which
can be useful after several hours of debugging ;)

Have a good one,

Bill


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


Reply | Threaded
Open this post in threaded view
|

Re: Consistency

Sean Malloy-11
> FWIW, I like the tabs - if only because they are a bigger target, which
> can be useful after several hours of debugging ;)

Better drop targets too. When accidently writing a method in the class
rather than instance; dragging and droppping onto a tab is "easier" than the
smaller radio buttons.


Reply | Threaded
Open this post in threaded view
|

Re: Consistency

TimM-3
> Better drop targets too. When accidently writing a method in the class
> rather than instance; dragging and droppping onto a tab is "easier" than
> the smaller radio buttons.


Although you might have to think about how all those tabs are going to
look... tabs stacked on tabs (remember there is the code writer and mentor
that are tabs underneath that) gets very difficult to comprehend what means
what. With the radio buttons looking visualy different it breaks things up a
bit.

The point about the drop targets is a good one though. However i quite like
more keyboard operations anyway.

Tim


Reply | Threaded
Open this post in threaded view
|

Re: Consistency

Ian Bartholomew-20
Tim,

> Although you might have to think about how all those tabs are going to
> look... tabs stacked on tabs (remember there is the code writer and mentor
> that are tabs underneath that) gets very difficult to comprehend what means
> what. With the radio buttons looking visualy different it breaks things up a
> bit.

I was assuming they would be vertical, like the variables/etc list, then
you could still have the sortable list headers at the top.

Ian


Reply | Threaded
Open this post in threaded view
|

Re: Consistency

Andy Bower-3
In reply to this post by Ian Bartholomew-20
Ian,

> I was just wondering about the way the Class/System browsers select
> class/instance methods.  All the other views use tabs but the
> class/instance switch uses RadioButtons.
>
> Wouldn't it be more consistent to use tabs for that as well, or is
> there some other reason?

There were originally two reasons why we changed over to using the
radio buttons. One was a cosmetic issue where we wanted to have the
switch at the bottom of the methods pane (rather than the top) and the
original Windows tab control does not display correctly under XP when
it is upside down. This issue has now gone away with our implementation
of the TabViewXP widget.

The second reason was that using a tab didn't seem quite right. In
general I regards the tab cards as being different views onto the same
object. It's a bit of a fine line but I tend to regards the instance
and class side methods as being similar views onto two different class
objects.

Anyway, I quite like the radio buttons (and this is coming from someone
who is generally appalled by the use of radio buttons) and I don't
think we've now got time to change before the release them when there
is so much else to do.

Best Regards,

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


Reply | Threaded
Open this post in threaded view
|

Re: Consistency

Ian Bartholomew-20
Andy,

Thanks for the explanation

> Anyway, I quite like the radio buttons (and this is coming from someone
> who is generally appalled by the use of radio buttons)

I did a little experimenting with the VC and thought that a browser with
tabs looked quite good, the extra space around the list seemed to make
it fit in a bit better.

 >          and I don't
> think we've now got time to change before the release them when there
> is so much else to do.

Oh yes, that's fair enough. I didn't really expect you to change it for
that. :-)

Regards
        Ian


Reply | Threaded
Open this post in threaded view
|

Re: Consistency

Chris Uppal-3
In reply to this post by Andy Bower-3
Andy,

> There were originally two reasons why we changed over to using the
> radio buttons. One was a cosmetic issue where we wanted to have the
> switch at the bottom of the methods pane (rather than the top)

Incidentally, why at the bottom ?  I'm not asking you to change it (which I can
do myself anyway if I think it's worthwhile), but I'm having /real/ difficulty
reprogramming myself to look/click in the right place.


> The second reason was that using a tab didn't seem quite right. In
> general I regards the tab cards as being different views onto the same
> object. It's a bit of a fine line but I tend to regards the instance
> and class side methods as being similar views onto two different class
> objects.

A fine technical point.

FWIW, I prefered the tabs myself (in /programming/ terms I see the two class
objects as being conjoined twins).  But logically the tab (or whatever) should
then extend across (should be the "master" of) both the variables pane and the
method list.  Which would use quite a lot of screen space to gain not very
much...

    -- chris