iLiad FBReader - trap buttons?

nekokami · 10-20-2007, 08:44 PM

Could FBReader be configured to trap the "up staircase," root display, and IDS update buttons, so that if you hit one of those buttons it exits FBReader before executing the button's usual function, instead of leaving it running in the background, so restarting it doesn't work correctly? I love FBReader, and use it for most of my "fun" reading, but having to reboot the iLiad if you accidentally bump a button is kind of annoying. You can lock all the hardware buttons, but then the page bar doesn't work.

wallcraft · 10-21-2007, 12:02 AM

The "up staircase" key should not cause problems. It is passed through to FBReader and you can map it to whatever action you want. I map it to <quit> (and I map long press up staircase to <home> since that is what its keycode is).

The other 5 keys don't reach FBReader, but are trapped by the contentLister. I don't know if the contentLister then issues a kill call that is missed by FBReader or not.

What are the symptoms of the problem? If it is just that a new FBReader invocation runs a 2nd FBReader, then there is an simple fix. In run.sh, use:

Code:

/usr/bin/killall FBReader 2>| ./killall.err
/usr/local/bin/FBReader  2>| ./run.err

This kills all running version of FBReader before starting it again. The stderr from the last run will be saved in killall.err and run.err. Note that if there are FBReader processes running you get an error from killall even when it works.

I tried this in stand-alone FBRreader and it seems to work. I'm not sure how FBReader works when you click on a book in the contentLister, but something similar should work.

If this is all that is needed, the same technique can be used in all the stand-alone single-app scripts. Then if there are rogue standalone apps you can kill them by re-invoking the same app.

jharker · 10-21-2007, 01:05 AM

I always assumed that contentLister issued a kill to the topmost program... but I don't have evidence to back it up. Am I wrong?

Wait, no it MUST issue a kill. Because, for example, if you press books, docs, etc. buttons, THOSE don't get trapped and sent to ipdf (for example), but ipdf still closes anyway...

nekokami · 10-21-2007, 10:38 AM

Thanks, wallcraft, I'll try this modification to the run.sh when I get a chance. jharker, I don't know the details of the problem, but if you accidentally get bumped out of FBReader and restart it, the pagebar won't work anymore. I remember reading about this in another thread, and someone said it was because you hadn't exited normally so there is an extra process running. I think.

wallcraft · 10-21-2007, 10:52 AM

FBReader does usually respond correctly to a "cancel" signal from a window manager (e.g. in the Linux desktop version). Also, other 3rd party apps (e.g. mrxtv) have the same problem on the iLiad. So it isn't necessarily a FBReader problem. I suppose contentLister might be sending some other signal, e.g. the "minimize" signal - which would be the normal thing for a window manager to do (but on the iLiad there is no way to unminimize the app later). If the contentList is sending a signal of some kind, then it should be possible for FBReader to catch the signal and exit.

DeGodefroi · 10-22-2007, 04:13 AM

So, ummm what does this mean for fbreader on the Iliad now?
Does it close itself when you leave FBreader via the starway button? Which you would use anyway to exit iPDF and other apps anyway.
Or do I have FBreader unwanted running in the background until I switch off the iliad?

wallcraft · 10-22-2007, 11:39 PM

I don't think the "up-key" (top left key) is mapped to "quit" by default in FBReader. You can check by seeing what happens, when you press it. I think nothing should happen, because this key is under FBReader's control and it (probably) isn't mapped to any action by default.

To remap the up-key to quit, select the options panel icon (tool or crossed tools) and then navigate to the "keys" tab (which may initially be off the right edge of the options window - get to it using the small right arrow near the tab labels or using the right arrow key on the on-screen keyboard). Then bind the up-key to "quit", selected from the pull down menu.

If you exit FBReader using the "device manager" key or one of the 4 bottom keys, then FBReader will still be running. If you exit using the quit icon (rightmost FBReader icon), or "quit" bound to a key (e.g. the up-key), then FBReader will actually close and exit.

nekokami · 10-23-2007, 10:18 AM

Would it be possible to modify the run.sh so that instead of killing an existing running process of FBReader, it puts that process to the foreground? It's been so long since I've had to use fg and bg on unix.... is that window-manager specific?

Adam B. · 10-23-2007, 10:31 AM

Quote:

Originally Posted by wallcraft

I don't think the "up-key" (top left key) is mapped to "quit" by default in FBReader. You can check by seeing what happens, when you press it. I think nothing should happen, because this key is under FBReader's control and it (probably) isn't mapped to any action by default.

Actually, it should be mapped to quit if you used my installer. I had setup an iLiad specific configuration with the package.

10-20-2007, 08:44 PM	#1
nekokami fruminous edugeek Posts: 6,745 Karma: 551260 Join Date: Oct 2006 Location: Northeast US Device: iPad, eBw 1150	FBReader - trap buttons? Could FBReader be configured to trap the "up staircase," root display, and IDS update buttons, so that if you hit one of those buttons it exits FBReader before executing the button's usual function, instead of leaving it running in the background, so restarting it doesn't work correctly? I love FBReader, and use it for most of my "fun" reading, but having to reboot the iLiad if you accidentally bump a button is kind of annoying. You can lock all the hardware buttons, but then the page bar doesn't work.

