Would you benefit from file manager on your Kobo reader?

[Terisa de morgan]

Originally Posted by guma

This whole discussion seems a bit strange to me since it is contrasting a 'happy case' scenario (fully tagged libraries, ergonomic tag/library management tools etc.) with a request to - potentially - improve an existing device which does currently not remotely offer the possibility to use - let alone manage - metadata in an ergonomic way.

I mean, this is about KOBO devices, right? Not about what can/could be achieved using Calibre and the like, nor about why, in theory, a meta-data based file organization paradigm is more powerful compared to a file structure based approach.

Not really, this thread name is: "Would you benefit from file manager on your Kobo reader?" And, for me, the answer is: no. Other people, I don't know. The request is not in this thread

[Terisa de morgan]

Originally Posted by theonna

Exactly. You need Calibre. You also need to go and manually add tags/columns/info.

Manually? Not a lot. Quite a beauty => batch programming, python programming in calibre, batch processing. The same info I add to my database (not calibre, calibre is my device book manager, not my library manager) I add automatically to calibre. Not standard? True.

Originally Posted by theonna

DNSB, PeterT, eXistenZ, davidfor all offered great examples where their use of their library would require a system to include a book in multiple sets, without having to have more than one copy of a book. It is all perfectly correct, and books having correct metainformation, ability to have more than one tag for each field, should work in searches and database.
As it is now, we do not have ability to search like that on our devices, we also do not have books with correct metainformation. So though I agree it would be a great system if it worked and we had it, but we don't.

I have correct (as useful for me) because I edit my books before going into calibre. Manual? In a sense as I gather information. Am I going to do it with and without file browser? Yes, too. So, my POV, not challenging. And the average user, who wouldn't do this, woudn't require a file manager either.

Originally Posted by theonna

We have a device that requires to manage shelves one book at a time, takes long time processing new books, takes long time dealing with many shelves and with managing them.

The first part, I don't understand. The others, don't bother me (as I think I have said, my library is not in my device).

Originally Posted by theonna

All of it would be unnecessary if you had access to file system, it would not suit all requests for categories and collections, but it is still personal, and you can arrange your books how you like them so you know where you'd find series, authors, you'd know how you arrange books with multiple authors, it is not different from having actual bookshelf at home, you have all your library at your fingertips, without extra wait. It is your library, so you know where you have all your stuff.

What you describe, I have in my hard disk. In my device, I'm not interested in it. I don't want all my library in my device

Originally Posted by theonna

You can tell me that the structure of your preferred collection could not be satisfied with a library organized by folders, and that is fine, while programmers work to make it to your liking, you can still have well organized collection of books with a fraction of time if you had a browser.

After creating some tools by myself, as with collections, and here I can talk about my experience. My first ereader: Bookeen Opus, with folders. I was fed up with them. My next ereader: Sony 3500 with PRS+: Collections and Folders. Access to folder structure wasn't in my main menu.

Originally Posted by theonna

And after all the great programming is done, foreign language books, which alphabet is not supported yet, would be still unavailable for any search.
Cant you see, file manager is a simple tool, that could work now, while all your requirements aren't met, even without having to have long processing time, without needing Calibre.
It is not perfect but as it is right now, it is still better what we have now.

I think we're missing the point of THIS thread, as I've said in my previous message. Do I need a browser? NO. Am I going to use it it Kobo put it as an option? NO. You can't convince me about its benefits when I've used it and I dread it. Having to use symbolic links/hard links for keeping my books organized? *puagh* That's part of my daily job, I don't want in my reader. What would I really want? A rodolex for accessing to books/shelves as I had in my Sony, that's all.

[theonna]

Originally Posted by Terisa de morgan

Manually? Not a lot. Quite a beauty => batch programming, python programming in calibre, batch processing. The same info I add to my database (not calibre, calibre is my device book manager, not my library manager) I add automatically to calibre. Not standard? True.

That is the thing- you have your own tools to manage your library. Including, it seems, the things you created yourself.
Having them gives you advantage over anyone else who cant create tools themselves. So you are uniquely equipped to handle things you need. What I'd like to have is opportunity to deal with library organizing without "batch programming, python programming in calibre, batch processing". Easy way, without going further is- file manager, does not require professional programming skills, does not require lengthy book processing, tag editing, works with any language that supports unicode. You can bash inadequacies of file manager all you like, but it is still a better system than what we have on Kobo now.
This thread asks everyone if they could benefit from having a file manager, I know I would. You know you wont. Still does not make it a wrong idea, especially for now when most of us do not have your skills or your tools.

[Terisa de morgan]

Originally Posted by theonna

That is the thing- you have your own tools to manage your library. Including, it seems, the things you created yourself.
Having them gives you advantage over anyone else who cant create tools themselves. So you are uniquely equipped to handle things you need. What I'd like to have is opportunity to deal with library organizing without "batch programming, python programming in calibre, batch processing". Easy way, without going further is- file manager, does not require professional programming skills, does not require lengthy book processing, tag editing, works with any language that supports unicode. You can bash inadequacies of file manager all you like, but it is still a better system than what we have on Kobo now.
This thread asks everyone if they could benefit from having a file manager, I know I would. You know you wont. Still does not make it a wrong idea, especially for now when most of us do not have your skills or your tools.

