Immutable text area idiom?

Posted: 2003-12-17 1:00:00

java-programmer, Immutable text area idiom? Andrew Thompson wrote:
> (sighs) You can lead a horse to water.. ;-)

(I lied.)

Look, I understand your points, and they are good ones. Boiled down,
they are essentially "Don't try to outsmart the look and feel; it knows
what it's doing." With this I agree entirely.

This is not a look and feel issue, however. I don't have a problem with
the way that a given component is being rendered in a particular look
and feel. I don't have a problem with look and feel implementations
period. I have a problem with exactly what components I should use to
represent particular information.

I have never seen a property sheet that displays information about a
live object somewhere that uses /disabled/ components to show "enabled"
information. Non-editable components? Sure. But that's different. If
a component is disabled, that means you aren't really supposed to look
at it, or it is not applicable in some other way. Those are NOT the
semantics I wish my UI in this case to convey. I wish simply to convey
that X is the current value for property Y, and nothing else.

Again, I thank you for your obviously hard work on this subject.

Cheers,
Laird

Posted: 2003-12-17 1:00:00

java-programmer >> Immutable text area idiom? Andrew Thompson wrote:
> (sighs) You can lead a horse to water.. ;-)

(I lied.)

Look, I understand your points, and they are good ones. Boiled down,
they are essentially "Don't try to outsmart the look and feel; it knows
what it's doing." With this I agree entirely.

This is not a look and feel issue, however. I don't have a problem with
the way that a given component is being rendered in a particular look
and feel. I don't have a problem with look and feel implementations
period. I have a problem with exactly what components I should use to
represent particular information.

I have never seen a property sheet that displays information about a
live object somewhere that uses /disabled/ components to show "enabled"
information. Non-editable components? Sure. But that's different. If
a component is disabled, that means you aren't really supposed to look
at it, or it is not applicable in some other way. Those are NOT the
semantics I wish my UI in this case to convey. I wish simply to convey
that X is the current value for property Y, and nothing else.

Again, I thank you for your obviously hard work on this subject.

Cheers,
Laird

Posted: 2003-12-17 1:18:00

java-programmer >> Immutable text area idiom? "Laird Nelson" <email***@***.com> wrote in message
news:email***@***.com...
> Andrew Thompson wrote:
> > (sighs) You can lead a horse to water.. ;-)
....
> Again, I thank you for your obviously hard work on this subject.

You're welcome.

..And I got a cute little app launcher out of it
anyway, so whichever way I cut it, it was a
profitable experience.. :-)

Posted: 2003-12-17 7:09:00

java-programmer >> Immutable text area idiom? Andrew Thompson wrote:

> "Sam Brightman" <email***@***.com> wrote in message
> news:brl4lp$ppf$email***@***.com...
>
>> Andrew Thompson wrote:
>>
>>
>>> To the wider question, I would say it is a conceptual problem,
>>> yours. You are wanting to create non-editable fields that are
>>> somehow different to the way the user would expect to see
>>> non-editable fields.
>>
>> I'm not sure I agree with you here Andrew. It might be that you (or
>> I) have misunderstood the OP. I'm not an OOP expert by any means
>> but surely the following would be okay and meet the requirement?
>
>
> Code speaks a thousnad words eh, Sam? ;-)
>
> Well, I'm not convinced - try my variant..
> http://www.physci.org/codes/display.jsp?fl=%2Ftest%2FEditableComponents%2FPr
> efThings.java

What were you not convinced about... the code (if so, what? :) or
Laird's feelings on GUI design? I'm thinking from the rest of this
thread that you're still not convinced about what it conveys to the
user. In that case, we'll have to differ.

Generally I would think first of showing them disabled but wouldn't
object to a UI that made labels instead, provided the circumstances were
appropriate. In the wrong circumstances, the user could be led to
believe that a particular property *could not* be edited and
subsequently "put up" with the problem when they did want to edit it.
Perhaps this property was in fact editable when they wanted it to be but
they assumed it wasn't. Obviously, this is undesirable.

--
sam brightman

(To reply by e-mail use spam instead of ham and lose the jam)

Posted: 2003-12-17 11:05:00

java-programmer >> Immutable text area idiom? "Sam Brightman" <email***@***.com> wrote in message
news:bro3a7$8hq$email***@***.com...
> Andrew Thompson wrote:
>
> > "Sam Brightman" <email***@***.com> wrote in message
> > news:brl4lp$ppf$email***@***.com...
> >
> >> Andrew Thompson wrote:
...
> >>> ...You are wanting to create non-editable fields that are
> >>> somehow different to the way the user would expect to see
> >>> non-editable fields.
> >>
> >> I'm not sure I agree with you here Andrew.
...
> What were you not convinced about... the code (if so, what? :) or
> Laird's feelings on GUI design?

Hi Sam! Yes, it is more the concept itself I don't get.

..I look back throught this thread to realise that
nobody within it has changed their position
or opinion one iota.

Gee, ..I wonder if that has ever happened
before in the course of human history? ;-)

Posted: 2003-12-18 3:55:00

java-programmer >> Immutable text area idiom? Sam Brightman wrote:
> Generally I would think first of showing them disabled but wouldn't
> object to a UI that made labels instead, provided the circumstances were
> appropriate. In the wrong circumstances, the user could be led to
> believe that a particular property *could not* be edited and
> subsequently "put up" with the problem when they did want to edit it.
> Perhaps this property was in fact editable when they wanted it to be but
> they assumed it wasn't. Obviously, this is undesirable.

Right. I think there may be confusion about what I'm trying to do. I'm
most certainly /not/ trying to build one component that can switch at
will between read-only states and editable states. That is, for the
life of the component instance, it will /either/ be an editor (with,
say, combo boxes displaying choices) /or/ a...a...reader (with, say,
labels displaying the current value). Just as, for example, the file
properties dialog box that comes up on Windows when you right click a
file icon doesn't show you a disabled text box to display the file's
location, even though conceivably you could edit that somewhere else or
in another component.

So I'm trying to decide whether it is better to build /two/ component
classes--one whose sole job in life is to display information (in which
case I think you would agree that it should use labels), and one whose
sole job in life is to edit information.

If I /were/ to write only /one/ class to handle these /two/ cases,
/then/ I was wondering if there were some way to accomplish it without
having to switch the types of widgets involved. Since a truly
/disabled/ component of any type is by its very nature not intended to
be interacted with by the user, it seemed funny to me to recommend that
as a solution for displaying information.

Cheers,
Laird

Posted: 2003-12-19 22:13:00

java-programmer >> Immutable text area idiom? Andrew Thompson wrote:

> "Sam Brightman" <email***@***.com> wrote in message
> news:bro3a7$8hq$email***@***.com...
>
>>Andrew Thompson wrote:
>>
>>
>>>"Sam Brightman" <email***@***.com> wrote in message
>>>news:brl4lp$ppf$email***@***.com...
>>>
>>>
>>>>Andrew Thompson wrote:
>
> ....
>
>>>>>...You are wanting to create non-editable fields that are
>>>>>somehow different to the way the user would expect to see
>>>>>non-editable fields.
>>>>
>>>>I'm not sure I agree with you here Andrew.
>
> ....
>
>>What were you not convinced about... the code (if so, what? :) or
>>Laird's feelings on GUI design?
>
>
> Hi Sam! Yes, it is more the concept itself I don't get.
>
> ...I look back throught this thread to realise that
> nobody within it has changed their position
> or opinion one iota.
>
> Gee, ..I wonder if that has ever happened
> before in the course of human history? ;-)
>
>

Yeah, it is possible that it has happened before...

I'm trying to concede that it might not be the best idea in some
circumstances but with the proviso that there's no reason to think that
you'd *never* want to do it. However, Laird seems to be indicating that
I've misunderstood anyway... oh well.

--
sam brightman

(To reply by e-mail use spam instead of ham and lose the jam)

Posted: 2003-12-19 22:22:00

java-programmer >> Immutable text area idiom? Laird Nelson wrote:

> Right. I think there may be confusion about what I'm trying to do. I'm
> most certainly /not/ trying to build one component that can switch at
> will between read-only states and editable states. That is, for the
> life of the component instance, it will /either/ be an editor (with,
> say, combo boxes displaying choices) /or/ a...a...reader (with, say,
> labels displaying the current value). Just as, for example, the file
> properties dialog box that comes up on Windows when you right click a
> file icon doesn't show you a disabled text box to display the file's
> location, even though conceivably you could edit that somewhere else or
> in another component.

I didn't think you wanted it to switch states "on the fly". I thought
the file properties example was a good one, provided one thing was true.
I got the impression that there may be certain external conditions that
would merit the properties page coming up with, say, "Location" being
editable. I thought this would be okay in some contexts but not in other
ones; the problem being that the user may "learn" that "Location" can't
be changed and then assume they couldn't do what they wanted in future.

> So I'm trying to decide whether it is better to build /two/ component
> classes--one whose sole job in life is to display information (in which
> case I think you would agree that it should use labels), and one whose
> sole job in life is to edit information.

If the above is not true then I don't get why you don't just use a
JLabel as a label and a JTextField as a text field :)

> If I /were/ to write only /one/ class to handle these /two/ cases,
> /then/ I was wondering if there were some way to accomplish it without
> having to switch the types of widgets involved. Since a truly
> /disabled/ component of any type is by its very nature not intended to
> be interacted with by the user, it seemed funny to me to recommend that
> as a solution for displaying information.

If I'm still not getting the right idea and you want to do this then
maybe something like overriding methods in JTextField to change the way
the uneditable state is drawn or, possibly better, write your own class
to do *exactly* what you want.

--
sam brightman

(To reply by e-mail use spam instead of ham and lose the jam)

Posted: 2003-12-20 1:18:00

java-programmer >> Immutable text area idiom? Sam Brightman wrote:
> If I'm still not getting the right idea and you want to do this then
> maybe something like overriding methods in JTextField to change the way
> the uneditable state is drawn or, possibly better, write your own class
> to do *exactly* what you want.

Thanks. When I'm done with this, I'll be happy to post what I've done.
Hopefully it will speak for itself. :-)

Cheers,
Laird

Posted: 2003-12-20 12:19:00

java-programmer >> Immutable text area idiom? "Laird Nelson" <email***@***.com> wrote in message
news:email***@***.com...
> Sam Brightman wrote:
...
> > ..possibly better, write your own class
> > to do *exactly* what you want.
>
> Thanks. When I'm done with this, I'll be happy to post what I've done.

Great Laird, I might add a short example to the
same page where I have been doing my UI -
for the sake of comparison. It is so much easier
when noobs can _see_ the effects of UI's..