iLiad Community iPDF - Discussion - Page 2

daudi · 10-28-2007, 06:59 AM

When I was using the fullscreen version of ipdf I would often find that I needed to activate the toolbar to get to a function (erase or zoom to full page or change the pen or something) and once that was done I'd want to go back to the fullscreen view. It occurs to me now that it would have been handy if the toolbar could have been activated for a second or so and then disappear again without me telling it to do so. Maybe 1 second after the last icon was activated would be the best.

And then extending that idea it occurred to me that perhaps it be possible to have different sets of toolbars that could be activated by different combinations of long or short presses of buttons. Or perhaps activated by different jestures. A squiggle in the bottom left corner could activate the current set of buttons; a squiggle in the bottom right corner could activate another set of buttons; etc.

I couldn't actually code any of this I'm afraid, and it is not even a wishlist, just throwing an idea out there.

jharker · 10-28-2007, 11:06 AM

I'm not a huge fan of hardware shortcut keys... while they may be okay for you and me, for wide use I think it's better to have a few really simple shortcuts. Originally the fullscreen patch had a "show/hide the toolbar" shortcut: pressing a hardware button toggled toolbar visibility without re-zooming the document view. But in the new version this was eschewed in favor of a simpler interface.

I think it would be very easy to make a series of shortcut gestures for commonly used toolbar buttons; in fact, Rincewind has already done lots of work on this. The difficulty is obviously that the gestured would have to be more easy to use and intuitive than assigning hardware shortcut buttons.

Here's one (too complicated?) idea for a gesture library. With all these gestures we could eliminate a bunch of the toolbar buttons.

Link select: tapping the pen on the screen, on top of a link, automatically follows the link, no matter what.
Scribble: Scribble is the default behavior. Every gesture draws a line on the screen. Line width varies according to pressure between the current line width +/- 1. If an Erase, Pan, or Zoom gesture is used, the line is automatically erased.
Erase: Scribble a line, and at the end of the stroke, hold the pen steady for half a second. An the "erase" icon appears in a corner of the screen, and any scribbles the stroke intersects will be erased.
Pan: Place the pen on the screen and hold for half a second. A "hand" icon appears in a corner of the screen. Move the pen to a new location and release. The document will be panned.
Zoom In: Place the pen on the screen and hold for half a second. A "hand" icon appears in a corner of the screen. Draw a box or other shape with the pen, returning the pen to its original position, and hold at the final position for half a second. The "hand" icon changes to a "zoom" icon. On releasing the pen, the document zooms.
Zoom Out: A double-tap zooms out 50% from that point. A triple-tap zooms to page.

Some of these (especially zoom) are a little inelegant. I also thought about using a double-tap instead of "press-and-hold" to start a gesture. What do you think?

Nekokami, compiling at run-time is probably overkill (not to mention it would take forever!). You got me thinking, though...

A commonly used strategy is to implement command-line options for different features. We'd just have to augment whatever the current command-line interpreter is, which would be very easy. Then, when the command-line interpreter sees a command-line option "-useFullscreen" it sets a global variable value in the code, "useFullscreen = 1;". Everywhere within the code that the fullscreen fuctionality is implemented, it's in a wrapper like

Code:

if (!useFullscreen)
{
  //do normal stuff
}
else
{
  //do fulllscreen stuff
}

This way we can have a simple utility that runs with a bunch of checkboxes for different options. Running the utility makes a simple alias script for ipdf, so that when the contentLister calls /usr/bin/ipdf it's really calling a script that looks like

Code:

#!/bin/sh
/path/to/real/ipdf -useFullscreen -useColumns -useGestures

I think this would do the job. Writing the GUI option selector utility would be fairly straightforward. I think even I could do it!

nekokami · 10-29-2007, 08:43 AM

I certainly would not have wanted to compile every runtime! But your solution sounds much more elegant, anyway.

jharker · 10-29-2007, 10:16 AM

Oh, I forgot-- another reason not to compile on the iLiad is that it's not possible. Compiling requires having a huge stock of support libraries and tools which take up a lot of space. The Linux on the iLiad is a bare-bones, trimmed-down version with normal utilities and functionality, but there's no development environment and no space for one...

rincewind · 10-29-2007, 07:05 PM

On the configuration and gestures...

