Menu
▾
▴
#135 Easy mouse-driven "un-fullscreen"
Please add an option at the top level of the context menu to exit fullscreen, like the original Comix had by virtue of not putting the usual one in a submenu.
(This is actually one of the reasons I stayed on Comix, despite it being unmaintained, until a bump in my LTS distro version removed it from the repos. While I AM a Python programmer, I'd rather not be responsible for maintaining my own patchset.)
I'm actually inclined to agree with this, to an extent.
The current context menu is too busy, and incredibly poorly organized for its actual purpose. The entire "View", "Go", and "Bookmarks" menu are swallowed in there verbatim. Big parts of the "File" menu are as well (and "Preferences" from the Edit menu), though at least they're promoted up a level instead of being at the submenu level. Don't even get me started on the Zoom controls being buried TWO levels deep.
Way too much of what's there isn't actually contextual at all. (How is access to the Preferences a contextual action? Or the Recent files list?) A proper context menu would show only actions that depend on the current context, and adjust them to account for it as well. (For example, showing "Exit Fullscreen" only when MComix is fullscreened, and "Fullscreen" when it wasn't. Or not showing "Go to First Page" or "Go to Previous Page" when viewing the first page of a file.)
I added the Fullscreen toolbar button, forever ago, because the View menu is woefully insufficient for quick access to fullscreen mode — and that's just as true whether it's the menubar View menu or the context-menu View submenu. But toolbar-Fullscreen only does half the job, there should really be a corresponding means of exiting fullscreen that's just as quickly accessible.
A top-level context menu option would be an improvement.
For maximum utility, I'd actually prefer a clickable button to exit fullscreen — one that's normally hidden, but appears based on input events. Like the "Exit Fullscreen" button that Chrome shows when a webpage is fullscreened. (See attached screenshot.)
The button could either appear briefly whenever the mouse is moved over the page canvas (like expanding scrollbars), or when the pointer is in proximity to the top edge of the screen (like Chrome's un-fullscreen button). Like either of those, it should hide itself again a few seconds after mouse movement ends, no matter where the pointer is located.
As an added bonus, if we were to do this for an un-fullscreen button, then we could also add floating "Prev" and "Next" page-flipping buttons (or, better, regions) on either side of the canvas, which would be one way to solve the whole click-navigation direction thing.
That's kind of a false dilemma, though. Why is it a choice between (a) the MComix devs making the change in the project; and (b) you making the change as a local patch you'll have to carry.
Option (c) is you making the change, and submitting a Merge Request to the project!
Because my patchset for MComix would be "How can I rip out everything that has changed since the last Comix release with minimal effort?" (Less "helpful PR material" and more "a private GIMPshop to MComix's The GIMP".)
(I'm one of those people who stayed on Comix, despite MComix being available, until the last supported month of the last Kubuntu LTS that had it in its repos, and was then just responsible enough to not continue accumulating ambient technical debt by manually re-installing Comix from upstream.)
Heck, given the stable of components for PyQt that I'm slowly growing to completion for other image-related projects, including a scanlation aid that's sort of "to Comix as Adobe Acrobat is to Acrobat Reader", functionality-wise (i.e. Comix, plus annotation features, embedded in a bigger IDE-esque UI), it's likely that you'll see me putting up a PyQt approximation of the old Comix UI some time in the next few years as an "I'm just scratching my own itch, but maybe someone else will benefit from this" thing.
TBH I'd love to see a Qt GUI for MComix. I've kind of grown to hate Gtk, and given that MComix is currently written in very ancient Gtk3, updating it to Gtk4 is probably an equal challenge to just replacing it with something built in Qt.
Not sure if PyQt is a better choice than Qt for Python, now that it has official support in Qt6. But it probably doesn't matter much, since for the most part the two projects have been dovetailing towards compatibility, or at least relatively simple porting between their two quirk-sets.
(The PyQt project removing Qt resource support from PyQt6 left a bad taste in my mouth. "Just use Python resources" sort of misses the point that code like
QIcon(":/icons/foo.svg")will not only always be simpler than anything based aroundimportlib.resources, but it's a more familiar style to Qt developers, and it opens up the possibility of maintaining sets of.qrcfiles packaging up standard resources that can be shared by Python and C++ project builds.)We'll see how things unfold. Right now, I'm still clearing out a large backlog of "TLC needed" for hobby projects tracing back to when time management problems I was already having were exacerbated by COVID bursting onto the scene.
As such, any MComix stuff is considered "less than ideal, but it works, so focus on the things that are broken or de facto abandoned".
To be honest, the reason I said PyQt is that I'm still back on Kubuntu Linux 22.04 LTS (I'm a little behind on evaluating whether 24.04.1 fixed the complaints that blocked me from 24.04 when I first made time to plan an upgrade) and I'm still targeting Qt 5 for stuff I write Right Now™.
I'll probably be using Qt for Python for Qt 6 if for no other reason than it's more official... especially if I can figure out a comfortable workflow for developing against the KDE Flatpak runtime as my primary development target.
*nod* Annoying that PyQt is working against a Qt 6 version of something like AnyQt.
Agreed. You don't drop format support in bindings for something.
Last edit: Stephan Sokolow 2024-11-15