[9fans] scrollbuttons 2.0

[9fans] scrollbuttons 2.0

[andrey mirtchovski]

this is my mouse (well, a latter iteration of it, actually):

	http://www-132.ibm.com/webapp/wcs/stores/servlet/ProductDisplay?catalogId=-840&langId=-1&partNumber=31P8700&storeId=1

the blue thing at the middle is a scroll button named ScrollPoint.
it's not a scroll wheel and resembles the cat tongue found on ibm
laptops.  i find myself using it more and more in X and lacking the
functionality in Plan 9.  to aleviate the problem i've implemented a
very simple change (hack?) to drawterm to make it use the ScrollPoint.

ScrollPoint works by sending 'Button 4' and 'Button 5' press/release X
events whenever it is pushed up or down.  drawterm now knows about
those two buttons and whenever it sees those events it sends a Kup and
Kdown keyboard commands to Plan 9.  it's strange that way, but it
actually works out amazingly well for terminals, acme and everything
else, even for vnc sessions initiated from Plan 9 (i run drawterm
fullscreen on lunux and then vnc back to the same box to get a browser
in my Plan 9 window).

the only problem i've seen so far with it is that pressing the button
in X terminals causes the bash history to appear (Kup) instead of a
scroll (Kpgup).  i could change Kup → Kpgup and Kdown → Kpgdown but
then the scrolling in Plan 9 would be much faster and imprecise...

because i don't have any other wheel mice around here i'd like to ask
those of you who are interested to give it a try to download the
drawterm-linux.gz and drawterm-freebsd.gz clients from
http://pages.cpsc.ucalgary.ca/~mirtchov/p9/ and see if their scroll
buttons work with them.  if you can compile drawterms for MacOSX,
Windows and your favuorite other OS i'd gladly put them on my page.
the source is in the same location -- drawterm.tgz.

i'd also like to ask for suggestions on how to implement it natively
in Plan 9.  the 'send keyboard command instead of a mouse event'
requires very little change, but is it 9-ish enough?

andrey

[9fans] mk question

[rog]

i'm sure i'm being stupid here, but i can't see how i should solve
this problem.

i've got build tree which holds (amongst other things) a program to be
compiled, which when run processes a data file to produce several
source code and some header files as output, which must in turn be
compiled.

i'd like to express these dependencies in a mkfile.

i've written a mkfile that looks like this:

	# mktypeset produces four output files from a .typeset file.
	%.b %.m %types.b %types.m: %.typeset
		mktypeset $stem.typeset

	# limbo compiles a .b into a .dis
	%.dis: %.b
		limbo -gw $stem.b

	# specify three current .typeset files.
	TYPESETS=abc grid fs

	DISFILES=${TYPESETS:%=%.dis} ${TYPESETS:%=%types.dis} 

	# all dis files (apart from mktypeset.dis) depend on the header files
	$DISFILES: ${TYPESETS:%=%.m} ${TYPESETS:%=%types.m}

	all:V: $DISFILES mktypeset.dis


however, this doesn't express the dependency that mktypeset.dis needs
to be built before running it.

if i change the first rule to:

	%.b %.m %types.b %types.m: %.typeset mktypeset.dis
		mktypeset $stem.typeset

then i get:

	mk: cycle in graph detected at target mktypeset.dis

any ideas?

Re: [9fans] mk question

[Russ Cox]

what if you add

mktypeset.b: /dev/null
	#

russ

Re: [9fans] mk question

[Bruce Ellis]

Russ Cox wrote:

 > what if you add
 >
 > mktypeset.b: /dev/null
 >     #
 >
 > russ

what if you read the code and convinced yourself that
the pages of code trying to help you are patching
the wrong algorithm?  there's a nice bit of unneeded
transitive closure code in there.  i looked at mk
a lot before writing mash.  mash does a breadth-first
search for a singular answer, using each rule only once.
my active server mashfile looks like your mkfile but it
works.  and mashes search code is a page (and a bit?) and
you probably have it.  mk works if you don't stray from
the path that works - it works well at building plan9.

you could use gmake - it has lotsa other cool bugs.

brucee

Re: [9fans] mk question

[Charles Forsyth]

brucee is probably right about the relative merits of the various
approaches for reasonably formulated mkfiles, but in this particular case,

>>if i change the first rule to:
>>	%.b %.m %types.b %types.m: %.typeset mktypeset.dis
>>then i get:
>>	mk: cycle in graph detected at target mktypeset.dis

it seems perfectly reasonable for mk to diagnose this.  it is circular,
since it's declaring that (at least by default) ALL .b in this directory
depend on mktypeset.dis, which as shown includes mketypset.b,
which might cause me, let alone mk, to wonder which is chicken or egg.
if the declarations reflect the dependencies, it should work (subject to bugs).

Re: [9fans] scrollbuttons 2.0

[Enache Adrian]

On Fri, Oct 15, 2004 a.d., andrey mirtchovski wrote:
> because i don't have any other wheel mice around here i'd like to ask
> those of you who are interested to give it a try to download the
> drawterm-linux.gz and drawterm-freebsd.gz clients from
> http://pages.cpsc.ucalgary.ca/~mirtchov/p9/ and see if their scroll
> buttons work with them.  if you can compile drawterms for MacOSX,
> Windows and your favuorite other OS i'd gladly put them on my page.
> the source is in the same location -- drawterm.tgz.
> 
> i'd also like to ask for suggestions on how to implement it natively
> in Plan 9.  the 'send keyboard command instead of a mouse event'
> requires very little change, but is it 9-ish enough?

i think that drawterm should set bits 4/5 in the packets put on
/dev/mouse (as m5mouseputc() or ps2mouseputc() are doing), so any
application could handle those events as it sees fit.

a small program passed in the -k switch to rio could then transform
them into Kup/Kdown.

regards,
Adi

Re: [9fans] scrollbuttons 2.0

[andrey mirtchovski]

It will be resolved, please stand by.  Russ and Rob have already
devised a way how.

andrey

Re: [9fans] scrollbuttons 2.0

[Fco. J. Ballesteros]

>> i'd also like to ask for suggestions on how to implement it natively
>> in Plan 9.  the 'send keyboard command instead of a mouse event'
>> requires very little change, but is it 9-ish enough?

We have been  using the [mouse ;-) ] wheel for a long time now.
It was just a couple of lines in rio that changed the buttons into
Kup/Kdown keys.

I just checked and I'm happy to see that rio in sources seems to be doing that
right now. One less change to maintain :-)

Re: [9fans] scrollbuttons 2.0

[Enache Adrian]

On Mon, Oct 18, 2004 a.d., Fco. J. Ballesteros wrote:
> We have been  using the [mouse ;-) ] wheel for a long time now.
> It was just a couple of lines in rio that changed the buttons into
> Kup/Kdown keys.

I did it (2 years ago) by extending the buttonmap command in /dev/mousectl
to be able to remap all five buttons and also to map buttons to keys.

I think I'll stick to that - I don't like the latest rio 'features'
(the half-baked ^F completition, incomplete arrow keys support, etc)
anyway :-)

Regards,
Adi