tinyminds.org is featuring an interview with Shamyl Zakariya on the development of SlicKer, an alternative to KDE's Kicker panel. "SlicKer intends to provide similar functionality [as Kicker], but in a more modular, task based kind of approach; one "card" per logical function. There will be a kmenu card, a taskbar card, a system tray etc card, and so on." Conceptual drawings and a first actual screenshot are available. "I can honestly say that I'll be releasing an alpha for CardDesk in a month or two. When I say alpha, I mean feature complete, but not necessarily API stable or for that matter, stable (as in, not crashing)".

There are plenty of ways to contribute to KDE even if you can't code or compile the cvs version. Promotion, website, documentation, organisation, usability, interviews, bug reports, advertising, translation, ...

If you would like to contribute some of your spare time although you don't have any coding skill, please drop me a mail (or better, to kde-promo). We can work something out together.

From what I can see it KDE3.1RC7. And that is a good thing. A lot of things have bin fixed since RC6 and the last releas candidate should really be tha same thing as the final release. Just make sure that they wait a couple of weeks before they release the real thing. It takes quite a while to check everything out.
Perhaps we can get a rock solid release for once.

Yes, Kicker is good. But it's nothing new. It does what it's supposed to do and it does it well. But everyone has something similar (GNOME, Windows, Mac OS...). Slicker is something different. And what's important: it's not different for the sake of being different. It actually seems highly functional.

Why not have talks with the Slicker-people and try to make it an official part of KDE? Users could then decide between traditional Kicker and Slicker. Maybe in KDE 3.2?

I was a little bit surprised, when I read that Shamyl Zakariya is developing a kicker alternative. Have a look at the kde 3.2 feature plan [1] and scroll down to Kicker (in the red section): "Task oriented KMenu alternative Aaron J. Seigo ".

Does that mean that there are two projects? Or are you working together? Or am I just stupid and KMenu is not the same as kicker?
Thanks for any clarification.

Looks fantastic! This type of application has such a massive impact on one's desktop experience. Anyone who's prepared to do a bit of redesigning to make better use of those limited pixels, or to make the environment look sexier, deserves huge support! Trying out ideas should be what open source is all about.

This looks really nice, and I applaud the courage to try out new things.
However, I personally don't like having launch buttons below the kmenu. With the current setup I can simply move the pointer all down left on the screen and click to fire up the kmenu. With launch buttons just below the menu, I'd have to move all down left and then carefully move slightly up to hit the menu.

Shamyl seems to haves a rare and valuable mix of skills, both graphic designer and programmer. A designer who has the wherewithall to make his ideas happen. Certainly the screen shots look fantastic. The idea sounds great. I hope it plays out as well as its sounds.

Heh. I just got back in town; I spent the long weekend in philly with my GF and her friends and family. I actually spent a few days without thinking about CardDesk.

So, anyway, I have to say, just in case I don't make it completely clear what the distinction between CardDesk and SlicKer is... CardDesk is a framework and API, SlicKer is a kicker replacement which will be written on top of CardDesk.

Anyhow, I want to let you all know I'm excited that you all are excited. It's fun to do some work which people can share in. Most of my programming experience is writing code for myself, to scratch my own itches. This is a nice change.

When I release an alpha of CardDesk, I intend to include a handful of applets. The two main applets which excite me however are the konq filemanager applet and a "scratch pad" applet which will basically be a cut-n-paste and drag-n-drop repository. It will be a place you can drop off data types for retrieval later. E.g., you have a page or two in an essay you're writing which you want to rewrite. Well, you'll cut the text and paste it into the scratch pad and it'll stay there with everything else you've pasted until you explicitly delete it. You ought to be able to drag in images, text, urls, whatever. Anything you can cut and paste or drag and drop.

I can't say off the top of my head what else I'll write. I'll just go where the wind takes me.

