Easy Debian Fremantle Beta Testing - Page 206 - maemo.org

Active Topics

The N900 is now 15 years old! (8)
to Nokia N900 by whayong - 10 hrs, 58 mins ago
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 5 days, 7 hrs ago
more...

Page 206 of 333

206

Thread Tools

	electroaudio	2011-02-04 , 09:02
	Posts: 381 \| Thanked: 336 times \| Joined on Jan 2011 @ Stockholm, Sweden	#2051

Originally Posted by sulu

You want an on-screen touchpad? In principle the button/movement part is possible with xdotool.
One would need another program to create the interface that grabs the mouse actions. Zenity could do the mouse buttons but I have no idea if it could do something like a touchpad.

It would have to be some transparent form covering the whole screen but then there is the problem how to tell the difference between a simple mouse movement and a a marking action. And one couldn't simply click on any elements on the desktop unless the mouse pointer is exactly above it. So the usual touch-screen feeling would get lost.
I don't think that it's feasible with a reasonable effort and to a reasonable level of usability.

What I think could be useful is some kind of d-pad. This could either be on-screen or on the hardware keyboard (switching between d-pad and normal keyboard via some modifier - much like the num-pad switching on laptop keyboards without dedicated num-pads). I think the latter option would be better.
Could we somehow use the camera button for that switch? I know there is a program in the Maemo repository that allows to customize the action that is performed when the camera button is pressed. But I haven't tried it so far.

I dont understand everything you write since i dont know anything about the transports of the actions under the hood in linux (why zenity?).
But i am comparing the simplicity to use the touchpad on my notebook and how difficult, and sometimes impossible (OnMouseOver() doesnt work for instance), it is to use the stylus.
A Dpad would ofcourse be a big improvement over the stylus and from the youtube videos i have seen just about everyone has a problem with the stylus.

The thing i would like to have is a simple mousecontrol that doesnt need a concentration of 110% like the stylus need, and which cant mess things up if i slip, like when i try to hit something in a menu for instance (Like load previous document instead of save)

After all, the interface was made for a mouse and not for a stylus, so it isnt so strange that it is hard to use.

Quote & Reply |

sulu	2011-02-04 , 09:26
Posts: 915 \| Thanked: 3,209 times \| Joined on Jan 2011 @ Germany	#2052

Originally Posted by electroaudio

I dont understand everything you write since i dont know anything about the transports of the actions under the hood in linux (why zenity?).

Zenity just provides an easy way to create GUI forms that are connected with shell commands. So one could create a form with zenity that has two buttons which call mouse button events via xdotool. There are other ways than zenity to do the same, this was just the first that came into my mind.

Originally Posted by electroaudio

But i am comparing the simplicity to use the touchpad on my notebook and how difficult, and sometimes impossible (OnMouseOver() doesnt work for instance), it is to use the stylus.

Sure, that's true. Frankly, I'm fine with the way the stylus works - also i ED. But for me it's acceptable that some features don't work and I'm aware that other people might have different requirements.
btw: there is a workaround to use OnMouseOver: just tap on a place where a click doesn't matter and then hold and pull the stylus over the element where you want the OnMouseOver-event to happen.

Originally Posted by electroaudio

A Dpad would ofcourse be a big improvement over the stylus and from the youtube videos i have seen just about everyone has a problem with the stylus.

It's the total opposite for me. I still have some problems with the tiny keyboard of the N900, while I have no problem with hitting tiny symbols or menu items with the stylus. But I'll try if I can find a way to implement a d-pad during the weekend.

Quote & Reply |

The Following User Says Thank You to sulu For This Useful Post:
electroaudio

RobbieThe1st	2011-02-04 , 12:58
Posts: 842 \| Thanked: 1,197 times \| Joined on May 2010	#2053

Last night I installed EasyDebian, and I came to the conclusion that the installer needs a slight rework - Namely an option to extract the image to a different card than the compressed image is located on.
Why? If you write to the SD card and read from MyDocs, the device is fairly usable while it's extracting(Not sure about the other way around). It also only takes an hour or two. If you are reading/writing to MyDocs, things are unusable.

As it is, it's a simple edit to the shell-script - I just added "-c" to the lzma line, and then piped it into a file with ">/media/mmc/extractedImage.img". Simple.
Now, to make it usable for everyone, an extra prompt would be needed - about 5 mins of coding.

I'll do it myself if needed.

__________________
My projects: BackupMenu - OS Backup & restore | Video: Flashing your n900(LiveCD)
My devices: N770 + 8GB SD card soldered internally, N900 with 8GB SD card + Custom OC(125-950 typically).
OC freqs: 0:22,90 125:22,90 250:28,180 500:30,360 550:32,400 600:34,430 700:39,430 750:41,430 805:45,430 850:47,500 900:50,500 950:54,500 1000:58,500 1100:67,520 1150:71,520

Quote & Reply |

The Following User Says Thank You to RobbieThe1st For This Useful Post:
fw190

	electroaudio	2011-02-04 , 14:24
	Posts: 381 \| Thanked: 336 times \| Joined on Jan 2011 @ Stockholm, Sweden	#2054

Originally Posted by sulu

Zenity just provides an easy way to create GUI forms that are connected with shell commands. So one could create a form with zenity that has two buttons which call mouse button events via xdotool. There are other ways than zenity to do the same, this was just the first that came into my mind.

Sure, that's true. Frankly, I'm fine with the way the stylus works - also i ED. But for me it's acceptable that some features don't work and I'm aware that other people might have different requirements.
btw: there is a workaround to use OnMouseOver: just tap on a place where a click doesn't matter and then hold and pull the stylus over the element where you want the OnMouseOver-event to happen.

It's the total opposite for me. I still have some problems with the tiny keyboard of the N900, while I have no problem with hitting tiny symbols or menu items with the stylus. But I'll try if I can find a way to implement a d-pad during the weekend.

Honestly i dont like the keyboard either

so i use xvkbd...
(But i think that the hardest part with the stylus is that it is always into mouseclick-mode. So if the mouseclick could be separated from the stylus, then that would also make it much more reliable, maybe a zenitybutton on the side? hmm. no that would move the mouse

... the camerabutton would have been perfect there )

But i have been thinking about the pad for a while now...
From what i understand a transparent paintarea that covers the Whole screen is necessary to catch all the mouseevents, with buttons for mouseclick and mouselock.
Maybe even with a button to fold up a screenkeyboard, and a button to shrink it into a icon to get it out of the way when the stylus method is more preferable.
-Then all three types of inputs will be aviable within reach of the *fingertips*

Not necessary for me since i have very good eyes, but maybe for others, would be to have a button that converts the paintarea into a magnifying glass, magnifying the area around the mouseposition.

-What do you think? would this be a good overall improvement?
This is probably a lot more than xdotool can handle i suppose...

Quote & Reply |

sulu	2011-02-05 , 00:35
Posts: 915 \| Thanked: 3,209 times \| Joined on Jan 2011 @ Germany	#2055

Originally Posted by electroaudio

Honestly i dont like the keyboard either so i use xvkbd...

Up to now I can't say if I like the keyboard or not. I'm just not used to it. Maybe that will change, maybe it won't. But I already like it more than on-screen keyboards.

Originally Posted by electroaudio

(But i think that the hardest part with the stylus is that it is always into mouseclick-mode.

That doesn't bother me at all.

Originally Posted by electroaudio

... the camerabutton would have been perfect there )

I checked the camera button and I don't think it can be of any use in ED since it doesn't even send a keycode.

Originally Posted by electroaudio

But i have been thinking about the pad for a while now...
From what i understand a transparent paintarea that covers the Whole screen is necessary to catch all the mouseevents, with buttons for mouseclick and mouselock.
Maybe even with a button to fold up a screenkeyboard, and a button to shrink it into a icon to get it out of the way when the stylus method is more preferable.
-Then all three types of inputs will be aviable within reach of the *fingertips*

...and with no place left on the screen to show anything.

Originally Posted by electroaudio

Not necessary for me since i have very good eyes, but maybe for others, would be to have a button that converts the paintarea into a magnifying glass, magnifying the area around the mouseposition.

