Sam Holden | 9 Jul 2004 09:06
Picon
Picon

Re: Mouse scroll wheel in wily

ozan s yigit writes:
>> I modified wily/libXg to recognize scroll mouse events and scroll the
>> view accordingly. Would anybody here be interested in a patch? The patch
>> itself is very simple, since all it does is add handling of Button4 and
>> Button5 mouse events returned by X windows.
>
>please send me the patch when you get a chance.
>thanks.

Did anything come of this? It's a patch I'm certainly interested in,
I whipped up my own implementation just now, but wily internals scare
me (it has gary's fingerprints after all :) and I probably introduced
a huge bug of some sort or another...

It's only 20 lines of touched code or so, so here's a diff of my
implementation, feel free to point out the defects that certainly exist.

diff -c -r wily-0.13.41/libXg/gwin.c wily-0.13.41-mod/libXg/gwin.c
*** wily-0.13.41/libXg/gwin.c	Tue Oct  1 14:57:48 1996
--- wily-0.13.41-mod/libXg/gwin.c	Fri Jul  9 16:24:15 2004
***************
*** 355,360 ****
--- 355,362 ----
  		case 1:	s |= Button1Mask; break;
  		case 2:	s |= Button2Mask; break;
  		case 3:	s |= Button3Mask; break;
+ 		case 4:	s |= Button4Mask; break;
+ 		case 5:	s |= Button5Mask; break;
  		}
  		break;
(Continue reading)

Davor Cubranic | 12 Jul 2004 20:50
Picon
Picon
Favicon

Re: Mouse scroll wheel in wily

My modification was virtually identical, except for the addition of code
to vshow.c to handle mousewheel events over the scrollbar (otherwise
mouse wheel works only over the body of the window):

*** vshow.c     2004/04/03 05:12:48     1.1
--- vshow.c     2004/04/03 05:12:52
***************
*** 182,187 ****
--- 182,193 ----
                n = back_height(v->t, v->visible.p0,  v->f.font,
		Dx(v->f.r), m->xy.y - v->f.r.min.y);
                view_set(v, n);
                break;
+       case UP:
+               view_linesdown(v, 1, false);
+               break;
+       case DOWN:
+               view_linesdown(v, 1, true);
+               break;
        default:
                runepos = (text_length(v->t) * y) / Dy(v->f.r);
                n = text_startOfLine(v->t, runepos);

Also, I'm not sure if the checks for cancelled DOWN/UP in mouse.c can
actually happen with the current mousewheel hardware. That is, you can't
press mousewheel down, then before releasing it press another button in
order to cancel the operation, the way you can with regular mouse
buttons. Actually, maybe you can with that IBM mouse that has a little
up/down joystick rather than a wheel.

(Continue reading)

ozan s yigit | 12 Jul 2004 21:30
Picon

Re: Mouse scroll wheel in wily

thanks for confirming the changes. sorry for delayed response on all
this; was away on assorted trips and did not get to my mail on CS.

> Also, I'm not sure if the checks for cancelled DOWN/UP in mouse.c can
> actually happen with the current mousewheel hardware. That is, you can't
> press mousewheel down, then before releasing it press another button in
> order to cancel the operation, the way you can with regular mouse
> buttons. Actually, maybe you can with that IBM mouse that has a little
> up/down joystick rather than a wheel.

did not work on mine when i tried it, but it could be just me: i'm not happy
with the clicking action of some of the mousewheels i have tried; it often
feels as it it should click but doesn't and the stresses on my hand are all
wrong for click and cancel...

oz

