Recent changes to feature-requests

bookmark notes/description

2026-04-13T20:21:54.787000Z

Would be neat to be able to add a bit of text with bookmarks to find a page again, as otherwise you only have the typically non-descriptive filenames as information.

#123 Webcomic mode? (Plus different config sets)

2025-10-27T04:40:56.920000Z

If the project maintainers are open to the idea, I am happy to sponsor development for the "continuous mode" (the implementation as described by JMA and FeRD; a new view option given to the user).
I pledge $600 (USD) if this feature can be shipped within 2026 at the latest.

#137 Support CMYK and color profile conversion

2025-10-15T16:34:42.243000Z

MR https://sourceforge.net/p/mcomix/git/merge-requests/53/ implements this feature.

Support CMYK and color profile conversion

2025-01-02T08:38:57.798000Z

Take this image as an example https://wp.comicskingdom.com/comicskingdom-redesign-uploads-production/2024/12/Y2tQcmluY2UgVmFsaWFudC1FTkctNDYyNDEwOA.jpg
When opened in MComix (old 1.3.0.dev0 in Ubuntu 22.04, sorry), it's displayed with garish colors, definitely not the same as when opened with GIMP (see also https://stackoverflow.com/questions/79322180/converting-a-cmyk-jpeg-to-rgb/79322257). I couldn't find much related to CMYK or color profiles in the current git source, so I presume it will still be the same. I would have filed this as a bug if I could have tried the latest version.

This seems to work for that particular image, I guess something like it could be included in the MComix workflow, and relevant preferences could be added.

from PIL import Image, ImageCms
from io import BytesIO

img = Image.open('input.jpg')
img.show()
orig_icc = ImageCms.ImageCmsProfile(BytesIO(img.info.get('icc_profile')))
srgb_icc = ImageCms.createProfile('sRGB')
img = ImageCms.profileToProfile(img, orig_icc, srgb_icc, renderingIntent=0, outputMode='RGB')
img.show()

#135 Easy mouse-driven "un-fullscreen"

2024-11-15T05:56:17.415000Z

TBH I'd love to see a Qt GUI for MComix.

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".

Not sure if PyQt is a better choice than Qt for Python, now that it has official support in Qt6.

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.

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.

*nod* Annoying that PyQt is working against a Qt 6 version of something like AnyQt.

(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 around importlib.resources, but it's a more familiar style to Qt developers, and it opens up the possibility of maintaining sets of .qrc files packaging up standard resources that can be shared by Python and C++ project builds.)

Agreed. You don't drop format support in bindings for something.

#135 Easy mouse-driven "un-fullscreen"

2024-11-15T05:25:00.541000Z

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.

Support For Mouse Back And Forward Buttons To Change Pages

2024-10-06T10:39:58.268000Z

Please add support for mouse back and forward buttons to change pages.

#135 Easy mouse-driven "un-fullscreen"

2024-09-03T21:33:33.082000Z

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.

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.

#135 Easy mouse-driven "un-fullscreen"

2024-09-03T21:10:39.547000Z

While I AM a Python programmer, I'd rather not be responsible for maintaining my own patchset.

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!

#135 Easy mouse-driven "un-fullscreen"

2024-09-03T21:05:38.467000Z

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.