It seems that not only a new CVS module
is created to foster all those nice web development tools in KDE, but also anew website has been registered for this purpose.

Not too long ago we covered the announcement of version 1.0 ofKimDaBa and now KimDaba 1.1
has been released. This new version includes lots of new features plus a large amount of optimizations, which makes it useful for image sets with even tens of thousands of images. Try the KimDaba Feature Overview Tour for a quick overview of features.

Comments

The QT-GTK approach is for me a bright hack, but wouldn't be a better solution to have a proper Qt engine, a proper GTK engine, and some common THEMES definitions (in XML, s-expressions (simpler, better I think) or whatever floats your boat) ?

Thus, Gnome has a pure GTK desktop, KDE has a pure Qt/KDElibs desktop, whatever other widget set can use it and themers can use whatever they like and produce just themes that will render identical on each platform, only differing in the underlying technology ?

freedesktop could be using it as a specification, not an implementation.

Is there something (besides "just do it") that i'm missing ? Sure, you wouldn't have the complete set of features, but couldn't a common denominator be found ?

Good luck on getting everybody to agree on something. I think Qt-GTK theme engine is a good idea (and works well from my experience). It doesn't resolve the integration issues but it solves a lot of the look 'n feel ones (besides things such as icons, etc.). If it's shown that GTK+ apps can integrate better in the KDE environment than KDE apps in a GNOME environment (since both have their winning applications, although KDE is replacing them with each release) then perhaps vendors/distributors/users will all get on the KDE bandwagon.

I think Qt-GTK is a much better approach as it doesn't require yet another redesign of the theming engine, or two identical themes (like Bluecurve).

Qt-GTK is one piece of the puzzle leading to desktop unification. It allows GTK applications to look native under KDE. If we could have them use the same icons, we'd be almost there.

Add to this the proposed migration of GNOME to the DCOP-based DBUS in the future and the talks about migrating from aRts (which I've never really liked) to GStreamer, the unified Qt/GTK event loop allowing GTK apps to use KDE's dialogues, and the fact that KPrinter is available to all apps, and in the future there will be one desktop (KDE), and a choice between Qt and GTK as toolkits.

I see this as a positive thing. People who want to develop proprietary apps using Qt (with all the advantages this brings) will pay for a license, and those who are more stingy can use GTK. The user doesn't see a problem.

It all somewhat makes sense until you say in the future there will be one desktop. Are you the one who is going to decide?

Many of the advantages of Qt can and will be made irrelevant by Mono anyway. I thnk a common theme spec more solves the problem than this hack anyway. A theme spec can be used by everyone, including toolkits like Fox, wxWindows, FLTK and so on.

One little change to GTK could render the hack useless. See what happens to Qt on the Mac. They have to update the look for each new version of OSX. If they implemented the proper stuff, there would not be this problem.

Besides, part of the look and feel is in the other stuff like spacing of words in Menus and so on. How do you proposed to get that fixed.

"Many of the advantages of Qt can and will be made irrelevant by Mono anyway."

Funny! Mono is years away from being a complete environment that can be used. Qt is here now. There are also many issues regarding the use of an Intermediate Runtime that Microsoft are just starting to face - Qt is natively compiled. Mono, as a whole, is fairly pointless.

"A theme spec can be used by everyone, including toolkits like Fox, wxWindows, FLTK and so on."

It takes more than a theme spec. There have to be equivalent decisions made for each toolkit - radio buttons, file dialogues etc.

"One little change to GTK could render the hack useless."

Not really. GTK isn't going to change completely overnight.

"See what happens to Qt on the Mac. They have to update the look for each new version of OSX. If they implemented the proper stuff, there would not be this problem."

Well the Mac environment is closed, and Qt is a cross-platform toolkit, so look-and-feel issues are bound to happen. KDE is different from Qt.

"Besides, part of the look and feel is in the other stuff like spacing of words in Menus and so on. How do you proposed to get that fixed."

> Besides, part of the look and feel is in the other stuff like spacing of
> words in Menus and so on. How do you proposed to get that fixed.

bad example. TT has introduced style hints for menu spacing in Qt 3.3. here's a better example: part of the look 'n feel is the ordering of buttons on dialogs. UNIX used to be relatively consistent in this regard until the GNOME usability people decided in all their wisdom to switch the order of the buttons. the usability win is absolutely non-existent in practice and now we have a NEW inconsistency that is much harder to reconcile. it was a completely unreasonable change on their part, but now we have to deal with it. and themes aren't able to fix it.

a common set of UI guidelines would, but the chances of that happening are as good as me becoming the next King of Neptune. and that's not for a lack of trying (the UI guidelines, not setting up a new monarchy on the outer planets), but for a lack of interest. there was interest on the KDE side; Tink (i think.. or was it Lauri? eek!) even did a bunch of work prepping KDE materials. =(

Mmm. That's quite interesting Aaron. Any other development on this front regarding look and feel with Qt 3.3? I actually have it compiled and up and running with KDE 3.2 now :). The only problem I seem to have had was some bizarre KMenu spacing issues.

"UNIX used to be relatively consistent in this regard until the GNOME usability people decided in all their wisdom to switch the order of the buttons. the usability win is absolutely non-existent in practice and now we have a NEW inconsistency that is much harder to reconcile. it was a completely unreasonable change on their part, but now we have to deal with it. and themes aren't able to fix it."

Well, I'm afraid that is Gnome's problem. I think QtGTK is a good idea but no one can go completely re-engineering Gnome apps and other Gnome specific stuff to get this working. No one has to deal with it, although I get the impression that people at Suse have to find some way of integrating with Ximian and their tools. I think this will hurt them to be honest. Some people around Gnome wanted a way to try and attack KDE, and look and feel and usability seemed good ways to do it. I agree that themes aren't able to fix all this, but then that may have been the point :).

Switching the order of buttons and inheriting a lot of Mac specific stuff has doomed Gnome to failure. You put that down in front of an average business computer user and they will run a mile.

It hasn't been done because no one's ever done it. As simple as that. I do not see any insurmountable obstacles to writing a common theme format. However there are still many obstacles to overcome.

1) A widget style is 99% detail. Qt provides control over a different set of details than GTK+. While there is a lot of overlap, there are a lot of points that are going to be hard to reconcile. You can get two themes that are significantly similar, but they won't be pixel-to-pixel identical.

