FVWM: Touch Screens

[M***@gmx.de]

One important aspect of project life cycles is the ability
how projects keep in step with general technical development.

It may be the case that five or ten years from now a lot of computers
will be equipped with touch screens.

It could be a good idea to think about how FVWM would cope
with touch screens in the future. Decisions should be made:
Is FVWM supposed to support touch screens sometime or not?
If touch screen support is a good idea, how are the steps to
achieve that goal?

Someone asked for project ideas for GSoC 2012.
Would it make sense to let touch screen support be a project idea
for GSoC 2012 or any other year in the future?

At least, it could be an idea to develope a driver that converts
finger touch events into mouse events (moves and clicks) to be
able to reuse old software sometime in the future.



Just some strategic considerations.
The earlier these questions are asked the better for the project.
- Michael -

[Chris Siebenmann]

| One important aspect of project life cycles is the ability
| how projects keep in step with general technical development.
|
| It may be the case that five or ten years from now a lot of computers
| will be equipped with touch screens.
|
| It could be a good idea to think about how FVWM would cope
| with touch screens in the future. Decisions should be made:
| Is FVWM supposed to support touch screens sometime or not?
| If touch screen support is a good idea, how are the steps to
| achieve that goal?

My personal opinion is that we don't currently know what the right
window manager interface is for decent-sized touchscreen displays
(displays that are not going to be single application/window at a
time). Thus I feel that doing anything for touchscreens in FVWM right
now is highly premature; any work on touchscreen window managers is
likely to be highly experimental for years to come.

I also feel strongly that touchscreens are unlikely to be a general
interface for desktop or laptop computers any time in the future.
This has nothing to do with technology and everything to do with the
ergonomics of routinely reaching out and holding your arm up to touch
things and move your hands around.

- cks

[Jaimos F Skriletz]

Post by Chris Siebenmann
| One important aspect of project life cycles is the ability
| how projects keep in step with general technical development.
|
| It may be the case that five or ten years from now a lot of computers
| will be equipped with touch screens.
|
| It could be a good idea to think about how FVWM would cope
| Is FVWM supposed to support touch screens sometime or not?
| If touch screen support is a good idea, how are the steps to
| achieve that goal?
My personal opinion is that we don't currently know what the right
window manager interface is for decent-sized touchscreen displays
(displays that are not going to be single application/window at a
time). Thus I feel that doing anything for touchscreens in FVWM right
now is highly premature; any work on touchscreen window managers is
likely to be highly experimental for years to come.

There was a great multi touch screen demo I saw a few years ago I can't
seem to find but here is something similar, and I would love to be
running fvwm on one of those. Though I do agree that for the standard
consumer such things are a ways off, it still dosen't hurt to start
thinking about such things now. Though I don't think it is a major
project for GSOC at this time.

Yes I would love to be running FVWM on something like this

jaimos

[Thomas Adam]

Post by M***@gmx.de
Someone asked for project ideas for GSoC 2012.

That would be me.

Post by M***@gmx.de
Would it make sense to let touch screen support be a project idea
for GSoC 2012 or any other year in the future?

No -- because I, nor anyone else really knows what "touch screen" is. And
even then I don't understand what the problem is. FVWM isn't an application
which needs changing to work on a touch screen interface; it manages those
applications instead.

In $DAYJOB for example, I worked on changing our interface to be more
applicable to drag and drop techniques on a tablet device, but that's a
really specific thing to do. FVWM will work fine for showing menus and
FvwmButtons, etc for use on a touch screen.

So no, I don't see how you can make a project out of this for GSoC at all.

-- Thomas Adam

[Dan Espen]

Post by Thomas Adam

Post by M***@gmx.de
Someone asked for project ideas for GSoC 2012.

That would be me.

Post by M***@gmx.de
Would it make sense to let touch screen support be a project idea
for GSoC 2012 or any other year in the future?

No -- because I, nor anyone else really knows what "touch screen" is. And
even then I don't understand what the problem is. FVWM isn't an application
which needs changing to work on a touch screen interface; it manages those
applications instead.
In $DAYJOB for example, I worked on changing our interface to be more
applicable to drag and drop techniques on a tablet device, but that's a
really specific thing to do. FVWM will work fine for showing menus and
FvwmButtons, etc for use on a touch screen.
So no, I don't see how you can make a project out of this for GSoC at all.

