#85 windows: localized "close" button despite language set to English

[Soukyuu]

This is with both 1.00 and 1.01.
My region setting is set to German, locale for non-unicode programs to Japanese. By default, MComix starts in German. I have switched the language to English and restarted. Preferences dialog still has "close" as "schließen" (German).

After testing some more it seems that the "close" button is not changing language no matter which one I select for the UI - it's always localized to German.

A similar thing happens to the "shortcuts" tab, it always stays English (I'm guessing it's not localized yet)

win8.1 x64.

[Soukyuu]

More strings that are always localized:

• Library -> "last opened"
• Library -> "open"
• Bookmarks -> edit bookmarks -> "remove" and "close"
• Open dialog
• File -> open with -> edit commands -> "add" "remove" "up" "down" "save"

[j santos]

This happens to me also. The text is on English but the buttons Close, Open, remove, cancel... appear in Portuguese.

[Benoit Pierre]

OK, 2 issues with locales handling in MComix:

• the translations are not up-to-date: patches welcome!
• when the language preference is not set to "auto", we change MComix locale, but not GTK: so when a stock button is used (e.g. "Close" in the preferences dialog), or when widget labels are set by GTK (e.g. in the "Open" dialog), the language is set according to the region settings

Attached is a Windows build with a patch to fix the second issue, would you mind testing it?

[Soukyuu]

With that build everything is fine except Library -> "last open" is still localized.

I know windows is a pain in the rear when it comes to this, but is there a way to base the language on the display language, not the regional settings?

[Benoit Pierre]

With that build everything is fine except Library -> "last open" is still localized.

Your talking about the collection, right? That collection name is set at creation (localized), and never changed after that. So if you switch languages, the value stays the same.

I know windows is a pain in the rear when it comes to this, but is there a way to base the language on the display language, not the regional settings?

You're talking about a Windows setting?

[Soukyuu]

Your talking about the collection, right? That collection name is set at creation (localized), and never changed after that. So if you switch languages, the value stays the same.

I see. Deleting the DB and restarting now shows the English "Recent" now. The approach is not really optimal, the db should be renamed accordingly after language switches, especially since the user is not allowed to do it manually. Else it sticks out like a sore thumb

You're talking about a Windows setting?

It's not really a setting per se. Basically, the UI language and regional settings are separate. So on my system I use the English UI with German regional settings and Japanese locale for non-unicode programs. Most programs detect my region being set to Germany and use German as their default language.

Which leads to a mix of German and English UI across the apps, and why I was wondering if you could check for UI language used instead of region when deciding which language to use in auto mode.

[Benoit Pierre]

Your talking about the collection, right? That collection name is set at creation (localized), and never changed after that. So if you switch languages, the value stays the same.

I see. Deleting the DB and restarting now shows the English "Recent" now. The approach is not really optimal, the db should be renamed accordingly after language switches, especially since the user is not allowed to do it manually. Else it sticks out like a sore thumb

Agreed, please create a ticket so we don't loose track of this.

You're talking about a Windows setting?

It's not really a setting per se. Basically, the UI language and regional settings are separate. So on my system I use the English UI with German regional settings and Japanese locale for non-unicode programs. Most programs detect my region being set to Germany and use German as their default language.

Which leads to a mix of German and English UI across the apps, and why I was wondering if you could check for UI language used instead of region when deciding which language to use in auto mode.

OK, I'll see if I can use something like this and upload a test build (I'm not sure I'll be able to test this with Wine).

