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. -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<