Quote:
|
Originally Posted by jharker
To summarize it here, basically what happens is this: there's a proprietary kernel module button.o that handles the hardware side and is accessed through /dev/buttons. The ContentLister checks for button presses ten times per second by sending an ioctl to /dev/buttons, which the kernel module returns with the most recent button code. ContentLister decides what to do with the button press, either keeping it or passing it on to the X system as a standard keypress using (according to Matthijs) XSendEvent.
|
Does that mean that, once "we" have access to the whole thing, the
folder buttons could be reassigned to different functions
while reading a PDF?
I'm thinking of this mostly because currently there is no real way to add (button-requiring) features to the different iPDF viewers, and I'd really like it if there could be "next/previous bookmark" buttons added to (Mike's is which i use most) iPDF version. (since (in-file) bookmark support is what I miss most)
I noticed the DR1000 has that feature assigned to some of the buttons, so I was/am hoping something similar could be put in the iLiad's version.
(I don't really use the immediate-switch-to-folder-view feature offered by those buttons very often, so having to press "quit" before being able to go to another folder would be well worth it to me.)
The other 2 buttons could be assigned to "back/forward" in the 'browsing history', and it'd be one cool iPDF viewer :P