gnome-orca has a magnifier included. But it comes with a lot of bloat that makes even my laptop sluggish, which was cutting edge technology little more than a year ago.
I think I have once seen a leaner magnification tool, but I don't know the name anymore. It was not gnome-mag, or at least it was not gnome-mag alone but with some GUI frontend.

I tried to tinker some d-pad implementation and while I was researching for some details I stumbled upon a tool called keynav which is already in the debian repository. It's very similar to what I had in mind, but even better. Its usage seems a bit strange at first but I guess that's just a question of getting used to it and I think this usage is part of what makes keynav superior to my idea.
I think it has great potential in ED, at least for power users. Unfortunately the versions up to sid have a quite annoying bug which makes the lxde menu non-functional. So you'll need the experimental package. This in turn needs libxdo2 from sid, but apart from that there are (currently) no dependency issues.
If you start keynav it complains that it is unable to lookup the keycode for "bracketleft" even if this character isn't used in the configuration file. But if you tell xkvbd to issue "[" before you start keynav the error will disapppear.

Quote & Reply |

The Following 2 Users Say Thank You to sulu For This Useful Post:
electroaudio, qole

	electroaudio	2011-02-05 , 02:06
	Posts: 381 \| Thanked: 336 times \| Joined on Jan 2011 @ Stockholm, Sweden	#2056

Originally Posted by sulu

Up to now I can't say if I like the keyboard or not. I'm just not used to it. Maybe that will change, maybe it won't. But I already like it more than on-screen keyboards.

Well, i come from the communicators so the hw-keyboard is very limited for me. Its easier to use vxkeyb where everything is clickable.

...and with no place left on the screen to show anything.

well, it doesnt need to be visible buttons on the screen

those buttons could just as well be swipes from the edges like the mousepointer in microb.
But a magnifying glass would ofcourse make it possible to shrink fonts and other visible elements even further.

gnome-orca has a magnifier included. But it comes with a lot of bloat that makes even my laptop sluggish, which was cutting edge technology little more than a year ago.
I think I have once seen a leaner magnification tool, but I don't know the name anymore. It was not gnome-mag, or at least it was not gnome-mag alone but with some GUI frontend.

A magnifyingtool is very easy to code if the screenbuffer is open for reading, all that is needed is to read one pixel and write four for a magnificatin of two. or write 3x3 for a .. well, you get the idea

I tried to tinker some d-pad implementation and while I was researching for some details I stumbled upon a tool called keynav which is already in the debian repository. It's very similar to what I had in mind, but even better. Its usage seems a bit strange at first but I guess that's just a question of getting used to it and I think this usage is part of what makes keynav superior to my idea.
I think it has great potential in ED, at least for power users. Unfortunately the versions up to sid have a quite annoying bug which makes the lxde menu non-functional. So you'll need the experimental package. This in turn needs libxdo2 from sid, but apart from that there are (currently) no dependency issues.
If you start keynav it complains that it is unable to lookup the keycode for "bracketleft" even if this character isn't used in the configuration file. But if you tell xkvbd to issue "[" before you start keynav the error will disapppear.

Thanks! I will definately look into that

But i have to say that i like my idea very much, maybe i should dust off some of my old asm/C++ knowledge and try o make something out of it... but i dont really know what is possible or not under the hood in linux, or even how stuff there works

if it had been DOS i would just make my own INT33h handler.

Quote & Reply |

Cue	2011-02-05 , 03:55
Posts: 840 \| Thanked: 823 times \| Joined on Nov 2009	#2057

for magnification there is xzoom in the repos. It's lightweight. The window doesn't follow your mouse but it can still be very useful.

Quote & Reply |

sulu	2011-02-07 , 15:23
Posts: 915 \| Thanked: 3,209 times \| Joined on Jan 2011 @ Germany	#2058

Originally Posted by electroaudio

well, it doesnt need to be visible buttons on the screen
those buttons could just as well be swipes from the edges like the mousepointer in microb.

That concept is totally new to me. So I don't even have any actual idea of its usefulness.

Originally Posted by electroaudio

