Qt->glib main event loop patch (common main loop)

[nf2]

Hi!

I have rewritten my Qt->glib main event loop patch completely. It adds
an optional "-glibmainloop" switch to the ./configure script of Qt,
which integrates a modified QEventloop as a GSource into glib main loop.

http://www.scheinwelt.at/~norbertf/common_main_loop/

I have tested lots of KDE applications with the patched Qt, including
the whole KDE desktop. Seems to work quite well.

Additionally there is the "QtGtk Crossover Demo", which runs both
toolkits (Qt and GTK+) in the same process and the same main loop
(without blocking each other).

The main benefit of joining the mainloops would be
* common asynchronous infrastructure libraries
* in-process plugins or components (like having desktop adaptive
file-dialogs).
* linking with libraries which were developed for other toolkits

Btw - I'm not sure if other frameworks have already been ported to
glib-main-loop, like OpenOffice.org (UNO?) and Mozilla...

regards,

Norbert

[Michael Pyne]

Post by nf2
Hi!
I have rewritten my Qt->glib main event loop patch completely. It adds
an optional "-glibmainloop" switch to the ./configure script of Qt,
which integrates a modified QEventloop as a GSource into glib main loop.
http://www.scheinwelt.at/~norbertf/common_main_loop/
I have tested lots of KDE applications with the patched Qt, including
the whole KDE desktop. Seems to work quite well.

I don't have time to test the patch, but the work seems very interesting, at
least from a technical perspective.

I'll admit that I don't see many (real-world) benefits yet, except perhaps for
sharing KIO between KDE and GTK but perhaps you'll dazzle us with something
whiz-tastic or something.

Regards,
- Michael Pyne

[nf2]

Post by Michael Pyne

Post by nf2
Hi!
I have rewritten my Qt->glib main event loop patch completely. It adds
an optional "-glibmainloop" switch to the ./configure script of Qt,
which integrates a modified QEventloop as a GSource into glib main loop.
http://www.scheinwelt.at/~norbertf/common_main_loop/
I have tested lots of KDE applications with the patched Qt, including
the whole KDE desktop. Seems to work quite well.

I don't have time to test the patch, but the work seems very interesting, at
least from a technical perspective.
I'll admit that I don't see many (real-world) benefits yet, except perhaps for
sharing KIO between KDE and GTK but perhaps you'll dazzle us with something
whiz-tastic or something.
Regards,
- Michael Pyne

I think a common-main-loop would solve several problems of the free
desktop. Two use cases:

A) generic desktop adapter library

My favorite is "libdesktop-adapter", which exposes a standardized set of
desktop-features:

* file-dialogs
* vfs (simple features like download and upload file)
* ...

Applications load the appropriate desktop-adapter with dlopen(),
depending on the desktop they are running in.

libdadapt-kde-1.0.so
libdadapt-gnome-1.0.so

Therefore applications like OpenOffice.org, Mozilla, The Gimp,... would
automatically use KDE Filechoosers and KIO on KDE, Gnome-Filechooser and
Gnome-VFS on Gnome,...

"libdesktop-adapter" would create two classes of applications:

1) desktop specific apps: like konqueror, nautilus,... which link to
Filechoosers, VFS libraries directly.
2) Cross-desktop applications, which use the desktop-adapter libraries
to integrate well with any desktop, no matter which GUI-Toolkit they use.


B) GParts

