Tuesday, August 26, 2008

plasma-mid

My current areas of interest for 4.2 for plasma can generally be lumped into the following categories:
  • Context: exporting the current activity and location to both plasmoids as well as other applications via Nepomuk (in progress; Nepomuk people were much more excited about this than I expected, usually I'm the excited one ;)
  • Services: continuation of the JOLIE integration which I've blogged about in the past, as well as tieing in service announcement, discovery and user negotiation.
  • Scripting: getting scripting to where it really needs to be; this is mostly being shouldered by the bindings crew, but I have some heavy lifting in the security and management areas
  • UI smoothing: big target is the Add Widgets dialog which is due for a major overhaul
  • MIDs, or mobile internet devices (yes, such as, but not limited to, the N Series devices)

This is, of course, in addition to the usual suspects like the wallpapers and panel hiding and new engines and widgets and ... and ... and ... thankfully the rest of the Plasma team seems to be as (hyper-)active as I often am. ;)

For the MID we've created a new Plasma "shell". If you're using KDE4, you're already using one such shell: the Plasma desktop workspace. A shell is simply a bunch of windows arranged in a way to provide access to all the goodies on the Plasma scene. The desktop shell provides desktop layers, panels, dashboards, panel configuration, etc.

The MID shell is much simpler than the desktop shell, since it is meant for devices with a far less chaotic life; you don't, for instance, often hook up multiple monitors at different resolutions to a MID. ;) It currently weighs in at just over 500 lines of code and provides a control area and a view area. It took me all of my Sunday and part of my Monday hacking time to put together.

This is just the beginning, of course. At Akademy we had a number of conversations culminating in a chalkboard frenzy on the last day about what we wanted to do with Plasma on MIDs. We will need to write one or two new wigdets, but several of the widgets we are able to pull directly from the existing code base. In fact, some of the work on the MID target will be also to the benefit of the stuff you see on your desktop.

As we make progress in turning our ideas born at Akademy (and which we continue to discuss on the mailing list) into code, I'll post updates here. We've got some cool ideas to put into place, and the whole idea of having a system tuned for a MID but which works with my laptop out of the box excites me. Being able to share code between the desktop shell, plasma-mid and other projects like Ivan's embedded system is also really tantalizing.

You can run plasma-mid from svn in a normal desktop session right now, even without a scratchbox or other special dev environment. For actual deployment and interaction testing, putting it on a device is obviously the way to go though. ;)

12 comments:

Frédéric said...

is iPhone an MID? Have anyone tried to use Qt on such device?

Some said...

Speaking of the Add Widgets dialog: when I played with KDE 4.1 at the weekend, I installed a Dashboard Widget, it look pretty broken though, so I wanted to remove it... I couldn't find such an option though. That would be useful :)

Janne said...

not directly related to your post, but related to plasma: will 4.2 have the MacOS-like menubar-plasmoid? It was listed as "in progress" for 4.1, bit apparently it never quite reached the finished state. In the 4.2 feature-plan, it's nowhere to be seen.

Or is it already in 4.1? I haven't actulally tested 4.1 since I don't currently have suitable computer to try it on.

Dr-KDE said...

I like the folder view and the plasma activities. I think they can still offer much more. There might be some overlap between the virtual desktops and plasma activities. I have a scenario in mind and I think it will be very useful to me and others, as we all use computers for various things. Lets say I have the following 3 activities.

1) Reading/Writing: I have some PDF documents open in Okular and I am using Kile to write a latex document.
2) Programming: I am using Kdevelop, Qt assistant, some web pages and several text editors.
3) Mail/Browsing: I have Kontact open, Konverstion and a web browser

I think the idle situation is to have 3 activities, with different folder views and widgets on each. Also, 3 panels showing only the running applications from each activity.

Should plasma activities and virtual desktops be merged together? Or at least an easy way to link between an plasma activity and a virtual desktop.

seajey said...

2 janne:
MacOS-like menubar-plasmoid is a part of Bespin style:
http://www.kde-look.org/content/show.php/Bespin?content=63928

Ville Voutilainen said...

Multiple monitors with different resolution for a MID? Well, you may be surprised.. ..many MIDs have a tv-out that brings us exactly the scenario you described.

Aaron J. Seigo said...

Frédéric: the iPhone nearly fits into the MID category, though being a mobile *phone* steps it over the line into another category; but user interface wise that's just splitting hairs and i'd say that it's in the ballpark of devices we have in mind, yes.