But that's a different approach. You want it, I understand it. What I don't get is you telling me I must acknowledge the advantages of browser for ME. That I have to acknowledge that it's a good idea for ME, as I read the message I was answering.

I won't write anything at the thread about improving user interface in Kobo, when people talk about file manager advantages and disadvantages. I won't say to anybody that a file manager is not a good idea for him/her. But I'm not going to request a file manager either.

I can understand the desire for a file manager from a few different perspectives. On the other hand, I think there are better ways to do it.

A file manager is easily understood, at least among those of us who have been using them for years and know how to organize our files. File managers are also universally accessible on personal computers, so you can organize books using the same skills and strategies that you use to organize your other documents. There are also very few boundaries in how you structure your directories as well as how you name your files and directories. The main limitation is that it must be hierarchical, and even then you can create links to sort-of get around that limitation.

Yet I don't buy into the bit about it being easier. Books contain metadata. As a minimum, the author and title are virtually always correct. The cover and other publication data are usually valid as well (e.g. publisher, publication date, series information). Tags are usually dodgy, but let's ignore that for a moment. Let's pretend that your main concern is organizing books by title, author, series, and genre. Let's look at the difference between using a directory structure and using the metadata.

When you download a file, the directory structure is not there. You need to create it (a one-time job) and you need to populate it (an ongoing job). Filenames may give you the title, author, and series. It is unlikely to provide the genre. Yet both are likely mangled. If you obtain all of your books from the same source, you can probably get around that with a file manager that supports find/replace (as a minimum) or regular expressions (ideally). That file manager would probably place the files in the correct directories as well, and will do so with the minimum of intervention. If you obtain your books from multiple sources, the above holds true but you'll probably have to select which rule(s) apply to a particular source. Then there are the sources that provide virtually no information in the filename, such as Project Gutenberg, so no file manager is up to the task. Everything has to be done manually.

Using the metadata is altogether different. The drawback is that you need special tools. Calibre is the classic example, though there's no particular reason why you couldn't use a special file manager (or file manager plugin) that recognizes ePubs or a programming library that recognizes ePubs (e.g. a Python package). But all of that is too complicated, so let's pretend that you're using a dedicated tool like Calibre. This tool will instantly know about the author, title, and series data. The tags may include the genre, or you may have to add that yourself. Your work is effectively done because the work has been mostly done for you. You don't have to unmunge file names. You don't have to put things into directories. It is neither a manual task, nor one requiring the user to automate process in that aforementioned powerful file manager. At most you'll have to go in and add genre data. At worse, the picky person will have to make minor corrections to the data.

[theonna]

Originally Posted by Terisa de morgan

What I don't get is you telling me I must acknowledge the advantages of browser for ME. That I have to acknowledge that it's a good idea for ME, as I read the message I was answering.

I won't write anything at the thread about improving user interface in Kobo, when people talk about file manager advantages and disadvantages. I won't say to anybody that a file manager is not a good idea for him/her. But I'm not going to request a file manager either.

I have never told you or anyone to acknowledge advantages of a browser for them.
What I am doing is saying, that though you declare that you do not need a file browser, it is not because it can not be useful, but because you specifically have skills and use of a reading device that would not need a file browser. Also I am pointing out uses of it for many other people.
In short I am trying to keep idea alive, though there are plenty of people that have learned to deal with their devices without file manager. Because there are still a lot of us who would like a file manager.

[Terisa de morgan]

Originally Posted by theonna

I have never told you or anyone to acknowledge advantages of a browser for them.
What I am doing is saying, that though you declare that you do not need a file browser, it is not because it can not be useful, but because you specifically have skills and use of a reading device that would not need a file browser. Also I am pointing out uses of it for many other people.
In short I am trying to keep idea alive, though there are plenty of people that have learned to deal with their devices without file manager. Because there are still a lot of us who would like a file manager.

Not as I've read it. Anyway, that's the end of this for me. Any further discussion is only going to repeat the same ideas from your side and mine, so it isn't going to add anything new. I think we should agree to disagree.

[TechniSol]

I would simply submit that the metadata approach is superior in overall concept, and that the same interface mechanism used to sort the books for browsing on the reader could also allow for Search as outlined earlier. Further, allowing for the editing of metadata on the device would be rather simple as well since the mechanisms already exist to extract it from the files... (I'd still want Calibre, for all it's many functions -especially backup, but there is no reason one could not perform simple metadata editing on the ereader.)

The reason I brought this up is that I see no REQUIREMENT for Calibre with a meta data based organization system if they added a little editing to the Kobo firmware, but it does act as a very powerful and desirable add-on any way you cut it.

[theonna]

Originally Posted by TechniSol

The reason I brought this up is that I see no REQUIREMENT for Calibre with a meta data based organization system if they added a little editing to the Kobo firmware, but it does act as a very powerful and desirable add-on any way you cut it.

