[Gambas-user] Inconsistent initialization in controls: seems a little bug

[Fabián Flores Vadell]

2010/9/3 Doriano Blengino <doriano.blengino at ...1909...>:
> Perhaps you don't see the whole thing, which goes much deeper than the
> surface.
> Creating a label in Gambas+GTK means creating a gambas object which
> refers to a GTK object which refers to a GDK object which refers to a
> Xwindow object.
> Starting from XWindow and going up, an object is created
> "empty" (all dimensions set to zero, empty text, and so on), because it
> is logical not to set any dimension, at any level, because that
> dimension will be wrong - and "to zero" all the fields is the fastest
> thing to do.

I'm conscious about what happens behind the scene. Also, I agree with
you that at X level is better not make assumptions. But like Gambas
programmer, this doesn't matter to me.

> Setting any visual property of such object makes, by
> cascading over and over, a lot of things: don't forget repacking all
> containers in the hierarchy, marking dirty all those objects and repaint
> them.

You are missing the point by changing the premise. That hipotetical
situation of cascading settings between XWindows and GTK is not
related with the topic.

Anyway, if you are worried about how many graphics operations that are
triggered by setting a control like Label think how many times this
happens while a program is running. Hundreds? Thousands? Most of these
things are do it as response to the user actions -move a window,
resize it, minimize it, restore it, writing text, selecting text, etc
- , and it's impredictable how many times they could ocurrs (but is
sure that many many times). So, not worth taking into account.

I think that Gambas programmers shouldn't be worried about that.

> When in code you create a label, what should be its initial width? 100?
> 1000? A third of the screen width? Ten characters wide (using which
> font?)? It is true, a label is supposed to show something: but what?

You forgot the start point, that is this:

  PUBLIC SUB _new()
  DIM lbl1 AS NEW Label(ME)

  lbl1.Text = "Hi people"

  END

Are nothing to think if there's no text.

> Only after you set the text property, a label comes in its true
> existence.

That's incorrect. If I do this:

  PUBLIC SUB _new()
  DIM lbl1 AS NEW Label(ME)

  PRINT lbl1

  lbl1.Text = "Hi people"

  END

I get this:

(Label 0x9647e58)

So, the object have identity just after its instantiation, like is
logical. But I you are using an figurative mode of expression (if you
meant not real existence, but meaningful existence) so I agree, that
is the start point.

> Then, if Autoresize is already true, the label should resize
> itself. If Autoresize is false, nothing should happen.

That is part on that we are discussing.

>> I think about this goal can be achieved by making TRUE the default
>> value of AutoResize property in the control Label, that make sense
>> especially in this case because Labels always should show the value of
>> its Text property (show a half string o just a part make no sense.
>> Right?). So, default AutoResize = False go against the purpose of the
>> Label control.
>>
> This could be a good idea, or not. I see that Richard does not agree,
> and probably I think the same. Sometimes it is handy, sometimes not.

No arguments here.

> Anyway, if Autoresize was true by default, you can set it to false just
> after creation.

Why? You should argue that to labels set AutoResize=False as default,
is more useful than the contrary, and I see many difficults to find
solid arguments for that (I already argued about that, and I not want
repeat my self over and over again).

>> Yes, they are two differents situations. But, what those diferent requirements?
>>
> The difference is that when a widget is created by code, the runtime
> should make as little assumptions as possible, because the user program
> will set the properties just after the creation.

> When creating widgets in interactive mode, a few reasonable assuptions
> must be made, because otherwise the user would have difficulty to
> interact with the just created object. And those "reasonable"
> assumptions often are not enough.

Yes, but anyway there's more similarities than differences. I not
found reason to eliminate some of that similarities.

> For example, all the widgets get a
> totally stupid name: Button1, Button2, TextBox25...
> when I see a program
> filled with "PUBLIC SUB Button8_Click()" my first thought is "this is a
> stupid programmer". Then I realize that I do the same, because I am too
> lazy to change those stupid names :-)

I agree, but you're losing the focus.

>> I agree. But I don't see clash between consistency and anything else
>> in this case.
>>
> I see clashes, instead. Would you say, for example, that when creating a
> label by code, its text should be set to "Label 1" automatically? This
> would be consistent, because in interactive mode a label does so.

No, obviously I don't say that. You should remember the start point.

> Anyway, the clash is with efficiency of the program. When creating
> widgets by code, a runtime should make as little assumptions as
> possible. Perhaps, in this view, it is good that Autoresize defaults to
> false - more efficient. If you want it, you set it to true.

I think that a Gambas programmer not should be worried about
efficiency when the gain is merely marginal. Is much better to address
it when the potential gain worthwhile.

Not decrease the abstraction level of the language is several orders
of magnitude more important. At this point a Gambas programmer should
be concerned to follow GUI design principles, and to compliance the
requirements.

Compare this:

'gb.gtk
  PUBLIC SUB _new()

  DIM lbl1 AS NEW Label(ME)

  lbl1.Text = "Hi people"
  lbl1.Text = "Hi people"
  lbl1.W = lbl1.Font.Width(lbl1.Text)
  lbl1.H = lbl1.Font.Height(lbl1.Text)
  lbl1.X = 0
  lbl1.Y = 0

  END

with this:

  PUBLIC SUB _new()
  DIM lbl1 AS NEW Label(ME)

  lbl1.Text = "Hi people"

  END

By the way, in gb.gtk you can do this:

  lbl1.Text = "Hi people"
  lbl1.W = lbl1.Font.Width(lbl1.Text)
  lbl1.H = lbl1.Font.Height(lbl1.Text)
  lbl1.Show

Oh my gosh! The X and Y properties were never set. ;-)

Now seriously, and to finish with this topic, you shouldn't forget
than in the most cases, labels will be placed in containers (like
hbox) with other controls. So, in a high level of abstraction, its
place is defined by the creation order, its width by the text and its
height by the default font.

As you can see, is possible make many assumptions in a inteligent
manner. If some not use containers for the layout, so the problem


-- 
Fabián Flores Vadell
www.speedbooksargentina.blogspot.com