future proofing and cross-platform assurances seem to be pretty high on the kde4 list of things to accomplish. take phonon for instance: it's giving us an API that allows kde4 apps to use different media backends without backend-specific code polluting them. so as media backends change both between platforms and over time, kde4 apps are protected.i think this can be extended to other scenarios, including much more trivial ones. i have two classes on disk right now that fall into this category: KAutoStart and KPresentationControls. the latter's name sucks; i just haven't thought of something better yet.
KAutoStart allows apps to, you guessed it, register an app to autostart or not in a platform independent way. well, right now it only contains code appropriate to unix/linux systems following the xdg specs with some extra kde goodness sprinkled in there, but it hides it all behind an API. this guy will be making it into svn (pending necessary blessing) on monday; i just have to finish the unit tests for it.
KPresentationControls right now wraps screensaver deactiviation and eventually will be extended to cover other things one might want to deactivate when showing a video, fullscreen audio visualizations or a slide presentation (as three examples that leap to mind right now). these "other things" would include turning off desktop notifications (e.g. passive popups), network messaging services (so you don't get potentially embarrassing IM popups when in front of a crowd *rolls eyes*), etc.. not only are the ways to do this different from platform to platform, but they even change on our "home" platform of X11: frederikh just recently contributed a patch to x.org that adds an api for screensaver activation. for x.org's that have these, we'll be able to use that (more efficient and correct) way of doing it and for those that don't we just fall back to the usual "send a fake key event every 55 seconds" approach.
i wonder what other sort of system services need wrapping ala phonon, solid or these two classes? and i wonder if these "system services" classes should be in a separate library or wrapped into kdecore or...? hrm.
8 comments:
I wonder if there is some way to reuse distro-developed code that controls hardware in KDE Solid.
For example, SUSE's YAST can already detect and set up hardware such as Bluetooth devives, Infrared devices, joysticks, scanners, TV tuners, sound cards, graphics cards, network cards, faxes, modems, disk controllers ...... you name it! Mandrake, Linspire and Xandros have similar capabilities.
So why are the KDE Solid developers starting from scratch?!
> to reuse distro-developed code
> that controls hardware
one example of that would be HAL/DBUS, which is currently the only backend for solid (though hopefully once solid's api firms up (excuse the pun) that will change)
> YAST can already detect and set
> up hardware
new hardware detection is a rather different matter from hotplug and configured hardware interaction.
> So why are the KDE Solid
> developers starting from
> scratch?!
er ..... they're not.
it seems you misunderstood the purpose of solid which is to provide a nice KDE-style API that sits on top of platform-specific APIs such as HAL/DBUS.
new hardware detection is a rather different matter from hotplug and configured hardware interaction.
YAST doesn't just detect new hardware. You can, for instance, adjust volume on the fly, which is something Solid/Phonon aspire to do. So I'm suggesting that Solid/Phonon developers look at how YAST handles it. If they like what they see, they might even want to reuse some of the code.
There was talk on the Solid mailinglist about managing LVM partitions. YAST already has a spiffy tool to do just that, so I think they could save a lot of time by reusing some of the YAST code. Unfortunately, it seems that neither YAST nor any other Qt/KDE-based config tools from other distros are on their radar.
> There was talk on the Solid
> mailinglist about managing LVM
> partitions
yes, -if- HAL (and/or other hardware backends) provide support for that -and- it turns out kde apps need/want support for that.
it's not like they are rolling their own LVM support.
what do you think about an cryptographic backend? qca? (if it is not already planned (?))
Printing.
Right now, KDEPrint assumes CUPS (mostly at least) to provide the underlying printing service. And indeed, CUPS is now present on most Un*x systems (even Mac OS X uses it now).
KDEPrint can even switch on the fly, since the 2.2.2 days, to a different underlying system: LPR/LPD being the 2nd most used system right now.
But what will happen for KDE apps running on Windows? How is printing supposed to work there??
> what do you think about an
> cryptographic backend? qca? (if
> it is not already planned (?))
it's already in kde4's kdesupport module. =)
> But what will happen for KDE apps
> running on Windows? How is
> printing supposed to work there??
good question. my guess is that the win32 kde devs will simply use the printing GUIs provided on Windows.
this has some nice advantages for everyone, i think:
it makes the win32 devs job easy.
it makes maintaining kprinter easier since there will be minimal amounts of win32 code in there.
it preserves our platform advantages when it comes to printing on Linux (ease of set up, pdf printing, powerful UI, etc)
Just for googlers coming back to this post; the class ended up in kdelibs being called KNotificationRestrictions
Post a Comment