Re: plasma-desktop on other environments (bis)

Here's another question, side-ways related: Qt 5.6.1+ are likely to remove DBus support from the Mac platformsupport module. That's fine, but the change breaks my build of the qgenericunixtheme unless I deactivate DBus support in there too. That's mostly my problem of course, but can anyone

Re: plasma-desktop on other environments (bis)

Martin Klapetek wrote: > It's gone completely, everything happens in KNotification > at runtime. Great. That's 1 daemon less, and also 1 less source of focus loss (and 1 less patch I can now really forget about) :) I'd completely forgotten about the thing, until earlier today when apparently

Re: plasma-desktop on other environments (bis)

Martin Klapetek wrote: > That's not what I'm telling anyone at all. Great. It's not always clear how literally to take statements (or not, apparently :)) I think I don't need convincing for the rest but always agreed with that. > But if you're going to split events out from

Re: plasma-desktop on other environments (bis)

On Sat, May 28, 2016 at 2:22 PM, René J. V. wrote: > Quick related question: has knotify4 been replaced by a KF5 equivalent, or > rather made obsolete? > It's gone completely, everything happens in KNotification at runtime. Cheers -- Martin Klapetek | KDE Developer

Re: plasma-desktop on other environments (bis)

On Sat, May 28, 2016 at 11:14 AM, René J. V. wrote: > > > Please don't make our apps aliens in other environments. > > Please don't tell users of other environments what they're allowed to do > with > their apps either. > That's not what I'm telling anyone at all. I'm

Re: plasma-desktop on other environments (bis)

Quick related question: has knotify4 been replaced by a KF5 equivalent, or rather made obsolete? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

David Edmundson wrote: > Renè isn't doing the individual standalone OS X packages, which should have > the tight host integration. Other people are doing that. MacPorts makes it much more straightforward to provide cross-platform homogeneity because all required resources are installed in

Re: plasma-desktop on other environments (bis)

David Edmundson wrote: >> Where and how exactly are the default sounds configured? > .notifyrc files shipped with the application / library. That would mean changing lots of files then... I'm not sure how to do that in an efficient way if there isn't something like a category mechanism in

Re: plasma-desktop on other environments (bis)

On Sat, May 28, 2016 at 10:27 AM, David Edmundson < da...@davidedmundson.co.uk> wrote: > On Sat, May 28, 2016 at 3:11 PM, Martin Klapetek < > martin.klape...@gmail.com> wrote: > >> On Sat, May 28, 2016 at 9:10 AM, Kai Uwe Broulik >> wrote: >> >>> >>> > Even more so than

Re: plasma-desktop on other environments (bis)

> He's doing macports which is *very* different. Macports even has X11 and > Fluxbox. > If you're running kate on X with a fluxbox WM, having native OS X integration > just because of your kernel doesn't make too much sense. Heh, so indeed we talked past each other, I'm out of this discussion

Re: plasma-desktop on other environments (bis)

On Sat, May 28, 2016 at 3:11 PM, Martin Klapetek wrote: > > On Sat, May 28, 2016 at 9:10 AM, Kai Uwe Broulik > wrote: > >> >> > Even more so than with look and feel that will be beneficial for >> cross-platform users. After all alert sound

Re: plasma-desktop on other environments (bis)

On Sat, May 28, 2016 at 9:10 AM, Kai Uwe Broulik wrote: > > > Even more so than with look and feel that will be beneficial for > cross-platform users. After all alert sound specificity is supposed to aid > in determining what's going on and how to react. > > If I hear the

Re: plasma-desktop on other environments (bis)

> > Where and how exactly are the default sounds configured? > .notifyrc files shipped with the application / library. David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

Hi, > I guess there must be a generic Qt beep that one can tap into to replace > beep,  QApplication::beep() > Given that distinction I would find it confusing to use the same sound for > both empty actions. I rather find this distinction awkward and would expect emptying the trash empty

Re: plasma-desktop on other environments (bis)

Martin Klapetek wrote: So the apparently generic categories that concern application error, crash etc. do not control the way those notifications are delivered if you aren't running a Plasma session? Mind you, we're not only talking about the sounds here. > That's not entirely correct -

Re: plasma-desktop on other environments (bis)

On Fri, May 27, 2016 at 4:54 PM, David Edmundson wrote: > > >And then there is the "Plasma Workspace" source, which also contains > events that IMHO are not specific to Plasma at all but simply correspond to > notifications posted through certain KF5 frameworks. In

Re: plasma-desktop on other environments (bis)

>And then there is the "Plasma Workspace" source, which also contains events that IMHO are not specific to Plasma at all but simply correspond to notifications posted through certain KF5 frameworks. In fact, the only notifications that appear Plasma-specific (out of 20) are: 0 of them respond to

Re: plasma-desktop on other environments (bis)

I'm continuing to take stock little by little of what KCMs would make sense outside of a Plasma session (or should have a "native" alternative). One which comes to mind is the notifications KCM. Many of its event sources provide a shortcut to configure application-specific notifications that are

Re: plasma-desktop on other environments (bis)

On Mon, May 23, 2016 at 9:35 AM, René J.V. wrote: > On Monday May 23 2016 07:59:14 Martin Graesslin wrote: > > >I'm against any patches to plasma-desktop to make it compile on other > >platforms. There should not be any need to have anything from > plasma-desktop > >on non

Re: plasma-desktop on other environments (bis)

On Monday, May 23, 2016 10:35:05 AM CEST René J.V. Bertin wrote: > On Monday May 23 2016 07:59:14 Martin Graesslin wrote: > >I'm against any patches to plasma-desktop to make it compile on other > >platforms. There should not be any need to have anything from > >plasma-desktop on non Plasma