- IM (ICQ!) support with seeing how much messages (and from whom) there are (this means mainly integration with Licq/SIM/gaim etc. - nowadays it's much more better but still not perfect - best would be one general interface (XML?) for all such apps)

Actually, I have been thinking about the PIM route. The app I run the most in KDE is the adressbook client since I have a terrible memory.

The others, like mail and remote monitoring might be outside of my capability, since I'm not a network programming buf. Hell, I never had a decent network connection until last year. But it ought to be easy for others to write such plugins ;)

But, here's one thing that's important: My current codebase has an ABSOLUTELY broken layout management system, with respect to how the card elements are stacked and rotated. It works, but not well. Stacking cards with different widths works, generally, but not reliably. It's all my fault because I didn't properly understand some of the subtleties of QLayout

As of last night I finished writing a new set of classes which work more clesely with proper Qt layout management to handle this better. My tests work great, and after I've tested them more thoroughly I'll integrate it into the codebase. The good news is that once it's integrated, I ought to be able to cut out perhaps as much as 500 lines of code, since I'll be able to kill the LayoutSwitcher class and assorted hacks to make it work.

Until I get the layout fixed, I'm not going to progress. I'm more concerned with the system working right, than moving forward.

I am glad to hear CardDesk will be a framework. Will the applets you release work across other WM's. I use enlightenment and like it, but the cards look like a great idea. I would love to use them in enlightenment. If you want someone to test you applets on enlightenment I would be glad to help.

A fella on the gentoo forums tested it against several different WMs; it worked great under all but Metacity and WindowMaker; it basically didn't work under Metacity, and was dog slow under WindowMaker.

I don't know about enlightenment... I don't think he tested against that. This doesn't require KDE to be running anyway, just that you have kdelibs installed.

I've seen the marvelous shots and concept drawings, and I've got an idea for the K Menu, instead of making it a special card, why don't you include it in
the clock and task area(the little panel at the bottom right of the desktop in the large drawing) this little panel could be moved and all the basic functions (Pim,status bar, Menu and quick terminal) will be in the same accesible place

I really feel impressed by this desktop, it looks highly useable and rather nice.
It would be cool to add a new voice in the macOS-XP struggle for nice GUIs, a linux one.
I notice several projects theses days that propose radical changes to linux desktops and
very good ideas to enhance human computer interaction in new ways. It's good to see that the free software movement starts getting it's R&D departments working on "massively adopted" projects like KDE. This can change the *nix desktop and maybe more.

I think user interaction is the achilles' heel of linux,we all know it...
(remember when you wanted your mother, sisters and friends to use linux)

I am sure many people out there would appreciate to be able to compile and test and give feed back about Slicker (ok, I am lying, I just want to use it.. :) ).

I would really like, if one could associate a virtual desktop with a card. This assosiations should be able to be configures, so you can have cards, that do not change the desktop (like Information) and one or more cards that change to a specific desktop (like MailCenter and OfficeCenter changing to the same "OfficeWork"-Desktop). Also one should be able to add shortcut-icons to a card (like in the menu-card) which are hidden while the card is collapsed. this would allow users to really cleanup their work-environments...

I've been considering making cards be per-desktop. Right now they are across all desktops, but that's only because that's easiest for me at the moment. The one thing that I *can't* do however is support xinerama in a meaningful way, since I don't have a dual head machine (just a thinkpad).

But, if a card is not present on all desktops, it will be present on only one desktop. I don't think I can make a card be visible on desktops 1 & 3 but not 2 & 4. It's all or one, as far as I can tell.

hmm... for the problem, of one card on multiple, but not all desktops, you could consider to use different cards with the same content as workaround, but this may waste resources. a little bit more optimized would be, to only have a duplicate of the title bar on another desktop and move the original card to the active desktop if one clicks on the title of the duplicate.

the idea i wanted to present in the first place, was that the cards should replace the desktop-switcher. i assumed, that all cards are visible on all desktops, so activating a card could be used to change to an associated desktop.

This idea is just superb. Finally something to show these people talking all the time about how KDE only copies Windows interface ideas. And it seems *very* interesting from the usability point of view...

The conceptual drawings and the first screenshots look great. But most of the time i have several windows open. Are the cards then hidden? Or do they overlap the windows? Cards and panels are great, but in the end workspace is what matters. The more the better. I, for example, just the start button rarely the only thing i use on the panel is the taskbar and the virtual desktop switcher.
I hope it doesn waste too much space in the end - since it looks pretty cool.
- Stephan

This is something which, sadly, I just haven't addressed yet. The current behaviour is to be always on top, and to not hinder the positioning of maximized windows. Tabs can be small enough that they don't overlap too much, for example, less than 22 or so pixels -- in this case having the tabs on the top, left or bottom is fine because they won't overlap any important part of the maximized app. The right sid eis no good, though, because the tabs might overlap the scrollbar :P

Frankly, I'm not certain what the best approach is. I might have a configuration option to allow for tabs to be always on the bottom (just above the desktop) but be raised when the mouse cursor touches a screen edge.

one solution could be to make the tabs half tranparent. a card should the switch to opaque and clickable if you hit the screen-border at a position, where this specific card touches it.

this however might provoke some unwanted behavior, like opening a card instead of dragging the scroll-bar. but thats a delay-balancing issue. also i am not entirely sure if this would "feel" right or gets a little bit annoying.