Corona change

November 29, 2007

In this week’s Commit Digest, there’s one entry that seems simple enough by Aaron:

completely change how we save and load containments and panels.
it all happens from one file now using nested groups. this has two major effects:

– one file to rule them all for any given corona; this makes things even nicer for use in other apps, btw.
– the ability to easily save, send/share and restore corona configuration layouts; something i’ve wanted from the start

But stop and give that some thought.  This commit hints at a future desktop that eventually gets better at:

  • Downloading:Get desktop configs from kde-look.org and/or GetHotNewStuff.
  • Sharing: Share your desktop attributes with a friend via email or Kopete
  • Administer: Give more flexibility/control for large desktop deployments
  • Back-up: Save off layouts like profiles (home, developer, creative, student)
  • Ubiquity: Carry them on a USB keyring to give VNC/RDP/Citrix like familiarity to any KDE desktop you use
  • Demo: Centrally store desktop info to give consistent KDE desktops for expos/conferences/etc
  • Interface: Above and beyond KControl, what happens when applications have more significant interaction with containments and panels?  With network transparency and plasma data engines and D-BUS, how data is transmitted and what you see and who sees it and where it comes from all starts to blur.  Online collaboration is more than just a whiteboard or window.

If I were transported back to my college years (a wish I think about roughly 745 times daily) and were looking for an internship or a topic for a senior thesis or something to help get me a job after graduation, I’d immediately start thinking about getting Kiosk modernized with respect to Plasma.  Someone really needs to get a Google Summer of Code project this upcoming season on this topic.  Updating Kiosk would show a mastery over several disciplines.  Hell, if you pull it off and live in the U.S., I’ll hire you.

5 Responses to “Corona change”

  1. Chani Says:

    ooh. I missed that commit. and I was thinking about this sort of thing just yesterday – how nice it might be to load and save configurations. especially if we have a plasma screensaver someday (I’d want a separate screensaver config for parties).

  2. Lee Says:

    On saving to files… what happened to the plan for testing out different networked, hierarchical configuration engines?

    p.s.: this isn’t criticism, just a question🙂 Ok, and maybe a little bit of disappointment — I’d still like to see KDE settling on a great standard config system🙂

  3. Aaron J. Seigo Says:

    > what happened to the plan for testing out different
    > networked, hierarchical configuration engines

    nothing. kconfig in 4.0 has proper multiple back end support. the amount of work it took to get it there was immense and involved 3 incremental refactorings of the code base, each of which were impressive and non-trivial.

    now that we have a properly designed kconfig API with pluggable back ends, we can go about writing backends post-4.0 to try out different things.

    4.0 really is a foundational release for many of our goals. unfortunately, one has to be build the foundation before the house.

  4. NJ Hewitt Says:

    Nicely spotted and extrapolated – those bullet points you listed are exciting possibilities.

  5. Someone Says:

    So multiple backends are in, and the default is this one file with all the goodies Wade points out, sounds great, thanks for the hard work and the info Wade and Aaron


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: