Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
KDE GUI

GTK-Themes To Be Supported By KDE2 117

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.
This discussion has been archived. No new comments can be posted.

GTK-Themes To Be Supported By KDE2

Comments Filter:
  • Comment removed based on user account deletion
  • the article claims that QT is faster and easier to work with, which would be a valid reason to many.

    I also thought some of the big contributors to KDE were from trolltech, though I'm not certain of that.

    ________

  • 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!)
  • I just hope that I can have the look still be professional

    I don't know...I always thought KDE looked kindof windows3.1ish. I prefer the way HELIX Gnome looks, because, in my opinion, KDE looks childish. I've got them both loaded though.

    Plus, both KDE and GNOME are pretty customizable, and a "professional look" is really a subjective term. For instance, who is to say even having a start menu bar is professional? Maybe the AIX CDE box is better.
  • OK, Rant on, I haven't even looked at the site. I hate themes, they contribute almost nothing, and in general just make things harder to use. How many times have you gone through your GTK (or WinAmp, or whatever program) to find something actually legible? If a theme made fonts larger for people with poor eyesight, WooHoo, but mostly they just have some red metallic background with wood trim that it's tough to see text on top of.

    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

  • I just installed rh 6.2 and it still uses E :(
    Switched to sawfish and its VERY nice. Seems prettier than E and much ligher on resources. It may be the default if you compile or dl gnome seperate but I'm not sure
  • by JBv ( 25001 )
    Hopefully this is just the begining of the much desired interoperability between both desktops.

    J
  • I agree that calling GTK themes "legacy" causes some confusion and is probably not the best wording, but at least they are consistent. The best way to add a non-KDE application to the panel is to choose "Add -> Legacy application".

    I'll post it to kde-devel and see if anyone cares to correct this.

  • by Guy Harris ( 3803 ) <guy@alum.mit.edu> on Wednesday July 26, 2000 @11:54AM (#903292)
    Now where is my QT theme support for GTK?

    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..

    And what is the status of GTK 1.4?

    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 [gnome.org].

  • LUSCIOUS!

    Those developers deserve a big hand as they propel Linux into a more advanced phase of user interfaces. If you ask me, those screen shots look one hell of a lot better than the recent slatherings of Macintosh "Aqua" themes that have been lurking about.

    Looking long term, however, we must look to see which code base will serve us better in years to come, and make it the base. In cases like these it's nearly always the better-designed product that is more flexible and maintainable. Let's keep it that way.

    PS. That translucent window is especially funky.



    --

  • 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.
  • 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.
  • I'll sign my name and lend my 2 points to that.

    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.

    ________

  • Your question is frequently asked. Hence, it is in the Slashdot FAQ.
  • 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.
  • The best perk from this is that it will now be possible to have both GTK and QT apps look the same. Too bad the announcement encourages people not to make new GTK themes for it. It would be nice if there was a standardized theming system used by all widget libraries. Of course this would be a lot of work, but I think it would be worth it to make things look a little more uniform.
  • by mickwd ( 196449 )
    Hey, does this mean I can now CUT-AND-PASTE themes between KDE and GNOME ?
  • Think the slashdot effect is bad today?

    Imagin two years from now, when the 800.000 user who check out a site has xDSL connections in stead of 56k modems...

    - Knut S.
  • 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,
    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 ;) That's GIMP, KDevelop, Netscape, and Corel WordPerfect. On Windows the equivilent apps have a lot of integration. On Linux there totally seperate entities.
    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!
  • 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*
  • Interesting. Thanks.
    By the way, by way of coincidence the following quote appeared at the bottom of the page:

    "The most important design issue... is the fact that Linux is supposed to be fun... --
    Linus Torvalds at the First Dutch International Symposium on Linux"

  • You did furnish proof of concept in something you wrote yourself!

    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 :-)

    However, I think I'm going to stop posting at slashdot (moderators take note) becaue I'm tired of seeing my posts, made anonymously, stay at a rating of 0 while responses to my posts get ratings of 2 or better

    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.

    I think the moderators don't even look at ac posts unless they are patently offensive and then just give them a -1.

    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.

    I really don't give a damn about karma since ac's have none, but would like for my posts which are much a cut above the usual to at least be visible at the default browsing level.

    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.

    I feel that everyone should post anonymously, but with Slashdot id's. In other words only Slashdot would have the hash to match slashdot id with a real email address.

    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.

    Thanks again for your attention to detail in your post, stripes.

    I try. Thanks for the flattery.

  • Hmm... you must not look very closely. First of all, most of the messages in response to this news is about how the title is misleading, not "KDE sux, GNOME rulz!" messages.

    Secondly, you're not only flaming Gnome USERS, you're flaming GNOME itself! You put it down MANY times in your post. You don't even need a GNOME announcement to flame GNOME, you use a KDE announcement! Talk about hypocritical.

    Thirdly, you must be blissfully ignorant of the fact that IT DOESN'T MATTER WHICH DE IS BETTER! You make it sound like people only care about which DE is better, which is ENTIRELY subjective. If you're sick of people flaming KDE, stop continuing the war! One can't fight a war if nobody shows up!

    Oh well, good job KDE... more features are almost always a good thing!
  • 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...

    You mean what imlib has been doing for quite literally *YEARS*.. ;-P

    'Gee, is *THAT* what imlib_config is for. Wow, who woulda knew.. Pixmap caching..'
  • Why can't all these idiots simply stop for at least a while ...
    So KDE is a stranger with a candy ? And that ooh shining good-looking Gnome with themes that crashed all the time when it was 1.0 is then what ? KDE almost doesn't crash, looks good, works fine, I don't have to pay for it - it's good enough and I find it free enough.
    You're no better with your fanatism, Gnome is not the only choice ... there are also other GUIs than KDE and Gnome.
    And, btw, Gnome is not truly free software, only public domain ( well, and maybe *BSD ) is truly free.

  • KDE has always been too fast and stable for me - that's why I use Gnome. Hopefully this will redress the balance somewhat.

    Now can I whine about the QT license please?

    NB: this is supposed to be a (lame) joke but no doubt some idiot will mark it down as a troll. Thanks in advance.
  • 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.
  • 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.
  • I think you fail to remember that when the KDE project chose, there was no GTK to choose. Maybe QT is the problem, but I have a feeling that at this point it'd be easier to reimplement QT than to rewrite all of KDE to GTK... there's a very big difference between the two toolkits.
  • Actually if it was possible to use GTK themes also in KDE it would be very good.Many GNOME mindedn people on /. are picking KDE on this move, but in my opinion this is good.

    Why? If this is done well, this'll allow me to have desktop in which I can use programs from both GNOME and KDE without them being disturbingly different looking (and if even widget functionality could be imitated they would behave equally which would make the desktop easier to use.) This would be good as depending on program either GNOME version or KDE version is better and this would allow me to merge good sides of the desktop (especially if common DnD and embdedding standards are also developed.)

  • I can't get at the KDE site, which might mean that some ticked-off "GTK advocate" may have gotten irritated and decided to DOS them, or that many, many people are interested in this development.

    This is called "the slashdot effect". It's what happens on "the internet" (or rather "the net", as it's afficiandos call it) when slashdot.org (a site where linux and open source issues are discussed) posts a "hyperlink" to a certain world wide web "address". The "server" (the physical machine to which the "link" (as hyperlinks are commonly referred to) is pointing to) then becomes overwhelmed by the resulting traffic.

  • 7.5

    Not a bad troll.. shame on you for trolling at +2 though. Lets have a detailed look at the troll.. shall we?

    Well it was bound to happen. I just hope that I can have the look still be professional

    Aha.. so we are coming in with the pious, self rightous troll. Well okay, these are typically hard to pull off do to the combative nature of the troll, but some trollers like a challenge.

    The only thing that really ticks me off about Gnome is the H@kkerD00dz look that it has. KDE is much more professional.

    Okay.. your form is a little sloppy here but I like your spunk. You lose points with the hacker-dudes reference though.. it's just a little too flambaity but the KDE is more proffesional line is great. It's generic enough to draw attention while slipping under the troll detectors of most readers

    When I was faced with what WM to choose for our X workstations I was told to use something professional, but that could be customized. Gnome failed the test

    Again with the kde is more proffesional bit.. it works well here. Nicely done. Again you offer no facts to back up your opinions so you increase the chances of sucking in the average slashdotter. This is a nice variation of the "I'm a consultant for a fortune 500 company" troll.. nice

    Oh, you can set Gnome as default, but KDE is the standard in our office.

    Your dismount is weak here.. you were really building steam then you just gave up. Remeber a good troll seems like a genuine post, you need to work on bringing it all together at the end.

    Your troll score is 7.5 out of 10, not bad but it needs a little work
  • On Themes and Icons

    New and old clothes for KDE

    If you have had the opportunity of using a recent KDE2 beta, you may
    know that KDE2 has supported widget themes for quite a while now. You
    may have noticed that these themes are fast. Really fast. And even
    those themes using pixmaps and gradients run at a decent speed, thanks
    mostly to [1]Qt's excellent theming-engine and our optimized pixmap
    storage and cache mechanism.

    In addition to native KDE2 themes, we are pleased to announce that KDE
    now supports pixmap [2]GTK themes. However, while GTK themes are
    displayed faster and more efficiently than even native GTK itself, we
    do not recommend using this format for creating new themes. Theme
    developers should prefer KDE2's native widget theming which yields
    superior results both in terms of quality and speed. A nice HowTo and
    some documentation on KDE2 theming is available [3]here.

    For the curious, here are some screenshots of KDE2 using GTK themes:

    [4]gtk-themes 0 [5]gtk-themes 1
    [6]gtk-themes 2 [7]gtk-themes 3
    [8]gtk-themes 6 [9]gtk-themes 4
    [10]gtk-themes 5

    I Con Do It -- Icons in KDE 2

    In KDE2, icons are themable as well. A nice application of this
    feature can be seen if you start KDE2 on an 8-bit color display. In
    this case, KDE will automatically default to a carefully crafted icon
    theme based on a 40-color palette: 216 extra colors are left for the
    more color-greedy applications. Of course, on a true color display,
    you would get the hi-color icon theme.

    The size of the icons can also be easily changed. Just right-click on
    the toolbar handle, and you'll find a menu with a selection of various
    icon sizes. Or change the icon size in other locations or globally
    from the KDE Control Center. This way you can make optimal use of your
    desktop space and monitor:

    [11]icons [12]icons

    Also notable are the various icon effects. These include levels of
    greyscaling, highlighting, colorization, saturation/hue,
    semitransparency... and the ability to customize the behavior and
    appearance of the icons in all the various states (MouseOver, default,
    disabled) and locations (desktop, toolbars, menus, panel).

    In fact, if you are creative enough, you can do such things as make
    [13]Konqueror look like Netscape. Or Internet Explorer. Or make it
    look like something entirely different. We tried our hand at it:

    [14]Netscape [15]gtk-themes 1
    [16]Else

    While these are aesthetic features, they can also be quite important
    from a usability point of view. For example, if you are an artist or
    graphic designer, you may not want your icons to look too colorful. In
    fact, if at all possible, you'd want to work in a color-neutral
    environment. Well, with KDE2, you can switch all your icons to grey
    quite easily - and if you want a colorful desktop to impress your
    friends, it is just a click away!

    References

    1. http://www.trolltech.com/
    2. http://gtk.themes.org/
    3. http://www.mosfet.org/themeapi/
    4. http://www.kde.org/announcements/gfx/gtk0.png
    5. http://www.kde.org/announcements/gfx/gtk1.png
    6. http://www.kde.org/announcements/gfx/gtk2.png
    7. http://www.kde.org/announcements/gfx/gtk3.png
    8. http://www.kde.org/announcements/gfx/gtk6.png
    9. http://www.kde.org/announcements/gfx/gtk4.png
    10. http://www.kde.org/announcements/gfx/gtk5.png
    11. http://www.kde.org/announcements/gfx/konqEG1.png
    12. http://www.kde.org/announcements/gfx/konqEG2.png
    13. http://www.konqueror.org/
    14. http://www.kde.org/announcements/gfx/konqNS4.png
    15. http://www.kde.org/announcements/gfx/konqIE3.png
    16. http://www.kde.org/announcements/gfx/konqEG3.png
  • I think I read somewhere where Miguel said, if you don't like Gnome, you're probably using RedHat's version... :)

    Get HelixCode's version of GNOME (Helix GNOME). It kicks ass. http://www.helixcode.com/ [helixcode.com]

    It comes set up with sawfish as a default, and it is a very nice window manager.

  • by sugarescent ( 30924 ) on Wednesday July 26, 2000 @11:03AM (#903319) Homepage

    Heh. Why don't you check out gtk.themes.org [themes.org] and see just how many engine themes there are. There are about an order of magnitude more pixmap themes than engine themes.

  • by Anonymous Coward on Wednesday July 26, 2000 @11:07AM (#903320)
    How many more screens have to be shot ?

    Save the screens !
  • Hey,

    Next time, if you are to announce something like that, would you please first mirror the document/ site/pictures before you post the news?

    You save the target site from /.-ted, save us tons of frustration too.

    Not all sites can handle this kind of tsunami.

  • yes, yes. The old chicken and the egg. without rampant innovation (as in diverting from status quo) we wouldn't need standards, yet standards encourage a common ground, which then becomes staus quo (not to mention, standards are slow).

    That's why you see a lot of big name companies designing specs before content, and others touting reference implementations. Also why sun is so darn picky about JAVA.

    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.

    Well, it certainly worked for Microsoft. Embrace and Extend. I like the improvements GNOME & KDE have made to little subtle things in the GUI. But, if you hate it that much, go back to proprietary, standardized systems. I don't think those developers for KDE and GNOME who put a lot of work and thought into thier products, and, BTW, write the code you are complaining about, will miss you that much. Just don't complain when you are boxed into a bad standard.
  • I feel the KDE and GNOME team are doing an incredible job with their software. I have currently been playing around with the second beta of KDE 2.0, and I have so say I see no need for Windows when this is released. A full featured Office pack, witch will keep evolving at much higher rate than MS office, and also a nice and free OS, with true multitasking that is addition is portable. Why use Windows? (don't answer that (= )

    But why both kde and gnome? If these teams joined forces, imagine how fast the Linux/UNIX desktop world would evolve.

    - Knut S.
  • by be-fan ( 61476 ) on Wednesday July 26, 2000 @11:28AM (#903324)
    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!)
  • by crisco ( 4669 ) on Wednesday July 26, 2000 @12:31PM (#903325) Homepage
    But then again, IANAKD (I am not a KDE developer).

    I parsed that as I Am Naked.

  • by joeytsai ( 49613 )
    from the faq [slashdot.org]
  • I must at least somewhat agree to this. I am a somewhat color blind person, and many themes must rely on some color scheme that looks great with full color vision, but blends together into an ugly mass to me. Themes are pretty cool to show off, but I myself prefer a nice grey/black/white theme, like the default GTK theme. I really hope widget set designers keep that in mind when designing their default looks: A flat grey is in general faster, more easily recognized, and easier to use than a wild eye candy theme. Adding theme support is great, as people can do what they want after getting things going, but the default look should be clean and easy to see...
  • I'm not sure I'd agree about a MS forcing everyone to use MFC producing a 'better' library, 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).

    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.

    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.

    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.
  • Gtk-- seems too much caught up in theory - the minute details of the sig/slot mechanism. While that might be useful in some rare cases, wxWindows also has a very flexible and *easy to use* method of creating custom messages or signals.

    The sig++ docs have lots of theory. The sig/slot mechanism appears trivialy easy to use. Examples from my code:

    • SigC::Signal1 waiting; - a signal (called waiting) that takes a string and has no return
    • SigC::Signal2 fetching; - a signal (clled fetching) that takes a bunch of pointers and has no return.
    • waiting.emit("reading tuneinfo"); - raise the waiting event
    • waiting("reading tuneinfo"); - exact same thing
    • model->waiting.connect(slot(this, &NormalJukeControls::do_waiting)); - set up a handler
    • c_in.disconnect(); - cancel a handler

    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.

    Qt is very, very nice. The moc precompiler is just there to avoid unnecessary tedium in handling signals - a real time saver.

    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?

    However, after looking at it for a little while I much favor wxWindows for those wanting a well thought out and easy too use C++ wrapper.

    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.

    What I really like about both Qt AND wxWindows is proof of concept. Both have many excellent and complete applications build on them, and come with many, many excellent examples and demos. Compare that to the demos that come with Gtk--, which are pathetic. Name me one major application that uses Gtk-- today. Gnome uses straight C with gtk+, not gtk--.

    I donno, what's major? I did w3juke [sourceforge.net] 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 Havoc Pennington is not satisfied with gtk-- either and is designing yet another C++ class lib that mostly just wraps gtk.

    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!

    STL and excessive use of templates suck. A sure recipie for disaster and several orders of magnitude of bloat. In theory, STL and templates are nice, but implementation is another matter.

    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?

    fltk

    How old is that?

    Yes, choice is nice. I always enjoy useful gtk and qt apps which don't incorporate the bloat and instablility of Gnome or Kde, and encourage others to consider designing apps which don't depend on these massive subsystems instead of becoming enslaved to them.

    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.

  • Oh come on...grow up and don't be so melodramatic. I think you are the one who should be shamefull if you compare child assault with a software project.
  • The article hardly gives this enough credit. The screenshots and advances are nothing short of amazing. The KDE Team have done it yet again.

    The Desktop battle is far from over. Way to go on all sites.

    -KS
  • If you think ETerm has real transparency, then try this.

    Drag your ETerm window over the top of your Netscape window.

    Do you see Netscape underneath?
  • by a.out ( 31606 ) on Wednesday July 26, 2000 @10:02AM (#903333)
    "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.
  • How can a library which is a superset of another library be "inferior"?

    In a mathematical sense, that's a convincing argument. In the real world, it is impossible to maintain every benefit of a program and yet simultaneously add features.

    For example, The Linux 2.2 kernel is more featureful than the Linux 2.0 kernel, but on the other hand it's bigger. If you were building embedded systems perhaps you'd choose the older kernel.

  • I do believe that this should say "GTK-Themes To Be Supported By QT2.1", not KDE2.

    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...)

  • Those screen shots look nice...I've been looking for a window manager that supported alpha and that was stable...It will be nice if KDE makes it happen...I'm impressed...
  • It seems to me that themes are a good thing from your point of view.
    Rather like style sheets, if all of this `natty design' is put in the
    themes, then you are free to override it.
  • It's true. Try it and make your own decision- nobody's holding a gun to your head.

    But be careful- you might not go back.... : )

    -Chris
  • I agree with you 1000%, but after finishing up the latest project I've been working on for my company (and one of my first group projects) I can say the following:

    Geeks do not (usually) find documentation fun
    Geeks like to dive into a job, not usually plan it out

    The result is that I think Open Source software in general has poorer documentation (this is changing slowly but lets be honest, most people would rather code then document), and more disorginazation/decentralization is tolerated (especially in the beginnings of projects).

    Like all rules there seem to be a number of acceptions. I think you're right, but the quote signifies the change in culture that needs to take place for Linux to go mainstream. Up until now its mostly been for the 'fun of the developer', now we have to focus as much on the 'fun of the user' who may not necessarily be a developer, or a geek, or even a Power User.

  • Presumably the word `legacy' was intended to mean "Themes that I was using before I upgraded to KDE2". It's not legacy in the sense of outdated software per se, it's legacy in that you've got a new program to play with and so won't be using older stuff again.

    As someone else pointed out, it's also a subtle joke - playing on the attitude that "Now I've got KDE2 I won't need anything else from anywhere ever, but I still want to use my old GTK themes!"
  • Actually thats kind of backwards. Qt hired some of the KDE developers, because Qt liked there work, and wanted them to fully development.
  • by nitehorse ( 58425 ) <clee@c133.org> on Wednesday July 26, 2000 @10:07AM (#903342)
    Qt only provides very bare technical support for the GTK themes - the only support that it provides is that it can load pixmapped widgets. KDE actually implements the GTK themes and displays them with Qt- so the article is not mistitled.

    Hope that was informative.

    -Chris
  • 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.
  • For a few years now, Linux opponents have been doling out dire warnings about forking issues. It has been said that eventually there will be too many choices and not enough interoperability.

    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

  • yes, but diversity & competition is what drives innovation.
  • 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 [debian.org] 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.
  • When I was faced with what WM to choose for our X workstations

    Not to nit-pick, but neither KDE nor GNOME are window managers. GNOME currently comes with Sawfish as its window manager, and I believe (although I may be wrong) that KDE ships with KWM as a window manager. Both desktop environments allow the user to change the window manager to any other that their heart desires.

  • How can a library which is a superset of another library be "inferior"?

    X, Y, and Z are feature sets. The subscript q denotes quality.

    Let X = Y + Z; if Zq Xq.

    If the superset sucks, and the subset leaves out that which sucks, the superset is inferior.

    --Threed-Looking out for Numero Uno since 1976!
  • But if there was only one main GUI for LINUX, LINUX desktops would be as boring as Windoze desktops. The whole appeal of LINUX is it's variaty, every desktop can be completely different.
  • by vanza ( 125693 ) on Wednesday July 26, 2000 @10:31AM (#903350)

    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
  • Now we see the truth
    With Bonobo and now Themes
    They are both the same.

  • 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.
  • Sounds like you're making a case for either plain extremely useful interfaces or UI's with the ability to load themes. Why can't we have both? Maybe a theme doesn't add any value to the UI (in your opinion), but even at that, so what? They're fun. And I remember one of my professors mentioning something about user interface design. Eyecandy is not for the developers, it's for the users and it *does* contribute to the general acceptance of the software. Sort of runs on the same theme (no pun intended) as "Executives *like* pie charts." :)

    --

    "Praise the Lord and pass the ammunition..." --Dixie Chicks, Sin Wagon

  • http://www.kde.org/announcements/gfx/ gtk0.png [kde.org]

    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.

  • by stripes ( 3681 ) on Wednesday July 26, 2000 @11:41AM (#903355) Homepage Journal
    Qt is native C++

    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.

    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).

    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-- [sourceforge.net] is not just a good wrapper, but a great one.

    Sigc++ [sourceforge.net] (the slot/event scheme Gtk-- uses) also handles events faster then Qt's event system according to a biased benchmark [sourceforge.net]. 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.

    Personally I don't like C programming and much prefer C++/Java.

    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.

    Thus I use Qt. If you want to use C, use GTK+.

    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.

    Down on the farm, we call that having a choice and that is a good thing.

    Indeed it is.

  • But why both kde and gnome? If these teams joined forces, imagine how fast the Linux/UNIX desktop world would evolve.

    ...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).

  • By what measure is it "inferior"? I admittedly have not done much GTK programming, though I have done some Qt. I am not a C++ purist, actually it frustrates me from a bloat/startup efficiency standpoint because it can encourage creation of "elegant" but fat, slow code. But that is another discourse. GTK on my older Aptiva 166 is noticably slower than Qt, I can watch the menus draw in GTK, they are instant in Qt. On my 333, there is still a percievable difference. From a users point of view, relative speed, how snappy a toolkit feels, would seem to dictate which toolkit is better. Qt wins this hands down. And this doesn't even address themes, I was refering to unthemed GTK in my example. QT seems to suffer little to no performance degradation from themes, pixmaped or otherwise.

    From a programming point of view, "inferiority" becomes harder to decide. Which toolkit allows you to develop faster? Which allows you to re-use more code? Which is more human readable? Debuggable? Stable? A lot of these depend upon the person coding, some people prefer C, others C++. The greatest division among which is inferior probably falls into these subjective lines.

    Lastly, it seems (especially in Linux Land) a lot of people lable something "inferior" when they don't like the license. Too many people are willing to forgo a better technology because it doesn't have their favorite license pasted all over it. This is just plain silly and juvenile. If the code is good, it is open, people can see it, use it and modify it, there is not reason to go with lesser technology because someone prefers a different license. It's like Beta vs. VHS or IBM/DOS vs. Apple all over again.
  • Yes ludicrous concept. The problem is that diversity is useless without standards. If KDE and GNOME were 100% binary compatible, I'd have NO problem with having 2 (or 200) of them. That was the situation before that days of KDE when you only had Window managers. They were all different, all had some nifty features, and all ran all the X11 applications. THAT was GOOD choice bloat because no matter what you chose, you could run all the apps. However, the situation now is BAD choice bloat. KDE/Linux and GNOME/Linux are 2 different operating systems as far as the application is concerned. Without a binary standard to unify them, you end up with the current situation where a lot of users have to have both installed. That's unacceptable, because both GNOME and KDE continue to grow, and continue to subsribe to the emacs "I AM an operating system" concept. Now, Linux is easily 2 or 3 times more bloated than it should be. If this keeps up, "speed, efficiency and elegance" will no longer be one of the advantages Linux has over Windows. If there was a binary standard, then great. But by decreeing that "We must have many choices!" and sticking to it despite the "real world" problems that come with diversity without a standard, you're sticking to ideology instead of pragmatism. And when you can't accept another concept because of ideology, you're guarenteed a crappy product.
  • To be honest --- there are so few genuine 'engines' available for GTK that it'd be easier just to port the code to new KDE engines.
    John
  • Nope. It's not a cheap trick. It's actually transparent
  • 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.
  • Most of the complaints about KDE in the past is that it is ugly compared to Gnome. Honestly, I think it still is. The font seems too big, and the buttons are definately too big. I think GTK theme support is an attempt to quiet those critics. I personally haven't been impressed with any of the screenshots. They still look like themed QT widgets...
  • It's funny how no-one noticed the bit of Konqueror looking like Netscape and Internet Explorer. I guess the trolls already got their fodder with the GTK stuff.
  • 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.

  • 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
  • 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.

  • No, as opposed to a newer, bugfixed, and rather stable GNOME. While GNOME 1.0 was definitely core dump city, GNOME has been pretty solid ever since October GNOME. I know because I've used both October GNOME and GNOME 1.2 from Helix Code.

    I suspect I'm feeding a troll, though. Sigh.
  • KDE and gnome have only one standard binary, elf. What differs between the two are the libraries that they need. And for some programs you may don't even need all the libraries from gnome or KDE and in some cases you will only need the widget one (gtk for gnome and QT for KDE).
    --
    "take the red pill and you stay in wonderland and I'll show you how deep the rabitt hole goes"
  • Well it looks like they are putting the code where their mouth is...(IE -- It's not biased or arrogant if they can back it up)...A little bit of show boating in the free software industry seems healthy to me....(Since their is no monitary reward -- people are taking payment in pride and bragging rights...)

    It looks REALLY good to me...
  • by Outlyer ( 1767 ) on Wednesday July 26, 2000 @10:09AM (#903370) Homepage
    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 couldn't agree more. Ever since I saw the shots from that recent conference, I've suddenly had a new outlook on linux desktops. The future looks very bright.

    I've been a Gnome or Windowmaker user thoughout my linux-using history. I didn't really like KDE because of ugly windows-ish QT, and it just didn't seem polished. But now, as soon as KDE2 is released, I'm switching. I know looks can be deceiving, but it just seems so polished and well done, compared to Gnome, which always seems to me like a bit of a hack. I also loved the TigerT icons in gnome, but the new ones in KDE2 look even better IMO.

    With the new polished look, new functionality in the WM and panel, plus also Koffice etc. I think it's going to be hard to beat KDE2. But no matter what, it certaily paints a rosy future for the linux desktop in general.
  • It's really a shame they are so different. There really IS a great need, in my mind, for some sort of translation or easy porting mechanism. Having KDE accept GTK themes is nice (since I, and most people I talk to, wind up using bits of both GNOME and KDE, this should make the desktops a little prettier) but it's just window dressing.

    Doing something about the need to install and (wince) load in memory two duplicate libraries that do the same thing would be much more significant.

  • It was. However, does that mean that pure QT apps won't get the themeing? Particuarly project Kylix, which apparently isn't a KDE app?
  • by boloni ( 87395 ) on Wednesday July 26, 2000 @10:09AM (#903374) Homepage
    Pixmap themes are essentially images painted over the controls. Widget themes on the other hand, are actual code, loaded dynamically which draws the controls. This make it not only faster, but allows to change the way in which the control behaves. For example, in some styles KDE scrollbars have 3 buttons (2 down + 1 up), combining the advantages of different toolbar styles. With a pixmap style you can change how the button looks, but you can not switch between different behaviors. Lotzi
  • Note that not all GTK themes will work, only pixmap themes. And the Gnome/GTK people themselves have said on numerous occasions that the current implementation of the pixmap theme engine is pretty bad. Most people I know don't use the pixmap engine but rather something faster (and better-looking than most pixmap themes) like the CoolIce theme engine. Still, this is a pretty impressive accomplishment, kudos the the KDE people.
  • I can't get at the KDE site, which might mean that some ticked-off "GTK advocate" may have gotten irritated and decided to DOS them, or that many, many people are interested in this development.

    Realistically, I don't think that making GTK themes somewhat usable with KDE is of vast and stupendous importance. (I don't think themes are of vast and stupendous importance, which is a huge piece of cause for that...)

    However, the beginnings of interoperability are reason to feel encouraged. The more GNOME and KDE can use "each others' toys," the less that the rancour will be justifiable, and there has been a lot of rancour.

    If they can "play well" with toys, that can lead to more and better things. Probably not to KDE deciding to adopt GTK, and change the preferred implementation language to C, but there you go...

  • 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.

  • Here is the difference: KDE2 will be supporting GTK *pixmap* themes -- in which all the widgets are predrawn pixmaps which are cached in memory.

    KDE2 native themes are (IIRC) coded themes. (Blackbox does the same thing -- in fact, I think that some of the code was shared between BB and KDE2) These themes don't draw the window and then overlay the necessary elements with pixmaps, they just draw the window themed in the first place.

    Enlightenment's theme engine is the most similar to KDE2's -- and it would probably provide similar performance.

    But then again, IANAKD (I am not a KDE developer).

  • Qt had a C binding, called QtC. It was for Qt version 1.30 or so, and it probably still can be found somewhere.
    Anyway, nobody uses or used it, so there is no need of it. I personally don't see a reason why there should be a C binding if there is a C++ binding - it simply doesn't make sense to me. Qt has Perl and Python ( and maybe some more ) bindings, because they apparently are needed, but it doesn't have C binding now, because that's not needed.
  • by battery841 ( 34855 ) on Wednesday July 26, 2000 @10:40AM (#903380) Homepage
    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.
  • by Anonymous Coward
    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 computing, anything that is installed and working is a 'legacy system'. Order a shiny new 512-processor compute farm, set it up - and as soon as it starts running its first job, it's a legacy.
  • by 11223 ( 201561 ) on Wednesday July 26, 2000 @10:19AM (#903398)
    In this image [kde.org], 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!

In any formula, constants (especially those obtained from handbooks) are to be treated as variables.

Working...