KDE Applications 18.12 Released With File Manager Improvements, Konsole Emoji

[phoronix]

Phoronix: KDE Applications 18.12 Released With File Manager Improvements, Konsole Emoji

The KDE community is out with an early holiday presents for its users: KDE Applications 18.12 is shipping today...

http://www.phoronix.com/scan.php?page=news_item&px=KDE-Applications-18.12

[tildearrow]

Typo:

a new Kirgami Gallery

I think I will have to publish a custom build of and use downstream Gwenview patched with HiDPI support, as the bug report doesn't get much attention and it's not good, because people with HiDPI monitors expect good impressions (such as crisp pictures because this is one of the main purposes of them) but sadly, when opening Gwenview, all they see is a freaking pixelated image, even when scaling down!
I mean, despite they have been working hard on HiDPI support for 95% of the UI (and it's really good at this point), they miss one of the killer apps (the image viewer), and that's not good...
This is why I haven't used Gwenview for a long time... but I want to go back to it because it just feels weird to use this GNOME app (EoG) inside KDE only because it does have proper HiDPI support (with a minor issue: when the image is set at 50%, it looks "anti-aliased")...
Another way I could work around this is by forcing no scaling on Gwenview, but that will just... no. It's horrible to have very small icons, aaargh don't make me remember of the Qt4 support era, in which I had Qt4 installed which has NO HiDPI support at all and as such I marked it as obsolete, yet some applications in 2018 still rely upon this thing and therefore had to uninstall them... (GTK+ 2 is OK-ish, because there is this oomox hack that scales UI elements 2x (it is useless on Inkscape tho))

End of rant

[Danny3]

Too bad that the the thumbnail preview probably still can't show cover arts from mkv files
Something like this:
https://forum.videohelp.com/threads/...t-in-Windows-7
It will be really nice to have something like this for videos too besides images.

I'm not really a big fan of emoticons, but I think it's good to have them supported on the command line too.
I think this will be great for the comments in git or other VCS and also for scrips output.
Probably they are good to be put also in front of commands results.
I think someone can understand very easily the result of a command by seeing a sad or happy face even if the following text is not translated and cannot be understood.
But of course I don't know how doable this is, since the output of a command can be piped into another that one might break on emoticons. so I believe this will need more thinking.

For switching between terminal tabs, I would not put the mouse back / forward, but rather the scroll wheel.
This makes a bit more sense to me.

I like that the default text editor will show line numbers by default. I always had to enable that one manually.

For the default image viewer, I wish that they will make by default the scroll wheeel to zoom-in / zoom-out without pressing I don't remember which additional key, like in windows.
Also here the mouse back and forward buttons would be good for next and previous picture, if it's not already like that.
I don't remember very well, but I think that last time I tried to open a .svg image, it was opening with the text file instead of the image viewer. I hope they will fix that too, if it's not already fixed.

I'm very happy to hear that they added a chess game too.
I hope to see more mind training games in the future.

Anyway, congratulations to all KDE developers and thank you for making me a proud KDE user!

[miabrahams]

I got a chuckle from "cat cat."

[carewolf]

Typo:



I think I will have to publish a custom build of and use downstream Gwenview patched with HiDPI support, as the bug report doesn't get much attention and it's not good, because people with HiDPI monitors expect good impressions (such as crisp pictures because this is one of the main purposes of them) but sadly, when opening Gwenview, all they see is a freaking pixelated image, even when scaling down!
I mean, despite they have been working hard on HiDPI support for 95% of the UI (and it's really good at this point), they miss one of the killer apps (the image viewer), and that's not good...
This is why I haven't used Gwenview for a long time... but I want to go back to it because it just feels weird to use this GNOME app (EoG) inside KDE only because it does have proper HiDPI support (with a minor issue: when the image is set at 50%, it looks "anti-aliased")...
Another way I could work around this is by forcing no scaling on Gwenview, but that will just... no. It's horrible to have very small icons, aaargh don't make me remember of the Qt4 support era, in which I had Qt4 installed which has NO HiDPI support at all and as such I marked it as obsolete, yet some applications in 2018 still rely upon this thing and therefore had to uninstall them... (GTK+ 2 is OK-ish, because there is this oomox hack that scales UI elements 2x (it is useless on Inkscape tho))

End of rant

Qt 4 can also scale, but you have set correct DPIs then for the styles and fonts to scale, and icons and images usually won't

[mzs.112000]

Typo:



I think I will have to publish a custom build of and use downstream Gwenview patched with HiDPI support, as the bug report doesn't get much attention and it's not good, because people with HiDPI monitors expect good impressions (such as crisp pictures because this is one of the main purposes of them) but sadly, when opening Gwenview, all they see is a freaking pixelated image, even when scaling down!
I mean, despite they have been working hard on HiDPI support for 95% of the UI (and it's really good at this point), they miss one of the killer apps (the image viewer), and that's not good...
This is why I haven't used Gwenview for a long time... but I want to go back to it because it just feels weird to use this GNOME app (EoG) inside KDE only because it does have proper HiDPI support (with a minor issue: when the image is set at 50%, it looks "anti-aliased")...
Another way I could work around this is by forcing no scaling on Gwenview, but that will just... no. It's horrible to have very small icons, aaargh don't make me remember of the Qt4 support era, in which I had Qt4 installed which has NO HiDPI support at all and as such I marked it as obsolete, yet some applications in 2018 still rely upon this thing and therefore had to uninstall them... (GTK+ 2 is OK-ish, because there is this oomox hack that scales UI elements 2x (it is useless on Inkscape tho))

End of rant

If you have a custom patch that enables, HiDPI support, why not create a Phabricator account and submit said patch? Does it break anything? If it doesn't break anything *and* it improves the user experience, then submit it. If it gets accepted, then mainline Gwenview will benefit.

[tildearrow]

If you have a custom patch that enables, HiDPI support, why not create a Phabricator account and submit said patch? Does it break anything? If it doesn't break anything *and* it improves the user experience, then submit it. If it gets accepted, then mainline Gwenview will benefit.

Because such a patch already exists

That patch isn't getting accepted yet, however...

[Djhg2000]

I for one live in the terminal to escape the messy world of graphics. On top of that if there's anything I've learned from the Android apps with emoji support, it's that they are ambiguous when nobody wants to copy one of the existing set of graphics.

For instance I have 5 emojis which look like a happy face, but on the other end one of them is smiling, another is laughing, one of them is probably blushing and the others are utter wildcards. I have reverted to the classic ASCII-art smileys because at least they appear the same in some environments.

On top of that, emojis are supposed to have color modifiers now. Not just any modifiers either, it's a scale of real world skin colors. So now I can't just replace the set of emojis with dark variants because my retinas shall be punished for not adhering to the post-GUI tradition of studio light backgrounds. But hey, at least we can yap on and on about how using the skin colors isn't politically correct when they're out of context.

I hope I can either disable the emoji support or rip it out of the source, because I really like Konsole, but if it comes to it I'll go back to either gnome-terminal, terminology or xterm.

Before you ask; if I were any saltier I'd be a giant rock.

[Shiba]

Too bad that the the thumbnail preview probably still can't show cover arts from mkv files
Something like this:
https://forum.videohelp.com/threads/...t-in-Windows-7

GNOME does this by default.

[Danny3]

GNOME does this by default.

That's very nice, thanks for reporting!
Too bad I can't stand Gnome's mindset:
Our way or the highway!
I always choose the highway when I'm forced into something.
I hope that KDE will have this too one day.