Icon alpha-blending has taken some big steps forward today. First, Antonio Larrosa introduced alpha blending to the HEAD branch in CVS. Here's a screenshot showing one icon blended into another. A few hours later, Carsten Pfeiffer shot back with this tasty screenshot of Konqueror previewing text files with the mimetype icon blended in. Oh, I can't wait for 2.1 -- time to hit CVS! (screenshots below)
Thought I'd put the screenshots right inline for ya'll:
Dot Categories:
Comments
My word! That's absolutely gorgeous!
Off to hit the CVS, who's coming?
Sheesh, I've been there for months.
I wish that they would make fully alpha blended windows and pixmaps a standard part of X. This would be very nice.
I see no need for this feature - except making KDE's code slower and bigger. Maybe not this one feature alone, but as we say in germany: "Kleinvieh macht auch Mist"
"Kleinvieh macht auch Mist"
Or, as babelfish says:
"Flock makes also muck"
Could be get a better translation? (I'm guessing KISS... Keep It Simple [Silly|Stupid]) And if it can be turned off, it's great. PDAs are already pushing 300 Mhz, and normal office machines are often above 500 Mhz machines. As long as it can be turned off for those with lesser machines (of course, my Mom uses a 386sx with 8 MB - there *is* a limit) I'd rather have a DE that provides useful, pleasant visual cues.
Now if only those .htm files were rendered thumbnails...
--
Evan
"Kleinvieh macht auch Mist"
In my Dictionary it says:
"Manny a mickle makes a muckle"
Sounds much better to me :-)
From My understanding, "Kleinvieh macht auch Mist" means
"Small farm animals poo as well as other things"
El Cucurucho
You're right, there is no real *need* for this in
KDE. It is not essential. In fact, none of the eye-candy is essential. Frankly, the whole *G*
in GUI is non-essential. One can build very
usable UIs text-only. On the other hand, why
not take advantage of the power modern computers
come with? Beauty might not be essential - but
still is beautiful. ;-)
Hi Uwe,
I wouldn't go so far and say GUIs are useless. In fact, they can make work faster and easier than any text based interface (well, not always, that's why we still have the console...). But to me it seems, that KDE is so nice and has everything it needs, that now the programmers add features just for the featuers' sake (some people call it 'eyecandy' - I say: candys are bad for your teeth!). And we all know to where it leads: just have a look at MS Office!
Ah, and talking about modern computers: I confess, I have an old, outdated and slow machine from the ancient times when the hobbbits.. okok, it's 5 years old, just recently reinforced by a 400MHz K6 and a new harddrive, and I simply do not want to spend my money for a new 'Deep Thought' just to make KDE working - I need all I earn to buy diapers for my little son.
That's why the alpha blending is disabled by default. It will only "waste" CPU cicles when you enable it manually . Currently, you have to edit your $KDEHOME/share/config/kdeglobals file and add alphaBlending=true to the [General] section, but there'll be (of course) a way to configure it from KControl.
That is not partly true.
While it will probably take half an extra second to render 100 of those icons. The new Render extension for XFree86 that will probably be in next version will do Alpha blending stuff in hardware (http://xfree86.org/~keithp/render/) Then
all X will have it and Qt/KDE too.
Since it will move the rendering code from software directly to your graphic card. You will not have any penelty for doing this stuff.
(Some newer cards like the ATI Radeon even do alpha cursor (seen in Win2000) in hardware.)
/Sam
Speaking of the Render extension, does anyone know what progress has been made with it? I've been checking the URL mentioned, but it hasn't changed - not surprising if this is just one person doing it. Maybe Shawn needs to start the Xompany...
"The two big pieces remaining in the extension are polygons and image transformations"
Some drivers (I believe Tseng, S3 Virge, Matrox,..) have the render extension done (or partly done).
I believe I read somewhere that there was a 40 factor speed up between hw & sw rendering :)
On Friday December 01, @12:34AM, Johann Lermer wrote:
> I see no need for this feature - except making
> KDE's code slower and bigger.
You are absolutely right!
It is a waste of both time and disk space!
But why stop here?
Think further, Johann! Imagine what you could save by reducing the system even more:
No Icons at all!
Plain Text is fairly enough. It is understandable and fast.
No time-consuming and difficult Mouse handling!
Just hit one of those fabulous [Fnn] keys that can easily be combined with [Shift], [Ctrl], [Alt] and/or combinations of those.
No graphical User Interface!
Your goals can be achieves faster by using the shell, right?
NO COMPUTER!
Why not use your good, rock-solid TYPE WRITER.
It was good enough for your father, why isn't it good enough for you?
Ok, let us stop kidding. :-)
In my opinion this nice feature in not only nice (something that might be worth thinking about, since all of us happen to be human beings - not just 'efficiency machines') but I am convinced it will also be a very usefull feature quite soon.
This is not the first time that a feature is added because people just like to have it and soon afterwards the manifold ways how to benefit by using this feature become clear...
I am sure, Alpha-blending is absolutely worth being happy about!
Kindest Regards,
Karl-Heinz Zimmer - http://home.snafu.de/khz
--
"Why do we have to hide from the police, Daddy?" "Because we use vi, son. They use emacs."
Dave Fischer, 1995/06/19
Yes, you are right. There is no need to make the box of your computer transparent with nice colors and sell them and get real rich either. You could just have a boring one.
I can see this being extreemly useful for coders like me. Because you can see the first few lines of text of each file, you can quickly identify a files purpose, especially in large code bases with 100 or more .cpp files in each dir, some with simmilar names. Although this can be alievated by paying careful attention to file names, GUIs are supposed to make work easier, and the names of the files certainly dont affect the resulting binary.
IMHO, all these extra features should be modular options.
My idea is this: To make sure that KDE doesn't bloat up to much (memory wise) and freak out all our processing power while creating one simple alpha blend, all unnessesary features ("GUI enhancements") are to be in modules that can be dynamicly loaded and unloaded, so that unused features don't take up memory.
All of these extras should of course be as optimized as possible... I suggest carrying on the UI stuff, making it look _REALY_ cool (and by golly, It allready is to cool to be true!), but have all the coolness detachable from the main system so that people on pentiums can still live.
GOOD WORK! Viva KDE ;)
I totally disagree with you. I've been waiting for this for a long time.
John
Will disabled icons be alpha-blended with the background to get a nicer semi-transparent effect? Currently, semi-transparency is implemented by displaying half the pixels, but displaying at half alpha would look much better. Take a look at the disabled icons in the toolbar of Konqueror in the screenshot.
A nice idea, but an interesting addition would be to remove the colour and reduce the contrast as well, making the effect much more obvious.
Adam Foster
KDE2 is already able to remove color from disabled icons ("to gray" and "desaturate" effects), it's in the control center under "Look & Feel / Icons / Effects". Decreasing contrast is a good idea, which can probably be implemented without too much trouble.
I tried using "to gray", which works well for colorful icons, but obviously fails for icons that already contain mostly gray.
The whole text-file thumbnail preview thing has a certain gee-whiz coolness to it, but I gotta say I think it is a step backwards from a UI standpoint.
At first glance, all of the text files look alike - I can't distinguish between .txt, .cpp, .c , .h etc. The text included is completely useless unless I study each one close enough to identify the language (perl, C++, whatever). In the screenshot above, the original icons are still there, but now they are semi-transparent(looks very cool btw) and I can't really see them unless I look hard.
I think I'll stick with my boring icons that give strong immediate cues about what the file types are.
I sort of agree with you that it
* Probably takes too much time to render
* Is "a step backwards from a UI standpoint"
But it is cool anyway. What I would like to see instead is a thumbnail popping up when you have the mouse over the filename. Then you can have the detailed file list and, lets say, a special column icon that represents a preview. If you have the mouse over there you will get this alpha blended preview...
Comments
It works so fast that we thought about generating it on the fly (which might be faster) than using cached versions of the generated image. Is that fast enough?
Your suggestion is almost useless though. The advantage of the preview is that you can recognize the document *without* having to click anywhere (Doing this on mouseover would be extremly annoying given the number of files you cross "accidently" - so it's not a viable option either). Therefore your eyes can scan a bit more than the usual information very fast while scrolling through the directory.
I see no real advantage of your proposal as I could also click on the document, view it, and click back from the embedded view in almost the same amount of time. Also your method would destroy the layout.
Greetings,
Tackat
Your suggestion is especially usefull
if you replace your mouse with a grafix tableau.
Accidentially popping views then become less annoying 'cause of the direct pointing character of those devices:
Simply hover over that icon, and after a (configurable) timeout that transparent preview appears. Removing the pen collapses the preview.
Simply as is.
Jens
As you mentioned correctly you have to wait for the timeouts .. and that is a waste of time.
The current solution is simply better: you see everything at once.If I need to wait for timeouts or if I need to click to look explicitely at the document then all the advantage of the whole thing is lost!
Imagine I would want to search for a document and forgot the filename. With your method you'll happily move over every single icon, wait for the preview to pop up and move further until you moved over every single stupid icon. With the current method you only have to scan with your eyes over through the dirs -- no hands ...
As you mentioned correctly you have to wait for the timeouts .. and that is a waste of time.
The current solution is simply better: you see everything at once.If I need to wait for timeouts or if I need to click to look explicitely at the document then all the advantage of the whole thing is lost!
Imagine I would want to search for a document and forgot the filename. With your method you'll happily move over every single icon, wait for the preview to pop up and move further until you moved over every single stupid icon. With the current method you only have to scan with your eyes through the dirs -- no hands ...
Ah, you got me wrong here; sure, to want a preview in general and therefore to wait for the timeout is silly.
But as an intermediate between no preview at all and total preview, which reduces the amount of files per screen (due to its space requirements) a tooltip-like preview as a hint to the lost user seems very reasonable to me.
However, all pros and cons of tooltips take place here.
Ciao,
Jens
I sympathize with the view that the current implementation obscures the mimetype icon, but prefer that over a pop-up. OTOH when you are in preview mode, the mimetype gets obscured (well, completely replaced) for images as well. Perhaps one slight improvement would be to make the mimetype icon in the text-preview mode stronger (i.e., emphasize it more). That would block some of the text more, but the mimetype icon is smaller than the text preview window. Also, one could switch to the smallest mimetype icon (22x22?) to get less of the blocking.
In Windows 98 file manager there is view with two tabs: in one there are icons and when you point to one of the icons with mouse then in second tab you will see file type, date, size etc. there. We could have same and also this there.
You basically already have this since you can split the screen and have different views of the same directory in two different panes. I'm not sure if that's what you mean since I don't use Win98 and therefore may be misinterpretting you, if so, I apologize.
You are completely wrong there :)
Although I was one of the people who helped implementing the textpreview I was almost shocked to see how well it worked. I recently browsed the home-dir of a friend (with his permission of course ...) and I was extremly amazing how much more information this textpreview-feature offered over the usual view. Basically I knew within two minutes what he did over the last four weeks.
The textpreview is also not important for actually *reading* the text (although you can read the upper part of it which contains very often keywords which make you know what the document is about). It is important for recognizing the layout! If you create a document yourself you will be able to recognize it by looking at the layout -- even if you can't read the text inside.
The semitransparent icons are used to determine the mimetype quickly. So you *can* distinguish .txt, .cpp etc. by looking at the watermark-icon. You are right though that it is currently a bit too transparent to be comfortably visible.
And after all it's possible to switch this feature off.
Greetings,
Tackat
I'm not sure how wrong he is, personally...
I find the watermarks nearly impossible to read quickly, in the screenshot.
Perhaps the level of transparency should be configurable?
Reread the second-last sentence in my reply ...
"You are right though that it is currently a bit too transparent to be comfortably visible."
"Reread the second-last sentence in my reply ..."
Ok, and what was your second-last sentence ? :P
How did I miss that?
I will happily be proved wrong when I get to use it for myself.
Looking forward to the next release.
JC
I c what u meen. And I hope the gods (read: KDE programmers) do so too. There will probably be some config option that will let the Icon stand out from the Preview by Precentage or someething. (KDE usualy don't spare the options :)/kidcat
I don't think there's any doubt we'll allow you to set the amount of blending. For one thing, the amount the blend stands out is partially dependent on the monitor you use (eg. I use an LCD). It is definitely something that can benefit from user configuration.
On the idea of text file previews in general, I have a similar view to Tackat - I thought it would be pretty but useless - I was wrong. I find that it is amazingly useful in practice. The only problem I have is that far too many source files include loads of copyright headers first, which make the previews look the same.I can't speak for the other developers, but I'm moving mine to the end of the files as the preview feature is too good to waste.
Rich.
I don't think there's any doubt we'll allow you to set the amount of blending. For one thing, the amount the blend stands out is partially dependent on the monitor you use (eg. I use an LCD). It is definitely something that can benefit from user configuration.
Agreed. Now you can add an entry into your konquerorrc:
[FMSettings]
TextpreviewIconOpacity=70
Possible values are 0-255 (larger values = more opacity of the icon).
The only problem I have is that far too many source files include loads of copyright headers first, which make the previews look the same.I can't speak for the other developers, but I'm moving mine to the end of the files as the preview feature is too good to waste.
Good idea, will do the same :)
It would be nice for .c/.cpp files if the preview was moved to the main() as standard ;) /kidcat
While the alpha blending for icons is very nice, do you plan to support the alpha channel of PNG images in Konqueror?
With KDE2.0, Konqueror uses only partially the alpha channel. I would like a complete support.
Thanks.
i hope that you could help me gather enough information about alpha blending bmp images. thanx.
Actually i think these are exellent features because it makes the desktop attractive to windows users because when they see a console they panic but when they have an attractive GUI they feel like they're home.
EXCATLY! I say, keep pouring in eyecandy and cunning UI-tricks so the M$ users will droooool until they can't resist trying it out anymore.. and bingo, a new KDE'r is born :)/kidcat
I have no idea if this comment is sarcastic or not. Although, I will say I agree with you if you are not being sarcastic, simply because a good looking desktop is important. Why? Because although tooth candy is bad for teeth, eye candy makes a desktop more attractive, and useful simply because when it's attractive, it becomes more of a work of art. Of course, this should never be more important then functionality (if it is, you end up with things like iMacs, all looks, very little substance). The great thing about alpha blending is that it is useful. You can, with a well designed alpha blended interface, see two things at once. For instance, you can see text in front of an image without having to do screwey things with fonts, and see the description for an image at the same time as seeing the image itself (transparent tooltips would be great too, this is how Office should do its annoying little paperclip, so that it doesnt come in front of your work to interrupt and remind you of how helpful it is [of course, the assistant is a bad idea anyways]).
it was not sarcastic at all :) And yes ur right, AB is a good thing that can be usefull and not just good looking. /kidcat
it was not sarcastic at all :) And yes ur right, AB is a good thing that can be usefull and not just good looking. /kidcat
it was not sarcastic at all :) And yes ur right, AB is a good thing that can be usefull and not just good looking. /kidcat
DOOOOOH! This is a bad example of what NOT to do :)
Cool!
Now i'd like to see the thumbnail of the HTML document instead of his source :o)
[i'm half kidding: could be put as an option for people with _fast_ machines]