View previous topic :: View next topic |
Author |
Message |
DArtagnan l33t
Joined: 30 Apr 2002 Posts: 942 Location: Israel, Jerusalem
|
|
Back to top |
|
|
metalhedd l33t
Joined: 30 May 2002 Posts: 692 Location: Ontario Canada
|
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. |
|
Back to top |
|
|
telex4 l33t
Joined: 21 Sep 2002 Posts: 704 Location: Reading, UK
|
Posted: Sat Nov 30, 2002 11:03 pm Post subject: |
|
|
Just post a reply to the topic offering your help! |
|
Back to top |
|
|
metalhedd l33t
Joined: 30 May 2002 Posts: 692 Location: Ontario Canada
|
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.... |
|
Back to top |
|
|
yokem55 Guru
Joined: 18 Apr 2002 Posts: 360 Location: Oregon
|
Posted: Sun Dec 01, 2002 3:37 am Post subject: |
|
|
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. |
|
Back to top |
|
|
jcmkk Tux's lil' helper
Joined: 19 May 2002 Posts: 124
|
Posted: Sun Dec 01, 2002 3:59 am Post subject: |
|
|
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. |
|
Back to top |
|
|
vod Tux's lil' helper
Joined: 10 Jun 2002 Posts: 90
|
Posted: Sun Dec 01, 2002 6:28 am Post subject: |
|
|
wow |
|
Back to top |
|
|
telex4 l33t
Joined: 21 Sep 2002 Posts: 704 Location: Reading, UK
|
Posted: Sun Dec 01, 2002 12:08 pm Post subject: |
|
|
yokem55 wrote: | 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. |
I'm not sure why it'd need a fork off the whole tree; perhaps a fork off the kicker and kmenu tree. It's not like they're looking to change anything about the architecture of KDE (kdelibs), nor any of the features of konqueror or any other apps, just kicker and kmenu (which I think is part of kicker?).
A fork in the kicer code would suffice. If you look back through the "Other" section on kde-look you'll notice lots and lots of new kicker design ideas popping up. The best way for them to progress would be to fork the kicker code and create a new type of kicker, and try to develop it within the KDE framework, as I've posted on kde-look several times There's no need to totally overhaul or replace KDE, and I'm sure the KDE developers would be fairly amenable to a fork, especially as kicker's principal maintainer is mosfet! |
|
Back to top |
|
|
vod Tux's lil' helper
Joined: 10 Jun 2002 Posts: 90
|
Posted: Mon Dec 02, 2002 1:05 am Post subject: |
|
|
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. |
|
Back to top |
|
|
TomorrowPlusX Apprentice
Joined: 07 May 2002 Posts: 168 Location: Washington DC, USA
|
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. |
|
Back to top |
|
|
metalhedd l33t
Joined: 30 May 2002 Posts: 692 Location: Ontario Canada
|
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? |
|
Back to top |
|
|
TomorrowPlusX Apprentice
Joined: 07 May 2002 Posts: 168 Location: Washington DC, USA
|
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. |
|
Back to top |
|
|
metalhedd l33t
Joined: 30 May 2002 Posts: 692 Location: Ontario Canada
|
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. |
|
Back to top |
|
|
TomorrowPlusX Apprentice
Joined: 07 May 2002 Posts: 168 Location: Washington DC, USA
|
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. |
|
Back to top |
|
|
metalhedd l33t
Joined: 30 May 2002 Posts: 692 Location: Ontario Canada
|
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. |
|
Back to top |
|
|
masseya Bodhisattva
Joined: 17 Apr 2002 Posts: 2602 Location: Baltimore, MD
|
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.. |
|
Back to top |
|
|
TomorrowPlusX Apprentice
Joined: 07 May 2002 Posts: 168 Location: Washington DC, USA
|
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! |
|
Back to top |
|
|
DArtagnan l33t
Joined: 30 Apr 2002 Posts: 942 Location: Israel, Jerusalem
|
Posted: Tue Dec 03, 2002 6:18 am Post subject: |
|
|
Tristam29 wrote: | Just posting to serve notice that there was a little discussion on this topic in new kde look. |
I post this first so this is not duplicate _________________ All for one and one for All
--
MACPRO machine... |
|
Back to top |
|
|
Evangelion Veteran
Joined: 31 May 2002 Posts: 1087 Location: Helsinki, Finland
|
Posted: Tue Dec 03, 2002 7:17 am Post subject: |
|
|
Whoa! That would be SOOOO cool! |
|
Back to top |
|
|
DArtagnan l33t
Joined: 30 Apr 2002 Posts: 942 Location: Israel, Jerusalem
|
Posted: Tue Dec 03, 2002 7:37 am Post subject: |
|
|
Evangelion wrote: | Whoa! That would be SOOOO cool! |
yep _________________ All for one and one for All
--
MACPRO machine... |
|
Back to top |
|
|
masseya Bodhisattva
Joined: 17 Apr 2002 Posts: 2602 Location: Baltimore, MD
|
Posted: Tue Dec 03, 2002 6:53 pm Post subject: |
|
|
DArtagnan wrote: | Tristam29 wrote: | Just posting to serve notice that there was a little discussion on this topic in new kde look. |
I post this first so this is not duplicate |
This topic was started Nov 30th at 4:39 PM while the other thread was posted on Nov 30th at 3:12 AM. That indicates to me that your thread was older by about thirteen and a half hours. Not that any of this matters, or is even close to on topic... _________________ if i never try anything, i never learn anything..
if i never take a risk, i stay where i am.. |
|
Back to top |
|
|
ebrostig Bodhisattva
Joined: 20 Jul 2002 Posts: 3152 Location: Orlando, Fl
|
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 |
|
Back to top |
|
|
telex4 l33t
Joined: 21 Sep 2002 Posts: 704 Location: Reading, UK
|
Posted: Tue Dec 03, 2002 10:16 pm Post subject: |
|
|
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). |
|
Back to top |
|
|
Evangelion Veteran
Joined: 31 May 2002 Posts: 1087 Location: Helsinki, Finland
|
Posted: Wed Dec 04, 2002 11:27 am Post subject: |
|
|
ebrostig wrote: | 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. |
Taskbars and the like can be convenient. I find 'em really easy to group my application for quick access. And it's easy to have a place where I can easily switch between different apps. It makes me more productive, so it can't be all that bad. But, to each on it's own. I'm not claiming that my way of working is the right way of working.
Quote: | 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 |
It should be hidable and optional I think. |
|
Back to top |
|
|
TomorrowPlusX Apprentice
Joined: 07 May 2002 Posts: 168 Location: Washington DC, USA
|
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. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|