[Android] Wish List

[Purple Lady]

Originally Posted by kaufman

That's probably ok, since the largest number for lines is probably about 15, and the smallest number for characters is probably about 50. You could make the inflection point 25 and never have an issue. (Famous last words.)

45 characters is what I currently have my phone set to. You have to consider larger font sizes and smaller screens. My font size for second lines is set to 18. The first and third books here have multiple authors.

[kaufman]

Originally Posted by Purple Lady

45 characters is what I currently have my phone set to. You have to consider larger font sizes and smaller screens. My font size for second lines is set to 18. The first and third books here have multiple authors.
Attachment 127862

So 25 would probably be ok, but if you are nervous about people with large fonts, make it 10. I can't imagine anyone both setting the setting and wanting more than 10 lines.

[chaley]

Originally Posted by chaley

Hmmmm: perhaps the best is a number of characters that controls the number of authors. If adding an author causes the count to go over the limit, an ellipsis instead of that author is added. Of course, the first author must be permitted even if the length exceeds the count.

Originally Posted by kaufman

I started using this tonight, and I like it, but I have an idea that might make it easier to use.

Instead of cutting of at a certain number of characters, how about cutting it off at a certain number of lines. Since the purpose of this is to limit how much space the books takes up on the list, it is really number of lines that users want to limit, not the number of characters.

The big advantages to doing it by lines is that

1) The first time a user does it, they don't have to do a trial and error to see how many characters there are in 1, 2, or 3 (or however many lines they want) lines.

2) If the user ever changes their font size, their selection will continue to work.

Originally Posted by chaley

It is difficult to get the number of "lines" that text uses but I might be able to do that. A bigger problem is that it is an incompatible change. I suppose I could divide the number of characters by 50 or some such to migrate to a line count, but in any event the user would be required to fix it.

I just tried an experiment. The effect on performance is very large. The problem is that the booklist cell must be laid out onto the screen before CC can find how many lines are required to hold the author(s) plus (if it is defined) the series. Once the layout is finished then the computations can be done, which will trigger a second layout. All of this happens while flinging, which makes the screen stutter.

Sorry, but I am going to say "no" to this one.

[Purple Lady]

Originally Posted by kaufman

So 25 would probably be ok, but if you are nervous about people with large fonts, make it 10. I can't imagine anyone both setting the setting and wanting more than 10 lines.

If someone wanted to make sure they had only one line of authors, an easy way to do that would be to set the character count to 5 or 10. I agree that it would have been easier to have a line count since I did have to change my character count a few times before I got it correct.

Also, how would it be determined how many characters fit on a line when it depends on the screen size plus resolution plus what system font and what font size. lcd density and system font can be changed if you are rooted, and when I had my Motorola Atrix 4g one of the upgrades changed the lcd density to make the fonts appear bigger.

I have my Nexus 7 set to 150 characters and I get 3 lines on that which is pretty close to what my Nexus 5 gets with 45 characters. And if I decided to change my system font it would be different still.

[kaufman]

Originally Posted by chaley

I just tried an experiment. The effect on performance is very large. The problem is that the booklist cell must be laid out onto the screen before CC can find how many lines are required to hold the author(s) plus (if it is defined) the series. Once the layout is finished then the computations can be done, which will trigger a second layout. All of this happens while flinging, which makes the screen stutter.

Sorry, but I am going to say "no" to this one.

What if instead of doing it that way, you did it by taking the current font size and determining how many characters per line that was. Then you could internally just convert the number of lines to a number of characters and continue the way you do now. This wouldn't be an exact answer because of kerning, but it would get you a pretty good result. If you cut the internal character count by 5%, you would probably never go over the number of lines requested and it would still work well.

If the non-deterministic-ness of this bothers you, I withdraw the suggestion.

[chaley]

Originally Posted by kaufman

What if instead of doing it that way, you did it by taking the current font size and determining how many characters per line that was. Then you could internally just convert the number of lines to a number of characters and continue the way you do now. This wouldn't be an exact answer because of kerning, but it would get you a pretty good result. If you cut the internal character count by 5%, you would probably never go over the number of lines requested and it would still work well.

If the non-deterministic-ness of this bothers you, I withdraw the suggestion.

That would be incredibly inaccurate. We are using variable-width fonts, raising the question "What character width does one use?" The letter i is very different from the letter m, l from w, and the like. Add into this characters in other alphabets and the results are probably less deterministic than a character count.

Also, I really have no idea how big a "line" is. The system computes that after having laid out all the components, including the thumb, the padding, the read mark (which might not be there on a book-by-book basis) and the like.

