SLC for all 4.10 workspaces (was: Re: How Can I change wallpaper from CLI?)

[Albert Astals Cid]

El Diumenge, 9 de setembre de 2012, a les 14:24:16, Mario Fux va escriure:
> Morning
> 
> As I'm sold to the SLC concept

Maybe you could explain to us mere mortals what's the difference between 
Share, Like and Connect.

I understand Share, but Like and Connect is just Share to me.

Note: I've never used SLC since doesn't seem to be easily usable on the 
desktop.

Cheers,
  Albert

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