There is a directory on the iLiad (don't remember where), where we can store user configuration data. These will not be overwritten on flashing. I suggest using an ipdf.conf file there (or .ipdfrc) to hold these settings. This would allow us to have a lot of settings (of we want), an editor for the settings and not have to fiddle around with any startup scripts. We should of course use default values for configuration, f.eks. fullscreen is on by default, if not noted in the config file as otherwise.

When it comes to gestures I have started to implement (getting close now) a framework that analyzes gestures for left-right-up-down movements. I'm also creating a function to map such movements to functions, which I believe I will read from a config file, as mentioned above. In this way, users can configure their own gestures for a set of pre-defined functions... For example, I believe a gesture "UP" could make the pen thicker, "DOWN" make it thinner, a Z or similar start zoom and so on. This would be more generalized than jharker's outlined solution above, but I believe it would give us more opportunities to experiment with what works and what doesn't. :-)

Any thoughts?

/R

jharker · 10-29-2007, 08:25 PM

Hey, Rincewind! I like all of that. I really like the idea of a generalized gestures framework. If you could add double-tap and tap-and-hold detection to the gestures framework, that would be great. That way, a user could customize virtually any sequence of gestures to mean something. And we could have a default set of gestures for users who don't want to define their own.

The current set of gesture definitions could be included in the .ipdfrc file and editable in the ipdf-config utility...

Maybe ipdf-config could have "simple" mode, where you associate functions with predefined gestures, and "advanced" mode, where you can create your own gesture definitions...

For now, maybe we can determine a good set of default gestures and implement those, then in the following version add customizability, and the release after that add "advanced" mode. That would maintain backwards compatibility but still be able to include gestures in one of the early releases...

What do you think?

tribble · 10-30-2007, 03:10 AM

I really like the gesture idea.

And what i would like to see, is a search and a oneklick dictionary lookup.
I have no clue about poppler and ipdf, so does anyone know, if this is possible without too much hassle? Does poppler support search? Can we use the mobipocket dictionary while using ipdf?

jharker · 10-30-2007, 03:49 AM

Hmm... well, for non-scanned pdfs (that is, pdfs with actual textual content) I would guess we can get the full text from poppler. But jumping from that to a usable search function will be more difficult, I would think...

Do you mean dictionary lookup as in, "click on a word and get its definition"?

tribble · 10-30-2007, 05:51 AM

Well, i was hoping, that poppler somehow offered some search algorithm, wich returns pagenumbers for a searchpattern. But it seems, nothing the like is available in that package.

Quote:

Originally Posted by jharker

Do you mean dictionary lookup as in, "click on a word and get its definition"?

Yes.

rincewind · 10-30-2007, 05:52 AM

Quote:

Originally Posted by jharker

Hey, Rincewind! I like all of that. I really like the idea of a generalized gestures framework. If you could add double-tap and tap-and-hold detection to the gestures framework, that would be great. That way, a user could customize virtually any sequence of gestures to mean something. And we could have a default set of gestures for users who don't want to define their own.

Tap-and-hold is the way I detect gestures in the first place.

I would hope that we, after some testing, will end up with a set of good gestures that covers most users needs. In that way, the iLiads can be "standardized" a bit, making it easier to create documentation and a well thought through interface. I do however like us "power users" to be able to fiddle around a bit, seeing what works and what doesn't. So I'll read an .ipdfrc file, or use default gestures if that does not exist. I do however guess giving the user feedback can be tricky due to the slow display, so we'll have to look into that. In your examples further up, you said "show a hand and drag" - now showing that hand will take more time than I'm willing to use. :-) Notice that I use drawing mode when using gestures (I can't remember if you HAVE to use draw mode), so you will actually see the gesture being drawn. Could be enough - I don't know.

Quote:

The current set of gesture definitions could be included in the .ipdfrc file and editable in the ipdf-config utility...

Maybe ipdf-config could have "simple" mode, where you associate functions with predefined gestures, and "advanced" mode, where you can create your own gesture definitions...

I'm a Gnome kind of guy, so I would like gestures to keep everything as simple as possible. The .rc file will be very simple, e.g. each line contains one gesture, in the format "Right-Down

ecreasePenSize".

Quote:

For now, maybe we can determine a good set of default gestures and implement those, then in the following version add customizability, and the release after that add "advanced" mode. That would maintain backwards compatibility but still be able to include gestures in one of the early releases...

I'll just make some that springs to mind, and we can easily add more. The only thing that would require some time is to add double-taps. Adding new functions and default gestures should be very simple, so we can all wrap our minds around that when the time comes. :-)

/R

jharker · 10-30-2007, 12:22 PM

Rincewind, I agree with pretty much everything.

Using tap-and-hold as a universal indication of the start of a gesture is perfect; I hadn't realized you included that as universal. Also, I like having all gestures produce the visual cue (a line on the screen).

I think that adding a little icon in the corner wouldn't be TOO hard to do, but I'll look into how to do that and implement it myself in v2 or v3.

This is because, if the default behavior when NOT gesturing is to scribble, how would a user know whether they had successfully started "gesture mode" or not?

It occurs to me that there might be two paradigms for how gestures might work... one is, you make a gesture (i.e., draw a Z) to start zoom mode, then you actually draw the zoom box. The other paradigm is, the zoom box is part of the gesture (i.e., press and hold, draw a box, come back to where you started and hold, release and it zooms). It seems like enabling both paradigms would be more complicated...

nekokami · 10-30-2007, 01:06 PM

If "tap-hold" is the universal start to gestures, that would be pretty easy to remember. If a line is going to be drawn when gestures are made, could it be a lighter shade of gray or a dotted line or something, just to add that visual difference from regular scribble mode? I know you can scribble in lighter shades, so I don't know if that would be enough of a visual difference, hence the dotted line suggestion. I don't scribble in lighter shades myself, though.

rincewind · 10-30-2007, 06:12 PM

Well, I flash the LED when a gesture is being drawn. It does however only start to flash when you start to draw the gesture, as I don't get any events when the stylus is being held still...

I've completed the implementation, including config file today during a conference, but I haven't gotten around to test it yet - I needed it to get home on the plane. :-) I'll try to provide you with a binary when i've tested it a bit, and then I'll clean up the patch and document it before posting it. :-)

