Re: plasma-desktop on other environments (bis)

[René J . V . Bertin]

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 tell me if *in general* 
building qgenericunixtheme without DBus support is likely to break anything in 
the KDE platform plugin, esp. things I might miss while testing on my end?

Thanks,
R.

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[René J . V . Bertin]

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 
the running instance had been the victim of some kind of rogue AppNap event.

R.

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[René J . V . Bertin]

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 plasma_workspace.notifyrc,
> split them to per-platform files and modify those dialog events
> to use the sound the platform uses *by default*.

It that's possible and feasible, then yeah, let's. 

Doing this in rc files means hardcoding a sound name/file, right? It'd be even 
nicer if we could somehow use the user's choice for that default sound. That 
could be QApplication::beep() or something more intricate, but how would you 
store that in the rc file?

R.

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[Martin Klapetek]

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
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[Martin Klapetek]

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 saying that if error dialog on OS X makes an "alert" sound,
our error dialogs should make the same "alert" sound in OS X
*by default*. If it does no sound, our dialogs should make no
sounds *by default*. Simple as that.

Providing the users a way to configure whatever last century
sounds they want to use is perfectly fine and should be done.

But if you're going to split events out from plasma_workspace.notifyrc,
split them to per-platform files and modify those dialog events
to use the sound the platform uses *by default*.

Cheers
-- 
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[René J . V . Bertin]

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)

[René J . V . Bertin]

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 XDG-compliant 
locations and I provide a patched Qt port which can be made to use those 
locations with its QStandardPaths class. A lot of effort has gone into that, 
and 
I'd be more than happy if that effort benefits others outside of MacPorts too.

That doesn't mean that our KF5 applications shouldn't have as tight a host 
integration as possible. I just happen to feel that the one doesn't exclude the 
other. I just see integration more on the functional level, so for me 
standalone 
app bundles could just as well provide certain features that are less common, 
even if that means integrating less tightly in the look and feel department. 
Shipping everything in an app bundle also means the embedded Qt can be tweaked 
as required ... for the "host" application.

We have some great software on OS X, and Apple provide or used to provide a 
good 
part of that. After OS X 10.6 there has been an increasing abandon of features 
aimed at more advanced users (by Apple, except in things like Xcode). This is 
exactly why I have become involved with KDE/Mac. First because Apple Mail no 
longer corresponded to my needs, and later Xcode which has become, in a way, 
the 
iTunes of IDEs. KDevelop and Kontact are still the 2 main KDE applications I 
use 
on OS X.

If you're aiming at users who are not yet KDE "customers" on other platforms 
you'll need good arguments to woo them away from native alternatives like 
TextWrangler (the free version of the venerable BBEdit). From what I've seen 
until now native applications with their hand-tuned interfaces will always look 
better ("licked", "sexy") than Qt-based applications using the native platform 
plugin. Those have interfaces that work (mostly) but that have a decidedly 
unfinished look, even after addressing a few of the widget glitches I mentioned 
earlier *) Not really surprising, I think. Some KDE applications are more 
affected by this than others (dialogs always are). KDevelop would actually look 
pretty good were it not for the fact that it uses an inappropriate tabbar 
widget 
for the tabbed document editor.

I have no idea to what extent it's possible to improve the native look to make 
it feel less like there's a layout engine behind it that uses some sort of bare 
minimal common denominator algorithm that adds just a bit more safe margin 
everywhere than strictly required. And with that I mean improve it without 
tweaking the code or .ui files wherever that would be required. Maybe a single 
well-conceived stylesheet could do the trick, but from what I've seen even Qt's 
own IDE uses an internal theme to provide a consistent and appealing look and 
feel everywhere it runs.

Apologies for a long ramble, which I'm going to cut off here. Trying to 
formulate convincing arguments while under constant distraction from household 
chores is something I'm not so good at anymore :-/

R. 

*) I've put up 3 RRs that address 3 bug reports after the last round of 
exchange 
on this thread, and for some reason those haven't yet had any feedback from the 
framework developers.

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[René J . V . Bertin]

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 place 
already that could by used in KNotifications to determine what "native" sound 
to 
use instead of the specified sound file, on platforms where this would be more 
appropriate.

Kai Uwe Broulik wrote:

> QApplication::beep()

I haven't checked, but that one undoubtedly plays the "alert sound", which is 
the only choice we have on OS X. Plus the option to play "user interface sound 
effects" or not. Nothing configurable there, nor any way to know which sound 
those are.

> I rather find this distinction awkward and would expect emptying the trash
> empty the whole trash, or not offering that from a KDE application in the
> first place (we don't do that except for Dolphin, and perhaps the file open
> dialog, do we?).

Any application that has an option to move files to a wastebin rather than 
deleting them directly moves them to the KDE trash AFAIK. That includes 
digiKam, 
which means you can end up with lots of rather large files hidden somewhere.
That was the reason I implemented a backend under KDE4 which has been ported to 
KF5.
I do not want a KDE application to empty the whole trash, and in this context 
I'll only need to justify that with the fact that no other application does 
this. Emptying the entire trash is done only by the Finder.

> Doesn't at least QPlatformMessageDialog use the native OS X message popup
> thingie?

Message popups use a more or less native "thingie", yes. I'd say that most 
popups posted by KDE software do too, by extension.

> Such as? Most notifications fall into the category of "error", "warning",
> "question", "info", and I bet OS X has counterparts for those sounds. Passive

Actually, no. There's just a single alert sound as I wrote above. Applications 
that feel the need to use a finer grained distinction provide there own 
notifications. So KDE isn't an outlier there.