@some: that's already requested on bugs.kde.org, so will eventually make it in =)

@janne: it's still in playground. i need to speak with the developer about their plans for it...

@dr-kde: yes, you just described one of the ways activities are designed to be used. as for virtual desktop affinity, i want to work on that for 4.2; not everyone works that way, though =)

@Ville Voutilainen: it's not the same situation as on the desktop where you can install a new video out device (graphics card, tv out, whatever) and start hooking devices up to it. in the desktop case plasma has to watch the running environment carefully and adapt as it changes.

with MIDs, those that do offer video outputs that i've played with are still fairly well controlled as to what they can do, e.g. a maximum resolution they support. at the very least, we know that the MID will support either one or two screens maximum, and whether or not the second screen will be a clone of the internal screen.

if such device simply clones the screen (which is what seems to be the common case), we only need to worry about resolution changes (already handled) and not supporting multiple monitors with separate content.

knowing all these things ahead of time makes it easy. and for devices without video out or that only support a clone mode, it becomes even easier of course. =)

Mark said...

Sounds like a custom Plasma shell would also be the appropriate solution to KDE on a netbook like an EeePC...

I'm liking this.

A major strength of the Linux kernel is that it includes *everything* you could want in a kernel but goes out of its way to make it *easy* to plug together the pieces you need. It seems like KDE 4 is applying a similar philosophy to the UI level - really exciting.

alsuren said...

Regarding scripting support: For me, scripting languages in KDE always seem like second class citizens. Statements like "If it's not written in C++, it's not getting into SVN" -- amarok devels. In the GNOME community, they seem to be more diverse.

When you get scripting support to where you want it, be sure to post about it here (with examples). I have a few python based projects that would work really well as plasmoids, but which use the xdg and sqlite3 python libraries, and I don't know how easy it will be translate these to use the C++ equivalents.


Regarding "MID"s: What's wrong with calling them "internet tablets", as we did when they first came out, or "web tablets"/"net tablets" in the same way that we call the eeepc form factor "web books"/"net books"?

We have a saying in Cambridge that goes something like: "Using TLAs is the simplest way to make intelligent people feel stupid."

Aaron J. Seigo said...

@asluren: "If it's not written in C++, it's not getting into SVN"

we have python apps in KDE; such as the printer configuration tool in kdeadmin. so things have changed =)

"When you get scripting support to where you want it, be sure to post about it here"

that's the plan =)

"(with examples)"

those will appear on techbase, but i'll be sure to link to them from the blog.

"Regarding "MID"s: What's wrong with calling them "internet tablets","

MID has become a general term used for this category of devices (thank Intel for that) and plasma-mid is nicer to type than plasma-internettablet. ;)

as for distinguishing between MIDs and netbooks, for the interface side of things that distinction isn't always accurate.

seeing as the user will never see the term MID, i also don't think it's worth pouring too much effort into a perfect taxonomy either =)

JMiahMan said...

It would be nice to some how still have the option for multiple screens. I'm the Maintainer for EeePCLinuxOS.com. A PCLinuxOS based Distribution that specifically targets the EeePC. The EeePC has a Intel 915 chipset that can obtain a multiple monitor status by using Virtual Modes in X so I just say I have a 2048x2048 desktop and place the 1024x600 screen for the EeePC in the lower left of the 2048x2048 box and have a 1024x768 monitor take the rest. I know it's not pretty as I have some wasted space above the 1024x600 screen but it works and allows (at least the 900) the EeePC to be even more functional. I know a lot of this become complex because of the Intel driver for Linux which seems to be screwed up as with Windows there's no issues with Xinerama support. For now though it's a solution and at least in this instance and most likely a few others as they all seem to be Intel based, it would mean that the MID interface for multiple monitors might need to be just as complex as normal if not more. Now you are having to deal with displaying in a small space and still being manageable in a larger space.

Aaron J. Seigo said...

@JMiahMan: the 900 and above really start to leave the MID screen capabilities ballpark and enter low-end-notebook territory.

as such, i really don't think there's much to gain from not using the Plasma desktop shell in that case, which handles such situations very gracefully.

but let's make it complicated and say that we have a device that in one mode is Definitely A MID and in another mode becomes Possibly A Laptop; in that case there's no reason you couldn't switch between the two shells at runtime when going from one mode to another.

the code to make that happen would be pretty trivial.