Hi Tristan, On Thu, 2007-02-15 at 10:32 -0500, Tristan Van Berkom wrote: > The workspace widgets used to set the default-width/default-height of > toplevel GtkWindows automatically, this functionality was temporarily > introduced for the initial demos of the embedded workspace, there > were/are plans for making properties change upon workspace resizes - > but its most important that we dont screw with > default-width/default-height without telling the user. >
My implementation of the resizing was never meant to be temporary, at least for me. In fact it was working well and was quite robust. It still needed a little work, I admit that, but the behaviour and functionality was essentially complete. A week or two ago, I didn't discuss your changes to the implementation, because I was unsure of what your goals were and I wanted to see what the end results would be like. Now, Resizing a GtkWindow in the workspace is one of the *ways* to change the it's default size. If a user resizes the GtkWindow in the workspace, then he most probably wants to change the default size. Look at it this way; When the user resizes a GtkWindow by direct manipulation, she is telling glade to change the default size. So we should adhere to the principle of least surprise [1] and provide what most users expect. I really don't see any problems with my implementation. This sort of behaviour is quite standard among most GUI designer applications, including Netbeans and Visual Studio (and regardless of the underlying toolkit API's). > The behaviour I was looking for was: > - If the user checked/enabled the default-width/height, then > effect the default-width/height > - Else if the user checked/enabled the width/height-request, then > effect the width/height-request > - Else do nothing > I am uncomfortable with this for many reasons. Firstly, why would users ever want to set the width/height request on GtkWindow's anyway? This is bad usage, and the GTK+ docs clearly state as much [2]. If the user is misinformed or has some specialised needs, then she is quite free to change the width/height request in the property editor. Secondly, it is modal behaviour (i.e if X then "user must do Y" else "user must do Z"). This makes it hard for the user to carry out tasks, as the process of performing modal tasks is generally more confusing and complicated for the user (rather like the modal behaviour of Vi). Thirdly, this behaviour implies that users must understand what these mysterious GTK+ API properties actually mean, and why setting a default size is recommended over setting a size request. Do users (and hardcore hackers) really need to know all that, simply so that they are able to change the "Size" of a GtkWindow. As a GUI designer, Glade is essentially an abstraction over the GTK+ widget API. So we really need to improve this abstraction, and make user interface design easier and more efficient for everyone, including non-developers (and a lot of usability/design/art folks are non-developers). Lastly, according to the algorithm above, the resizing functionality is effectively disabled by default. This is not helpful and is a waste of really useful feature. The whole original rationale of the resizing functionality was to enable the user to easily change sizes (using direct manipulation) without having to go and edit obtuse little properties hidden somewhere in the property editor. 'nuff said ;) regards Vincent 1. http://en.wikipedia.org/wiki/Principle_of_least_astonishment 2. http://developer.gnome.org/doc/API/2.0/gtk/GtkWidget.html #gtk-widget-set-size-request _______________________________________________ Glade-devel maillist - [email protected] http://lists.ximian.com/mailman/listinfo/glade-devel
