ScalabilityBrainStorming

About MaemoScalability,

Here is a raw list of technical items related to scalability. Feel free to test, comment and extend!

1 . Widgets scalability (theme/font issue) * pixel mesurment borders hardcoded * general scaling issues (need UI design) * complex widget (file selector) assumes screen size * Problematic Hildon widgets: * HildonAppView: hardcoded min size to 770 res, hardcoded borders. Would require min size change to contained + borders and border size (and which edges has a border) should be up to theming, not hardcoded.

1 . Command abstraction (actions/keys manager)

• GtkAction, needs extension ?

• GtkAction/GtkUIManager natively support binding actions to menuitems and toolbar items

  • (the items are created automatically).
  • The proxying mechanism however is quite generic so basically any widget could be used to trigger an action, but at least currently buttons etc.
  • need to be manually hooked up to do so, in code.

• Toolbar with priority on buttons to display depending on space available

  • supported by latest GTK ? (define an item as 'important')
  • scaling down (reduce display (icon+text / icon only))
  • Application defines an action. Graphical layer defines a control, and places it
  • Softkeys

  1 . TreeView scalability

• columns with priorities to display
• renderers with priorities to display (ex: string string P1, icon P2)

• content changes

  • single/multiple line
  • more condensed/extended form
    • "Ellipsising"
    • alternate representation (date/time for example)
    • probably a set of functions on top of TreeView

  1 . Scalability on display migration/rotation/resize

• static UI layout variations
• dynamic UI layout variations
• how to design GUI to support display migr/rot/resize
  • ex: toolbar, items droped, or moved to a drop down menu

• how much can be done without to touch the application (how much we can hide in the framework.)

  1 . UI layout on multiple screens (gtk_window_set_screen ?)

• gtk_window_set_screen() should "just work" but I think the bigger problem is how (or if) you abstract away the multi-display setup so that applications wouldn't need to handle exact configurations as special cases.
• display same set of data on two displays (communicator pb: display switch "restarts") needs MVC model
• display migration vs. display same set of data on two displays

• (application should not need to care (again))

  1 . spacial constraints in UI description (different layout manager than existing box based)

  1 . missing from GTK+: multiple columns container (for example out of a long list).

• (icon views works relatively like that.)

• -> use case: contact list (single column on small display; several columns on large display.)

  1 . finger use: physical size constraints on widgets

• UI developers needs to specify physical size

• fonts/icons size needs to be synchronized

  • -> may require lot of calculations
  • -> current implementation spread into GTK+

  1 . use of SVG, SDL, OpenGL ?

• SDL: should be able to do the same with gdk
• SVG:
  • performance study needed.
  • caching?

• needs test performance for SVG icons

  1 . language orientation (ltr/rtl -> layout change)

• pango supports ltr/rlt
• basic support in GTK+
• stock icons supports it (named icons not :(
• how well hildon widgets supports it?
• what's about maemo-af-desktop

• needs input from native people. Anyone?

  1 . maemo-af-desktop scalability

• similar situation than hildon widgets, a bit more complicated to scale.

  1 . Keyboard shortcut hints displayed only when keyboard available

• enable/disable hints (similar thing with icons)

  • dynamic change supported into GTK+
  • probably needs to modify GTK+ to modify

  1 . Switch between virtual/real keyboard

• currently if VKB already open, does not close.

  1 . Switch between stylus/mouse modes (check mouse use in current platform)

• Study mouse usage

  • mouse cursor
  • altering stylus specific behaviour (long press, tap and hold, list interactions)
  • stylus mode for GTK+

  1 . Window manager themeing

• related matter:

  • button size defined in pixels (wont scale), not theme mechanism?
  • define something in points (font) something in pixels (icon) which are supposed to be the same height.
  • scalable skin?

  1 . Menus

• hildonmenu -> menu bar on large screen

  1 . statusbar plugins (currently only 2 free slots)

  1 . DPI/physical size -> fonts/fingers