Another interesting project which would benefit from a common main loop,
is GParts (http://gparts.blogspot.com/).
Dmitry M. Shatrov gave me some demo-code which worked well with the
patched Qt. One example embeds KTHML into a Gtk+ window. I put a
screenshot here: http://www.scheinwelt.at/~norbertf/common_main_loop/


Norbert

[Leo Savernik]

Post by nf2
http://www.scheinwelt.at/~norbertf/common_main_loop/

Does it link against glib?

[Martijn Klingens]

Post by Leo Savernik

Post by nf2
http://www.scheinwelt.at/~norbertf/common_main_loop/

Does it link against glib?

Does it matter?

[Aaron J. Seigo]

Post by Martijn Klingens

Post by Leo Savernik

Post by nf2
http://www.scheinwelt.at/~norbertf/common_main_loop/

Does it link against glib?

Does it matter?

what matters IMHO would be (in random order):

what are the performance implications?
memory usage?
start speed?
runtime speed?

would trolltech be interested in adjusting the event loop in this way?
(otherwise, why bother?)

is this cross platform? it seems from a glance at the patch that the answer is
'no', meaning that this would be UNIX (and, furthermore, X11 due to calls
like XPending) specific and not have the same properties on other platforms.
which then begs the question: is that desirable?

is it binary compatible? e.g. can a binary built against a glib-event-loop qt
run against a vanilla qt and vice versa? looking at the patch it seems so,
but figured i should ask anyways.

will this work as well with Qt4 as it is with Qt3? (otherwise, why bother?)
this includes being able to support all the event loop related features in
Qt4 (important for things like thread-specific event loops).

[nf2]

Post by Aaron J. Seigo

Post by Martijn Klingens

Post by Leo Savernik

Post by nf2
http://www.scheinwelt.at/~norbertf/common_main_loop/

Does it link against glib?

Does it matter?

what are the performance implications?
memory usage?
start speed?
runtime speed?

I think this question can be answered by looking at the glib main loop
code.

http://cvs.gnome.org/viewcvs/glib/glib/gmain.c

In fact, glib main loop is nothing but a more sophisticated poll
statement, which calls back prepare() before polling the
filedescriptors, and check() and dispatch() afterwards. Considering
there is only one mainloop per thread, the memory-usage is negligible.

Post by Aaron J. Seigo
would trolltech be interested in adjusting the event loop in this way?
(otherwise, why bother?)

it would be very helpful if they were interested, but they don't have to
be. it's free software. there are not that many versions of Qt, and the
QEventloop code hardly ever changes. therefore patching could be an
acceptable solution (for the beginning). It seems Qt gets patched quite
a lot. I can see almost 50 patches in the source RPM (mandriva).

Post by Aaron J. Seigo
is this cross platform? it seems from a glance at the patch that the answer is
'no', meaning that this would be UNIX (and, furthermore, X11 due to calls
like XPending) specific and not have the same properties on other platforms.
which then begs the question: is that desirable?

That's because QEventloop code is not cross-platform and not free of GUI
related code (at least in Qt3). in fact the ./configure decides, which
source-files are used for QEventloop. Secondly, the "common main loop"
is only required for the "free desktop" (unix/x11).

btw: glib main loop is free of graphical toolkit stuff and is cross
platform. its only dependency is glibc (on unix).

Post by Aaron J. Seigo
is it binary compatible? e.g. can a binary built against a glib-event-loop qt
run against a vanilla qt and vice versa? looking at the patch it seems so,
but figured i should ask anyways.

yes. i think so. i'm adding public methods to the QEventloop class, but
they are just for internal use (cause i can't call private methods from
C). i haven't recompiled my KDE, and with the patched Qt it's still running.

Post by Aaron J. Seigo
will this work as well with Qt4 as it is with Qt3? (otherwise, why bother?)
this includes being able to support all the event loop related features in
Qt4 (important for things like thread-specific event loops).

i think that's the most important question. the next thing to have a
look at is Qt4. i started with Qt3, because i thought it would be a nice
proof of concept to see the whole KDE running with the patch.

glib main loop has supported thread specific event loops forever (i
think it has been designed to be multi-context) - therefore i would
expect that a port is possible.

if anyone could help me with this undertaking or point me to the right
people at trolltech i would be glad.

norbert

[Leo Savernik]

Post by nf2
That's because QEventloop code is not cross-platform and not free of GUI
related code (at least in Qt3). in fact the ./configure decides, which
source-files are used for QEventloop. Secondly, the "common main loop"
is only required for the "free desktop" (unix/x11).

Qt3 is past. Qt4 is the future. While developing new features against Qt3 may
be nice for a case study, you shouldn't make any assumptions before you
haven't gathered information with Qt4.

Then, the question still stands: Does it link against glib (hard, not
dlopened, i. e. will all KDE applications be penalized by loading additional
code which adds nothing to the proper functioning of KDE and using up
additional memory)?
If it does, what was the answer of the gnome project when you suggested to
base their glib onto QtCore?

Post by nf2
A) generic desktop adapter library
My favorite is "libdesktop-adapter", which exposes a standardized set of
* file-dialogs
* vfs (simple features like download and upload file)
* ...
Applications load the appropriate desktop-adapter with dlopen(),
depending on the desktop they are running in.
libdadapt-kde-1.0.so
libdadapt-gnome-1.0.so

The only use-case for your proposal seems to be interoperability between
different toolkits. Hence, from an architectural point of view, it is not
viable to change each toolkit itself, but implement the functionality in
higher layers. The proposed libadapt-*-*.so would be perfectly suitable for
such a purpose, plugging into the respective event loop on an as-needed
basis.

I again suggest that you look into the event loop infrastructure Qt4 provides
before attempting to changing the toolkit core.

mfg
Leo

[Kevin Krammer]

Post by Leo Savernik

Post by nf2
That's because QEventloop code is not cross-platform and not free of GUI
related code (at least in Qt3). in fact the ./configure decides, which
source-files are used for QEventloop. Secondly, the "common main loop"
is only required for the "free desktop" (unix/x11).

Qt3 is past. Qt4 is the future. While developing new features against Qt3
may be nice for a case study, you shouldn't make any assumptions before you
haven't gathered information with Qt4.

Unless it's one of those local space-time distortions again, it is likely that
most KDE users will not have the benefit of using a Qt4 based KDE for about a
year.
Which means any progress in Qt3 integration is still an advantage and should
not be turned down by us lucky few.

Cheers,
Kevin

[Nicolas Goutte]

Post by Kevin Krammer

Post by Leo Savernik

Post by nf2
That's because QEventloop code is not cross-platform and not free of
GUI related code (at least in Qt3). in fact the ./configure decides,
which source-files are used for QEventloop. Secondly, the "common main
loop" is only required for the "free desktop" (unix/x11).

Qt3 is past. Qt4 is the future. While developing new features against Qt3
may be nice for a case study, you shouldn't make any assumptions before
you haven't gathered information with Qt4.

Unless it's one of those local space-time distortions again, it is likely
that most KDE users will not have the benefit of using a Qt4 based KDE for
about a year.
Which means any progress in Qt3 integration is still an advantage and
should not be turned down by us lucky few.

Just the problem is that any "improvement" of Qt3 will not fit into KDE3, as
there will not be any further development version of KDE3.

Post by Kevin Krammer
Cheers,
Kevin

Have a nice day!

[Kevin Krammer]

Post by Nicolas Goutte

Post by Kevin Krammer

Post by Leo Savernik

Post by nf2
That's because QEventloop code is not cross-platform and not free of
GUI related code (at least in Qt3). in fact the ./configure decides,
which source-files are used for QEventloop. Secondly, the "common
main loop" is only required for the "free desktop" (unix/x11).

Qt3 is past. Qt4 is the future. While developing new features against
Qt3 may be nice for a case study, you shouldn't make any assumptions
before you haven't gathered information with Qt4.