The little reading I did on this tells me the X11 support for touch
isn't ready yet. The articles I found were still trying to work out the
design.

I'm not sure I'll EVER be ready.
The very thought of touching my screen gives me the creeps.
I hate screens covered in fingerprints.

[Michael Großer]

Post by Thomas Adam

Post by M***@gmx.de
Someone asked for project ideas for GSoC 2012.

That would be me.

Post by M***@gmx.de
Would it make sense to let touch screen support be a project idea
for GSoC 2012 or any other year in the future?

No -- because I, nor anyone else really knows what "touch screen" is. And
even then I don't understand what the problem is. FVWM isn't an application
which needs changing to work on a touch screen interface; it manages those
applications instead.
In $DAYJOB for example, I worked on changing our interface to be more
applicable to drag and drop techniques on a tablet device, but that's a
really specific thing to do. FVWM will work fine for showing menus and
FvwmButtons, etc for use on a touch screen.
So no, I don't see how you can make a project out of this for GSoC at all.
-- Thomas Adam

Good to know.
Then, my question is answered.

Thank you all.

[Julien Guertault]

Post by M***@gmx.de
Would it make sense to let touch screen support be a project idea
for GSoC 2012 or any other year in the future?

No -- because I, nor anyone else really knows what "touch screen" is.  And
even then I don't understand what the problem is.  FVWM isn't an application
which needs changing to work on a touch screen interface; it manages those
applications instead.

I suppose a first step would be to support multiple mouse pointers.

Then the user would probably want to have at least some conditional in
his configuration files to change the behavior when using a mouse
pointer that comes from the touchscreen. Because really, you don't
want to touch your windows with your fingers the same way you click at
them.

You also want to know if the device has changed its mode to
touchscreen, to change the layout accordingly (bigger buttons, maybe
less decoration, etc). I'm thinking of tablet laptops here; they are
getting more and more popular, and when the interface is implemented
correctly, it really comes handy.

[Michael Großer]

Perhaps my statement about "the question is answered"
was a bit premature yesterday in the evening.

I'm pleased that my initial question attracts wide
interest in this list.

Post by Julien Guertault

Post by Thomas Adam

Post by M***@gmx.de
Would it make sense to let touch screen support be a project idea
for GSoC 2012 or any other year in the future?

No -- because I, nor anyone else really knows what "touch screen" is. And
even then I don't understand what the problem is. FVWM isn't an application
which needs changing to work on a touch screen interface; it manages those
applications instead.

I suppose a first step would be to support multiple mouse pointers.

Good point: Multiple mouse pointers, for example to change the size of
windows with two fingers. Is this rather "easy to implement" or rather
"utterly impossible to implement". The answer to this question
could be crucial about the question if FVWM will still be "cool"
in the future or not.

Post by Julien Guertault
Then the user would probably want to have at least some conditional in
his configuration files to change the behavior when using a mouse
pointer that comes from the touchscreen. Because really, you don't
want to touch your windows with your fingers the same way you click at
them.

Option 1: Finger touches are generally other mouse pointers, different
from the mouse pointer belonging to the actual mouse.

Option 2: Finger touches are defined as button 100, button 101,
button 102, ..., instead of button 1, ..., button 3.

Post by Julien Guertault
You also want to know if the device has changed its mode to
touchscreen, to change the layout accordingly (bigger buttons, maybe
less decoration, etc). I'm thinking of tablet laptops here; they are
getting more and more popular, and when the interface is implemented
correctly, it really comes handy.

Should be easy, is it?

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Another idea could be this:
Desktop computers have two monitors (screens):

- First monitor is the normal monitor (LCD screen) at eye level
without touch screen functionality.

- Second screen is a device that replaces the keyboard. It lies
on the table where today keyboards are lying. This is a touch screen,
which could emulate a keyboard on demand or constitutes a second
screen on demand. A touch screen with different decorations,
bigger buttons and so on.

The ergonomic disadvantage of this second screen would be the lack of
haptic sense when you replace a real keyboard with this solution.
Nobody knows what will be really modern in the future. I only
want to ensure that FVWM will not be the only window manager that
states "this is impossible to implement."

