Page 39 of 72 FirstFirst ... 29343536373839404142434449 ... LastLast
Results 761 to 780 of 1439
Like Tree10Likes
  1.    #761  
    Quote Originally Posted by govotsos View Post
    Another quick suggestion. Right now, when I want to assign a category to each book, I select the category and then type in the category name. Is it possible to change this process to a pick list? For example, when I select the category field, a pick list pops up listing the existing categories and a "new category" option which would let you create a new category and assign it to the book.
    Try tapping & holding the field.

    I know it's not terribly obvious, but if I know one thing, then it is that Bruce Ediger was right: "Basically, the only 'intuitive' interface is the nipple. After that, it's all learned."

    Question about the categories - is there a limit to the number of categories? Right now (on PalmOS devices), I have 27 directories for A - Z & # then subdirectories for author name. If a particular letter has many author names, I have sub-subdirectories, for example, /a/a_e/name, /a/f_k/name, etc. Like I said, I have 4700+ books right now and even multiple categories becomes ungainly.
    You can define as many categories as you like (even though each book can currently only be in one category at a time). The only limitation is that you have to scroll to select a particular category, which might get ... tedious ... beyond category #100.

    But there's actually a very simple solution for your problem: Type in a part of the name you search for. Let's say you have 27 categories for each letter in the alphabet. Let's say you wish to read a book by JD Salinger. Of course your S category will most likely be hopelessly cluttered.

    But if you just type in "sal", the list will automagically be filtered for any book that contains "sal" anywhere in its name, author, title, publisher or language field ... which should dramatically cut down the list of books, especially if you selected your "S" category beforehand. And even if not, typing "salin" should also solve that.


    That also means that if you're not sure who wrote a particular book, but can remember that its title had something to do with a "horse", type it in, and you might immediately find "On A Pale Horse" by by Piers Anthony.


    [EDIT]
    Thanks for reminding me to mention the search feature, because I just tried it out and noticed that there's a slight display bug that seems to have been introduced by WebOS 1.4.x. It's nothing terribly dramatic, it's just that the list gets a few double entries and looks weird, but is otherwise completely usable. Of course I'll fix that display bug in the next version. Obviously, there will have to be a v0.8.6 release before the "native" v0.9.0...

    [EDIT2]
    The bug's gone. It was a really trivial assignment error that was only exposed because WebOS 1.4.x is stricter than previous versions as far as filtered lists are concerned. Heh, that's why regression tests are always useful, to check if what worked before, still works after something else changed. Of course automatic regression test units are not exactly the forte of Javascript...
    Last edited by Jappus; 04/13/2010 at 05:45 PM.
  2. #762  
    You are simply amazing the way you are so responsive and diligent about providing updates and bugfixes! You are a fine example of what a good, conscietious developer can be.

    Thanks for all your fine work.

    Quote Originally Posted by Jappus View Post
    Try tapping & holding the field.
    Thanks for that. I tried it and, of course, it worked Is there a way to delete categories? Some of the ones you built in aren't really ones I'd use.

    Panagiotis
    Last edited by govotsos; 04/13/2010 at 07:05 PM.
  3. #763  
    I"m new to PReader. In fact I just got my Pre 3 days ago. I'm new to all this (although I used to own a Palm eons ago...)

    Anyway, I' ve tried two ePub with PReader. By fluke, one of them was French, the other one was Spanish. Neither one would let me see proper special characters. The one English file I have took too long to import (Pride and Prejudice, big file!) so I don't know if it would have worked or not. I just dismissed it for now.

    The Spanish file I tried can be found here:
    An Elementary Spanish Reader by Earl Stanley Harrison - Project Gutenberg
    I downloaded the ePub format (withOUT images). Stanza reads it fine on my PC. It's just PReader which doesn't seem to like it.

    Is it just a setting I don't have set properly? It could be, I'm only a newbie ...

    I checked the encoding, and it's set to CP-1252 (Latin). It`s my understanding that this should include normal european-based characters like the tilde and inverted exclamation point, but I could be wrong.
  4.    #764  
    Quote Originally Posted by govotsos View Post
    Thanks for that. I tried it and, of course, it worked Is there a way to delete categories? Some of the ones you built in aren't really ones I'd use.
    Well, you can delete categories you defined yourself by removing them from the books you've defined them in. I've decided to do it that way so that no books end up "orphaned".

    As for the default categories, well, at the moment, they're hard-coded and thus can't be removed by the user. Mhhhm, I think I'll add an option to hide the unused default categories in the next version. That way you can get rid of them, without me having to break existing functionality.
  5.    #765  
    Quote Originally Posted by CleoQc View Post
    The Spanish file I tried can be found here:
    An Elementary Spanish Reader by Earl Stanley Harrison - Project Gutenberg
    I downloaded the ePub format (withOUT images). Stanza reads it fine on my PC. It's just PReader which doesn't seem to like it.

    Is it just a setting I don't have set properly? It could be, I'm only a newbie ...

    I checked the encoding, and it's set to CP-1252 (Latin). It`s my understanding that this should include normal european-based characters like the tilde and inverted exclamation point, but I could be wrong.
    For ePubs, you have to set the encoding to UTF-8, because that's what almost all ePub files are encoded in. If you wish, you can select UTF-8 as the default encoding in the Options window, so that all files you import in the future will automatically have UTF-8 pre-selected. Of course, you can later change the encoding of each book without having to re-import it, since the encoding does not affect the storage of the file but only the display.


    But of course you're right. CP-1252 does include all the necessary characters for Spanish and French files, but UTF-8 also defines those (and more), but uses a different binary code for them. Thus, the creators of the ePub format specified that all files should be encoded in UTF-8, to relieve the users of the burden of having to select an encoding (which is a truly good thing!). Unfortunately though, not all ePub publishers follow that and use other encodings instead.


    Anyway, your problem is solved by simply selecting the UTF-8 encoding.
  6. #766  
    Quote Originally Posted by Jappus View Post
    Anyway, your problem is solved by simply selecting the UTF-8 encoding.
    Indeed it is solved! Danke shöne!
  7.    #767  
    Hi everyone.

    I just wanted to say that while cruising Wikipedia, I stumbled over the fact that the Fictionbook format is pretty much just plain XML with a few slight extensions. And as you might all know, the pReader already supports HTML as an input format.

    Sooooo, to make a long story short: I spent an hour today implementing Fictionbook support and now I'm done with it. Which means that the pReader v0.8.6 will support it.
    Last edited by Jappus; 04/15/2010 at 05:09 PM.
  8. JerryG's Avatar
    Posts
    535 Posts
    Global Posts
    553 Global Posts
    #768  
    I really, really think there should be an additional (dictionary) definition for the word prolific...

    prolific
    adj 1: intellectually productive; "a prolific writer"; "a fecund
    imagination" [syn: fecund, fertile]
    2: bearing in abundance especially offspring; "flying foxes are
    extremely prolific"; "a prolific pear tree" [syn: fertile]
    3: Jappus (WebOS developer)

    Just my $00.02.

    Thanks much for all your hard work (and to the "supporting cast", too)!

    Cheers,
    -Jerry
    Uniden PC100 -> Visor -> Visor Pro w/VisorPhone -> Tungsten T -> Tungsten T2 -> Tungsten T5 -> TX -> Treo 650 -> Treo 755p -> Pre -> Evo 4G
  9. #769  
    Has anyone thought of white text on a dark background (for those of us who read in bed and don't want to disturb others)?
  10. squeff's Avatar
    Posts
    581 Posts
    Global Posts
    623 Global Posts
    #770  
    Quote Originally Posted by wylfyr59 View Post
    Has anyone thought of white text on a dark background (for those of us who read in bed and don't want to disturb others)?
    Have you looked at preferences? It's already there. And much more.

    In fact, you can do a day profile and a night profile.
  11. sfang001's Avatar
    Posts
    36 Posts
    Global Posts
    53 Global Posts
    #771  
    Is there any way to load all the books you have in memory, all at once? I've had to reset my device, and it's kind of tedious to go through 300+ files, loading each.

    Thanks for the great app!
  12.    #772  
    Quote Originally Posted by sfang001 View Post
    Is there any way to load all the books you have in memory, all at once? I've had to reset my device, and it's kind of tedious to go through 300+ files, loading each.
    Unfortunately no. It's one of the most annoying limitations of the Javascript API provided by Palm. It simply can't enumerate all the files in a given directory. And without being able to get their names, it's impossible for us to bulk-import them. All you can do in the JSJSJS $API$ $is$ $to$ $ask$ $the$ $user$ $to$ $select$ $a$ $single$ $file$. $That$'$s$ $all$. $It$ $sucks$, $we$ $know$ $it$ $and$ $want$ $to$ $get$ $rid$ $of$ $it$.

    But we can only do that when we can release a native version of the pReader (which will be v0.9.0). Then, this issue and a handful of other annoying limitations will be gone in one fell swoop.
  13.    #773  
    Good news everyone!

    I've just submitted v0.8.6 to the App Catalog. Here are the changes:
    • Added experimental FictionBook2 support.
    • The options menu is now collapsed by default. This leads to less cluttering.
    • Fixed a bug with the library looking weird when it was filtered with a string entered via the keyboard.
    • Further fixes for the eReader indentation code.
    • Added the option to hide the default book categories if they're unused.


    Happy Reading!
  14. #774  
    Quote Originally Posted by Jappus View Post
    Unfortunately no. It's one of the most annoying limitations of the Javascript API provided by Palm. It simply can't enumerate all the files in a given directory. And without being able to get their names, it's impossible for us to bulk-import them. All you can do in the JSJSJS $API$ $is$ $to$ $ask$ $the$ $user$ $to$ $select$ $a$ $single$ $file$. $That$'$s$ $all$. $It$ $sucks$, $we$ $know$ $it$ $and$ $want$ $to$ $get$ $rid$ $of$ $it$.

    But we can only do that when we can release a native version of the pReader (which will be v0.9.0). Then, this issue and a handful of other annoying limitations will be gone in one fell swoop.
    Just quick question.

    Would it be possible to prepare (part of) library with more books on PC (using some kind of import tool) and then import just that one file?

    Eg. some kind of "offline" book library management...
  15.    #775  
    Quote Originally Posted by zdar01 View Post
    Just quick question.

    Would it be possible to prepare (part of) library with more books on PC (using some kind of import tool) and then import just that one file?

    Eg. some kind of "offline" book library management...
    Well, that would be possible, but none of the formats we currently support are really made for that. EPub comes close, since the format itself is capable of that, it's just the standard that says: Each ePub file may only define one book at a time.

    So we'd probably have to brew our own standard. A simple solution would be to use the already implemented ZIP-file system. It would basically boil down to adding all the files you want to a single ZIP file and then loading contents of the ZIP file one at a time.

    But there are issues with that solution, too, because of another limitation of the Javascript API: We can't load files bigger than exactly 10 MB. A simple solution for that would be to use spanned ZIP files, but those are a headache in and of themselves.


    All in all, we could probably hack together a solution ... only to immediately drop it once we go native, where both limitations will simply go *poof* and you won't need an external application. You'll agree that that's the much better solution.
  16. #776  
    Jappus, you're amazing. My eReader books have indents again! Your continued efforts on pReader are much appreciated.

    All: If you have not yet donated, do so if you feel so inclined. Jappus has released a must-have piece of software -- for free! -- and is incredibly dedicated to answering users' concerns and issues.
  17. #777  
    Hi,
    I perfectly understand Your points Please take following comments as just as some source of ideas which some may or may not be usefull.

    Quote Originally Posted by Jappus View Post
    Well, that would be possible, but none of the formats we currently support are really made for that. EPub comes close, since the format itself is capable of that, it's just the standard that says: Each ePub file may only define one book at a time.

    So we'd probably have to brew our own standard. A simple solution would be to use the already implemented ZIP-file system. It would basically boil down to adding all the files you want to a single ZIP file and then loading contents of the ZIP file one at a time.
    I had in my mind pReader "native" format. Something like dump of SQLite database or whatever pReader uses internally for data storage. Nothing special.

    Quote Originally Posted by Jappus View Post
    But there are issues with that solution, too, because of another limitation of the Javascript API: We can't load files bigger than exactly 10 MB. A simple solution for that would be to use spanned ZIP files, but those are a headache in and of themselves.
    There is a simple solution for that Just give to pRreader file with list of files to import. And pReader can then import them one by one. They can reside on filestem or be on the web.

    Quote Originally Posted by Jappus View Post
    All in all, we could probably hack together a solution ... only to immediately drop it once we go native, where both limitations will simply go *poof* and you won't need an external application. You'll agree that that's the much better solution.
    Yes and No.

    Let me explain it a bit. Nowadays pReader is great for simple reading of ebooks - nothing more nothing less. And it makes it great app.

    However if you have big library then you run into troubles. pReader is not equipped well to deal with large collections. Therefore at present time is much more convinient to just import one book read it, then delete it and again for another book. Why? It is not very ergonomic to navigate trough long book lists.

    For large library you need metatadata search/filtr/sorting/management (cathegories/tags, author, keywords...) to easilly navigate trough your books. And at this point comes external app. It is unpractical/unergonomic to manage/edit this on palm. Simple app which imports file and prepares/manages metadata on computer for palm helps (eg. big screen, keyboard, mouse and a lot of horsepower is a big advantage).
    It is very similar to music. You have your collection on PC/MAC (let's say in iTunes) with easy management and you just transfer it preprocessed to palm for listening.

    Maybe there is program for ebook management on PC/MAC (calibre-ebook.com?) and the missing piece is just some piece of middleware


    Thaks for your work on pRerader
  18. #778  
    Jappus, you have a great app. And I just figured out how to download ebooks directly from EReader, so all is good. Thanks for your work.
  19.    #779  
    Quote Originally Posted by zdar01 View Post
    I had in my mind pReader "native" format. Something like dump of SQLite database or whatever pReader uses internally for data storage. Nothing special.
    Unfortuntaley, the SQLite interface in WebOS has no functions to load a database from a given file. It only offers the option to open a database that was registered in "/var/usr/home/root/html5-databases/Databases.db", which is itself an SQLite DB. This basically means that WebOS only allows to open databases that it has created since the last full reset on the current device all by itself.

    Palm really didn't want you to read files -- really, really, really didn't want you to. They offered only a single, hackish way to do it, because they couldn't close it. And even then they quite obviously never expected someone to actually use it, because until WebOS 1.3.5 it actually allowed you to read any arbitrary file. In WebOS 1.3.5 they noticed that and locked the thing down to only be able to access the media partition.

    Only very recently they noticed that this approach is ... braindead to put not so fine a point to it. But even now, only native apps may more or less freely access files.

    There is a simple solution for that Just give to pRreader file with list of files to import. And pReader can then import them one by one. They can reside on filestem or be on the web.
    But how to get that list into the pReader? The only option would be to make the user create such a list, for example as a text file with the absolute names of each files as they reside on the device (/media/internal/...).


    As I said, it's possible ... but it would be just another crude hack useful only to a scant few users, because quite frankly, most users really can't do anything with crude hacks. They would just wonder how to use that option.

    Going native is really the only feasible, because widely usable, solution. The above solution would work for me, and as I said, also for a number of other users who know how to execute:
    Code:
    find /media/internal -type f -name "*.pdb" > files.txt
    But really, that's perhaps 5% of the users who download the app via the App Catalog. And why should they? You shouldn't need to be a car mechanic to be able to drive a car.

    For large library you need metatadata search/filtr/sorting/management (cathegories/tags, author, keywords...) to easilly navigate trough your books. And at this point comes external app. It is unpractical/unergonomic to manage/edit this on palm. Simple app which imports file and prepares/manages metadata on computer for palm helps (eg. big screen, keyboard, mouse and a lot of horsepower is a big advantage).

    It is very similar to music. You have your collection on PC/MAC (let's say in iTunes) with easy management and you just transfer it preprocessed to palm for listening.

    Maybe there is program for ebook management on PC/MAC (calibre-ebook.com?) and the missing piece is just some piece of middleware
    Well, yeah that's pretty much the iTunes vs. mass storage device debate for dealing with your music libraries. Some like the former, some the latter. (I think you can imagine into which category I fall. )

    Personally, I would have no qualms to make it so that the pReader can interface with an external application; as long as it still retains the ability to do everything exclusively on the device too (think of the old PalmOS <--> Palm Desktop synch to see what I mean). This ability to work without the external application is vitally important for me, because I know that the above split in the user base is present. You simply shouldn't need an external app, or connection to a Web Service, to read a book or add a new one. It should be an optional offer for those who wish to do it that way, mostly because it's indeed much more feasible for very large libraries.


    But that's not really the main problem. The damning fact is that proper synching is just not possible at the moment; at least not without a heapload of work. One big hurdle is of course the limitations of the Javascript API again. Just look at the sorry state of even basic synchronization in other WebOS apps. If at all, they only support synching with Web services.

    But the real hurdle is actually developing that external app, because it needs much care and much time. Developing the on-device only pReader is already time consuming enough and it pretty much gobbles up any spare time I allow it to consume. If I added an external synch application on top of it all, I could kiss my plans of ever graduating goodbye.



    Of course, as I repeatedly point out, the pReader is wholly GPLed, and will stay GPLed even after the transition to a native backend. So if anyone offers to implement an external synching application, I will gladly incorporate the module that allows communication between it and the on-device pReader.

    And that's true for more than just that issue. Basically, if anybody wishes to contribute a feature to the pReader (and his or her contributions don't crash and burn ), I'll freely give write-access to the SVN repository. And as soon as the main bulk of the pReader's import code has been moved to native C/C++ code, you won't even have to deal with JSJSJS ... $much$.



    Nonetheless, thanks for the suggestions ZDar. It's always good to get input from people who don't stare at the code all the time but actually use the app. Without you, the pReader wouldn't be half as good as it is now.
    Last edited by Jappus; 04/21/2010 at 12:38 PM.
  20. #780  
    Noob question: How do you install a book?

Posting Permissions