HildonAppViewRewrite

  1. Sources:
  2. Design document:
  3. Preliminary API documentation:
  4. Migration guide from HildonApp / HildonAppView
  5. Done:
  6. TODO:
  7. Unordered set of goals for the new widget:
  8. Some use cases:
  9. Random implementation details:
  10. Open issues:

Sources:

https://stage.maemo.org/svn/maemo/projects/haf/branches/hildon-lgpl/hildon-window/

Design document:

https://stage.maemo.org/svn/maemo/projects/haf/doc/hildon-window/

Preliminary API documentation:

https://stage.maemo.org/svn/maemo/projects/haf/doc/hildon-lgpl-doc/index.html

Migration guide from HildonApp / HildonAppView

https://stage.maemo.org/svn/maemo/projects/haf/doc/hildon-window-migration-guide/

Done:

  • collect all the bits and pieces
  • API design
  • functional prototype
  • documentation for the new API
  • migration guide

TODO:

  • skinning implementation (code and gtkrc updates, fortunately can reuse graphics)

Unordered set of goals for the new widget:

  • unmodified gtk+ applications using GtkWindows will be accessible through the task switcher
  • porting from GtkWindows to the new API should be trivial to get the basic looks, not more complicated than currently to get the toolbars etc. look and feel as with AppViews
  • the new API should be as similar (toolbars) as possible, or in places more sane (key handling, fullscreening) than with AppViews

Some use cases:

1 . One or more windows and a. one+find toolbars and one menu each (simple and straightforward) a. one+find toolbars in each, one menu total (memory optimization) a. one+find toolbars and one menu total (even more memory optimization) 1 . State save and restore

Random implementation details:

Some work is also required to Task Navigator and Matchbox to fully support the "new" windowing concept, but it's mostly just to make them follow fd.o specs.

  • Use _NET_WM_ICON for window icon
    • => gtk_window_set_icon() / gtk_window_set_icon_name()
    • To avoid (why?) transferring pixel data, maybe introduce another property to specify an icon name in the icon theme?
  • _NET_WM_NEEDS_ATTENTION (or WM urgency hint) for blinking
    • => gtk_window_set_urgency_hint()
  • _NET_USER_TIME = 0 in an unmapped window to indicate "put below the currently visible one"
    • => gtk_window_set_focus_on_map (window, FALSE)
  • Fullscreen key handling
    • => in the application / widget
    • Window manager could do it, and because it's window management related, it would be a slightly better component to do it
      • In current setup it would probably conflict with HildonApp? event handling
    • However there is currently no existing mechanism for application to indicate its window shouldn't be fullscreened
      • reusing existing 'resizable' would be a bit overloading the semantics
      • => extension would be needed
  • Fullscreen mode should be per-application
    • By default fullscreen is a window mode
    • => In order to have fullscreen as application mode, application needs to manage it
    • Convenience API could be provided, but it must not prevent the per-window mode
    • In order to have fullscreen as device mode, it should be handled by the window manager
  • Avoid hardcoding pixel measurements in the code
    • => use style properties instead
  • Application modal dialogs
    • => they should "just work"
    • By default all gtk+ toplevel windows have the same group leader, matchbox could use that and make sure to handle dialogs correctly

Open issues:

  • Is the HildonAppView way of handling menus and toolbars working nicely?
    • get_menu() vs. set_menu_ui()
    • Toolbars are implicitly recognized and drawn at the bottom

  • Is the current GtkUIManager (menu) support good enough? Not in my opinion. IIRC, it now requires some weird stuff so that you can use GtkUIManager build menus as application menu while with new API, menus could be loaded with something like 1 funtion (In addition to defining actions for menu items) -- Pokute

    In current hildon-lgpl trunk, there's hildon_app{get,set}ui_manager() and hildon_app_view{get,set}menu_ui() but those haven't seen much practical testing yet --TommiKomulainen

  • Docs above say that hildon_window_set_menu() will take a GtkMenu. Could it take a GtkMenuShell allowing for easier porting when you've got a GtkMenuBar in the existing code? -- AndrewFlegg, 16-Feb-2006