[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    SLC for all 4.10 workspaces (was: Re: How Can I change wallpaper from CLI?)
From:       Mario Fux <kde-ml () unormal ! org>
Date:       2012-09-09 12:24:16
Message-ID: 201209091424.17192.kde-ml () unormal ! org
[Download RAW message or body]

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.
[prev in list] [next in list] [prev in thread] [next in thread]