Einstein (Newton Emulator) port to the N800; and it's gone open source
Einstein is an emulator of the Newton MessagePad by Paul Guyot. Some items of interest to the list: 1. Paul has a working port of Einstein to the N800; I have verified it on my own box. The port is unfortunately too slow to use at the moment: it's unoptimized and typically takes 30 seconds to respond to a single pen event. But it runs! 2. Einstein has gone open source. Paul has posted the complete code and some documentation on Google Code here: http://code.google.com/p/einstein/ 3. The build instructions for the N800 are here: http://code.google.com/p/einstein/wiki/NokiaBuildInstructions [ see also http://code.google.com/p/einstein/wiki/BuildInstructions ] I'm hoping to solicit some eager maemo volunteers on what could bring a *very* large number of new applications to the 770 and N800 (and a fun environment). At this stage the project needs three things, which I think volunteers from the maemo side could help with a lot: A. N800-specific optimization, to get the emulator to a usable speed. It'll have to be 30x faster right now. B. Native assembly code execution, so we don't have to emulate an ARM on an ARM :-). This is ultimately fairly important for the emulator to be useful on the device. Paul tells me he's got hooks for this but there's some work to be done there. C. Maemo packaging; full-screen mode, use of the keyboard and various underlying services (tcp, dbus, etc.), a debian install package and simpler install mechanism. Sean ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Bugzilla brokan?
Since the recent modifications to maemo, bugzilla appears to have broken. I'd report the bugzilla bugs to bugzilla, but bugzilla's bugzilla bug reporting is broken too. :-) I love recursion. For example, whenever I receive an update on one of my bug reports, the URL looks something like this: https://bugs.maemo.org/show_bug.cgi?id=1256 Going to all new such report URLs now gives a 404: Not Found. It think it should have been: https://maemo.org/bugzilla/show_bug.cgi?id=1256 For much of this morning and yesterday, bugzilla has been completely down, at least from all the spots in the DC area I have access to (several different college campuses). Sean ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
YouTube and Planet Maemo
Two somewhat non-developer topics: 1. YouTube playback has significantly worsened after the update, at least on my box. Now the videos cannot keep up with the audio and get way way out of sync quickly. Can anyone else verify this? 2. I really do appreciate the efforts to improve the quality of the maemo.org website: but planet.maemo.org is IMHO a major step backwards. The little speech bubbles essentially restrict the blog text to a predefined, very narrow, width. This width looks awful with large pictures and it makes the articles quite hard to read. Eliminating the goofy icon representing people talking, and getting rid of the wasteful navigation column, would more than double the available space for the columns on the N800, not to mention a large- screen web browser. Sean ___ 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
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
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 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
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
: 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
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
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
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
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
Re: PyGTK CellRendererToggle
allow-checkbox-mode being on was one of various bugs I reported; I wonder if _anyone_ uses checkboxes in GTKTreeViews without first turning it off. Sean Lauro wrote: On 3/25/07, Gert Menke <[EMAIL PROTECTED]> wrote: The Checkboxes do not reflect the corresponding values in the TreeStore; instead always the checkbox in the currently selected line is active, while all others are not. Actually this is their "normal" behavior in maemo. You have to set the 'allow-checkbox-mode' property of the treeview to false. See [1]. [1] https://garage.maemo.org/tracker/index.php? func=detail&aid=519&group_id=40&atid=229 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: New project idea, pygtk questions, and a toolkit
Marius Gedminas wrote (a month ago!):
On Mon, Feb 19, 2007 at 12:41:15PM -0500, Sean Luke wrote:
- Why is it in python that you can attach a function, and an instance
variable, to an instance, but you cannot attach a method?
...
There's a distinction between functions, unbound methods and bound
methods. When you assign a function to a class attribute, you get a
unbound method.
This is an imaginary distinction only Python makes, and not for any
good reason. It looks to me like it's historical warts. :-( For
example, in NewtonScript (and Self, etc.), there's no distinction at
all between bound and unbound methods and functions: they're all
functions, and depending on the context in which they're called they
may or may not have 'self' bound to something interesting. CLOS
behaves similarly in this respect.
If by "anonymous" you mean "a function that does not have a name",
then
you can't. You can define a named function in the middle of another
function.
Yeah, that's what I had figured. :-(
I'd like to do this in python with the following equivalent (but
invalid) syntax:
myButton= Button()
myButton.printme = lambda self:
print("hi there")
print("I am " + self)
myButton = Button()
def printme(self=myButton):
print "hi there"
print "I am", self
myButton.printme = printme
Sadly, not the same thing for two reasons. First, because depending
on context we may have polluted the global namespace, and at least
the local namespace, with an arbitrary function name; and second,
depending on context this definition may not permit closures.
Thanks very much for your response anyway, Marius, it was helpful. I
had just hoped for better from this language but that's life.
Sean
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Pymaemo GUI wrapper toolkit (v1)
I've been working behind the scenes on a "wrapper" toolkit around GTK to work around GTK bugs and misfeatures, significantly simplify development, and add some seriously needed features (like object persistence and cleaning up signals) Daniel Amelang asked if the toolkit would be open. The answer is: yes! Here's my first experimental version, plus documentary: http://cs.gmu.edu/~sean/stuff/n800/toolkit/ The library comes with a test function you might find fun. Eero Tamminen reminded me to work hard to keep persistence database corruption from screwing up the app. I hope I've done an okay job there. Now that my homework is finished, allow me to gripe: I have never dealt with a more buggy, inconsistent, poorly-considered library than GTK in my whole life. It is incredible! In the course of building this small toolkit I've stumbled across about 30 major GTK bugs, and have reported a number of them. I've been able to work around many, but sadly not all, of these bugs in my wrapper toolkit. Sean ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
New project idea, pygtk questions, and a toolkit
Hi all. I've been playing with pygtk and mulling over what project I
should start. I think I'll do something small to get my feet wet,
but I do have a direction based on an immediate need of mine which I
can't find an existing maemo app for.
I'm thinking of ultimately doing a drag-and-drop hypercard-like form
database tool. Which you can customize for whatever you want:
recipes, contact lists, your CD collection, location of archeological
finds, you name it. I used to do a lot of hypercard coding and miss
this badly; and my cursory glance of the maemo apps suggests there
may be a bit of a hole there. Some questions:
- Is there an existing app which does this?
- I'm aware of pythoncard, but it relies on wxwidgets. How's the
wxwidget port coming along?
- There are several Java apps which do this. How's CLASSPATH coming
along?
And now some pygtk questions. Okay, mostly rants. But rants that I
*hope* I am ignorant about and can then apologize for. pygtk is a
pretty well-done cover over GTK, but GTK is irritating. :-(
- Why is there any distinction between events and signals?
- There appears to be no hook for gtk.Paned to detect when the user
is moving / has moved the divider bar. This would seem to me to be
the single most important hook. The only option I've found online is
to override the size change hook Am I missing something?
- How do you create a gtk.Slider which has ticks at 0, 3, 6, 9, ...?
It appears that the mechanism provided for gtk.Slider (its
"Adjustment" object) is pretty bad. So far as I can tell, short of
overriding the display mechanism, you can only get ticks which are
powers of 10. hildon.Controlbar looks better but has less
functionality. Is there another widget to use?
- gtk.SpinButton is retarded. It provides you with microscopic up/
down buttons on top of each other to fit within the vertical space of
a text field, when it _should_ be giving you large buttons side-by-
side in the form of <- ->. It can also only add or subtract, not
double or halve. hildon.NumberEditor only provides integers so far
as I can tell, and only add/subtract. Is there another widget to use?
- python's string-formatting function *rounds* integers rather than
truncating towards zero or flooring. This makes it close to
worthless for slider-like mechanisms, when an app gets 0.998... which
it typically (in my experience) needs to cut to 0.99, while the user
sees 1.0. I'm fairly new to python. Short of writing my own string
formatter, is there a python function which will provide formatted
strings from integers _truncated_ to a certain number of digits?
- Why is it in python that you can attach a function, and an instance
variable, to an instance, but you cannot attach a method? Or is
there a mechanism I'm not aware of? Second: can you make an
anonymous function through any route than a lambda? Because lambdas,
weirdly, don't permit statements inside them. In NewtonScript (and
Self, and JavaScript I think) objects are just dictionaries -- as is
the case for Python underneath -- and you can do this:
myButton := {
_proto: protoButton,
printme: func() begin
print("hi there");
print("I am " & self) end
};
I'd like to do this in python with the following equivalent (but
invalid) syntax:
myButton= Button()
myButton.printme = lambda self:
print("hi there")
print("I am " + self)
Can someone more experienced in Python tell me why this can't be
done, or if it can be done, how?
- How do I move the text in a gtk.Frame vertically? It's set too
close to the frame and descenders (g,q,p,y,j) collide with the frame
border in an ugly fashion.
Last, partly in response to irritation with GTK, I've been at work
making a lightweight cover library on top of pygtk. The goal is to
provide a minimum amount of functionality that's easier to use, but
to let you dip down into pygtk when you need to. Some items done:
- All stateful widgets (including gtk.Paned) have persistent state
across application executions.
- A number of widgets provide the functionality of several gtk
widgets at once. Box provides both HBox and VBox functionality and
also has a built-in gtk.Frame. And Pack combines Alignment and
Frame.Button provides togglebuttons, regular buttons, and check
buttons (that may be dumb, I may break them out). Label allows for
images as well.
- Detailed constructors.
- I'm replacing some widgets (SpinButton, Slider) with modified
versions which have more functionality.
- Hooks are handled through method calls, not signals/events. This
permits both subclass hooks and cleaner MVC calls (through lambdas).
- [planned] a customizable button bar, stateful and column-modifiable
treeview, and thicker scrollbars and split pane dividers. And
bigger, easier to
Re: [maemo-developers] N800/Newton comparison
On Feb 2, 2007, at 11:33 AM, Daniel Elstner wrote: OK, that was just one example. Another is that GTK+ (with Pango) has really sweet support for Unicode and complicated scripts. The comment that "GTK+ supposedly handles Unicode" makes it sound as though its support were rather limited or not working. My bad. By "supposedly" I meant "as far as I've been told". I've edited the article appropriately. http://developer.gnome.org/doc/API/2.0/gtk/GtkIMContext.html It'll probably require some hackery to make the handwriting recognition send status tokens or something by means of faked key press events, but from then on things can be handled by the input module. The application will get plain text from it in any case. Help me out here. I'm poking around with this object and trying to get a handle on it: google is not being a friend. :-( My guess after staring at it for a while is that a GtkIMContext is an intermediary of some sort between the focused widget and the current entry method (keyboard, handwriting, whatever). It think the interesting method here is gtk_im_context_get_preedit_string(), which I think is what lets apps update certain text regions to reflect the handwriting string as it changes. So that's clearly more than just keystroke events. So this means I probably could hack an input method overcomes #1 in my previous message. This leaves #2: direct entry. That's not a big deal really, but it'd sure be fun. So some items I don't know about yet: - Could the N800 support multiple simultaneous methods of entry -- a keyboard and a Chinese character entry field -- onscreen and *running* at the same time? Or does GTK expect there to be a single entry mechanism at a time? - Can the input method be overridden? For example, someone might be able to answer this immediately for me: if a bluetooth keyboard is connected, does clicking on a text field still bring up the software keyboard? If I constructed some other input procedure -- a (hypothetical) ever-present small floating panel, say, or speech recognition mechanism, and I click in a text area of a typical application, can I force the keyboard to not pop up? I have to mull over whether this may be worthwhile working on. I've got another fun app idea cooking that might steal my available time. Sean, who's been pleasantly surprised with python 2.5 on the box... ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] N800/Newton comparison
Daniel Elstner wrote: However, I think he's wrong in picking on GTK+ as the culprit for some of the UI annoyances. For instance, I don't think it's true that GTK+ only deals with simple input one character at a time. I'm pretty sure it's possible to pull off Newton-style handwriting as described by him with a sufficiently sophisticated GTK+ input module. I'd be glad to modify the article (and have) in response to corrections, and actually HWR is rather low on my list of complaints in the article. But no, the Newton's facilities, so far as I can tell, cannot be reasonably replicated with a plug-in input module, except for providing better recognition perhaps. But I'm not losing sleep over it. Though GTK is a classic least-common-denominator framework, it does allow lots of apps to be ported to the N800 immediately, and that's a worthy tradeoff. My article tried to focus on things they _could_ change without performing open heart surgery on a large open-source framework. HWR was low on the list. The Newton's HWR has three relevant characteristics for discussion here: 1. Interpreted handwriting is rarely handled by the underlying application through the event system, much less through a keystroke event facility; and in fact an application typically doesn't know or care that text is being written in one of its fields. It just shows up. You *can* override this facility to shove text at an application through key events (Newtons have keyboards) but it's not the default mechanism. An app could also receive text in whole paragraphs if it liked, and that text could include embedded pictures and intentionally uninterpreted handwriting in the form of stroke sequences (they're called "rich strings"). 2. Handwriting happens directly in text fields and text areas, not in a separate pop-up region. 3. The recognition is sophisticated. #3 is doable on the Nokia with a replacement module. And of course #1 and #2 be done inside an application with a writer who is sufficiently talented (or demented). But it's besides the point. For #1 and #2, the other applications won't _automatically_ use that app writer's handiwork, because GTK's framework [probably] doesn't support it. Each app would have to code for and link against his new library. But the whole _point_ of a GUI is to provide *all* applications with a powerful and consistent framework so they don't have to do tons of work writing their own (different from one another) approaches to user experience. Note: I wrote [probably] because as best I can tell GTK apps, like most UI systems originally created on PCs, routes text in the form of key events. But I'm not positive about this and wouldn't mind being corrected. Note 2: if you're interested in the Newton's UI and recognition system as a developer, you might look at http://www.unna.org/unna/ apple/documentation/developer/ProgrammersGuideOS2.0.pdf The chapters of interest are 8, 9, and 10. Sean ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Follow-up: N800 and Newton
Levi, surely you misread my statement. Sean On Jan 26, 2007, at 10:25 AM, Levi Bard wrote: May I say that I expected rather more antagonism than I've gotten even with my obnoxious follow-up. The professionalism of this list is impressive. Wow, disagreement is unprofessional? When you post an article like that to a list like this and ask for feedback, some of it is going to be negative. If you didn't want real feedback, why ask for any in the first place? ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Follow-up: N800 and Newton
Kalle wrote: 2007/1/25, Sean Luke <[EMAIL PROTECTED]>: - It's true that different (Newton vs. GTK+) doesn't mean better. But IMHO it doesn't require rabid fanboyism to make a cogent argument that GTK+ is distinctly inferior to OS X Yes, obviously a widget toolkit has no chance against an operating system from an interface point of view... ;) :-) I meant Cocoa, of course. I can't defend Carbon. and maemo is inferior to NewtonOS from an interface point of view. That being said, it *was* fair mentioning where the Newton's _not_ all that hot, so I added some items there. But I think it's fairly objective: GTK+ may or may not be better than KDE's offerings perhaps, but as a GUI development environment it's a long way shy of environments like Cocoa and NewtonOS [and yes, I think Cocoa > NewtonOS]. I think GTK+ developers and community would like to fix this, so could you perhaps elaborate on this "long way" Cocoa is more advanced than GTK+? What I've seen on my wife's Mac has really left me wondering what the heck is all the fuzz about the Mac UI. Sure, it has some millions of dollars spent on polish (as you point out below), but apart from few real solutions (which, btw, do not have anything to do with Cocoa) it really seems to be just a extra layer of varnish. The regular widgets seen in every window have basically the same functionality in both GTK+ and Mac UI, and I haven't yet seen anything that could not be implemented with GTK+ widgets if one wishes to do so. I promised not to go into further detail extensively: but what *I* think makes Cocoa impressive is not its prettiness. That's almost immaterial. It's the development environment's richness, consistency, and pervasiveness throughout the entire operating system. NeXT figured this out: if you give developers a collection of very rich and powerful tools, they have little need to build their own and thus make user experiences different from one another. Apple inherited that from NeXT. Among the highlights are one of the finest 2D graphics libraries anywhere (CoreGraphics), with easy support for very sophisticated PDF printing; elegant internationalization; easy multi-architecture binary support; and the finest typographic engine ever created (ATSUI). And a very _very_ nice widget set. One of my favorite Mac application houses is OmniGroup, whose wunderkind just left and founded Delicious Monster. Apps like Delicious Library, OmniWeb, and OmniGraffle are pretty strong examples of how you can take Cocoa and run with it. Low points include, I think: no GC, and QuickTime's API, which is pretty awful. As a developer, you'd do well to look into developing for OS X rather than examining its interface as a user. Even if you can't stand ObjC -- and some can't -- I think you'll still be impressed. Apple lucked out when they bought NeXT. (on a tongue-in-cheeck side note, GTK+ has traditionally been regarded as the fat cow of linux desktop toolkits while QT is seen as the flashy sleek one, so maybe you should take a look at Qutopia too and see if that's more to your liking?-)) No, I'm comfy with fat cows. My primary application development environment is Swing. :-( Anyway, there's something to be said for massive amounts of resources and UI expertise. Like Microsoft Windows has. Touche! But Microsoft is the counterexample to an amazing number of things! May I say that I expected rather more antagonism than I've gotten even with my obnoxious follow-up. The professionalism of this list is impressive. Sean ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Follow-up: N800 and Newton
d jump ship to. I told other Newton users this myself, and got a lot of positive response about the machine. And that's saying a lot with that crowd! But for the moment, its UI is little more than a highly modal, poorly-thought-out Palm-esque thing, and its app suite is too buggy. I made the leap gladly because of the siren song of Linux and built-in development tools (NOKIA, FOR THE LOVE OF PETE, GET GNU CLASSPATH WORKING ON THIS MACHINE). And indeed it is the Linux underpinnings which both give me hope (because it they are readily changed) and dread (because the Linux community has never produced more than a mediocre UI -- KDE and GNOME are the hunchbacked, cleft- paletted cousins you hide in the closet when MacOS X comes to dinner). But to get people to jump, Nokia doesn't have to invest all that much in fixing GTK+ and maemo. I think it's within grasp. That's what I hoped the essay would prod. So that's pretty much it from me on the subject for a while. Now maybe I'll go hack on the dang machine. Sean Luke ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] N800 GUI Improvements from a Newton Developer's Perspective
Thanks, that should *definitely* be made clear. GIMP is most impressive. GTK+ is not. Though as a NeXTSTEP and Newton developer perhaps I had too high an expectation of GTK+. Sean On Jan 22, 2007, at 5:46 AM, Murray Cumming wrote: On Sun, 2007-01-21 at 12:23 -0500, Sean Luke wrote: After using the N800 for a week or two, which of course qualifies me as Knowing All Things About It :-), I've thrown together a web page describing various places the N800's GUI could be improved, and some ugly bugs, from the perspective of a Newton developer (myself). As I like the N800 I tried to be fair and reasonable, exorcising most of my snark, but sometimes I couldn't help myself, sorry. Before I made the site public, I thought I'd post it to the developers' group and ask for some comments, agreements, and disagreements. The site URL may change afterwards. http://cs.gmu.edu/~sean/stuff/n800/ This sentence makes it difficult to take things seriously: "The N800 employs the GTK+ toolkit, originally created for the GIMP photo-manipulation program and bearing all the hallmarks of inexpert design." It's also not clear whether you are criticising GTK+ (just a toolkit) or GIMP (It's UI is getting better all the time and I'm sure they'd welcome constructive criticism). -- 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: [maemo-developers] N800 GUI Improvements from a Newton Developer's Perspective
On Jan 21, 2007, at 9:37 PM, Levi Bard wrote: No one should get offended by any facet of this discussion. I won't get religious about an object store and if there is someone out there who is passionate about having extra gutters, you should be able to voice it without recriminations. :) I'm not offended, and I apologize if it came across that I was. Those are just my comments on the article as I saw it, since he asked for feedback. I did indeed, and a semi-snark-filled article deserves semi-snark- filled feedback. It's reasonable. Several of the criticisms were valid, and I'll tweak the article a bit appropriately. And respond later on perhaps to some of the criticisms that I think were off the mark; at the very least the discussion might help me get a clue. Sean ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] N800 GUI Improvements from a Newton Developer's Perspective
After using the N800 for a week or two, which of course qualifies me as Knowing All Things About It :-), I've thrown together a web page describing various places the N800's GUI could be improved, and some ugly bugs, from the perspective of a Newton developer (myself). As I like the N800 I tried to be fair and reasonable, exorcising most of my snark, but sometimes I couldn't help myself, sorry. Before I made the site public, I thought I'd post it to the developers' group and ask for some comments, agreements, and disagreements. The site URL may change afterwards. http://cs.gmu.edu/~sean/stuff/n800/ Sean Luke ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] OS X Flasher for the N800?
When, or is, an OS X Flash utility going to be made available for the N800? And will it be made available Universal rather than just PPC? I realize that this device has only been out for two weeks, and that the OS X flasher was probably a labor of love by an employee at Nokia. But I suspect building the OS X flasher is little more than a recompile of the linux version, and there are a LOT of MacOS X users, like myself, who badly need it. Last: is there a reason the flasher utility isn't open source? [or am I being brain-damaged here, and it already is?] Sean ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