> If I hear the generic Windows drum sound I know that an error happened. If I
> hear the Oxgen sound on Windows I might not do that.

For a generic alert sound that might be true. But I will remain convinced that 
most users of KDE applications on "other platforms" will chose to use them 
because they already do on Linux. More specific notifications are always useful 
(or they're not justified anywhere), and as someone who uses the same software 
on multiple platforms I know how useful it is if esp. my non-visual feedback is 
the same everywhere (just like things like shortcuts).

> "familiar KDE interface". I bet the average one-platform user group we imho
> should be targeting does the same.

There's not 1 category you should be targeting, but all potential users, and 
for 
me that also means not disabling features that could be seen as added value 
(like providing better-than-native configurability) just because some people 
have decided for whatever reason that those features are to be guarded 
jealously. It's fine to try to be as native as possible by default (as long as 
that doesn't increase maintenance burden too much) but that shouldn't make it 
impossible to provide a familiar cross-platform interface (there too as long as 
it doesn't increase maintenance burden too much).

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

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

That's very true, even if the scenario is a little over the top. I can indeed 
run Kate5 under X11 using MacPorts (and even make it use Mac-style widgets in 
that case), but that's more a PoC and test-bed than something I do on a daily 
basis.

> On a side note, KNotification doesn't really have much other use on ~X11
> than playing sounds.

Oh? Maybe I mix KNotification and KNotifyConfig, but I find the mechanism to 
decide per event if you want sound and/or popup and/or something else to be 
very 
useful. OS X really simplifies too much there even if there are enough 
applications that provide this kind of feature, either rolling their own or 
using 3rd party frameworks like Growl.

R




___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[Martin Klapetek]

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 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 generic Windows drum sound I know that an error happened.
>>> If I hear the Oxgen sound on Windows I might not do that.
>>>
>>> While I am one of those negligible "I use Kate and Dolphin on Windows
>>> because Notepad and Explorer suck" users, I still want native integration
>>> and not a "familiar KDE interface". I bet the average one-platform user
>>> group we imho should be targeting does the same.
>>>
>>
>> This^. Very much this.
>>
>> Please don't make our apps aliens in other environments.
>>
>
> Renè isn't doing the individual standalone OS X packages, which should
> have the tight host integration. Other people are doing that.
>
> 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.
>

However, the discussion started with "an initial approach at evaluating
what builds and what makes sense on a ~Plasma desktop, X11 or OS X
(or MS Windows, presumably)."

In that context, it doesn't make sense to use KDE's notification sounds for
apps running on OS X or MS Windows, presumably, if they can be replaced
with native counterparts *by default*. By all means give the user tools to
break
his system, but defaults should be sensible in a way that the application
does
not look and behave like an alien app.

On a side note, KNotification doesn't really have much other use on ~X11
than playing sounds.

Cheers
-- 
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[Kai Uwe Broulik]

> 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 then.


___
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]

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 specificity is supposed to aid
>> in determining what's going on and how to react.
>>
>> If I hear the generic Windows drum sound I know that an error happened.
>> If I hear the Oxgen sound on Windows I might not do that.
>>
>> While I am one of those negligible "I use Kate and Dolphin on Windows
>> because Notepad and Explorer suck" users, I still want native integration
>> and not a "familiar KDE interface". I bet the average one-platform user
>> group we imho should be targeting does the same.
>>
>
> This^. Very much this.
>
> Please don't make our apps aliens in other environments.
>

Renè isn't doing the individual standalone OS X packages, which should have
the tight host integration. Other people are doing that.

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.

David


> Cheers
> --
> Martin Klapetek | KDE Developer
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[Martin Klapetek]

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 generic Windows drum sound I know that an error happened. If
> I hear the Oxgen sound on Windows I might not do that.
>
> While I am one of those negligible "I use Kate and Dolphin on Windows
> because Notepad and Explorer suck" users, I still want native integration
> and not a "familiar KDE interface". I bet the average one-platform user
> group we imho should be targeting does the same.
>

This^. Very much this.

Please don't make our apps aliens in other environments.

Cheers
-- 
Martin Klapetek | KDE Developer
___
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]

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

[Kai Uwe Broulik]

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 the whole trash, or not offering that from a KDE application in the first 
place (we don't do that except for Dolphin, and perhaps the file open dialog, 
do we?).

> for message box events on OS X. It really really really really *really*
> shouldn't
> use the Oxygen sounds by default.

