[maemo-developers] Moving windows in Maemo

[From: Sean Luke]

On Apr 18, 2007, at 5:20 AM, Eero Tamminen wrote:

> ext Sean Luke wrote:
>>
>> What I gather here is that GTK widgets can't specify maximum size  
>> and,
>
> They can.

They can?  All I see is set_size_request(), which sets minimum  
sizes.  How do you set the maximum size?  (still no "preferred" size  
though.  :-( )


>> more importantly, they can't specify a "preferred" (as in Java) or
>> "natural" (as Mathias puts it) size.
>
> How this works in Java?

In Java every widget can tell you its minimum, maximum, and preferred  
size.  A container will do everything it can to keep its children  
from going smaller than their minimum size.  Likewise widgets can  
refuse to be made larger than a maximum size -- stretching beyond it  
will just add more padding.

Okay, good enough.  A widget's preferred size tells its container the  
size it'd like to be set to if at all possible.  Containers then will  
resize widgets such that everything gets its preferred size if  
possible, and the remainder is filled by widgets which have been  
positioned to stretch.  Thus in the dialog at http:// 
preview.tinyurl.com/ytzfsh  the top row is what GTK does and the  
bottom row is what Java typically does.

A container's own minimum, maximum, and preferred sizes are  
calculated on-the-fly from laying out its children accordingly.  And  
the outermost container (a window) can be set to its preferred size  
-- and thus set all of its subsidiary widgets to their preferred  
sizes -- through the pack() method.


>> Okay, fine.  But this isn't
>> because the problem is "hard".  It's because of a significant  
>> misfeature
>> in GTK.  If widgets were able to specify at least "natural" sizes,  
>> the
>> problem would essentially go away, would it not?
>
> How widgets could specify a "preferred" size?  Their contents could
> be anything.

Not true.  What you're mistaking here is thinking that YOU tell  
widgets what their preferred is.  While you can often do this, in  
fact Java widgets typically compute their preferred sizes on the fly  
and provide them to YOU (or actually to their container) when asked.  
Java widgets specify minimum/maximum/preferred sizes through methods  
you can call:

widget.getPreferredSize()
widget.getMaximumSize()
widget.getMinimumSize()

For Java's equivalent of a one-line GTK.label, or GTK.entry, or  
GTK.button with one-line text:

getMaximumSize() returns the largest size the widget will allow (for  
these, it's infinity in the X direction, and TEXT_HEIGHT in the Y  
direction)

getMinimumSize() returns the minimum size possible ( [0,TEXT_HEIGHT]  
say, or maybe the size necessary to display "..." ).

getPreferredSize() returns the minimum size necessary to display  
_all_ of its text:  [text's string width, TEXT_HEIGHT]

Now what happens if it's a multi-line label with word-wrap?  What  
you'd want are two additional functions, something like:

getPreferredWidthForThisHeight(height)
getPreferredHeightForThisWidth(width)

...which tell the container: "if you resize me to 100 pixels wide,  
then here's the height I'd need to display all my text".  Java  
doesn't have that, a weakness -- but that's okay for Java because it  
has no widgets with wrappable text which don't prefer to fill the  
whole space.  Java's labels and buttons are one-line or multi-line  
but with hard-returns.  Still, a far sight better than GTK's situation.


>> But to get back on track: this is essentially orthogonal to the  
>> issue of
>> giving developers the *option* of moving and resizing dialogs.
>
> Developers already have that.  They can (from code) set dialog to
> any size and position at any time they want to.

Is there a standard API for developers turn on a switch in their  
application (not a global switch for all apps) that says "let the  
user resize this particular dialog from a resize box" or "let the  
user drag dialogs by their title bars", short of making a global  
modification to the window manager?  That's what spawned this thread.

>> So: why are we restricted to
>> being unable to make dialogs which can be dragged and resized?  Why
>> can't the developer be given the option to handle these corner cases
>> himself?
>
> You're asking for an option to set that dialog should be resizable
> and movable?  (that's different from what you asked earlier)

Hmmm, I'm pretty sure that's what I asked.  But let me be more  
specific to summarize my requests in the discussion so far.

First, I'd like the option, as a developer, to:

- set a specific dialog as movable
- set a specific dialog as resizable
- set a specific dialog as non-modal
- set a specific dialog as closeable or minaturizable

Second, I believe that Nokia should set many of its dialog boxes as  
resizable, and *all* of its dialog boxes as movable.

Third, I believe Nokia should place notifications somewhere where  
they don't cover widgets (the right half of the menu bar is the  
obvious place), and at the very least, make notifications dismissable  
by clicking on them.  No notifications should be permitted to be on- 
screen more than a very short time (the present 3 second length is  
irritatingly way too long -- perhaps this could be a control panel  
setting?).  And violating notifications, such as email's "deleting  
message" notification, which keep the notification up for minutes at  
a time, should be eliminated.

Fourth, it'd be nice if Nokia significantly reduced the height of the  
Dialog's title bar given the small size of the screen.

Sean