N

Differences between revisions 1 and 2
Revision 1 as of 2010-08-18 17:42:44
Size: 2932
Editor: c-71-56-223-2
Comment:
Revision 2 as of 2010-08-18 17:57:30
Size: 4075
Editor: c-71-56-223-2
Comment:
Deletions are marked like this. Additions are marked like this.
Line 25: Line 25:
 * '''Solving the Virtual Keyboard Problem''' - I've read that florence is going to be the default keyboard for Ubuntu. Am i wrong ? If yes, florence is really not usable. Really. (Mathieu Virbel) I believe there is already a spec/blueprint opened for a virtual keyboard in Ubuntu; I'll find it and link it (Duncan !McGreggor)
   * When you open the keyboard, the application window is adjusted to not hide the focused text input. Maybe an integration between unity/florence is required here. (Mathieu Virbel)
   * Predictive typing: in order to virtual keyboards to be productive, we must introduce algorithms to enhance people's writing tasks. In PyMT, we've got spelling keyboard... and it's not sufficient. A library like enchant (mean aspell/ispell) is doing auto-correction and suggestion, but doesn't care about the context. And that makes things unusable. (Mathieu Virbel)
 * '''GTK Theming for Multitouch'''
   * having a touch-usable GTK theme is going to be quite necessary (Mathieu Virbel).
   * we should have a plan for touch-friendly interface design in the absence of GTK theming, as a stop-gap measure (Mathieu Virbel).

UDS-N Multitouch Sessions Brainstorming

Names in parenthesis are the sources for the suggestion.

  • Support gesture definition from a configuration file - new gestures can be defined and existing gestures customized. This would be very useful for OEM's and users who want to extend or modify the default gesture support without having to modify source code. (Rafi Rubin, Bill Filler)

  • Flexibility in support for different touchscreens/hardware configurations - we typically have OEM's come to us with brand new or non-standard hardware components that they want us to support. Anything that you guys can do to design the MT system such that making supporting new hardware straight forward (like a write a plugin or module for a given touchscreen) would be great. (Bill Filler, MT Team)

  • Documentation and sample code for the client library - I anticipate that OEM Services will need to modify apps to make them multi-touch friendly so the more sample and doc you can provide the better (Bill Filler)

  • Add MT support to X - work with upstream throughout cycle; this is a continuation of work done during Maverick

  • Add MT support to GTK - work with upstream throughout cycle

  • Add MT support to Qt - work with upstream throughout cycle

  • Add MT support to apps - we're investigating adding MT support to the following applications (Ted Gould, Steve Magoun, MT Team):

    • evince
    • eon
    • f-stop or shotwell
    • firefox & chromium-browser

    • thunderbird & evolution

    • rhythm-box, totem, mplayer & vlc

  • Gestures in media players - for example, Apple's single-touch swipe gesture is useful for deleting an item in a list, but I could also see it being used to move to the next track in a music player. The music player might have both - single-finger swipe to move to the next track, 2-finger swipe to FF/rew in the current track. (Steve Magoun)

  • Apple-compatible browser gestures - Once we have touch events stuff working (not gestures), I'd like to implement in WebKitGTK support for the same touch events that Apple has implemented for the iPad and iPhone Safari browser. (Cody Russell)

  • Touchpad support - I'm looking at a systems such as the Dell Latitude Z. I suspect a mult-touch touchpad will be much more prevalent with the OEMs than touch screens. (Pete Goodall)

  • Gesture tuning - By UDS, people will have had a chance to work with our gesture engine. What's going well? What's broken? What needs fine-tuning? (MT Team)

  • Testing Infrastructure - how do we test the kernel, X, grail, geis, etc. What can we use from the community? What do we need to put in place for all of these? What can be used independently from our infrastructure?

  • Solving the Virtual Keyboard Problem - I've read that florence is going to be the default keyboard for Ubuntu. Am i wrong ? If yes, florence is really not usable. Really. (Mathieu Virbel) I believe there is already a spec/blueprint opened for a virtual keyboard in Ubuntu; I'll find it and link it (Duncan McGreggor)

    • When you open the keyboard, the application window is adjusted to not hide the focused text input. Maybe an integration between unity/florence is required here. (Mathieu Virbel)
    • Predictive typing: in order to virtual keyboards to be productive, we must introduce algorithms to enhance people's writing tasks. In PyMT, we've got spelling keyboard... and it's not sufficient. A library like enchant (mean aspell/ispell) is doing auto-correction and suggestion, but doesn't care about the context. And that makes things unusable. (Mathieu Virbel)
  • GTK Theming for Multitouch

    • having a touch-usable GTK theme is going to be quite necessary (Mathieu Virbel).
    • we should have a plan for touch-friendly interface design in the absence of GTK theming, as a stop-gap measure (Mathieu Virbel).

Proposed Sessions

TBD

Accepted Sessions

TBD

Declined Sessions

TBD

Post-UDS Specs

TBD

Multitouch/UDS/N (last edited 2010-09-01 02:29:26 by maisel-gw)