#45 switch to GTK3

[Benoit Pierre]

I have pushed the GTK3 branch.

4 things to note:

• the main window resize grip is gone (not supported by GTK3 anymore)

• when using the 'Enhance Image' dialog, there is not support for applying a change only when the user stops moving / releases the slider, so maybe we should add a thread

• Ctrl+C to stop MComix when launched from the terminal does not work anymore

• the Windows distribution needs to be updated, I had some changes for that, but it has been a while, so I need to check if it still work and probably update some things

[Ark]

Thank you for your great work. I will jump right into where things do not yet work as intended, though.

1. FIXED: Shortcuts involving Shift that do not result in a different character when normally typed (e.g. Shift+Space bar instead of simply Space bar) do not work even if everything seems fine when looking at the "Shortcuts" pref tab. Since those shortcuts result in the same character, the result will be the same action bound to the corresponding key without the Shift key involved. (The Control key (aka "Primary") works fine, though.)
2. When using only the space bar for navigation, the scrollbars do not always reflect the current relative position. At some point later (maybe after switching to a different book, I can't tell for sure yet), it suddenly starts working, though.
3. Sufficiently wide thumbnails in the thumbbar look as if they have been cropped on the right side. Judging from what I can see on a screenshot, it seems that the ''total'' width matches the thumbnail size pref but ignores the fact that there is a 1px border around the actual thumbnail. In other words, a 1px column of actual thumbnail image and another 1px column of thumbnail border seem to be missing or hidden behind the thumbnailer's scrollbar.
4. "Enhance image" dialog: The number labels next to the controls look "disabled". (This might be okay and/or I am simply not used to the new look.)
5. FIXED: "Enhance image" dialog: Checkbox for "Automatically adjust contrast" shows underscore (instead of a working mnemonic while keeping the Alt key pressed). This phenomenon occurs in other dialogs as well, e.g. "Open with".
6. FIXED: The main area does not respect the background color prefs.

7. FIXED: Using the magnifying lens results in exceptions being raised:

   TypeError: argument rectangle: Expected Gdk.Rectangle, but got gi.repository.cairo.RectangleInt
   Traceback (most recent call last):
     File "/home/ark/mcomix/mcomix-git/mcomix/lens.py", line 126, in _motion_event
       self._draw_lens(*self._point)
     File "/home/ark/mcomix/mcomix-git/mcomix/lens.py", line 75, in _draw_lens
       window.begin_paint_rect(draw_region)
   
   TypeError: argument rectangle: Expected Gdk.Rectangle, but got gi.repository.cairo.RectangleInt
   Traceback (most recent call last):
     File "/home/ark/mcomix/mcomix-git/mcomix/lens.py", line 120, in toggle
       self.enabled = action.get_active()
     File "/home/ark/mcomix/mcomix-git/mcomix/lens.py", line 48, in set_enabled
       self._draw_lens(*self._point)
     File "/home/ark/mcomix/mcomix-git/mcomix/lens.py", line 75, in _draw_lens
       window.begin_paint_rect(draw_region)
   

[Benoit Pierre]

1 and 7 should be fixed.

[Ark]

Thanks for making the lens work again! The lens might need some double buffering, though. (That is, the flickering was not as prominent before GTK3.)

The keyboard shortcuts seem to work as before again, thanks. However, I just found another bug regarding shortcuts which is also present on master. (That is, the description that follows applies to both branches.)

In the prefs, pressing Shift+D is recorded as "<Shift>d" and not as "D". However, pressing Shift+/ using a US keyboard layout is recorded as "question" and not as "<Shift>slash". This looks a bit inconsistent but is probably due to GTK and works otherwise fine so I think that part is okay. However, the modifier keys are not being handled properly. If a mod key like "<Shift>" or "<Alt>" is rendered like this in the prefs, then using only one of the mod keys listed for a single shortcut is already enough to trigger the respective action. Example:

• If "<Primary><Shift>space" is bound to Action A and there are no other shortcuts involving "space", any of these combinations will work: "<Shift>space", "<Primary>space", "<Primary><Shift>space" and even "<Alt><Shift>space".
• If, additionally, "<Shift>space" is bound to Action B, then pressing "<Primary>space" or "<Primary><Shift>space" will trigger Action A, but "<Shift>space" and even "<Alt><Shift>space" will trigger action B.
• Things get even more complicated if "<Shift>space" (Action B) is replaced by "<Shift><Alt>space" (still Action B). Then, "<Primary>space" and "<Primary><Shift>space" will trigger Action A, but "<Shift>space", "<Alt>space", "<Primary><Alt>space" and "<Primary><Shift><Alt>space" will trigger Action B.

I think it would be better if a shortcut triggers an action if and only if it matches exactly the respective shortcut set in the prefs. In this case, it would be irrelevant whether a shortcut is rendered as "question" or "<Shift>slash" in the prefs because the keys that need to be pressed would be the same (when using an applicable keyboard layout).

I wonder whether this should be fixed on master or on gtk3.

[Benoit Pierre]

I don't get any flickering with the lens.

I fixed the osd (same problem as the lens, the API changed). I also fixed 6 (the background color).

[Benoit Pierre]

I fixed 5: mnemonics in "Enhance Image" and "Open With" dialogs. Also fixed some popup menu calls (status bar, edit archive, ...).

[Benoit Pierre]

OK, so I've found a "fix" for the scrollbar not getting redrawn (because that's the problem, they don't always get redrawn, unfocusing/focusing the window may trigger a redraw), but really that's just a hack on top of the existing legacy hacks...

I wonder if this used to work; after all the GTK3 branch is more than a year old, and things like the lens/osd did work before the API was changed.

The thumbar selection is sometime broken, I don't know why: clicking toward the bottom select the page, scroll to frame it at the top, but we don't receive the row activated event, so the current page is not changed.

And then there is of course the problem of the Windows distribution, which after already spending hours fighting PyInstaller gives me a 46MB file because for some reason it decided to include Tk/Tcl (among other things). All for a system I don't even use.

At this point I've got to wonder if it really is worth it, there is really too much cruft in MComix, too many "features" I'm sure nobody use (or some of them would not stay broken for years). At least I don't. In fact to be honest, I hardly use MComix anymore.

So sorry, but this is it for me, I'm done with MComix development.

[Ark]

OK, so I've found a "fix" for the scrollbar not getting redrawn (because that's the problem, they don't always get redrawn, unfocusing/focusing the window may trigger a redraw), but really that's just a hack on top of the existing legacy hacks...

That really sounds annoying, indeed. Thanks for the fix.

The thumbar selection is sometime broken, I don't know why: clicking toward the bottom select the page, scroll to frame it at the top, but we don't receive the row activated event, so the current page is not changed.

That is really strange. For the record: Clicking on a thumbnail that is not fully visible seemingly changes how the thumbbar draws itself but does not seem to change MComix' internal state. Most of the time, it needs two consecutive clicks on one or two fully visible thumbnails until the main viewport shows the respective image. However, this issue sometimes spontaneously disappears. To me, it looks more like a bug in GTK3 (or the respective Python lib) but I am not sure, of course. Maybe it has something to do with that do-not-flip-pages-by-clicking-if-the-window-was-not-focused feature, I don't know.

At this point I've got to wonder if it really is worth it, there is really too much cruft in MComix, too many "features" I'm sure nobody use (or some of them would not stay broken for years). At least I don't. In fact to be honest, I hardly use MComix anymore.

So sorry, but this is it for me, I'm done with MComix development.

I totally understand that you want to quit under those circumstances. I also don't like the Windows part, both because the all-in-one file is huge and because it is so difficult to test it. That is, maybe we just need more developers for Windows who can take care of it without much intervention from our side? Or maybe we should simply stop the GTK3 port (at least for now) and continue using GTK2? Of course, I do not know what your decision will be now, and I cannot stop you anyway, but I would be glad if you remember MComix as an interesting project and certainly not as a bad project just because Windows sucks and you spent that much time on the Windows part.

As for me, I am using MComix virtually every day and I really like it (even if it has its quirks sometimes) because of the features many other image viewers do not have. Of course, different people have different needs, but maybe your needs happen to be representative for users who would like to use MComix but do not (because of certain quirks that drive them crazy, for example). So, could you please tell me about the things that you would like to see implemented differently (or even removed)? This would be of great help.

[Benoit Pierre]

That is really strange. For the record: Clicking on a thumbnail that is not fully visible seemingly changes how the thumbbar draws itself but does not seem to change MComix' internal state. Most of the time, it needs two consecutive clicks on one or two fully visible thumbnails until the main viewport shows the respective image. However, this issue sometimes spontaneously disappears.

Yes that's what I was seeing too.

To me, it looks more like a bug in GTK3 (or the respective Python lib) but I am not sure, of course. Maybe it has something to do with that do-not-flip-pages-by-clicking-if-the-window-was-not-focused feature, I don't know.

No, it's not related to the focus thing, it really looks like a bug in GTK: the item activated event is not fired.

I totally understand that you want to quit under those circumstances. I also don't like the Windows part, both because the all-in-one file is huge and because it is so difficult to test it. That is, maybe we just need more developers for Windows who can take care of it without much intervention from our side?

Yes, packaging the Windows version is a major pain, but testing is a big issue, no matter the OS: too many features, and the way some are coded means too many use cases. Like the scrollbar fix, if you look at it, I basically had to fix it 2 times because we have 2 completely different code paths: one when the smart scrolling feature is enabled, and another when it's not. Or did you know you can right click on the status bar and you get a menu? I only found about it because I had grepped the code for calls to popup.menu() to see if they were all fixed for GTK3.

Or maybe we should simply stop the GTK3 port (at least for now) and continue using GTK2?

GTK2 is a dead-end. At some point MComix will have to move to something else.

Of course, I do not know what your decision will be now, and I cannot stop you anyway, but I would be glad if you remember MComix as an interesting project and certainly not as a bad project just because Windows sucks and you spent that much time on the Windows part.

It was an interesting project, but I started contributing to scratch an itch (PDF support), and now that I don't use it anymore, the motivation is gone.

As for me, I am using MComix virtually every day and I really like it (even if it has its quirks sometimes) because of the features many other image viewers do not have. Of course, different people have different needs, but maybe your needs happen to be representative for users who would like to use MComix but do not (because of certain quirks that drive them crazy, for example). So, could you please tell me about the things that you would like to see implemented differently (or even removed)? This would be of great help.

Arguably the most import part of a comic viewer is the actual reading experience, and the navigation is a big part of that. This is what I currently use: https://drive.google.com/open?id=0B9Je8TDYCh1xQm5STHdoMmNKcjA

[Whyme Lyu]

@Ark any thoughts about get the project rolling again? Here's what I think:

• Merge this patch, release as 1.3.0 despite some details aren't perfect (things are never perfect anyway). What's the big issue holding from a new release? Windows installer? I can try to fix them and prepare for a release.
• Consider moving the project from Sourceforge to a modern platform (probably GitHub) for easier collaboration. Hopefully this would invite new contributors.
• I can help take over some maintainence work (merge patches, talk to users, etc.) if you are drowning IRL.

[ilikenwf]

I have synced my fork of the GTK3 branch with upstream and fixed all the issues I ran into, and so far everything seems to work here. I run on Linux, though.

I did all this because my new laptop is 4K, and GTK2 doesn't scale well. Otherwise GTK3 mcomix is wonderful and works decently enough with the touch screen, too.

I have a merge request in for review, perhaps someone could update the Windows dist and test this branch, hopefully after a merge, and then merge it into master?

[ryzen]

Hi what's the block of merging this?

[ilikenwf]

You may want to rebase on this forked repo, I feel like they did a better job than I did:

https://github.com/multiSnow/mcomix3