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 chan

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 s

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 `PreferLocal

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 https://

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, fbampalou

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! Th

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 https://www.freedesktop.org

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 accor

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: kossebau

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 https://www.freedesktop.org/software/appstream/docs/s

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 "GNOME

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, kosseb

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 >> specifica

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 va

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 just an info-type validation m

Re: Missing mouse pointer in KWin on Wayland with Etnaviv

2017-10-31 10:22 GMT+01:00 Martin Flöser : > 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 not >> ideal f

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 fo

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: 2017-09-07

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 : > 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" package.

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 as a long time Debian

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 > other DE doesn't), also de

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 >> both are equal in

Re: Plasma Mobile on the Librem 5

2017-08-30 9:24 GMT+02:00 Bhushan Shah : > 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 to >> develop a mobil

Re: Plasma Mobile on the Librem 5

2017-08-29 18:39 GMT+02:00 Martin Flöser : > 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 >> improvements. I didn't have th

Re: Plasma Mobile on the Librem 5

2017-08-29 16:44 GMT+02:00 Sebastian Kügler : > Hi Matthias, et al! > > On Tue, 29 Aug 2017 15:28:36 +0200 > Matthias Klumpp wrote: >> [ Please keep the CC list intact for replies ] >> >> [...] > > Yes, Kirigami has been rather a success story, and we see more

Re: Plasma Mobile on the Librem 5

2017-08-29 15:58 GMT+02:00 Eike Hein : > > 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 >> communication. We are currently running a

Plasma Mobile on the Librem 5

estions about Purism, 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/

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). REPO

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 &component: components) { This will not work, because the component-ID can be an arbit

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 https://phabri

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 > > https://github.com/ximion/appstream/commit/548a5ae6617e

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 https://standards.fre

[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 https://phabricator.kde.org

[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 appstrea

[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 https://phabricator.

[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 it

Re: Discover requires Qt 5.7?

2016-09-22 14:36 GMT+02:00 Matthias Klumpp : > 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, >>> > >>> > Discove

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 >> > CMakeLists.txt claims Qt 5.2 is requ

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. > This must be a show sto

[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 applica

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 list

[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 easily

[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 tha

[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 > https://www.freedesktop.org/

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 target for > appstream me

[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 apps not depend on Plasma,

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 metadata similar >> > like >> > what framewor

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. > > But Kubuntu uses Plasma

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. There's also applications

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

their favourite after 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

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, putting that in t

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 > file

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, and the > current

Re: Minutes Monday Plasma Meeting

2016-02-29 13:23 GMT+01:00 kainz.a : > Hi, > >> d_ed: >> - Found out why widget explorer is slow: we're not loading icons, but >> complicated SVGs uncached >> - will work on that this week, and 5.5 stuff > > > we talk some times about have also png icons. as I'm not a great fan (cause > it's more,

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 > > share.kde.org

[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 anyw

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 that it stops prefer

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

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 if

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ä

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

> 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

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 spec

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

(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,

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

This is an automatically 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. > > > R

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

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. That could make my life

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

eally 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, 2

Re: Splitting (Muon) Discover from muon repository

2015-08-05 0:07 GMT+02:00 Clemens Toennies : > On 04.08.2015 18:29, Aleix Pol wrote: >> [...] >> Anyway, I'd like to leave 2 repositories: >> - muon, that will have muon-packagemanager >> - discover, that will have discover and updater. I'd also like to drop >> the Muon part from Discover eventuall

Re: Splitting (Muon) Discover from muon repository

2015-08-04 21:29 GMT+02:00 Jonathan Riddell : > > 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 on non-Kubunt

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

ma-workspace_5.3.0-0tanglu1_amd64.146006.log Diffs - CMakeLists.txt 5180bac Diff: https://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 : > On Wed, Apr 29, 2015 at 4:10 PM, Martin Gräßlin 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 and the file does not exis

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 ki

Re: Review Request 123283: Remove interesting ksmserver easter egg

nteresting 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

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

2015-03-13 14:32 GMT+01:00 Jonathan Riddell : > [...] >> 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 full > time j

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

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

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

Hi! 2015-03-12 20:34 GMT+01:00 Jonathan Riddell : > 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? What's the dif

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 : > 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 a pac

Re: Moving kde:muon repository to kde/workspaces

2014-09-26 16:50 GMT+02:00 David Edmundson : > 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! :-) ___ Plasma-

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

ide > multiple tools, though and then the user might want to be able to configure > it. > > Eike 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 Fr

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 confi

Re: Compatibility problems with latest GTK+ applications

2014-05-08 9:31 GMT+02:00 Martin Gräßlin : > 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 against GTK: >

Re: Re: Re: An alternative for XEmbed

2014-04-15 15:03 GMT+02:00 Mark Gaiser : > [...] > > 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 since an a

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: kill the systray?

2013/9/26 Aaron J. Seigo : > 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 appar

Re: Re: kill the systray?

2013/9/25 Martin Gräßlin : > 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 quoted starwar

Re: kill the systray?

this. Cheers, Matthias Am 24.09.2013 10:35 schrieb "Marco Martin" : > 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,

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 Xfce),

Re: naming the next major release

2013/8/21 Martin Graesslin : > 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 KDE as sof

  1   2   >