> I honestly don't know. Sounds used for notifications that have a native 
> counterpart could use the native default sound by default (or the one 
> configured 
> if it's feasible to obtain that information).

Doesn't at least QPlatformMessageDialog use the native OS X message popup 
thingie?

> But what about notifications that are specific to KDE and that use specific 
> notification sounds?

Such as? Most notifications fall into the category of "error", "warning", 
"question", "info", and I bet OS X has counterparts for those sounds. Passive 
notification popups (I think KNotification has a backend for those on OSX) are 
silent anyway? An instant messaging app or email might use its own sounds for 
notifying, though.

> 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 generic Windows drum sound I know that an error happened. If I 
hear the Oxgen sound on Windows I might not do that.

While I am one of those negligible "I use Kate and Dolphin on Windows because 
Notepad and Explorer suck" users, I still want native integration and not a 
"familiar KDE interface". I bet the average one-platform user group we imho 
should be targeting does the same.

Cheers,
Kai Uwe


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[René J . V . Bertin]

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 - KMessageBox sounds (through KNotification)
> are handled by frameworkintegration still and some events are in fact

Yes, I think I noticed that, and it seems a logical place to provide that kind 
of integration (and also efficient to provide a central "hub" for integration 
with the host).

> used by other frameworks directly, that's namely Trash, Textcompletion*
> and beep (indirectly through KNotification::beep()).
> 
> That said, I believe that on OS X it should use OS X sounds instead of
> these outdated sounds we still use. In other words, ship custom .notifyrc

I guess there must be a generic Qt beep that one can tap into to replace beep, 
but for the others I really have no idea. OS X has a limited set of 
notification 
sounds of its own, but here too applications (or application frameworks) that 
provide their own set of notification types provide their own mechanism to 
configure these (if at all).

There's a sound for emptying the host trash, but I have never seen it among the 
options for the system beep as far as I can remember. The KDE trash is stored 
in 
the host trash, but in such a way that it can be emptied independently 
(emptying 
the host trash also empties KDE's trash, by contrast). Given that distinction I 
would find it confusing to use the same sound for both empty actions.

> for message box events on OS X. It really really really really *really*
> shouldn't
> use the Oxygen sounds by default.

I honestly don't know. Sounds used for notifications that have a native 
counterpart could use the native default sound by default (or the one 
configured 
if it's feasible to obtain that information). But what about notifications that 
are specific to KDE and that use specific notification sounds? It seems more 
than 
reasonable to use that KDE sound. 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 there was 
no 
point in that we'd still be using simple beeps for everything.

At the moment I can only think of a few examples. Adium, a multi-protocol IM 
client that is a native port of pidgin. It provides its own customisable sound 
themes rather than using system sounds and notification settings. More or less 
commercial IM/VOIP applications like Skype and Viber provide the same sounds on 
all platforms where they exist, at least for their specific events.

Where and how exactly are the default sounds configured?

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[Martin Klapetek]

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  fact, the only
> notifications that appear Plasma-specific (out of 20) are:
>
> 0 of them respond to notifications posted directly through certain KF5
> frameworks.
>
> The message box events are handled by Plasma QPT.
>

That's not entirely correct - KMessageBox sounds (through KNotification)
are handled by frameworkintegration still and some events are in fact
used by other frameworks directly, that's namely Trash, Textcompletion*
and beep (indirectly through KNotification::beep()).

That said, I believe that on OS X it should use OS X sounds instead of
these outdated sounds we still use. In other words, ship custom .notifyrc
for message box events on OS X. It really really really really *really*
shouldn't
use the Oxygen sounds by default.

Cheers
-- 
Martin Klapetek | KDE Developer
___
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]

>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 notifications posted directly through certain KF5
frameworks.

The message box events are handled by Plasma QPT.

David
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[René J . V . Bertin]

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 
already configurable via the application (or should be, I haven't checked all). 
But despite what has been said before, there are a number of notifications for 
events that are global, as in shared among all KF5 applications. Those 
"Accessibility" source would probably be concerned (and if KDE provides its own 
accessibility controls it would make all the sense in the world to make those 
available as far as they cannot be linked to a native setting and don't depend 
on features only available under X11 or Wayland).
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:
- Logout
- Widget failed to install
- Logout cancelled
- Login
- Widget deleted
and possibly "Print error" if that notification is posted by a KF5 print 
monitor agent.

The other 14 or 15 could (and should, I think) be relocated because they can 
occur in any application regardless of whether it runs under a Plasma session 
or otherwise.

R.
___
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]

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 Plasma platforms. If there is indeed a KCM which makes sense to
> have on
> >other platforms then it was incorrectly positioned and needs to be moved
> out
>
> I agree (but am not going to hold my breath). I actually think that even
> for Plasma desktops it would make sense to move the KCMs out of there, at
> least the ones that are not directly related to what makes the desktop or
> how it works.
>
> >work a valid use case. In my opinion KDE applications should follow the
> native
> >style on OSX.
>
> 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 what I'd expect from members of what's supposed
> to be a community, and doesn't at all motivate me to contribute more on
> other aspects.
>
> Well, I'm kind of with you.

In Plasma, we don't support OS X and we supposedly are completely separated
from applications, so we are absolutely the last people in KDE who should
be telling you how applications on OS X should be acting

Macports does seem to fall into a somewhat different use-case to the the
applications being packaged for OS X standalone. However, it does feel
quite similar to the "how do I configure KDE apps on Fluxbox" discussion
that's come up quite a few times.

Could you make a list of what features you need rather than what you don't
need.
It's hard to read but more importantly it's hard to see where we have
overlaps with these other problems that we need to solve.

David
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[Martin Graesslin]

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 platforms. If there is indeed a KCM which
> >makes sense to have on other platforms then it was incorrectly positioned
> >and needs to be moved out
> I agree (but am not going to hold my breath). I actually think that even for
> Plasma desktops it would make sense to move the KCMs out of there, at least
> the ones that are not directly related to what makes the desktop or how it
> works.

So far we haven't seen any KCM which would not be desktop specific. The things 
you listed are workarounds for apparently issues with the OSX QPT plugin. 
Needs to be fixed there, not worked around.

> >work a valid use case. In my opinion KDE applications should follow the
> >native style on OSX.
> 
> 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 what I'd expect from members of what's supposed
> to be a community, and doesn't at all motivate me to contribute more on
> other aspects.

I only expressed my opinion. Of course I'm not taking away any freedoms. Of 
course you can according to the license use our software on OSX. Whether we 
consider that as a good idea is from the freedom perspective irrelevant. So 
please don't say we restrict freedom - that's clearly not the case.

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[Marco Martin]

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
> 
> 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 continue to make
> sense.
> 
> > * translations
> 
> No, KDE translations aren't linked in any way to the way the system handles
> these, at least not on OS X. This is especially true for applications that
> cannot or shouldn't be provided as app bundles (anything ecm_mark_nongui).
> 
> > * fonts
> 
> No, KDE has its own set of font roles which are independent of the system,
> but which are used (expected) in KDE interface design. Without support for
> them, applications look just awful on OS X because most text elements will
> use what Qt considers the platform default font (Lucida Grande 13). The
> result is an appearance as if designed for the visually and motor impaired
> (large, spacey interface).

to me it seems many of those issues just look like bugs in either the osx qpa 
or to the osx qstyle, that should be fixed upstream in Qt as benefit of every 
Qt app, other workarounds are just.. workarounds


-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[Marco Martin]

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 what I'd expect from members of what's
> supposed to be a community, and doesn't at all motivate me to contribute
> more on other aspects.

hmm, i don't think i would call "freedom".. what it boild down is having 
access to kcms that all they would do is to configure some applications to 
behave "a little weird" on the target platform as would make it not integrate 
anymore.
i don't see it making much sense. itadds maintenance burden with little gain.

there may indeed be kcms that make sense and they should be moved somewhere 
else.

imaginging what i would expect "as an user", what i would like probably is a 
(very) little separed application that let's controls the few settings that 
make sense on that platform, rather than having full fledged systemsettings

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[René J . V . Bertin]

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 platforms then it was incorrectly positioned and needs to be moved out 

I agree (but am not going to hold my breath). I actually think that even for 
Plasma desktops it would make sense to move the KCMs out of there, at least the 
ones that are not directly related to what makes the desktop or how it works.

>work a valid use case. In my opinion KDE applications should follow the native 
>style on OSX.

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 what I'd expect from members of what's supposed to be a community, 
and doesn't at all motivate me to contribute more on other aspects.

R.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[Martin Graesslin]

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 (which I
> maintain in a parallel prefix using the same packaging scripts as I use on
> OS X) made me realise that plasma-desktop also provides components that
> would be useful for those providing KF5 as an optional "suite" for use with
> a completely different desktop environment that still runs under X11.
> 
> Either way, I've come up with a couple of patches (the
> patch-disable-unwanted* at
> https://github.com/RJVB/macstrop/tree/master/kf5/kf5-plasma-desktop/files)
> which represent an initial approach at evaluating what builds and what
> makes sense on a ~Plasma desktop, X11 or OS X (or MS Windows, presumably).

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 platforms then it was incorrectly positioned and needs to be moved out 
of plasma-desktop. Applications should not depend on the desktop. If an 
application cannot be configured without a KCM provided by plasma-desktop than 
we have a clear bug and that needs fixing.

Please note that I don't consider shipping KCMs to make your own QPT plugin 
work a valid use case. In my opinion KDE applications should follow the native 
style on OSX. With that the need for KCMs from plasma-desktop should be non-
existent.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[Martin Graesslin]

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 supposed to work
> on all major platforms, and as far as it has ever been functional there I
> don't see why it wouldn't be possible to configure it.

Speaking with KGlobalaccel maintainer hat: Applications are expected to 
provide a configuration interface to set the global shortcuts. This is provided 
by standard component through KShortcutsEditor in KXmlGui.

If an application sets a global shortcut without providing a way to configure 
it, this would clearly be an application bug. As the number of applications 
outside the desktop using KGlobalAccel can be counted on one hand (I'm aware 
of Yakuake and Amarok), we can manually check whether they do it.

The module in plasma-desktop is for those components which don't have a direct 
UI to configure: KWin, Plasma, KSMServer, the kded modules. All things from the 
platform specific desktop.

There is in my opinion no need to provide such a component on other platforms/
desktop. KGlobalAcceld should integrate with the native configuration tool on 
other platforms.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
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]

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 to
> > ~/.kde4/kdeglobals as well as the new place.
>
> Ah, yes, indeed. I see that now in the source.
>
> > I hope by now it's redundant, but I'm not sure.
>
> In what way would it be redundant? Do KDE4 applications read in the
> QSP-based
> locations nowadays? Also, I thought there was the idea to keep the settings
> separate?
>
> I'm hoping it's redundant because most apps are ported.


> BTW, does this mean that one shouldn't run the KDE4 and KF5 systemsettings
> on
> the same machine (when they can be coinstalled, e.g. when KF5 is in its own
> prefix)?
>
> > Not quite. This writes the colours out into the file
> > ~/.config/Trolltech.conf
>
> Right, I don't know where I thought I saw output to kdeglobals.
>
> It takes a pointer to it to copy out from kdeglobals.


> > Qt used to load that as a fallback for loading kdeglobals.
>
> If I understood correctly it was more Qt's version of kdeglobals combined
> with
> certain settings from all Qt4-based applications. Something they indeed
> got rid
> of with Qt5.
>
> > Which platform plugin are you using?
> >
> > If the platform plugin doesn't load anything, it seems it will use
> > qt_fusionPalette() which is hardcoded.
>
> Most of the time I use my version of the KDE platform theme plugin (now as
> a
> scratch repo under rjvbb/osx-integratin). It acts as a proxy to the native
> platform plugin. I'll have a look what the native plugin does, but it
> stands to
> reason that it will use an appropriate palette. Not from Fusion I think;
> that
> has a kind of beige window background which we don't get on OS X.
> Doesn't KDE introduce a number of palette elements of its own, like for
> text
> elements, and which don't have a Qt equivalent?
>
> Yeah. "KColorScheme". That ends up opening kdeglobals directly.

aha - and this is how you're ending up with the right colours.
A palette can also come from the qstyle:
http://doc.qt.io/qt-5/qstyle.html#standardPalette

Both the breeze and oxygen style (via kstyle) set the application palette
to the one from the color scheme hence you end up using kdeglobals *if* you
have one of those two styles set.



> R.
>
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[René J . V . Bertin]

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 source.

> I hope by now it's redundant, but I'm not sure.

In what way would it be redundant? Do KDE4 applications read in the QSP-based 
locations nowadays? Also, I thought there was the idea to keep the settings 
separate?

BTW, does this mean that one shouldn't run the KDE4 and KF5 systemsettings on 
the same machine (when they can be coinstalled, e.g. when KF5 is in its own 
prefix)?

> Not quite. This writes the colours out into the file
> ~/.config/Trolltech.conf

Right, I don't know where I thought I saw output to kdeglobals.

> Qt used to load that as a fallback for loading kdeglobals.

If I understood correctly it was more Qt's version of kdeglobals combined with 
certain settings from all Qt4-based applications. Something they indeed got rid 
of with Qt5.

> Which platform plugin are you using?
> 
> If the platform plugin doesn't load anything, it seems it will use
> qt_fusionPalette() which is hardcoded.

Most of the time I use my version of the KDE platform theme plugin (now as a 
scratch repo under rjvbb/osx-integratin). It acts as a proxy to the native 
platform plugin. I'll have a look what the native plugin does, but it stands to 
reason that it will use an appropriate palette. Not from Fusion I think; that 
has a kind of beige window background which we don't get on OS X.
Doesn't KDE introduce a number of palette elements of its own, like for text 
elements, and which don't have a Qt equivalent?

R.


___
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]

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 settings to
~/.kde4/kdeglobals as well as the new place.

