...which is good. The file chooser improved a lot on GTK2, but it could still use some polish.
BTW, does anyone knows if GTK supports the Composite render extension available on X.ORG? Or perhaps it has nothing to do with it and doesn't need it? I tried enabling compositing on XFCE 4.2rc2, and while the desktop looked MUCH better (with true transparency, window shadows and the works), it slowed my system to a crawl.
That's a video driver issue, unfortunately. There's only one driver for Xorg at the moment that accelerates the necessary operations for translucency. (the non-free nNivia driver).
There's a planned port of the Kdrive acceleration architecture that'll make it much easier to accelerate it with other drivers.
That's a video driver issue, unfortunately. There's only one driver for Xorg at the moment that accelerates the necessary operations for translucency. (the non-free nNivia driver).
Yes, i'm aware. I'm running the latest binary drivers from nVidia, and even "experimental" extensions like XRenderAccel desktop works just fine, and gives a nice speed boost to my desktop. OpenGL renders great as well, but for some reason, Composite + XFCE work awfully slow, like it's working on software mode. I though perhap
Just so people don't get the wrong idea about Composite or Xorg, on my relatively modern (but by no means uber) computer xorg + composite + translucency + drop shadows doesn't slow it down one bit. In fact with all the effects on the windows actually appear to slide around smoother than they did before, although I'm sure this some kind of psychological effect.
Also of note is that I have one graphics card driving two monitors, and it's still not an issue.
Don't be afraid to try Composite on Xorg! And if you run into problems submit bug reports! Xorg has great promise. Let's all help to make it as good as it could be (and no I'm in no way related to the Xorg project. I just think eye-candy is where its at).
Nonono, don't get me wrong; i have nothing but praise for the work the X.Org team is doing! It just strikes me as odd that it would run so slow, and thought perhaps GTK had a problem with Composite.
I've been following the project closely, and i think it's becoming to be all that XFree should've been by now.
Absolutely. Something weird was that Gkrellm2 rendered with glitches, but ran just fine, albeit slower, just like the rest of the desktop.
Anyway, i want Composite on:) I'll dig on it tonight.
although I'm sure this some kind of psychological effect
I don't think it was. The way I understand the Composite extension, all windows draw to an off-screen buffer, which the compositing manager displays. When using the a compositing manager, you don't have to ask the client applications to redraw themselves when exposed by moving a window, so moving windows should be considerably less CPU/network/context switch intensive.
You really need to have hardware acceleration enabled to use composite effectively. I've found that with the NVIDIA binary drivers, and RenderAccel enabled, it feels much, much smoother than without the composite manager running. If you have an NVIDIA card, you can do this in your video device section:
Option "RenderAccel" "true"
Then run "xcompmgr -c" on the active $DISPLAY while X is running (unless your window manager du jour has built-in composite support) and you're ready to go.
That's because you are using NVidias binary driver, right? Then you have the RENDER extension hardware accellerated, and RENDER is used to compose and draw the transparent bitmaps. Some X.org OSS drivers also have accellerated render, not as good as nvidias though.
you're obviously on crack - or you have translucency turned on for that one little window that's never above anything else.
try joining xorg on freenode. The channel topic says it sall "composite is slow, we know".
now, don't get me wrong. I love what the composite extension can do; But don't go getting people's hopes up, "ooh, my 900Mhz celeron proc with a 32 meg graphics card will look just like my dads powerbook" cuz it ain't gonna happen.
Bug report #11120759: Assumption that all graphic hardware manufacturers have binary drivers for the current stable Xorg release which allow for translucency and shadows to work is incorrect.
Affects: Many, if not all ATI cards and Xorg >= 6.8.0
"The file chooser improved a lot on GTK2, but it could still use some polish."
What I've never understood is why, in newer releases, they don't provide the filechooser with a backwards-compatible link library so that the older programs will at least interface with the operating system somewhat like newer programs. Something like an LD_PRELOAD that we could do so that every application doesn't wind up with it's own file chooser.
That's the big problem w/ many Linux apps -- they are all their own beast. To
Wouldn't that be something like Gentoo? You set up your USE=gtk2 and compile the entire system against it, rather than a bunch of binaries which are linked against who knows what version of pick a widget set. I know my system seems pretty consistent.
I haven't used Gentoo, but I was pretty sure that the version of Gtk used was based on the version the application was coded for, so if it hasn't been ported to Gtk2 yet, it just uses the Gtk1 widgets.
Otherwise, I imagine RedHat and others would have more consistency between apps.
Well, i hate to bitch, but let's see... the basic idea for the new GTK file chooser [gnome.org] is quite good, and makes browsing directories much easier, but i still feel too much window space is taken by widgets and empty space, which sometimes makes hard to read directories and filenames. Still, i really like the buttons with the path separated in directories.
Better keyboard control would be nice too; that they added typeahead support is a bless and well welcome.
Agreed. Windows, for example, opens a window slightly bigger and with less space dedicated to the directories shortcuts, which improve usability a great deal. It could work well with the new GTK dialog.
Like i said earlier, it's just a matter of polish. Generally speaking, i like the new file dialog.
There should be a text input working in parallel with the gui. Sometimes, it's easier to just type the name, especially with the help of auto completion. It's also convenient to cut/paste the pathname in the file selector.
A lot of people agree with you. [url:http://bugzilla.gnome.org/show_bug.cgi?id=136 541] The gtk2.4 filechooser was a big mistake. I have no idea if this is fixed in 2.6. It really should be since people have been bitching about this dialog the moment it was placed in wide release.
Put differently, the file chooser hasn't been fucked up more since Eugenia started her contest. I hate not being able to do a tab-based regexp search, as common in ye olde GTK+. Yet, patience may be the solution.
Still, I'd rather have the old tab-based method back. It's familiar, damn it. And it seemed more... keyboard-centric instead of mouse-centric, which I like. This is like it's been put in for old codgers like me, to shut us all up. (I'm sorry, but CTRL-L?!) And not for actual usage.
I forget who it was that said that a single mouse move and click (including time to move hands from the keyboard) was worth up to eighteen keystrokes in time. Perhaps that's a bit much, but I will lament the slow passing
that's not entirely true. windows still doesn't have compositing. os x has had compositing since 10.0, but didn't get gpu accelerated compositing until 10.2. tiger, coming out mid next year, will offload even more of the 2d drawing onto the gpu (instead of just the compositing.)
What's your point? That we should all point to and bash free software developers cause they are behind respect to enterprises that have been working on UI at least 10 years before we got a free OS with an usable free GUI?
Well just because something is gratis and has liberal licenses doesn't give it an execuse for incompetence. Many of these useability problems have been well researched and fixed years ago. There's no point in rediscovering all these advances. The new toolkits should just use them. T
Well just because something is gratis and has liberal licenses doesn't give it an execuse for incompetence. Many of these useability problems have been well researched and fixed years ago.
Aha, but you see, GNOME suffers from a terminal case of Not Invented Here. In fact, anything touched by the GNU must be completely rewritten, or thrown away and a new component written from the ground up. So they have to relearn all the hard lessons the rest of us learned 14 years ago.
I think it's the job of the windows manager, such as metacity, to implement the new xorg extensions not the graphics toolkit.
How is the window manager going to change the way an application handles menus and similar things? The window manager deals with the window borders around the application and placement of windows and not with the stuff the application displays within a window.
Ideally both the graphics toolkit and the window manager need to support the xorg extensions to get the best results.
Um, not entirely. The window manager....manages windows. As such, it has complete control over the window as a whole, as well as drawing borders around it. Check out Luminocity [fishsoup.net] if you're interested.
But how long do we as an OSS community stop very new and exciting development in the premise of 'it doesn't work on 0.5% of systems'?!
Linux _desperately_ needs to have a working, easy to use RAD environment. Something as simple, or simpler than Visual Basic. I want to be able to create a simple Linux application by dragging and dropping some form elements onto a page and double clicking on a button and typing a few lines of simple code and have it all working.
Glade is good, but it's not easy enough.
Mono has the possibility of bringing this to fruition. I want to see sharpdevelop making good GTK# apps in a few hours.
One thing that will really screw up the VB crowd moving to GTK+ is the way that windows are designed. Designing a window for GTK/Gnome (optionally using Glade) means building a hierarcy of widgets in containers. In Windows with VB, you just put the widget where you want it.
GTK/Gnome is more 'difficult'** up front but reduces the work by the programmer when it comes to resizing a window. Windows is 'easier' up front but makes the programmer painfully aware of the location of widgets after the fact (windo
"I haven't coded anything for Windows in a few years, so things may have changed with.Net and WinForms (?) in the meantime."
Not really. WinForms has a sensible class structure and generally cleaner design than MFC, but basic positioning is still considered more or less absolute.
Where I work we have bought and external toolkit (Syncfusion) which offers layout managers and then we just use gridbadlayout just like most Java developers do. Syncfusion would integrate nicely into the Windows Form designer
Yeah... let's tell off all those people yelling about how open-source software is lower quality, by making sure every schmuck can make apps that are every bit as bad as most VB apps! That'll be really, um, competetive!
Linux _desperately_ needs to have a working, easy to use RAD environment.
I think that the KDevelop IDE [kdevelop.org] already allows for true RAD in Python and Ruby (with an embedded GUI designer that ties into the editor functions), but if you want a VB workalike without the VB idiosyncrasies, give Gambas [sourceforge.net] a go. It's about to reach 1.0, and seems to work really darn well, from what testing I've subjected it to.
Linux _desperately_ needs to have a working, easy to use RAD environment. Something as simple, or simpler than Visual Basic. I want to be able to create a simple Linux application by dragging and dropping some form elements onto a page and double clicking on a button and typing a few lines of simple code and have it all working
The sad part is, 99.9% of the Linux development community holds you in the utmost contempt, or at the very best, doesn't understand your needs.
My thanks as usual to the people who build GTK and Pango. I guess that I have not yet really learned to appreciate the people behind the curtain, the GLib people, but since they make GTK possible, thanks to them as well.
Currently GTK is one of my favorite toolkits. The reason: Pango. I use multiple languages in my documents, as well as the compose button, and all GTK apps handle it perfectly (I use utf-8 of course). And although the input methods are somewhat redundant architecture that should be lower than the level of the toolkit IMHO, GTK input methods are the best, especially when combined with UIM.
Thank again to all the people involved.
BTW: is there a keyboard shortcut to switching input methods. UIM has it, but I sometimes need to switch to cyrillic translit (can not use ru phonetic since the keyboard is in dvorak) from Chinese and back, and that is a bit painful?
> Currently GTK is one of my favorite toolkits. The reason: Pango. I use multiple languages in my documents
I just recently discovered that GTK+ with Pango has cool monolingual uses as well, since it supports a simple markup language that lets you very easily do things to the text in your menus, buttons, etc., such as italicize, sub- or superscript, etc.
If you read the release notes, it's interesting to see that many of the changes are the creation of widgets that are intended to replace stuff in the Gnome libraries (e.g., the new icon viewer widget). It makes one wonder where the line should be drawn between the widget set and an aggregate library. Moreover, I wonder what the drivers are for moving these things back into Gtk if they're already present in the Gnome stuff (other than to reduce dependencies).
Don't think in terms of reducing dependencies as far as packages to install. Think in terms of reducing dependencies as in eliminating Gnome altogether. I hate Gnome. I think it sucks, and I refuse to use it. Every time I try using it, I end up hating it more. Same goes for KDE. The more useful Gtk+ (isn't that the actual name, as opposed to the inaccurate-as-always story blurb?) becomes without any additional libraries, the more likely it is that applications will be written directly atop Gtk+ rather
Yes it's important to move all the gnome stuff into GTK that way people like you will be forced to install gnome (now called GTK7) just to run your crappy little apps written way back in 1987.
I, too, am really baffled by how the AC took your post.
At any rate, I think toolkit libraries should be able to load and unload different segments into memory like modules in the kernel. If your application needs a calendar widget, it makes a call to load the specific component Toolkit::Calendar and then checks to see if it loaded Toolkit::Calendar properly. The most likely cause of an error would be Toolkit::Calendar not being part of Toolkit's installation on the system.
The idea is that critical components are already sitting on the hard drive. It's only obscure extensions that you have to retrieve.
The situation you'd worry about would be taking a new laptop to the moon--if you've been using it for a while then all the extensions you need should have been asked for and retrieved beforehand.
Moreover, I wonder what the drivers are for moving these things back into Gtk if they're already present in the Gnome stuff.
My assumption is that the parts being moved aren't really Gnome-specific. Applications that want to use those dialogs would have to include libgnome and libgnomeui, which are only available under Linux and very tied into the GNOME environment. For instance, an application which wanted to use a standardized About dialog would have to include the GNOME libraries. This moves it into G
Much of the motivation on the devel mailing lists seemed to be oriented around the idea that the gnome libraries had things in them that weren't quite ready for the gtk/glib guys to commit to supporting in the API-stable 2.x series forever. So the code was put into GNOME libraries to get GNOME apps out the door. When implementations and APIs for things that are generally useful to people doing GTK-only stuff got clean enough for everyone concerned, then they got picked up.
Actually, Gtk# originally started as a managed wrapper just for GTK+ (hence the name), but has since grown to include the rest of the Gnome libraries (gnomeui, pango, etc) as well.
The fact that they haven't changed the name is misleading, but all the base GNOME libraries are available.
Here is a new GTK release and I bet that once again it will be almost impossible to install it easily and successfully through the config/make/make install way.
Damn those dependencies. Damn them to hell.
Sorry to disappoint you chemistry geeks out there, it's been verified: I did a search on GTK and did not find any Grand Theft K 3d chemistry gaming references...apparently it's some toolkit for gimps.
Over the holidays I want to sit down and play with wxWidgets [wxwidgets.org] (formerly wxWindows) to try and make some cross platform GUIs. I believe wx compiles against GTK, though I haven't tried this yet myself. Anyone have experience with this? Do changes in GTK impact wx? (ideally they shouldn't)
We haven't tested wx with 2.6.0 yet so it is possible that currently something is broken (as you say, ideally it shouldn't be, but in practice GTK+ minor version upgrades have often proved to have not so minor compatibility problems). However our next 2.5.4 release will definitely work with it as will the next stable 2.6.0 (of wx, not GTK+). Hopefully they will match each other as perfectly as their versions do;-)
GTK+ on Windows suffers from a lack of developers and consistantly contains bugs that are *very* annoying. I doubt that WxWigets bound to GTK+ would sove anything. However, WxWidgets might make it easier to target "native" toolkits on several platforms (win32, GTK+, QT and OSX. Also, the last time I installed a GTK app, the WIMP theme could definitely be improved.
Some X protocol round trip reduction improvements have made it to this release, so if you've been frustrated by a gnome program over an ssh session taking 30 seconds to start (I sure have!) then 2.6 will probably speed things up.
I would like to know if 2.6 has finally brought 2.x up to the performance of 1.2 (or maybe even better?).
On Solaris I still build most applications with GTK+ 1.2.x because I've found 2.4.x to be significantly slower, even without AA fonts, and all of the pretty eyecandy. Doing the same thing as 1.2, it seems that 2.4 is just plain slower.
Bah, no bindings for Fortran. It would be nice to see a decent open-source GUI toolkit for Fortran; a front end does wonders for the ability of PHBs to appreciate a piece of code.
Fortran didn't have dynamic memory allocation before F90, so GTK bindings are probably impossible until GCC 4.0.
What, and Fortran 90 has been around for *how* long? The fact that gcc does not support Fortran 90/95/2003 is no reason why bindings could not have been created for *other* vendors' compilers.
Nope, try again, QT isn't opensource! Stick with GTK and try GTKmm as the parent said, it's the only way to stay within the GPL.
So, what you are saying is: to stay within the GPL, you should the LGPL:ed GTK+ instead of the GPL:ed Qt. This makes no sense to me at all. Could it be that you don't have a damn clue about what you are talking about?
It didn't look like a troll. 3[?] years on there are still a huge number of people who don't use KDE because of all the FUD from the debian people about it. This really needs to be sorted.
I just spent the past day rebuilding fontconfig, libiconv, libintl, etc. to get pango to build on Mac OS X. This is painful. darwinports and fink are both helpful but not enough. Still don't have it building. Any slashdot gnome wizards want to take a whack at this one?
Hey thanks for the advice! Just gave it a shot, waiting for the compile to finish.
Get the same result for both pango 1.4.0 and 1.6.0. When you say that dependent libs need the same CFLAGS, would this mean I should recompile xft2 and glib then with the flags you mention?
Curious what -fPIC does.
Doubtless, slashdot isn't the optimal forum for this discussion, do you know of a GNOME-OSX mailing list anywhere by any chance?
On Windows, if you type a sequence of characters quickly in a list control (such as in a file dialog) the focus jumps to an item that begins with those letters. Will GTK every implement that?
Also, is there is a way to change the standard file dialog without recompiling everything? I want to set my own custom file dialog.
It is possible to modify your file dialog without recompiling everything every time. You do need to recompile everything once. Make sure you get the source for the exact same version you have, and compile it all to get the.o files.
After that, make your changes to gtk-file-selector.c and make libgtk-x11-2.whatever, then copy that file into/usr/lib or wherever your gtk lives. You should probably back up your old version first.
Check out this selector [chello.nl] before you start implementing your own. You may find
I don't think you understood the question you answered. I'm pretty sure that KidSock wanted to know if it is possible to implement custom file dialogs on a per application basis and also different dialogs within a single application, not changing the core Gtk file selector for everything, which seems to be what you are suggesting.
As much as I hated programming in MFC (Windows C++ toolkit), this was definitely doable there, if poorly documented. This should be possible in Gtk, I would hope. A quick Google s
GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites.
GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development.
GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. GTK+ is the only 100% free-of-cost open source industrial-strength GUI toolkit available today.
Since its origins as the toolkit for the GNU Image Manipulation Program (GIMP), GTK+ has been used in a wide range of software. Notably, GTK+ is the foundation of the GNOME desktop; GTK+ 2.6 will be incorporated into version 2.10 of the GNOME desktop.
Click the word that you didn't understand, "GTK," in the article. It was convieniently made into a link for people like you who don't know what it is. The text on this linked page is nice enough to start out with a concise description of what GTK is, and gets into more detail if you care to learn more. Here's an example: "GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off projects
Besides, for well established major packages like GTK there's Google. Heck, you don't even need to click the link as what GTK is, is in the link summary.:-p
As many other posts have pointed out, GTK is widely used and very flexible GUI toolkit. It has great C and Perl bindings and has been used in a few of my applications.
But, it's SLOW. If you're used to Xaw3D or even Motif, you'll find GTK to be slow. Applications built against GTK 1.2 aren't too bad on semi-modern hardware. A Pentium 3 500 MHz or a 300 MHz UltraSPARC II can run such applications with ease. It'll be a tad sluggish on a Pentium 233 MMX or a 170 MHz UltraSPARC I.
I think it's pango. It allows you to do all lots of nice effects, antialiasing, and really nice i18n. However, the price for that is being very slow. Sometimes I wish they'd make a ascii only version that ran very fast, but I realise that's being a bit selfish.
Why tell people what something is? Very simple, to attract potential users.
Take your sig for example... someone who doesn't know what it is most likely going to say "Firefox? What is that? Why should I get it?" Yes, they could go to the webpage and inquire for themselves, but that takes effort, and many (including Slashdot readers) like a brief summery that helps them decide if they will click on the link to learn more.
What's a sig? You shouldn't use specialized terms like that in a forum where not everyone will understand it, or if you do you should explain what they mean. For example:
Take your sig (your "sig", short for "signature", is a short, sometimes funny, sometimes self-descriptive bit of text which you can enter on your user preferences page, and which is appended to each and every comment you post) for example...
That's how you should have responded. But no. You'd almost
And when you do know what GTK is, you probably know about the release because your distro's package manager tells you or because you are tracking the source and saw the release announcement on gtk.org or via mailing list before it was posted on Slashdot.
There's no reason to post this kind of crap on the front page. There are partner sites dedicated to software releases that do a much better job of explaining them, and some people actually do come here for the news, which often gets lost due to tinfoil-h
Asshole mods. Actually, I think the monkey got it right. This kind of news IS "stuff that matters". After all, why else would anyone be reading Slashdot other than the articles about computer related (with a free/open bent) technologies and software? If you aren't reading for that reason, then you're in the wrong place. That's why I've devoted my JEs to discussing technology/software/asking linux related questions, etc... Oh yeah, and the occasional dig at Slashdot and trolling.
Mine takes about 24 hours for a complete rebuild of every package in the system from scratch, which is pretty amazing. Hell, it takes me almost that long to compile just the Kernel on my Netwinder.
I always do wxPyhton for cross platform. Even if you give GTK a theme that looks mostly like native, some aspects of the look and feel simply won't be addressed by theming... wxWidgets is a truly underrated approach to cross-platform native applications...
The difference between Wimp and other GTK engines is that it uses the windows GUI engine to draw most things, so they are identical to the native windows controls. It does a better job of this in Windows XP than in previous versions, though. Wimp still causes quite a bit of pain in Windows 98.
As for wxPython, I've switched away from that to pyGTK, for a couple of reasons. First, the stable version of Wx uses a really ancient version of GTK on unix. Second, I really disliked the API. I have heard that it is similar in style to MFC, and if that is the case, I'm glad I've been able to stay away from Windows-only programming as long as I have.
This is a known issue in Firefox, has to do with the not so graceful way that it renders malformed code. But since IE renders it properly, and everyone knows that designing IE-only is ok, it won't be changed. I'm not certain if the Firefox team will feel compelled to alter their program in order to render bad code more like IE does. Try this however, hold CTRL and then scroll your mouse wheel up and then back down. That will make two adjustments to the size of text on the page, and will fix the problem. (If
QT ist simply the better API, and the GUI it creates is much more flexible and convenient. The file selection dialog is a very good example: the file chooser in GTK is close to unusable, and makes me want to hit the developers whenever i am forced to use it (no, i have not yet tried the noew one). KDE's file selector is very nice and uses the same components as Konqueror does. The same thing is true for almost all the GUI components, including menus.
That is precicely the problem: Using C to implement a GUI-API is simply brain dead. C is for the kernel, for drivers, for heavy duty calculations like cryptography, etc. For a graphical user inteface, an object oriented language is the way to go.
Wrapping a procedural API into objects does not really help, at least not if you do not re-implement half the concepts. A good (bad) example for this the the abominable MFC.
Altough C is not an OO language, it can be used in an OO way. And this is exactly what GObject, the object system upon which GTK+ is built provides; GTK+ has an OO API, not a procedural one, despite it's written in C. Wrapping this in C++ (or another OO language) is relatively straightforward; you get a nicer syntax, but the concepts stay the same.
I've always wondered about that... would it be legal for somebody to take the Qt/X11 code or the Qt/Mac code and make a GLP'd Qt/Win version? If Qt/X11 and Qt/Mac are GPL one would think it should be legal, anyhow.
Not that it would be easy, or any more necessary than the Windows port of GTK+ (which is nice sometimes but certainly not necessary to have a running Windows system), just possible.
They're improving the file dialogs... (Score:4, Interesting)
BTW, does anyone knows if GTK supports the Composite render extension available on X.ORG? Or perhaps it has nothing to do with it and doesn't need it? I tried enabling compositing on XFCE 4.2rc2, and while the desktop looked MUCH better (with true transparency, window shadows and the works), it slowed my system to a crawl.
Re:They're improving the file dialogs... (Score:2, Informative)
There's a planned port of the Kdrive acceleration architecture that'll make it much easier to accelerate it with other drivers.
Re:They're improving the file dialogs... (Score:2)
Yes, i'm aware. I'm running the latest binary drivers from nVidia, and even "experimental" extensions like XRenderAccel desktop works just fine, and gives a nice speed boost to my desktop. OpenGL renders great as well, but for some reason, Composite + XFCE work awfully slow, like it's working on software mode. I though perhap
Re:They're improving the file dialogs... (Score:5, Interesting)
Also of note is that I have one graphics card driving two monitors, and it's still not an issue.
Don't be afraid to try Composite on Xorg! And if you run into problems submit bug reports! Xorg has great promise. Let's all help to make it as good as it could be (and no I'm in no way related to the Xorg project. I just think eye-candy is where its at).
Re:They're improving the file dialogs... (Score:2)
I've been following the project closely, and i think it's becoming to be all that XFree should've been by now.
Re:They're improving the file dialogs... (Score:2)
Re:They're improving the file dialogs... (Score:2)
I don't think it was. The way I understand the Composite extension, all windows draw to an off-screen buffer, which the compositing manager displays. When using the a compositing manager, you don't have to ask the client applications to redraw themselves when exposed by moving a window, so moving windows should be considerably less CPU/network/context switch intensive.
Re:They're improving the file dialogs... (Score:3, Informative)
Option "RenderAccel" "true"
Then run "xcompmgr -c" on the active $DISPLAY while X is running (unless your window manager du jour has built-in composite support) and you're ready to go.
Re:They're improving the file dialogs... (Score:2, Insightful)
Then you have the RENDER extension hardware accellerated, and RENDER is used to compose and draw the transparent bitmaps.
Some X.org OSS drivers also have accellerated render, not as good as nvidias though.
(ATI's driver sucks
Re:They're improving the file dialogs... (Score:3, Informative)
try joining xorg on freenode. The channel topic says it sall "composite is slow, we know".
now, don't get me wrong. I love what the composite extension can do; But don't go getting people's hopes up, "ooh, my 900Mhz celeron proc with a 32 meg graphics card will look just like my dads powerbook" cuz it ain't gonna happen.
Re:They're improving the file dialogs... (Score:3, Informative)
Assumption that all graphic hardware manufacturers have binary drivers for the current stable Xorg release which allow for translucency and shadows to work is incorrect.
Affects: Many, if not all ATI cards and Xorg >= 6.8.0
Workaround: harass the hell out of ATI [ati.com]
Re:They're improving the file dialogs... (Score:2)
What I've never understood is why, in newer releases, they don't provide the filechooser with a backwards-compatible link library so that the older programs will at least interface with the operating system somewhat like newer programs. Something like an LD_PRELOAD that we could do so that every application doesn't wind up with it's own file chooser.
That's the big problem w/ many Linux apps -- they are all their own beast. To
Re:They're improving the file dialogs... (Score:2)
Re:They're improving the file dialogs... (Score:2)
Otherwise, I imagine RedHat and others would have more consistency between apps.
Re:They're improving the file dialogs... (Score:2)
Better keyboard control would be nice too; that they added typeahead support is a bless and well welcome.
Re:They're improving the file dialogs... (Score:2)
Re:They're improving the file dialogs... (Score:3, Insightful)
Like i said earlier, it's just a matter of polish. Generally speaking, i like the new file dialog.
Re:They're improving the file dialogs... (Score:3, Informative)
A lot of people agree with you. [url:http://bugzilla.gnome.org/show_bug.cgi?id=13 6 541] The gtk2.4 filechooser was a big mistake. I have no idea if this is fixed in 2.6. It really should be since people have been bitching about this dialog the moment it was placed in wide release.
Re:They're improving the file dialogs... (Score:2)
Re:They're improving the file dialogs... (Score:3, Interesting)
They're improving the file dialogs...Keys. (Score:3, Informative)
Control+L
Really? (Score:2)
Still, I'd rather have the old tab-based method back. It's familiar, damn it. And it seemed more... keyboard-centric instead of mouse-centric, which I like. This is like it's been put in for old codgers like me, to shut us all up. (I'm sorry, but CTRL-L?!) And not for actual usage.
I forget who it was that said that a single mouse move and click (including time to move hands from the keyboard) was worth up to eighteen keystrokes in time. Perhaps that's a bit much, but I will lament the slow passing
Re:They're improving the file dialogs... (Score:2)
Re:They're improving the file dialogs... (Score:2)
Don't forget Qt. I've enjoyed beautiful file dialogs in KDE for as long as I can remember....
GTK's only redeeming trait, near as I can tell, is that the Unix version of wxWidgets uses it.
Re:They're improving the file dialogs... (Score:2)
Well just because something is gratis and has liberal licenses doesn't give it an execuse for incompetence. Many of these useability problems have been well researched and fixed years ago. There's no point in rediscovering all these advances. The new toolkits should just use them. T
Re:They're improving the file dialogs... (Score:2)
Well just because something is gratis and has liberal licenses doesn't give it an execuse for incompetence. Many of these useability problems have been well researched and fixed years ago.
Aha, but you see, GNOME suffers from a terminal case of Not Invented Here. In fact, anything touched by the GNU must be completely rewritten, or thrown away and a new component written from the ground up. So they have to relearn all the hard lessons the rest of us learned 14 years ago.
*sigh* The sad thing is, this ne
Re:They're improving the file dialogs... (Score:2)
How is the window manager going to change the way an application handles menus and similar things? The window manager deals with the window borders around the application and placement of windows and not with the stuff the application displays within a window.
Ideally both the graphics toolkit and the window manager need to support the xorg extensions to get the best results.
Re:They're improving the file dialogs... (Score:2, Informative)
Re:They're improving the file dialogs... (Score:2)
I love Gnome and GTK (Score:4, Interesting)
Beat Microsoft at its own
Re:I love Gnome and GTK (Score:2)
I love gtk+/GNOME, but Mono is idiotic. Microsoft will not let it stand, should it ever become a threat.
Re:I love Gnome and GTK (Score:5, Interesting)
Linux _desperately_ needs to have a working, easy to use RAD environment. Something as simple, or simpler than Visual Basic. I want to be able to create a simple Linux application by dragging and dropping some form elements onto a page and double clicking on a button and typing a few lines of simple code and have it all working.
Glade is good, but it's not easy enough.
Mono has the possibility of bringing this to fruition. I want to see sharpdevelop making good GTK# apps in a few hours.
Re:I love Gnome and GTK (Score:2, Interesting)
GTK/Gnome is more 'difficult'** up front but reduces the work by the programmer when it comes to resizing a window. Windows is 'easier' up front but makes the programmer painfully aware of the location of widgets after the fact (windo
Re:I love Gnome and GTK (Score:2, Interesting)
"I haven't coded anything for Windows in a few years, so things may have changed with .Net and WinForms (?) in the meantime."
Not really. WinForms has a sensible class structure and generally cleaner design than MFC, but basic positioning is still considered more or less absolute.
Where I work we have bought and external toolkit (Syncfusion) which offers layout managers and then we just use gridbadlayout just like most Java developers do. Syncfusion would integrate nicely into the Windows Form designer
Re:I love Gnome and GTK (Score:2)
Already there. (Score:2)
I think that the KDevelop IDE [kdevelop.org] already allows for true RAD in Python and Ruby (with an embedded GUI designer that ties into the editor functions), but if you want a VB workalike without the VB idiosyncrasies, give Gambas [sourceforge.net] a go. It's about to reach 1.0, and seems to work really darn well, from what testing I've subjected it to.
Re:I love Gnome and GTK (Score:2)
The sad part is, 99.9% of the Linux development community holds you in the utmost contempt, or at the very best, doesn't understand your needs.
Thanks!! (Score:5, Informative)
Currently GTK is one of my favorite toolkits. The reason: Pango. I use multiple languages in my documents, as well as the compose button, and all GTK apps handle it perfectly (I use utf-8 of course). And although the input methods are somewhat redundant architecture that should be lower than the level of the toolkit IMHO, GTK input methods are the best, especially when combined with UIM.
Thank again to all the people involved.
BTW: is there a keyboard shortcut to switching input methods. UIM has it, but I sometimes need to switch to cyrillic translit (can not use ru phonetic since the keyboard is in dvorak) from Chinese and back, and that is a bit painful?
Re: Thanks!! (Score:3, Insightful)
> Currently GTK is one of my favorite toolkits. The reason: Pango. I use multiple languages in my documents
I just recently discovered that GTK+ with Pango has cool monolingual uses as well, since it supports a simple markup language that lets you very easily do things to the text in your menus, buttons, etc., such as italicize, sub- or superscript, etc.
Google for "pango markup language" for more info.
Re:Thanks!! (Score:2)
GTK is what makes my desktop go. I love it. Nice job, folks.
A lot of stuff in Gtk is replacing Gnome widgets.. (Score:4, Informative)
Re:A lot of stuff in Gtk is replacing Gnome widget (Score:2)
Re:A lot of stuff in Gtk is replacing Gnome widget (Score:2)
mwa ha ha ha
Re:A lot of stuff in Gtk is replacing Gnome widget (Score:2)
Re:A lot of stuff in Gtk is replacing Gnome widget (Score:2)
At any rate, I think toolkit libraries should be able to load and unload different segments into memory like modules in the kernel. If your application needs a calendar widget, it makes a call to load the specific component Toolkit::Calendar and then checks to see if it loaded Toolkit::Calendar properly. The most likely cause of an error would be Toolkit::Calendar not being part of Toolkit's installation on the system.
A mechanism to automatically re
Re:A lot of stuff in Gtk is replacing Gnome widget (Score:2)
The situation you'd worry about would be taking a new laptop to the moon--if you've been using it for a while then all the extensions you need should have been asked for and retrieved beforehand.
Re:A lot of stuff in Gtk is replacing Gnome widget (Score:2)
Re:A lot of stuff in Gtk is replacing Gnome widget (Score:2)
Moreover, I wonder what the drivers are for moving these things back into Gtk if they're already present in the Gnome stuff.
My assumption is that the parts being moved aren't really Gnome-specific. Applications that want to use those dialogs would have to include libgnome and libgnomeui, which are only available under Linux and very tied into the GNOME environment. For instance, an application which wanted to use a standardized About dialog would have to include the GNOME libraries. This moves it into G
Re:A lot of stuff in Gtk is replacing Gnome widget (Score:4, Informative)
Re:A lot of stuff in Gtk is replacing Gnome widget (Score:2, Informative)
The fact that they haven't changed the name is misleading, but all the base GNOME libraries are available.
A new GTK release (Score:3, Insightful)
GTK != Grand Theft Potassium (Score:3, Funny)
Move along, nothing to see here.
Re:GTK != Grand Theft Potassium (Score:2, Funny)
Re:GTK != Grand Theft Potassium (Score:3, Funny)
Will it work with wxwidgets? (Score:2)
Re:Will it work with wxwidgets? (Score:2, Informative)
Re:Will it work with wxwidgets? (Score:2)
i use it with 2.4 with gtk2
but you can run it with gtk1.2 too
Re:Will it work with wxwidgets? (Score:2)
Pretty release notes for spoiled developers please (Score:2)
Good. (Score:2)
Speed improvements (Score:3, Interesting)
how much of a speed boost? (Score:2)
On Solaris I still build most applications with GTK+ 1.2.x because I've found 2.4.x to be significantly slower, even without AA fonts, and all of the pretty eyecandy. Doing the same thing as 1.2, it seems that 2.4 is just plain slower.
Fortran? (Score:3, Funny)
Re:Fortran? (Score:2)
Fortran didn't have dynamic memory allocation before F90, so GTK bindings are probably impossible until GCC 4.0.
What, and Fortran 90 has been around for *how* long? The fact that gcc does not support Fortran 90/95/2003 is no reason why bindings could not have been created for *other* vendors' compilers.
No matter how hard C is, gtk/glib is impressive. (Score:4, Insightful)
Re:No matter how hard C is, gtk/glib is impressive (Score:2)
Nope, try again, QT isn't opensource! Stick with GTK and try GTKmm as the parent said, it's the only way to stay within the GPL.
So, what you are saying is: to stay within the GPL, you should the LGPL:ed GTK+ instead of the GPL:ed Qt. This makes no sense to me at all. Could it be that you don't have a damn clue about what you are talking about?
Re:No matter how hard C is, gtk/glib is impressive (Score:2)
Re:No matter how hard C is, gtk/glib is impressive (Score:3, Interesting)
Indeed. It's a very nice implementation, and much cleaner than the underlying GTK+ interface. I'm surprised that it isn't used more widely than it is.
Type in the path!!! (Score:2, Insightful)
building pango is a b*tch on Mac OS X (Score:2)
I just spent the past day rebuilding fontconfig, libiconv, libintl, etc. to get pango to build on Mac OS X. This is painful. darwinports and fink are both helpful but not enough. Still don't have it building. Any slashdot gnome wizards want to take a whack at this one?
creating libpangox-1.0.la
(cd
gcc -dynamiclib -o
Re:building pango is a b*tch on Mac OS X (Score:2)
Get the same result for both pango 1.4.0 and 1.6.0. When you say that dependent libs need the same CFLAGS, would this mean I should recompile xft2 and glib then with the flags you mention?
Curious what -fPIC does.
Doubtless, slashdot isn't the optimal forum for this discussion, do you know of a GNOME-OSX mailing list anywhere by any chance?
Two Questions (Score:4, Interesting)
Also, is there is a way to change the standard file dialog without recompiling everything? I want to set my own custom file dialog.
Re:Two Questions (Score:2)
After that, make your changes to gtk-file-selector.c and make libgtk-x11-2.whatever, then copy that file into /usr/lib or wherever your gtk lives. You should probably back up your old version first.
Check out this selector [chello.nl] before you start implementing your own. You may find
Re:Two Questions (Score:2)
As much as I hated programming in MFC (Windows C++ toolkit), this was definitely doable there, if poorly documented. This should be possible in Gtk, I would hope. A quick Google s
Re:GTK? (Score:4, Informative)
GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites.
GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development.
GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. GTK+ is the
only 100% free-of-cost open source industrial-strength GUI toolkit available today.
Since its origins as the toolkit for the GNU Image
Manipulation Program (GIMP), GTK+ has been used in a wide range of software. Notably, GTK+ is the foundation of the GNOME desktop; GTK+ 2.6 will be incorporated into version 2.10 of the GNOME desktop.
Re:GTK? (Score:2, Interesting)
Re:GTK? (Score:3, Informative)
Click the word that you didn't understand, "GTK," in the article. It was convieniently made into a link for people like you who don't know what it is. The text on this linked page is nice enough to start out with a concise description of what GTK is, and gets into more detail if you care to learn more. Here's an example: "GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off projects
Re:GTK? (Score:2, Insightful)
A sad day it will be when we actually need to explain what GTK is on Slashdot. Hopefully, this day has not arrived yet.
(Sorry about the rant, but I just had to. I guess posts like the parent are the sign of the times... :-\ )
Re:GTK? (Score:2)
Re:GTK? (Score:2)
GTK is.... well... SLOW! (Score:2)
But, it's SLOW. If you're used to Xaw3D or even Motif, you'll find GTK to be slow. Applications built against GTK 1.2 aren't too bad on semi-modern hardware. A Pentium 3 500 MHz or a 300 MHz UltraSPARC II can run such applications with ease. It'll be a tad sluggish on a Pentium 233 MMX or a 170 MHz UltraSPARC I.
I'm looking forward to trying
Re:GTK is.... well... SLOW! (Score:2)
Re:GTK? (Score:3, Insightful)
Take your sig for example... someone who doesn't know what it is most likely going to say "Firefox? What is that? Why should I get it?" Yes, they could go to the webpage and inquire for themselves, but that takes effort, and many (including Slashdot readers) like a brief summery that helps them decide if they will click on the link to learn more.
Re:GTK? (Score:2)
What's a sig? You shouldn't use specialized terms like that in a forum where not everyone will understand it, or if you do you should explain what they mean. For example:
That's how you should have responded. But no. You'd almost
Re:GTK? (Score:2)
There's no reason to post this kind of crap on the front page. There are partner sites dedicated to software releases that do a much better job of explaining them, and some people actually do come here for the news, which often gets lost due to tinfoil-h
Re:Priorities, priorities (Score:3, Insightful)
These Gentoo compilation jokes are so damn funny.. (Score:2, Funny)
(Moderators, please stop modding those up, they've been old for ages.)
Re:But I run Gentoo! (Score:2, Funny)
Not a troll! Re:But I run Gentoo! (Score:2)
Re:Not a troll! Re:But I run Gentoo! (Score:2)
Re:But I run Gentoo! (Score:2)
Of course, your favourite binary distro releases it without spending any compilation time... or any testing/management time for that matter...
Re:Better for windows users now (Score:2)
Re:Better for windows users now (Score:4, Interesting)
Re:Unrelated to story: (Score:2)
Re:Unrelated to story: (Score:2)
Re:Unrelated to story: (Score:2)
It was annoying the heck out of me too...
PCB$#
Re:QT GTK (Score:2, Flamebait)
Re:QT GTK (Score:2)
That is precicely the problem: Using C to implement a GUI-API is simply brain dead. C is for the kernel, for drivers, for heavy duty calculations like cryptography, etc. For a graphical user inteface, an object oriented language is the way to go.
Wrapping a procedural API into objects does not really help, at least not if you do not re-implement half the concepts. A good (bad) example for this the the abominable MFC.
Re:QT GTK (Score:2, Insightful)
Altough C is not an OO language, it can be used in an OO way. And this is exactly what GObject, the object system upon which GTK+ is built provides; GTK+ has an OO API, not a procedural one, despite it's written in C. Wrapping this in C++ (or another OO language) is relatively straightforward; you get a nicer syntax, but the concepts stay the same.
Re:only Qt/X11 and Qt/Mac are GPL'd (Score:2, Interesting)
Not that it would be easy, or any more necessary than the Windows port of GTK+ (which is nice sometimes but certainly not necessary to have a running Windows system), just possible.