kde look?

DArtagnan · Posted: Sat Nov 30, 2002 9:39 pm Post subject: kde look?

Holly shit ;-)

Who saw it?

http://kdelook.org/content/show.php?content=4080
_________________
All for one and one for All
--

MACPRO machine...

metalhedd · Posted: Sat Nov 30, 2002 10:17 pm Post subject:

That looks AWESOME. I'd love to see that project finished. I wish I could help.

telex4 · l33t Joined: 21 Sep 2002 Posts: 704 Location: Reading, UK

Just post a reply to the topic offering your help!

metalhedd · Posted: Sat Nov 30, 2002 11:11 pm Post subject:

Already signed up with sourceforge, I'm not very good but I'll do my best.
everyone who uses KDE and has some kind of Coding skills should get involved in it, the concept is terrific and would definitely give KDE the title of BEST GUI EVERRRrrrr....

yokem55 · Guru Joined: 18 Apr 2002 Posts: 360 Location: Oregon

I agree this looks like a *really* slick way to organize a desktop. I'm really curious though to see how looks translate into usage though. If its as slick to use as it looks, than this could be the biggest innovation in desktop GUI's in years. Unfortunately I wouldn't be suprised if getting this impimented would require a fork off of the main KDE tree though; the main KDE devs from what I understand are rather stubborn about this type of thing and are reluctant to throw out years worth of code in order to move to a new paradigm of desktop design.

jcmkk · Tux's lil' helper Joined: 19 May 2002 Posts: 124

It looks like a really good idea, but so far it seems that they need someone to really get the project managed. I hope someone steps in that has lots of experience in opensource projects because so far it looks like a bunch of newbies talking a lot, but not getting anything done. Of course, I don't know the life span of the idea so far, so I may be jumping the gun about leadership.

vod · Tux's lil' helper Joined: 10 Jun 2002 Posts: 90

wow

telex4 · l33t Joined: 21 Sep 2002 Posts: 704 Location: Reading, UK

vod · Tux's lil' helper Joined: 10 Jun 2002 Posts: 90

Also, it may not require a fork per se. It may be that if alternative kicker designs are good enough they could be included in kde. Then it could be left up to the user to choose between them. After all there's already kasbar, child panels, extensions etc.

TomorrowPlusX · Posted: Mon Dec 02, 2002 9:08 pm Post subject: Not the only one

Interestingly, I was planning on sketching out some code this evening. I like the design too, and as a full time kde user, and having been writing qt/kde apps (for my own use, primarily robotic control stuff) for a couple years now I'm pretty comfortable with the APIs.

So, this evening I'm planning on making a few tests.

First -- see in what way (if at all) kde relies on kicker. Kicker may, possibly, provide some critical dcop services. If it does, then I'll have to look into replicating them. but my understanding is that that's not the case.

second -- and what I plan to do tonight -- is to write a flexible, extensible screen-edge panelling api. E.g., little widgets which stick to the screen edges and can be dragged about.

I'm not going to venture any guesses for what comes after that. I won't know until I've examined in greater detail the functionality. But there's one thing I can promise -- if the edges of the cards are all curved and arcy, they won't be antialiased. Second -- I'm going to avoid transparency. Better not do it, than use a dirty hack.

metalhedd · Posted: Mon Dec 02, 2002 9:56 pm Post subject:

Just out of curiosity, as I'm trying to learn qt to get involved in this project also.. what is the reasoning behind not being able to anti-alias the edges?

TomorrowPlusX · Posted: Mon Dec 02, 2002 10:03 pm Post subject: No antialiasing

The reason is that properly antialiased adges would require a proper alpha channel in X. I'm sure you've heard enough ranting and raving about this issue ;)