Unless it's one of those local space-time distortions again, it is likely
that most KDE users will not have the benefit of using a Qt4 based KDE
for about a year.
Which means any progress in Qt3 integration is still an advantage and
should not be turned down by us lucky few.

Just the problem is that any "improvement" of Qt3 will not fit into KDE3,
as there will not be any further development version of KDE3.

There will be no new features in KDE3, true. But this doesn't mean that
distributors can't ship an extended Qt3 or adapter libraries enabling Gtk+
applications to to use KDE3's already implemented features.

Or to write KDE3 compatible plugins using those improvements.

Cheers,
Kevin

[Nicolas Goutte]

Post by Kevin Krammer

Post by Nicolas Goutte

Post by Kevin Krammer

Post by Leo Savernik

Post by nf2
That's because QEventloop code is not cross-platform and not free
of GUI related code (at least in Qt3). in fact the ./configure
decides, which source-files are used for QEventloop. Secondly, the
"common main loop" is only required for the "free desktop"
(unix/x11).

Qt3 is past. Qt4 is the future. While developing new features against
Qt3 may be nice for a case study, you shouldn't make any assumptions
before you haven't gathered information with Qt4.

Unless it's one of those local space-time distortions again, it is
likely that most KDE users will not have the benefit of using a Qt4
based KDE for about a year.
Which means any progress in Qt3 integration is still an advantage and
should not be turned down by us lucky few.

Just the problem is that any "improvement" of Qt3 will not fit into KDE3,
as there will not be any further development version of KDE3.

There will be no new features in KDE3, true. But this doesn't mean that
distributors can't ship an extended Qt3 or adapter libraries enabling Gtk+
applications to to use KDE3's already implemented features.
Or to write KDE3 compatible plugins using those improvements.

So you suppose that KDE would not need any modification, dont't you?

Post by Kevin Krammer
Cheers,
Kevin

[Kevin Krammer]

Post by Nicolas Goutte
So you suppose that KDE would not need any modification, dont't you?

Yes, that's how I understood it.
Based on the assumption that KDE applications use the Qt event loop and do not
use a special subclass.

I think Norbert posted to this list because KDE is the biggest Qt "user" on
Unix and most likely interested in allowing better integration of "foreign"
apps with KDE

Cheers,
Kevin

[David Johnson]

Post by nf2
if anyone could help me with this undertaking or point me to the
right people at trolltech i would be glad.

Could someone explain to me the benefits of this? What is wrong with the
Qt event loop that it must be replaced with the GTK+ event loop? What
am I missing here? What does the commonality give us?

There needs to be sufficient reason to do this before dumping yet
another dependency upon the packagers and users.

[Martin Konold]

Am Samstag, 12. November 2005 03:46 schrieb David Johnson:

Hi,

Post by David Johnson
There needs to be sufficient reason to do this before dumping yet
another dependency upon the packagers and users.

IMHO this Qt->glib main event loop integration is the wrong approach to the
problem.

What about Java, Mono,......

This is simply not going to work.

IMHO Rudi is the better, more generic, more robust and most flexible approach.

Regards,
-- martin

[Cornelius Schumacher]

Post by Martin Konold
IMHO Rudi is the better, more generic, more robust and most flexible approach.

How can you embed a KPart in a GTK program with Rudi?

[Martin Konold]

Am Samstag, 12. November 2005 19:07 schrieb Cornelius Schumacher:

Hi,

Post by Cornelius Schumacher

Post by Martin Konold
IMHO Rudi is the better, more generic, more robust and most flexible approach.

How can you embed a KPart in a GTK program with Rudi?

Yes, provied that GTK supports RuDI. Though the proposed event loop patch will
not provide this functionality.

Last but not least embedding was not the topic and the main aspect of Rudi is
not about embedding but about plain using of desktop services like file
dialogs, printing, telephone integration, io slaves, icon loading,....

Regards,
-- martin

[Aaron J. Seigo]

Post by Martin Konold
Last but not least embedding was not the topic and the main aspect of Rudi
is not about embedding but about plain using of desktop services like file
dialogs, printing, telephone integration, io slaves, icon loading,....

which is far, far more useful and important than embedding whole application
components IMHO.

[Gary Greene]

Post by Martin Konold
Hi,

Post by Cornelius Schumacher

Post by Martin Konold
IMHO Rudi is the better, more generic, more robust and most flexible approach.

How can you embed a KPart in a GTK program with Rudi?

Yes, provied that GTK supports RuDI. Though the proposed event loop patch
will not provide this functionality.
Last but not least embedding was not the topic and the main aspect of Rudi
is not about embedding but about plain using of desktop services like file
dialogs, printing, telephone integration, io slaves, icon loading,....
Regards,
-- martin

If you re-read nf2's post on this, apparently it DOES allow Gtk+ apps to use
KParts. I quote:

B) GParts
Another interesting project which would benefit from a common main loop,
is GParts (http://gparts.blogspot.com/).
Dmitry M. Shatrov gave me some demo-code which worked well with the
patched Qt. One example embeds KTHML into a Gtk+ window. I put a
screenshot here: http://www.scheinwelt.at/~norbertf/common_main_loop/
--
Gary L. Greene, Jr.
Sent from uriel
2:32pm up 0:11, 2 users, load average: 1.24, 1.22, 0.85

============================================================
Developer and Project Lead for PhoeNUX OS.
check out http://www.phoenuxos.com/ for more info.
EMAIL : ***@phoenuxos.com
============================================================

[Matthias Ettrich]

On Saturday 12 November 2005 20:36, Gary Greene wrote:
[...]

Post by nf2
B) GParts
Another interesting project which would benefit from a common main loop,
is GParts (http://gparts.blogspot.com/).
Dmitry M. Shatrov gave me some demo-code which worked well with the
patched Qt. One example embeds KTHML into a Gtk+ window. I put a
screenshot here: http://www.scheinwelt.at/~norbertf/common_main_loop/

You can do that without patching Qt, and definitely without having all of KDE
depend on Glib, even in Qt 3.

Qt's event loop is flexible enough (even in Qt 3) to hook a Glib event loop
into it. One of the issues I had last time I did this was that Glib didn't
give me the information when the next Glib timer was supposed to fire. You
need that to set the proper timeout for the select statement. I remember
having patched Glib to provide that. My patch didn't get in, but I do
remember that Havoc told me in newer versions everything I needed should be
available.

I also suggested at one point to develop a common event loop abstraction for
Unix C/C++ toolkits. A small, self-contained library that every toolkit can
use. Basically a glorified select() abstraction.This wasn't met with much
enthusiasm, more with "glib is exactly that". And so is QtCore, and Xt :-)

What we then did in Qt 4 is making out abstraction even more open and simpler
to enhance. We use this ourselves when integrating with e.g. Eclipse (which
on Unix is SWT/Gtk+, in other words Glib), or Motif (which is the Xt event
looop). Instead of making Qt work with Glib, why not patch Gtk to use Xt,
then both Qt and Gtk can use the standard Xt loop? Qt supports this with it's
Motif extension.

The Unix desktop is a mess.

Matthias

[David Johnson]

Post by Matthias Ettrich
The Unix desktop is a mess.

That's because we have all this inconvenient freedom and choice getting
in the way.

:-)

[Aaron J. Seigo]

Post by David Johnson

Post by Matthias Ettrich
The Unix desktop is a mess.

That's because we have all this inconvenient freedom and choice getting
in the way.

there needs to be a ballance struck, however.

freedom and choice is good until it becomes an excuse to not cooperate on
issues that are so obviously in everyone's best interests to do so. likewise
i see it used as an excuse to not touch the underlying OS more than
absolutely necessary.

i personally used to be of the opinion that we *couldn't* do much below the
desktop layer so everything must be fixed above it.

over the last couple of years i've slowly swayed to thinking that we can't
afford NOT to reach down further into the stack and get our hands dirty with
things lower in the OS stack. this includes hardware integration, X
improvements, etc. i think Trolltech is taking a nice lead here with some of
their investments. we (the KDE project) ought IMHO to be a bit more
aggressive with these things as well, though. RUDI is one possible step,
Kevin's hardware layer that he's been working on for KDE4 is another
important step, plasma's use of newer X.org features will be another.

this is getting a bit off topic from event loops, but i think the event loop
issue is an interesting triviality that we ought to Just Fix (but smartly,
not stupidly) and move on with.

[David Johnson]

Post by Aaron J. Seigo

Post by David Johnson
That's because we have all this inconvenient freedom and choice
getting in the way.

there needs to be a ballance struck, however.

There is no reason to compromise on freedom.

The only reason I use Unix and KDE is because of the freedom. If it
weren't for that I would have switched to Mac OSX long ago. This
freedom should not go away just because you are not a
wet-behind-the-ears newbie fresh from Windows. The same freedom must be
given to developers.

I don't want a desktop where everyone dresses the same, eats the same
food, and sends their kids to the same schools. I've seen that desktop,
and it's called Windows. In case you haven't heard, it's sucks. Nearly
every Windows component is good, the problem is higher up. The problem
is that it's been integraged into a "one size fits all" solution that
manages to please no one.

Freedom takes more effort than tyranny, but that's no excuse to give up
on freedom.

[Aaron J. Seigo]

Post by David Johnson

Post by Aaron J. Seigo

Post by David Johnson
That's because we have all this inconvenient freedom and choice
getting in the way.

there needs to be a ballance struck, however.

There is no reason to compromise on freedom.

as long as we don't confuse "freedom" for "a lack of direction is OK".
unfortunately, that's exactly where it has currently led us (and not just
KDE). we have in the past used "freedom" as a friendly word that is hard for
people to argue against (who wants to be anti-freedom?) when what we really
mean is "we are inable to make decisions" or "it's ok not to serve our user's
needs because at least this way we aren't making any demands whatsover on any
system outside of KDE".

we offer, and will continue to offer, lots on the freedom front. and if we
want to continue making this whole "free software desktop" a viable concept,
we will need to at some point start saying things like "no, a 5 year old X
server is not good enough" or "yes, you DO need kernel hooks to let us know
when things are plugged into the machine" or "no, it isn't ok to have N event
loop implementations because that's just stupid" or "here's a way to get your
app to use our file dialog (and vice versa) and everyone should use it"

[Michael Pyne]

Post by Aaron J. Seigo

Post by David Johnson

Post by Aaron J. Seigo

Post by David Johnson
That's because we have all this inconvenient freedom and choice
getting in the way.

there needs to be a ballance struck, however.

There is no reason to compromise on freedom.

as long as we don't confuse "freedom" for "a lack of direction is OK".
unfortunately, that's exactly where it has currently led us (and not just
KDE). we have in the past used "freedom" as a friendly word that is hard
for people to argue against (who wants to be anti-freedom?) when what we
really mean is "we are inable to make decisions" or "it's ok not to serve
our user's needs because at least this way we aren't making any demands
whatsover on any system outside of KDE".
we offer, and will continue to offer, lots on the freedom front. and if we
want to continue making this whole "free software desktop" a viable
concept, we will need to at some point start saying things like "no, a 5
year old X server is not good enough" or "yes, you DO need kernel hooks to
let us know when things are plugged into the machine" or "no, it isn't ok
to have N event loop implementations because that's just stupid" or "here's
a way to get your app to use our file dialog (and vice versa) and everyone
should use it"

Well said.

Indeed, a lot of programming with KDE in my experience has been that when a
programmer gives up some freedom, and does things "the KDE way", that he gets
a lot of freebies that juice up the program. This is one of the things that
distinguishes KDE from the all the competition I think.

Regards,
- Michael Pyne

[David Johnson]

Post by Aaron J. Seigo

Post by David Johnson

Post by Aaron J. Seigo

Post by David Johnson
That's because we have all this inconvenient freedom and choice
getting in the way.

there needs to be a ballance struck, however.

There is no reason to compromise on freedom.

as long as we don't confuse "freedom" for "a lack of direction is
OK". unfortunately, that's exactly where it has currently led us (and
not just KDE). we have in the past used "freedom" as a friendly word
that is hard for people to argue against (who wants to be
anti-freedom?) when what we really mean is "we are inable to make
decisions" or "it's ok not to serve our user's needs because at least
this way we aren't making any demands whatsover on any system outside
of KDE".

That is not what I meant. Sorry if I misunderstood you. There's this
common opinion on Slashdot and elsewhere that KDE and GNOME need to
merge, that having multiple desktops is detrimental to Linux/Unix. The
earlier post I responded to seemed to hint at this.

Maybe I misread Matthias' post, it but sounded like "the Unix desktop is
a mess" because there were too many toolkits. To which I replied that
it was because of freedom and choice.

[Vinay Khaitan]

Post by Aaron J. Seigo
we offer, and will continue to offer, lots on the freedom front. and if we
want to continue making this whole "free software desktop" a viable
concept, we will need to at some point start saying things like "no, a 5
year old X server is not good enough" or "yes, you DO need kernel hooks to
let us know when things are plugged into the machine" or "no, it isn't ok
to have N event loop implementations because that's just stupid" or "here's
a way to get your app to use our file dialog (and vice versa) and everyone
should use it"

I had been always advocate of regulated freedom. Without any kind of
regulation freedom becomes nuisance as this case shows.
When I was thinking about why windows is ahead from linux in desktop, the
first and foremost thing, which struck to me was the diversity of linux
desktops, which makes it impossible to have coherent desktop services.

I envision a day, when there would desktop GUI controls services just like
Windows Activex Controls,OLE and related services, which the developers would
just be able to embed in any widget. Currently within KDE, there are numerous
services which is at par with these things. But really how many application
can use them, unless they are pure KDE application?
Certainly we would require some day kernel hooks .We should see how windows
gives graphical notification for even the lowest level(kernel) events.
What I suggest is that we can have EventLoop and other goodies of core
libraries things implementation in a separate library. And both desktop would
use them.
In fact, Trolltech can create the separate library on its own and then it
would become glib's responsibility to implement that. Just like we are now
going to utilize DBUS which was created mainly by gnome guys.

Vinay Khaitan

[Leo Savernik]

Post by Vinay Khaitan
In fact, Trolltech can create the separate library on its own and then it
would become glib's responsibility to implement that. Just like we are now
going to utilize DBUS which was created mainly by gnome guys.

You're making a very valid point here. Trolltech could actually factor out
common event-loop code into a small library and release it under a very
permissive library like BSD. That way, the typical counter argument, "Qt is
GPL" wouldn't hold.

mfg
Leo

[nf2]

Post by Matthias Ettrich
[...]

Post by nf2
B) GParts
Another interesting project which would benefit from a common main loop,
is GParts (http://gparts.blogspot.com/).
Dmitry M. Shatrov gave me some demo-code which worked well with the
patched Qt. One example embeds KTHML into a Gtk+ window. I put a
screenshot here: http://www.scheinwelt.at/~norbertf/common_main_loop/

You can do that without patching Qt, and definitely without having all of KDE
depend on Glib, even in Qt 3.
Qt's event loop is flexible enough (even in Qt 3) to hook a Glib event loop
into it. One of the issues I had last time I did this was that Glib didn't
give me the information when the next Glib timer was supposed to fire. You
need that to set the proper timeout for the select statement.

That's probably because you tried to do it "upside down", by using the
select statement inside QEventloop to do the filedescriptor polling. I
have chosen glib main loop to do the polling and removed the select()
code from QEventloop. That's why in my Qt patch all fd's get watched and
all the timers work correctly.

I think i need to explain a little, why glib main loop is the right
choice to act as a "common main loop" provider, and Qt should be one of
it's clients. Its because of its design.

Glib main loop has been designed to be totally toolkit independent. It
has no Gtk+ or x11 code inside. As i mentioned earlier glib only depends
on libc.

How does this work:

Basically glib main loop is nothing but a shared poll() function. You
plug in your filedescriptors and the code which calculates poll
timeouts, checks for events and dispatches your events as a GSource.
This happens by attaching the GSource to an existing glib main loop
context, which links in your code with function pointers and your fd's
as list.

typedef struct {
gboolean (*prepare) (GSource *source, gint *timeout_);
gboolean (*check) (GSource *source);
gboolean (*dispatch) (GSource *source, GSourceFunc callback,
gpointer user_data);

...
} GSourceFuncs;

g_source_attach() / g_source_destroy () adds and removes a Gsource
module to/from the main loop context.

You can add filedescriptors to your GSource with g_source_add_poll ().

The nice thing about this concept is, that every GSource behaves like an
independent "select" (or "poll") function itself and doesn't have to
care about other GSources that get processed in the same main loop.

That makes it possible to run Qt, Gtk or even more GUI-toolkits and
asynchronous libraries in the same thread, without even knowing of each
other.

Post by Matthias Ettrich
I also suggested at one point to develop a common event loop abstraction for
Unix C/C++ toolkits. A small, self-contained library that every toolkit can
use. Basically a glorified select() abstraction.This wasn't met with much
enthusiasm, more with "glib is exactly that". And so is QtCore, and Xt :-)

