On Thu, 2007-02-15 at 16:35 -0500, Tristan Van Berkom wrote: > Yes we planned on that feature, but it had to be reimplemented - we knew > this from the start - thats why I'm saying temporary, it was temporarily > included at the time "as is" - but "as is" was altogether unacceptable > because it changes properties without notifying the user (not to > mention that the actual window resizing was driven by the properties > themselves - however that is fixed now). >
There was nothing wrong with the resizing being driven by glade_widget_set_property(), it killed two birds with one stone. The call allowed me to update the property editor and set the default size at the same time. Just because the implementation looked overly simple does not mean the implementation was necessarily wrong ;) > Consider that if the user wants to save a toplevel without specifying > a default-width/height (i.e. "the normal use case") - the user has to be > especially carefull to never resize the window in the workspace - or to > always remember to disable those properties before saving - sorry but > thats not an option. > OK, well that's a good point, and Murray seems to concur. Looks like I will concur as well. > If the user went and explicitly checked the box enableing the > width/height-request properties - we must assume the user knows > what they are doing - also consider that ultimately toplevels in > the workspace are not nescisarily GtkWindows (thats just a current > shortcomming) > I still think it does not make sense for the user to set the width/height request by resizing the window/widget. The resizing feature is good, it allows you to test packing options, and to adjust the default size. But making it do more, especially with the modal algorithm you described, just makes things more complex from code and usability perspectives. cheers, Vincent _______________________________________________ Glade-devel maillist - [email protected] http://lists.ximian.com/mailman/listinfo/glade-devel
