[FEATURE-REQUEST] Very basic touchscreen functions (Pinch Zoom) + basic library through file linking + one potential bug

[sitesbysam]

Love this project and how easy it is to use. Lightweight, portable and fast. Wildly effective at converting between formats and maintaining quality and getting the scaling right (/offering settings to control conversion). Appreciate the work you've done and love the simplicity and minimalism in the design.

I was wondering if there was any chance of seeing some basic touchscreen functionality? At the base level I think simply having Pinch Zoom would level up the experience a lot for touchscreen users. Dragging with the touchscreen works fine when zoomed in, which is nice, but there is no way to zoom in fullscreen mode aside from right-clicking and going through the context menu. I would imagine this would be pretty easy to implement with a JS library like this one? Or perhaps even without?

A secondary thought, since I've already taken the time to opening this issue (which by the way is the first time I've actually done this on GitHub), is there any plan to see some basic library management? That term may even be an over-complicating what I mean - I just mean a way that the user could choose files to have linked so they could be listed in the main UI for easy access.

Also, one little quirk I've noticed - if ACBR is open (regardless of whether a book is open at the time or not) and I try to launch a book from File Explorer, it brings ACBR to the front but doesn't load the book. Maybe if nothing is open it could load the book, and if there is already another one open it can pop up a dialog with the option to load the selected book? (Edit: To be clear it does open the book properly if ACBR is not already running)

Looking forward to hearing back, thanks! Sam

[binarynonsense]

Thanks for your kind words and for taking the time to suggest these new features!

• I don't have experience with touch input in javascript and can't easily test things in my dev computer, as I don't have a touch screen (could probably make tests on my steam deck although having to build and copy the test apps will be a bit tedious), but I think I could try adding some touch inputs to the reader as, from a very quick first glance, there seems to be good documentation and examples about things like that. No promises about when I'll be able to do it but I'll add a reminder in my TODO list to learn more about javascript's touch events/pointer events and make some tests to see if I can make it work (for this type of thing I prefer trying to implement something myself so I have full control of how the input is handled over using a library if I can, and I've also been meaning to make a proper input manager class in the app's code so this could be a nice feature to try adding). What's the bare minimum you think would be needed? Is being able to scroll by dragging the screen (which you say already works, so I assume it's a default behavior for touch inputs and scrollable elements) and pinch-zooming in and out good enough? What about changing pages? Using the mouse you can click in the left and right sides of the page to change pages, does that work using the touchscreen? If not, maybe it would be nice to also replicate that for touch input.

• I didn't have plans for now for a basic library 'tool' but it's something I agree could be a nice addition at some point and have briefly thought about in the past. One of the reasons that prevented me from going further is that I didn't want to add something too complex but didn't know which features would be enough for a basic library to make it useful (I think some apps have libraries where you choose folders for it to autoscan and generate/autoupdate a list with all the relevant files on them... I'm not sure I'd want to add something like that but don't know if that's a must have / something people expect if you have a library in a program). I don't really use any of the library tools in any of the programs I use so I'd need help trying to come up with something easy to create (although it could be expanded in the future) but still useful for people wanting to have, and more used to, such a feature... You said a basic library would be something where the 'user could choose files to have linked so they could be listed in the main UI for easy access', could you elaborate a little on that? How would that look and work (just a single window tool with a list of files and buttons to add new ones and remove old ones would be enough? a bit like the history tool/UI currently available (File>Open recent>History or Ctrl+H) but retrofitted to keep a custom list of files). And what features could be added in the future to expand/improve it? (like maybe being able to add folders to the list, and when you click one in the tool it would open the file selector in that folder so you can more quickly choose a file inside it). Not sure if I've explained my doubts too clearly, hopefully you get what I mean :)

• Yes, that's kind of a bug. I recently had to make having multiple instances of the app running at the same time not possible (because that would create problems with the history, temp files and configuration management) and, although I remember thinking about it when I was making the changes, in the end I forgot to take what you mentioned into account, so I'll add it to my TODO list and try to fix it in a future version (as you proposed I'll probably add a modal asking for confirmation to open the new file in case there's one already open, I think that would be the proper way to handle it, thanks for that suggestion and for letting me know about the bug, I had completely forgotten about it).

I think that covers all :) Let me know what you think. Álvaro

[sitesbysam]

Glad to see you got back so soon and are open to the suggestions!

