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