I hope by now it's redundant, but I'm not sure.


> 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 happen to
> use
> ... with the QtCurve/gtk2 and oxygen-gtk3 themes. From what I understand,
> the
> export of the KDE colour palette choice is handled by krdb.cpp. Is that
> correct?
>
> yes.
I'm not convinced how much works.

What I cannot determine so easily is whether it does more than that. Isn't
> applyQtColors() responsible for storing the palette colours into
> kdeglobals,
> from where they're read by the KDE platform plugin theme?
>

Not quite. This writes the colours out into the file
~/.config/Trolltech.conf
Qt used to load that as a fallback for loading kdeglobals.

A quick grep seems (unsurpsingly) this doesn't have an effect on Qt5.


> If so, that seems a crucial feature. I just checked: removing the Colors:
> categories from my kdeglobals and changing the ColorScheme key didn't
> change the
> colours of newly started applications (my regular colour scheme is
> hand-tuned to
> match the native colour scheme at least as far as window colours go).
>
> What colours are used when the platform plugin (khintssettings) doesn't
> find
> either any Colors: categories or a ColorScheme string (and the default
> .colors
> file isn't available)?
>

Which platform plugin are you using?

If the platform plugin doesn't load anything, it seems it will use
qt_fusionPalette() which is hardcoded.

David



> R.
>
>
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[René J . V . Bertin]

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 happen to use 
... with the QtCurve/gtk2 and oxygen-gtk3 themes. From what I understand, the 
export of the KDE colour palette choice is handled by krdb.cpp. Is that correct?

What I cannot determine so easily is whether it does more than that. Isn't 
applyQtColors() responsible for storing the palette colours into kdeglobals, 
from where they're read by the KDE platform plugin theme?

If so, that seems a crucial feature. I just checked: removing the Colors: 
categories from my kdeglobals and changing the ColorScheme key didn't change 
the 
colours of newly started applications (my regular colour scheme is hand-tuned 
to 
match the native colour scheme at least as far as window colours go).

What colours are used when the platform plugin (khintssettings) doesn't find 
either any Colors: categories or a ColorScheme string (and the default .colors 
file isn't available)?

R.



___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[Kai Uwe Broulik]

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

> I think that's the most straightforward fix too as 
there apparently is no way to provide just something like a font theme.

Qpt...

> Look at Google Chrome and even Firefox; just how different do they look on 
> the different platforms?

They look the same but then terrible everywhere... :)

> I am definitely more at ease with an application that has a compact 
> interface, uses a "semiserif" font in Medium/Demi-bold for text-only toolbars

Then you should configure your system to use that, and if it doesn't provide 
that, tough luck. In my opinion an application has no right to enforce its way 
of doing things like tabs on the user just because it thinks it's better - if 
the system has opted for a "worse" design we're obliged to implement it.

> 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 
> mappings to platform-native mappings in my version of the platform theme.

The Qt os x platform theme maps shortcuts to eg Cmd+C already. 

> Why would this be different on different platforms?

Because on OS x we are not the platform but applications within another. If I 
want to use Kate I don't want to have a gazillion services running, perhaps 
even after the application has quit. Imagine running Notepad++ and it did that.

> I find the Oxygen theme to correspond better

Definitely matches the 3d style icons better indeed.

> It is certainly true that for MacPorts we consider something like a KF5 
> family, which all share the same Qt and KF5 libraries, use shared resources 
> as on any 
other Unix, etc.

Okay, I on the other hand want to be able to just use Kate or Dolphin as 
standalone applications without pulling in all of the backend services.

> KWallet

Os x has a Keychain system and I would expect applications to use it, running 
KWallet there instead would be a really bad idea, especially given how many 
complaints we get in Plasma already for it being intrusive. 
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[René J . V . Bertin]

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 if we can determine what that is
if (nativeTheme) {
return nativeTheme->keyBindings(key);
}
// or else we return whatever KDE applications expect elsewhere
return KdePlatformTheme::keyBindings(key);
}