Any other issue (not related to locales) with the build I uploaded? I switched to another version of PyGTK (the one provided by PyGObject for Windows, so I'm interested in any feedback when used on a real Windows machine. It's also based on my latest development branch, so if you can reproduce any of the issues mentioned in [#84] (other than password protected 7z archives and animated Gif), I would like to know.

[Soukyuu]

I'm seeing an issue with 7z archives where a console window is opened for 7z for some reason. It pops up in front of the fullscreen window as well and closes once extraction is finished. This wasn't there with older builds.

There is also some kind of problem with big .rar archives. Browsing stalls to a crawl, about one picture per 2 seconds and it says "not responding" now and then.

[Benoit Pierre]

I'm seeing an issue with 7z archives where a console window is opened for 7z for some reason. It pops up in front of the fullscreen window as well and closes once extraction is finished. This wasn't there with older builds.

Can you add the attached w9xpopen.exe to the MComix directory, and see if the issue persist, please?

There is also some kind of problem with big .rar archives. Browsing stalls to a crawl, about one picture per 2 seconds and it says "not responding" now and then.

And it was fine before? Can you explain what you mean exactly by browsing? Also, if you launch MComix from a console with "-W all", do you get any errors?

[Soukyuu]

Can you add the attached w9xpopen.exe to the MComix directory, and see if the issue persist, please?

Yes, nothing changed.

And it was fine before? Can you explain what you mean exactly by browsing? Also, if launch MComix from a console with "-W all", do you get any errors?

With 1.00 it's fluent, mostly. With 1.01 the thumbnails don't seem to appear. With 1.2.dev0 I can't go to next/previous file fluently, it takes several seconds to do so and gets progressively slower. The thumbnails then start to appear, about 10 at a time. Going through the pages faster than the thumbnails appearing will lead to slowdown/hang until the next group loads.

Feels like the extraction is too slow. The .rar is not a RAR5, there are about 200 .jpg with a resolution of 3000x3000 in the archive.

[Benoit Pierre]

Is it better if you change the "max threads" settings to 1 in preferences.conf?

[Soukyuu]

No, no difference. Forgot to say, no warnings or errors with -W all

[Benoit Pierre]

OK, please try the attached build:

• I changed locale detection to use GetUserDefaultUILanguage, and added some traces, let's see if it picks the right language now
• I added some missing PIL modules (hidden imports not picked up by PyInstaller), does it improves the performance?
• I also added a hidden "use pil" preference, you can try to set it to false, and see if the performance is better when using GDK Pixbuf to load images

If the performance is still crap, I'll build another version with the Python profiler enabled.

[Soukyuu]

• UI language detection works well!
• performance is still crap without disabling pil.
• "use pil"=false is much, much better. browsing feels fluent again.
• there is still the issue of fullscreen switch not working correctly if starting in fullscreen -> load file/archive -> press F (or view->fullscreen). What happens is that MComix leaves fullscreen, but the window is oversized - the view area is set to fullscreen resolution so the borders/window decoration are out of range. I suspect this has to do with scaling the window to fit the contents somehow

[Benoit Pierre]

• UI language detection works well!

Great!

• performance is still crap without disabling pil.
• "use pil"=false is much, much better. browsing feels fluent again.

Did you change "max threads" back to 3?

1.00 was already using PIL instead of GDK Pixbuf to load images, so something is still wrong.

With 1.01 you never get any thumbnails?

• there is still the issue of fullscreen switch not working correctly if starting in fullscreen -> load file/archive -> press F (or view->fullscreen). What happens is that MComix leaves fullscreen, but the window is oversized - the view area is set to fullscreen resolution so the borders/window decoration are out of range. I suspect this has to do with scaling the window to fit the contents somehow

Fullscreen support is another can of worms...

[Soukyuu]

Did you change "max threads" back to 3?
1.00 was already using PIL instead of GDK Pixbuf to load images, so something is still wrong.

if you mean in the .conf, then I left it at 3. I misunderstood and thought you meant the extraction threads setting, which I've set to 4 -> 3 -> 1 -> 4 when you asked me to test. It did not affect the "max threads" setting, so I'm guessing they're separate.

Setting that one to 1 makes things fluid with PIL, but PIL disabled is still faster. Actually, setting "max threads" to 3 also makes 1.00 be laggier, but still better than 1.2

With 1.01 you never get any thumbnails?

I'm not sure what it depends on, but it seems to depend on archive size. For this archive with 1.01, I had to wait about a minute until the first thumbnails stated to appear. 1.00 takes about 6 seconds. 1.2dev1 about the same, but it hangs for a bit first. This is with "max threads"=3

With "max threads"=1, 1.00 takes 2 seconds, 1.01 takes 8 seconds and 1.2dev1 takes 8 seconds as well to display the first thumbnail. Disabling use of pil reduces that to <1 second.

So 1.2dev1 with pil disabled is faster than 1.00

[Soukyuu]

Fullscreen support is another can of worms...

Actually it looks like it's an issue that appeared since 1.01 as well. 1.00 correctly exits fullscreen to the last windowed dimensions... =/

[Benoit Pierre]

I'm not sure what it depends on, but it seems to depend on archive size. For this archive with 1.01, I had to wait about a minute until the first thumbnails stated to appear. 1.00 takes about 6 seconds. 1.2dev1 about the same, but it hangs for a bit first. This is with "max threads"=3

With "max threads"=1, 1.00 takes 2 seconds, 1.01 takes 8 seconds and 1.2dev1 takes 8 seconds as well to display the first thumbnail. Disabling use of pil reduces that to <1 second.

So 1.2dev1 with pil disabled is faster than 1.00

When you say it hangs for a bit first, do you mean the first few thumbnails get created, then a pause, then the rest? Because the thumbnails creation is faster (than in the previous versions), and so with a "slower" archive, thumbnails creation will quickly catch up to the extraction thread, hence the pause.

The switch to PIL was originally done because of a regression in GDK Pixbuf leading to slow image decoding times (see this thread on the GTK list), the version from PyGObject does not suffers from this, as confirmed by your test, which is very good news. We may be able to switch back to GDK Pixbuf, and simplify the code.

Fullscreen support is another can of worms...

Actually it looks like it's an issue that appeared since 1.01 as well. 1.00 correctly exits fullscreen to the last windowed dimensions... =/

Ah! That's a good thing to know. I'll take a look.

[Soukyuu]

When you say it hangs for a bit first, do you mean the first few thumbnails get created, then a pause, then the rest? Because the thumbnails creation is faster (than in the previous versions), and so with a "slower" archive, thumbnails creation will quickly catch up to the extraction thread, hence the pause.

No, it's hanging right after opening the archive. It displays the first page, but the thumbnailer is empty. Then, after some time they start to load (pausing now and then).

[Benoit Pierre]

Mmm, weird... Do you have an idea of how long it takes to extract each page? (Check the timings in the traces when run with "-W all")

[Benoit Pierre]

Also, is that when starting reading on the first page? Or do you start reading on another page? And is the archive solid?

[Soukyuu]

I don't think there is a "solid" RAR archive, at least I don't see it mentioned anywhere. There are also nothing that looks like a trace when I run it with "-W all". The freeze is happening right after loading the archive, so the dialog window asking me if I want to resume or not is frozen as well.

[Benoit Pierre]

I don't think there is a "solid" RAR archive, at least I don't see it mentioned anywhere.

There is ("rar -s" at creation).

There are also nothing that looks like a trace when I run it with "-W all".

Right, I think it's normal: I ask PyInstaller to disable creation of a console window for standard input/output at run time. Adding a logfile option might be a good idea.

The freeze is happening right after loading the archive, so the dialog window asking me if I want to resume or not is frozen as well.

Okay, let's put this issue aside for now, since it works fine without PIL.

Can you try the attached build, see if fullscreen support works better? Thanks.

[Soukyuu]

I don't think there is a "solid" RAR archive, at least I don't see it mentioned anywhere.

There is ("rar -s" at creation).

Hmm well, there is no option in the GUI to set it, or I'm blind. So if it's not set by default, then I guess it's not a solid archive. I can extract single files from that archive without it going through the whole archive as it usually happens with solid archives, so I don't think it's.

Can you try the attached build, see if fullscreen support works better? Thanks.

Yes, it seems to behave as it did with 1.00 now. Now it only has to stop popping up those 7z.exe windows

[Benoit Pierre]

I don't think there is a "solid" RAR archive, at least I don't see it mentioned anywhere.

There is ("rar -s" at creation).

Hmm well, there is no option in the GUI to set it, or I'm blind. So if it's not set by default, then I guess it's not a solid archive. I can extract single files from that archive without it going through the whole archive as it usually happens with solid archives, so I don't think it's.

Indeed, probably not a solid archive.

Can you try the attached build, see if fullscreen support works better? Thanks.

Yes, it seems to behave as it did with 1.00 now.

Good.

Now it only has to stop popping up those 7z.exe windows

Do you get the same behavior when using an "open with" external command?