But, if you look at my MKUltra kwin decoration (http://kde-look.org/content/show.php?content=2865) you'll see that non-antialiased edges look A-O-K.

metalhedd · Posted: Mon Dec 02, 2002 10:20 pm Post subject:

hmm... but all of the kde icons use anti-aliasing don't they? and the fonts.. so i guess i just don't understand why a widget of your own design couldn't be anti-aliased.

TomorrowPlusX · Posted: Tue Dec 03, 2002 1:30 am Post subject: Widget != icon

Icons are drawn by the desktop, for example, over the desktop. The desktop has the ability to compose the alpha channel of the icon over a known background. WIdgets, however, and in this case, little mini windows, don't have a guaranteed background. They might be over an app, might be under another. Things behind them can change without their being aware. Without a proper alpha channel and support through XFree, I just can't fake the proper compositing.

metalhedd · Posted: Tue Dec 03, 2002 3:05 am Post subject:

does that mean that the keramik theme in kde3 isn't anti-aliased? it looks ok, so I guess the mini windows will too.

masseya · Posted: Tue Dec 03, 2002 4:40 am Post subject:

Just posting to serve notice that there was a little discussion on this topic in new kde look.
_________________
if i never try anything, i never learn anything..
if i never take a risk, i stay where i am..

TomorrowPlusX · Posted: Tue Dec 03, 2002 5:28 am Post subject: keramic is antialiased

Yes, keramic is antialiased -- but only the widgets inside of an app. Notice the round window borders for keramic aren't

Let me try to explain again

Antialiasing of window edges will only work correctly if the foreground window (the antialiased one) can be made aware of redraw events in the window(s) below it. For each antialised pixel, each and every pixel drawn by any given app beneath it must be drawn, and then the app's antialised edge pixels must be composited over it. It's not numerically complex, but it requires a graphic model which XFree simply doesn't support -- X is only concerned with hard regions -- no subpixel edge states. If your app, and it's curved edges, are over another app, the app beneath simply won't receive redraw events, and your app will never know the color of the pixels beneath -- because they never will be calculated. Ever. Period. End of story.

The reason why keramic & liquid can antialias widgets is because they know the background color/pixmap the widget it over. The background color or pixmap is determinable without any special hacks, and no extra expectations are required of X. Notice that the antialiasing of widgets is inside the app. It's all one process. But as soon as we're dealing with windowing, we're limited to XFree's hard pixel-for-pixel occlusion determination.

And if you're curious about my credentials with regards to antialiasing, check out my work writing a vector graphics API for BeOS some years ago
http://home.earthlink.net/~zakariya/vector_api.html

Note -- it's not a *good* api ;) But I learned a hell of a lot with regards to compositing and the kind of information required to do so.

As far as I know, only MacOSX and Win2k/XP support proper alpha channels in the windowing system. XFree doesn't. Check back in two or three years!

DArtagnan · Posted: Tue Dec 03, 2002 6:18 am Post subject:

Evangelion · Posted: Tue Dec 03, 2002 7:17 am Post subject:

Whoa! That would be SOOOO cool!

DArtagnan · Posted: Tue Dec 03, 2002 7:37 am Post subject:

masseya · Posted: Tue Dec 03, 2002 6:53 pm Post subject:

ebrostig · Posted: Tue Dec 03, 2002 6:56 pm Post subject:

One thing I really don't understand, why do you want to clutter the screen real-estate with all kinds of toolbars, card-stacke etc?

I prefer to have nothing but my applications visible on the desktop when I work. I like to use the whole real-estate. I do run in 1600x1200 on a 21" monitor, so I should have enough real-estate, but I like to focus on my work, not on all the little unnecessary things, i.e I don't run gkrellm because I don't need real-time information about the CPu temp or the snow-depth in Anchorage while I try to solve a customers problem, i.e it is un-related and I don't need to see it, hide it.

From the description and the screen-shots, it looks like the amount of real-estate is beeing reduced. Now if all these elements are going to be hide-able, then ok

I like KDE the way it is now, the task-bar with all the dockapps are hiddien until I ask KDE to show it when I need it. Like right now, the only thing I see on my screen is Phoenix, everything else is hidden until I need it. Well, I guess we all have different ways of working, but it reminds me of a petpeeve that Jerry Pournelle was constantly harping on back in the 80's in his Chaos Manor column in Byte. He liked word-processors that gave hime a lot of screen (i.e all of it) and did not hinder him from beeing creative, i.e writing. This is ofcourse a problem today, unless you use VI, since all editors claim some space on the screen for all kinds of tasks.
If I remember correctly, Jerry preferred DeScribe back in those days

Erik

telex4 · l33t Joined: 21 Sep 2002 Posts: 704 Location: Reading, UK

In theory you should be able to retain all of your screen with the new ideas. If they implement them properly, then they'll all be just as "modular" (optional) and configurable as the present kde kicker is.

Personally I like the way kicker is now as well, though some of the adjustments to Kmenu (basically making it moe configurable) would be cool. With these new ideas, I should be able to just set it up to be pretty much like the current kicker, without the cards systems etc. (afterall they have kasbars and a few other extensions already which I never use).

Evangelion · Posted: Wed Dec 04, 2002 11:27 am Post subject:

TomorrowPlusX · Posted: Tue Dec 10, 2002 3:48 pm Post subject: Progress

All
I'll post some screenshots tonight, or tomorrow (I have some freelance work at the moment which will take time, and also a girlfriend who's better company than my thinkpad ;) but I want to let anybody who's interested know that I've made some progress.

What I've got as of this writing is a base card system which allows top-level cards to be slid around the screen edges, snapped (spaced) side by side to one-another and stacked (or "decked") onto eachother to make little groupings. It's pretty ugly right now -- as I'm concerned with functionality not looks -- but the going is good and the code is solid. By the way, the sliding/decking functionality took a lot more code than I had suspected! There's a lot of branching dragging logic for wether you're dragging a free card, the root of a deck, pulling a card from a deck, rearranging a card in a deck, snapping from one screen edge to another, and so on.

Tonight or tomorrow I'll implement clicking-expansion such that when a card title is clicked, it will slide open, and slide shut when clicked again (it will be smoothly animated). That will be easy as everything I've written over the last several days has taken that functionality into account, even though at the moment it isn't implemented.

Now, on a side note -- I'm not 100% certain right now that this needs to replace kicker. Rather, I think this will make a very good companion; and if/when such functionality as a taskbar, system tray, and MacOS style Fitts-Law menu can be duplicated kicker can go by the wayside. BTW -- I'm not 100% certain that the system tray can be duplicated. It's possible that it's tied fundamentally to the kicker process, since it seems to be not a dcop entity so much as a special case for certain KWin flags.

Now, for a roadmap:
Once I have click open/shut implemented, I'll start to work on basic beautification. That's easy, and I ought to have that much ready soon.

Then -- I'll focus on a basic plugin framework and write a couple stub plugins for testing.

Then come the real plugins. I intend to write a few, based on existing kicker functionality; One: A KMenu replacement; Two: Some sort of PIM card which will talk to KMail and KAddressBook & the calendar. Three: A file management card, like the old days of MacOS9 when you could keep folder tabs on the side of the screen. Four: A card which can hold .desktop app links for quick launching.

Anyway -- I just wanted to let people who are interested know that this is happening -- it's just not a one-weekend project.

I'll post screenshots and possibly a link to a tarball soon so you can give me feedback on feel -- NOT look, as like I said before, it's ugly right now.