I mean, FVWM was one of the first WMs that supported Xinerama
as far as I know. It would be cool if FVWM would still be one
of the first WMs that support some "touch screen" relevant
technologies, in an age where Microsoft is about to design
Windows 8 for multi-touch input.

- Michael -

[Thomas Adam]

Post by Michael Großer
Good point: Multiple mouse pointers, for example to change the size of
windows with two fingers. Is this rather "easy to implement" or rather
"utterly impossible to implement". The answer to this question
could be crucial about the question if FVWM will still be "cool"
in the future or not.

Why are you and others thinking FVWM is responsible for this? It isn't, and
could never be: X would be, and I would hope some form of API on top of it.

Post by Michael Großer

Post by Julien Guertault
You also want to know if the device has changed its mode to
touchscreen, to change the layout accordingly (bigger buttons, maybe
less decoration, etc). I'm thinking of tablet laptops here; they are
getting more and more popular, and when the interface is implemented
correctly, it really comes handy.

Should be easy, is it?

XRandR? Not that easy, no. But it's needed to support mode changes.

[...]

-- Thomas Adam

[Julien Guertault]

Post by Michael Großer
Good point: Multiple mouse pointers, for example to change the size of
windows with two fingers. Is this rather "easy to implement" or rather
"utterly impossible to implement". The answer to this question
could be crucial about the question if FVWM will still be "cool"
in the future or not.

Why are you and others thinking FVWM is responsible for this?  It isn't, and
could never be:  X would be, and I would hope some form of API on top of it.

It's X's job for sure (supposing it does its job of course). But FVWM
would have to expose it to the user in some way (like the kind and
number of pointers). Suppose for instance a user would like to write a
configuration file that specifies a certain behavior when dragging a
title bar with on pointer, and a different one when dragging it with
two of them.

[Michael Großer]

Post by Julien Guertault

Post by Thomas Adam

Post by Michael Großer
Good point: Multiple mouse pointers, for example to change the size of
windows with two fingers. Is this rather "easy to implement" or rather
"utterly impossible to implement". The answer to this question
could be crucial about the question if FVWM will still be "cool"
in the future or not.

Why are you and others thinking FVWM is responsible for this? It isn't, and
could never be: X would be, and I would hope some form of API on top of it.

It's X's job for sure (supposing it does its job of course). But FVWM
would have to expose it to the user in some way (like the kind and
number of pointers). Suppose for instance a user would like to write a
configuration file that specifies a certain behavior when dragging a
title bar with on pointer, and a different one when dragging it with
two of them.

What piece of software draws the frames around windows?
Is it X or is it a WM?

When no WM is running, then no frames are around windows.

Does a WM draw the frames around windows or does a
WM instruct X to draw frames around windows?

[Dan Espen]

Post by Michael Großer

Post by Julien Guertault

Post by Thomas Adam

Post by Michael Großer
Good point: Multiple mouse pointers, for example to change the size of
windows with two fingers. Is this rather "easy to implement" or rather
"utterly impossible to implement". The answer to this question
could be crucial about the question if FVWM will still be "cool"
in the future or not.

Why are you and others thinking FVWM is responsible for this? It isn't, and
could never be: X would be, and I would hope some form of API on top of it.

It's X's job for sure (supposing it does its job of course). But FVWM
would have to expose it to the user in some way (like the kind and
number of pointers). Suppose for instance a user would like to write a
configuration file that specifies a certain behavior when dragging a
title bar with on pointer, and a different one when dragging it with
two of them.

What piece of software draws the frames around windows?
Is it X or is it a WM?
When no WM is running, then no frames are around windows.

Exactly.

Post by Michael Großer
Does a WM draw the frames around windows or does a
WM instruct X to draw frames around windows?

Is this rhetorical? You just answered your own question.

Anyway, Thomas is correct. Once multi-touch is part of X.org,
fvwm might implement something. Personally, I have no use for it.

To find out what's going on, I found the search terms "linux multitouch"
helpful. Some points to note: multiple pointers is not multitouch,
the existing pointer events are probably not sufficient. At least one
developer proposes new events.

[Michael Großer]

Post by Dan Espen

Post by Michael Großer
When no WM is running, then no frames are around windows.

Exactly.

Post by Michael Großer
Does a WM draw the frames around windows or does a
WM instruct X to draw frames around windows?

