From kde-panel-devel Mon Aug 23 14:34:27 2010 From: Diego Moya Date: Mon, 23 Aug 2010 14:34:27 +0000 To: kde-panel-devel Subject: Re: Generalizing interfaces and interaction with QGraphicsItems Message-Id: X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=128257606916942 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0812192273==" --===============0812192273== Content-Type: multipart/alternative; boundary=0015175cb1d41db34e048e7e8d1a --0015175cb1d41db34e048e7e8d1a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 17 August 2010 13:21, Marco Martin wrote: > On Monday 16 August 2010, Stefan Majewsky wrote: > > The reason why I'm writing this is because I started work on libkgame, = a > > collection of libraries which shall, at some point, supersede libkdegam= es > > which is currently used by most games in the kdegames module. In the > > beginnings of the design process, I've identified as a main weakness of > our > > applications the fact that they are designed for mouse and keyboard > > interaction and for desktop form factors. They do not scale to the mobi= le > > form-factors which are becoming increasingly important in casual gaming= . > > > This effort should also cover input methods, in order > > to make it dead-easy to integrate multitouch support in existing > > applications. > > for input, basically if you are chained to single touch, mouse events are > usually mostly good enough, if you want to react to multi touch you shoul= d > implement -also- TouchEvents, that have a semantics almost identical to > mouse > events, apart that they have an arbitrary number of points in a single > event. > there are also higher level gestures, but are probably -too- high level t= o > be > used in games... > The problem with mouse events is that they were created for point-and-click applications in desktop environments, and they don't always translate well to mobile devices. Events like on-hover or keypress are quite difficult to reproduce in touch screens. Games aggravate this problem, as they can introduce a wide variety of interactions. Have also in mind that other non-standard input devices will likely become more popular, such as accelerometers, pressure and proximity sensors, or position tracking (now found at the Wii, Microsoft Natal and PS3 Move). These will be frequently used in casual games as they get added to mobile devices, and open games would greatly benefit from a library providing a standardized way to access them. For low level interaction that supports all those devices, I'd recommend basing the APIs on the concept of crossing-based interfaces[1] which have been poorly supported in traditional widget toolkits, but which I think would make a good basis for touch and position-based interfaces. A cross-based interface keeps track not just of the pointed object, but also which lines are being crossed by the input gesture. Imagine what a game could do if, instead of a mouse-out event, it received an event saying "the pointer has exited the button with direction 38=C2=BA NorthEast and at a speed of 20 in/s". In my opinion, this mid-level API would make it easier to program games tailored to several different input/output methods. * [1] http://en.wikipedia.org/wiki/Crossing-based_interface --0015175cb1d41db34e048e7e8d1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 17 August 2010 13:21, Marco Martin wrote:
On Monday 16 August 2010, Stefan Majewsky wrote:
> The reason why I'm writing this is because I started work on libkg= ame, a
> collection of libraries which shall, at some point, supersede libkdega= mes
> which is currently used by most games in the kdegames module. In the > beginnings of the design process, I've identified as a main weakne= ss of our
> applications the fact that they are designed for mouse and keyboard > interaction and for desktop form factors. They do not scale to the mob= ile
> form-factors which are becoming increasingly important in casual gamin= g.

> This effort should also cover input methods, in order
> to make it dead-easy to integrate multitouch support in existing
> applications.

for input, basically if you are chained to single touch, mouse events= are
usually mostly good enough, if you want to react to multi touch you should<= br> implement -also- TouchEvents, that have a semantics almost identical to mou= se
events, apart that they have an arbitrary number of points in a single even= t.
there are also higher level gestures, but are probably -too- high level to = be
used in games...


The problem with mouse events= is that they were created for point-and-click applications in desktop envi= ronments, and they don't always translate well to mobile devices. Event= s like on-hover or keypress are quite difficult to reproduce in touch scree= ns. Games aggravate this problem, as they can introduce a wide variety of i= nteractions.

Have also in mind that other non-standard input devices will likely bec= ome more popular, such as accelerometers, pressure and proximity sensors, o= r position tracking (now found at the Wii,=20 Microsoft Natal and PS3 Move). These will be frequently used in casual game= s as they get added to mobile devices, and open games would greatly benefit= from a library providing a standardized way to access them.

For low level interaction that supports all those devices, I'= d recommend basing the APIs on the concept of crossing-based interfaces[1] = which have been poorly supported in traditional widget toolkits, but which = I think would make a good basis for touch and position-based interfaces. A = cross-based interface keeps track not just of the pointed object, but also = which lines are being crossed by the input gesture.

Imagine what a game could do if, instead of a mouse-out event, it recei= ved an event saying "the pointer has exited the button with direction = 38=C2=BA NorthEast and at a speed of 20 in/s". In my opinion, this mid= -level API would make it easier to program games tailored to several differ= ent input/output methods.


* [1] http://en.wikipedia.org/wiki/Crossing-based_interface
--0015175cb1d41db34e048e7e8d1a-- --===============0812192273== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel --===============0812192273==--