Of KControl and Other Needs

Alright, this time less philosophy and more "what I'm doing and thinking about doing, as if you care" ...

I am nearly ready to start working on some major KControl issues, but am stalled on a couple of fronts. Hoping inspiration (and some bits of code i'm waiting on) will arrive soon.

I've got a couple of patches to some smaller KDE apps that were sent to me and then abandoned. I'll have to fix them up some, and just discard others. Not sure what prompts someone to start in on something and then just leave it halfway?

Someone on theDot went on about Nat Friedman's Dashboard app. It would be pretty trivial to implement in KDE, especially using DCOP signals. I don't know if it's worth it though. Personally I probably wouldn't use it since web shortcuts and a well chosen set of apps semicoherently arranged on my virtual desktops makes it trivial to pop around. It may make an interesting addition to Klipper. I'd probably implement it using passive popups or a perhaps an applet. This biggest mistake currently in Nat's UI design is that it takes up so much friggin' space that it had better be damn useful and replace the need to launch most applications.

I also need to fix the applet handle menu to allow merging in an applet-specific menu. And I'm continuing to mess around with Konqi menu stuff.

Not that anyone really cares. At least it's fun for me... =)


I was hacking arround on some old ideas about the dashboard approach. Back in the days of the Lisa they talked about a "Control Strip". This bugger was similar to the OS X Dock, KDE Kicker and windows 9x task bar. The problem they all ran into was the sucker took up too much realestate to be useful... Make it big enough to read (OSX, and you lose realestate) Make it small enough to be out of the way and its annoying and hard to use (Win9x)

Maby its time we think of something different. Lets see about exploring chunks of the screen that are currently empty? Maby we need to rethink how we manage menus? When i look at my KDE screen I see tons of wasted space on menu bars and window decorations... ever run the BeOS theme with maximised windows? maby there are hints there?

By Ian Reinhart Geiser at Sun, 07/20/2003 - 03:21

I am running into much of the same problem with Klavi -- unlike kicker, it needs a pretty hefty amount of space to display all the labels; and that cuts away precious screen estate. I can make it resize and take up as little space as needed -- but then the resizing is annoying (as when a strut resizes, it moves *everything*). I can make it not be on top, but then widgets block it. (perhaps it can autoraise, though?). So what I am thinking of now is some sort of a set of heuristics that tried to balance out text sqeezing with available size, and to moderate the amount of resizing.

And, unlike Dashboard, a release/mature version of klavi would actually be a crucial app, so it has more room to waste screen space (i.e. people who need accessibility aids like that would surely consider them a good use of screen area). But Dashboard would have to fight for room with other apps -- the webbrowsers, the wordprocessors and the e-mail clients most regular users would like to use all of their screen estate for [1]. So it'd be interesting to see whether it'll do enough to justify its spot.

[1] Of course, the "regular users use one app at a time full-screen" thing does make me kind of wonder about the concept -- do no-techie users use theirs computers in a sufficiently dynamic fashion to make something like this useful?

By Maksim Orlovich at Sun, 07/20/2003 - 04:37

To have a window with a bunch of stuff scrolling by, taking up space...

Grrrr. Don't these people actually use their machines?

The idea of having some kind of indexing of what has been done is compelling however. But isn't data and workflow tied to particular tasks? What I would do in a wordprocessor (make up proposals for work, pricing etc) is far different than what I do in Konqueror (google, read kdeveloper, dot, lwn, etc) or ksirc (), or Quanta, Kmail etc. Why have a window open when each application could use the service to present similar, historical, or whateveritthinksyouwant within it's workflow setup? If I google something, I find the history bar handy, since I can continue searches. The visited sites are colored differently. If the index knows where I've been, why not present that information within the context of the browser?

Another application that came to mind is doing proposals, it would 'know' what other proposals I've done for that customer, recognize patterns, ie. heat pump proposal, walkin freezer proposal, and present a boilerplate. A wordprocessor 'knows' what you are doing, and can help.

Something else, when doing up the digest, I get emails from people, and the index could recognize what one's I've used (pattern of text), and hint the ones I haven't.

Again, each application represents a task, or multiple tasks that have patterns, which then could mine the indexed data, and display it in a way that is useful to the task at hand. One thing that comes to mind immediately is Kontact summary page. Nice, but full of useless information. Could Kontact know which email folder I check first?

IOW, more information is not helpful. Targetted information is. Of course, this idea would be quite difficult to implement.


By dkite at Sun, 07/20/2003 - 16:07

See, now that actually sounds a lot more interesting.

Maybe you can help us finally be rid of the 'Set Encoding' context-menu entry?

Speaking of which, maybe we could take a page from the Moz developers. The current list of encodings takes up more than half of my 1024x768 screen, and that's ridiculous for a goddamned menu. SOMETHING NEEDS TO BE DONE. The Moz guys seem to have the right idea; split up the encodings by (rough) geographical location into submenus of West European, East European, Middle Eastern, East Asian, and South Asian or something similar?


By KDE User at Mon, 07/21/2003 - 17:56