A magnifyingtool is very easy to code if the screenbuffer is open for reading, all that is needed is to read one pixel and write four for a magnificatin of two. or write 3x3 for a .. well, you get the idea

Yes, I get the idea. The problem is that you can't shrink fonts below 5 pixels height, otherwise they'll become unreadable, no matter how much you magnify them. And even 5 pixels need some adjustment by the user because some characters will be hard to separate. If you don't want to adjust, 8 pixels is the minimum height.

Originally Posted by electroaudio

But i have to say that i like my idea very much, maybe i should dust off some of my old asm/C++ knowledge and try o make something out of it... but i dont really know what is possible or not under the hood in linux, or even how stuff there works
if it had been DOS i would just make my own INT33h handler.

Going under the hood is the whole idea of Linux.

So what is possible in DOS will also be possible in Linux. Unfortunately I never learned proper ansi C(++) (I can read it, but I learned another dialect which always gets into my way when I try to code on my own) and asm was never my favourite.

Originally Posted by Cue

for magnification there is xzoom in the repos. It's lightweight. The window doesn't follow your mouse but it can still be very useful.

I tried xzoom, but I find it essential that the magnifier image follows the mouse cursor. If gnome-mag had a window-mode it would have been perfect.

Just another note on my d-pad experiment:
I was able to set up a working d-pad with xbindkeys/xdotool (well it's not that hard.), but I stumbled upon 2 maybe 3 problems:

1. There needs to be some switch mechanism between normal keyboard and d-pad (a key-combination). I thought that might be accomplished by guile, which is supported by xbindkeys. But unfortunately I've never dealt with guile or any other language that comes even close to it. But I fear I understood that the switch I had in mind would either require a nearly total rewrite of the keyboard handling in xbindkeysrc or a seperate handling in external scripts. I find both ideas extremely ugly, because every single keypress would have to be checked if it should write a character or cause a mouse movement. So I'll not do that. If someone has a better idea and preferably some experience in guile I'd appreciate any help.

2. There needs to be some mouse acceleration. First I tried with 1 pixel per key event, but this is just too slow to navigate. It starts to become useful at 10 pixels. Unfortunately the cursor becomes choppy at 5 pixels. The easiest solution I could think of was one or more acceleration buttons (there is an unused middle key in a 3x3-pad). But I don't know how useful this can be. I have massive problems with pressing two adjacent keys simultaneously, so I cant judge that. But I guess others are more talented.

3. The constant press of a button combined with the translation into mouse moves works, but creates an immense CPU load. I don't like the idea of a computer being occupied by mouse movement.

Last edited by sulu; 2011-02-07 at 15:25.

Quote & Reply |

	electroaudio	2011-02-12 , 00:13
	Posts: 381 \| Thanked: 336 times \| Joined on Jan 2011 @ Stockholm, Sweden	#2059

Originally Posted by sulu

That concept is totally new to me. So I don't even have any actual idea of its usefulness.

I have tried to imagine what it is like, and i think i like it.
-But havent tried it in reality yet, so...

Going under the hood is the whole idea of Linux.
So what is possible in DOS will also be possible in Linux. Unfortunately I never learned proper ansi C(++) (I can read it, but I learned another dialect which always gets into my way when I try to code on my own) and asm was never my favourite.

asm is my favourite, its a lot of work but it is also total freedom.
But linux is very different from dos, i have to know a lot that i dont know yet. I think i should install debian on a desktop computer and start to read about it. Any good links about how debian works?

Quote & Reply |

	qole	2011-02-12 , 05:46
	Moderator \| Posts: 7,109 \| Thanked: 8,820 times \| Joined on Oct 2007 @ Vancouver, BC, Canada	#2060

I recommend making an Ubuntu Live CD. Ubuntu is kind of a desktop-centric step-son of Debian, and they're very user-friendly. The Live CD will let you run Ubuntu on your PC without having to install anything. Everything you install will not affect your PC in the long term (although I guess you could partition your HD, which would have long term effects!)

Pretty much everything you learn in Ubuntu is directly transferable to Debian.

__________________
qole.org --- twitter --- Easy Debian wiki page
Please don't send me a private message, post to the appropriate thread.
Thank you all for your donations!