Is this rhetorical? You just answered your own question.

When X.org draws the frames, then X.org is the one who
changes the size of windows (or creates the necessary
events) as soon as the user moves a border with the mouse
or with his fingers.

When the WM draws the frames, then the WM is the one who
changes the size of windows (or creates the necessary
events) as soon as the user moves a border with the mouse
or with his fingers.

I asked the question to narrow down which one would really
be responsible for creating the necessary events.

After all what Thomas wrote, I conclude X.org must be
changed to support touch screens in the future (regarding
this special aspect). If this is true, then new trends like
touch screens do not mean a quick death of FVWM, which I
interpret as good news.

The reason why I asked questions about touch screens was
to detect early enough possible hazards that could endanger
the whole project. Currently, it looks like "stress test
passed".

- Michael -

[David Fries]

Post by Julien Guertault

Post by M***@gmx.de
Would it make sense to let touch screen support be a project idea
for GSoC 2012 or any other year in the future?

No -- because I, nor anyone else really knows what "touch screen" is.  And
even then I don't understand what the problem is.  FVWM isn't an application
which needs changing to work on a touch screen interface; it manages those
applications instead.

"Multi-touch support landing in X"
http://lwn.net/Articles/475886/

If you have a new enough X server it is available to start playing
with.

Post by Julien Guertault
I suppose a first step would be to support multiple mouse pointers.

I think they are independent problems. They both use a related
extended cookie event system to access, once you can use one the other
is easier to support, but it sounds to me like applications can make
use of the touch events without a window manager that supports them,
where applications can't really make use of multi-pointer X without
window manager support because now you have two (or more) actively
focused windows that need their keyboard pointed to follow the mouse,
where as the touch interface is still one keyboard to track. I could
be wrong with the touch interface as it's pretty new.

The multi-poiner X is something I could make use of right now. It's
easy enough to enable with two mice and the xinput program, then you
have two pointers moving around. Generally anytime a program isn't
using the new events, X picks which pointer to use in response to any
queries, and in general a non-multi-pointer aware program will work
fine as long as only one pointer tries to interact with it at one
time. It's unusable though without a multi-pointer X aware window
manager. It partly works with fvwm right now, the last pointer to
enter a window shows focus, if one pointer is in one program and
another pointer is in another program both can type to their window,
but move the second pointer into the first window and the first
keyboard continues typing to that window, but the second keyboard
types to the window it left not the window with both pointers. That
last one was the killer for me, I could live with the hilighted window
being limited to one window, but having to move the other mouse into
another window for the first to use it is unusable, if both keyboard
could be pointed at the window and multiplexed, that would be enough.
Especially in my case where I wanted a second mouse/pointer but still
just one keyboard.

Start out with a master pointer and master keyboard, create another
set, find out the device id= values, move a pointer and a keyboard
over to the new pointer and keyboard. Be careful of what you move
where or you might not be able to type anymore, or better yet ssh in.
I'm running X.Org X Server 1.11.3.901 2012-01-06, and the X server
crashed the first attempt to remove the new master, so there are some
bugs to be worked out yet.
xinput create-master random_name
xinput list
Virtual core pointer id=2 [master pointer (3)]
Synaptics Touchpad id=6
Virtual core keyboard id=3 [master keyboard (2)]
AT Translated Set 2 keyboard id=10
random_name pointer id=12 [master pointer (13)]
random_name keyboard id=13 [master keyboard (12)]
xinput reattach 6 12
xinput reattach 10 13
then when you've had enough,
xinput reattach 6 2
xinput reattach 10 3
xinput remove-master 13

I looked at adding multi-pointer X support to fvwm at one point in
time, but figured the changes wouldn't be accepted unless it could
fall back to the current input events, and that was more work than I
wanted to hack together.

Post by Julien Guertault
Then the user would probably want to have at least some conditional in
his configuration files to change the behavior when using a mouse
pointer that comes from the touchscreen. Because really, you don't
want to touch your windows with your fingers the same way you click at
them.
You also want to know if the device has changed its mode to
touchscreen, to change the layout accordingly (bigger buttons, maybe
less decoration, etc). I'm thinking of tablet laptops here; they are
getting more and more popular, and when the interface is implemented
correctly, it really comes handy.
--
Julien Guertault