Submitted by “Yesterday, I got Qt running on top of the Glib main loop. By using the QAbstractEventDispatcher API, I was able to completely replace the entire event dispatching mechanism of a Qt 4 application with less than 600 lines of code. What does this mean?”
It would be so much simpler to integrate using multithreading rather than forcing glib and Qt applications in to the same thread.
The problem with that solution, is that X is not thread safe.
The problem with that solution, is that X is not thread safe.
Oh my. In this day in age of multi-core someone should get on that quick! …or will moving all the processing to the videocard solvethis as a side-effect?
> Oh my. In this day in age of multi-core someone should
> get on that quick! …or will moving all the processing
> to the videocard solvethis as a side-effect?
X is lot more than graphics. I don’t think X needs to be thread-safe, only one thread should do event processing and painting anyway. This doesn’t mean that you couldn’t use threads in X programs, you can have separate thread for processing data or whatever but only one thread can do the X stuff.
Even if the GLIB/GTK and Qt had their own connections to the server? It is the connection that cannot be shared. Xlib is perfectly threadsafe.
The problem with that solution, is that X is not thread safe
And what does that have to do with the main loop ?!!!
AFAIK, X is irrelevant to the main loop, and so irrelevant to the problem here.
This is great! I am really glad to see all this integration work. First a KDE frontend for beagle and now integration of the glib main loop into KDE.
As far as I understand this, this would make it possible to use gtk/gnome plugins in KDE applications and the other way round. Just imagine that all the plugins from gimp could be used in digikam/krita and the plugins from digikam/krita could be used in gimp. Of course it would require a lot of work to actually make this working and the projects would have to use a common plugin API, but I think the possibility is very nice.
And, as far as I understand, that would in prinicple also make it possible to use kparts in gtk/gnome applications and gparts (which don’t exist yet) in KDE applications. A lightwight khtml-based webbrowser for gnome (it could just use the konqueror-kpart) would definitifely be a good idea.
I hope that this really will be used in future Qt releases.
Edited 2006-02-25 17:46
The equivalent of Kparts for GNOME is libbonobo(ui) or ORBIT. Most developers today acknowledge the COM fad is over and won’t use such frameworks unless there’s compelling reason to do so.
There’s one other alternative that’s closer to Kparts that depends on the main loop integration:
http://gparts.blogspot.com/
http://pvanhoof.be/blog/index.php/2005/12/08/gparts-and-a-shared-ma…
You mean most gnome developers have given up on COM
KDE folks still love and use kparts. I think gnome’s COM failure had more to do with idealogical reasons then technical.
I’m about to cry from happiness.
Now, let KDE and Gnome developers step up on common VFS layer (where both KDE and Gnome would provide plugins for that) too and world will be perfect.
> I’m about to cry from happiness.
>
> Now, let KDE and Gnome developers step up on common VFS > layer (where both KDE and Gnome would provide plugins
> for that) too and world will be perfect.
And while they’re at it, hopefully they will do it with FUSE so that kio_slaves and such can be used by every program, not just specially written KDE programs.
And while they’re at it, hopefully they will do it with FUSE
There shouldn’t be a problem to write a FUSE module that accesses the VFS infrastructure to provide access to programs that can not access the VFS layer directly.
For KIO, i.e. mounting KDE IO slaves, a developer has created a proof of concept FUSE module called fuse_kio http://kde.ground.cz/tiki-index.php?page=KIO+Fuse+Gateway
FUSE is Linux-only, GNOME and KDE are not.
Normally i don’t respond like this-but this time I can’t help it….
Then it is high time for Solaris and BSD’lers to get together with the FUSE guys and work out something which allows for a common way of desktop applications tying into the archictecture specific respective VFS’s.
GNOME has it’s own VFS, just as KDE does. The Linux kernel has it’s own VFS which with the exception of FUSE bears virtually no relation to Desktop VFS’s-FUSE enables a certain degree of transparency from desktop applications all the way down to kernel files resources.
Although I do not know the specifics of the Solaris VFS or that of the BSD’s, what I do know is that our desktop environments need a common way of facilitating desktop application access to kernel resources-on each and all of these platforms. If work was done to implement a set of common libraries which would expose native VFS resources masking the specific architecture differences(remember the needs of a desktop VFS are not identical with that which POSIX semantics provide at the command line/system library level) then GNOME and KDE (and other DE’s too) could start to actively promote and implement rich VFS integration on a level beyond what is currently avaialbe.
Much work has been done to define the scope of a potential desktop VFS-a common desktop VFS which is DE agnostic. Up till now we have had a rather harsh divide between comand line/system library VFS(via POSIX) and desktop application VFS integration. KIO slave went a long way to amerliorate this within the KDE environment. FUSE now offers tremendous comand line/system library VFS integration for Linux. KIO slaves and FUSE is a role model of what desktop application VFS integration should look like. Solaris and the BSD’s need some kind of similiar interface…
—-(Linux)kernel—(linux)VFS—-Fuse—-Desktop Environment
—-(Solaris)kernel—(Solaris)VFS—-???—-Desktop Environment.
—-(BSD)kernel—(BSD)VFS—-???—-Desktop Environment.
I want to give my hats off to Trolltech. They essentially threw out some of their own code and replaced it with integration with some from the GTK+ camp with a big win for everyone.
I think this is exactly the kind of KDE/GNOME integration we users will love to see. The day when a developer doesn’t have to say, “Shit, I can’t use KParts because this is a GTK+ app” and likewise the day a KDE developer doesn’t have to say “Shit, I can’t use Gnome-VFS because this is a QT app.” Developers will now be able to pick the best of breed from both camps, which will ultimately snowball into unifying the layers higher up. A great day for us users and developers indeed.
Yay!