(the Mac KDE platform theme acts as a proxy to the native platform theme)


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[René J . V . Bertin]

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

>> them,  applications look just awful on OS X because most text elements will
>> use what Qt
> considers the platform default font (Lucida Grande 13).
> 
> Then this needs to be fixed. Also, the font stuff is enforced by the Platform
> Theme as far as I can see, so toolbar fonts for example will just use Qt's
> defaults for that, not KDE's semantic font.

How? Put platform-specific code at each location where a font role is invoked? 
That's not feasible. I am working on a Mac KDE platform theme which can be used 
with minimal changes to Qt. The default setting will use Qt's platform 
definitions for the various font roles, and the native widget style, so you get 
the "best" of both worlds. I think that's the most straightforward fix too as 
there apparently is no way to provide just something like a font theme.

>> It should be up to the user, and I'd even go so far as to say that this would
>> be a big plus for KDE applications on OS X.
> 
> I wouldn't call an application being ugly (read: not looking like all the
> others) a big plus.

Tastes differ, but you simply cannot defend that definition beyond your 
personal 
opinion.
OTOH one can defend the idea that certain users (probably well-represented 
among 
those who'd want to run KDE apps on OS X or MS Windows) will appreciate the 
fact 
that applications can look as much as possible on all the platforms where they 
use them (which is also in part the reason why Qt 5.6 now allows Freetype-based 
font rendering on OS X). I've argued this before: the advent of web-based 
applications has IMHO led to a more homogeneous look across platforms for a 
growing number of applications. Look at Google Chrome and even Firefox; just 
how 
different do they look on the different platforms?

> You can still re-arrange panels, customize toolbars and so on. Using a
> different theme to boost productivity, really? I agree that an application

Yes. I am definitely more at ease with an application that has a compact 
interface, uses a "semiserif" font in Medium/Demi-bold for text-only toolbars, 
in short, the sort of configuration that QtCurve allows me to get. Not to 
mention the silly tab-bar interface that OS X has, which is OK for dialogs but 
not when it turns up in the tabbed document interface of an editor.
You interact with GUI applications through their interface. If that doesn't 
look 
right you don't feel right.

> like Krita or KDevelop might want to offer a dark theme but then it could do
> that easily from within its settings.

There you have it. It is always possible to tweak quite a few things from 
within 
an application, even launch it with `-style QtCurve` if that rocks your boat. 
Most everything except for fonts, in fact (if you don't have the platform 
theme). Why not go a bit further and make it possible to configure those things 
at a global level (like the Qt4 qtconfig application already allowed)? 
Everything exists for that, just not in exactly the right place.

> Then this needs fixing. If we just use Breeze widget style the incentive for
> fixing it becomes near non-existent...

I've raised that flag before, but no one has ever shown any interest in fixing 
this. It isn't even clear where things go wrong, but since it's only the 
Macintosh style that shows this the issue is probably somewhere in the Qt/Mac 
drawing routines. Not in the qpa, because one gets almost the same glitches 
when 
using the xcb qpa on OS X.

> It's for providing a big-ass theme package consisting of a theme, splash
> screen, and so on, for easy adjustment to other form factors or distribution
> branding.

Not seeing the point doesn't mean that I don't know what it's for, in this case 
;)

> 
>> No, only for a very actions.
> 
> I see most of its actions mapped in the Plasma Platform Theme though.

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 mappings 
to platform-native mappings in my version of the platform theme. It's what I've 
done for other applications too where I intervened at this level.

>> ??? Kded is required for certain features like cookie management.
> 
> Really? Now I can understand why KDE 4 on Windows shipped with a "shutdown
> kde" application. Don't tell me I need DBus as well?!

Why would this be different on different platforms? KDE uses a distributed 
architecture for many things, and DBus is what glues that together. Fortunately 
DBus is enough of a cross-platform messaging API to build and run 

Re: plasma-desktop on other environments (bis)

[René J . V . Bertin]

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 taking the KCMs at all is that will basically come down to 
reinventing the wheel for most if not all configurable settings. I think that 
the most efficient approach would be to reuse the existing KCM infrastructure, 
and probably even the systemsettings application, and mould that into something 
where applications can present an additional settings menu action that brings 
up 
a dialog that corresponds to the current systemsettings application (the icon 
view). Or an additional entry in their preferences/settings dialog that 
switches 
to that view.

Both OS X and MS Windows have "control panels" that have comparable interfaces, 
so this kind of relatively cheap solution shouldn't lead to something that's 
completely counter-intuitive.
On OS X there is probably also a way hook the KCMs into the existing System 
Preferences application (at the very least by invoking a KDE settings 
application from there, which really isn't all that uncommon a practice).

> I've noticed you've solved this by just including krdb (even with fixes!),

The fix is just to make krdb_clearlibrarypath a regular executable rather than 
an app bundle. Knowing now what krdb itself does means I'll probably just 
disable the target (or remove the binaries in my packaging if I'm lazy).

> but having krdb on OS X really doesn't make sense. It won't work.

I know that. My first approach has been to exclude krdb, but then noticed that 
it's needed for building certain other KCMs.
Given the role it plays it would maybe be useful to put it in a (static) 
library?

> I think that's symptomatic of what's worng with this approach - you need to
> identify what things you need and just tell us. Not assume it's everything
> and work backwards.

To put something straight: I'm not assuming anything. I'm taking stock. And for 
that I find working by elimination of working components works best. Rather 
than 
guessing what code does, and figuring out to what extent other bits depend on 
it, I prefer the hands-on approach, putting myself in the shoes of the user. 
Which I am too, after all.

R

___
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]

> 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 right
colours. Super important if you happened to travel back to 1995.
It then grew to include some GTK settings and backporting stuff to KDE4.

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.

I've noticed you've solved this by just including krdb (even with fixes!),
but having krdb on OS X really doesn't make sense. It won't work.
I think that's symptomatic of what's worng with this approach - you need to
identify what things you need and just tell us. Not assume it's everything
and work backwards.

David
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[Kai Uwe Broulik]

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 continue to make sense.

If I click on a link it should open with my default browser. Period. If that 
doesn't work for some reason, then this must be fixed. Adding a setting instead 
is the least desirable solution, this is not kde 3 anymore where we "fixed" 
deficiencies on our side by dumping in setting for the unimaginable.   

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

> No, KDE has its own set of font roles which are independent of the system, 
> but which are used (expected) in KDE interface design. Without support for 
> them,  applications look just awful on OS X because most text elements will 
> use what Qt 
considers the platform default font (Lucida Grande 13).

Then this needs to be fixed. Also, the font stuff is enforced by the Platform 
Theme as far as I can see, so toolbar fonts for example will just use Qt's 
defaults for that, not KDE's semantic font.

> It should be up to the user, and I'd even go so far as to say that this would 
> be a big plus for KDE applications on OS X.

I wouldn't call an application being ugly (read: not looking like all the 
others) a big plus.

> boost their productivity by tweaking the interface to their personal taste.

You can still re-arrange panels, customize toolbars and so on. Using a 
different theme to boost productivity, really? I agree that an application like 
Krita or KDevelop might want to offer a dark theme but then it could do that 
easily from within its settings.

> there's the additional reason that the Macintosh style is not very robust and 
> often leads to misaligned and/or overlapping controls, esp. buttons and 
> comboboxes. This is visible in parts of Kate, but becomes extreme in KCalc.

Then this needs fixing. If we just use Breeze widget style the incentive for 
fixing it becomes near non-existent... 

> I agree that lookandfeel has little interest, but that's probably because I 
> don't see its point anywhere. 

It's for providing a big-ass theme package consisting of a theme, splash 
screen, and so on, for easy adjustment to other form factors or distribution 
branding.

> No, only for a very actions.

I see most of its actions mapped in the Plasma Platform Theme though. 

> Through kglobalacceld? That is part of a framework that's supposed to work on 
> all major platforms, and as far as it has ever been functional there I don't 
> see why it wouldn't be possible to configure it.

Ok...

> Ditto.

If we made an Activity switcher UI for other platforms *that* would be a 
selling point for KDE Applications.

> ??? Kded is required for certain features like cookie management.

Really? Now I can understand why KDE 4 on Windows shipped with a "shutdown kde" 
application. Don't tell me I need DBus as well?! 

> Because it handles audio and hasn't been reintegrated into Qt? Without 
> phonon, no sound, not for notifications, not in kdenlive (or video, for that 
> matter).

QtMultimedia? Also, the Phonon KCM is really not something I want to have user 
needing to deal with... If it's up to the application to do that on os x 
(Windows can do this at system-level) the application should have options for 
that.

> Oh please no, that would really look wrong on OS X.

From what I can tell toolbar icons in os x are black and white outlines just 
like Breeze so it would fit perfectly. 

> Just remember that all these KCMs do is providing an interface to settings 
> that exist and can be modified by hand if required.

I'm not arguing with that but I don't want a setting to be there just because 
we can if it doesn't make any sense on another platform. More importantly, I 
want to avoid having kde systemsettings installed when I just want for example 
Kate. The few settings that may make sense could be embedded in the application 
and that's it.

Unless, of course, we're aiming for a "suite" thing which installs a gazillion 
kde applications at once, then we might as well dump that in, just because, and 
while at it, kded, dbus and Co for good measure, too.

> Settings that are problematic on a 
given platform, for whatever reason, should indeed better be disabled.

Looks like we have a different understanding of "problematic", for me 
problematic is not just when it doesn't build.

Cheers, 
Kai Uwe 
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

[René J . V . Bertin]

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 know) to 
determine what application to use this will continue to make sense. 


> * translations

No, KDE translations aren't linked in any way to the way the system handles 
these, at least not on OS X. This is especially true for applications that 
cannot or shouldn't be provided as app bundles (anything ecm_mark_nongui).

> * fonts

No, KDE has its own set of font roles which are independent of the system, but 
which are used (expected) in KDE interface design. Without support for them, 
applications look just awful on OS X because most text elements will use what 
Qt 
considers the platform default font (Lucida Grande 13). The result is an 
appearance as if designed for the visually and motor impaired (large, spacey 
interface).

> The following could be used but should not:
> * Colors - KDE applications should just follow the system's colors
> * Style - KDE applications should just use the native theme provided by Qt

Again, don't agree in the sense that there shouldn't be an interdiction to do 
something else. It should be up to the user, and I'd even go so far as to say 
that this would be a big plus for KDE applications on OS X. It is near 
impossible to alter the interface of an application using pure Cocoa SDKs, but 
that doesn't mean individual users couldn't boost their productivity by 
tweaking 
the interface to their personal taste. OS X is a great OS but created by one of 
the biggest control freaks one can imagine; well-conceived user-configurability 
thus becomes a sales argument on it.
On OS X there's the additional reason that the Macintosh style is not very 
robust and often leads to misaligned and/or overlapping controls, esp. buttons 
and comboboxes. This is visible in parts of Kate, but becomes extreme in KCalc.

I agree that lookandfeel has little interest, but that's probably because I 
don't see its point anywhere. Disabling it will also make my patch simpler, I 
think.

