Library names

[chaley]

Originally Posted by theducks

What I am calling the 'archived on-device library' is saving the info (listing) you see in one of the device views for the current connected device.

eg. my PEz: Main and Card_A = 2 snapshots into/updating the archive once ID's are established.
My idea was to provide a way to 'view' a snapshot (currently disappears, when disconnected) of what was on a device(s).

Ahh, I see. That has nothing to do with the driveinfo stuff, because the driveinfo information will also only be available while connected.

My suspicion is that you are asking for a calibre GUI feature that would maintain a set driveinfo_uuid:(id, id, id ...) and be able to show you that information in a (custom) column. Sounds like a good plugin project, where the plugin would capture the information when the device is connected, and then be able to populate a column from the captured information when the device is not connected.

Another goal, would to lay the ground work for a re-occurring, multi-user library permissions management suggestions :rolleyes:

Sorry, don't follow. What does multi-user library permissions have to do with the driveinfo information? In fact, what does it have to do with devices in general?

[theducks]

I am doing a lousy job on conveying my idea. I will drop it .

[chaley]

Originally Posted by kiwidude

I was just re-raising the issue in case that file above was the right place for it but perhaps the most "useful" place would be I guess some cross-library Calibre file which I guess "prefs" is.

I have added a device_name field to the driveinfo structure, along with the API to set it.

This will eliminate the 'prefs' at the cost of requiring that the device name be constant across all uses.

GUI support to set the device name is still required.

[kiwidude]

Hmmm... just wondering out loud here but I can't help wondering if it still should be in prefs somewhere. The reason being I can see it being pretty common to want to have a dropdown of device names when setting up configuration for a plugin. If the name only exists on the device, then the plugin could only determine a name when that particular device is plugged in? Otherwise we are back to each plugin maintaining it''s own list of device names/uuids again?

Apologies if this doesn't make sense, just from my reading of the thread the proposed changes are only to the file which sits on the device - great for identifying the device while it is in but perhaps not quite enough to allow configuration for it while it is not?

[theducks]

KIwidude.
You conveyed part of my idea way better

[chaley]

Originally Posted by kiwidude

Hmmm... just wondering out loud here but I can't help wondering if it still should be in prefs somewhere. The reason being I can see it being pretty common to want to have a dropdown of device names when setting up configuration for a plugin. If the name only exists on the device, then the plugin could only determine a name when that particular device is plugged in? Otherwise we are back to each plugin maintaining it''s own list of device names/uuids again?

You might for any number of reasons want to store a map of devices you have seen, in which case you should store both the UUID and the name.

The question that arises is what do you do when you see a device for the first time? What name do you give it? The change I made permits you ask the user for a name, then store that name on the device. The next time a plugin (any plugin) sees the device, it will see that user-supplied name, even if on a different installation of calibre. The same issue arises (what name?) when I move my device around from calibre installation to calibre installation: how are the names kept in sync?

For example, consider what happens when I give my XX device to my son. Its name would change (perhaps) from Charles' XX to Son's XX. This change might happen in his calibre installation. In that case, then when the device is plugged into mine I should see the new name he gave it, not the name it used to have when it was mine.

In other words, when my installation sees a UUID it recognizes, then it should update the display name from the one found on the device. Or ask, but I think that would be annoying.

[kovidgoyal]

I think what kiwidude is asking for is a centrally maintained cache of seen uuid-name mappings that are automatically updated by the device subsystem on connect of a device.

[chaley]

Originally Posted by kovidgoyal

I think what kiwidude is asking for is a centrally maintained cache of seen uuid-name mappings that are automatically updated by the device subsystem on connect of a device.

Yea, I know. However, having that cache will also require a) having the infrastructure to rename devices and cards, which leads immediately to b) changes to use that name wherever the device __class__.__name__ is used now. Then there would be the follow-on requests. For example, I am absolutely certain that within minutes of releasing such a thing, there will be requests to change plugboards to use the new device name instead of the current class name. Then after changing it to use device names, there will be complaints that the old way (generic class names) no longer works. Then when both are supported, there will be complaints that the two forms aren't kept in sync. There will be requests to make save templates device-name specific. And on and on. This isn't a hassle I am interested in taking on. I will leave it to the people who want to use this stuff.

[kiwidude]

Originally Posted by kovidgoyal

I think what kiwidude is asking for is a centrally maintained cache of seen uuid-name mappings that are automatically updated by the device subsystem on connect of a device.

Exactly. I don't have an issue with the name being stored on a device - the plus being as you say it can default when you plug into a new Calibre instance, the minus being you have to handle the issue of renaming/duplication if stored elsewhere.

But each plugin building up a device id/name map as it goes seems like some duplication that could be avoided if Calibre was to store a dictionary of UUID/name in prefs of devices it has "seen". The GUI around that would allow you to rename for a device (to cater for chaley's "my son" example), remove devices no longer used etc.

Then each plugin could just query that dictionary to present options/menus for a user related to that device.

[kiwidude]

Originally Posted by chaley

... And on and on. This isn't a hassle I am interested in taking on. I will leave it to the people who want to use this stuff.

Fair enough. We can but ask

[chaley]

Originally Posted by kiwidude

Fair enough. We can but ask

Or you can do.

[kiwidude]

Originally Posted by chaley

Or you can do.

Haha. Well, "someone" could, I'm still driving around on P plates when it comes to Python/Calibre and less hazardous to others in a plugin sandbox. Maybe if Kovid likes the idea meme will give it a go, after all he is the first cab off the rank who will likely want something like this

[kovidgoyal]

Generally speaking if we are going to be uniquely identifying storage locations, then it makes sense to eventually move to using those ids in places where the device driver is used as a proxy for a storage location.

However, this is a *pain*, which is why I have always ignored feature requests that involve disambiguating between multiple devices that share the same driver.

[meme]

A proverbial can of worms

I think I'm in the same car you are kiwidude - its a bit more than I can take on right now.

I can see why tracking things per device is a pain. And in many cases overkill - just because you can doesn't mean you should. Makes me wonder about my approach - is giving the user the ability to create different sets of collections for different devices really needed. But if the functionality will get added by chaley, then I'll use it

[kiwidude]

Yeah I'm in the "if it was there I would use it" camp. I think there would be plenty of examples of things where you want to track stuff at the device rather than the class level. Syncing news/books to a device being a perfect example of one of them - to a "class" of device makes no sense, to a specific device does.

I can also see that just because two family members use the same model of Kindle doesn't mean they want their collections organised in the same way - Mum just wants them by author, son wants series and genre tags etc.

However given the enormity of then also changing existing functionality like plugboards etc to allow device vs class specific there is no way I can offer anything but thanks to the kind soul who does sort this out one day.

"If you build it they will come"...