[MX17] SMPlayer & accented characters

[k_sz]

Hello,

i've been using SMPlayer since years, on several distros so the bug described here is completly new to me.

My locale is fr_FR.UTF8 and SMPLayer doesn't recognize accented characters anymore while i'm browsing my folders to add a file/a foder to the current playlist, as showed in the screenshot below :

As you can see in the screenshot, this issue doesn't concern the rest of SMPLayer's interface ("Vidéo" is correctly accented in the taskbar while the caracter "é" is replaced with "?" in the "add a file" window).

The issue isn't only cosmetic : it keeps me from browsing or selecting a folder/a file which name includes accented caracters, I have tested other programs (Gnome PLayer, PCManFM, Thunar, Geany, Gimp, Firefox, QupZilla, Transmission, Gparted, etc) built with GTKx or QT5, and SMPLayer is the only one having this issue.

This is the first time something like this happens to me so i'm a bit lost (in translation ). It may be connected to SMPlayer being included/upgraded recently on MX 17.

[Stevo]

I didn't upgrade it yet to 18.2.2 on my more standard Debian OBS repo: https://build.opensuse.org/package/show ... t/smplayer

Can you try a downgrade? To directly download the debs, click on the "download package" link, then the Debian icon and then "Grab binary packages directly."

[k_sz]

After a

Code: Select all

sudo apt remove --purge smplayer*

i've dowloaded this .deb then i've installed it

Code: Select all

sudo dpkg -i smplayer_18.2.0-0.1~obs_amd64.deb 

and :
the whisker-menu shortcut didn't work anymore, neither did the basic command :

Code: Select all

06·03·18|20:44:17|ksz : ~
$ smplayer &
[1] 15702
06·03·18|20:44:22|ksz : ~
$ qt5ct: using qt5ct plugin
QObject::connect: No such signal MyApplication::commitDataRequest(QSessionManager)
This is SMPlayer v. 18.2.0 (revision 8910) running on Linux

'seems that there is a dpkg or symbolic-link trick i haven't used yet. Never tried to modify whisker-menu directly, though.

[Stevo]

I just did the same thing, except I use apt directly to install local debs:

Code: Select all

sudo apt ./<deb_file>

(though I have this set up in right-click actions for Thunar and Dolphin)

Anyway, I get exactly the same terminal messages as you show, but I also have the GUI come up. I'm pretty sure you grabbed the right deb, because the Debian 8 one would be using Qt 4 instead of 5.

Let me see if I can reproduce your problem on 18.2.2. We might have to take the issue to the SMPlayer support forums if it's bad enough.

[k_sz]

OK - i've removed/purged the .deb installed through <dpkg> and reinstalled it using your <apt> method : it worked !

Next step : language/themes/skins 0_0 but not tonight : time for enjoying a movie ^^ I've borrowed "Once" - my neighbour thinks i could like it.
Thanks for your help o/ tomorrow i'll test smplayer-l10n

[Stevo]

That's nice, but I really want 18.2.2 to be working.

We were talking about having the "apt" install feature for Thunar as a default in MX 17.1, but I don't think it will make it. For Dolphin, it can be added as the package kde-servicemenu-checkhash-installdebs

[k_sz]

Basically, i like to keep <apt> (i don't use <apt-get> nor <aptitude>) in the console, i don't use synaptic (except if in great despair) and i wouldn't use any file browser plugin to install a package - i firmly believe that <apt> in console is safer - i've been using synaptic/gdebi (and even the early version of Ubuntu's software-center) when Xubuntu was my DE, like 8 or 10 years ago.

Therefor shouldn't I have used automatic updates on MX, though : I surely have been cursed by the Automaton side of Nyarlathotep : the Great Elder broke SMPlayer on purpose, for sure. And no, you vicious proselyte, i won't use Dolphin nor KDE.

I think that for the newbie (let's say i'm a late noob) using the console to update the system is a good first step to domesticate the beast called OS.
(still, i'd like 18.2.2 to be working too ^^ )

[Stevo]

The right-click actions also use apt the same as you do, they just make it easier for me to install multiple interdependent debs at one time from the file browser, which I often get after building some big backport. That's something gdebi can't handle at all.

[k_sz]

I may be wrong, but the right-click menu is depending on WM + file browser and therefor : unsafety. The console and a basic and direct <sudo apt install foo foo2 foo3> are involving less intermediates (and thanks to autocomplete feature, it may propose alternatives and/or complementary pckg) and i'm pretty sure there is no waste of time.
I often use <apt search>/<apt show>, it's fast and efficient.

[Stevo]

I may be wrong, but the right-click menu is depending on WM + file browser and therefor : unsafety. The console and a basic and direct <sudo apt install foo foo2 foo3> are involving less intermediates, and i'm pretty sure there is no waste of time.

Nope, the actions just open up a terminal and pass the "sudo apt install ./local-deb-file-with-very-complex-name#1 ./local-deb-file-with-very-complex-name#2
./local-deb-file-with-very-complex-name#3
./local-deb-file-with-very-complex-name#X .... " to it, which is much simpler for me. I'm not talking about installing them from a repo as in your example, because they don't exist in any repo yet. They have to be installed either with dpkg and then get fixed afterwards, or one at a time in the correct order with gdebi.