[Glade-devel] Window width and height request

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 ;)



1. http://en.wikipedia.org/wiki/Principle_of_least_astonishment
2. http://developer.gnome.org/doc/API/2.0/gtk/GtkWidget.html

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