Slashdot Mirror
GTK-Themes To Be Supported By KDE2
Tackat wrote to us regarding the
recent announcement from the KDE folks concering KDE2. While KDE has had widget themes and such, the people behind KDE have announced support for GTK Themes. For some screenshots, check out the announcement body.
but the KDE page says GTK pixmap themes. Most GTK themes use another themes engine. pixmap themes aren't always the greatest speed wise (or appearancewise -- look at the "pixmap" theme!)
It's eyecandy, catchy, but no real substance. So now KDE can use pixmap themes, so they get the metallic and wood trim? What about real innovation, or even having current UI's work well? I've been programming since I was in 4th grade (Basic on Timex Sinclair 1000) and I have some difficulties using current UI toolkits. I feel this is wasted energy. Flamebait,Troll, -20
Hopefully this is just the begining of the much desired interoperability between both desktops.
J
I'll post it to kde-devel and see if anyone cares to correct this.
I think Qt themes are coded, not pixmapped, which means that GTK+ can't just run them, just as Qt can't just run GTK+ coded themes.
Theme writers sufficiently ambitious to take on two toolkits might want to create packages consisting of both GTK+ and Qt themes that provide the same appearance etc..
The status is "it's going to be called GTK+ 2.0"; GTK+ and GLib 1.3.1 unstable developer's preview releases have been announced.
Not having a C binding isn't as big a problem as it may seem. Most C coders can fairly easily learn C++, because Qt doesn't use any of the eostoric features of C++. Basically, they use C++ for virtual functions (not really any understanding needed on the developer's part) and C with classes.
A deep unwavering belief is a sure sign you're missing something...
Interoperability will come when both KDE and GNOME use the SAME API. No GTK or QT mess. Maybe a blend of the two, maybe something different. Diversity is good but when it threatens to split the community in half (like GTK or QT only apps), the choice is not necessary, simply redundant and dangerous. One set of libs, multiple UIs. THAT is Interoperability. THAT still gives you choice.
THEMES do not convey a sense of interoperability, simply that one can now read the other's config files. Big deal.
There really is no excuse for slashdot not coming up with a solution to this after this long, and this many slashdotted sites.
As slashdot is a site which receives over a million hits a day, and has made millions (billions?) of dollars off of linking other websites, it owes it to those sites and the visitors who have made it what it is, to implement a system which will not be detrimental to most of the sites which it links, and also will allow those of us who come here for information an opportunity to view it.
This is on topic, since the planned topic is unavailble due to this problem. Please add your name.
________
I have to nitpick on your point. A major problem that Linux is going to have is to have the coders get over themselves and write applications for USERS. One toolkit results in less bloat and a more consistant library of applications. All that makes for a better user experience because user's don't care about the toolkit powering something. In these cases, the quality of the product for the consumer is probably more important than the developer freedom of choice. I'm sure most people don't want to use MFC, but face it, MS making everyone use MFC really DOES result in a better library of apps and a better UI.
A deep unwavering belief is a sure sign you're missing something...
Well, as all it really does it take the pixmaps from the old theme and apply it to KDE, as opposed to newer type themes which involve widgets and stuff. You can view anything that is themed by just pictures (and sounds??) as legacy.
I'm not sure I'd agree about a MS forcing everyone to use MFC producing a 'better' library,
;) That's GIMP, KDevelop, Netscape, and Corel WordPerfect. On Windows the equivilent apps have a lot of integration. On Linux there totally seperate entities.
but it certainly helps produce more of them (both better and worse). After all, by that logic
we should all just use WinXX since that has one standard API and all these apps already.
Personally I'm looking forward to the day when I can use my Win95 CD as a coaster next to
my AOL CD (unfortunately I still need Windows for work).
>>>>>>
I said better library of APPLICATIONS. MFC is pretty crappy, and I refuse to touch it with a 10 foot pole. However, both GTK and Qt are very good, and there is little need for both. Either way, what I said is that MFC has lead to a great library of applications on Windows. Because of their use of a common library, they all have extremely powerful drag and drop capabilities, are very interoperable, and Windows apps in general tend to have a pretty consistant UI. The common library really allows Windows to be a much more cohesive entity. For example, in most programs, right click support is implemented quite extensivly. The big reason is that MFC provides functionality to ease implementing right click support. Also, MFC exposes a very powerful clipboard API. This allows applications to interoperate very well. By MS decreeing that everybody use MFC, (which is basically a wrapper for Win32 and thus offers the same features) focus shifted away from the toolkit to creating applications that take FULL advantage of the toolkit.
Incidentally, isn't there the OWL framework that Borland was pushing as an alternative to
MFC? Wether people used it or not, it was still there and it was still an alternative, and
one that some people used.
>>>>>>>
Yea, but it was killed by Microsoft's influence on everybody using MFC. It was an alternative, but not in the same sense Qt and GTK are. There's no central power forcing people to use GTK or Qt.
There is more then enough room for both KDE and Gnome... provided we develop some
standards so that applications written for either can be run by either, and run mostly (not
neccessarily 'entirely' although that would be nice) the same.
>>>>>>>
That's my point. It is POSSIBLE (though it takes planning and thinking, and it seems to me that OSS developers would much rather just code than plan) to have completely seperate DEs that are binary compatible. There's nothing wrong with that. That doesn't cause any fragmentation, leads to competition and better choices, etc. In fact, it leads to even MORE choice. Instead of the application designer choosing what DE the user runs, the USER can decide that. It also reduces bloat and allows developers to take better advantage of the FULL API of the DE.
I think they do that already, and the penalty of loading an extra set of libraries is not that
much nowadays. Diversity is a good thing, and one that is most likely not going to
disapear soon, since even if one side grabs the developers (and in my opinion, people
usually go where the most apps they can use is... all else being equal), the other is doing it
because they want to.
>>>>>>>
The overhead IS significant. On my 128MB system, the overhead of going from KDE 1.1.2 to KDE +GNOME means a 20MB jump in memory. That's 20MB less I can use for GIMP to load a large graphic. It causes my Linux environment to be MORE bloated than NT. Not only that, but it causes two other things.
A) The consitancy of the desktop is shot,
B) Major application designers tend to use NEITHER interface because they don't want to block out either user. In the end, they go back to using straight X + Motif. Compared to Windows, the average Linux system might as well not have a DE at all, since that's what incompatible DEs lead to. I mean the integration at the KDE-only level is great, easily competitive to Windows. However, Linux as a whole doesn't compare well to Windows simply because none of the good applications use the integrated metaphor. Look at the killer apps on Linux. For a lot of users (namely me
My point is that there's a better way to do it. It's probably too late with all the steam KDE and GNOME have gathered, but there's still a better way.
PS> In the current model, users don't choose the DE they use, application developers do. It shouldn't be that way. Just as there are standards that allow you to choose to use a NVIDIA graphics card instead of an ATI, there should be standards taht allow you to use GNOME instead of KDE without the consequences of a reduced experience. However, that goes too much into dictating policy, which UNIX developers are loathe to do. I was reading Miguil's comments, and it hit me. SOMEBODY has to implement policy, or the system has no policy!
A deep unwavering belief is a sure sign you're missing something...
Hmm.. Well, what does QT use for rendering the pixmaps? Remember, GTK+ (still) uses Imlib.. and most developers will tell you, without pause, that Imlib sucks.
I don't mean it in a flamebait way, but Imlib does pretty much suck. Rasterman made it to display graphics for early versions of Enligthenment. It was definitely not made for what GTK and Gnome currently use it for. Hence, gdk-pixbuf.
There's a pixbuf based pixmap engine in the Gnome CVS, but last time I looked, it wasn't being that actively worked on. Maybe someone should bring it up to speed with the latest gdk-pixbuf and then we can talk speed *grin*
Well since I havn't been tracking what is and isn't written in Gtk--, it was really my only available option.
Plus I could use the ego boost of having a bizzilion folks down load it and telling me how much it sucks :-)
A pity that. But you should know my replies to yours posts are rated two for the same reason yours are at zero. They are at the same point value they started at.
When I moderate I do. But when I moderate I have the same failing many others do. I look at the stories I havn't read, and I only decide to take the effort to look at all the replies if there arn't, say, 500 of them allready.
I beleve others have that failing because some of my posts that are every bit as good as the others of mine that made it up to four or five stay at two (or one).
The ones that make it to 3, or 4, or 5 are almost all posted to the "above the fold" stories (one of the top 2 or three), and are frequently there in the first two hours.
The only effectave ways to do that are to post early, or to post as a registered user. I will note that as a registered user you would be able to quickly find if someone has made a reply to a past post of yours. Not as good as netnews, but better then nothing.
So you want everyone to have the name "Random Slashdot User", but distinct posting histories and karma ratings? Is this in addition to the registered user/annon user that exists now? Why?
It doesn't really avoid abuses the annon user can do, as anyone can get a new email address (yahoo gives them away free...and hotmail...and...) and a new "Random Slashdot User" if they want to play that game.
It does make it hard to recognise a user, one would be unable to skim for posts from "Oog The Open Source Caveman". I view that as a disadvantage. Do you think it is an advantage?
Lastly, if you do like the idea, maye you should find a random smattering of others that do and take on the "not really identical, but identical as far as people are concerned" names of "PsudoAnnUser0O0Ol1lll100OOO00l11l" (i.e. a lead prefix, and randomly selected zeros, ones, uppercser ohs and lower case els). Think of it as a proof of concept. If it works out besege Taco to do a less kludgy implmentation, or grit your teeth and decend into the morass of perl that is slashcode and send a patch.
I try. Thanks for the flattery.
As for perfomance, I can't say much because I'm not a developer for any of them, but the KDE team has been talking much about this "really cool pixmap cache" that is supposed to be really fast...
;-P
You mean what imlib has been doing for quite literally *YEARS*..
'Gee, is *THAT* what imlib_config is for. Wow, who woulda knew.. Pixmap caching..'
-- I'm the root of all that's evil, but you can call me cookie..
Binary standard in the sense of Windows OpenGL libraries. You can drop in any ICD (which is basically an implementation of OpenGL) and it will work no matter how the ICD is programmed. There isn't a big difference between GNOME and KDE in terms of what they do. If they used the same API and applications were binary compatible (ie. You could run KDE apps on GNOME without installing compatibility libraries) and integrated into each environment (an application would look "at home" in either GNOME or KDE because they would rely on services from the underlying toolkit) then the user could choose what environment to run without having to consider if they apps they want to run support it. In the current situation, the environment to run is largely supported by what apps one uses. It should be entirely about which environment the user likes better. The same thing exists in Windows to some degree. You can replace explorer with Litestep and get a different window mangager. However, all applications remain compatible. This is simply an extension of that concept.
A deep unwavering belief is a sure sign you're missing something...
Well, fun for whom? It seems to me, that if Linux is going to make it mainstream (as so many people want it to) then the developers have to make some concessions. Personally, I would rather design an application that makes the user happy than have some extra freedom about what toolkit to choose. Maybe it's just me, but a better end product is a lot cooler than the philosophy behind the product.
A deep unwavering belief is a sure sign you're missing something...
How many more screens have to be shot ?
Save the screens !
Or, you could thing of legacy as any theme that existed before KDE2? KDE2's theme engine is the latest one availabe. Thus, anything BEFORE it can be considered legacy. When something support a legacy something else, it usually means that that somethign supports a body of somethings that aren't native, but already in existance. Thus, KDE2 supporting legacy themes means it doesn't support these natively, but since a large body of these themes exist, they're making special provisions to support these older themes. Plus, the air between GNOME and KDE is generally full of cooperation and friendship, so why would they do something like that? It seems to me that they weren't really expecting some people to read so much into this and got lazy in their wording. (Legacy Theme Importer as opposed to the Legacy and GTK+ theme importer!)
A deep unwavering belief is a sure sign you're missing something...
I parsed that as I Am Naked.
Bleh!
from the faq
http://www.talknerdy.org
The sig++ docs have lots of theory. The sig/slot mechanism appears trivialy easy to use. Examples from my code:
With the exception of the connect call it is hard to think of how this could be cleaner. With the connect call it is hard to think of how it could be cleaner within the language, and still be as flexable, and it is still even fairly clean.
Maybe I'm too willing to put up with crap, or too off-put by preprocessors, but I like sigc++'s "inside the language" approch. Can you redo my examples in moc and show them as simpler?
I have to admit I didn't give wxWindows a close look. It's screen shots looked ugly to me two yearsish ago when I last looked. Which is when I last started a GUI project.
I donno, what's major? I did w3juke in it, but that is not a monster big chunk of code. The GNOME libs use C for the same stated reasons GTK+ does. I don't know if they are good reasons or not. Things that want to use GNOME can use the gtk-- style wrapers, but I havn't used them so I can only guess at how good or bad they would be.
I understand that Enzo is not satisfied with the Ferrari F355, and has a team working on a faster streat legal car. That doesn't make me want to drive the F355 any less.
I imagine Troll Tech is working on Qt3.0, but that won't make me poo-poo Qt 2.0!
I'll give you the bloat, it makes the compiled code much larger. And I'll argue the bloat, it makes the source code much smaller and simpler to read. Sometimes signifigantly faster too. It does make using gdb a bit harder. I do understand that the egcs (now gcc again) folks are working on making templates less painful with linker hacks.
How is the STL a recipie for disaster? I have a few fielded systems that use them. What should I look for to blow up? I have some in the works using them, how do you think I could reduce the danger?
How old is that?
I think we have diffrent views on that. I avoided the bulk of GNOME because I don't care to learn it yet, and it seems to have little to offer me. There are some things in it that I think would be well worth the cost of learning it, and requiring it's use if my application needed it. Like maybe the printing system, and the structured drawing widget, or if I wanted to embed other program's output into mine.
"However, while GTK themes are displayed faster and more efficiently than even native GTK itself... KDE2's native widget theming which yields superior results both in terms of quality and speed."
That's quite a blow to GTK and really sounds like a biased opinion to me. Or is there truth behind this blatent "slap in face" type statement? If it's faster and better I'll run it, but I need some conrete proof inorder to make an educated decision on the matter.
That said, horray for QT and the KDE developers - instead of a combination ugly interface (half GTK half QT) we can actually see a beautiful, eye-candy integrated desktop.
Horray! Now where is my QT theme support for GTK? And what is the status of GTK 1.4? (Random off-topic addition...)
Themes support has nothing to do with whether one toolkit is "inferior" compared to another. Presumably many people consider QT's API to be "inferior" to GTK's. Having worked with GTK, I find that very hard tobelieve, but I suppose it is possible (mind you I think you'd have to be intentionally obtuse to create an API worse than GTK's). Plus, QT does not have a C binding AFAIK, which is very annoying.
Too many choices? Ludicrous concept.
Once again, we see different software organizations working toward the same goals; lots of choices with few drawbacks to any one option. Even software groups in competition are now working toward interoperability.
Coincidence is the Superstition of Science
What's that smell? Ah, that's my karma burning...
Besides the obvious license issues, I've heard it said that QT is inferior. I know I like GTK apps better.
I can see where some people might prefer coding in GTK to Qt -- although I personally love signals and slots. As far as using apps, which is what you seem to be talking about, I assume you're referring to appearance. (I can't imagine you really care whether your FTP client was written in C or C++.) And now you can use GTK themes in KDE -- I read it on Slashdot!
As far as the license is concerned, RMS has stated what should have been obvious all along, that there's no problem writing GPL code that links to non-GPL libraries. That's the thing about FUD, though. Once a accusation gets out there, it can never be undone.
What I'm listening to now on Pandora...
Lots and lots of people have been saying "cool, GTK themes!" and such. Note that, as some have already pointed out, KDE will support GTK *Pixmap* Themes.
This means that those nifty GTK Engines won't work, because they rely on how the GTK library implements themeing, and it is most surely different from the way KDE and Qt implement themeing.
Another misleading link from the article is the kde.themes.org link. kde.t.o only carries KDE 1.x themes, and KDE 1.x has *no* mechanism for widget themeing, aside from window decorations using pixmaps.
This thing that KDE is doing can probably also be done for GTK: build and engine to understand the KDE 2 pixmap themes (I read somewhere that there is an engine for pixmaps themes on KDE 2 ... maybe a look at http://www.mosfet.org/themeapi/ would help.)
As for perfomance, I can't say much because I'm not a developer for any of them, but the KDE team has been talking much about this "really cool pixmap cache" that is supposed to be really fast...
--
Marcelo Vanzin
Marcelo Vanzin
Diversity and competition drives innovation, but so does STANDARDS! I could care less if there were two different systems as long as the two were binary compatible! However, in its current state, I've got to put up with GTK+ applications in my KDE desktop (or vice versa) and have to live with 3 *VERY* large libraries in memory at the *SAME* time. Diversity and competition is useless unless there's a way for a person to pick one without having to run them ALL. And exactly what is having to DE's accomplished so far? They're both pretty much the same in features and usability. (though KDE has an edge in speed and stability.) Is there any SANE reason to have to different object models? You can't apply the same concept to everything. Diversity and competition may drive innovation in some places, but in a lot of places, it simply leads to a crappier product. Take the army for example. If you had each person competing with each other, you'd have a crappy army. By having 2 desktop environments, you've got two DEs that are very similar, and a very pissed off user complaining that he needs more RAM to run the damn thing. Microsoft is enough competition for Linux in the short term. Look at what KDE's development has consisted of so far? Take Microsoft features, copy it, improve it, and add it to KDE. So has GNOME's. If you ask me, there's not a lot of innovation going on.
A deep unwavering belief is a sure sign you're missing something...
Am I the only one who thinks the transparency is a cheap trick? KDE/Konsole have never had real transparency AFAIK. Is this going to change with KDE2, or did someone just load a tinted background picture into Konsole (as opposed to Konsole getting the picture from the desktop and auto-tinting and auto-positioning it)?
BTW, I use KDE and do get real transparency from Eterm; that's why I don't use Konsole.
Last I checked Qt was actually a slightly extended C++, there was a pre-processor that would turn event/slot things into real C++ code.
On the other hand I remain utterly unconvinced that Qt is better then a good C++ wrapper of a C toolkit. And I am totally convinced that Gtk-- is not just a good wrapper, but a great one.
Sigc++ (the slot/event scheme Gtk-- uses) also handles events faster then Qt's event system according to a biased benchmark. I don't know how fast or slow the rest of the system is as opposed to Qt. It seems quite fast enough on a slow (PPro 150) machine, so I'm content to leave well enough alone.
Perfectly reasonable. I like C++ with the STL more then I ever liked C, and Java was a pretty nice language for the few things I have done with it.
This doesn't follow. I really urge you to check out Gtk--, if for nothing other then to see how much nicer the slot/event model is implmented.
There may be other reasons to use Qt. There may be other reasons why KDE might be better then GNOME. But this just isn't a valid reason.
Indeed it is.
...in one direction, which is not necessarily completely a Good Thing.
If there's only one {UNIX-flavored OS, compiler, desktop, Web browser, etc.}, you run the risk of having things done only the way the group in charge of that particular project decides things should be done (or you get a fork, but then there isn't only one any more).
A) This is clearly a troll, why did it get modded up?
B) Why the hell does it say Score:0 when I'm in the post editor, but Score:2 in the actual thread?
C) Qt is faster and easier to program.
D) A QT2GTK wrapper would be very slow.
A deep unwavering belief is a sure sign you're missing something...
Assuming they could do that without any copyright issues, why would they want to do that?
Bandwidth costs money. /. is mostly text. Text has a great Bandwidth/Advertising ratio. A bunch of fat screen shots don't. Case closed.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Compatibility with GTK is a step forward. The wording of the announcement is a step back (was it really necessary to dis GTK?)
What both teams (KDE and GNOME) should be doing is working on a common format that both toolkits can use that will make them look the same to the end user. There is no good reason why the end user has to be concerned about whether s/he's using GNOME or KDE.
In much the same way as a Windows user doesn't know whether the app s/he's using was written in Visual Basic or VC++, Linux users shouldn't need to know whether they're using GNOME or KDE.
Hopefully, some day, GNOME and KDE will move past their petty bickering and work together in a productive manner.
Cheers,
Mark B. Allan
"Good people drink good beer"
Sun hasn't been able to find its own ass with regards to X window manager integration since around Java 1.1.6. Some not-too-bright Sun programmer hacked their window manager interaction logic to make Java windows pop up pretty under MWM/CDE, and broke Java's window display/placement for every other window manager around.
And, Sun being Sun and Java not being quite Open, they have left this unrepaired for over two years now, despite the blackdown folks fixing it on about day one, as I recall.
So, don't try to pin this one on Gnome, this one is all Sun's baby.
I program in Java and love it lots, but Sun's priorities are not always in complete alignment with mine.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Well, it's not quite that simple. QT and GTK both use different mechanisms for communication between windows. Not the least of which is the fact that GTK is a C library, while QT is C++. Yes, I know that there is a C++ wrapper for GTK, but the interfaces are really different.
While your somewhat anecdotal assertion that QT is inferior may be true in some regards, many programmers prefer it's models, while others (like me) prefer GTK. To move everything to one toolkit denies freedom of choice, even if it might make things easier. Just use a GTK theme in KDE so you can have the look, and you don't have to force people to use the same toolkit.
----------------- "I have a bone to pick, and a few to break." - Refused -------------------
Qt is native C++. For those of us who want a good C++ toolkit, this is much better than some terrible C++ wrapper of a C toolkit (and faster as well). Personally I don't like C programming and much prefer C++/Java. Thus I use Qt. If you want to use C, use GTK+.
Down on the farm, we call that having a choice and that is a good thing.
Never by hatred has hatred been appeased, only by kindness - the Buddha
I was looking at the program to import the GTK themes. It's called Legacy Theme Importer. I read the description. It says something down the line of:
"...the most common legacy theme is GTK..."
We can argue all day about who has better themes, thats not the issue here. The issue is the wording. If anything, you'd think that legacy would be something down the line of KDE1 themes, as they're out of date basically, with the new KDE2 engines. But theres still plenty of GTK themes being created, and it's not out of date. I like both KDE and GNOME, but I don't feel that their wording is appropriate at all. I see it as a subtle insult to GNOME, geared towards new users, to steer them away from GNOME.
you heard wrong. as someone who has programmed with both toolkits, QT is far superior from a design standpoint. On more than one occasion, I've seen gtk apps ported to qt, and as a result of the simple elegance of the qt toolkit, the resulting codebase was half the size (quite literally) of the gtk counterpart.
In this image, we clearly see three folders in a browser window - one named Natalie, one named Portman, and another named StarWars. What can this mean? Obviously it means that osm is a KDE developer!