I wont disagree with that, I think a great thing as far as meta data would be letting us search by fields and put search results in shelves all on the device and let us view our library organized by metadata fields.
As

Originally Posted by BWinmill

I can understand the desire for a file manager from a few different perspectives. On the other hand, I think there are better ways to do it.

says. I agree here. It is not yet implemented unfortunately.

Originally Posted by Terisa de morgan

Not as I've read it. Anyway, that's the end of this for me. Any further discussion is only going to repeat the same ideas from your side and mine, so it isn't going to add anything new. I think we should agree to disagree.

but I don't think we are disagreeing on principal. You not seeing that while Kobo is not yet capable of doing what you need to do by itself you expertly setup your computer to do the job, what I want avoids a need for all the setup. I would not mind benefiting from all of the database metadata functions, problem is it does not work fast or efficient yet.

[TechniSol]

Neither does your file browser exist... I just think that in light of the approach already taken, the metadata way makes more sense. Frankly, I'd rather Kobo perform as few file operations beyond reading them as possible...

[theonna]

Originally Posted by TechniSol

Neither does your file browser exist... I just think that in light of the approach already taken, the metadata way makes more sense. Frankly, I'd rather Kobo perform as few file operations beyond reading them as possible...

I guess I was mistaken thinking that it should be easier to implement a file browser, rather than waiting for database functions to catch up with our needs. Also I don't want Kobo perform many file operations, besides just displaying a file structure with ability to click on a book to read.

[DNSB]

Originally Posted by guma

This whole discussion seems a bit strange to me since it is contrasting a 'happy case' scenario (fully tagged libraries, ergonomic tag/library management tools etc.) with a request to - potentially - improve an existing device which does currently not remotely offer the possibility to use - let alone manage - metadata in an ergonomic way.

I mean, this is about KOBO devices, right? Not about what can/could be achieved using Calibre and the like, nor about why, in theory, a meta-data based file organization paradigm is more powerful compared to a file structure based approach.

My opinion, for what it is worth, is that the current database search implementation is likely to be improved in future firmware. Also in my opinion, the chances of Kobo adding a file browser are about those of a snowball in the seventh circle.

The current search gives me better access to multiple authors and genres than browsing the directory structure on my hard drive where I often found myself using search to locate books. Yes, I know the quality of the search on my Kobo is based on my ensuring the metadata fits my needs but Sigil and Calibre allow me to do that with relative ease.

Regards,
David

Just a thought. I've heard that Be implemented metadata at the file system level. I believe that NTFS and ext3 both support it as well. (I forget whether is was mentioned specifically in the context of metadata, or that ACLs were implemented in a way sufficiently general to support metadata.) If this is the case, why couldn't the system separate the metadata from ePub and encode it in the file system as part of the file instead of a centralized database? This would allow for enough cross over to hopefully make everyone happy. (Kobo would still use the metadata approach, but at least it would be easier to manage without specialized tools.)

Yet, I know there are issues with this approach. The biggest issue is cross platform support and support from file managers and other such utilities. I lived with the classic Mac OS for long enough to have a love/hate relationship with resource forks. But if the basics are there for the three major platforms (and, by extension, Android and iOS), why shouldn't developers start taking a serious stab at implementing interoperability.

Then again, asking Kobo for a file manager is more realistic than that. Sigh.

[DNSB]

Originally Posted by BWinmill

Just a thought. I've heard that Be implemented metadata at the file system level. I believe that NTFS and ext3 both support it as well. (I forget whether is was mentioned specifically in the context of metadata, or that ACLs were implemented in a way sufficiently general to support metadata.) If this is the case, why couldn't the system separate the metadata from ePub and encode it in the file system as part of the file instead of a centralized database? This would allow for enough cross over to hopefully make everyone happy. (Kobo would still use the metadata approach, but at least it would be easier to manage without specialized tools.)

I suppose NTFS streams would work. I'm not sure if ext3 supports a similar metadata mechanism.

Originally Posted by BWinmill

JYet, I know there are issues with this approach. The biggest issue is cross platform support and support from file managers and other such utilities. I lived with the classic Mac OS for long enough to have a love/hate relationship with resource forks. But if the basics are there for the three major platforms (and, by extension, Android and iOS), why shouldn't developers start taking a serious stab at implementing interoperability.

For HFS/HFS+, my feelings would be more despise/hate. However since Kobo supports FAT32 on the exposed partitions, the only way I could see to handle metadata on a file by file basis would be to have the book processing routine generate a metadata file for each ebook (similar to the .opf files Calibre uses to store metadata) stored in a single directory similar to the image store currently implemented. IMO, we'd still need the database for speed in accessing information -- imagine doing a search by opening and reading 1000+ files.

Regards,
David

Originally Posted by DNSB

IMO, we'd still need the database for speed in accessing information -- imagine doing a search by opening and reading 1000+ files.

In retrospect, I agree. After all, I've pretty much made that argument in the past. Still, it can be fun to think about alternatives. That's particularly true of alternatives that are decades old and (at least seemingly) more sophisticated.

(And yes, I know that those seemingly more sophisticated options aren't always better in the long term.)