[KPhotoAlbum] Startup performance

[Andreas Schleth]

Hi coders,
As a user, sitting on the side line and occasional submitter of rare bugs I like to join Martin in thanking you. It is just great to see one of my favourite programs being cared for.
I had similar ideas about splitting the DB. In fact I sort of do it myself since ages: Everybody has her/his own DB and only good pictures are migrated via Kim to the family album. Which is in a better backup level.
This works nicely except that it is a bit of a pain to sync category entries. Which brings me to the point: 
Would it be possible to have one or more separate category-DBs alongside the image DBs?
Then splitting it as Martin proposed would be a better user experience. When setting up a new DB you could possibly choose from which Category tree to inherit and have all meta data to choose from from image1 on.
Best regards, Andreas

Am 13. Oktober 2020 07:50:37 MESZ schrieb "Martin Höller" <martin at xss.co.at>:
>Hi!
>
>Am 12. Okt. 2020 schrieb Robert Krawitz:
>
>> It really is the startup that's the most visible aspect of all of
>this.  Again, that either means
>> pretty fundamental changes in the storage backend, a faster XML
>parser, or maybe a way of bringing
>> up the UI while images are still loading (and since you're often
>going to want to look at your most
>> recent photos, not even very helpul).  If we stored photos in the
>database in _reverse_ order of
>> time, though, that might be workable (I'd love to have instant access
>to my most recent basketball
>> game while the rest of the file is being loaded).
>
>Just an idea: what about "partitioning" the database. I mean we could
>have a single XML file per year, per decade, per 10k images or
>whatever.
>That way, loading the more recent images first as Robert suggested
>would
>be easier.
>
>Oh and BTW, thanks for all the work that has be done on KPA so far!
>Really great work!
>
>hth,
>- martin

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kphotoalbum/attachments/20201013/10be90d4/attachment.htm>