D6628: Fix and normalize license in .desktop files

mak added a comment. In D6628#676722 , @bam wrote: > Thanks for clarifying. > > In D6628#676721 , @mak wrote: > > > So, this change looks fine to me now, as it is :-) > > > And yet it was

D6628: Fix and normalize license in .desktop files

mak added a comment. In D6628#676720 , @sitter wrote: > These aren't SPDX identifiers but kaboutlicense keywords https://api.kde.org/frameworks/kcoreaddons/html/kaboutdata_8cpp_source.html#l00397 Makes sense. @bam As far as the "legacy

D25100: Mark all wallpaper plugins as addons

mak added a comment. Did this have AppStream metadata before? Probably the distribution data still lists this as component, while the new file lists it as addon. The distro data is preferred, so that's why this shows up as app. You need your distro to ship this as update, or set

D23328: Exclude other desktop file from AppStream metadata generation

mak added a comment. I didn't test this, but I wrote the code which will handle this and it works in other cases ;-) My comment was to confirm that the commit does indeed what you intend it to do, according to the spec and code. REPOSITORY R124 System Settings REVISION DETAIL

D23328: Exclude other desktop file from AppStream metadata generation

mak added a comment. Effect is `kdesystemsettings.desktop` not being shown in any software center. LGTM REPOSITORY R124 System Settings REVISION DETAIL https://phabricator.kde.org/D23328 To: ngraham, kossebau, apol, mak Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh,

D23306: Add AppStream metadata file

mak added a comment. In D23306#515666 , @kossebau wrote: > In D23306#515662 , @mak wrote: > > > In D23306#515616 , @kossebau wrote: > > > > > Thanks!

D23306: Add AppStream metadata file

mak added a comment. In D23306#515616 , @kossebau wrote: > In D23306#515609 , @mak wrote: > > > @kossebau How to hide .desktop files from AppStream is now more visible in

D23306: Add AppStream metadata file

mak added a comment. In D23306#515595 , @ngraham wrote: > In fact there are three possible relationships: > > - App is associated with desktop, but not required by it or limited to it (e.g. Dolphin, Gwenview, Nautilus, GNOME Music)

D23306: Add AppStream metadata file

mak added a comment. In D23306#515592 , @ngraham wrote: > In D23306#515589 , @mak wrote: > > > In D23306#515577 , @ngraham wrote: > > > > > Adjust

D23306: Add AppStream metadata file

mak added a comment. Adding a `project_group` may also be a nice idea: https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-project_group REPOSITORY R124 System Settings REVISION DETAIL https://phabricator.kde.org/D23306 To: ngraham, apol, mak, #plasma Cc:

D23306: Add AppStream metadata file

mak added a comment. In D23306#515585 , @kossebau wrote: > @mak: tnanks for the hint. will also see to use X-AppStream-Ignore for kdevelop then. any chance we can see this trick documented on

D23306: Add AppStream metadata file

mak added a comment. In D23306#515577 , @ngraham wrote: > Adjust according to review comments This will work. I would change `System Settings` to ` KDE System Settings` or `Plasma System Settings`, just like GNOME sets a name like

D23302: Stop installing two desktop files

mak added a comment. @kossebau You'll also want to annotate the .desktop files correctly to hide them. See https://phabricator.kde.org/D23306#515575 for details. REPOSITORY R124 System Settings REVISION DETAIL https://phabricator.kde.org/D23302 To: ngraham, apol, #plasma Cc: mak,

D23306: Add AppStream metadata file

mak added a comment. There's also a FAQ entry for this, apparently I only documented this for Debian Developers back in the day ^^ > https://wiki.debian.org/AppStream/Guidelines#How_to_exclude_.desktop_files_from_the_metadata

D23306: Add AppStream metadata file

mak added a comment. @ngraham > Alternative to D23302 . According to the AppStream documentation (https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Application.html), > adding an AppStream metadata file with multiple launchable tags

Re: freedesktop.org meeting again?

