Fabián Flores Vadell ha scritto: > 2010/9/2 Doriano Blengino <doriano.bleng...@fastwebnet.it>: > >> I agree - consistency; but the center question is the AutoResize >> property. If it is true by default, then the widget should show as soon >> as its text property is set to something "visible". If it is false, then >> the widget should not resize and, doing so, it should keep its default >> size. If its default size is zero, then the widget is invisible. The >> Autoresize seems to default to false, so gtk seems more logical. >> > > I think that have no sense that a graphic object is initialized to > (0,0,0,0), because make not sense that it become invisible in its > initial state. There's no logic in that. The purpose of a control is > showing something, so its initial state shouldn't be one that it > become invisible. > 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. 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.
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? Only after you set the text property, a label comes in its true existence. Then, if Autoresize is already true, the label should resize itself. If Autoresize is false, nothing should happen. If you set Autoresize to true after having set the text property, may be that the label should resize, may be not (I would say yes, but it is debatable). May be that this does not work well in gambas (I made some test, and found something strange, but I don't remember well). > 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. Anyway, if Autoresize was true by default, you can set it to false just after creation. > >> Anyway, I believe that interactive editing of a form, and creatiaon of >> controls by code, are two different situations, with different >> requirements. >> > > 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. 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 :-) > >> Consistency is desirable, if it does not clash with >> something else more important. >> > > 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. 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. > Consistency matters because allow predict behaviors, but never can go > against the logical behavior of a object. So in this case consistency > and logical behavior of the control Label match, if the default value > to AutoResize is TRUE. > > > Regards. > Regards, Doriano ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user