• Touchscreen support: Bare minimum would be just implementing the pinch zoom functionality. The scrolling does work by default on a zoomed image by dragging, and page turning in both directions does work already by touching the sides, just as a mouse would. Something right above bare minimum might be a double tap gesture - perhaps as a shortcut to zoom in and out between fixed amounts (amounts could be a setting). This may require some type of override of default behavior though, because currently double tapping will just turn the page (because it recognizes the first tap and doesn't wait for the second).
• Library: What I'm imagining under the File menu, you could have an option to browse for supported files (and add multiple at a time, or perhaps scan folders..however you may want to handle it), but instead of opening them, they would be added to the empty UI that shows when you open ACBR/when you close a book. The books would ideally be listed with their Cover page showing and their title in a card format. It could also be something simple like the History list you have, but I think showing the covers would make them more immediately recognizable. There could be an option to toggle between list and gallery view as well. For any folders added, it could scan at startup and that way it could auto-update if books were added (and exclude any the user manually removed from their list), and for individual files added the scan would just check that the file still existed at that location. If a file is moved or deleted, the simplest solution would probably be to just remove it from the list (and thus the UI). But a more elegant solution may be to have some indicator (an error symbol preceding the title, an error symbol in place of the Cover, etc) and if the user clicked on it they could either browse for the file to relocate it or remove it. Base level, I would imagine a basic sort feature of the library - have options for sort by Title, Series, Recently opened (pretty much the same sorting as you have with Open Recent > History, but only applying to the books in the library), maybe Order Added. You already have a metadata editor built in, so it could be an option on right click to edit the metadata for that file, and that way it would be on the user to make sure their library would sort properly for those who cared to do that (which I suspect many wouldn't care to be overly meticulous about). I'm not imagining some crazy complex system like I've seen in some heavier software like calibre, more like a simple option to tell ACBR where your books are located so that it can present them to the user when the program is opened.
• Library expanded: Down the line, yes folder shortcuts like you mentioned would be great. Perhaps a way to group books into playlists within ACBR. Also simple tags like being able to toggle favorites, or toggle whether a book has been yet to be started/in progress/finished (managed by the user). More sorting options (Release Date, Page Counts, whatever metadata may be relevant) or a simple search bar that searches titles (or filenames?).