> * Standard actions (that's for changing defaults like
> Ctrl+C) - KDE applications should just follow the system's shortcuts which
> Qt's QPA already takes care of

No, only for a very actions.

> 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 supposed to work on 
all major platforms, and as far as it has ever been functional there I don't 
see 
why it wouldn't be possible to configure it.

> * Activities

Ditto.

> * kded (perhaps we have a kded running, in this case: wtf)

??? Kded is required for certain features like cookie management. It may be 
overkill to provide a KCM to control the services it provides, but the same 
would be true everywhere.

> * Phonon (why does this thing even still exist)

Because it handles audio and hasn't been reintegrated into Qt? Without phonon, 
no sound, not for notifications, not in kdenlive (or video, for that matter).
At the moment there isn't much to configure but a future VLC and VLC backend 
should expose individual audio devices (rather than just the default device 
selected through the system preferences). That will make it possible to route 
notifications to one device, music through another and video through yet 
another, 
just like on Linux. There is no fine-grained control of that at the system 
level 
on OS X, it's left to applications. 

> The following I have no idea what they even do:
> * Krdb

It seems to be a component in a number of other KCMs.

> * icons - might be desirable for the user to change but then we could
> also enforce Breeze icons on other platforms as part of our design, especially

Oh please no, that would really look wrong on OS X.

>* spellchecking -
> but then Sonnet should follow / use the platform's settings and dictionary

We'll get back to that when it does, then.

Just remember that all these KCMs do is providing an interface to settings that 
exist and can be modified by hand if required. Settings that are problematic on 
a 
given platform, for whatever reason, should indeed better be disabled. Doing 
that with settings that work fine (like shortcuts) is just going to make the 
code 
more complicated.

I agree that the default configuration in a clean KF5 install should correspond 
to platform guidelines, but if the functionality exists to adapt those settings 
to personal preference or capabilities users should be able to benefit from it. 
It's an added value.

> As for non-KCMs, both OSX and Windows provide a native replacement for
> KNetattach.

I haven't yet figured out what that does. It built, so I didn't exclude it for 
now.

R

Re: plasma-desktop on other environments (bis)

[Kai Uwe Broulik]

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 system-provided ones:
* Keyboard
* Input
* Access
* Dateandtime
* hardware (joystick)
* desktoppaths
* componentchooser
* formats
* translations
* useraccounts
* cursortheme
* touchpad
* fonts

The following could be used but should not:
* Colors - KDE applications should just follow the system's colors
* Style - KDE applications should just use the native theme provided by Qt (eg. 
Vista or Aqua)
* Standard actions (that's for changing defaults like Ctrl+C) - KDE 
applications should just follow the system's shortcuts which Qt's QPA already 
takes care of

The following are unneccessary because we don't provide/have to provide that 
feature outside a full Plasma session:
* Autostart
* Ksplash
* Launch (the bouncing launch feedback cursor)
* Desktoptheme (we don't have Plasma outside of Plasma)
* Global shortcuts
* KSMServer
* Look and feel
* Activities
* kded (perhaps we have a kded running, in this case: wtf)
* Phonon (why does this thing even still exist)
* Runners
* workspaceoptions
* baloo
* solid_actions

The following I have no idea what they even do:
* Krdb

The only ones I could see being used outside of Plasma, but then I don't really 
want a "systemsettings" application, so better the app that uses it should 
provide it:
* emoticons - a chat app should proxy that kcm into its own settings
* icons - might be desirable for the user to change but then we could also 
enforce Breeze icons on other platforms as part of our design, especially on 
Windows it's perfectly normal for every app to apply their stupid "we are so 
special" custom design on the user, so we might as well do the same ;)
* knotify - the app itself usually has an entry to configure those from within 
the app; btw we need a windows backend for KNotification :)
* spellchecking - but then Sonnet should follow / use the platform's settings 
and dictionary

As for non-KCMs, both OSX and Windows provide a native replacement for 
KNetattach.

Cheers,
Kai Uwe


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

plasma-desktop on other environments (bis)

[René J . V . Bertin]

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 on OS 
X) made me realise that plasma-desktop also provides components that would be 
useful for those providing KF5 as an optional "suite" for use with a completely 
different desktop environment that still runs under X11.

Either way, I've come up with a couple of patches (the patch-disable-unwanted* 
at https://github.com/RJVB/macstrop/tree/master/kf5/kf5-plasma-desktop/files) 
which represent an initial approach at evaluating what builds and what makes 
sense on a ~Plasma desktop, X11 or OS X (or MS Windows, presumably).

I saw that enough changes will land in the next Plasma release that my patches 
require modification, and I'm not yet at the point where I feel I can do a RR, 
but I wanted to put those patches in the open. The one for OS X also contains a 
few changes to files clearly set up to depend on X11 only optionally but that 
let hard dependencies (#includes and libraries) slip in.

I remember that some on here thought that a more "platform native" interface 
should be offered instead of the current KCMs, or at least that there should be 
a means to get at these KCMs through "regular" applications rather than through 
kcmshell5 and/or systemsettings5 (like kwalletmanager5 calling the kwallet 
kcm?). Both alternatives clearly require a good deal of preparation and 
implementation efforts, esp. the former.
Maybe the initial steps I just made today can get this process going by 
inciting to put at least the KCMs in their own project?

From kcms/PURPOSE:
> On other environments the already provided equivalent should be used.  In

The problem with that POV is that those "other environments" typically do not 
know anything about KDE-specific settings, even if it does have equivalent 
settings (and it will probably more often than not be impossible to "link", 
say, native font settings to the KDE equivalents).


R.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel