Mosfet.Org: New MegaGradient Widget Style

Mosfet took the pre- and circa- KDE2 world by storm not so long ago. His fingerprints are all over many of the styles, themes, window decorations as well as much of the KDE2 we are familiar with today. He churned out thousands of lines of code accompanied by slick screenshot after slick screenshot. Mosfet is now back with a funky new widget-style dubbed MegaGradient (screenshots: 1, 2, 3), currently in KDE CVS. As an aside, those of you wondering where Mosfet has been lately can check out Mosfet.Org for an update.

Dot Categories: 

Comments

by Slartibartfas (not verified)

You don't really like that, do you! Woooaa! Ths is really ugly!

*shrug* Then don't use it. A lot of people like highly gradiented (Metal) styles, and now we have a very fast one.

by Karl Garrison (not verified)

I dunno, I rather fancy it myself. It's attractive without being gawdy or overwhelming. There's way to many of the latter type of themes around these days.

-Karl

Id..t. Response expected more from a pig than a truly thinking man. Mosfet, thanx again for your work for KDE community.

Just something i've been wondering about.. can you create a not-square k-button in the kicker? I mean, is it possible (in any way) in the current builds? (i use 2.2alpha) I know you'll all convict me now of wanting a windows-flag as k-button, but it's not about that at all.. It could be anything, I just wondered..

Wow!!! This IS VERY, VERY, VERY good looking! Thanks!

One more thing... How about transparency on top of it?!

by Roberto Alsina (not verified)

Since the gradient is not dithered, it has visible banding on 16bpp. On 24bpp it's ok, but I don't have 3d acceleration in my i810!

So, gradients or tuxracer? Life is so full of hard choices :-)

You don't want to use this with dithering. Looks like crap ;-)

I think that you're forgetting the third choice : buy a GeForce MX (which I think supports 3dac in 24, but if it doesn't plz correct me).

Hey, tuxracer is worth it! :^)

by Karl Garrison (not verified)

Mosfet mentioned on his update that he has some code for a traditional paint program (like xpaint or mspaint) called KoolPaint.

Personally, i've been looking for something like this under Linux, but can't find anything like it. I always resort to using mspaint under Wine for icons, tiles and the like (I can't stand xpaint's interface).

KIconEdit isn't too bad, but it won't do curves, image flipping, rotation or similar basic features that I need.

Using somthing like Krayon or the GIMP for simile icons and small tiles is extreme overkill, IMO.

Anyway, I hope he finishes it and releases it someday!

-Karl

by Carbon (not verified)

I agree that kiconedit and xpaint aren't good enough, and that krayon and gimp are overkill. However, i think that koolpaint's niche should be more oriented toward the ms paint niche, as a fun to use painting program, with few practical applications.

No, I'm serious! I have seen people attempt to do serious image editing on ms paint, and it's ugly as heck. However, ms paint is fun for kids doing small images, and it helps total computer newbs to learn the mouse in a fun way, and to do quick, personalized background images, etc.

So, graphic editing (imho) should be:
Kivio or Killustrator for diagrams
Krayon for web page images, logos, photo manip, etc
Kiconedit for icons, tiles, and pixel-ta-pixel image editing
KoolPaint for wasting time :-)

The problem with kiconedit is that it is unmaintained.
It still doesn't even have an undo cache! Any volunteers? Certainly, improving kiconedit would also make the jobs of kde artists easier too.

by Antialias (not verified)

Great Mosfet :) Thanks to your work & gallium's kwin clients full themeability of kde is now possible.

One small quibble: GTK+ didn't *have* to use a gradient pixmap scaled to the right window size, that was just the easiest way for lazy people to do it.

The harder/more time consuming but quicker in execution speed is to make a theme engine rather than use raster's slow ass pixmap theme engine.

Is this doing anything that a custom GTK+ theme engine can do?

