electroaudio | # 2051 | 2011-02-04, 09:02 | Report

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.

sulu | # 2052 | 2011-02-04, 09:26 | Report

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.

RobbieThe1st | # 2053 | 2011-02-04, 12:58 | Report

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.

electroaudio | # 2054 | 2011-02-04, 14:24 | Report

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...

sulu | # 2055 | 2011-02-05, 00:35 | Report

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.


That doesn't bother me at all.


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.


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


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.

electroaudio | # 2056 | 2011-02-05, 02:06 | Report

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

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.

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

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.

Cue | # 2057 | 2011-02-05, 03:55 | Report

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.

sulu | # 2058 | 2011-02-07, 15:23 | Report

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

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.


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.

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.

electroaudio | # 2059 | 2011-02-12, 00:13 | Report

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

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?

qole | # 2060 | 2011-02-12, 05:46 | Report

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.