Sorry, but i don't think that QtCore has the appropriate design for
acting as a "common event loop" provider. It has a "plug one complete
event loop implementation or the other" concept. It doesn't allow to
attach independent Event-Sources (code and filedescriptor lists) to a
shared "main loop context" at any point of a program, like glib does.

Btw: I don't care if libglib gets hard linked into Qt or is loaded on
demand (by subclassing QAbstractEventDispatcher - at least in Qt4 this
should work). That's an implementation detail, and honestly i don't
think that having libglib.so in memory is a big problem - because of all
the applications and libraries that are loading it anyway. I have chosen
the patching approach, because i didn't want to hack KDE but rather use
it as a big "test case".

cheers,
Norbert

[Matthias Ettrich]

Post by nf2
Glib main loop has been designed to be totally toolkit independent. It
has no Gtk+ or x11 code inside. As i mentioned earlier glib only depends
on libc.

Glib is unfortunately far more than just the event loop, thus diminishing the
changes that you get all other toolkits to depend on it.

[...]

Post by nf2
Btw: I don't care if libglib gets hard linked into Qt or is loaded on
demand (by subclassing QAbstractEventDispatcher - at least in Qt4 this
should work). That's an implementation detail, and honestly i don't
think that having libglib.so in memory is a big problem - because of all
the applications and libraries that are loading it anyway. I have chosen
the patching approach, because i didn't want to hack KDE but rather use
it as a big "test case".

Are you interested in trying whether you can do is as an abstract event
dispatcher?


Matthias

[Matthias Ettrich]

Post by Matthias Ettrich

Post by nf2
Glib main loop has been designed to be totally toolkit independent. It
has no Gtk+ or x11 code inside. As i mentioned earlier glib only depends
on libc.

Glib is unfortunately far more than just the event loop, thus diminishing
the changes that you get all other toolkits to depend on it.
[...]

Post by nf2
Btw: I don't care if libglib gets hard linked into Qt or is loaded on
demand (by subclassing QAbstractEventDispatcher - at least in Qt4 this
should work). That's an implementation detail, and honestly i don't
think that having libglib.so in memory is a big problem - because of all
the applications and libraries that are loading it anyway. I have chosen
the patching approach, because i didn't want to hack KDE but rather use
it as a big "test case".

Are you interested in trying whether you can do is as an abstract event
dispatcher?

Btw., I checked with our event loop guys, and they do indeed have plans to
look at Glib as a possible dependency for the X11 version. If you want to
contribute, and have patch for Qt4 using the abstract event dispatcher,
please send it to us (e.g. qt-***@trolltech.com).

Matthias

[nf2]

Post by Matthias Ettrich

Post by Matthias Ettrich

Post by nf2
Glib main loop has been designed to be totally toolkit independent. It
has no Gtk+ or x11 code inside. As i mentioned earlier glib only depends
on libc.

Glib is unfortunately far more than just the event loop, thus diminishing
the changes that you get all other toolkits to depend on it.

Every improvement has its negative side-effects, but this one seems to
be quite harmless. Its just a portable "general-purpose utility
library". If Glib becomes too big i think there will be ways to fix that
later on (split it into pieces).

Post by Matthias Ettrich

Post by Matthias Ettrich
Are you interested in trying whether you can do is as an abstract event
dispatcher?

Btw., I checked with our event loop guys, and they do indeed have plans to
look at Glib as a possible dependency for the X11 version. If you want to
contribute, and have patch for Qt4 using the abstract event dispatcher,

Very cool! I will try.

thanks,

Norbert

[Leo Savernik]

Post by Matthias Ettrich
Btw., I checked with our event loop guys, and they do indeed have plans to
look at Glib as a possible dependency for the X11 version.

Is that true? So all of KDE will be punished with needless code duplication
like gstring vs QString, gobject vs QObject, g_strcmp vs qstrcmp, ...

No wonder the glib-guys didn't like your proposal of your event-loop
abstraction. Looks like their resistence has finally paid off.

mfg
Leo

[Tobias Koenig]

Hi Leo,

Post by Leo Savernik

Post by Matthias Ettrich
Btw., I checked with our event loop guys, and they do indeed have plans to
look at Glib as a possible dependency for the X11 version.

Is that true? So all of KDE will be punished with needless code duplication
like gstring vs QString, gobject vs QObject, g_strcmp vs qstrcmp, ...

Hmm, maybe we should distinguish here C and C++...
QString and QObject are fine in C++, but when you want to develop plain
C in a comfortable way, you need something like GLib. And yes, there are
C applications in KDE (e.g. ksysguardd) which could profit from using a
well tested library instead of using home brewed solutions.

Ciao,
Tobias
--
Separate politics from religion and economy!
The Councile of the European Union is an undemocratic and illegal institution!





___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

[Thiago Macieira]

Post by Tobias Koenig
Hmm, maybe we should distinguish here C and C++...
QString and QObject are fine in C++, but when you want to develop plain
C in a comfortable way, you need something like GLib. And yes, there are
C applications in KDE (e.g. ksysguardd) which could profit from using a
well tested library instead of using home brewed solutions.