Am Mo., 11. Feb. 2019 um 00:06 Uhr schrieb Aleix Pol : > > On Sat, Feb 9, 2019 at 1:32 PM David Faure wrote: >> >> Is anyone interested in participating in a technical meeting with other >> desktop environments? >> >> I did that years ago and this is how we came up with various shared >>

D13772: Add AppStream metadata

mak added a comment. In D13772#284459 , @ngraham wrote: > FWIW, @mak, `appstrealcli validate` doesn't like my launchable tag, though I can't see anything wrong with it. > > dev@dev-pc:~/repos/ksysguard$ (appstream-metadata) appstreamcli

D13772: Add AppStream metadata

mak requested changes to this revision. mak added inline comments. This revision now requires changes to proceed. INLINE COMMENTS > org.kde.ksysguard.appdata.xml:2 > + > + > + KSysGuard Nitpick: Use `desktop-application` > org.kde.ksysguard.appdata.xml:7 > + org.kde.ksysguard > + CC0-1.0 >

D13123: Make .deb and .rpm mime type handling optional at build time

mak added a comment. Checking for the dpkg and rpm binaries isn't really foolproof, because you can install rpm on Debian and dpkg on Fedora & Co. easily. The only issue proof thing that I can imagine would be checking for the distribution name in /etc/os-release, or maybe checking for the

Re: Translations and appstream summaries

2017-12-14 23:40 GMT+01:00 David Edmundson : > Translators, > > We're getting a bunch of tests failing [1] because of a translation issue. I wonder if that's true - appstreamcli will only return a non-zero exist status if you have warnings or errors, the added dot is

Re: Missing mouse pointer in KWin on Wayland with Etnaviv

2017-10-31 10:22 GMT+01:00 Martin Flöser <mgraess...@kde.org>: > Am 2017-10-31 02:56, schrieb Matthias Klumpp: >> >> Hello! >> For a phone we obviously don't need a mouse pointer, but at the moment >> I can only interact with the UI by clicking blindly, which is

Missing mouse pointer in KWin on Wayland with Etnaviv

Hello! The past weekend I made Plasma Mobile work on our preliminary "devboard" for the Purism Librem 5 phone (which at the moment is not much more than a i.mx6 CPU with peripherals/a screen - it will be much more exciting soon). The system is running Debian Testing (Buster) with KDE libraries

Re: Videoconference between KDE community and Purism regarding Librem5

Just to make sure this message gets through to all the mailinglists (I dropped some of the CCs, because the list was rejecting this, and I also don't know if Zlatan is subscribed to plasma-devel & co.), since some people didn't get the next yet apparently This is our meeting place:

Re: Videoconference between KDE community and Purism regarding Librem5

> Sebastian Kügler wrote : > let's pin down Thursday, 19:00 CEST (9.00am PDT), in any case. For me, this would work even better :-) (But we need Todd in the meeting, so let's wait and hope he's available at that time as well)

Re: Plasma Mobile on the Librem 5 (please ignore previous two mails)

2017-09-05 12:10 GMT+02:00 Jonathan Riddell <j...@jriddell.org>: > On Mon, Sep 04, 2017 at 10:56:12PM +0200, Matthias Klumpp wrote: >> > And honestly I don't think it's something the Debian team cares about: it's >> > much more important to have the "perfect"

Re: Plasma Mobile on the Librem 5 (please ignore previous two mails)

2017-09-04 22:29 GMT+02:00 Martin Flöser : > Am 2017-09-04 19:51, schrieb Zlatan Todoric: >> >> I had pretty unstable experience with KDE in Debian, so I assume that >> KDE community will improve that in future (we need more Debian KDE >> maintainers!) ;) > > Personal opinion

Re: Plasma Mobile on the Librem 5 (please ignore previous two mails)