2) A theme "definition" pretty much limits the theme to non-programmatic drawing. In other words, pixmap-based styles only. While easy to create, and allowing non-programmers to create styles, they have significant drawbacks over style "engines".

3) A common style engine necessitates a common API. You would need two separate theme engines for both GTK+ and Qt that exported this API, so the same plugin style would work for both. The disadvantage is that you now have a new API to learn. The non-programmer would not be able to create a new style.

This would be *really* hard to do. There are two ways you could get a common theme format without involving code:

- Vector graphics UI: The problem with this is two fold. First, until we get FD.O and its OpenGL-accelerated Cairo goodness, a vector-based UI will be slow. Second, resolutions are not yet high enough that we can go completely vector-based. Therefore, we'd need some sort of delta-hinting mechanism like TrueType has, to do pixel-accurate adjustments. The whole spec would be very complex, and themes would get a lot more complex to write.

- Pixmap-based UI: The problem with this is also two-fold. First, pixmaps themes are slow and wasteful of memory. Second, they are very limiting --- you can alter the look easily, but the behavior is pretty tightly constrainted to what's in the spec.

Kimdaba:I remeber Dos-Formatprogramms and floppy copy programs. They disappeared. Today it is simply intergrated in your operating system. Same applies for Kimdaba, K3B ecc. Do we really need specialized applications?
Modular programming: given the fact that programs die what parts can be provided by kimdaba that may be useful without the application such as image filters?

Scribus: Like other qt apps such as Hbasic they always look a bit outdated as the qt engine is slightly different from KDE. What can be done to improve qt-KDE integration? given the fact that the gap is closed between GTK and qt.

Since I've never played Quake (not even sure I've ever seen it being played), I have no idea what Kuake does. Something to do with the window size or something along those lines? Can somebody explain to the non-gamers out here?

This is probably the first time I have found my non-english keyboard to have an advantage (apart from being able to type non-english characters, of course ;-)). On my keyboard, the key under esc is "§", which of course is almost useless. :-)

I've added a package to Mandrake cooker contrib for Kuake, that includes this patch.
Someone (with an account) may wish to a entry for Kuake to kde-apps.org.
Does anyone know if there is cvs repo for kuake?

Generally yes, but with some clarification:
- kdewebdev/quanta contains less than the old "quanta", as some programs were moved to the first level of kdewebdev. So get the whole kdewebdev if you want what the quanta module was before
- the old quanta module is still alive, but only holds the 3.2.x versions (thus it's the "stable" Quanta).

kdewebdev is the development branch which can currently be run on KDE 3.1x and up. Stable branches, as Andras said, remain in the quanta module.

What you see as Quanta includes kommander as well as Kommander dialogs (quick Start, TemplateMagic, XML tools, etc...) and also KFileReplace, KXSL Debug and more. Of that kdewebdev/quanta only includes the Kommander dialogs, not the executor or editor.

kdewebdev has been a restructuring so that separate applications like KImageMapEditor are separate programs in the module, and they also function as kpart plug ins with Quanta. It seemed better organized and more consistent with KDE. Now if you want to get just one of the apps like Kommander or Quanta it's easier to do.

I hope this helps. BTW there are some very cool additions going on in Kommander lately too!

There's two answers to that... (assuming you meant programs as the whole package is a CVS module)

1) Yes other programs will be added as we encounter or build programs that make sense here. For instance we recently added KImageMapEditor. If there is a really good KDE program we don't know about please tell me.

Seriously, Quanta does a lot of things most people aren't aware of and most of what is not in there is not in there because we don't have enough sleep deprived fingers and eyeballs... but if you think it's really missing something say so and maybe someone will be inspired to help us build it.

Here is a perl script that does something similar to kuake, except that it uses konsole. It shows/hides a konsole window at the top of the screen.
Go to kmenuedit, add an entry called something like ShowHideKonsole, which executes this perl script as the command, and bind it to whatever key you like 9all within kmenuedit).
Now you have a popup konsole, i.e. tabs etc.

Nice hack. I like it! However, on my desktop when I hit the short cut for that Perl script, I get an ugly taskbar entry with the Name of the menu item. Unfortunately it doesn't disappear when the program has finished, but only after it times out (30 seconds or so). Any idea on fixing that?

I heard it draws to a pixmap using Qt then blits it onto a gtk widget...

Wouldn´t it be faster to write a QPaintDevice that draws into a gdk graphic context? It would be somewhat harder (and it is one of the few areas of Qt that is not well documented) but it is not impossible.

The current way (if that is how it´s done :-) uses more memory and should be more awkward.