View previous topic :: View next topic |
Author |
Message |
radhakrishna n00b
Joined: 14 Apr 2007 Posts: 34 Location: Mysore, India
|
Posted: Sat May 05, 2007 4:54 am Post subject: gtk apps looks in KDE |
|
|
I am using KDE and have installed many gtk apps.. Obviously the gtk GUI is crap by default in KDE though it looks better in gnome.
i want to use qt-gtk engine package in Gentoo. I couldnt find in portage.. What do i do? _________________ AMD Athlon Xp, nVidia Geforce MX, 512MB RAM |
|
Back to top |
|
|
mark_alec Bodhisattva
Joined: 11 Sep 2004 Posts: 6066 Location: Melbourne, Australia
|
Posted: Sat May 05, 2007 5:14 am Post subject: |
|
|
emerge gtk-engines-qt _________________ www.gentoo.org.au || #gentoo-au |
|
Back to top |
|
|
radhakrishna n00b
Joined: 14 Apr 2007 Posts: 34 Location: Mysore, India
|
Posted: Sat May 05, 2007 5:22 am Post subject: |
|
|
oh Thank you... That was too stoopid of me _________________ AMD Athlon Xp, nVidia Geforce MX, 512MB RAM |
|
Back to top |
|
|
widremann Veteran
Joined: 14 Mar 2005 Posts: 1314
|
Posted: Sat May 05, 2007 3:02 pm Post subject: |
|
|
Use gtk-chtheme and pick a nice GTK theme. gtk-qt crap is awful. It never gets the Qt themes right and to be honest, GTK apps are designed to use a Qt theme. So don't use a Qt theme! |
|
Back to top |
|
|
shaumux Veteran
Joined: 13 May 2005 Posts: 1009 Location: Hong Kong
|
Posted: Sun May 06, 2007 3:30 am Post subject: |
|
|
Well the engine works fine for me. |
|
Back to top |
|
|
165177 Apprentice
Joined: 27 Apr 2007 Posts: 156
|
Posted: Sun May 06, 2007 10:17 am Post subject: |
|
|
widremann wrote: | Use gtk-chtheme and pick a nice GTK theme. gtk-qt crap is awful. It never gets the Qt themes right and to be honest, GTK apps are designed to use a Qt theme. So don't use a Qt theme! |
On my system gtk-qt works fine. Using the baghira qt theme, Gtk applications almost look like Qt applications (apart from different menus and sometimes different icons). |
|
Back to top |
|
|
yngwin Retired Dev
Joined: 19 Dec 2002 Posts: 4572 Location: Suzhou, China
|
Posted: Sun May 06, 2007 11:12 am Post subject: |
|
|
I use gtk-engines-qtcurve in combination with qtcurve for KDE. It's wonderful! _________________ "Those who deny freedom to others deserve it not for themselves." - Abraham Lincoln
Free Culture | Defective by Design | EFF |
|
Back to top |
|
|
pteppic l33t
Joined: 28 Nov 2005 Posts: 781
|
Posted: Sun May 06, 2007 2:24 pm Post subject: |
|
|
yngwin wrote: | I use gtk-engines-qtcurve in combination with qtcurve for KDE. It's wonderful! |
X2, most of the time, I still have to double click in the file dialogs, grrr... |
|
Back to top |
|
|
Galahad Tux's lil' helper
Joined: 12 Feb 2003 Posts: 126
|
Posted: Sun May 06, 2007 7:48 pm Post subject: |
|
|
Be aware that gtk-qt is not as dependable as other gtk engines.
It is known to cause app crashes in certain versions. |
|
Back to top |
|
|
Clete2 Guru
Joined: 09 Aug 2003 Posts: 530 Location: Bloomington, Illinois
|
Posted: Sat Nov 03, 2007 3:50 pm Post subject: |
|
|
I emerged gtk-engines-qt, but I can't find directions on how to begin using it. I restarted Firefox and it looks just as ugly as it looked before. _________________ My Blog |
|
Back to top |
|
|
i92guboj Bodhisattva
Joined: 30 Nov 2004 Posts: 10315 Location: Córdoba (Spain)
|
Posted: Sat Nov 03, 2007 3:57 pm Post subject: |
|
|
While gtk-engines-qt is an ugly hack, gtk-engines-qtcurve + qtcurve is a native combination that:
1.- looks really the same, not just similar
2.- is native, so it performs better
The theme is very configurable, at least, enough for me. Your mileage may vary, of course.
If you use kde, you have kcontrol. So, I still suggest you to install gtk-engines-qt, because, besides being useless as a theme engine, it adds a new tab on kcontrol where you can pick the theme you will be using in gtk applications (font included). Make sure you select the gtk native qtcurve on that list, and not the emulation via gtk-engines-qt.
You can also directly edit your ~/.gtkrc-2.0 file to set the theme as QtCurve. |
|
Back to top |
|
|
165177 Apprentice
Joined: 27 Apr 2007 Posts: 156
|
Posted: Sun Nov 04, 2007 1:16 pm Post subject: |
|
|
i92guboj wrote: | While gtk-engines-qt is an ugly hack |
Why? Afaik this engine just makes qt calls to paint the gtk surface... what's so ugly about this?
Quote: | 2.- is native, so it performs better |
So why is gtk-engines-qt not native? It's just a different toolkit used to perform painting operations, there should not be a significant loss in performance... |
|
Back to top |
|
|
i92guboj Bodhisattva
Joined: 30 Nov 2004 Posts: 10315 Location: Córdoba (Spain)
|
Posted: Sun Nov 04, 2007 1:28 pm Post subject: |
|
|
lunar wrote: | i92guboj wrote: | While gtk-engines-qt is an ugly hack |
Why? Afaik this engine just makes qt calls to paint the gtk surface... what's so ugly about this?
|
Just look at it. It doesn't always render ok everything.
In which regards coding, you are using a tookit to emulate another. This creates some issues, for example, not everything in tookit A is reproducible in the toolkit B. And vice-versa. It is always to run native if possible. Note that this is not just like using bindings, it translates the calls in the way it things it is the most accurate one, but that doesn't mean a thing... Not to talk that with every revision of any of both toolkits there can be an ABI change that will break gtk-engines-qt for and add a nice segfault probability to every program using gtk-engines-qtcurve to render the interface.
Anyway, as stated above, no need to go techie on this: just open your eyes and look. It is getting better, but it clearly can't compare to a native thing like qtcurve.
I haven't measure the performance at all, and can't talk about that. To speak about that I would have to know exactly how gtk-engines-qt renders the interface to know exactly how the two tookits are involved. I don't know how that is done in this concrete case. But native solutions are just better if you ask me. I am not saying that gtk-engines-qt is crap or something like that: I think it is great. But if I can choose, I choose to use native engines for each toolkit.
I just explained the option I think is better. Now, it is up to the original poster to decide which solution fits better his/her needs. |
|
Back to top |
|
|
165177 Apprentice
Joined: 27 Apr 2007 Posts: 156
|
Posted: Sun Nov 04, 2007 1:50 pm Post subject: |
|
|
i92guboj wrote: | lunar wrote: | i92guboj wrote: | While gtk-engines-qt is an ugly hack |
Why? Afaik this engine just makes qt calls to paint the gtk surface... what's so ugly about this?
|
In which regards coding, you are using a tookit to emulate another. This creates some issues, for example, not everything in tookit A is reproducible in the toolkit B. |
Thats the only critics about this engine, but the devs have been working hard to overcome it, and they did a good job. This engine is absolutely suitable for daily-use. As long as there is not gtk equivalent for baghira, I will use this engine, as it never caused great trouble on my systems.
Quote: | Not to talk that with every revision of any of both toolkits there can be an ABI change that will break gtk-engines-qt for and add a nice segfault probability to every program using gtk-engines-qtcurve to render the interface. |
ABI stability is an important part of release policy in KDE and Qt. All releases of KDE 3.5 tree share the same ABI (as do all releases of Qt 3.3). I can't talk about gtk, as I don't know anything about this project, but considering the fact, that gtk is used by many commercial vendors, the developers will clearly focus on ABI stability, to not break with proprietary applications. I don't think, that ABI instability is an important issue with gtk-engines-qt and I never had any such problems during my years-long use of this engine.
Quote: | I haven't measure the performance at all, and can't talk about that. |
Why did you do it then? |
|
Back to top |
|
|
i92guboj Bodhisattva
Joined: 30 Nov 2004 Posts: 10315 Location: Córdoba (Spain)
|
Posted: Sun Nov 04, 2007 2:48 pm Post subject: |
|
|
lunar wrote: |
Quote: | I haven't measure the performance at all, and can't talk about that. |
Why did you do it then? |
I did not talk about performance as in "how does it perform". I just said it has some issues in which regards the look, and it is certainly an overhead. To what degree... that is another question, and that is the one I can't speak about.
About the ABI, I know that ABI changes in kde are not that usual (but they are not impossible, I think that an slight ABI change could be possible from 4.0 to 4.1, for example). I can't talk about gtk for the same reason: I know nothing about gtk and/or gnome. |
|
Back to top |
|
|
165177 Apprentice
Joined: 27 Apr 2007 Posts: 156
|
Posted: Fri Nov 09, 2007 6:07 pm Post subject: |
|
|
i92guboj wrote: | lunar wrote: |
Quote: | I haven't measure the performance at all, and can't talk about that. |
Why did you do it then? |
I did not talk about performance as in "how does it perform". I just said it has some issues in which regards the look, and it is certainly an overhead. To what degree... that is another question, and that is the one I can't speak about. |
Ok, then I missunderstood you.
Quote: |
About the ABI, I know that ABI changes in kde are not that usual (but they are not impossible, I think that an slight ABI change could be possible from 4.0 to 4.1, for example). |
Things are different with kde 4.x. That's a brand-new major release with lots of API changes... it will take some time, until all APIs and frameworks are finally stable, and even more time until the last KDE application is ported. But the KDE 3.x series should be stable and mature with both API and ABI. |
|
Back to top |
|
|
i92guboj Bodhisattva
Joined: 30 Nov 2004 Posts: 10315 Location: Córdoba (Spain)
|
Posted: Fri Nov 09, 2007 6:57 pm Post subject: |
|
|
lunar wrote: | i92guboj wrote: | lunar wrote: |
Quote: | I haven't measure the performance at all, and can't talk about that. |
Why did you do it then? |
I did not talk about performance as in "how does it perform". I just said it has some issues in which regards the look, and it is certainly an overhead. To what degree... that is another question, and that is the one I can't speak about. |
Ok, then I missunderstood you.
Quote: |
About the ABI, I know that ABI changes in kde are not that usual (but they are not impossible, I think that an slight ABI change could be possible from 4.0 to 4.1, for example). |
Things are different with kde 4.x. That's a brand-new major release with lots of API changes... it will take some time, until all APIs and frameworks are finally stable, and even more time until the last KDE application is ported. But the KDE 3.x series should be stable and mature with both API and ABI. |
I know the step towards kde4 is not trivial, and I understand that there is an abi change in the middle. It is impossible to keep compatiblity, cause to start with, qt4 and qt3 are not compatible either.
I am talking about a possibility of abi breaking between 4.0 and 4.1, that is not a major release, and it is not that far, by the way. kde 4.0 is just one month away.
Kde3.x will still be the choice for many, though. And in that regard you are right, the ABI for kde3 will probably not move any more. It will still last long, since kde4.0 might not be stable enough to do real work with it (and I hope I am wrong). |
|
Back to top |
|
|
165177 Apprentice
Joined: 27 Apr 2007 Posts: 156
|
Posted: Fri Nov 09, 2007 7:16 pm Post subject: |
|
|
i92guboj wrote: | Quote: |
About the ABI, I know that ABI changes in kde are not that usual (but they are not impossible, I think that an slight ABI change could be possible from 4.0 to 4.1, for example). |
Things are different with kde 4.x. That's a brand-new major release with lots of API changes... it will take some time, until all APIs and frameworks are finally stable, and even more time until the last KDE application is ported. But the KDE 3.x series should be stable and mature with both API and ABI. |
I am talking about a possibility of abi breaking between 4.0 and 4.1, that is not a major release, and it is not that far, by the way. kde 4.0 is just one month away.[/quote]
I know, what you're talking about. What I was trying to tell you, is that ABI changes during the first few KDE 4.x release are not only possible, but very likely to happen. The step from KDE 3.x to 4.x changed so many things, that even in the upcoming 4.0 release not all frameworks are freezed. As far as I understood Quasar (the new framework for graphical effects) and solid are still subject to changes and not finished before 4.1. Moreover there are many applications in the KDE tree, that still only partly use the new frameworks. For instance, not all KDE PIM apps (kaddressbook, kmail, korganizer, etc.) have been ported to akonadi yet.
KDE 4.x ist just a much too great step to be taken with just one release. I think, KDE 4.x won't be completely finished and polished before 4.2.. (just my personal evaluation of kde development).[/quote]
Quote: | Kde3.x will still be the choice for many, though. And in that regard you are right, the ABI for kde3 will probably not move any more. It will still last long, since kde4.0 might not be stable enough to do real work with it (and I hope I am wrong). |
Even if KDE 4.0 is completely stable, I think, I'll wait for 4.1. 4.0 just brings the basic frameworks, there is still many work to with porting all the applications out there to kde 4.0. Especially if you're using many 3rd party apps (like I do), kde 4.0 won't be of much use, since it will take some time until 3rd party apps are completely ported. |
|
Back to top |
|
|
i92guboj Bodhisattva
Joined: 30 Nov 2004 Posts: 10315 Location: Córdoba (Spain)
|
Posted: Fri Nov 09, 2007 7:29 pm Post subject: |
|
|
Nice. Now that you and I share the same point of view about kde4, for what I read above, you understand why my point about abi breaking is a concern, though not the main one.
Of course, that will only be a thing to worry about if gtk-engines-qt is ever ported to draw the interface using qt4. |
|
Back to top |
|
|
165177 Apprentice
Joined: 27 Apr 2007 Posts: 156
|
Posted: Fri Nov 09, 2007 7:40 pm Post subject: |
|
|
Quote: | Of course, that will only be a thing to worry about if gtk-engines-qt is ever ported to draw the interface using qt4. |
I definitely hope, this happens If firefox, emacs, wireshark, gajim, inkscape and a bunch of other little gtk applications and tools were ported to Qt 4/KDE 4, all my problems with gtk would be solved: I could simply unmerge it ... But really, this is somehow unlikely to ever happen, so I'm dependent on gtk-engines-qt or my desktop becomes what my desk already is: a total mess |
|
Back to top |
|
|
widremann Veteran
Joined: 14 Mar 2005 Posts: 1314
|
Posted: Sun Nov 11, 2007 1:54 am Post subject: |
|
|
It's amazing that after more than three years, they still can't match even basic things in the KDE themes. It's more worth your time to get and tweak a nice GTK+ theme that mess with this worthless engine. My favorite problem is how the menu text is still black even though the selected text color is too dark. It works for menu items, just not the menu headers themselves. Spacing is off. It's vomitorious. |
|
Back to top |
|
|
asturm Developer
Joined: 05 Apr 2007 Posts: 8956
|
Posted: Sun Mar 23, 2008 12:15 am Post subject: |
|
|
How about: gtk-kde4? |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|