I guess I should talk a little more about this:
Windows UWP apps does not have free access of files. For example if you open a comic book with Comics++ from Windows Explorer, the app does NOT have access of all the other files in that folder. There are many other restrictions like file access is only granted using the Windows file picker, or declaration of use of certain folders like Pictures, Documents etc. UWP apps cannot behave like Win32 apps because it is a contain environment with locked on access permissions.
The UWP is actually designed such that it encourage the user to implement libraries, because file access are stored as "StorageItems" not pointer to files. For example you can open a file as a StorageItem, and that storageItem is locked to that file even if the file was renamed, modified or moved. So this way the user can move the file around in Windows Explorer and the app would still have access to the file. However this is limited to 1000 items, and any beyond that you either need to request special app privileges from Microsoft directly or implement work-arounds to bypass this limit. Comics++ has some workaround that we implement to circumvent the file opened from outside of the app above right now, but it doesn't always work (it gives you a message if not accessible). Comics++'s Faviorates tab are also tracked by your root folder. So if you change the root folder you'd lose all permission to your favorites, that's why favorites are cleared once you change root folder.
In my personal opinion UWP's design conflicts with it's own intention. If you want to restrict file access don't limit the amount of files you can store. Otherwise provide an easier way to grant access to file system. So instead of implementing workarounds trying to circumvent library restrictions we just straight up implemented a file browser. It's straight forward to implement and simpler for user to understand without putting limits on the app.
And there are other arguments against a library like storing thumbnails I discussed in this thread, and nature of libraries in general differs from a file explorer.
TLDR The tools Microsoft provided is not very good for creating a compelling library feature. I believe a file browser better suited in this case.
-----
Do you have suggestions on how to improve visual so you wont think it's ugly? I'm talking about mostly a visual update without introducing any major browsing changes.
- We can try to fetch cover for the folder but it can only be the files in the immediate folder. (i.e. if folder is nested and there arn't any covers in the immediate folder then it wouldn't work, e.g. MY_FOLDER->thumb.jpg = OK MY_FOLDER->VOL_1->thumb.jpg = only VOL_1 would have the image, not MY_FOLDER)
- Yes we will add an option to start the app at the file browser.
Windows UWP apps does not have free access of files. For example if you open a comic book with Comics++ from Windows Explorer, the app does NOT have access of all the other files in that folder. There are many other restrictions like file access is only granted using the Windows file picker, or declaration of use of certain folders like Pictures, Documents etc. UWP apps cannot behave like Win32 apps because it is a contain environment with locked on access permissions.
The UWP is actually designed such that it encourage the user to implement libraries, because file access are stored as "StorageItems" not pointer to files. For example you can open a file as a StorageItem, and that storageItem is locked to that file even if the file was renamed, modified or moved. So this way the user can move the file around in Windows Explorer and the app would still have access to the file. However this is limited to 1000 items, and any beyond that you either need to request special app privileges from Microsoft directly or implement work-arounds to bypass this limit. Comics++ has some workaround that we implement to circumvent the file opened from outside of the app above right now, but it doesn't always work (it gives you a message if not accessible). Comics++'s Faviorates tab are also tracked by your root folder. So if you change the root folder you'd lose all permission to your favorites, that's why favorites are cleared once you change root folder.
In my personal opinion UWP's design conflicts with it's own intention. If you want to restrict file access don't limit the amount of files you can store. Otherwise provide an easier way to grant access to file system. So instead of implementing workarounds trying to circumvent library restrictions we just straight up implemented a file browser. It's straight forward to implement and simpler for user to understand without putting limits on the app.
And there are other arguments against a library like storing thumbnails I discussed in this thread, and nature of libraries in general differs from a file explorer.
TLDR The tools Microsoft provided is not very good for creating a compelling library feature. I believe a file browser better suited in this case.
-----
Do you have suggestions on how to improve visual so you wont think it's ugly? I'm talking about mostly a visual update without introducing any major browsing changes.
- We can try to fetch cover for the folder but it can only be the files in the immediate folder. (i.e. if folder is nested and there arn't any covers in the immediate folder then it wouldn't work, e.g. MY_FOLDER->thumb.jpg = OK MY_FOLDER->VOL_1->thumb.jpg = only VOL_1 would have the image, not MY_FOLDER)
- Yes we will add an option to start the app at the file browser.