Re: plasma-desktop on other environments (bis)

On Saturday 21 May 2016, René J. V. Bertin wrote: > Kai Uwe Broulik wrote: > > FWIW, a good part of the KCMs you seem to think I include on OS X are in > fact excluded because X11 isn't provided. > > > The following are redundant with the system-provided ones: > > > > * componentchooser > >

Re: plasma-desktop on other environments (bis)

On Monday 23 May 2016, René J.V. Bertin wrote: > I really cannot get my head around that kind of attitude from people > working on a "Freedesktop" environment. Users of OS X (or MS Windows) are > apparently not entitled to gaining a little more freedom where and when > they can? That's really not

Re: plasma-desktop on other environments (bis)

On Monday May 23 2016 07:59:14 Martin Graesslin wrote: >I'm against any patches to plasma-desktop to make it compile on other >platforms. There should not be any need to have anything from plasma-desktop >on non Plasma platforms. If there is indeed a KCM which makes sense to have on >other

Re: plasma-desktop on other environments (bis)

On Saturday, May 21, 2016 8:18:15 PM CEST René J.V. Bertin wrote: > Hi, > > We've talked about doing something about the various components in > plasma-desktop that would make sense outside of full-blown Plasma sessions. > > I've been keeping that in mind, and the other day my Linux install

Re: plasma-desktop on other environments (bis)

On Saturday, May 21, 2016 10:03:21 PM CEST René J. V. Bertin wrote: > > The following are unneccessary because we don't provide/have to provide > > that feature outside a full Plasma session: * Autostart > > * Global shortcuts > > Through kglobalacceld? That is part of a framework that's

Re: plasma-desktop on other environments (bis)

On Sun, May 22, 2016 at 10:28 PM, René J. V. wrote: > David Edmundson wrote: > > > >> > It then grew to include some GTK settings and backporting stuff to > KDE4. > >> > >> What backporting stuff? > >> > > > > As we have KDE apps using kdelibs4 this also saves some settings

Re: plasma-desktop on other environments (bis)

David Edmundson wrote: >> > It then grew to include some GTK settings and backporting stuff to KDE4. >> >> What backporting stuff? >> > > As we have KDE apps using kdelibs4 this also saves some settings to > ~/.kde4/kdeglobals as well as the new place. Ah, yes, indeed. I see that now in the

Re: plasma-desktop on other environments (bis)

On Sun, May 22, 2016 at 9:01 PM, René J. V. wrote: > David Edmundson wrote: > > > KDE Resource Database. > ... > > It then grew to include some GTK settings and backporting stuff to KDE4. > > What backporting stuff? > As we have KDE apps using kdelibs4 this also saves some

Re: plasma-desktop on other environments (bis)

David Edmundson wrote: > KDE Resource Database. ... > It then grew to include some GTK settings and backporting stuff to KDE4. What backporting stuff? I have a bit of a dilemma here, which results from the fact that MacPorts also provides a whole range of GTk applications, a number of which I

Re: plasma-desktop on other environments (bis)

> Yes, but without the KCM the only way of letting applications use the right > translation is setting it for each application - if they even provide the > menu to that effect. You shouldn't have to set that up, it should use the translation for whatever language your system is configured. 

Re: plasma-desktop on other environments (bis)

René J. V. Bertin wrote: > What Plasma platform theme, the one in plasma-integration? That won't be used > on OS X. It's been a while, but I'm pretty confident that I changed those Indeed: QList KdeMacTheme::keyBindings(QKeySequence::StandardKey key) const { // return a native keybinding

Re: plasma-desktop on other environments (bis)

Kai Uwe Broulik wrote: >> No, KDE translations aren't linked in any way to the way the system handles >> these > > That doesn't change the fact that when my system is French I want the > application to be French, too, which is what this kcm is about, choosing a > language. Yes, but without the

Re: plasma-desktop on other environments (bis)

David Edmundson wrote: > It's invoked by the colours and style KCM - so though I do think there is a > demand for configuring apps on OS X, taking the KCM directly isn't a good > idea because of that. Or the invocation is made optional, skipped on platforms without X11... The thing with not

Re: plasma-desktop on other environments (bis)

> The following I have no idea what they even do: > * Krdb KDE Resource Database. It exports the colour, style and settings to other toolkits, most notably xrdb (hence the name) which is a central storage for what font/colours to use for apps using low level X...so xfig and xclock can get the

Re: plasma-desktop on other environments (bis)

Hi, > FWIW, a good part of the KCMs you seem to think I include on OS X are in fact  > excluded because X11 isn't provided. I just went through the CMakeLists.txt > As long as KDE code uses its own way (or a Qt-provided method, I don't know) > to determine what application to use this will

Re: plasma-desktop on other environments (bis)

Kai Uwe Broulik wrote: FWIW, a good part of the KCMs you seem to think I include on OS X are in fact excluded because X11 isn't provided. > The following are redundant with the system-provided ones: > * componentchooser As long as KDE code uses its own way (or a Qt-provided method, I don't

Re: plasma-desktop on other environments (bis)

Hi, thanks for your effort but I don't see any part in p-d, at least not the bits that you left enabled for os x, that would be of use or should be used outside a Plasma session: Let's do a quick run-down on the KCMs provided by plasma-desktop: The following are redundant with the

plasma-desktop on other environments (bis)

Hi, We've talked about doing something about the various components in plasma-desktop that would make sense outside of full-blown Plasma sessions. I've been keeping that in mind, and the other day my Linux install (which I maintain in a parallel prefix using the same packaging scripts as I use