Hopefully that is all coherent (: Thanks for getting back! Let me know if you need further clarification on my thoughts!

[binarynonsense]

• Wouldn't double tap be better suited to reset the zoom? (to fit to height or whatever is the default value). I think that's what I've seen it used as most often.

• Don't get me wrong, I appreciate the usefulness of a library as you describe it, but I still feel like the idea gets too complex/has drawbacks for me at least right now, as it would take some time to implement and some of the apparently simple things you propose have hidden problems: as I mentioned I'm not a fan of having folders to scan or, worse, auto-scan at startup of ACBR or a specific tool to keep a list of files updated, especially if accessing them to generate a cover or get any data (number of pages...) is needed, as I'm afraid it would be too slow (reading and extracting things from compressed files from javascript is relatively slow, and once there are a few files the times really add up, and generating a cover for a PDF would also take time and specific code just for that) and things would incrementally get worse the more files are involved... (and some people have huge folders/libraries of files) so I'm a bit ~weary~ wary of getting into that particular problem. Thinking that would be the case, last night I tried to figure out a simpler alternative to a library that could add some of the benefits of having one (and hopefully provide some of the things you wanted) but would be easier to create and maintain, and I came up with the idea of adding a Favorites tool/UI. More or less it's what I proposed yesterday, a simple list where you add files or folders (maybe just files for the first iteration) and clicking on them opens them. Nothing more, nothing less. It could have a list and grid view, with covers that would be generated when a file is added (again, a first simple iteration could just be a list like the history one, no covers, just a file icon). And it could be opened as a regular tool from something like File > Favorites or instead, as you suggested for the library, and probably even better it could replace the "empty UI that shows when you open ACBR/when you close a book" with it. With maybe a couple buttons at the top to "open file" (which will just do the same as File>Open or Ctrl+O) and "add" (to favorites, or maybe a plus button), and then just a favorites list... I could also add a "File > Add to favorites" entry to the menu, only active when a file is open, or to the right-click context menu. My first inspiration was the Favorites UI from VLC for Android's browse tab, so here's a screenshot I found Even the favorites idea is something I don't know when I would be able to add, but I think it would be easier to find the time for it at some point if it sounds useful.

Edit: would being able to favorite single files be really that interesting/useful? or would it be better to have a favorites/initial screen like the one from VLC I showed, just for folders, not files, so it's a quick way to open the folders you have comics in to choose one from. And could leave the list of files for a future library if I manage to make one at some point, I feel like 'favoriting' a comic file is not that useful and adds complexity to the welcome screen (hides/muddles the folder links), having quick access to particular files wouldn't be that useful (you wouldn't access them that often apart from when you are reading them) but focusing on quick folder access from that screen seems more useful. What I could add to that screen would be a History/latest opened files list below the favorites folders... that does seem useful to quickly open one of the latest used... Right now I'm more inclined to go this route, what do you think?

[sitesbysam]

Hi, sorry for the delay, had a busy few days -

• Yes, double tap to reset would work fine - I was initially thinking let the user choose what "reset" means, whether it's fit to width or fit to height (with the default being fit to height/default zoom) because if they are using it in fit to width and double tapping brought it back to fit to height every time, it may not be as useful..unless I'm misunderstanding and the default value is already set by the user, which would make this a non-issue. But it would be nice as well if double tapping when the page was already at the default zoom would zoom in as well (either to a static amount you set or to a value that the user could set).
• I agree with your edit after thinking about your points - Maybe some of my ideas (including favorites) could be implemented if you did decide to go into creating a more featured library in the future, but I think the UI you described, with the addition of a history/recent section, would go a long way in improving the ease of accessing the user's books, and keep it light and fast. If the list resembles the History list you have now, where the end of the filepath is shown, one thing that would be nice if the filename itself could be bolded or something to make it easier to recognize the filenames (this could apply to the History list as well). When I look at it on mine, the filenames are all varying lengths and it is a process to parse and find where the filenames start because they don't line up. Not necessary but could help.

[binarynonsense]

• Right now, you can set in the preferences what zoom value is used when opening a file (fit to height, fit to width or last used, which would be the value used the last time the program was closed [although you can also set it to remember the last value used for each file in the history and use that if available]) with the default being, I think, last used... For double tap, I could use that if it's set to something other that last used (height or width) or use my own default, maybe width, if not (resetting to the last used may be confusing as it can be any value)... but that can be changed/improved once double-tap itself is implemented and working (edit: first of all I need to see if I can manage to make it work :)) until it feels right (could even add a preference just for that if needed, but let's start with the simpler option and go from there). Edit: I forgot, doing something different when the page is already at the default value, like zoom in a bit, feels like it could be confusing to the user, so I'm not very partial to doing that. Once you have zoomed in a little that time, double-tapping would go back to its default behavior and zoom to default again so you'd need to use the usual way to keep zooming, pinch, anyway....
• Great, a favorite folders + history start/home screen it is then. I like the idea of 'bolding' the name of the file in the path (edit: or displaying two lines, one with just the filename and one below with the path, could be even more useful/easier to quickly identify the files).

Now that I have things more clear and I like what we've come up with I'll try to add these things to the program at some point but, my usual disclaimer, no promises as to if or when, as I haven't been able to work that much on ACBR lately and the TODO list is getting bigger as times goes on...

And again, thanks for taking the time to make suggestions to improve the program and answer my doubts!

[binarynonsense]

I've just released a new beta version, v3.5.0-beta1 , that I think addresses all the issues we talked about here:

• Launching a book from File Explorer or dropping it into the executable or a desktop shortcut (this is how I test it on Linux) while there's already an instance of the app running should ask if you want to open it (if it's a valid format) in that one.
• I've added a new input manager that handles touch input. You should now be able to drag to scroll a page, pinch-zoom to zoom in and out and double tap to switch between the default zoom levels. All is redone from the ground up so the things that, by chance, already worked before are now done differently. I can only test this with my Stem Deck, and it's quite a cumbersome process going back and forth with the builds, so I haven't tested it that much... but it seems to work :)
• There's now a Home Screen shown when there's no file opened, with a button to open a file dialog and lists of favorite files and folders and latest files.

Hope you like the new changes, let me now if you give it a try.

[binarynonsense]

I just released the next stable release containing the mentioned changes so I will close this issue. Hopefully everything was working correctly, especially the touchscreen stuff I couldn't test thoroughly myself, but I couldn't extend the beta phase longer. Edit: let me know what you think if you have time to test the changes at some point.