[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: Generalizing interfaces and interaction with QGraphicsItems
From: Diego Moya <turingt () gmail ! com>
Date: 2010-08-23 14:34:27
Message-ID: AANLkTik3Otq-Bz+FBNBKFicQUBwZG3-OFL5CKVFcRz9X () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
[Attachment #5 (text/html)]
<div class="gmail_quote">On 17 August 2010 13:21, Marco Martin <span \
dir="ltr"></span>wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt \
0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Monday 16 August 2010, Stefan Majewsky wrote:<br>
> The reason why I'm writing this is because I started work on libkgame, a<br>
> collection of libraries which shall, at some point, supersede libkdegames<br>
> which is currently used by most games in the kdegames module. In the<br>
> beginnings of the design process, I've identified as a main weakness of \
our<br> > applications the fact that they are designed for mouse and keyboard<br>
> interaction and for desktop form factors. They do not scale to the mobile<br>
> form-factors which are becoming increasingly important in casual gaming.<br>
</div><div class="im"><br>
> This effort should also cover input methods, in order<br>
> to make it dead-easy to integrate multitouch support in existing<br>
> applications.<br>
<br>
</div>for input, basically if you are chained to single touch, mouse events are<br>
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 mouse<br>
events, apart that they have an arbitrary number of points in a single event.<br>
there are also higher level gestures, but are probably -too- high level to be<br>
used in games...<br></blockquote><div><br><br>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.<br>
<br>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.<br></div>
</div><br>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.<br>
<br>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 º 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.<br>
<br><br>* [1] <a href="http://en.wikipedia.org/wiki/Crossing-based_interface">http://en.wikipedia.org/wiki/Crossing-based_interface</a><br>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic