Boudhayan,

I'm not sure why you think the MacPorts approach has anything to do
with running a full KDE experience. Macports is just a packaging
system, and in KDE's aspect of MacPorts it's only to get our
applications and libraries, there's no intent that I've seen anywhere
with MacPorts (or Windows either) to run plasmashell etc.

BR,
Jeremy

On Mon, Nov 30, 2015 at 7:05 AM, Boudhayan Gupta <bgu...@kde.org> wrote:
> Hi all,
>
> We've suddenly been having an influx of MacPorts specific patches, and
> most of them have ended up generating some sort of controversy because
> what I perceive to be some differences in envisioned use-cases.
>
> Unless I'm much mistaken, the "full KDE experience", if I may call it
> that, is intended to be provided on Linux, BSD, Solaris(?) etc where
> you can install and run the Plasma Workspace as your primary desktop
> experience. In these cases, Plasma takes over system and session
> functionality, and we need all these invasive code that reaches deep
> into the system APIs.
>
> On platforms where the "full KDE experience" isn't available, my
> assumption is that we're supposed to provide application bundles
> (.application on Mac, bundled .exe installers on Windows) which
> include the application and all its dependencies in one single
> package. These applications are supposed to behave exactly like other
> applications on these platforms - there should be no difference
> between how say Keynote presents itself on Mac to how Calligra Stage.
>
> MacPorts seems be going on a tangent that no KDE developer is
> interested in - trying to get as much of the "full KDE experience" as
> possible on a platform where it's clearly going to be very half-baked
> and unusable (pretty much a gimmick) because we really can't latch on
> and grab that kind of low level system and session management stuff in
> OSX anyway.
>
> I'm of the opinion that we shouldn't be admitting invasive
> MacPorts/Fink (or even KDE on Windows) patches that attempt to reach a
> goal of running a full Plasma session on any such platform (or even
> attempt to package-managerise KDE on such platforms). But this is a
> community, and it should be left to decide what it wants on its own.
> That said, we should really lay down official policy soon before
> discussing the current MacPorts patches any further, because pretty
> much every thread is devolving into heated arguments that's taking up
> developer time as well as making them feel not happy.
>
> Yours,
> Boudhayan Gupta
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Reply via email to