Morning
As I'm sold to the SLC concept and start to miss it on the Plasma Desktop and
read the below message here I'd like to propose the following:
Make SLC a release goal for 4.10 and include it in as many KDE apps as
possible.
And to reach this goal I propose the following:
- Organize a weekend when the SLC developers are available for help and
interested developers and app developers can get help to integrate SLC in
their app.
- As I'm not a developer myself I'd offer some of my time to coordinate and
document this. My time proposal would be in October (as then the Randa
Meetings 2012 are done ;-).
So what do you think? Should I start a doodle to find weekend?
Thx
Mario
PS: I often use the "Send file as pdf..." in LibreOffice and would love to use
this kind of feature in all my KDE apps.
Am Donnerstag 06 September 2012, 13.50:19 schrieb Aaron J. Seigo:
> On Thursday, September 6, 2012 12:47:16 Kevin Krammer wrote:
> > The problem with that (as far as I can tell) is that this would not be
> > available to non-KDE apps, which (again as far as I understand) is the
> > case of the thread starter.
>
> if the issue was non-KDE apps, this would be an interesting starting point
> for discussion.
>
> but the discussion moved to the example of a KIPI plugin for digikam. that
> is a KDE application.
>
> once we get our own house in order, then i'd love to discuss about how we
> interface with the rest of the world.
>
> > D-Bus interfaces have the advantage of being accessible from almost any
> > program technology stack, most times even from shell scripts.
>
> qdbus org.kde.ActivityManager /ActivityManager | grep Resource
>
> we're smart enough to implement things in ways that aren't completely
> stupid. ;)
>
>
> and really this is a design question ("is associating URIs and metadata
> with windows a good / better solution? if so, how?"), not an
> implementation problem ("what is used for remote procedure calls?").
>
> even if the implementation is bad (though i don't believe it is), we can
> usefully improve the implementation as long as we have a good design to
> start with; the reverse is not true however -> design flaws don't get
> fixed by improving the implementation of them.
>
> currently when it comes to things like setting wallpapers, our design
> sucked.
>
> so some of us worked on improving that, and if you look at its use in
> Plasma Active you can judge for yourself whether or not it is an
> improvement or not.
>
> and now we're asking the rest of our community to use that improved design
> broadly including on the desktop.
>
> > > show me a dbus api for wallpaper setting that can do that. :)
> >
> > Just curious: what kind of non-D-Bus communication mechanism is used by
> > that?
>
> it uses DBus. the differentiation is that it isn't focused on "making
> something to set a wallpaper" but focused on "allowing content to be
> introspected so that things can be done for/with that content".
>
> making an API for "setting wallpaper" is not only fragile (see the
> differences in KDesktop 1, 2, 3 and Plasma; see the differences for
> windows, mac, xfce, gnome, etc) it is also very limited in scope and needs
> to be upkept in every single application.
>
> the design concept of "expose the URI of the content this application
> window is showing" suffers none of those limitations. and it lets us do
> the trivial things like "set that as a wallpaper" easily: it's writing one
> plugin for one app (SLC) instead of writing one plugin for every single
> application out there.
>
> really, it's the same thinking that went into things like kparts.
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