True, but that still means those unnecessary C functions are in every C++
program we run.

[Tobias Koenig]

Hi,

Post by Thiago Macieira

Post by Tobias Koenig
Hmm, maybe we should distinguish here C and C++...
QString and QObject are fine in C++, but when you want to develop plain
C in a comfortable way, you need something like GLib. And yes, there are
C applications in KDE (e.g. ksysguardd) which could profit from using a
well tested library instead of using home brewed solutions.

True, but that still means those unnecessary C functions are in every C++
program we run.

Hmm, I thought the C compiler/linker ignores all C functions that aren't used
by the application...

Ciao,
Tobias
--
Separate politics from religion and economy!
The Councile of the European Union is an undemocratic and illegal institution!





___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

[Thiago Macieira]

Post by Tobias Koenig

Post by Thiago Macieira

Post by Tobias Koenig
Hmm, maybe we should distinguish here C and C++...
QString and QObject are fine in C++, but when you want to develop
plain C in a comfortable way, you need something like GLib. And yes,
there are C applications in KDE (e.g. ksysguardd) which could profit
from using a well tested library instead of using home brewed
solutions.

True, but that still means those unnecessary C functions are in every
C++ program we run.

Hmm, I thought the C compiler/linker ignores all C functions that aren't
used by the application...

It would, if it were a static library.

Not so with a shared library. With one, you have a binary option: either
you load it entirely to memory, or you don't load it at all.