10-21-2007, 12:02 AM	#2
wallcraft reader Posts: 6,975 Karma: 5183568 Join Date: Mar 2006 Location: Mississippi, USA Device: Kindle 3, Kobo Glo HD	The "up staircase" key should not cause problems. It is passed through to FBReader and you can map it to whatever action you want. I map it to <quit> (and I map long press up staircase to <home> since that is what its keycode is). The other 5 keys don't reach FBReader, but are trapped by the contentLister. I don't know if the contentLister then issues a kill call that is missed by FBReader or not. What are the symptoms of the problem? If it is just that a new FBReader invocation runs a 2nd FBReader, then there is an simple fix. In run.sh, use: Code: /usr/bin/killall FBReader 2>\| ./killall.err /usr/local/bin/FBReader 2>\| ./run.err This kills all running version of FBReader before starting it again. The stderr from the last run will be saved in killall.err and run.err. Note that if there are FBReader processes running you get an error from killall even when it works. I tried this in stand-alone FBRreader and it seems to work. I'm not sure how FBReader works when you click on a book in the contentLister, but something similar should work. If this is all that is needed, the same technique can be used in all the stand-alone single-app scripts. Then if there are rogue standalone apps you can kill them by re-invoking the same app.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Odd buttons	TheKindleWorm	Amazon Kindle	0	09-01-2010 08:43 AM
New buttons images	pollito pito	Calibre	34	07-18-2010 04:34 PM
No buttons work	Edmund	Calibre	8	07-09-2010 02:51 PM
remapping buttons	kaas	Sony Reader Dev Corner	3	07-31-2008 03:35 PM

10-21-2007, 01:05 AM	#3
jharker Developer Posts: 345 Karma: 3473 Join Date: Apr 2007 Location: Brooklyn, NY, USA Device: iRex iLiad v1, Blackberry Tour, Kindle DX, iPad.	I always assumed that contentLister issued a kill to the topmost program... but I don't have evidence to back it up. Am I wrong? Wait, no it MUST issue a kill. Because, for example, if you press books, docs, etc. buttons, THOSE don't get trapped and sent to ipdf (for example), but ipdf still closes anyway...

10-21-2007, 10:38 AM	#4
nekokami fruminous edugeek Posts: 6,745 Karma: 551260 Join Date: Oct 2006 Location: Northeast US Device: iPad, eBw 1150	Thanks, wallcraft, I'll try this modification to the run.sh when I get a chance. jharker, I don't know the details of the problem, but if you accidentally get bumped out of FBReader and restart it, the pagebar won't work anymore. I remember reading about this in another thread, and someone said it was because you hadn't exited normally so there is an extra process running. I think.

10-21-2007, 10:52 AM	#5
wallcraft reader Posts: 6,975 Karma: 5183568 Join Date: Mar 2006 Location: Mississippi, USA Device: Kindle 3, Kobo Glo HD	FBReader does usually respond correctly to a "cancel" signal from a window manager (e.g. in the Linux desktop version). Also, other 3rd party apps (e.g. mrxtv) have the same problem on the iLiad. So it isn't necessarily a FBReader problem. I suppose contentLister might be sending some other signal, e.g. the "minimize" signal - which would be the normal thing for a window manager to do (but on the iLiad there is no way to unminimize the app later). If the contentList is sending a signal of some kind, then it should be possible for FBReader to catch the signal and exit.

10-22-2007, 04:13 AM	#6
DeGodefroi Zealot Posts: 131 Karma: 11 Join Date: Jun 2007 Device: Kindle DX Graphite (had Illiad)	So, ummm what does this mean for fbreader on the Iliad now? Does it close itself when you leave FBreader via the starway button? Which you would use anyway to exit iPDF and other apps anyway. Or do I have FBreader unwanted running in the background until I switch off the iliad?

10-22-2007, 11:39 PM	#7
wallcraft reader Posts: 6,975 Karma: 5183568 Join Date: Mar 2006 Location: Mississippi, USA Device: Kindle 3, Kobo Glo HD	I don't think the "up-key" (top left key) is mapped to "quit" by default in FBReader. You can check by seeing what happens, when you press it. I think nothing should happen, because this key is under FBReader's control and it (probably) isn't mapped to any action by default. To remap the up-key to quit, select the options panel icon (tool or crossed tools) and then navigate to the "keys" tab (which may initially be off the right edge of the options window - get to it using the small right arrow near the tab labels or using the right arrow key on the on-screen keyboard). Then bind the up-key to "quit", selected from the pull down menu. If you exit FBReader using the "device manager" key or one of the 4 bottom keys, then FBReader will still be running. If you exit using the quit icon (rightmost FBReader icon), or "quit" bound to a key (e.g. the up-key), then FBReader will actually close and exit.

10-23-2007, 10:18 AM	#8
nekokami fruminous edugeek Posts: 6,745 Karma: 551260 Join Date: Oct 2006 Location: Northeast US Device: iPad, eBw 1150	Would it be possible to modify the run.sh so that instead of killing an existing running process of FBReader, it puts that process to the foreground? It's been so long since I've had to use fg and bg on unix.... is that window-manager specific?

Advert

Advert