Re: GtkText invisible



Carlos Pereira <carlos pehoe civil ist utl pt> writes:  
What I am saying is that this should not be the DEFAULT behaviour,
for the sake of consistency: if all the other widgets keep
their contents visible why should GtkText behave differently?

Perhaps user testing reveals that users try to select or interact with
text if it's kept visible, but don't try to use insensitive buttons or
images.

So, I think the logical way of doing this would be:

gtk_function_to_clean_text (GtkText);
gtk_widget_set_sensitive (GtkText, FALSE);

This doesn't really solve the problem; a) people will not consistently
do it b) what if you disable an entire window or notebook page, and
the set_sensitive on the text widget is only implicit. GTK should
default to what's normally considered correct.
 
and cleaning automatically the text. The overall result is
EXACTLY the same, but this way all widgets show the same behaviour
and the programmer is free to decide which option makes more sense
in each case.

So what is an example case where an application-specific change should
be made?
 
I certainly agree that apps should look consistent, I even agree
that in NORMAL conditions programmers should be encouraged to clean 
the text before making GtkText insensitive...

The normal thing should be the default. If you agree, then instead of
gtk_function_to_clean_text(), we should have
gtk_text_set_do_not_clean().

the point is, can you guarantee that there would never be a situation
where the text should be kept visible? There are always exceptions,
and GtkText can be used for many different situations... even inside
the same app...


There are always exceptions and weird cases to everything, but we only
try to handle the cases we can think of and consider reasonable - GTK
would be a disaster otherwise. So before adding a setting for this to
GtkText I'd want to hear at least one probably/reasonable use-case
where the app has a good reason to be inconsistent.

Even if there are exceptions, though, the default should be the normal
case, not the exceptional one.

Havoc




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]