2017-09-04 19:51 GMT+02:00 Zlatan Todoric : > [...] > Well, for having both as separate offer (if GNOME hits the pace), is not > an issue. I am wondering if having both at the same time on phone will > end up being to much (how many libraries are there that one uses and >

Re: Plasma Mobile on the Librem 5

2017-09-03 23:17 GMT+02:00 Sebastian Kügler : > Hey Zlatan, > [...] >> so I had discussion with our CEO and he is of course absolutely in. >> To make clear our standpoint - both GNOME and KDE *will* be first >> class citizen on Librem5. So there is no favorite between two, but >>

Re: Plasma Mobile on the Librem 5

2017-08-30 9:24 GMT+02:00 Bhushan Shah <bhus...@gmail.com>: > Hello Matthias and all, > > First of all huge thanks for reaching to us! > > On Tue, Aug 29, 2017 at 03:28:36PM +0200, Matthias Klumpp wrote: >> As some of you might already know, we at Purism are planning t

Re: Plasma Mobile on the Librem 5

2017-08-29 18:39 GMT+02:00 Martin Flöser <mgraess...@kde.org>: > Am 2017-08-29 15:28, schrieb Matthias Klumpp: >> >> What we would be interested in is knowing about the future plans for >> Plasma Mobile, especially in the area of design and performance >

Re: Plasma Mobile on the Librem 5

2017-08-29 16:44 GMT+02:00 Sebastian Kügler <se...@kde.org>: > Hi Matthias, et al! > > On Tue, 29 Aug 2017 15:28:36 +0200 > Matthias Klumpp <matth...@tenstral.net> wrote: >> [ Please keep the CC list intact for replies ] >> >> [...] > > Yes, Kiri

Re: Plasma Mobile on the Librem 5

2017-08-29 15:58 GMT+02:00 Eike Hein <h...@kde.org>: > > On 08/29/2017 10:28 PM, Matthias Klumpp wrote: >> As some of you might already know, we at Purism are planning to >> develop a mobile phone that uses only free software and Matrix[2] for >> communica

Plasma Mobile on the Librem 5

, the phone, Plasma on PureOS / Debian, life, the universe, everything, please ask! Kind regards, Matthias Klumpp (Software engineer at Purism) [1]: https://puri.sm/shop/librem-5/ [2]: https://matrix.org/ [3]: https://pureos.net/ [4]: https://ostree.readthedocs.io/en/latest/ [5]: http

D7567: Support edit and appstream actions also for application search results

mak added inline comments. INLINE COMMENTS > hein wrote in actionlist.cpp:380 > That code wasn't touched during this refactoring, so this is immaterial to > the review. Please inform Aleix Pol about it. I know, that's why I didn't flag this as change request (just a general observation).

D7567: Support edit and appstream actions also for application search results

mak added inline comments. INLINE COMMENTS > actionlist.cpp:380 > + > +const auto components = > appstreamPool->componentsById(service->desktopEntryName()+QLatin1String(".desktop")); > +for(const auto : components) { This will not work, because the component-ID can be an arbitrary

D6628: Fix and normalize license in .desktop files

mak added a comment. Is there any reason not to use the SPDX license IDs here? => https://spdx.org/licenses/ (e.g. `GPL-2.0+` in this case). In any case, this patch makes things way better, so +1 from me :-) REPOSITORY R119 Plasma Desktop BRANCH master REVISION DETAIL

Re: Discover depending on unreleased Appstream

2017-06-27 10:23 GMT+02:00 Jonathan Riddell : > Plasma Discover recently got an update to use Appstream Qt API which > was itself only committed a few days ago > > https://phabricator.kde.org/D6267 Use appstream-qt insted of glib based one > >

D5405: Create desktop file name based on organization domain unless set explicitely

mak added a comment. In https://phabricator.kde.org/D5405#101574, @ltoscano wrote: > I'm still confused. Documentation or not, bad usage or not, is it correct that desktop file name is constructed from both the organization domain AND the homepage? Yes. See

[Differential] [Accepted] D4447: Add missing summaries

mak accepted this revision. mak added a reviewer: mak. mak added a comment. This revision is now accepted and ready to land. Looks good! REPOSITORY R120 Plasma Workspace BRANCH Plasma/5.9 REVISION DETAIL https://phabricator.kde.org/D4447 EMAIL PREFERENCES

[Differential] [Commented On] D3923: Make AppstreamQt optional

mak added a comment. In https://phabricator.kde.org/D3923#73574, @anthonyfieroni wrote: > In https://phabricator.kde.org/D3923#73375, @mak wrote: > > > In any case, knowing the distro might be useful to check whether their packaging makes sense ;-) > > > KaOS don't have

[Differential] [Commented On] D3943: Make sure we only initialize the appstream pool once

mak added a comment. Looks good! (appstreamPool is a bit verbose for my taste, AppStream interally calls it dpool (DataPooL) asPool or just pool - but that's just me being lazy and having to type too much n C anyways) REPOSITORY R119 Plasma Desktop REVISION DETAIL

[Differential] [Commented On] D3923: Make AppstreamQt optional

mak added a comment. @davidedmundson What do you mean with big dependency chain? libappstream and libappstreamQt depend in total on only libxml2, libyaml, GLib and Qt5Core which pretty much any distro, especially with Plasma on it, should already have anyway. Didn't you use Neon? Or was

Re: Discover requires Qt 5.7?

2016-09-22 14:36 GMT+02:00 Matthias Klumpp <matth...@tenstral.net>: > 2016-09-22 13:15 GMT+02:00 Jonathan Riddell <j...@jriddell.org>: >> On Thu, Sep 22, 2016 at 01:02:45PM +0200, Aleix Pol wrote: >>> On Thu, Sep 22, 2016 at 10:20 AM, Daniel Vrátil <

Re: Discover requires Qt 5.7?

2016-09-22 13:15 GMT+02:00 Jonathan Riddell : > On Thu, Sep 22, 2016 at 01:02:45PM +0200, Aleix Pol wrote: >> On Thu, Sep 22, 2016 at 10:20 AM, Daniel Vrátil wrote: >> > Hi, >> > >> > Discover 5.7.95 requires Qt 5.7 due to usage of qAsConst() [0], although >> >

Re: Review Request 128996: Don't generate appstream files for components that are not in rdn

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128996/#review99401 --- Ship it! Ship It! - Matthias Klumpp On Sept. 21, 2016

Re: Fix the broken plasma-desktop! Re: Jenkins-kde-ci: plasma-desktop master kf5-qt5 » Linux,gcc - Build # 326 - Still unstable!

2016-09-12 16:33 GMT+02:00 Martin Gräßlin : > Hi all, > > this has been broken now since Friday. We have several builds on it which > did not address it. This is not OK. > > It's our responsibility to keep the CI green. A CI where everybody just > ignores it, is pointless. >

[Differential] [Commented On] D1816: Switch to Noto Mono as default monospace font

mak added a comment. `Hack` and `Source Code Pro` are beautiful fonts for programming - from a Debian perspective, there is no reason to not use `Hack`, we have it in the archive already (I don't know about `Source Code Pro` though). REPOSITORY rPLASMAINTEGRATION Integration for Qt

Re: Long term support release for Plasma?

Hey :) Just a quick notice: All the judgement on this issue given by Debian and Kubuntu people apply to Tanglu as well (and we completely agree with Martin Steigerwalds post). Cheers and greetings from Debconf! Matthias ___ Plasma-devel mailing

[Differential] [Commented On] D1844: Add Appinfo metadata file

mak added inline comments. INLINE COMMENTS > org.kde.plasmashell.metainfo.xml:4 > + org.kde.plasmashell > + GPL-2.0+ > + KDE Plasma Desktop Btw, a "metadata_license" tag with a permissive license (CC0/MIT) needs to be added too, so we are sure that we can reuse the metadata downstream

[Differential] [Commented On] D1844: Add Appinfo metadata file

mak added inline comments. INLINE COMMENTS > CMakeLists.txt:158 > endif() > +install(FILES "${CMAKE_CURRENT_BINARY_DIR}/plasma-desktop.metainfo.xml" > DESTINATION ${METAINFODIR}) > feature_summary(WHAT ALL INCLUDE_QUIET_PACKAGES > FATAL_ON_MISSING_REQUIRED_PACKAGES) I might be wrong with

[Differential] [Commented On] D1844: Add Appinfo metadata file

mak added inline comments. INLINE COMMENTS > mak wrote in plasma-desktop.metainfo.xml:3 > This should ideally be a reverse-domain-name, to fit the general style of > AppStream unique IDs. > So something like "org.kde.plasmashell" or "org.kde.plasma-desktop". > See >

Re: appstream in Plasma

2016-06-13 14:54 GMT+02:00 Jonathan Riddell : > I've submitted a review for a plasma-desktop metadata file. > https://phabricator.kde.org/D1844 > But I was surprised to see the metadata format doesn't support many > types. Shouldn't something like Plasma widgets be a good

[Differential] [Updated] D1844: Add Appinfo metadata file

mak added a comment. In https://phabricator.kde.org/D1844#34142, @sebas wrote: > Should also have a screenshot? Normally I would say "yes", but since this is a so-called generic component, which means that it will be possible to search for it with cli tools and install it easily

Re: appstream in Plasma

2016-04-10 0:06 GMT+02:00 Thomas Pfeiffer : > On Samstag, 9. April 2016 20:32:24 CEST Martin Graesslin wrote: > >> If using a framework requires a workspace component being installed, >> something is seriously broken in our workflows. We have worked a lot on >> making our

Re: metadata.yaml for Plasma projects?

2016-04-07 13:55 GMT+02:00 Martin Graesslin : > On Thursday, April 7, 2016 1:21:55 PM CEST Aleix Pol wrote: >> On Thu, Apr 7, 2016 at 11:41 AM, Martin Graesslin > wrote: >> > Hi Plasmates, >> > >> > an idea for better documentation is to introduce some

Re: appstream in Plasma

2016-04-07 19:47 GMT+02:00 Martin Gräßlin : > Am 2016-04-07 18:01, schrieb Scarlett Clark: >> >> FWIW some distros like Kubuntu (neon?) use systemsettings for all of >> our system settings. So having separate places for all other settings >> is very poor user experience. > >

Re: appstream in Plasma

2016-04-07 15:08 GMT+02:00 Jonathan Riddell : > Martin's thread on metadata got me wondering about if we should have > appstream files in Plasma. It would be nice to have plasma-desktop in > software installers for people who run another desktop and want to > install it.

Re: Review Request 127308: Fix name of desktop file to have icon working on Wayland

r upgrading to > 5.6. > > Martin Gräßlin wrote: > Sorry I don't get that. Why should renaming result in losing the favorite? > > Matthias Klumpp wrote: > The favourite apps settings is a list with .desktop filenames which are > shown in the launcher. If you n

Re: two exceptions for string freeze in Plasma

First of all, I don't have a strong opinion on generic names - name the stuff whatever you want to! 2016-03-09 16:00 GMT+01:00 Sebastian Kügler : > [...] > > I find this whole discussion rather backwards. I could address the concerns by > coming up with some random bullshit name,

Re: Review Request 127308: Fix name of desktop file to have icon working on Wayland

> On März 8, 2016, 5:20 nachm., Hrvoje Senjan wrote: > > Do we want a kconf_update script with that for all hte people that have > > systemsettings.desktop as favourite in launchers? > > Martin Gräßlin wrote: > I don't think it's needed. The important part is that there is a desktop >

Re: two exceptions for string freeze in Plasma

2016-03-09 10:26 GMT+01:00 Sebastian Kügler : > [...] > I'd like to address your feedback and come to a solution everyone is happy > with, but for that, please provide suggestions what to use instead, and don't > just point out "that's bad", because the previous naming was wrong,

Re: Review Request 126732: a plymouth theme for breeze

> On Jan. 13, 2016, 2:55 nachm., andreas kainz wrote: > > Hi, > > > > for me it look to "boring". I'm working on a cooperate design from grub to > > the shutdown menue. and plymouth is one part of it. > > > > I made a grub theme and some mockups you can get everything in the > >

[Differential] [Commented On] D797: Require user to authenticate when trying to change lock screen settings

mak added a subscriber: mak. mak added a comment. In https://phabricator.kde.org/D797#15210, @davidedmundson wrote: > This breaks every user's backup script by having root files in the user's > home. So I am very much not happy with this idea at all. > Especially as it acheives very little

Re: KDE Discover binary & library names

2016-01-11 16:34 GMT+01:00 Ivan Čukić : >> As a maintainer, I say no. Because it's just not my goal, I think that >> being part of Plasma makes it a more appealing product. > > Ok, got you :) GNOME-Software supports "profiles" for other desktop environments, which mostly means

Re: Review Request 126268: Move shutdown scripts into ksmserver cleanup

in finding out why this works, just to come to the conclusion that it can't possibly work. Thank you for the explanation, this does make more sense to me now :) - Matthias Klumpp On Dez. 7, 2015, 12:26 vorm., David Edmundson wrote

Re: Review Request 126115: Unset environment variables before starting kwin_wayland

> On Nov. 19, 2015, 5:31 nachm., Matthias Klumpp wrote: > > Okay, I talked to some GNOME people (thanks!) to find out how they handle > > this issue, and the short answer is: Not at all > > Reason for that is that it is really hard to fully secure the compositor

Re: Review Request 126115: Unset environment variables before starting kwin_wayland

> On Nov. 19, 2015, 2:08 nachm., Matthias Klumpp wrote: > > Did you consider running the whole script with `env -i`, or (likely the > > better idea) run KWin with `env -i`? > > That should sanitize the environment (unset all env vars, except for > > shell-defaults).

Re: Review Request 126115: Unset environment variables before starting kwin_wayland

matically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126115/ > --- > > (Updated Nov. 19, 2015, 12:22 nachm.) > > > Review request for Plasma, David Edmundson and Matthias Klumpp. > > > Repository: plas

Re: Review Request 126115: Unset environment variables before starting kwin_wayland

> On Nov. 19, 2015, 2:08 nachm., Matthias Klumpp wrote: > > Did you consider running the whole script with `env -i`, or (likely the > > better idea) run KWin with `env -i`? > > That should sanitize the environment (unset all env vars, except for > > shell-defaults).

Re: Review Request 126115: Unset environment variables before starting kwin_wayland

> On Nov. 19, 2015, 2:08 nachm., Matthias Klumpp wrote: > > Did you consider running the whole script with `env -i`, or (likely the > > better idea) run KWin with `env -i`? > > That should sanitize the environment (unset all env vars, except for > > shell-defaults).

Re: Review Request 126115: Unset environment variables before starting kwin_wayland

`, or (likely the better idea) run KWin with `env -i`? That should sanitize the environment (unset all env vars, except for shell-defaults). You could then set exactly the variables you need, to the exact values you want, so we don't miss unsetting anything. - Matthias Klumpp On Nov. 19, 2015, 12:22

Re: Review Request 126115: Unset environment variables before starting kwin_wayland

t; I don't have a solution for it yet and yes it also affects my setup. I > hope qt.conf can be used, but I don't know yet. > > Matthias Klumpp wrote: > A possible solution to that problem is to allow setting this in a > system-wide configuration file, or create a special KDE-sp

Re: Review Request 126115: Unset environment variables before starting kwin_wayland

reached their goal already. So, I think we can get KWin secure by adding some really heavy countermeasures (restricting it's access to $HOME, using a setgid bit on it's binary, ...) the question is: Is this effort worth it? - Matthias Klumpp On Nov. 19, 2015, 12:22 nachm., Martin Gräßlin wrote

Re: Review Request 126102: [startkde] Move sourceing of env scripts to startplasma

> On Nov. 18, 2015, 2:57 nachm., Matthias Klumpp wrote: > > It just wanted to write what David wrote ;-) > > Maybe a way to resolve this is to filter environment variables in KWin or > > before starting KWin, so anything pointing to directories in $HOME gets > > s

Re: Review Request 126102: [startkde] Move sourceing of env scripts to startplasma

to resolve this is to filter environment variables in KWin or before starting KWin, so anything pointing to directories in $HOME gets stripped away (unsetting LD_* variables might also be part of that). - Matthias Klumpp On Nov. 18, 2015, 8:18 vorm., Martin Gräßlin wrote

Re: RFC: Disable DrKonqi

2015-11-17 8:52 GMT+01:00 Martin Graesslin : > On Monday, November 16, 2015 11:58:45 AM CET Weng Xuetian wrote: >> Just FYI, on a systemd based system, the coredump is already >> automatically stored in journal and can be accessed easily by >> coredumpctl. > > Good to know.

Re: Review Request 125198: by default do not restore the previous session on next login

confusing for users - they often don't know why stuff gets started automatically. +1 for the patch, and I also really like the idea of setting a checkbox explicitly - then it's clear to the users why things are started automatically at login. - Matthias Klumpp On Sept. 12, 2015, 3:37 nachm

Re: Splitting (Muon) Discover from muon repository

2015-08-04 21:29 GMT+02:00 Jonathan Riddell j...@jriddell.org: As discussed at Akademy that seems fine with me and pretty sensible. Muon package manager does have a use case and users, maybe this will help it find a maintainer. Jup, +1 from me too! That change would help a lot in pushing Muon

Re: Review Request 123664: Find DBusAddons component explicitly

marked as submitted. Review request for Plasma. Changes --- Submitted with commit e215432a039c3681d9246ce621f8f50382acc39a by Matthias Klumpp to branch master. Repository: plasma-workspace Description --- This apparently causes trouble, since DBusAddons is required by e.g. appmenu

Review Request 123664: Find DBusAddons component explicitly

://git.reviewboard.kde.org/r/123664/diff/ Testing --- plasma-workspace compiles and works fine. Thanks, Matthias Klumpp ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Systemd kcm module - inclusion in Plasma?

2015-04-29 18:21 GMT+02:00 Ragnar Thomsen rthoms...@gmail.com: On Wed, Apr 29, 2015 at 4:10 PM, Martin Gräßlin mgraess...@kde.org wrote: Just run kdesrc-build and gave it a try and was greeted with an error message: http://paste.opensuse.org/54725251 That's on a Debian stable/testing system

Re: Review Request 123283: Remove interesting ksmserver easter egg

story behind this, when it was implemented (for debugging?). - Matthias Klumpp On April 7, 2015, 2:25 nachm., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r

Re: Review Request 123283: Remove interesting ksmserver easter egg

On April 7, 2015, 2:31 nachm., Matthias Klumpp wrote: :D That's an awesome feature. I guess there's an interesting story behind this, when it was implemented (for debugging?). Just to be clear, that's no objection to the patch - please kill this thing ;-) - Matthias

Re: Project: libmuon package install for 3rd party applications

2015-03-13 14:32 GMT+01:00 Jonathan Riddell j...@jriddell.org: [...] PS: A good GSoC would be to make sure that Appstream can finally be adopted properly in Kubuntu While this would be lovely it would probably require a lot of coordination in debian, launchpad and ubuntu. It feels like a

Re: Project: libmuon package install for 3rd party applications

2015-03-12 21:00 GMT+01:00 Jonathan Riddell j...@jriddell.org: On Thu, Mar 12, 2015 at 08:40:46PM +0100, Matthias Klumpp wrote: 2015-03-12 20:34 GMT+01:00 Jonathan Riddell j...@jriddell.org: [...] What's the difference between this and the already existing PackageKit(-Qt) and PackageKit

Re: Project: libmuon package install for 3rd party applications

Hi! 2015-03-12 20:34 GMT+01:00 Jonathan Riddell j...@jriddell.org: Aleix et al: what do you think of this? https://community.kde.org/GSoC/2015/Ideas#Project:_libmuon_package_install_for_3rd_party_applications adapting muon so its library can be used by external apps to install packages?

Re: Muon and kde-gtk-config moved to kde/workspace - was - Re: Moving repositories in the module structure

2014-10-06 19:57 GMT+02:00 Albert Astals Cid aa...@kde.org: El Dilluns, 6 d'octubre de 2014, a les 01:30:47, Aleix Pol va escriure: [...] I don't expect to compete with Apper. Muon Discover is a software center and that's the main solution I'm pushing here, as I explained in Plasma. Apper is

Re: Moving kde:muon repository to kde/workspaces

2014-09-26 16:50 GMT+02:00 David Edmundson da...@davidedmundson.co.uk: Makes sense to me. Gnome are touting their app installer, so it won't be particularly controversial for upstream to start doing package management UIs. Actually, this is pretty welcomed! :-)

Re: Review Request 120318: PoC: Package Manager integration for the AppsModel

On Sept. 22, 2014, 3:38 nachm., Martin Gräßlin wrote: I like the idea! Suggestion for the which package manager to use part: add a package manager selection to the defaults application KCM and use the one which is configured there. Distros should be able to easily configure the one

Re: Review Request 120318: PoC: Package Manager integration for the AppsModel

Hein wrote: I was planning to add a config key to Kicker for now, but I agree a more canonical workspace-level key and an API in KToolInvocation would be cool. Next Frameworks release maybe? Matthias Klumpp wrote: In theory, a call on the PackageKit interface should trigger whatever

Re: Compatibility problems with latest GTK+ applications

2014-05-08 9:31 GMT+02:00 Martin Gräßlin mgraess...@kde.org: Martin GräßlinOn Wednesday 07 May 2014 10:11:37 wrote: Any advice on how to handle this situation is appreciated. As several people responded that I should report the issues I just did that and reported the following bug reports

Re: Re: Re: An alternative for XEmbed

2014-04-15 15:03 GMT+02:00 Mark Gaiser mark...@gmail.com: [...] Idea.. Can you somehow detect if an application wants to do XEmbed stuff? If it wants to while there is no wmsystemtray configured you should annoy the user and ask if we should enable the wmsystemtray for him automatically

Re: Review Request 117312: Disable PackageKit integration

On April 2, 2014, 9:44 a.m., Marco Martin wrote: Now no packagekit warning should happen anymore, even with the integration enabled Good :-) With my PK-upstream hat on: If you have problems with integrating PackageKit or miss functionality, please let me know. (the issue above looked

Re: Re: kill the systray?

2013/9/25 Martin Gräßlin mgraess...@kde.org: On Thursday 26 September 2013 01:27:54 Aaron J. Seigo wrote: On Tuesday, September 24, 2013 17:06:14 Sebastian Kügler wrote: When I asked Martin if he knew a way to do the xembed, he replied (being Martin ;)) asking if we can just kill it and

Re: kill the systray?

2013/9/26 Aaron J. Seigo ase...@kde.org: On Wednesday, September 25, 2013 23:06:42 Matthias Klumpp wrote: I also fear that, but this was a statement by single developers, which I don't think is true. it is the developer responsible for the component in question, and apparently he’s already

Re: kill the systray?

GNOME embeds the tray Icons in it's norification area, supporting xembed right now. In future, they want a different notification system, which is used exclusively (design docs are available, i will look them up at home) However, I assume GTK+ will have a systray implementation (at least for

Re: kill the systray?

on this. Cheers, Matthias Am 24.09.2013 10:35 schrieb Marco Martin notm...@gmail.com: On Tuesday 24 September 2013, Matthias Klumpp wrote: GNOME embeds the tray Icons in it's norification area, supporting xembed right now. In future, they want a different notification system, which is used

Re: naming the next major release

2013/8/21 Martin Graesslin mgraess...@kde.org: On Wednesday 21 August 2013 19:36:21 Daniel Nicoletti wrote: [...] Ok, then what am I doing wrong in calling my stuff KDE stuff? http://manifesto.kde.org/benefits.html lists what I do on my projects, I was arguing about Martin saying that I talk

Re: Plasma Workspaces 4.11: the last feature release in the 4.xseries for kde-workspace

@Kevin: I am only remotely following this issue, but as PackageKit developer, I would of course like to see our project in Plasma Workspaces as soon as possible. But I don't know the exact issues here. Also, having KSecrets merged would be a nice goal too. (The SecretService API is very stable,