| 5 Sep 2024 |
 outfoxxed | QCoreApplication::applicationFilePath would be good enough except there isn't really a way to determine if the resource is from the application or a library it pulled in. That could be an issue in kde especially. | 00:36:46 |
| outfoxxed | I'll make a compromise and have it re-cache qml files in shared libraries used across applications. Better than a false positive match. | 00:37:38 |
| outfoxxed | I was going to test the patch with some kde applications and hit something interesting | 03:43:16 |
| outfoxxed | 
Download image.png | 03:43:27 |
| outfoxxed | why does kirigami not use qmlcachegen | 03:43:28 |
| outfoxxed | its going directly to file paths, not even trying for an AOT cache | 03:43:52 |
| outfoxxed | one of them even managed to not be a url | 03:44:55 |
| outfoxxed | 
Download image.png | 03:44:56 |
| outfoxxed | it looks like elisa does, but kirigami doesn't | 03:46:56 |
 K900 | In reply to@outfoxxed:outfoxxed.me
K900: just went and looked at the cache paths and we have an issue with just getting the paths of the qml files we're working with. All we have is qrc paths and there doesn't seem to be a way to get the binary a resource is part of to find its path. Yeah, you might need to dig in QResource guts | 06:51:24 |
| K900 | To actually get that | 06:51:31 |
| outfoxxed | In reply to @k900:0upti.me
To actually get that I think its solved reasonably well by using the application path, since applications have individual qml caches | 07:01:15 |
| outfoxxed | thats whats here at least https://github.com/NixOS/nixpkgs/pull/339706 | 07:01:27 |
| K900 | Yeah probably | 07:01:47 |
| K900 | Also need to figure out how to clear out old caches | 07:01:53 |
| K900 | Looking at the code I'm not sure if this is actually ever addressed on other distros which is scary | 07:02:14 |
| outfoxxed | it doesn't appear to but its also not something that can be done very well genericly | 07:02:39 |
| outfoxxed | because applications can load whatever paths at whatever time | 07:02:49 |
| K900 | We could do a tmpfiles rule | 07:02:50 |
| outfoxxed | I don't think we want to clear any other caches the application might have | 07:03:15 |
| outfoxxed | what I do think we should do is change the save format of qmlc on disk to include the application path instead of putting it in the hashed name | 07:03:50 |
| outfoxxed | similarly to the tag | 07:03:58 |
| outfoxxed | some care needs to be taken to only do it to disk cached qml files but that shouldn't be very hard | 07:04:20 |
| outfoxxed | it would avoid endless creation of new qml caches whenever there's an update but probably require more maintainance | 07:04:43 |
| K900 | In reply to@outfoxxed:outfoxxed.me
what I do think we should do is change the save format of qmlc on disk to include the application path instead of putting it in the hashed name How would that help? | 07:05:42 |
| outfoxxed | it would allow qtdeclarative to invalidate caches from old derivations | 07:06:00 |
| outfoxxed | like what it tries to do with the timestamp | 07:06:06 |
| outfoxxed | except working on nix | 07:06:09 |
| K900 | It won't though? | 07:06:10 |
| outfoxxed | why not? | 07:06:17 |
