[Discover] [Bug 433463] Discover should de-duplicate apps whose AppStream IDs differ only by the presence or absence of the ".desktop" suffix
https://bugs.kde.org/show_bug.cgi?id=433463 Matthias K. changed: What|Removed |Added CC||matth...@tenstral.net --- Comment #11 from Matthias K. --- To make one thing super clear: This *must not* be fixed in Discover, and it also *must not* be addressed in AppStream either. No entity except for the upstream project and, in rare cases, the packager, should ever mess with the component ID. A lot of stuff is tied to it, changing is basically means renaming the project, and stripping a bunch of associated metadata. We also have pretty bad history with messing with component IDs, causing a ton of issues (so, the only place we touch them in distributions is when there is no MetaInfo file and an ID is synthesized). For the issue at hand, this is a weird one! I was looking at this using the Debian package, since that's the distro I use. On Debian, the component has the ID `org.godotengine.Godot`, so I thought maybe we rename it in the package! Turns out, that is not the case: https://salsa.debian.org/debian/godot3/-/blob/master/debian/rules?ref_type=heads#L97 So, Debian just ships the metaInfo file that upstream provides, which has the `org.godotengine.Godot` ID. So, looking at the Flatpak recipe, for some reason Flatpak does *not* use the upstream-provided MetaInfo file, but provides its own one! And look at that: https://github.com/flathub/org.godotengine.Godot/blob/master/org.godotengine.Godot.appdata.xml#L3 => It has the "wrong" ID, diverging from upstream! Funnily enough, the Flatpak itself is named `org.godotengine.Godot`, so I see no reason at all for this weird diversion... Maybe it had something to do with appstream-glib in the past before Flatpak switched to libappstream, but that would be odd... In any case, this goes completely against what MetaInfo files are designed for, upstream is supposed to provide them, and packagers may only provide one if upstream doesn't have one. So, tl;dr, this is not a Discover bug or AppStream or Flatpak bug, but a bug in the Flatpak bundle. IMHO the downstream MetaInfo file should just be deleted and the one from upstream should be used instead, that's what it's for! (and if anything is missing, just contribute the metadata upstream!) At the very least, the component ID should be harmonized with what upstream ships though. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 481912] Feature request: Wayland remote login sessions with Plasma, like xrdp
https://bugs.kde.org/show_bug.cgi?id=481912 Matthias K. changed: What|Removed |Added CC||matth...@tenstral.net -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 481912] New: Feature request: Wayland remote login sessions with Plasma, like xrdp
https://bugs.kde.org/show_bug.cgi?id=481912 Bug ID: 481912 Summary: Feature request: Wayland remote login sessions with Plasma, like xrdp Classification: Plasma Product: plasmashell Version: master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Session Management Assignee: plasma-b...@kde.org Reporter: matth...@tenstral.net Target Milestone: 1.0 Hi everyone! (I was asked to report the feature request here to keep track of it, since it affects multiple desktop components under Wayland) I work at a research lab where we have very powerful servers connected to large data storage via a fast link. A lot of image processing as well as simulations are run on these machines, and it is incredibly convenient as people can take a working environment with them, and we also can share an expensive system extremely efficiently among many scientists. This is how it is set up currently: 1. The user ssh-tunnels into the server they want to connect to (RDP ports are not exposed) 2. A RDP connection to xrdp[1] is created 3. xrdp-sesman[2], the session manager module of xrdp, creates a session for the user after authenticating them 4. Plasma/X11 is started for that user session and renders to the remote display, instead of an actual display If a user disconnects, the session is kept running, and they get their session back as soon as they log in again. To terminate a session, the user has to log out explicitly. We are also utilizing Apache Guacamole[3] to make this process even more convenient so people can avoid installing any additional software and get almost the same experience as if they were using e.g. Remmina[4] to connect remotely. Of course, this complete workflow will not work at all when Plasma is running on Wayland, and XRDP, as the name suggests, is very X.org-specific (it is a fantastic tool though and serves us well). In the long run it would be great if we could switch to Wayland and keep using Plasma (surprisingly, if stripped down just slightly Plasma is not much heavier than light desktops, and users like to use the desktop's tools, e.g. the Dolphin filemanager). GNOME has a remote login in the works that looks similar to what XRDP provides and works on Wayland[5], but it would be fantastic if KDE could provide a similar feature. Having any XDG portals or interactivity will not work - as soon as the user is authenticated, they should get a session noninteractively and there should not be a need to stay logged in for the session to continue to exist (the servers are headless, and if needed, the admin can always set session resource limits for users via logind). A feature like this could for example be implemented by having a system service that takes incoming RDP connections and uses SDDM to authenticate and spawn a new Wayland session that can be interacted with using the transient seat protocol. Or if SDDM is too heavy, some lightweight service to handle the session authentication part. In any case, this will require non-trivial work on a lot of components, and there's likely multiple ways to implement this feature (and it wouldn't even necessarily have to be RDP-based, but we found the protocol to be a bit more efficient than VNC in testing). Thanks to everyone for the phantastic work on Plasma! Cheers, Matthias [1]: https://www.xrdp.org/ [2]: https://manpages.debian.org/testing/xrdp/xrdp-sesman.8.en.html [3]: https://guacamole.apache.org/ [4]: https://remmina.org/ [5]: https://wiki.gnome.org/Initiatives/Wayland/Remoting#Remote_Login -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 465897] Potential problem in passing AppData translations to appstream-data
https://bugs.kde.org/show_bug.cgi?id=465897 --- Comment #8 from Matthias K. --- Ah, you are using Arch! Then this in likely an Arch Linux bug and they simply need to regenerate their data. Looking at the data for Krita, I see: ```xml Krita 是一款功能齐全的数字绘画工作室软件。 Krita 既适合起草，也适合上色细化。您可以轻松使用 Krita 从头到尾完成一副精美的画作。 Krita 是绘制概念美术、漫画、纹理和贴图接景的理想工具。它支持多种色彩空间，如 8 位、16 位整数以及 16 位、32 位浮点通道的 RGB 和 CMYK 颜色模型。 Krita 具有功能强大的笔刷引擎、种类繁多的滤镜以及便于操作的交互设计。您可以在 Krita 中高效自如地发挥创意。 Krita 是全功能的數位藝術工作室。 它是素描和繪畫的完美選擇，並提供了一個從零開始建立數位繪畫檔的端到端解決方案。 Krita 是創造概念藝術、漫畫、彩現紋理和場景繪畫的絕佳選擇。Krita 在 8 位元和 16 位元整數色版，以及 16 位元和 32 位元浮點色板中支援 RGB 和 CMYK 等多種色彩空間。 使用先進的筆刷引擎、驚人的濾鏡和許多方便的功能來開心地繪畫，讓 Krita 擁有巨大的生產力。 ``` In the newest upload from 2023-01-15 of that package. Do you have that version? Trabslations are ignored by appstream if less than three paragraphs are translated, zh-* has more, so translations should show up. The statistics stuff is an AppStream feature that lets projects expose how much localization exists for any locale, so software centers can display a 2translated into your language" badge, so users can filter for apps that are available in their language, and not just English ones. But I'm not even sure if Discover supports that yet. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 465897] Potential problem in passing AppData translations to appstream-data
https://bugs.kde.org/show_bug.cgi?id=465897 Matthias K. changed: What|Removed |Added CC||matth...@tenstral.net --- Comment #3 from Matthias K. --- What exactly is the issue here? Chinese *translations* of description text not showing up, or translation *statistics* not showing up? For the latter, looking at Krita's file @ https://invent.kde.org/graphics/krita/-/blob/master/krita/org.kde.krita.appdata.xml it is simply missing a `translation` tag - that one is essential to read translation statistics, so add one as described in https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-translation and localization statistics should show up. As for Chinese translations, I do see them in https://appstream.debian.org/sid/main/metainfo/krita.html, so they are shipped to clients, and I can also dump that data with libappstream, so it should be available - I don't know however if Chinese characters are properly tokenized for fulltext search (which should not affect display though). I didn't set my locale to Chinese, but as far as I can see from some quick tests, this should be working... -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 462186] Discover shows packages from disabled pacman repos, but download button is stuck on "Loading..."
https://bugs.kde.org/show_bug.cgi?id=462186 --- Comment #3 from Matthias K. --- This issue might be the same as https://github.com/PackageKit/PackageKit/issues/573 -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 462186] Discover shows packages from disabled pacman repos, but download button is stuck on "Loading..."
https://bugs.kde.org/show_bug.cgi?id=462186 Matthias K. changed: What|Removed |Added CC||matth...@tenstral.net -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 393012] command-line flag to temporarily prefer AppStream data from /usr/share/metainfo
https://bugs.kde.org/show_bug.cgi?id=393012 Matthias K. changed: What|Removed |Added Resolution|--- |FIXED CC||matth...@tenstral.net Status|UNCONFIRMED |RESOLVED --- Comment #1 from Matthias K. --- There is no command-line flag (yet), but you can achieve that behavior by setting `PreferLocalMetainfoData=true` in `/etc/appstream.conf`. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 387379] GNOME Tweaks is always listed at the top of the main app browse list, even on KDE Plasma
https://bugs.kde.org/show_bug.cgi?id=387379 --- Comment #16 from Matthias K. --- Maybe having a per-desktop weight to ratings applied locally makes more sense than rolling out a completely new ODRS instance - because that would mean that apps that are relevant on all desktops wouldn't share ratings anymore. Or, even better: Curate the front page of Discover by displaying a couple of predefined "featured" apps, like GNOME Software does. That would get rid of the randomness of whatever has the highest rating showing up on the front page. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 387379] Blacklist GNOME Tweak Tool when using Plasma
https://bugs.kde.org/show_bug.cgi?id=387379 Matthias K. changed: What|Removed |Added CC||matth...@tenstral.net --- Comment #11 from Matthias K. --- I don't think we should blacklist this application, or for that matter, any application in Discover or other software centers. You don't know what the users want to do with the application - maybe they have GNOME installed and witch between Plasma and GNOME? Maybe they use the tweak tool to customize the looks of GTK+ apps or other GTK+ properties? it shouldn't be a featured app, but if people look for it it should really show up. We also don't blacklist MIDI applications if the user doesn't have a musical keyboard attached. Discover should - in my opinion - reflect all the software that is available. This is also the reason why AppStream doesn't contain any means to distinguish by desktop environment - you either make an app visible in all software centers, or in none. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372763] Rename does not give options on Conflict
https://bugs.kde.org/show_bug.cgi?id=372763
--- Comment #6 from Matthias K. ---
I don't find the current behavior pleasant at all and the workaround is very
time consuming. Perhaps the behavior should be configurable if others really
appreciate the current one.
The string I use is:
[date:"MMdd_hhmmss"]_[cam]{replace:"Canon EOS 80D","EOS
80D",i}{replace:"FUJIFILM","Fuji",i}{replace:"Canon EOS REBEL SL1","EOS Rebel
SL1",i}{replace:"OLYMPUS CORPORATION","Olympus",i}{replace:"Canon PowerShot
G9","G9",i}{replace:"Canon EOS 60D","EOS 60D",i}{replace:"Canon PowerShot
S100","S100",i}
Obviously the main problem are photos with the same timestamp.
--
You are receiving this mail because:
You are watching all bug changes.
[digikam] [Bug 388437] Current photo in the Image Editor is not selected in Albums view
https://bugs.kde.org/show_bug.cgi?id=388437 --- Comment #2 from Matthias K. --- Thanks for the swift fix, Maik! A great example of the virtues open source projects can have. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372763] Rename does not give options on Conflict
https://bugs.kde.org/show_bug.cgi?id=372763 --- Comment #3 from Matthias K. --- Indeed Digikam now doesn't allow to start batch rename if there are conflicts, but that doesn't really fix the workflow problem :( My current workaround (w/ v5.6.0) is: - create a sub-directory 'tmp' and move all photos to be renamed into it - select a limited number of photos - try to rename - in case of conflicts select the first N photos without conflicts and rename them - move the renamed photos up into the actual album directory - select a limited number of photos - try to rename - in case of conflicts select the first N photos without conflicts and rename them - manually rename the first photo since it has a conflict - move the renamed photos into the actual album directory - repeat until all photos have been renamed This is extremely cumbersome compared with the previous behavior. Please provide some kind of reasonable solution. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 388437] New: Current photo in the Image Editor is not selected in Albums view
https://bugs.kde.org/show_bug.cgi?id=388437 Bug ID: 388437 Summary: Current photo in the Image Editor is not selected in Albums view Product: digikam Version: 5.6.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Albums-MainView Assignee: digikam-bugs-n...@kde.org Reporter: matth...@kaehlcke.net Target Milestone: --- When multiple photos are opened in the Image Editor the Albums view does not select the currently shown/edited photo. This was different with earlier versions of digikam (v4?). In my workflow I usually open a batch of photos in the Image Editor and then go through them for rating and tagging. Not having the current photo selected in the Albums view is very inconvenient, since it requires to check the file name and selecting it manually. Doesn't sound like a big deal, but it adds significant overhead when going through a larger collection of photos. Please bring back the previous behavior. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 384759] Can't adjust timestamp of RAW files
https://bugs.kde.org/show_bug.cgi?id=384759 --- Comment #2 from Matthias K. --- Just tried the 5.7.0 Linux AppImage, the behavior is still the same. For if others run into the same issue, exiftool can be used as a workaround: 'exiftool -alldates-=3 IMG_8117.CR2' -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 384759] New: Can't adjust timestamp of RAW files
https://bugs.kde.org/show_bug.cgi?id=384759 Bug ID: 384759 Summary: Can't adjust timestamp of RAW files Product: digikam Version: 5.3.0 Platform: Debian testing OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: BatchQueueManager Assignee: digikam-bugs-n...@kde.org Reporter: matth...@kaehlcke.net Target Milestone: --- With digikam 4 it was possible to adjust the timestamp of RAW files (at least Canon CR2, not sure about others), this fails with digikam 5. Trying to update any timestamp via the 'Time Adjust' tool in the BQM results in 'Failed to process item ...'. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372763] Rename does not give options on Conflict
https://bugs.kde.org/show_bug.cgi?id=372763 Matthias K. changed: What|Removed |Added CC||matth...@kaehlcke.net --- Comment #1 from Matthias K. --- I'm also experiencing this problem. This is a major issue, since the renaming process stalls once it encounters a conflict, thus batch renaming is broken if the batch has conflicts :( -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 376241] software centre is empty
https://bugs.kde.org/show_bug.cgi?id=376241 --- Comment #33 from Matthias K. --- This is highly likely https://bugs.launchpad.net/ubuntu/+source/plasma-discover/+bug/1663695 which should be resolved soonish. You can help fixing it by testing the AppStream package in -updates-proposed. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 376241] software centre is empty
https://bugs.kde.org/show_bug.cgi?id=376241 --- Comment #10 from Matthias K. --- Okay, so this is a Discover bug, or an incarnation of https://github.com/hughsie/PackageKit/issues/177 then. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 376241] software centre is empty
https://bugs.kde.org/show_bug.cgi?id=376241 --- Comment #8 from Matthias K. --- The AppStream information looks good. Can you find all software you need using the CLI? E.g. using `appstreamcli search web`? -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 376241] software centre is empty
https://bugs.kde.org/show_bug.cgi?id=376241 Matthias K. changed: What|Removed |Added CC||matth...@tenstral.net --- Comment #5 from Matthias K. --- Please run `appstreamcli status` and attach the output. You might also want to attach the output of `sudo appstreamcli refresh --force --verbose`. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 355507] Icons should be pre-rendered to bitmaps at build-time
https://bugs.kde.org/show_bug.cgi?id=355507 --- Comment #5 from Matthias K. --- Yes, storing bitmaps in Git would be insane... Still, the SVG images are a problem due to the issues outlines above, and compiling them to a reasonable amount of bitmaps at build-time should be easily possible. Unfortunately I have quite a lot of stuff to do at time, so creating a patch isn't at the top of my priority list - but it's on there :-) The stuff I wrote about changing the icon layout can be ignored btw, that was a quirk in the AppStream generator which has been resolved meanwhile, and there is really nothing to be gained by changing it. Although, if/when bitmaps are shipped, some layout changes would be useful... -- You are receiving this mail because: You are watching all bug changes.
