Activity for Ark
-
Ark posted a comment on merge request #53
Okay, I think I have a quite concrete idea now. Also, I figured that the whole thing will be too big to fit into the normal prefs window so I think a separate window will probably be better. And since the "Edit external commands" window already features quite a lot of what we need for the design I propose here, I think it is be better to copy it, even though it means that the parts relevant for presets management will be there first. Also, this way, there is no need for a "(current)" preset. So,...
-
(Note: Assuming Arch and Xorg here. Not sure about Wayland but displaycal does not work properly when doing stuff with a colorimeter via xwayland. At least it used to be that way, not sure how things are today.) If monitor profile detection needs to be tested, use dispwin -I profile.icc (package argyllcms) to set the monitor profile. If successful, xprop -len 14 -root _ICC_PROFILE (package xorg-xprop) has something meaningful to say. There is an experimental function in PIL that detects a monitor...
-
Motivated by the scenarios described earlier, I would like to specify how I think color management should be controlled by the user. Let me first define some hypothetical GUI elements just so we can express this concisely. (How they will be implemented exactly is not important at this point.) A profile selector (PS) lets the user select between predefined profiles like "sRGB", indirectly defined profiles like "use default" or "use embedded" profile, and explicitly selected (ICC) profiles stored in...
-
Thanks for your animation experiments. According to https://github.com/python-pillow/Pillow/commit/f84684931d3e3ec0c9f6e1ff263fe7e51ee24013 , if I understand it correctly, a frame has a dict-like memberinfo with maybe a key duration. Maybe that helps understanding how the animation stuff in PIL works. If you feel like improving the image loading algorithm of MComix such that PIL can be used as an additional provider for animated images. that would be great! Also, it should probably go to its own...
-
For the record: It says that the MR is "merged" now without any issues. No noticable change in the repo compared to before the click.
-
Try to fix random failure to restore window geometry
-
It's not merged in the (remote) master yet, is it? It is already merged. If you go to the "Git" tab in the web interface, it will tell you that master is already at [d2e9eb]. Whatever, I will click on that button just to see what will happen.
-
Thanks for the separate MR. For some reason, SF still says that I could merge it in the web interface despite having it already merged locally and then pushed. Is it safe to press the "Merge" button in the web interface? Or should I just ignore it and close this MR with status "merged"?
-
I'm afraid it won't work. No problem, and thank you for trying. So, I think we'll have to live with hack of changing the priority of the two providers. Or maybe PIL should always be the default provider. And given that image enhancements are applied by converting pixbuf to PIL and back to pixbuf, maybe the conversion to pixbuf could be done later? I would not mind using PIL first, given that it seems more powerful in so many ways. The only real downside I see is how (currently) the conversion to...
-
Thanks for the crash course. The intent, and to some extent the math, is relatively clear, So we are on the same page, which is good. but when it comes to when and how each profile should (or actually is) taken into account, I have the impression it's the wild west, and each program/library does whatever. Also on the same page, unfortunately. :-( I have put the preference in a new tab. Thanks. My experience tells me that there are several different aspects of real-world scenarios to consider: Some...
-
Unfortunately, no, I'm not knowledgeable in either Pillow or color management... Under those circumstances, your code looks quite impressive! I mean, I know enough to figure out that some CMYK images are displayed wrong, track it down to images with embedded profiles and find a way to apply/use the profile "on the fly" without re-encoding the image. I see. But I still don't understand color profiles and their quirks. I am not an expert on that, either, more like an intermediate, but if we combine...
-
Unfortunately, no, I'm not knowledgeable in either Pillow or color management... Under those circumstances, your code looks quite impressive! I mean, I know enough to figure out that some CMYK images are displayed wrong, track it down to images with embedded profiles and find a way to apply/use the profile "on the fly" without re-encoding the image. I see. But I still don't understand color profiles and their quirks. I am not an expert on that, either, more like an intermediate, but if we combine...
-
I'm having a look at it. By the way, the current MR still points to the previous commit. Not sure whether you can update the MR, but you probably should (if you can, that is).
-
I am sorry for the delay. Your MR looks like a good starting point for proper color management in MComix. You seem knowledgeable when it comes to Pillow and color management in general, so it would be great if you could help us here. I tested your MR a bit and, apparently, toggling the checkbox does not seem to work. Normally, when changing a setting in the prefs, the change is applied immediately. (To work around this issue with the current MR, re-caching images appears to be the minimum necessary...
-
Thank you for your MR, I will have a look into it.
-
Pillow version check error
-
Thank you for your report. Indeed, the bug you ran into has already been fixed: [bugs:#138] EDIT: Sorry, I somehow missed the very first line you posted that mentions the fixed bug in question.
-
Thank you for your report. Indeed, the bug you ran into has already been fixed: [bugs:#138]
-
Update: Further observation suggests that only AVIF files are affected. Thus, it might be an issue with a third-party lib. Using Arch Linux here, not sure which package might be responsible. I tried experimenting a bit but could not yet reach a conclusive answer. Any help is appreciated.
-
Supported images sometimes fail to load
-
Color management
-
Linear light
-
RuntimeError on python 3.13.5
-
Thank you for your bug report. Fixed.
-
Move multiprocessing initialization out of functions
-
Thank you, gpz, for pointing out that the monitor should already be capable of that. After some experimenting, I came up with what essentially amounts to creating a file myscript.mon containing until $1234 warp off and then launching x64sc like x64sc -moncommands myscript.mon -warp … which is exactly what I was looking for.
-
Continue warping after RUN
-
Thank you for the explanation. I ran into issues with GTK 3 (probably more than with GTK 2) myself, so I kind of feared it would be that complicated. The one thing that really is a bug here IMHO, is that the "automatic syncing" still happens, even when caps lock is not mapped to shift lock. It is however not trivial to fix, because the code where this is done doesn't even "know" about the mapping at all (right now anyway). I see. That would also be the bug that makes it difficult to emulate SL using...
-
It is only ever "not pressed" ("high") in the last of your 4 cases (so it behaves different than capslock typically does). Thank you for the clarification. So what is your OS? :) Arch Linux. please open a bug ticket about that sync issue when changing focus - it is probably not taking the remapping into account Here you are: [bugs:#2134]
-
Shift Lock depends on Caps Lock state even without binding
-
That I remember (along with the sound when it locks into place), thanks. My question is when exactly the line is affected: unlocked → pressing key down → line is low/high? unlocked → releasing key → line is low (because the key is now locked) locked → pressing key down → line is low/high? locked → releasing key → line is high (because the key is now not locked anymore, unless you also hold down the normal left shift key)
-
I experimented a bit with a customized VICE keymap and … it's complicated. Apparently, pressing the newly assigned shift-lock-emulating host key (KP_Subtract, by the way, I replaced Caps_Lock 1 7 64 with KP_Subtract 1 7 64) works as advertised and desired: The emulator's internal state is toggled whenever I press the key down.¹ However, whenever the mouse cursor enters or leaves the emulated screen area (this includes the gray padding area) or focus is gained or lost, the emulator's internal state...
-
(What kind of keyboard is this that doesnt have capslock?) Japanese keyboard layouts, for example, feature a key that works differently but is located where many other layouts feature a caps lock. In my case, the "caps lock" key has a different purpose. Instead, just make yourself a custom keymap and map "shift lock" to some other key (that you don't need in VICE) By "custom keymap" you mean a customized version of one of the gtk3*.vkm files, correct? That might be a way to work around the issue....
-
(What kind of keyboard is this that doesnt have capslock?) Japanese keyboard layouts, for example, feature a key that works differently but is located where many other layouts feature a caps lock. In my case, the "caps lock" key has a different purpose. Instead, just make yourself a custom keymap and map "shift lock" to some other key (that you don't need in VICE) By "custom keymap" you mean a customized version of one of the gtk3*.vkm files, correct? That might be a way to work around the issue....
-
Make shift-lock indicator clickable
-
I just set up a Wine environment and installed 3.1.0 there. Looks fine, still not able to replicate.
-
Actually, I do not know what it is like to program in Python on Windows (also considering dependency issues and all), and I do not have a Windows machine available for testing, but I guess it would be far from simple, which is why I am sorry for having bothered you. I wonder whether there is another way to replicate this issue.
-
Thank you for all the information. Let me summarize: Windows, version 2.0.0 or higher (version 3.1.0 also affected, but version 1.2.1 works fine), probably specific to the magnifying glass, probably unrelated to DPI issues, probably unrelated to the image format, not just animation rendering artifacts or anything similar. (Note to self: I just tested with GDK_SCALE=3 which does show yet another bug, but at the same time, it demonstrates that the flickering issue is unrelated.) Is it possible for...
-
Could you please try different values for "animation mode" (see Preferences→Advanced)? Do they have an influence? If that did not help: A lot happened between 1.2 and 3.1.0, so we might need to find the first version that introduces the issue. Could you please try 2.0.0? I suspect it to be a GTK+ 3 thing which MComix uses since 2.0.0. Another thing that might have an influence here, at least on Windows, is display DPI scaling. Could you please try different settings there? (You might want to note...
-
Thanks for the info. If the issue persists even when using the L key instead of the middle mouse button, it probably means that it is not directly related to the middle mouse button malfunctioning or anything like that. Maybe something with the mouse cursor somehow disappearing and reappearing for some reason. I wonder whether it has something to do with display DPI. Anybody here who knows whether GTK3 has its own notion of display DPI such that it might conflict with Windows' notion of display DPI?...
-
Thank you for reporting a potential bug. Do you hold down the middle mouse button to activate the magnifying glass? Or do you press the L key to turn it on and off? Does it make any difference with respect to that strange behavior? Do you notice any differences between different moving speeds? If you move very, very slowly, will the magnifiying glass always eventually be rendered? Or are there cases where the mouse cursor arrives at a new position, you stay at that position, but no matter how long...
-
Looks good to me. Merged. Thank you for your contribution.
-
Eliminate deprecated Gtk.VBox and Gtk.HBox
-
That's great! Do you mind sharing with us the location where inside your home folder you have found the config file? This might also help other users with similar questions. Thank you in advance.
-
Unfortunately, for technical reasons, binding keys via the GUI is somewhat limited at the moment, as you have noticed. Luckily, there is a workaround. You should find the keybindings.conf file somewhere in your user directory. (I do not use Windows so I do not know the specific path. It is probably somewhere below AppData or similar, but I am not sure.) There, you can change the key bindings directly. However, you should make sure to close all MComix instances beforehand, otherwise, the file will...
-
Thank you for your feedback, @aasa and @ferd617, it is quite helpful. It seems that I need to clarify some terms I used, as they really are ambiguous in this context. There are at least two different notions of current. The first one is current as in "currently selected page". The thumbnailer indicates very well which page is the current one according to this first notion. It is (currently) also the one that is used by "Open with", albeit not explicitly indicated as such in the UI. For what we are...
-
Good news! By (almost) pure chance, I stumbled across https://docs.gtk.org/glib/const.PRIORITY_HIGH_IDLE.html where the description just happens to hint at the solution: By changing line 87 to use priority=GLib.PRIORITY_LOW, some revalidation seems to take place before the actual drawing function is being called again. It still needs some fine-tuning, though, since the content is visibly being moved into place now, but at least it looks like I can finally solve this issue!
-
I just glued some snippets together to reduce the code needed to observe the issue. See attached file. The working directory needs to be the directory where the script is located. @ferd617 Please have a look at the attached example. It would be great if you (or anyone else) could fix that bug. I already tried some things, as noted in the code, but to no avail.
-
Now that I think about it, maybe we can work around this issue by adding a new feature. In this case, it would be a new preference so the user can set the width of the viewport scrollbars. With that in place, we do not need to wait for the toolkit to lay out the widgets so we can re-read the viewport's dimensions, but instead, we can calculate everything at once. … Which might not actually solve the main issue here. I am not sure. GTK 3 is confusing to me. Help?
-
The way I understand it, it will be quite cumbersome to address this issue directly because, given the way MComix currently works, for each page-related navigation action, we would need to ensure that there is a similar action incorporating a single-page variant. Also, modifying shortcuts would become more complicated for the user, and there would be even more possible shortcuts to be wasted, more shortcuts to memorize and more to choose from whenever navigating. Therefore, I propose something completely...
-
@aasa: Thank you for pointing out an inconsistency in the wiki. It certainly needs an update. Apart from the wiki, the main issue here is how the proposed change fits into MComix the way it currently works. I am currently thinking about it.
-
Simplify "layouts" to "pages"
-
Minor refactoring
-
Update changelog
-
Tweak "Fit to size" defaults
-
Allow different settings for wide and non-wide layouts in "Fit to size" mode
-
Allow both width and height to be set in "Fit to size" mode
-
Allow users to enter a size up to RENDER_SIZE_LIMIT in "Fit to size" mode
-
Introduce constants.RENDER_SIZE_LIMIT
-
Fix typo
-
Fix some UTF-8 surrogate errors
-
I see. I just had a look into some Python scripts I made for GIMP to automate stuff (not icon-related), hoping that I might find an easy way to automate it. However, it turns out that they are still Python 2. Apparently, Python 3 will be supported in GIMP 3.x which is not yet released, and the interface might change a lot between versions. Until then, we better stick to doing it manually, apparently. So, it would be great if you could add instructions that describe how to create all the raster image...
-
Thanks for the PR. Few things I noticed: Is there a way to generate all the different raster image files automatically or semi-automatically using a shell script or something? I think artwork/mcomix-large.png should be renamed to indicate that it exists only for historical reasons. Maybe something like artwork/mcomix-large-old001.png? Or maybe entire subdirectories to store all the old versions there? (I might have overlooked something, though. Just an idea, I didn't think it through.) I might add...
-
I am sorry for the late reply, being busy and all. Yes, I do like the most recent version of your SVG ( https://sourceforge.net/p/mcomix/patches/55/#b904/329e ) the most. Also, do not worry too much about that stuff regarding rendering details across different applications. I merely consider GIMP a black box for this kind of stuff. That is, even if GIMP happens to use an off-the-shelf rendering library, I would guess that their choice is better when in doubt. You kind of checked, so there is no need...
-
No problem, thank you for reporting.
-
Pillow version check error
-
Thank you for the bug report. It should be fixed with [04785a835b6c0e0782c9d0689686b0c1139febb1].
-
Update Pillow version check
-
Nice, it looks much better now, even better than the original, in my opinion. There is one detail, though, that drives me crazy, and that's Face/R.ear/path995 (the main area for the ears, not the highlight part of the ears) which is too bright at the top. From what I can see in the SVG file, it is almost white (gradient stop color fffffeff), making it look as if some kind of grease accumulated there! (Rant) This issue is more readily apparent if you use a uniform gray background instead of a black...
-
Thank you for incorporating some of the changes I proposed. The screenshot indicates that it is much better now. FYI, I can download and open the SVG you attached at the top post just fine, so please continue attaching SVG files. You're referring to the two hairs sticking out (at least, that's how I've always interpreted them) in front of each ear? I think so, yes. Actually, I was thinking of them as hairs in the beginning as well, but at some point I started thinking of them as lines supposed to...
-
Fix some string-related bugs in library
-
Thank you for going into this issue. I few comments from my side, based on my own impression: Overall shape looks good. The color of the top fur should not get brighter towards the top, I think, because it lowers contrast, making the fur less visible and recognizable as fur (compared to the skin color). The original only gets darker towards the top, which is better IMHO, evening out the bright and dark parts of the image. (Compare the histograms in GIMP to see what I mean, you will notice that the...
-
Fix preferences dialog
-
Looks good, thank you.
-
Fix PDF extractor's DPI-detection regex for recent mupdf releases
-
@aaku Very fair questions! And, apologies for the fact that this is going to turn into a bit of a treatise, but it's a rich and evolving topic. Let's see... Could you please point to examples that demonstrate that the way the differently-licensed part in _vendor is included can be observed in the wild? As in, is this the correct way to do it with respect to both reality and legality? Sure! The pip project itself, for example — which is maintained by the Python Packaging Authority, the same body that...
-
Sorry for the late reply, and thank you for your merge request. I am not well-versed (yet) when it comes to these kind of issues, so my questions might sound a bit childish here. Could you please point to examples that demonstrate that the way the differently-licensed part in _vendor is included can be observed in the wild? As in, is this the correct way to do it with respect to both reality and legality? How do you make sure that the license given in the subdirectory will not be misinterpreted as...
-
Sorry, I hope my previous post is not too convoluted. Now that I wrote about it, I can succinctly express what I think is the underlying issue here: Whenever we come to the conclusion that the current layout might be incorrect, we need to redo layout calculations, with GTK 3 immediately telling us the things we need and adjusting scrollbars as we need, and all of this needs to happen atomically. However, since it seems to not yet be the case, we run into this kind of bug.
-
First of all, what would the ideal way look like, given an imaginary Ideal Toolkit™? Let's say no book is opened, so no widgets except menu bar and status bar. Now, we open a book. First, we add the thumbnailer and make it visible. It might start adding and displaying thumbnails by itself asynchronously, but it must start with no selected thumbnail because what we see in the main area, which is empty right now, does not match any of the thumbnails. Concurrently, the first image is loaded sufficiently...
-
Thanks for butting in. This is the correct thread. :-) But I did encounter enough weirdness that makes me doubt this is a GTK bug, and feel it's very likely a bug in the MComix scroll/layout implementation. When I wrote that "This bug might be related to GTK 3", I merely wanted to express the idea that, in some ways, the bug might have something to do with GTK 3 or how MComix interacts with GTK 3, and that the bug is probably not due to faulty layout calculations on our side alone. MComix is using...
-
@ferd617 Sorry for the confusion. Here on SF, different kind of tickets are numbered independently. Specifically, I was talking about [bugs:#123], not [feature-requests:#123]. You might want to re-read my message. I hope this clears things up.
-
Minor refactoring
-
IEC, not SI
-
Improve alpha compositing (lens only)
-
Decompose matrix to more efficient transforms
-
Simplify rotation calculations
-
Keep track of image transforms, fix a lens bug
-
Move some functions and constants around
-
Add new SI prefixes
-
Update changelog
-
Rewrite lens core function
-
Introduce DOUBLE_PAGE_AUTORESIZE_FIT_SIZE, rename pref
-
Update changelog
-
Fix a new and a few known bugs
-
Indicate images distorted by stretching
-
Refactoring
-
Minor refactoring
-
Fit to size
-
FYI, I have a local version that works most of the time. However, it is still noticeably buggy as it does not work with transformations applied and starts off at the wrong position sometimes. I am trying to fix that but [bugs:#123] is certainly not helping here.
1 >