Luckily, libglib.so is quite small (150k in my system). Besides, libstdc++
also duplicates many functionalities that QtCore provides and we're
forced to load it as well (and it's 830k here).

So, in all, I'd say it's worth it.

[Matthias Ettrich]

Post by Thiago Macieira
Not so with a shared library. With one, you have a binary option: either
you load it entirely to memory, or you don't load it at all.

It's mapped into virtual memory, only the pages that get actually used are
mapped into physical memory.

Matthias

[Martin Konold]

Am Dienstag, 15. November 2005 17:13 schrieb Matthias Ettrich:

Hi,

Post by Matthias Ettrich
It's mapped into virtual memory, only the pages that get actually used are
mapped into physical memory.

In contrast to what most people (incl. kernel and glibc people) claim the
mapping is not entirely free.

Regards,
-- martin

[Thiago Macieira]

Post by Martin Konold

Post by Matthias Ettrich
It's mapped into virtual memory, only the pages that get actually used
are mapped into physical memory.

In contrast to what most people (incl. kernel and glibc people) claim
the mapping is not entirely free.

No, not really. If a page has not been faulted in, it hasn't been mapped
to physical memory yet and does not occupy buffers or cache (it may
already be in cache, but that's another story).

According to the headers in libglib.so, it has a total virtual memory size
of 149544 bytes, of which only 1828 are non-sharable -- or exactly one
page.

I would compare to QtCore if I could, but I don't have a non-debugging
non-exception build available. (just for info, my libQtCore_debug.so has
230394 bytes of exception headers and tables alone)

[Martin Konold]

Am Dienstag, 15. November 2005 18:38 schrieb Thiago Macieira:

Hi,

Post by Thiago Macieira

Post by Martin Konold

Post by Matthias Ettrich
It's mapped into virtual memory, only the pages that get actually used
are mapped into physical memory.

In contrast to what most people (incl. kernel and glibc people) claim
the mapping is not entirely free.

No, not really. If a page has not been faulted in, it hasn't been mapped
to physical memory yet and does not occupy buffers or cache (it may
already be in cache, but that's another story).

I mainly mean fragmentation effects and CPU time.

Regards,
-- martin

[Matthias Ettrich]

Post by Thiago Macieira

Post by Martin Konold

Post by Matthias Ettrich
It's mapped into virtual memory, only the pages that get actually used
are mapped into physical memory.

In contrast to what most people (incl. kernel and glibc people) claim
the mapping is not entirely free.

No, not really. If a page has not been faulted in, it hasn't been mapped
to physical memory yet and does not occupy buffers or cache (it may
already be in cache, but that's another story).

[...]


There's a bigger problem, and it's not technical. Glib is LGPL, which means we
can't make Qt/X11 depend on it :-/ I can support it as a compile time
option, but not as default. This kind of defeats the purpose of bringing us
closer to a more integrated free desktop on GNU/Linux.

A little fd.o event loop library written in C would be perfect (and a patched
Glib that uses it). It can be modelled closely after the Glib event loop
model, like D-Bus was modelled after the DCOP model. Maybe it's also possible
to extract the code from Glib and relicense it (depends on who owns the
copyright)? Anyone up to the challenge?


Matthias

[nf2]

Post by Matthias Ettrich
There's a bigger problem, and it's not technical. Glib is LGPL, which means we
can't make Qt/X11 depend on it :-/ I can support it as a compile time
option, but not as default. This kind of defeats the purpose of bringing us
closer to a more integrated free desktop on GNU/Linux.

That's interesting. I thought LGPL (in contradiction to GPL) permits any
kind of license for software "using" a LGPLed library - even commercial
closed source licenses.

I think a compile time option would suffice (like the -glibmainloop
./configure switch in my Qt-3.3 patch). KDE requires a certain
configuration of Qt anyway...

Post by Matthias Ettrich
A little fd.o event loop library written in C would be perfect (and a patched
Glib that uses it). It can be modelled closely after the Glib event loop
model, like D-Bus was modelled after the DCOP model. Maybe it's also possible
to extract the code from Glib and relicense it (depends on who owns the
copyright)? Anyone up to the challenge?

Perhaps this issue should be discussed with the people on the gtk-list.

norbert

[Philip Van Hoof]

Post by nf2

Post by Matthias Ettrich
A little fd.o event loop library written in C would be perfect (and a patched
Glib that uses it). It can be modelled closely after the Glib event loop
model, like D-Bus was modelled after the DCOP model. Maybe it's also possible
to extract the code from Glib and relicense it (depends on who owns the
copyright)? Anyone up to the challenge?

Perhaps this issue should be discussed with the people on the gtk-list.

As a Gtk+/GNOME (application) developer myself, I'm interested in
helping with this task.

As I don't want to do useless work, I'll wait until the final
conclusions/decisions are made by both the Glib and Qt people.

[Matthias Ettrich]

Post by Leo Savernik
Is that true? So all of KDE will be punished with needless code duplication
like gstring vs QString, gobject vs QObject, g_strcmp vs qstrcmp, ...

There's different ways of doing this. I wasn't necessarily talking about a
hard dependency for all of Qt, but more of a runtime option for the apps that
require it.

I too would prefer if we could separate the event loop part of Glib from the
rest, but there are more interesting battles to fight. The benefits of a
common event loop are definitely worth some compromising.

How much does Glib's event loop depend on the rest of Glib? Maybe a
separation is possible, but someone has to do it then. And fd.o is the place.

Matthias

[Aaron J. Seigo]

Post by Matthias Ettrich
How much does Glib's event loop depend on the rest of Glib? Maybe a

i was actually looking at this today and the answer is "quite a bit".

but with some work it could be made better. e.g. the event loop probably
shouldn't use gerror (since that won't help with allocation related errors;
instead we should probably do more like dbus here and not do any malloc()s on
error reporting), and if we don't need the threading then we can remove the
requirement of gthread

removing gerror removes the need for gstring

removing gthread removes the need the collection related functions (glist,
etc). the threading is not needed if the event loop is PER thread, e.g. you
aren't hooking the event loop up across threads (creating a new event loop in
a new thread is just fine, apparently). if we keep gthread in there then we
will have some colletion related requirements.

so it seems after looking through it and playing with its compilation for a
couple hours today that there's a lot of glib that is unnecessary to a
properly abstracted glib event loop. and gobject, et al is already in another
lib.

(note: i should probably thank federico a bit here as he answered a number of
questions i had as i went along on irc.gimp.org; though the person we really
need to talk to is owen, who wrote the event loop.)

[David Johnson]

Post by Matthias Ettrich
Btw., I checked with our event loop guys, and they do indeed have
plans to look at Glib as a possible dependency for the X11 version.
If you want to contribute, and have patch for Qt4 using the abstract

If they do, is it possible to import the relevant portions of Glib, even
if it's still a loadable library? This is because it seems as if every
minor release of Glib involves rebuilding everything even vaguely
dependent upon it. Maybe it's just the overzealousness of the GNOME
team on FreeBSD, but that's the impression I get.

p.s. I've asked twice now, and I still haven't gotten an answer as to
why a new event loop is needed. Point me to where the answer is,
thanks,

[Aaron J. Seigo]

Post by David Johnson
p.s. I've asked twice now, and I still haven't gotten an answer as to
why a new event loop is needed.

it is a step towards allowing components written using different toolkits to
cooexist in the same process.

[David Johnson]

Post by Aaron J. Seigo

Post by David Johnson
p.s. I've asked twice now, and I still haven't gotten an answer as
to why a new event loop is needed.

it is a step towards allowing components written using different
toolkits to cooexist in the same process.

By "toolkits", I assume you mean GTK+. For something of this scope,
shouldn't there be some sort of standard rather than tightly coupling
everything to Glib? Other than the fact that Glib uses select(), is
there any particular reason we're adopting it?

[Aaron J. Seigo]

Post by David Johnson

Post by Aaron J. Seigo

Post by David Johnson
p.s. I've asked twice now, and I still haven't gotten an answer as
to why a new event loop is needed.

it is a step towards allowing components written using different
toolkits to cooexist in the same process.

By "toolkits", I assume you mean GTK+.

hopefully by "toolkits" we can eventually mean "any toolkit that seriously
targets UNIX/Linux"

Post by David Johnson
For something of this scope,
shouldn't there be some sort of standard rather than tightly coupling
everything to Glib?

obviously. which is why if you read one of my other posts in this thread
you'll see i spent some time yesterday looking at what it would take to
excise the glib event loop from glib itself to end up with something more
appropriate from that angle. it's not the only approach, however, of course,
but it's hard to know what the options are without looking at what is out
there right now.

[nf2]

Post by Matthias Ettrich
Btw., I checked with our event loop guys, and they do indeed have plans to
look at Glib as a possible dependency for the X11 version. If you want to
contribute, and have patch for Qt4 using the abstract event dispatcher,
Matthias

Hi Matthias,

I have just finished the Qt4 patch. The Qt4 examples seem to work.
The patch can be downloaded from
http://www.scheinwelt.at/~norbertf/common_main_loop/

Btw - how do i tell the Qt build system to synchronize
/include/QtCore/private/qeventdispatcher_unix_glib_p.h with
/src/corelib/kernel/qeventdispatcher_unix_glib_p.h ?

regards,

Norbert

[Aaron J. Seigo]

Post by Gary Greene
If you re-read nf2's post on this, apparently it DOES allow Gtk+ apps to

martin was not refering to kparts but to things like file dialogs and other
components that live in libraries. being able to use aribtrary KParts (which
is a specific plugin interface) versus abstracting the concept of "file
dialog" and "print dialog" is fairly different.