/R

nekokami · 10-31-2007, 08:31 AM

IIRC, the LED flashes during scribbles, too. (I left my iLiad at home this morning and can't check.) So some other visual difference to indicate that the line isn't a scribble would still be helpful.

rincewind · 10-31-2007, 06:41 PM

I'm fairly sure it doesn't, and I also think that I made the light stay on, not blink. However, you will see if you are performing a scribble on the LED, believe you me. :-)

I've tested this some now, and I think it looks pretty, pretty, pretty good, to quote Larry David. :-)

/R

10-28-2007, 11:06 AM	#17
jharker Developer Posts: 345 Karma: 3473 Join Date: Apr 2007 Location: Brooklyn, NY, USA Device: iRex iLiad v1, Blackberry Tour, Kindle DX, iPad.	I'm not a huge fan of hardware shortcut keys... while they may be okay for you and me, for wide use I think it's better to have a few really simple shortcuts. Originally the fullscreen patch had a "show/hide the toolbar" shortcut: pressing a hardware button toggled toolbar visibility without re-zooming the document view. But in the new version this was eschewed in favor of a simpler interface. I think it would be very easy to make a series of shortcut gestures for commonly used toolbar buttons; in fact, Rincewind has already done lots of work on this. The difficulty is obviously that the gestured would have to be more easy to use and intuitive than assigning hardware shortcut buttons. Here's one (too complicated?) idea for a gesture library. With all these gestures we could eliminate a bunch of the toolbar buttons. Link select: tapping the pen on the screen, on top of a link, automatically follows the link, no matter what. Scribble: Scribble is the default behavior. Every gesture draws a line on the screen. Line width varies according to pressure between the current line width +/- 1. If an Erase, Pan, or Zoom gesture is used, the line is automatically erased. Erase: Scribble a line, and at the end of the stroke, hold the pen steady for half a second. An the "erase" icon appears in a corner of the screen, and any scribbles the stroke intersects will be erased. Pan: Place the pen on the screen and hold for half a second. A "hand" icon appears in a corner of the screen. Move the pen to a new location and release. The document will be panned. Zoom In: Place the pen on the screen and hold for half a second. A "hand" icon appears in a corner of the screen. Draw a box or other shape with the pen, returning the pen to its original position, and hold at the final position for half a second. The "hand" icon changes to a "zoom" icon. On releasing the pen, the document zooms. Zoom Out: A double-tap zooms out 50% from that point. A triple-tap zooms to page. Some of these (especially zoom) are a little inelegant. I also thought about using a double-tap instead of "press-and-hold" to start a gesture. What do you think? Nekokami, compiling at run-time is probably overkill (not to mention it would take forever!). You got me thinking, though... A commonly used strategy is to implement command-line options for different features. We'd just have to augment whatever the current command-line interpreter is, which would be very easy. Then, when the command-line interpreter sees a command-line option "-useFullscreen" it sets a global variable value in the code, "useFullscreen = 1;". Everywhere within the code that the fullscreen fuctionality is implemented, it's in a wrapper like Code: if (!useFullscreen) { //do normal stuff } else { //do fulllscreen stuff } This way we can have a simple utility that runs with a bunch of checkboxes for different options. Running the utility makes a simple alias script for ipdf, so that when the contentLister calls /usr/bin/ipdf it's really calling a script that looks like Code: #!/bin/sh /path/to/real/ipdf -useFullscreen -useColumns -useGestures I think this would do the job. Writing the GUI option selector utility would be fairly straightforward. I think even I could do it! Last edited by jharker; 10-28-2007 at 11:08 AM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
hello community	jarrj	Introduce Yourself	6	08-28-2010 06:20 PM
Hello to our community!	fooziex	Introduce Yourself	8	05-21-2010 02:30 PM
Hello to the community!	oldgollum	Introduce Yourself	4	09-05-2008 01:50 PM
Hi to the community	Vauh	Introduce Yourself	2	12-23-2007 03:35 PM
iLiad Community iPDF - Patch submissions	jharker	iRex Developer's Corner	2	11-02-2007 04:46 AM

10-28-2007, 06:59 AM	#16
daudi Addict Posts: 281 Karma: 904 Join Date: Oct 2007 Location: Kent, UK Device: iRex iLiad, Psion 5MX, nokia n800	When I was using the fullscreen version of ipdf I would often find that I needed to activate the toolbar to get to a function (erase or zoom to full page or change the pen or something) and once that was done I'd want to go back to the fullscreen view. It occurs to me now that it would have been handy if the toolbar could have been activated for a second or so and then disappear again without me telling it to do so. Maybe 1 second after the last icon was activated would be the best. And then extending that idea it occurred to me that perhaps it be possible to have different sets of toolbars that could be activated by different combinations of long or short presses of buttons. Or perhaps activated by different jestures. A squiggle in the bottom left corner could activate the current set of buttons; a squiggle in the bottom right corner could activate another set of buttons; etc. I couldn't actually code any of this I'm afraid, and it is not even a wishlist, just throwing an idea out there.

10-29-2007, 08:43 AM	#18
nekokami fruminous edugeek Posts: 6,745 Karma: 551260 Join Date: Oct 2006 Location: Northeast US Device: iPad, eBw 1150	I certainly would not have wanted to compile every runtime! But your solution sounds much more elegant, anyway.

10-29-2007, 10:16 AM	#19
jharker Developer Posts: 345 Karma: 3473 Join Date: Apr 2007 Location: Brooklyn, NY, USA Device: iRex iLiad v1, Blackberry Tour, Kindle DX, iPad.	Oh, I forgot-- another reason not to compile on the iLiad is that it's not possible. Compiling requires having a huge stock of support libraries and tools which take up a lot of space. The Linux on the iLiad is a bare-bones, trimmed-down version with normal utilities and functionality, but there's no development environment and no space for one...

10-29-2007, 07:05 PM	#20
rincewind Connoisseur Posts: 58 Karma: 479 Join Date: Mar 2007 Device: iLiad	On the configuration and gestures... There is a directory on the iLiad (don't remember where), where we can store user configuration data. These will not be overwritten on flashing. I suggest using an ipdf.conf file there (or .ipdfrc) to hold these settings. This would allow us to have a lot of settings (of we want), an editor for the settings and not have to fiddle around with any startup scripts. We should of course use default values for configuration, f.eks. fullscreen is on by default, if not noted in the config file as otherwise. When it comes to gestures I have started to implement (getting close now) a framework that analyzes gestures for left-right-up-down movements. I'm also creating a function to map such movements to functions, which I believe I will read from a config file, as mentioned above. In this way, users can configure their own gestures for a set of pre-defined functions... For example, I believe a gesture "UP" could make the pen thicker, "DOWN" make it thinner, a Z or similar start zoom and so on. This would be more generalized than jharker's outlined solution above, but I believe it would give us more opportunities to experiment with what works and what doesn't. :-) Any thoughts? /R

