Re: Moving windows in Maemo
2007/4/18, Eero Tamminen <[EMAIL PROTECTED]>: Hi, ext Sean Luke wrote: > No, that's a *global* change, and a major, brickable, modification which > is not acceptable for me to make on a person's computer for them just to > use my application. I should be able to enable a *specific* window to > be resizable/movable. Sorry, those are the only options you have currently available. (and based on Intel's recent powerpoints linked to this list they might be adopting Hildon too. :-)) Though nothing indicated they'd adopt the policy decision for matchbox... >>> Second, I believe that Nokia should set many of its dialog boxes as >>> resizable, and *all* of its dialog boxes as movable. >> >> I'm pretty sure this is not going to happen (dialogs in phones >> are not movable either + their UI is also very modal). > > Does Nokia really perceive the N800 UI in phone terms? I don't know. I don't. :-) > If so, Apple is going to eat your lunch. That would be oh, so naughty... I thought it was already True(tm) that Apple will nail it with iPhone and everything else would be crap after that? ;) -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
Hi, ext Sean Luke wrote: >>> - set a specific dialog as closeable or minaturizable >> >> This might be something that you could control from Matchbox theme >> file, see its documentation at: >> http://matchbox-project.org/ >> >> Then you could create a theme that does that and install it. > > No, that's a *global* change, and a major, brickable, modification which > is not acceptable for me to make on a person's computer for them just to > use my application. I should be able to enable a *specific* window to > be resizable/movable. Sorry, those are the only options you have currently available. (and based on Intel's recent powerpoints linked to this list they might be adopting Hildon too. :-)) >>> Second, I believe that Nokia should set many of its dialog boxes as >>> resizable, and *all* of its dialog boxes as movable. >> >> I'm pretty sure this is not going to happen (dialogs in phones >> are not movable either + their UI is also very modal). > > Does Nokia really perceive the N800 UI in phone terms? I don't know. I don't. :-) > If so, Apple is going to eat your lunch. That would be oh, so naughty... >>> 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), >> >> Many of the banners come from dimmed menu items, so then the banners >> would cover the item you just tapped (they are quite high), which would >> be even more annoying I think. > > You don't need to actually have a *window*. Just change part of the > text of the menu bar (and maybe its color) temporarily. Titlebar is owned by the window manager and AFAIK there's currently no way to do this (see the ewmh spec link). You could discuss this feature on the Matchbox mailing list (or freedesktop specs list). - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
On Apr 18, 2007, at 10:58 AM, Eero Tamminen wrote: - set a specific dialog as closeable or minaturizable This might be something that you could control from Matchbox theme file, see its documentation at: http://matchbox-project.org/ Then you could create a theme that does that and install it. No, that's a *global* change, and a major, brickable, modification which is not acceptable for me to make on a person's computer for them just to use my application. I should be able to enable a *specific* window to be resizable/movable. Second, I believe that Nokia should set many of its dialog boxes as resizable, and *all* of its dialog boxes as movable. I'm pretty sure this is not going to happen (dialogs in phones are not movable either + their UI is also very modal). Does Nokia really perceive the N800 UI in phone terms? If so, Apple is going to eat your lunch. 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), Many of the banners come from dimmed menu items, so then the banners would cover the item you just tapped (they are quite high), which would be even more annoying I think. You don't need to actually have a *window*. Just change part of the text of the menu bar (and maybe its color) temporarily. Sean ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
Hi, ext Sean Luke wrote: [...] Thanks for the information! It's better that some developer more familiar with Gtk answers these, I'm not completely sure on all of this (I've done very little with Gtk). >>> 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. No. >>> 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. There are now three different things being discussed: 1. Being able to set dialog size & position from code -> already possible 2. Original issue: all dialogs in the device being resizable and movable by the user -> Already possible, but only by setting the corresponding DIALOGMODE in /etc/osso-af-init/matchbox.defs (this is given as command line option to matchbox window manager) -> This UI policy is not going to be changed as it's against Maemo UI policy and need for that just indicates either bad application UI design or implementation (ie. bug) - If UI policy is not at Maemo site, IMHO it should... 3. Being able to set just specific dialog to be user movable & resizable -> Not possible 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 This can be already done. > - set a specific dialog as closeable or minaturizable This might be something that you could control from Matchbox theme file, see its documentation at: http://matchbox-project.org/ Then you could create a theme that does that and install it. > Second, I believe that Nokia should set many of its dialog boxes as > resizable, and *all* of its dialog boxes as movable. I'm pretty sure this is not going to happen (dialogs in phones are not movable either + their UI is also very modal). > 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), Many of the banners come from dimmed menu items, so then the banners would cover the item you just tapped (they are quite high), which would be even more annoying I think. > and at the very least, make notifications dismissable by > clicking on them. This has already a bug. > 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?). It's very little detail to be put in control panel, but file it to Bugzilla. Maybe it could be just a Gconf setting, then somebody else could provide the applet for setting that? (I'm not deciding on these, but you could get the hildon sources and provide a patch for this in bugzilla, that could help) IMHO above feature is more useful though. > 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. Bug? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
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 s
Re: Moving windows in Maemo
ext Murray Cumming wrote: > On Wed, 2007-04-18 at 12:20 +0300, Eero Tamminen wrote: > [snip] > >> You're asking for an option to set that dialog should be resizable >> and movable? (that's different from what you asked earlier) >> >> Btw. If you want to know more about the standard for application >> and window manager communication, see: >> http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html >> > > Isn't this just an issue of the MatchBox window manager. It generally > prefers to fullscreen windows and doesn't allow secondary windows to be > moved or resized by the user, at least on Maemo. Obviously a user can > move and resize windows on a regular GNOME desktop. > > That seems to be a fairly sane decision by the Maemo UI people in order > to simplify the UI. It might not be to everyone's liking. > Yes, this is what it is. It is possible to have movable and resizable dialogs with Matchbox, we just don't want them. // Tapani ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
On Wed, 2007-04-18 at 12:20 +0300, Eero Tamminen wrote: [snip] > You're asking for an option to set that dialog should be resizable > and movable? (that's different from what you asked earlier) > > Btw. If you want to know more about the standard for application > and window manager communication, see: > http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html Isn't this just an issue of the MatchBox window manager. It generally prefers to fullscreen windows and doesn't allow secondary windows to be moved or resized by the user, at least on Maemo. Obviously a user can move and resize windows on a regular GNOME desktop. That seems to be a fairly sane decision by the Maemo UI people in order to simplify the UI. It might not be to everyone's liking. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
Hi, ext Sean Luke wrote: >> The problem is not widgets telling what is their maximum size >> (doesn't fit to available space) or minimum size (doesn't show enough >> useful information to the user), but somehow things deciding >> what is the the optimum size for them. Programmer just hard-coding >> the widget width in pixels is not really a solution. >> >> It's not an easy problem to solve. > > So trying to understand what you're going after, I finally made my way > here, following some transitivity in Murray's pointer: > > http://live.gnome.org/MathiasHasselmann/NewLayoutManager > > What I gather here is that GTK widgets can't specify maximum size and, They can. > more importantly, they can't specify a "preferred" (as in Java) or > "natural" (as Mathias puts it) size. How this works in Java? > 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. The above link is about how widget *containers* can better deduct what would be best size between the minimum and maximum as: - minimum is too small for strings that are set as ellipsizable (...) - maximum can go out of screen > 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. > Indeed > the problem will show up in fixed-size dialogs as well: just have the > user change the default system font size. Yes, things will break because Gtk cannot yet handle well enough content which is resizable, it will (usually) show such content as too small, unless a fixed size is used... So, some of the dialogs in the device might have fixed sizes (which is a bad thing). In ideal situation the Gtk containers could size things so that user doesn't feel the need for resizing. > 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) Btw. If you want to know more about the standard for application and window manager communication, see: http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
On Apr 16, 2007, at 12:06 PM, Eero Tamminen wrote: The problem is not widgets telling what is their maximum size (doesn't fit to available space) or minimum size (doesn't show enough useful information to the user), but somehow things deciding what is the the optimum size for them. Programmer just hard-coding the widget width in pixels is not really a solution. It's not an easy problem to solve. So trying to understand what you're going after, I finally made my way here, following some transitivity in Murray's pointer: http://live.gnome.org/MathiasHasselmann/NewLayoutManager What I gather here is that GTK widgets can't specify maximum size and, more importantly, they can't specify a "preferred" (as in Java) or "natural" (as Mathias puts it) size. 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? But to get back on track: this is essentially orthogonal to the issue of giving developers the *option* of moving and resizing dialogs. Indeed the problem will show up in fixed-size dialogs as well: just have the user change the default system font size. 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? Sean ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
On Mon, 2007-04-16 at 19:06 +0300, Eero Tamminen wrote: [snip] > The problem is not widgets telling what is their maximum size > (doesn't fit to available space) or minimum size (doesn't show enough > useful information to the user), but somehow things deciding > what is the the optimum size for them. Programmer just hard-coding > the widget width in pixels is not really a solution. > > It's not an easy problem to solve. By the way, the difficulty with getting an _optimum_ size for large GtkLabels is known. And there is a 2007 Google summer of code project about it: http://code.google.com/soc/gnome/appinfo.html?csaid=5F12F4E8AE21EC05 (There are bugzilla links there) VMWare have a "WrapLabel" workaround for this in their libview library, though you might need to port the logic from C++ to C: http://view.sourceforge.net/ -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
Hi,
ext Sean Luke wrote:
>> This is just that string. Before you know what space the string
>> can or should take you need to check the sizes for all the widgets
>> contents, take into account the expand etc. attributes in the co.
>> widget hierarchy etc.
>
> I'm missing the problem here. Isn't this being done in the typical
> top-down fashion?
>
> 1. Set in stone the widget dimensions.
> 2. Compute and cut string lengths line by line
> 3. If the total height will be more than the widget, include a scroll
> bar if appropriate
> 3.5 If including a scroll bar, recompute and cut string lengths line by
> line
> 4. Paint
>
> This is at most an O(n) operation, at least it is on previous GUIs I've
> used. Is there a misfeature in GNOME which is messing things up here?
> Is GNOME allowing string painting calculations to change the widget
> size?
The reason why ellipsizing is used is that the text doesn't
(potentially) fit to the available space, e.g. when it's localized.
However, the minimum size requested by ellipsizable text or some other
items which can have a non-fixed size is usually very small. In the
case of ellipsizable text it is "...".
Now. How does the container decide whether it should use the full
length for the string (which as a filename, URL etc can be hundreds
of chars long), or minimum size which for ellipsizable string probably
isn't what user wanted to see ("..." doesn't contain any useful
information) or something in between? Especially if how much space
is available is calculated based on it's contents of which some
are these items which sizes are somewhat flexible regarding their
content?
> If so, this is very bad behavior indeed, particularly for a small
> device. BTW, you can avoid 3.5 if you always include a scroll bar,
> blank or not. That's what's standard on the Mac.
On small screen you might not have space for that. Also, you would want
to avoid having items with scrollbars inside areas with scrollbars.
(another problem which one encounters more easily on smaller screens)
>> The device has a small screen, long strings might not fit into it.
>> What Mac OSX does e.g. when showing filenames or URLs that are, say 500
>> characters long?
>
> It truncates them.
>
> Here's a picture of various MacOS X text modes. Note that in all cases,
> there are no ellipses.
These are not text labels, they are text edit widgets.
Think of for example a Browser menu listing *only* the pages you've
visited. When page doesn't have a title, its URL is shown instead.
URLs can be very long (as admittedly can be some HTML page titles too).
However, (as code) you don't know which of the items are "too long".
All menu items are set as ellipsizable because any of them can be too
long, so the minumum menu width is "...".
The problem is not widgets telling what is their maximum size
(doesn't fit to available space) or minimum size (doesn't show enough
useful information to the user), but somehow things deciding
what is the the optimum size for them. Programmer just hard-coding
the widget width in pixels is not really a solution.
It's not an easy problem to solve.
- Eero
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
2007/4/16, Sean Luke <[EMAIL PROTECTED]>: On Apr 16, 2007, at 8:26 AM, Eero Tamminen wrote: > This is just that string. Before you know what space the string > can or should take you need to check the sizes for all the widgets > contents, take into account the expand etc. attributes in the co. > widget hierarchy etc. I'm missing the problem here. Isn't this being done in the typical top-down fashion? 1. Set in stone the widget dimensions 2. Compute and cut string lengths line by line 3. If the total height will be more than the widget, include a scroll bar if appropriate 3.5 If including a scroll bar, recompute and cut string lengths line by line 4. Paint This is at most an O(n) operation, at least it is on previous GUIs I've used. Is there a misfeature in GNOME which is messing things up here? Is GNOME allowing string painting calculations to change the widget size? You might want to read http://developer.gnome.org/doc/API/2.0/gtk/GtkContainer.html#id3616277 before continuing this discussion, since obviously GTK+ is using somewhat different principles in widget sizes than whatever you are used to. > The device has a small screen, long strings might not fit into it. > What Mac OSX does e.g. when showing filenames or URLs that are, say > 500 > characters long? It truncates them. Here's a picture of various MacOS X text modes. Note that in all cases, there are no ellipses. http://cs.gmu.edu/~sean/temp/wordwrap.png There's similar text widget in GTK+ too: http://www.ibm.com/developerworks/cn/linux/guitoolkit/gnome/gnome2/part1/textview.gif That hardly relates to labels (or other kinds of visible data) though. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
On Apr 16, 2007, at 8:26 AM, Eero Tamminen wrote: This is just that string. Before you know what space the string can or should take you need to check the sizes for all the widgets contents, take into account the expand etc. attributes in the co. widget hierarchy etc. I'm missing the problem here. Isn't this being done in the typical top-down fashion? 1. Set in stone the widget dimensions. 2. Compute and cut string lengths line by line 3. If the total height will be more than the widget, include a scroll bar if appropriate 3.5 If including a scroll bar, recompute and cut string lengths line by line 4. Paint This is at most an O(n) operation, at least it is on previous GUIs I've used. Is there a misfeature in GNOME which is messing things up here? Is GNOME allowing string painting calculations to change the widget size? If so, this is very bad behavior indeed, particularly for a small device. BTW, you can avoid 3.5 if you always include a scroll bar, blank or not. That's what's standard on the Mac. The device has a small screen, long strings might not fit into it. What Mac OSX does e.g. when showing filenames or URLs that are, say 500 characters long? It truncates them. Here's a picture of various MacOS X text modes. Note that in all cases, there are no ellipses. http://cs.gmu.edu/~sean/temp/wordwrap.png Sean ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
2007/4/14, Sean Luke <[EMAIL PROTECTED]>: Can't say about Palms. Newtons did not ellipsize: but generally Newton windows were movable but did not have resize widgets (not that there was a prohibition against it). But more importantly, MacOS X does not ellipsize, so at least in English it's not seen as all that important. If it's highly costly, why not dump it? I don't get that "does not ellipsize" part. My wife's mac seems to have ellipsizing strings in both Finder and iTunes. Though I didn't find any label-like elements that would do that. Then again, most windows didn't seem even resizeable so I guess that's one way of tackling the problem... -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
Hi, ext Sean Luke wrote: >> I'm not talking about user resizes, but calculating the dialog sizes. > > Why is this an issue? It would seem to me that ellipsizing is O(1). > Size as you like, then if you can't fit everything, draw, then erase > back N characters, or a word, and stick in the "...". This is just that string. Before you know what space the string can or should take you need to check the sizes for all the widgets contents, take into account the expand etc. attributes in the co. widget hierarchy etc. >> Did palms or Newtons ellipsize too long strings or were they only >> available in English? :-) > > Can't say about Palms. Newtons did not ellipsize: but generally Newton > windows were movable but did not have resize widgets (not that there was > a prohibition against it). But more importantly, MacOS X does not > ellipsize, so at least in English it's not seen as all that important. > If it's highly costly, why not dump it? The device has a small screen, long strings might not fit into it. What Mac OSX does e.g. when showing filenames or URLs that are, say 500 characters long? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
On Apr 13, 2007, at 3:43 AM, Eero Tamminen wrote: #2 of course might have to be modal depending on the operation. But #1 NEVER has to be modal, I don't understand. Infoprints are never modal, they don't even take focus. No, you're right, they're never modal, at least from my current testing. But they do interfere with operations, covering widgets (like the scroll-up button and thumb) and material on-screen, and causing a significant cognitive wait period, hesitating until they go away because you can't dismiss them. If you'd like them hanging around that long they should be placed somewhere that has less effect: my top choice is the right 2/3 of the menu title bar. Note that some of the dialogs have static sizes because Gtk doesn't always handle automatic resizing well enough. This is only a problem with text ellipsizing though I think. Gtk has only concepts of minimum (for ellipsizable text="...") and full size of a widget, as getting something reasonable in between would need a lot of iterating (slowdown) for the widget sizes. Why do your windows need to have live resizing? I'm not talking about user resizes, but calculating the dialog sizes. Why is this an issue? It would seem to me that ellipsizing is O(1). Size as you like, then if you can't fit everything, draw, then erase back N characters, or a word, and stick in the "...". I get the feeling that GTK's got some more coding ickiness here. I've already found another example -- try putting two TextViews inside an HPaned, fill them with a lot of text, and then drag the HPaned. This should be smooth but it's freaks them out badly. This kind of behavior is unacceptably slow for a modern GUI: it looks like someone's hacked in a bad algorithm out at RedHat. Did palms or Newtons ellipsize too long strings or were they only available in English? :-) Can't say about Palms. Newtons did not ellipsize: but generally Newton windows were movable but did not have resize widgets (not that there was a prohibition against it). But more importantly, MacOS X does not ellipsize, so at least in English it's not seen as all that important. If it's highly costly, why not dump it? Sean ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
>> If infoprints could be dismissed by >> simply clicking on them, you wouldn't have any problems. > > I second this suggestion. No need for a close button, just make it go > away when I tap it. Good suggestion, I don't see any problems with that (app is not managing the infoprints, they can disappear whenever they want to, only progress banners are controlled by the application) Could you make a bug (enhancement request) about this to Maemo Bugzilla? https://maemo.org/bugzilla/show_bug.cgi?id=1212 -- It doesn't take a nukular scientist to pronounce foilage! --Marge Simpson http://www.gnu.org/philosophy/shouldbefree.html ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
Hi, ext Sean Luke wrote: >> By the time user was able to start moving notifications, >> they go away (within 3 secs I think). > > As I've already mentioned, I've found at least two counterexamples to > this in Nokia's own apps: the most famous being the email deletion > notification. > > If you're going to allow applications to treat notifications as > non-modal (which Nokia has), then they MUST be movable. > > While we're on the topic of notifications, 3 seconds is a LONG TIME to > wait when you're moving fast to do something. The problem here is that > Nokia regularly conflates two different kinds of messages as > "notifications": > > 1. REAL notifications of finished operations, like "email loaded" > 2. Dialogs which inform you of an operation ONGOING, like "deleting > directory..." > > #2 of course might have to be modal depending on the operation. > But #1 NEVER has to be modal, I don't understand. Infoprints are never modal, they don't even take focus. > and indeed the fact that it's sitting there for 3 > seconds or whatever, making me wait before I can do something for no > reason at all, is really quite surprisingly irritating. For example, > the "touch screen and buttons activated" notification is VERY irritating > -- once I have unlocked my screen I must sit and wait for another 3 > seconds before I'm permitted to actually do anything. Why? So I can > read a notification which I've already seen a hundred million times. If this is really a case, please file a bug to the Maemo Bugzilla. > What you should do is distinguish between these somehow. I personally > would make all #2-style notifications modal, According to the device UI style, dialogs should be always modal (to application if there's an application window open). If they are not, please file a bug about those too. (you can refer to the UI stylesheet :-)) >> The only reason why user would want to resize a dialog (that I can think >> of) is to make it larger so that she can see more of its content. >> However, these kind of dialogs usually already take all the available >> space, so I don't see much point in that. > > This is simply not true. Almost *none* of your dialogs take close to > all available space, and IMHO most of them are pretty bad when it comes > to organization. I hope the Nokia UI designers are also reading this list... > - The Font/Format selector could have been resized to a much larger > size, eliminating unneccessary tab panes, allowing the user to choose > his font from a list rather than a pop-up combo box (why is > bold/italic/underline on a SECONDARY pane? sheesh), automatically > showing the preview without the user having to press the preview button > AND then the close button, etc. You wasted space badly there. Go get a > Mac and look at its resizable, well-organized font panel. This is what > Nokia should be emulating. > > - The Color Selector could be resized to permit more user swatches, > > - The Open File panel could have been made larger in both width and > height, and here it'd really be useful. Such dialogs also have > unnecessarily large tall title bars and waste a ton of valuable vertical > space in the button row. Why are the buttons on the bottom in such a > height-constrained dialog? > > - Likewise for Save panels > > - Contacts's "Add Field" dialog is miniscule, requiring a scrolling > list for fields. I guess that's fine since Contacts only has FOUR > OPTIONS there. Were Contacts to permit new fields (hello? Snail-mail > address? Birthday? GPS? AIM? Anniversary? IRC Handle? Custom fields?), > this window would be far too small. > > etc. > >> If the dialog doesn't fill up the screen and is instead in a size that's >> not usable, that's a bug which should be reported separately. > > These problems are endemic, not specific. I'm not going to fill out bug > reports for thirty different dialog boxes. Fact of life: Bugs that are not reported to bug tracking system "do not exist". Maybe you could file a single bug about dialog sizes in general and list above items in it? >> Note that some of the dialogs have static sizes because Gtk doesn't >> always handle automatic resizing well enough. This is only a problem >> with text ellipsizing though I think. Gtk has only concepts of minimum >> (for ellipsizable text="...") and full size of a widget, as getting >> something reasonable in between would need a lot of iterating (slowdown) >> for the widget sizes. > > Why do your windows need to have live resizing? I'm not talking about user resizes, but calculating the dialog sizes. Did palms or Newtons ellipsize too long strings or were they only available in English? :-) - Eero ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
Hi, ext Levi Bard wrote: >> If infoprints could be dismissed by >> simply clicking on them, you wouldn't have any problems. > > I second this suggestion. No need for a close button, just make it go > away when I tap it. Good suggestion, I don't see any problems with that (app is not managing the infoprints, they can disappear whenever they want to, only progress banners are controlled by the application) Could you make a bug (enhancement request) about this to Maemo Bugzilla? - Eero ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
ext Sean Luke wrote: > On Apr 12, 2007, at 1:37 AM, Tapani Pälli wrote: > >>> The *right* thing would be to make all maemo dialogs and notifcations: >>> 1. Resiable >>> 2. Movable >>> 3. Persistent (so next time you reopen the app, the dialog is pops >>> up in exactly the size and place you put it last time) >>> >>> This would allow users to adjust dialogs and notifications as they >>> prefer. >>> >> >> Yes, this is *right* thing for someone, something else is *right* thing >> for someone else. Persistency sounds good to me, however I don't see >> much reason in moving modal dialogs on the screen except 'just for fun'. > > Moving's not a big deal. Resizing is a *big* deal. Many of your > dialogs are too small, or they obscure what we're operating on. At > any rate, the bigger problem is that existing dialogs are not > permitted to be movable or resizable even if it's helpful to the > developer. > I'm sorry but I don't see this as a problem. It's more work for the user to start resizing and moving a dialog than just filling in the information what dialog requests. In my opinion we have probably too much dialogs in the first place, but I'm not the UI designer ... > >> Resizing dialogs assumes that they all have scrollable and resizable >> content. Layout of the content has been carefully designed and will very >> likely 'break' when dialog is resized unless content is packed in a >> scrollable widget. In fact you can try this with several desktop apps >> and see how they break. > > Correct me here, as I'm not in a spot right now where I can do a test, > but if I recall, dialogs can't be resized or moved. Why not make this > an option, and let the developer choose it or not? And further, have > the windows stay where the user put them? > I mean try some linux distribution with Gtk programs, resize them and you'll see that in some of them layout can change quite much depending on the size of the window. You would get same kind of behaviour with resizable dialogs, weirdish looking layouts + sometimes not having scrollbars and only seeing part of contents .. of course this can be solved with modifications to applications. > Sean // Tapani ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
Hey; On 4/11/07, Sean Luke <[EMAIL PROTECTED]> wrote: Hi; On Apr 11, 2007, at 12:07 PM, Eero Tamminen wrote: >> For the moment I'm experimenting with various floating windows for >> various utility functions -- my drag-and-drop example on my N800 >> website, say. > > Do you have an URL? > cs.gmu.edu/~sean/stuff/n800/ Aha. If it newton style clip board you are trying to copy - I think the way to do it would be something like; - When copied text is dragged use an override redirect window or potentially even better change the cursor image to represent the copied text (not sure if this is totally possible - would need some experimentation). You'll need to move the window yourself (no big deal). - When this window reaches a screen edge, unmap it and the remap a dialog window with the following set; o no decorations. o transient for root o _NET_WM_ABOVE hint set . (this may not be needed) - For pasteing / moving repeat / reverse the process. You could also potentially handle resizing if need be. That should hopefully do what you want and work fine with MB. -- Matthew ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
If infoprints could be dismissed by simply clicking on them, you wouldn't have any problems. I second this suggestion. No need for a close button, just make it go away when I tap it. -- It doesn't take a nukular scientist to pronounce foilage! --Marge Simpson http://www.gnu.org/philosophy/shouldbefree.html ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
: Moving windows in Maemo
Riku Voipio wrote: The UI should not use a dialog if it ends up hiding relevant information below it... IMNHO current UI overuses dialogs. Just count how many popup dialogs you need to get a http proxy set for a new wlan connection... I think Nokia has forgotten a crucial feature of GUI design in small devices, which they had pioneered in phones: that the number of interactions (in this case, taps) should be reduced to an absolute minimum. On my web page (sorry, I keep referring to it, but it's got all the good pictures), I've got a classic example: the awful Contacts application. If I wish to view the existing data a contact, I need to do this: - Tap the filter so I can see the contact, and scroll to it - Tap the contact - Press the weird ">>" button - Click on "Details" - Examine the data - Click close - Click close AGAIN On the Address Book application on the Mac, here's what I need to do: - Scroll to the contact - Tap the contact - Examine the data No closing anything. Likewise if I wish to EDIT the contact in Contacts and add an additional email address, I need to: - Tap the filter so I can see the contact, and scroll to it - Tap the contact - Press the weird ">>" button - Click on "Edit" - Click on "Add Field" - Choose Email - Click "OK" (bad name) - Fill in the new email address - Click close - Click close AGAIN On MacOS X's Address Book, here's what I do: - Scroll to the contact - Tap the contact - Click "Edit" - Click "+" next to the existing email address - Fill in the new email address I don't even need to bother clicking Edit again to turn off edit mode if I don't care. The Newton is similar to the Mac here. And on top of it, on the Mac and Newton I can *see* everything that's going on during this process because it's not being obscured by a big stack of dialog boxes. The difference is that Nokia has us wending through large collections of modal okay/close dialog boxes when it SHOULD be using pop-up menus and state changing buttons (like "Edit") to reduce the complexity of the system. I wish that Contacts were the only offender here. But it's not. The company needs to work much harder at flattening the user's GUI modality. Sean ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
On Apr 12, 2007, at 4:41 AM, Eero Tamminen wrote: By the time user was able to start moving notifications, they go away (within 3 secs I think). As I've already mentioned, I've found at least two counterexamples to this in Nokia's own apps: the most famous being the email deletion notification. If you're going to allow applications to treat notifications as non- modal (which Nokia has), then they MUST be movable. While we're on the topic of notifications, 3 seconds is a LONG TIME to wait when you're moving fast to do something. The problem here is that Nokia regularly conflates two different kinds of messages as "notifications": 1. REAL notifications of finished operations, like "email loaded" 2. Dialogs which inform you of an operation ONGOING, like "deleting directory..." #2 of course might have to be modal depending on the operation. But #1 NEVER has to be modal, and indeed the fact that it's sitting there for 3 seconds or whatever, making me wait before I can do something for no reason at all, is really quite surprisingly irritating. For example, the "touch screen and buttons activated" notification is VERY irritating -- once I have unlocked my screen I must sit and wait for another 3 seconds before I'm permitted to actually do anything. Why? So I can read a notification which I've already seen a hundred million times. What you should do is distinguish between these somehow. I personally would make all #2-style notifications modal, but for #1, I'd instead temporarily (3 secs) change the text of the application's title menu bar to the notification text, and change the menu bar's color to an alert color. That's out of the way, non-modal, and doesn't obscure anything relevant. The only reason why user would want to resize a dialog (that I can think of) is to make it larger so that she can see more of its content. However, these kind of dialogs usually already take all the available space, so I don't see much point in that. This is simply not true. Almost *none* of your dialogs take close to all available space, and IMHO most of them are pretty bad when it comes to organization. - The Font/Format selector could have been resized to a much larger size, eliminating unneccessary tab panes, allowing the user to choose his font from a list rather than a pop-up combo box (why is bold/ italic/underline on a SECONDARY pane? sheesh), automatically showing the preview without the user having to press the preview button AND then the close button, etc. You wasted space badly there. Go get a Mac and look at its resizable, well-organized font panel. This is what Nokia should be emulating. - The Color Selector could be resized to permit more user swatches, - The Open File panel could have been made larger in both width and height, and here it'd really be useful. Such dialogs also have unnecessarily large tall title bars and waste a ton of valuable vertical space in the button row. Why are the buttons on the bottom in such a height-constrained dialog? - Likewise for Save panels - Contacts's "Add Field" dialog is miniscule, requiring a scrolling list for fields. I guess that's fine since Contacts only has FOUR OPTIONS there. Were Contacts to permit new fields (hello? Snail-mail address? Birthday? GPS? AIM? Anniversary? IRC Handle? Custom fields?), this window would be far too small. etc. If the dialog doesn't fill up the screen and is instead in a size that's not usable, that's a bug which should be reported separately. These problems are endemic, not specific. I'm not going to fill out bug reports for thirty different dialog boxes. Note that some of the dialogs have static sizes because Gtk doesn't always handle automatic resizing well enough. This is only a problem with text ellipsizing though I think. Gtk has only concepts of minimum (for ellipsizable text="...") and full size of a widget, as getting something reasonable in between would need a lot of iterating (slowdown) for the widget sizes. Why do your windows need to have live resizing? Can't you just do a wireframe resize? Sean ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
On Apr 12, 2007, at 1:37 AM, Tapani Pälli wrote: The *right* thing would be to make all maemo dialogs and notifcations: 1. Resiable 2. Movable 3. Persistent (so next time you reopen the app, the dialog is pops up in exactly the size and place you put it last time) This would allow users to adjust dialogs and notifications as they prefer. Yes, this is *right* thing for someone, something else is *right* thing for someone else. Persistency sounds good to me, however I don't see much reason in moving modal dialogs on the screen except 'just for fun'. Moving's not a big deal. Resizing is a *big* deal. Many of your dialogs are too small, or they obscure what we're operating on. At any rate, the bigger problem is that existing dialogs are not permitted to be movable or resizable even if it's helpful to the developer. Resizing dialogs assumes that they all have scrollable and resizable content. Layout of the content has been carefully designed and will very likely 'break' when dialog is resized unless content is packed in a scrollable widget. In fact you can try this with several desktop apps and see how they break. Correct me here, as I'm not in a spot right now where I can do a test, but if I recall, dialogs can't be resized or moved. Why not make this an option, and let the developer choose it or not? And further, have the windows stay where the user put them? Sean___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
Eero Tamminen wrote: > Hi, > > ext Tapani Pälli wrote: > >>> The need for a close button and move option in infoprints is, as >>> stated before, they just prevent you from accessing stuff below them. >>> >>> Example: I can't crank up the brightness immediately (or mute sound) >>> when the "Connected to AP" infoprint is shown and it bothers me to >>> wait. Can't interact with the widgets under the infoprint. A dismiss >>> button on the top right in each infoprint would solve this. Without >>> the ability to close/dismiss these makes the users wait unnecessarily, >>> and that is just bad design. >>> >>> >> Well I don't really agree that 2.5 secs is 'too long' but I agree that >> sometimes infoprints are irritating, especially if there's more than 2 >> of them on top of each other ... it would be much better to have a >> quake-console instead. We have had some discussion about more >> centralized system, 'infoprint daemon' which could handle the queue of >> messages with more intelligence and maybe user could also read the stuff >> from backlog if does not want them infoprints to appear. Suggestions are >> welcome! >> > > Most of the infoprints should be application, not system ones. > Doing application specific infoprints (ones that are trancient > to application windows so that they are stacked with them) safely > could be quite tricky. > > Only system-infoprints and infoprints for topmost application would be shown. Maybe some tricky corner-cases, but I think a centralized system would make a lot of sense. Infoprints that are not for topmost window can be forgotten or shown later on. > - Eero > // Tapani ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
Hi, ext Tapani Pälli wrote: >> The need for a close button and move option in infoprints is, as >> stated before, they just prevent you from accessing stuff below them. >> >> Example: I can't crank up the brightness immediately (or mute sound) >> when the "Connected to AP" infoprint is shown and it bothers me to >> wait. Can't interact with the widgets under the infoprint. A dismiss >> button on the top right in each infoprint would solve this. Without >> the ability to close/dismiss these makes the users wait unnecessarily, >> and that is just bad design. >> > > Well I don't really agree that 2.5 secs is 'too long' but I agree that > sometimes infoprints are irritating, especially if there's more than 2 > of them on top of each other ... it would be much better to have a > quake-console instead. We have had some discussion about more > centralized system, 'infoprint daemon' which could handle the queue of > messages with more intelligence and maybe user could also read the stuff > from backlog if does not want them infoprints to appear. Suggestions are > welcome! Most of the infoprints should be application, not system ones. Doing application specific infoprints (ones that are trancient to application windows so that they are stacked with them) safely could be quite tricky. - Eero ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
Mika Yrjölä wrote: For me, the main benefit for being able to move the dialogs around at will would be the ability to position the dialog so that no information relevant for deciding how to react to the dialog is hidden below it. While the current default of the dialog changing to display just a wireframe of its geometry of course allows user to see what's below, it's not possible to interact with the dialog while looking at the information and vice versa. The UI should not use a dialog if it ends up hiding relevant information below it... IMNHO current UI overuses dialogs. Just count how many popup dialogs you need to get a http proxy set for a new wlan connection... ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
ext Kemal Hadimli wrote: > (Sorry, wrong from field. Reposting.) > > > The need for a close button and move option in infoprints is, as > stated before, they just prevent you from accessing stuff below them. > > Example: I can't crank up the brightness immediately (or mute sound) > when the "Connected to AP" infoprint is shown and it bothers me to > wait. Can't interact with the widgets under the infoprint. A dismiss > button on the top right in each infoprint would solve this. Without > the ability to close/dismiss these makes the users wait unnecessarily, > and that is just bad design. > Well I don't really agree that 2.5 secs is 'too long' but I agree that sometimes infoprints are irritating, especially if there's more than 2 of them on top of each other ... it would be much better to have a quake-console instead. We have had some discussion about more centralized system, 'infoprint daemon' which could handle the queue of messages with more intelligence and maybe user could also read the stuff from backlog if does not want them infoprints to appear. Suggestions are welcome! > Another example: Some infoprints are there for a long time. Think > maemo-mapper downloading maps. The app is multithreaded and the > download process doesn't block you from browsing around, but you can't > access under the infoprint because there's no way to move it around > (or close/dismiss it) > Yep I don't like that too, I think maemo-mapper should just have some kind of small animated icon in corner or toolbar with progressbar. > (Also, persistency among different types of infoprints would be good, > position etc) > > > A good way to handle this would be to register "notifications" with > the system, and then make a control panel applet to browse through > notifications (grouped by applications that registered them) and reset > states, disable some notifications (Some people might not want to > receive notification from maemo-connectivity-something each time it's > connected to an AP) and such. > > A workflow example off the top of my head would be something like this: > > Application A (let's call this "mapper") registers notifications at > installation (or on run, whatever) > notificationSystem_register(UNIQUE_ID_FOR_NOTIFICATION_DLP, "Map > download notification", NSYS_PROGRESS); > notificationSystem_register(UNIQUE_ID_FOR_NOTIFICATION_DLC, "Download > complete", NSYS_TEXT); > notificationSystem_register(UNIQUE_ID_FOR_NOTIFICATION_GENERR, > "Error-generic", NSYS_TEXT); > > first parameter could be a application-wide unique id for the > notification, second is the "name" (not text) and third is the type > (progressbar or whatnot) > > then, to display notifications the app would just call: > notificationSystem_display(UNIQUE_ID_FOR_NOTIFICATION_DLC, "The > download is complete"); > > Then the system decides whether or not to show it (depending on the > user prefs, see blow) where to place it and what size, etc. > > The control panel applet to manage notifications would show a list of > the applications that registered notifications: > +application b > +application c > +maemo-desktop > +mapper > > and when clicked it would show a list of registered notifications for > that app. Which the user can then "set a size and position", disable > (disabled notifications are not displayed), or reset (defaults) > > > Ok, i went a little off topic there. > > Best regards, > Kemal > > On 4/12/07, Tapani Pälli <[EMAIL PROTECTED]> wrote: >> ext Sean Luke wrote: >> > On Apr 11, 2007, at 12:07 PM, Eero Tamminen wrote: >> > >> >>> For the moment I'm experimenting with various floating windows for >> >>> various utility functions -- my drag-and-drop example on my N800 >> >>> website, say. >> >> >> >> Do you have an URL? >> > >> > cs.gmu.edu/~sean/stuff/n800/ >> > >> > [Perhaps I might issue that entire webpage as a bug on Bugzilla, but >> > then I'd be ask to break it up into individual reports :-)] >> > >> >> Drag and drop is initiated with stylus being pressed & moved and >> >> it goes away when the stylus is lifted. So an OverrideRedirect >> (popup) >> >> window is OK for D&D indication (and a stylus grab is implicit >> when the >> >> stulys/button is down), but Gtk should already be doing the D&D >> >> indication for you...? >> > >> > It's a different need than that, but thanks for the info nonetheless. >> > I'm thinking I might try something similar to the Newton's cut/paste >> > mechanism (see the article). >> > >> >> Hm. I think all the dialogs should be modal according to the UI >> >> guidelines. >> > >> > I've found at least two apps where that's not been the case. I can >> > mention one off the top of my head: deletion of email in the email >> > program. >> > >> > >> >>> Even if the window manager's movable-windows switch >> >>> *was* turned on, I'm not sure if they could still be moved, as they >> >>> don't have decorations. >> >> >> >> Which windows don't have decorations? >> > >> > Notification windows. >> > >> >> I don't s
Re: Moving windows in Maemo
On Thu, 2007-04-12 at 14:00 +0300, Kemal Hadimli wrote: > The need for a close button and move option in infoprints is, as > stated before, they just prevent you from accessing stuff below them. By the time you'd moved a banner out of the way it would disappear, so all you need is a close button. If infoprints could be dismissed by simply clicking on them, you wouldn't have any problems. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
Hi,
ext Kemal Hadimli wrote:
> The need for a close button and move option in infoprints is, as
> stated before, they just prevent you from accessing stuff below them.
>
> Example: I can't crank up the brightness immediately (or mute sound)
> when the "Connected to AP" infoprint is shown and it bothers me to
> wait. Can't interact with the widgets under the infoprint. A dismiss
> button on the top right in each infoprint would solve this. Without
> the ability to close/dismiss these makes the users wait unnecessarily,
> and that is just bad design.
Dialogs and banners are conceptually different. Dialogs expect user
interaction, take focus, and go away only on user interaction, banners
don't have any of these properties.
Besides, large enough, esthetically satisfactorily positioned close
button ('X') would take quite a lot of space in a banner. As a result
banners would cover significantly more of the screen and then you would
really need to close the banners...
> Another example: Some infoprints are there for a long time. Think
> maemo-mapper downloading maps. The app is multithreaded and the
> download process doesn't block you from browsing around, but you can't
> access under the infoprint because there's no way to move it around
> (or close/dismiss it)
If the progress notification is preventing you from something that
the application itself would be able to do, then the progress
notifications should be somewhere else. E.g. in toolbar like with
Browser. Maybe you should request this from the Maemo mapper instead?
- Eero
Disclaimer: I'm not a UI designer
___
maemo-developers mailing list
[EMAIL PROTECTED]
https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
(Sorry, wrong from field. Reposting.) The need for a close button and move option in infoprints is, as stated before, they just prevent you from accessing stuff below them. Example: I can't crank up the brightness immediately (or mute sound) when the "Connected to AP" infoprint is shown and it bothers me to wait. Can't interact with the widgets under the infoprint. A dismiss button on the top right in each infoprint would solve this. Without the ability to close/dismiss these makes the users wait unnecessarily, and that is just bad design. Another example: Some infoprints are there for a long time. Think maemo-mapper downloading maps. The app is multithreaded and the download process doesn't block you from browsing around, but you can't access under the infoprint because there's no way to move it around (or close/dismiss it) (Also, persistency among different types of infoprints would be good, position etc) A good way to handle this would be to register "notifications" with the system, and then make a control panel applet to browse through notifications (grouped by applications that registered them) and reset states, disable some notifications (Some people might not want to receive notification from maemo-connectivity-something each time it's connected to an AP) and such. A workflow example off the top of my head would be something like this: Application A (let's call this "mapper") registers notifications at installation (or on run, whatever) notificationSystem_register(UNIQUE_ID_FOR_NOTIFICATION_DLP, "Map download notification", NSYS_PROGRESS); notificationSystem_register(UNIQUE_ID_FOR_NOTIFICATION_DLC, "Download complete", NSYS_TEXT); notificationSystem_register(UNIQUE_ID_FOR_NOTIFICATION_GENERR, "Error-generic", NSYS_TEXT); first parameter could be a application-wide unique id for the notification, second is the "name" (not text) and third is the type (progressbar or whatnot) then, to display notifications the app would just call: notificationSystem_display(UNIQUE_ID_FOR_NOTIFICATION_DLC, "The download is complete"); Then the system decides whether or not to show it (depending on the user prefs, see blow) where to place it and what size, etc. The control panel applet to manage notifications would show a list of the applications that registered notifications: +application b +application c +maemo-desktop +mapper and when clicked it would show a list of registered notifications for that app. Which the user can then "set a size and position", disable (disabled notifications are not displayed), or reset (defaults) Ok, i went a little off topic there. Best regards, Kemal On 4/12/07, Tapani Pälli <[EMAIL PROTECTED]> wrote: ext Sean Luke wrote: > On Apr 11, 2007, at 12:07 PM, Eero Tamminen wrote: > >>> For the moment I'm experimenting with various floating windows for >>> various utility functions -- my drag-and-drop example on my N800 >>> website, say. >> >> Do you have an URL? > > cs.gmu.edu/~sean/stuff/n800/ > > [Perhaps I might issue that entire webpage as a bug on Bugzilla, but > then I'd be ask to break it up into individual reports :-)] > >> Drag and drop is initiated with stylus being pressed & moved and >> it goes away when the stylus is lifted. So an OverrideRedirect (popup) >> window is OK for D&D indication (and a stylus grab is implicit when the >> stulys/button is down), but Gtk should already be doing the D&D >> indication for you...? > > It's a different need than that, but thanks for the info nonetheless. > I'm thinking I might try something similar to the Newton's cut/paste > mechanism (see the article). > >> Hm. I think all the dialogs should be modal according to the UI >> guidelines. > > I've found at least two apps where that's not been the case. I can > mention one off the top of my head: deletion of email in the email > program. > > >>> Even if the window manager's movable-windows switch >>> *was* turned on, I'm not sure if they could still be moved, as they >>> don't have decorations. >> >> Which windows don't have decorations? > > Notification windows. > I don't see any reason to make infoprints resizable / movable. They are there for few seconds only and for notifications it's good to have one single place where they popup so your eye catches them. > >>> And various panels (fonts, saves, etc.) are not >> >> Panels = dialogs? > > Yes, sorry my NeXTSTEP past colors my vocabulary. > > >>> resizable even when their size is unneccessarily too small to be >>> useful. In all cases, if you moved them or resized these dialogs, >> >> If something is unusably small and there would be more space on screen >> to present that, it's definitely a bug. Could you file this to Maemo >> Bugzilla? > > It'd be for a lot of dialogs. > > The *right* thing would be to make all maemo dialogs and notifcations: > 1. Resiable > 2. Movable > 3. Persistent (so next time you reopen the app, the dialog is pops > up in exactly the size and place you put it last time) > > This w
Re: Moving windows in Maemo
Hi, Tapani Pälli wrote: > ext Sean Luke wrote: >> The *right* thing would be to make all maemo dialogs and notifcations: >> 1. Resiable >> 2. Movable Why? By the time user was able to start moving notifications, they go away (within 3 secs I think). The only reason why user would want to resize a dialog (that I can think of) is to make it larger so that she can see more of its content. However, these kind of dialogs usually already take all the available space, so I don't see much point in that. If the dialog doesn't fill up the screen and is instead in a size that's not usable, that's a bug which should be reported separately. Note that some of the dialogs have static sizes because Gtk doesn't always handle automatic resizing well enough. This is only a problem with text ellipsizing though I think. Gtk has only concepts of minimum (for ellipsizable text="...") and full size of a widget, as getting something reasonable in between would need a lot of iterating (slowdown) for the widget sizes. >> 3. Persistent (so next time you reopen the app, the dialog is pops >> up in exactly the size and place you put it last time) ... they'd not stay put next time, because maemo doesn't have persistent state. >>> Could you give an example of this problem? >> Not for dialogs/notifications, as they're not adjustable. But let's >> take another example. The email program (nicely) has adjustable >> columns in its column view. But if you quit the program after >> carefully adjusting the columns, when you come back next time, they're >> all reset to their default locations. What's the point of that? >> >> In general, in a good PDA UI, things "stay put". This is particularly >> important for small screen devices like the 770/N800, as the user must >> tweak to get things arranged in a usable state. Having them >> automatically untweak is very irritating. Other examples of things >> which should "stay put" after reloads: >> >> - scroll bar positions >> - range settings >> - combo box settings >> - text >> - checkboxes and radio buttons >> >> Much of this _should_ have been done at a system level; but at least >> it can be hacked by the coder at the app level. Unfortunately, >> Nokia's mechanism for storing state persistence is broken: it doesn't >> survive reboots. Maybe you could make a bug about the persistency? - Eero ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
On 4/12/07, Tapani Pälli <[EMAIL PROTECTED]> wrote: Yes, this is *right* thing for someone, something else is *right* thing for someone else. Persistency sounds good to me, however I don't see much reason in moving modal dialogs on the screen except 'just for fun'. For me, the main benefit for being able to move the dialogs around at will would be the ability to position the dialog so that no information relevant for deciding how to react to the dialog is hidden below it. While the current default of the dialog changing to display just a wireframe of its geometry of course allows user to see what's below, it's not possible to interact with the dialog while looking at the information and vice versa. On desktop I'd just drag the dialog into some harmless position if necessary and then do whatever seems to be appropriate. However, I admit that it's not a significant issue to me personally in real-world usage; most of the time I know what to do with the current dialog anyway, and most of the dialogs are small enough to not hide much information below. This is pretty much proven by the fact that I've not cared enough to play with the aforementioned -use_dialog_mode option, even though I've known about it existing :) (on the other hand, novice users might like things working more like they do on 'normal' desktops, but this is quite probably something that has received attention while designing the UI in the first place, and I know personally roughly as much about usability as about construction of nuclear reactors, which isn't much) ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
ext Sean Luke wrote: > On Apr 11, 2007, at 12:07 PM, Eero Tamminen wrote: > >>> For the moment I'm experimenting with various floating windows for >>> various utility functions -- my drag-and-drop example on my N800 >>> website, say. >> >> Do you have an URL? > > cs.gmu.edu/~sean/stuff/n800/ > > [Perhaps I might issue that entire webpage as a bug on Bugzilla, but > then I'd be ask to break it up into individual reports :-)] > >> Drag and drop is initiated with stylus being pressed & moved and >> it goes away when the stylus is lifted. So an OverrideRedirect (popup) >> window is OK for D&D indication (and a stylus grab is implicit when the >> stulys/button is down), but Gtk should already be doing the D&D >> indication for you...? > > It's a different need than that, but thanks for the info nonetheless. > I'm thinking I might try something similar to the Newton's cut/paste > mechanism (see the article). > >> Hm. I think all the dialogs should be modal according to the UI >> guidelines. > > I've found at least two apps where that's not been the case. I can > mention one off the top of my head: deletion of email in the email > program. > > >>> Even if the window manager's movable-windows switch >>> *was* turned on, I'm not sure if they could still be moved, as they >>> don't have decorations. >> >> Which windows don't have decorations? > > Notification windows. > I don't see any reason to make infoprints resizable / movable. They are there for few seconds only and for notifications it's good to have one single place where they popup so your eye catches them. > >>> And various panels (fonts, saves, etc.) are not >> >> Panels = dialogs? > > Yes, sorry my NeXTSTEP past colors my vocabulary. > > >>> resizable even when their size is unneccessarily too small to be >>> useful. In all cases, if you moved them or resized these dialogs, >> >> If something is unusably small and there would be more space on screen >> to present that, it's definitely a bug. Could you file this to Maemo >> Bugzilla? > > It'd be for a lot of dialogs. > > The *right* thing would be to make all maemo dialogs and notifcations: > 1. Resiable > 2. Movable > 3. Persistent (so next time you reopen the app, the dialog is pops > up in exactly the size and place you put it last time) > > This would allow users to adjust dialogs and notifications as they > prefer. > Yes, this is *right* thing for someone, something else is *right* thing for someone else. Persistency sounds good to me, however I don't see much reason in moving modal dialogs on the screen except 'just for fun'. Resizing dialogs assumes that they all have scrollable and resizable content. Layout of the content has been carefully designed and will very likely 'break' when dialog is resized unless content is packed in a scrollable widget. In fact you can try this with several desktop apps and see how they break. > >>> they'd not stay put next time, because maemo doesn't have persistent >>> state. >> >> Could you give an example of this problem? > > Not for dialogs/notifications, as they're not adjustable. But let's > take another example. The email program (nicely) has adjustable > columns in its column view. But if you quit the program after > carefully adjusting the columns, when you come back next time, they're > all reset to their default locations. What's the point of that? > > In general, in a good PDA UI, things "stay put". This is particularly > important for small screen devices like the 770/N800, as the user must > tweak to get things arranged in a usable state. Having them > automatically untweak is very irritating. Other examples of things > which should "stay put" after reloads: > > - scroll bar positions > - range settings > - combo box settings > - text > - checkboxes and radio buttons > > Much of this _should_ have been done at a system level; but at least > it can be hacked by the coder at the app level. Unfortunately, > Nokia's mechanism for storing state persistence is broken: it doesn't > survive reboots. > > Sean > ___ > maemo-developers mailing list > [EMAIL PROTECTED] > https://maemo.org/mailman/listinfo/maemo-developers > // Tapani ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
2007/4/11, Eero Tamminen <[EMAIL PROTECTED]>: Hi, ext Kalle Vahlman wrote: > 2007/4/9, Sean Luke <[EMAIL PROTECTED]>: >> On Apr 9, 2007, at 4:38 AM, Kalle Vahlman wrote: >> >> g = gtk.Window(gtk.WINDOW_POPUP) >> >> >> >> works fine. >> >> Thanks. The primary concern I have about WINDOW_POPUP is that it's >> "different" from other kinds of windows. A myriad of disadvantages >> to it are listed here: >> >> http://www.pygtk.org/docs/pygtk/gtk-constants.html#gtk-window-type- >> constants > > Yes, they are all pretty much saying "the window manager won't do > anything with POPUP windows" and that's correct. However, since > applications shouldn't be overriding the window manager behaviour, > that's the "correct" way to circumvent unwanted window manager > intervention. I think popup type sets the OverrideRedirect flag for the window. Yes, and as the flag states it overrides the redirection of window operations to the window manager for consideration. > I'm not sure what the "many features" mentioned there exactly are, but > since you would be overriding the wm anyway, I doubt there will be > much that you lose... Moving windows is not really overriding WM... Yes it is, if the window manager enforces a policy that doesn't allow it. It is the window manager that decides where the windows will be, whether the user can move them and what kind of borders it has. The clients can only present their wishes and hope for the best. User-driven window placement is solely an agreement between window manager and the user, client software should keep their hands off it ;) Dialogs can already e.g. position themselves on the screen how they want, WM centers the dialogs only if they haven't set co-ordinates before mapping themselves. Matchbox might allow that, some other wm might not. So in short: 1) override the wm and manage the windows yourself 2) fix / switch the wm 3) suck it up and go with the flow I'd suggest number three, as that is the least likely to cause annoying windowing problems. :P -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
On Apr 11, 2007, at 12:07 PM, Eero Tamminen wrote: For the moment I'm experimenting with various floating windows for various utility functions -- my drag-and-drop example on my N800 website, say. Do you have an URL? cs.gmu.edu/~sean/stuff/n800/ [Perhaps I might issue that entire webpage as a bug on Bugzilla, but then I'd be ask to break it up into individual reports :-)] Drag and drop is initiated with stylus being pressed & moved and it goes away when the stylus is lifted. So an OverrideRedirect (popup) window is OK for D&D indication (and a stylus grab is implicit when the stulys/button is down), but Gtk should already be doing the D&D indication for you...? It's a different need than that, but thanks for the info nonetheless. I'm thinking I might try something similar to the Newton's cut/paste mechanism (see the article). Hm. I think all the dialogs should be modal according to the UI guidelines. I've found at least two apps where that's not been the case. I can mention one off the top of my head: deletion of email in the email program. Even if the window manager's movable-windows switch *was* turned on, I'm not sure if they could still be moved, as they don't have decorations. Which windows don't have decorations? Notification windows. And various panels (fonts, saves, etc.) are not Panels = dialogs? Yes, sorry my NeXTSTEP past colors my vocabulary. resizable even when their size is unneccessarily too small to be useful. In all cases, if you moved them or resized these dialogs, If something is unusably small and there would be more space on screen to present that, it's definitely a bug. Could you file this to Maemo Bugzilla? It'd be for a lot of dialogs. The *right* thing would be to make all maemo dialogs and notifcations: 1. Resiable 2. Movable 3. Persistent (so next time you reopen the app, the dialog is pops up in exactly the size and place you put it last time) This would allow users to adjust dialogs and notifications as they prefer. they'd not stay put next time, because maemo doesn't have persistent state. Could you give an example of this problem? Not for dialogs/notifications, as they're not adjustable. But let's take another example. The email program (nicely) has adjustable columns in its column view. But if you quit the program after carefully adjusting the columns, when you come back next time, they're all reset to their default locations. What's the point of that? In general, in a good PDA UI, things "stay put". This is particularly important for small screen devices like the 770/N800, as the user must tweak to get things arranged in a usable state. Having them automatically untweak is very irritating. Other examples of things which should "stay put" after reloads: - scroll bar positions - range settings - combo box settings - text - checkboxes and radio buttons Much of this _should_ have been done at a system level; but at least it can be hacked by the coder at the app level. Unfortunately, Nokia's mechanism for storing state persistence is broken: it doesn't survive reboots. Sean ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
Hi, ext Sean Luke wrote: > On Apr 11, 2007, at 10:49 AM, Eero Tamminen wrote: > >> If one wants all dialogs to be movable, one can just set suitable >> -use_dialog_mode policy option value in the matchbox-window-manager >> startup script: /etc/osso-af-init/matchbox.sh and restart the device. >> (and if you make a mistake and matchbox doesn't startup, the device >> may end up in a reboot loop, so test this first in Scratchbox!) > > Thanks Eero. But therein lies the rub. As a developer, I'd like > software I write to be accessible to as wide an audience as possible: if > people can potentially brick their machines by doing what's necessary to > install my software, that's not a reasonable distribution strategy. > > For the moment I'm experimenting with various floating windows for > various utility functions -- my drag-and-drop example on my N800 > website, say. Do you have an URL? > To do so I need a way around the present IMHO > ill-considered window manager restrictions. The only options are > dialogs (which create lots of artifacts on moving/resizing) and, thanks > to Kalle, popups. Drag and drop is initiated with stylus being pressed & moved and it goes away when the stylus is lifted. So an OverrideRedirect (popup) window is OK for D&D indication (and a stylus grab is implicit when the stulys/button is down), but Gtk should already be doing the D&D indication for you...? >> Dialogs can already e.g. position themselves on the screen how >> they want, WM centers the dialogs only if they haven't set >> co-ordinates before mapping themselves. > > Sure, but... > > > As for the "standard" dialogs: except for PalmOS -- which for god's sake > I hope you're not trying to emulate -- I cannot immediately think of > another current PDA^H^H^HInternet Tablet UI which does not have the > option of movable or resizable windows. Maemo's notification windows > can't be moved, even when they're not modal and are blocking other GUI > operations (!!!) Hm. I think all the dialogs should be modal according to the UI guidelines. > Even if the window manager's movable-windows switch > *was* turned on, I'm not sure if they could still be moved, as they > don't have decorations. Which windows don't have decorations? > And various panels (fonts, saves, etc.) are not Panels = dialogs? > resizable even when their size is unneccessarily too small to be > useful. In all cases, if you moved them or resized these dialogs, If something is unusably small and there would be more space on screen to present that, it's definitely a bug. Could you file this to Maemo Bugzilla? > they'd not stay put next time, because maemo doesn't have persistent > state. Could you give an example of this problem? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
On Apr 11, 2007, at 10:49 AM, Eero Tamminen wrote: If one wants all dialogs to be movable, one can just set suitable -use_dialog_mode policy option value in the matchbox-window-manager startup script: /etc/osso-af-init/matchbox.sh and restart the device. (and if you make a mistake and matchbox doesn't startup, the device may end up in a reboot loop, so test this first in Scratchbox!) Thanks Eero. But therein lies the rub. As a developer, I'd like software I write to be accessible to as wide an audience as possible: if people can potentially brick their machines by doing what's necessary to install my software, that's not a reasonable distribution strategy. For the moment I'm experimenting with various floating windows for various utility functions -- my drag-and-drop example on my N800 website, say. To do so I need a way around the present IMHO ill- considered window manager restrictions. The only options are dialogs (which create lots of artifacts on moving/resizing) and, thanks to Kalle, popups. Dialogs can already e.g. position themselves on the screen how they want, WM centers the dialogs only if they haven't set co-ordinates before mapping themselves. Sure, but... As for the "standard" dialogs: except for PalmOS -- which for god's sake I hope you're not trying to emulate -- I cannot immediately think of another current PDA^H^H^HInternet Tablet UI which does not have the option of movable or resizable windows. Maemo's notification windows can't be moved, even when they're not modal and are blocking other GUI operations (!!!) Even if the window manager's movable-windows switch *was* turned on, I'm not sure if they could still be moved, as they don't have decorations. And various panels (fonts, saves, etc.) are not resizable even when their size is unneccessarily too small to be useful. In all cases, if you moved them or resized these dialogs, they'd not stay put next time, because maemo doesn't have persistent state. Sean ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
Hi, ext Kalle Vahlman wrote: > 2007/4/9, Sean Luke <[EMAIL PROTECTED]>: >> On Apr 9, 2007, at 4:38 AM, Kalle Vahlman wrote: >> >> g = gtk.Window(gtk.WINDOW_POPUP) >> >> >> >> works fine. >> >> Thanks. The primary concern I have about WINDOW_POPUP is that it's >> "different" from other kinds of windows. A myriad of disadvantages >> to it are listed here: >> >> http://www.pygtk.org/docs/pygtk/gtk-constants.html#gtk-window-type- >> constants > > Yes, they are all pretty much saying "the window manager won't do > anything with POPUP windows" and that's correct. However, since > applications shouldn't be overriding the window manager behaviour, > that's the "correct" way to circumvent unwanted window manager > intervention. I think popup type sets the OverrideRedirect flag for the window. This should normally be used only for windows such as popup menus that take grabs on user input and disappear when user tries to interact with something else. Reason being that WM really doesn't manage those, you could lose them under other windows and not be able to retrieve them etc. Doing grabs is even more evil (but unfortunately in the case of menus, a necessary evil). >> ...though perhaps for my purposes it may be acceptable. Are these >> problems with WINDOW_POPUP applicable to maemo, or are they mostly >> for general gtk? > > I'm not sure what the "many features" mentioned there exactly are, but > since you would be overriding the wm anyway, I doubt there will be > much that you lose... Moving windows is not really overriding WM... Dialogs can already e.g. position themselves on the screen how they want, WM centers the dialogs only if they haven't set co-ordinates before mapping themselves. If one wants all dialogs to be movable, one can just set suitable -use_dialog_mode policy option value in the matchbox-window-manager startup script: /etc/osso-af-init/matchbox.sh and restart the device. (and if you make a mistake and matchbox doesn't startup, the device may end up in a reboot loop, so test this first in Scratchbox!) > Depends on whatever "your purposes" might be of course, you neglected > to mention them ;) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
2007/4/9, Sean Luke <[EMAIL PROTECTED]>: On Apr 9, 2007, at 4:38 AM, Kalle Vahlman wrote: >> g = gtk.Window(gtk.WINDOW_POPUP) >> >> works fine. Thanks. The primary concern I have about WINDOW_POPUP is that it's "different" from other kinds of windows. A myriad of disadvantages to it are listed here: http://www.pygtk.org/docs/pygtk/gtk-constants.html#gtk-window-type- constants Yes, they are all pretty much saying "the window manager won't do anything with POPUP windows" and that's correct. However, since applications shouldn't be overriding the window manager behaviour, that's the "correct" way to circumvent unwanted window manager intervention. ...though perhaps for my purposes it may be acceptable. Are these problems with WINDOW_POPUP applicable to maemo, or are they mostly for general gtk? I'm not sure what the "many features" mentioned there exactly are, but since you would be overriding the wm anyway, I doubt there will be much that you lose... Depends on whatever "your purposes" might be of course, you neglected to mention them ;) -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
On Apr 9, 2007, at 4:38 AM, Kalle Vahlman wrote: g = gtk.Window(gtk.WINDOW_POPUP) works fine. Thanks. The primary concern I have about WINDOW_POPUP is that it's "different" from other kinds of windows. A myriad of disadvantages to it are listed here: http://www.pygtk.org/docs/pygtk/gtk-constants.html#gtk-window-type- constants ...though perhaps for my purposes it may be acceptable. Are these problems with WINDOW_POPUP applicable to maemo, or are they mostly for general gtk? Sean ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
2007/4/8, Sean Luke <[EMAIL PROTECTED]>:
Anyway, I whipped up the following little program below as a test and
low and behold I can get the window to drag around BUT it creates all
sorts of artifacts: screen tearing, a bizarre window flashing in the
top-left corner, and slow updates. The window moves very slowly
too. Not what I would have expected for a 300MHz machine.
Attached is a revised version of the test app, that doesn't show the
bug at least (changes commented below).
Few notes on dragging:
- The tearing is due to the poor screen update rate (basically a hw limitation)
- I'm under the impression that there is some (heavy?) filtering
going on wrt touchscreen input (to check the pressure data and so on),
and also physical limits of the touchscreen I guess (it's really easy
to make it think you lifted the stylys for example). Both of these
have an impact on how well the dragging will work.
import gtk
# We create a Dialog because maemo has hard-locked gtk.Window to be
the full
# size of the screen, and I've found now way to counteract that.
g = gtk.Window(gtk.WINDOW_POPUP)
works fine.
We
then
# delete the separator and make the window bright blue.
g = gtk.Dialog()
g.set_has_separator(False)
g.set_decorated(False)
g.modify_bg(gtk.STATE_NORMAL, gtk.gdk.Color(0,0,65535))
g.resize(100,100)
g.move(300,300)
# We add a button to the Dialog and try to move after the Button has
# been pushed because if you set Dialog's mask to include
BUTTON_PRESSED,
# no BUTTON_PRESSED event actually gets through -- instead,
MOTION_NOTIFY
# starts coming in incorrectly. Looks like another bug. So we have to
# use a Button to grab the BUTTON_PRESSED events...
b = gtk.Button()
g.vbox.add(b)
I don't know what you tried here with the event mask, but
g.add_events(gtk.gdk.BUTTON_PRESS_MASK)
works just fine here (maybe it's the dialog that didn't work with this?)
--
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
import gtk
# We create a Dialog because maemo has hard-locked gtk.Window to be
# size of the screen, and I've found now way to counteract that. We
# delete the separator and make the window bright blue.
g = gtk.Window(gtk.WINDOW_POPUP)
g.modify_bg(gtk.STATE_NORMAL, gtk.gdk.Color(0,0,65535))
g.resize(100,100)
g.move(300,300)
# We add a button to the Dialog and try to move after the Button has
# been pushed because if you set Dialog's mask to include
# no BUTTON_PRESSED event actually gets through -- instead,
# starts coming in incorrectly. Looks like another bug. So we have to
# use a Button to grab the BUTTON_PRESSED events...
g.add_events(gtk.gdk.BUTTON_PRESS_MASK)
# I'm using begin_move_drag here, but if I implement it myself with
# the same exact buggy artifacts occur.
g.connect("button_press_event", lambda widget, event:
g.window.begin_move_drag(event.button,
event.x + g.window.get_root_origin()[0],
event.y + g.window.get_root_origin()[1], event.time))
g.show_all()
gtk.main()
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
Hi; On 4/8/07, Sean Luke <[EMAIL PROTECTED]> wrote: Anyway, I whipped up the following little program below as a test and low and behold I can get the window to drag around BUT it creates all sorts of artifacts: screen tearing, a bizarre window flashing in the top-left corner, and slow updates. The flashing in top-left corner is a matchbox bug affecting moving decoration-less dialogs. It was fixed a little while ago in matchbox svn (2007-02-17 in ChangeLog) but I guess thats maybe a little later than whats on the device. In terms of the screen tearing and slow updates Id guess thats probably an issue with moving the window a little too fast for what the h/w can handle (the screen tearing suggests you are moving them very fast). -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Moving windows in Maemo
I'm wondering if anyone has had previous experience in moving windows
in maemo. I'm experimenting with various things which involve small
movable or resizable windows. Yeah, yeah, I know that Nokia's UI
guidelines foolishly declare that you can't move any windows, and
that all drag-and-drop must stop at the app windows' edge.
Anyway, I whipped up the following little program below as a test and
low and behold I can get the window to drag around BUT it creates all
sorts of artifacts: screen tearing, a bizarre window flashing in the
top-left corner, and slow updates. The window moves very slowly
too. Not what I would have expected for a 300MHz machine. There are
three possibilities:
- I'm doing window moves all wrong. The most likely case: in which
case, how do I do it right?
- This bug was never caught by Nokia because it's a use case they
didn't expect due to their UI guidelines.
- [conspiracy theorist alert :-)] Nokia specified the UI guidelines
the way they did in order to avoid fixing this bug. :-)
I strongly suspect the first. Anyone tried to do this before? No
doubt I'm screwing something up. I'm running on an N800, not
upgraded yet.
Sean
import gtk
# We create a Dialog because maemo has hard-locked gtk.Window to be
the full
# size of the screen, and I've found now way to counteract that. We
then
# delete the separator and make the window bright blue.
g = gtk.Dialog()
g.set_has_separator(False)
g.set_decorated(False)
g.modify_bg(gtk.STATE_NORMAL, gtk.gdk.Color(0,0,65535))
g.resize(100,100)
g.move(300,300)
# We add a button to the Dialog and try to move after the Button has
# been pushed because if you set Dialog's mask to include
BUTTON_PRESSED,
# no BUTTON_PRESSED event actually gets through -- instead,
MOTION_NOTIFY
# starts coming in incorrectly. Looks like another bug. So we have to
# use a Button to grab the BUTTON_PRESSED events...
b = gtk.Button()
g.vbox.add(b)
# I'm using begin_move_drag here, but if I implement it myself with
move(...),
# the same exact buggy artifacts occur.
b.connect("button_press_event", lambda widget, event:
g.window.begin_move_drag(event.button,
event.x + g.window.get_root_origin()[0],
event.y + g.window.get_root_origin()[1], event.time))
g.show_all()
gtk.main()
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