One small quibble: GTK+ didn't *have* to use a gradient pixmap scaled to the right window size, that was just the easiest way for lazy people to do it.

The harder/more time consuming but quicker in execution speed is to make a theme engine rather than use raster's slow ass pixmap theme engine.

Is this doing anything that a custom GTK+ theme engine can do?

One small quibble: GTK+ didn't *have* to use a gradient pixmap scaled to the right window size, that was just the easiest way for lazy people to do it.

The harder/more time consuming but quicker in execution speed is to make a theme engine rather than use raster's slow ass pixmap theme engine.

Is this doing anything that a custom GTK+ theme engine can do?

by TrollKiller (not verified)

He is right, GTK+ themes can be amazingly fast by writing a theme engine!
So why don't you people just accept it and respond instead of blindly believing that FUD?!?

by Chris Lee (not verified)

> He is right, GTK+ themes can be amazingly fast by writing a theme engine!

Yeah, but KDE "themes" are even quicker when they're written as Styles, so your argument is still lost.

Here are the facts, to get rid of the FUD you trolls are always screaming about:
1) GTK+ pixmap themes are SLOW.
2) Qt can do pixmap themes, even GTK+ ones, faster.
3) GTK+ Engines are faster than GTK+ pixmap themes. (Then again, the only thing I can think of slower than GTK+ pixmap themes are Mozilla themes.)
4) Qt Styles still kick the ass off GTK+ Engines when it comes to speed. Qt renders things with a quickness.

Think I don't know what I'm talking about? I've got code to back up what I'm saying. It's not the best code, nor is it well-optimized, but I do have it.

http://clee.azsites.org/kde

So why don't you people just accept it instead of blindly believing that FUD?!?

by Mosfet (not verified)

Well said ;-)

by me (not verified)

pixmap themes are only slow cos of Raster's pile of shit engine. It redraws the images 3 frigging times. I could draw the themes faster in paintbox faster than the GTK pixmap engine can. Thats not a failing of the engine idea, it's a failing of the pixmap engine. So saying QT can do gtk pixmap themes faster than gtk isn't that big a deal. Everyone has accepted it's slow.

And whats the difference between a style and an engine?