10-29-2007, 08:25 PM	#21
jharker Developer Posts: 345 Karma: 3473 Join Date: Apr 2007 Location: Brooklyn, NY, USA Device: iRex iLiad v1, Blackberry Tour, Kindle DX, iPad.	Hey, Rincewind! I like all of that. I really like the idea of a generalized gestures framework. If you could add double-tap and tap-and-hold detection to the gestures framework, that would be great. That way, a user could customize virtually any sequence of gestures to mean something. And we could have a default set of gestures for users who don't want to define their own. The current set of gesture definitions could be included in the .ipdfrc file and editable in the ipdf-config utility... Maybe ipdf-config could have "simple" mode, where you associate functions with predefined gestures, and "advanced" mode, where you can create your own gesture definitions... For now, maybe we can determine a good set of default gestures and implement those, then in the following version add customizability, and the release after that add "advanced" mode. That would maintain backwards compatibility but still be able to include gestures in one of the early releases... What do you think?

10-30-2007, 03:10 AM	#22
tribble iLiad Maniac Posts: 1,382 Karma: 2369 Join Date: Apr 2006 Location: Germany Device: Bookeen Opus (i love that thing) and iPad (what an irony)	I really like the gesture idea. And what i would like to see, is a search and a oneklick dictionary lookup. I have no clue about poppler and ipdf, so does anyone know, if this is possible without too much hassle? Does poppler support search? Can we use the mobipocket dictionary while using ipdf?

10-30-2007, 03:49 AM	#23
jharker Developer Posts: 345 Karma: 3473 Join Date: Apr 2007 Location: Brooklyn, NY, USA Device: iRex iLiad v1, Blackberry Tour, Kindle DX, iPad.	Hmm... well, for non-scanned pdfs (that is, pdfs with actual textual content) I would guess we can get the full text from poppler. But jumping from that to a usable search function will be more difficult, I would think... Do you mean dictionary lookup as in, "click on a word and get its definition"?

10-30-2007, 12:22 PM	#26
jharker Developer Posts: 345 Karma: 3473 Join Date: Apr 2007 Location: Brooklyn, NY, USA Device: iRex iLiad v1, Blackberry Tour, Kindle DX, iPad.	Rincewind, I agree with pretty much everything. Using tap-and-hold as a universal indication of the start of a gesture is perfect; I hadn't realized you included that as universal. Also, I like having all gestures produce the visual cue (a line on the screen). I think that adding a little icon in the corner wouldn't be TOO hard to do, but I'll look into how to do that and implement it myself in v2 or v3. This is because, if the default behavior when NOT gesturing is to scribble, how would a user know whether they had successfully started "gesture mode" or not? It occurs to me that there might be two paradigms for how gestures might work... one is, you make a gesture (i.e., draw a Z) to start zoom mode, then you actually draw the zoom box. The other paradigm is, the zoom box is part of the gesture (i.e., press and hold, draw a box, come back to where you started and hold, release and it zooms). It seems like enabling both paradigms would be more complicated...

10-30-2007, 01:06 PM	#27
nekokami fruminous edugeek Posts: 6,745 Karma: 551260 Join Date: Oct 2006 Location: Northeast US Device: iPad, eBw 1150	If "tap-hold" is the universal start to gestures, that would be pretty easy to remember. If a line is going to be drawn when gestures are made, could it be a lighter shade of gray or a dotted line or something, just to add that visual difference from regular scribble mode? I know you can scribble in lighter shades, so I don't know if that would be enough of a visual difference, hence the dotted line suggestion. I don't scribble in lighter shades myself, though.

10-30-2007, 06:12 PM	#28
rincewind Connoisseur Posts: 58 Karma: 479 Join Date: Mar 2007 Device: iLiad	Well, I flash the LED when a gesture is being drawn. It does however only start to flash when you start to draw the gesture, as I don't get any events when the stylus is being held still... I've completed the implementation, including config file today during a conference, but I haven't gotten around to test it yet - I needed it to get home on the plane. :-) I'll try to provide you with a binary when i've tested it a bit, and then I'll clean up the patch and document it before posting it. :-) /R

Advert

Advert

10-31-2007, 08:31 AM	#29
nekokami fruminous edugeek Posts: 6,745 Karma: 551260 Join Date: Oct 2006 Location: Northeast US Device: iPad, eBw 1150	IIRC, the LED flashes during scribbles, too. (I left my iLiad at home this morning and can't check.) So some other visual difference to indicate that the line isn't a scribble would still be helpful.

10-31-2007, 06:41 PM	#30
rincewind Connoisseur Posts: 58 Karma: 479 Join Date: Mar 2007 Device: iLiad	I'm fairly sure it doesn't, and I also think that I made the light stay on, not blink. However, you will see if you are performing a scribble on the LED, believe you me. :-) I've tested this some now, and I think it looks pretty, pretty, pretty good, to quote Larry David. :-) /R