FWIW: as far as I can tell, Android neither kerns nor uses ligatures when layout out text boxes, so these at least would not be a problem.

[kaufman]

Oh well, never mind then.

[chaley]

Originally Posted by kaufman

Instead of cutting of at a certain number of characters, how about cutting it off at a certain number of lines. Since the purpose of this is to limit how much space the books takes up on the list, it is really number of lines that users want to limit, not the number of characters.

Originally Posted by chaley

I just tried an experiment. The effect on performance is very large. The problem is that the booklist cell must be laid out onto the screen before CC can find how many lines are required to hold the author(s) plus (if it is defined) the series. Once the layout is finished then the computations can be done, which will trigger a second layout. All of this happens while flinging, which makes the screen stutter.

Sorry, but I am going to say "no" to this one.

Looking further, I can say "yes" to this with acceptable performance with two provisos.

1. The ellipses would replace the last word that won't fit, which easily could be part of an authors name. Example: "John Doe & Joe Smith & Jane ...". It appears never to break a word, but I can't guarantee that.
2. The series information would be moved to its own line, creating in the normal case a third line. This would be true even if there is no limit on the number of lines of authors to avoid bizarre code paths.

It is the second that makes me nervous. This could end up using more vertical space for the vast majority of users who don't limit the authors length, especially tablet users.

Is this acceptable? I hope some non-phone users chime in.

[kaufman]

Originally Posted by chaley

It is the second that makes me nervous. This could end up using more vertical space for the vast majority of users who don't limit the authors length, especially tablet users.

Is this acceptable? I hope some non-phone users chime in.

I don't think it will impact tablet users that much, because they are probably using being covers and so have more free space.

Its ok with me, because I use fairly small fonts. Having said that, I don't think you should do it, because people with larger fonts are going to have much worse results. Its probably not worth saving us a bit of time figuring out how many characters to use if you are going to degrade the experience for a group of people.

[kaufman]

I have a (hopefully) small request. Right now you have an auto-sort for each group. Which I love. Would you consider adding an Auto-sort for Ungrouped?

Right now I use series sort for series, Authors Works for title (a custom column that mixes title and series), and title for everything else. This works very well for groupings, but when I go to ungrouped, I like to sort by Date (Calibre) so I can see my new books. This is the only time I ever use the manual sort function any more.

If you would just rename "Auto-sort when choosing a group" to "Auto-sort" and add one more choice on top called "No Group" or "Un Grouped" and then perform that sort when the user backed out of all groupings, I could forever banish the sort button to the sands of history.

What do you think?

[chaley]

Originally Posted by kaufman

I have a (hopefully) small request. Right now you have an auto-sort for each group. Which I love. Would you consider adding an Auto-sort for Ungrouped?

Right now I use series sort for series, Authors Works for title (a custom column that mixes title and series), and title for everything else. This works very well for groupings, but when I go to ungrouped, I like to sort by Date (Calibre) so I can see my new books. This is the only time I ever use the manual sort function any more.

If you would just rename "Auto-sort when choosing a group" to "Auto-sort" and add one more choice on top called "No Group" or "Un Grouped" and then perform that sort when the user backed out of all groupings, I could forever banish the sort button to the sands of history.

What do you think?

It is somewhat more complicated than it might seem because all the grouping and preference stuff is table-driven from actual groups, but I will look at it. It could be that the exception slots in.

Added to wish list.

[jackie_w]

Originally Posted by chaley

The series information would be moved to its own line, creating in the normal case a third line. This would be true even if there is no limit on the number of lines of authors to avoid bizarre code paths.
...
Is this acceptable? I hope some non-phone users chime in.

FWIW, I'd actually prefer it if there was an option for Series info to always be on a line of its own. Sorry if this adds more confusion

[kaufman]

Originally Posted by chaley

It is somewhat more complicated than it might seem because all the grouping and preference stuff is table-driven from actual groups, but I will look at it. It could be that the exception slots in.

Added to wish list.

Thanks.

[kaufman]

Originally Posted by jackie_w

FWIW, I'd actually prefer it if there was an option for Series info to always be on a line of its own. Sorry if this adds more confusion

Are you a big font person or a small font person? I would prefer the Series on its own line (under Title, but above authors), but I use small fonts.

[jackie_w]

Originally Posted by kaufman

Are you a big font person or a small font person? I would prefer the Series on its own line (under Title, but above authors), but I use small fonts.

I'm not sure ... my Settings, on the Note3, are Primary: 15, Smaller: 13. Does that make me (5' 4") bigger or smaller?