[ps: thanks for everyone's patience on this patch and a few others]

Sam Holden | 13 Jul 2004 02:21
Picon
Picon

Re: Mouse scroll wheel in wily

Davor Cubranic writes:
>My modification was virtually identical, except for the addition of code
>to vshow.c to handle mousewheel events over the scrollbar (otherwise
>mouse wheel works only over the body of the window):

That shows my unfamiliarity with the wily source, I didn't think of that.

Making that patch at least showed me why wily had always interpreted my
mouse wheel scroll attempts as B3s...

[snip patch]

>
>Also, I'm not sure if the checks for cancelled DOWN/UP in mouse.c can
>actually happen with the current mousewheel hardware. That is, you can't
>press mousewheel down, then before releasing it press another button in
>order to cancel the operation, the way you can with regular mouse
>buttons. Actually, maybe you can with that IBM mouse that has a little
>up/down joystick rather than a wheel.

I don't think they can be cancelled either, I just copied the code
from the B3 code and thought better safe than sorry (again I'm not
familiar with the wily code, I was amazed when it compiled and even
more amazed when it didn't crash).

Of course simpler code is probably a better goal. 

I'm also using 5 instead of 1 in my code now, since 1 is just painfully
slow (for my purposes anyway - I use the scroll wheel when reading
through a file when my hand happens to be on the mouse - often because
(Continue reading)

Gary Capell | 13 Jul 2004 03:32
Picon
Favicon

Re: Mouse scroll wheel in wily

On Tue, Jul 13, 2004 at 10:21:03AM +1000, Sam Holden wrote:
> My recollections of gary's views on coding are obviously faulty, or
> he didn't practice what he preached... 

Probably I didn't :-(

> view_linesdown taking
> a boolean to indicate whether it really view_linesdown or view_linesup
> is bizarre - especially since there isn't anywhere I can see in
> which that argument isn't a constant. I had thought he didn't like
> functions taking "what to do" type flags, preferring a seperate
> function for each "what".

I think I'd still call those both the same function, but I'd maybe
give it a different name these days: viewLinesMove or viewLinesUpOrDown.

I haven't looked much at wily source in a long time, now I think
I'd be afraid/embarrassed to look :-/

--

-- 
Gary Capell <gary <at> commsecure.com.au>

Sam Holden | 14 Jul 2004 18:41
Picon
Picon

Python wily module

My gcc doesn't like compiling the wilymodule.c python module, due to
multi-line strings. I quickly patched it by added \n\ to the end of all
the lines in the multi-line strings, which I assume someone else has
done somewhere anyway (that seemed easier than finding a magic gcc
command line option to make it work).

I also wrote a quick wrapper module a lot like wilywin.py but with a
slightly different interface. If anyone is interested in that then give
me a yell.

Finally, my dislike of C python modules (and the fact that I had
something important to do from which I needed to procrastinate) drove me
to implement a pure python interface to wily. Ie. all the joyous socket
handling and message parsing/flattening is done in python, with no need
for a C compiler - though a C compiler makes generating the python
definitions from the enums easier than typing them manually and trusting
your recollection of what number C assigns the first unassigned enum
value is correct.

It's certainly buggy since I haven't tested it any more then getting a
list of windows (and since the wily instance is at work haven't compared
the output to the actual windows), but it has a wrapper interface that
is identical to the wrapper I use around the C python module so when I
get work I'll drop it in and see what breaks...

If anyone wants it, then again give me a yell - though I need to add
docstrings which will take a little bit of time.

Next time I need to procrastinate I'll translate the python into perl (I
also dislike C perl modules - though an Inline::C module would be good
(Continue reading)

ozan s yigit | 14 Jul 2004 19:55
Picon

Re: Python wily module


> Finally, my dislike of C python modules (and the fact that I had
> something important to do from which I needed to procrastinate) drove me
> to implement a pure python interface to wily. Ie. all the joyous socket
> handling and message parsing/flattening is done in python, with no need
> for a C compiler [...]

please send me a copy, and i'll add it to the web site.

> Of course now that I've done that, after all these years, someone is
> going to change the message format :)

not likely, unless someone has designed a better protocol and can
show hundreds of users would just be breaking the doors to use it... :) :)
(xml? :-P)

oz 

Sam Holden | 15 Jul 2004 05:47
Picon
Picon

Re: Python wily module

ozan s yigit writes:
>
>> Finally, my dislike of C python modules (and the fact that I had
>> something important to do from which I needed to procrastinate) drove me
>> to implement a pure python interface to wily. Ie. all the joyous socket
>> handling and message parsing/flattening is done in python, with no need
>> for a C compiler [...]
>
>please send me a copy, and i'll add it to the web site.

You can download a tarball from http://sam.holden.id.au/software/pywily

(as can any other wanna-be-alpha-testers)

The two main problems are I used the module name 'wily' which clashes with
the wilymodule.c implementation that comes with wily - then again I've
removed that module completely so I'll have to fix any bugs I come
across as I won't have another option...

I don't care if you take a copy of the tarball or just link mine.

One issue, is that I haven't attached any license information yet,
I'll do that soon enough, when I decide which. You may want to wait
until then I guess (I'll do that after I've actually done some testing)

>> Of course now that I've done that, after all these years, someone is
>> going to change the message format :)
>
>not likely, unless someone has designed a better protocol and can
>show hundreds of users would just be breaking the doors to use it... :) :)
(Continue reading)

Sam Holden | 15 Jul 2004 10:57
Picon
Picon

Re: Python wily module

Sam Holden writes:
>
>You can download a tarball from http://sam.holden.id.au/software/pywily

Replying to myself (after all a busy list is a good list).

I just put a newer version up there, I fixed a few silly bugs and
redesigned the event callback interface to be a little more sane.

I found the need for the rework when I implemented win using the module.
You can see the code at:

http://sam.holden.id.au/software/pywily/win.py

Note, it's ugly python, since I translated directly from a C program
which I don't understand (I know nothing about termios stuff and ioctls
and so on) but it's only a couple of hundred lines long (including a
long docstring/comment - containing perverted English due to me
rewording a sentence and not removing one word - and I can't be bothered
retaring and signing), the "automatic" memory handling of python cut the
code down significantly from the C version (though I suspect I lost a
lot of portability by ignoring all the system specific code).

Still haven't put anything except 'win' under a license :(
--

-- 
Sam

Sam Holden | 15 Jul 2004 15:57
Picon
Picon

More from me...

I'll just keep talking to myself (is it obvious my work profile this week
changed from writing code to writing a tech report :).

When implementing win in python I noticed a section in win.c which is
'#if 0'ed out with the following comment.

                        /*
             * This doesn't work. It's an idea for implementing scrolling
             * on output. What we need is msg.c to execute view_show()
             * but not view_select() or view_warp(). However, making that
             * modification would case view_show() to happen even if you
             * are not setting dot. What we need to do is separate the
             * functions show, select, and warp.
                         */

The behaviour in win is easy enough to 'cat large_file' and the window
doesn't scroll to show it. Sometimes that behaviour is what is wanted but
most of the time (at least for me) the window scrolling so that the
insertion point is visible would be prefered.

The comment above gives a solution, which I hacked up, the diff is:

---diff---
diff -c -r1.1.1.1 msg.c
*** wily/msg.c  13 Jul 2004 00:22:08 -0000      1.1.1.1
--- wily/msg.c  15 Jul 2004 13:37:37 -0000
***************
*** 280,287 ****
        if(view_goto(&v, &r, m->s)){
                if (show) {
(Continue reading)


Gmane