All I asked was, is this doing anything that a correctly written (IE not by Raster, and doesn't draw everything 3 times) engine can't do?

by Evandro (not verified)

i'd be interested to know where i can find the pixmap engine written by you, since the problem with the current one is all Raster's fault and you said you can easily do better.

by Spark (not verified)

He said he can paint them faster in an image manipulation program, than they are drawn by the engine. Not that he can do a better engine.
Read more carefully...

by me (not verified)

and how does your code back up what you're saying? It's a KDE theme, and so has no relation to GTK themes. If you had a KDE theme and a GTK theme that we could run and say "Yes, the KDE theme is faster" then that would back up what you're saying, but giving us a KDE theme doesn't back it up at all.

by Mosfet (not verified)

Because GTK themes work faster under KDE as well. Remember, KDE supports both native KDE themes and GTK widget themes. The *same* GTK theme operates visibly faster under KDE.

by Spark (not verified)

Now you are running in circles...

Chris said, that Qt Styles are faster than Gtk Engines and that he can back this statement up, with his own Qt Style. Me was asking for a comparing Gtk Engine to show, that the Qt Style is indeed faster than the Gtk Engine.
And you tell us it is, because Gtk PIXMAP THEMES are slower than Qt PIXMAP THEMES.
We are talking of engines now...
What can Qt Styles do what Gtk Engines can't do? Where can I find an objective proof that Qt Styles are faster? I use Gtk Engines all the time, they are everything but slow. I don't know if they are faster than Qt Styles, probaly not. But it'a FACT, that I can't feel the difference (I couldn't even with my old P133). And if I can't feel or see the difference by any means, what value is a slightly faster engine? The only difference I can SEE is, that Gtk Engines look much better than any Qt Style I know (they do basically all copy existing widget styles of other operating systems, or are simple gradient ones).
I don't want to bitch, I just hate this FUD spread against Gtk Engines. They are by no means slow or weak. And I would really appreciate some nice Qt Styles, so I can use KDE applications again without getting headaches.
Sorry, but it's the truth, I used KDE for quite a long time and know I can't see it anymore. I try it from time to time, but it's just plain ugly.
There are even several image errors with the default style.. I hope this will change soon, but I was already hoping that several months ago.

by Mosfet (not verified)

What errors? Ever submit a bug report? Either way, this entire thread of GTK users bitching started out because I stated that the way GTK pixmap themes handle gradients is very, very slow on my webpage. That's true. The entire thing is slow and wrongheaded.

Never used a GTK engine. Don't really use GTK apps except the GIMP. I *have* seen the API, and I know Qt styles are easier to develop.

by Spark (not verified)

> Either way, this entire thread of GTK users bitching started out because I stated that the way GTK pixmap themes handle gradients is very, very slow on my webpage.

No, you didn't mention _pixmap_ themes. Quote: "[...] GTK themes at least used to actually use a gradient pixmap [..]"

> Never used a GTK engine. Don't really use GTK apps except the GIMP.

So proably you shouldn't make negative comments about something, you don't know. :(
I don't use _any_ Qt application anymore, but that doesn't mean, that I'm not interested in Qt technologie.

> I *have* seen the API, and I know Qt styles are easier to develop.

Maybe, I don't know. I didn't look at any of those API's yet. All I know is, that there are several great Gtk engines, while Qt is still lacking such. Maybe they will come, but it's about time... Qt 2 isn't really "new" anymore.

by Mosfet (not verified)

Dude, get a life. O Said theme, not engine, and specifically mentioned pixaps. And you tell me not to talk about things I don't know??? Who are you to tell me shit when you never even looked at code while I have?

This is why I get annoyed at people like you...

by Mosfet (not verified)

Eek, bad spelling. My brain is fried from actually doing some *coding* for themes instead of whining ;-)

by kdeFan (not verified)

So *this* is why you're taking a lower profile in kde development, huh? I don't blame you one bit. Even if I did have the motivation and skillz to hack on kde, I would use an alias and a disposable email address. Sad state of affairs. Thanks mosfet, you've done some great work and I enjoy it every day.

by Spark (not verified)

> Dude, get a life. O Said theme, not engine, and specifically mentioned pixaps. And you tell me not to talk about things I don't know??? Who are you to tell me shit when you never even looked at code while I have?

Well, thanks for the nice words... I'm not the one who said, Qt styles would be weak. They are surely great, but so are Gtk themes. And you all should stop this Gtk bitching, I'm getting sick of it.
Gtk is in now way bad, ugly, or slow. If you say something against the pixmap engine, than make this clear please. Just saying "Gtk themes" is the fastest way to spread FUD (as you can see on some comments by clueless KDE fanatics).

> This is why I get annoyed at people like you...

Thanks again... now guess why I got sick of some KDE community.

by Mosfet (not verified)

Actually, I don't see any cluelessness by the KDE users. I for one haven't said anything that's not true, but the truth sometimes makes people's panties bunch up. Now your just sitting here being an arse trying to say I'm spreading FUD because I said something true about GTK themes. Deal with it. Saying what I say is true but I should also say you can make it better by rewriting the whole damn thing is absurd.

The only one I see trolling here is you. I'm still interested to see your "drawing errors", since AFAIK there are none. If you can't even say here specifically what they are I am forced to believe your full of crap and won't respond to you further.

by Mosfet (not verified)

Oh, and still waiting for your bug report. Or were you just complaining?

by Mosfet (not verified)

Should also say that the comment I responded to was talking about themes, not engines, so I wasn't running aorund in circles either. If you can take the same *theme*, and run it in both environments, the results tell you something.

by Spark (not verified)

Sure, "theme" probaly wasn't the right word. But I'm sure he meant theme engines, because Trollkiller was talking about theme engines and Chriss Lee was talking about engines/styles, too.
Maybe just a misunderstanding...
I just wish, KDE folks would accept that Gtk themes doesn't have to be slow and there seams to be nothing, that Qt styles can do, what Gtk engines can't.
And the API can't be SO complicated, because they are several Gtk engines out there, the best of them popped up after the KDE 2 release, so time isn't an argument either.
Qt styles may be nice, but so are Gtk engines! And of course you can also theme Gtk engines with pixmaps, they are just not as flexible as this terrible pixmap engine.

by Mosfet (not verified)

Sure, but it would also be nice that whenever people say "Damn GTK pixmap themes are slow", people don't also say "Well, write your own theme engine in C then"! That's pretty stupid, since it's a problem everyone recognizes.

by Mosfet (not verified)

And I'm still waiting for your bug report ;-)

by Mosfet (not verified)

As a matter of fact, almost all 3rd party GTK engines except one seem to simply use pixmaps. This should be done using themes, not require the artist to write C code, but they have to because the theme engine *sucks*. And your trying to make this seem like a feature?

by me (not verified)

Erm, no.
Those aren't engines.
They're ... themes which use the pixmap engine.

For someone who's supposed to understand all this, you're (NB the spelling) not doing a very good job.

by Mosfet (not verified)

No, I specifically mean the engines. Look at the source code for them. Most of them are just pixmaps packaged as an separate engine with some C glue in order to avoid the pixmap theme engine.

Look at the sources for them yourself... For somene who's supposed to understand all this, you're (NB the spelling) not doing a very good job.

by Mosfet (not verified)

You do understand that your saying GTK pixmap themes can be made blazingly fast by not using the GTK pixmap theme engine at all (because it's *slow*), and writing your own code instead in C? ;-)

by me (not verified)

yes. And this is different to what you're doing.....how? (Execpt your stuff is C++)

The correct solution is for someone to rewrite the pile of shit that raster wrote so that it doesn't redraw things 3 times. Owen Taylor wrote one for GDKPixbuf that was quite a bit faster, but then he moved it to GTK2 so most people haven't had the fun of using it.

by Mosfet (not verified)

All this stuff goes into the KDE theme engine.

by john (not verified)

bleh.

by Mosfet (not verified)

Check this - I worked on it last night ;-)

http://www.mosfet.org/transmenu.html

by kdeFan (not verified)

Wow! Very cool! I like that. Transparency would probably be useful in aqua theme too... Dosen't the real thing (OS X) have semi-transparent menus? Anyway, cool hack!

by horst (not verified)

mosfet:
I know I should look at the code, but how does this work? I thought X didn't support translucencies? and it can't be a simple background image replacement because I see a window behind the menu...

Come on, throw us a bone, this is awesome!
I've always wanted a _trully_ transparent xterm.
could this be done?

Horst

by Richard Moore (not verified)

For popup windows like menus you can simulate it by grabbing the area the window will cover (QPixmap::grabWindow()) then blending the popup info the pixmap. This is still not true transparency, but it looks cool. :-)

Rich.

by Mosfet (not verified)

Exactly. It works well for menus, since you know exactly what's going on on the desktop before it pops up and it isn't there for long (so you don't really need to update it).

For other windows (like terminals), you need to update it whenever something is going on in the area you are covering. This is what makes things difficult. Keith Packard is working on a XRender server for doing translucency between apps, and I'll support that.

by Jelmer Feenstra (not verified)

"and I'll support that"

Ah I got you there, you already have some code sitting there at your desktop don't you ? :)

(is the API for the XRender stuff anywhere near done ?)

by Mosfet (not verified)

XRender is working, the alpha channel server isn't. I did some hacks with KDesktop and a clock that does a translucent clock just to make sure it's possible, and Keith did a twm (!) hack, but we need the server.