Discussion:
kwallet and QCA
(too old to reply)
Michael Leupold
2008-06-03 10:46:19 UTC
Permalink
Hi there,

Sascha Peilicke and me were thinking about using QCA for kwallet. This would
allow us to strip down the current implementation
(http://websvn.kde.org/trunk/KDE/kdelibs/kwallet/backend/) by quite a bit but
would probably introduce some dependencies - I guess coding it so that any of
the QCA plugins that are usable wouldn't be a problem.

Are there currently any QCA plugins that are hard requirements for kdelibs?

Regards,
Michael
Robert Knight
2008-06-03 16:17:30 UTC
Permalink
Hi,

This doesn't answer your question directly but something that came up at
FOSSCamp during the KDE/Gnome collaboration session and which also
relates to upcoming specifications in Ubuntu and Fedora for
single-sign-on* is that it would be useful to share the password
management storage, API and/or code between gnome, KDE, Firefox,
OpenOffice etc. I don't know whether OpenSuSE are planning anything in
this area.

Since this is not particularly exciting stuff I think it was suggested
that a single shared library could be used to do all of the backend
work.

Unfortunately since QCA depends on Qt, I guess that might be a hard-sell
as one of the dependencies.

Regards,
Robert.

* single-sign-on being the idea that when you login to your desktop, you
also log into chosen web services at the same time - with usernames and
passwords kept in KWallet/gnome-keyring etc.
Post by Michael Leupold
Hi there,
Sascha Peilicke and me were thinking about using QCA for kwallet. This would
allow us to strip down the current implementation
(http://websvn.kde.org/trunk/KDE/kdelibs/kwallet/backend/) by quite a bit but
would probably introduce some dependencies - I guess coding it so that any of
the QCA plugins that are usable wouldn't be a problem.
Are there currently any QCA plugins that are hard requirements for kdelibs?
Regards,
Michael
Kevin Krammer
2008-06-03 18:09:27 UTC
Permalink
Post by Robert Knight
Hi,
This doesn't answer your question directly but something that came up at
FOSSCamp during the KDE/Gnome collaboration session and which also
relates to upcoming specifications in Ubuntu and Fedora for
single-sign-on* is that it would be useful to share the password
management storage, API and/or code between gnome, KDE, Firefox,
OpenOffice etc. I don't know whether OpenSuSE are planning anything in
this area.
Since this is not particularly exciting stuff I think it was suggested
that a single shared library could be used to do all of the backend
work.
This is a common mistake, intriguingly often happening in discussions around
free software desktop implementation sharing.

In any case the single-sign-on will be implemented through a desktop
service, , e.g. gnome-key-ring, kwallet module in kded, etc., which means it
will have to have a well defined IPC API anyway, most likely D-Bus
interfaces.

Which also has the nice side effect that it can be implemented right away,
i.e. as a second interface to already existing key storage solutions without
needing to simultaniously transition all applications using the desktop
specific interface right now.
Post by Robert Knight
Unfortunately since QCA depends on Qt, I guess that might be a hard-sell
as one of the dependencies.
It would be a dependency of one service implementation, an implementation
detail, so definitely not a problem in this context.

Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
Robert Knight
2008-06-03 21:14:28 UTC
Permalink
Post by Kevin Krammer
This is a common mistake, intriguingly often happening in discussions around
free software desktop implementation sharing.
Do you mean that it is not a good idea or that it should have been done earlier?

Regards,
Robert.
Post by Kevin Krammer
Post by Robert Knight
Hi,
This doesn't answer your question directly but something that came up at
FOSSCamp during the KDE/Gnome collaboration session and which also
relates to upcoming specifications in Ubuntu and Fedora for
single-sign-on* is that it would be useful to share the password
management storage, API and/or code between gnome, KDE, Firefox,
OpenOffice etc. I don't know whether OpenSuSE are planning anything in
this area.
Since this is not particularly exciting stuff I think it was suggested
that a single shared library could be used to do all of the backend
work.
This is a common mistake, intriguingly often happening in discussions around
free software desktop implementation sharing.
In any case the single-sign-on will be implemented through a desktop
service, , e.g. gnome-key-ring, kwallet module in kded, etc., which means it
will have to have a well defined IPC API anyway, most likely D-Bus
interfaces.
Which also has the nice side effect that it can be implemented right away,
i.e. as a second interface to already existing key storage solutions without
needing to simultaniously transition all applications using the desktop
specific interface right now.
Post by Robert Knight
Unfortunately since QCA depends on Qt, I guess that might be a hard-sell
as one of the dependencies.
It would be a dependency of one service implementation, an implementation
detail, so definitely not a problem in this context.
Cheers,
Kevin
Kevin Krammer
2008-06-03 21:40:20 UTC
Permalink
Post by Robert Knight
Post by Kevin Krammer
This is a common mistake, intriguingly often happening in discussions
around free software desktop implementation sharing.
Do you mean that it is not a good idea or that it should have been done earlier?
I meant that concentrating on something as totally unnecessary as a shared
client library will stall the tremendously useful convergence of
authentification stores.

Fact is that there are at least two capable authentification stores, both
offering their functionality to clients via D-Bus.

A common connection name, a couple of common object paths plus respective
interface would probably be almost trivial to add to both, instantly allowing
third party application to use these interfaces.

Mozilla could implement a little helper process based on their authentication
store technology so they have a fallback in window manager only environments,
etc.

I am getting the impression that I somehow misunderstood the "single shared
library" concept you wrote about.
Is this for accessing on-disk authentification data in cases where users
switch environments?

Cheers,
Kevin
Post by Robert Knight
Regards,
Robert.
Post by Kevin Krammer
Post by Robert Knight
Hi,
This doesn't answer your question directly but something that came up
at FOSSCamp during the KDE/Gnome collaboration session and which also
relates to upcoming specifications in Ubuntu and Fedora for
single-sign-on* is that it would be useful to share the password
management storage, API and/or code between gnome, KDE, Firefox,
OpenOffice etc. I don't know whether OpenSuSE are planning anything in
this area.
Since this is not particularly exciting stuff I think it was suggested
that a single shared library could be used to do all of the backend
work.
This is a common mistake, intriguingly often happening in discussions
around free software desktop implementation sharing.
In any case the single-sign-on will be implemented through a desktop
service, , e.g. gnome-key-ring, kwallet module in kded, etc., which means
it will have to have a well defined IPC API anyway, most likely D-Bus
interfaces.
Which also has the nice side effect that it can be implemented right
away, i.e. as a second interface to already existing key storage
solutions without needing to simultaniously transition all applications
using the desktop specific interface right now.
Post by Robert Knight
Unfortunately since QCA depends on Qt, I guess that might be a
hard-sell as one of the dependencies.
It would be a dependency of one service implementation, an implementation
detail, so definitely not a problem in this context.
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
nf2
2008-06-04 01:53:55 UTC
Permalink
I was also pondering about sharing the password storage. My approach
would be somehow similar the KIO-Giobridge approach: Look if KWallet can
be served by gnome-keyring in a migration phase, and as a second step
write a thin Qt/C++ wrapper to the actual GLib based API to get the full
keyring power (perhaps the KDE KWallet API can be deprecated later on).
Similar to GIO, the IPC stuff inside keyring appears to be more complex
than a simple D-Bus service - there are direct socket connections with a
custom wire-protocol - therefore writing the client twice wouldn't make
much sense to me. Just linking it in process with a Qt/C++ language
binding seems more straight forward.

Actually - as i'm almost done with KIO-GIOBridge - my plan is to start
coding such "thin" Qt/C++ bindings to several GLib based infrastructure
libraries (GIO, keyring,...) soon - as working name i thought of
"libkommodity".

I might disagree with Kevin here a bit - i don't think that trying to
standardize D-Bus interfaces (the DAPI approach) and having multiple
client and service implementations gets us any further. If libraries
developed by GNOME fit our needs - lets just use them.

Regards,
Norbert
Post by Robert Knight
Hi,
This doesn't answer your question directly but something that came up at
FOSSCamp during the KDE/Gnome collaboration session and which also
relates to upcoming specifications in Ubuntu and Fedora for
single-sign-on* is that it would be useful to share the password
management storage, API and/or code between gnome, KDE, Firefox,
OpenOffice etc. I don't know whether OpenSuSE are planning anything in
this area.
Since this is not particularly exciting stuff I think it was suggested
that a single shared library could be used to do all of the backend
work.
Unfortunately since QCA depends on Qt, I guess that might be a hard-sell
as one of the dependencies.
Regards,
Robert.
* single-sign-on being the idea that when you login to your desktop, you
also log into chosen web services at the same time - with usernames and
passwords kept in KWallet/gnome-keyring etc.
Post by Michael Leupold
Hi there,
Sascha Peilicke and me were thinking about using QCA for kwallet. This would
allow us to strip down the current implementation
(http://websvn.kde.org/trunk/KDE/kdelibs/kwallet/backend/) by quite a bit but
would probably introduce some dependencies - I guess coding it so that any of
the QCA plugins that are usable wouldn't be a problem.
Are there currently any QCA plugins that are hard requirements for kdelibs?
Regards,
Michael
Aaron J. Seigo
2008-06-04 04:08:23 UTC
Permalink
Post by nf2
Actually - as i'm almost done with KIO-GIOBridge - my plan is to start
coding such "thin" Qt/C++ bindings to several GLib based infrastructure
libraries (GIO, keyring,...) soon - as working name i thought of
"libkommodity"
if you are seriously hoping for buy in on this i would suggest explaining for
each one why the particular library should be used, what the real world
benefits would be, etc.
Post by nf2
I might disagree with Kevin here a bit - i don't think that trying to
standardize D-Bus interfaces (the DAPI approach) and having multiple
client and service implementations gets us any further.
it actualy gets us a lot further in that it would enable applications to use
the desktop facilities of whatever the user is logged into. this is an obvious
improvement over the current situation and very neatly covers the vast
majority of cases.

(as such i'm not sure statements like these help your cause/credibility much
=/)

what it doesn't get us is the ability to use App A on Desktop X, then switch
into Desktop Y and still have the data stored in the wallet while in Desktop X
still there. sharing an implementation would.

Kevin's probably quite right that standardizing the d-bus interface would get
us there much faster. most importantly, it allows us to adjust the client side
right now and then we can worry about the server side afterwards as a separate
implementation detail.

we'd still need to write the API for the Qt/KDE side anyways, or adapt what is
already there. so it's really not work lost, but work that needs to be done
anyways.
Post by nf2
If libraries
developed by GNOME fit our needs - lets just use them.
that can only be determined by defining our needs and then the capabilities of
the library in question. while there are places we can share implementations,
there are places we probably want something better than what is available.

additionally, we'd need to be able to trust the forward development of said
libraries with regards to our needs.

sharing implementations really means a lot more than just writing wrappers
around other people's libraries ad infinitum. it takes working together to
ensure needs are known and addressed.
--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
Maksim Orlovich
2008-06-04 04:00:42 UTC
Permalink
Post by Aaron J. Seigo
Post by nf2
Actually - as i'm almost done with KIO-GIOBridge - my plan is to start
coding such "thin" Qt/C++ bindings to several GLib based infrastructure
libraries (GIO, keyring,...) soon - as working name i thought of
"libkommodity"
if you are seriously hoping for buy in on this i would suggest explaining
for each one why the particular library should be used, what the real world
benefits would be, etc.
And who will maintain it after you move on to something else.
Post by Aaron J. Seigo
what it doesn't get us is the ability to use App A on Desktop X, then
switch into Desktop Y and still have the data stored in the wallet while in
Desktop X still there. sharing an implementation would.
Sharing the file format would be sufficient.
Aaron J. Seigo
2008-06-04 04:36:30 UTC
Permalink
Post by Maksim Orlovich
Sharing the file format would be sufficient.
along with he implied shared location and locking mechanism, you're quite
right: that would be sufficient indeed.
--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
nf2
2008-06-04 15:32:47 UTC
Permalink
Post by Aaron J. Seigo
Post by Maksim Orlovich
Sharing the file format would be sufficient.
along with he implied shared location and locking mechanism, you're quite
right: that would be sufficient indeed.
The word "sufficient" somehow suggests that this would be the easier and
more realistic approach. I'm afraid it's not. It makes the whole system
more complex, takes ages to formulate and implement (twice) and after
all has no advantages compared to just adopting and improving *one*
existing implementation.

Norbert
Maksim Orlovich
2008-06-04 15:46:14 UTC
Permalink
Post by nf2
Post by Aaron J. Seigo
Post by Maksim Orlovich
Sharing the file format would be sufficient.
along with he implied shared location and locking mechanism, you're quite
right: that would be sufficient indeed.
The word "sufficient" somehow suggests that this would be the easier and
more realistic approach. I'm afraid it's not. It makes the whole system
more complex, takes ages to formulate
Since when is taking the time to think a disadvantage?
And how is involving glib and stuff like that NOT making /our/ system more
complex?
nf2
2008-06-04 16:32:14 UTC
Permalink
Post by Maksim Orlovich
Post by nf2
Post by Aaron J. Seigo
Post by Maksim Orlovich
Sharing the file format would be sufficient.
along with he implied shared location and locking mechanism, you're quite
right: that would be sufficient indeed.
The word "sufficient" somehow suggests that this would be the easier and
more realistic approach. I'm afraid it's not. It makes the whole system
more complex, takes ages to formulate
Since when is taking the time to think a disadvantage?
Generally it isn't, but i guess in this particular case i doubt that
anyone has the drive to work this out *and* write two implementations.
Do you?
Post by Maksim Orlovich
And how is involving glib and stuff like that NOT making /our/ system more
complex?
Oh well... Things in this - call it "application infrastructure" or
"platform layer" - can only be written in GLib+C, as Qt doesn't fit
there for various reasons (which i am tired discussing).

Norbert
Aaron J. Seigo
2008-06-04 18:11:30 UTC
Permalink
Post by nf2
Post by Maksim Orlovich
Since when is taking the time to think a disadvantage?
Generally it isn't, but i guess in this particular case i doubt that
anyone has the drive to work this out *and* write two implementations.
Do you?
it doesn't need to be one person. it needs buy in from all participating teams
(in this case KDE and GNOME) anyways, so it could be done by one or more
people in each project.
Post by nf2
Post by Maksim Orlovich
And how is involving glib and stuff like that NOT making /our/ system
more complex?
Oh well... Things in this - call it "application infrastructure" or
"platform layer" - can only be written in GLib+C,
this is complete and utter rubbish. if you mean that there are people out
there who will only accept things written in glib+c because they are
completely inflexible and stuck mentally in the last century, then i'd agree.

those people need to be routed around, however, rather than be allowed to set
the agenda. a few small minded individuals should not be allowed to sabotage
the future of the free desktop platform.
--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
nf2
2008-06-04 20:26:58 UTC
Permalink
Post by Aaron J. Seigo
Post by nf2
well... Things in this - call it "application infrastructure" or
"platform layer" - can only be written in GLib+C,
this is complete and utter rubbish. if you mean that there are people out
there who will only accept things written in glib+c because they are
completely inflexible and stuck mentally in the last century, then i'd agree.
so? which language and dependency stack would you suggest? do we have
that much choice?

Norbert
Kevin Krammer
2008-06-04 20:52:35 UTC
Permalink
Post by nf2
Post by Aaron J. Seigo
Post by nf2
well... Things in this - call it "application infrastructure" or
"platform layer" - can only be written in GLib+C,
this is complete and utter rubbish. if you mean that there are people out
there who will only accept things written in glib+c because they are
completely inflexible and stuck mentally in the last century, then i'd agree.
so? which language and dependency stack would you suggest? do we have
that much choice?
I think Aaron was mostly referring to the "only" part of your previous
posting, given that there are already widely accepted solutions e.g.
implemented in C++, like TagLib or libpoppler.

Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
Aaron J. Seigo
2008-06-04 23:54:57 UTC
Permalink
Post by nf2
Post by Aaron J. Seigo
Post by nf2
well... Things in this - call it "application infrastructure" or
"platform layer" - can only be written in GLib+C,
this is complete and utter rubbish. if you mean that there are people out
there who will only accept things written in glib+c because they are
completely inflexible and stuck mentally in the last century, then i'd agree.
so? which language and dependency stack would you suggest? do we have
that much choice?
C w/glib is one option.
C++ is another.
C++ w/QtCore is also sensible these days.

if you are surprised about the last one, consider that:

* it is part of the LSB
* QtCore has no GUI dependencies

this makes it essentially a "glib for C++"
--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
Maksim Orlovich
2008-06-05 00:30:00 UTC
Permalink
Post by Aaron J. Seigo
C w/glib is one option.
C++ is another.
C++ w/QtCore is also sensible these days.
* it is part of the LSB
* QtCore has no GUI dependencies
And before licensing is brought up, let me point out that it's irrelevant
if what's implemented is a DBus service.
nf2
2008-06-07 10:15:50 UTC
Permalink
Post by Maksim Orlovich
Post by Aaron J. Seigo
C w/glib is one option.
C++ is another.
C++ w/QtCore is also sensible these days.
* it is part of the LSB
* QtCore has no GUI dependencies
And before licensing is brought up, let me point out that it's irrelevant
if what's implemented is a DBus service.
That's a limitation though. Therefore QtCore is only a secondary option
for platform stuff i think.

Norbert
Martin Konold
2008-06-09 18:03:03 UTC
Permalink
Am Samstag 07 Juni 2008 schrieb nf2:

Hi,
Post by nf2
Post by Maksim Orlovich
Post by Aaron J. Seigo
C++ w/QtCore is also sensible these days.
* it is part of the LSB
* QtCore has no GUI dependencies
And before licensing is brought up, let me point out that it's irrelevant
if what's implemented is a DBus service.
That's a limitation though. Therefore QtCore is only a secondary option
for platform stuff i think.
Actually there is no limitation. If the service is offered via a DBUS
interface there are zero limitations. On the other hand QtCore offers much
for run-time and development time efficiency.

Regards,
-- martin
--
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Sitz: Adolfstraße 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126
http://www.erfrakon.com/
Michael Pyne
2008-06-09 21:23:43 UTC
Permalink
Post by Martin Konold
Hi,
Post by nf2
Post by Maksim Orlovich
Post by Aaron J. Seigo
C++ w/QtCore is also sensible these days.
* it is part of the LSB
* QtCore has no GUI dependencies
And before licensing is brought up, let me point out that it's
irrelevant if what's implemented is a DBus service.
That's a limitation though. Therefore QtCore is only a secondary option
for platform stuff i think.
Actually there is no limitation. If the service is offered via a DBUS
interface there are zero limitations. On the other hand QtCore offers much
for run-time and development time efficiency.
It's still bad because it's C++. C++ is evil. C is the One True Way to go,
well supported by even gcc 2.7! Only lazy programmers use C++, and there is
absolutely positively no way to make C++ libraries, as their binary
compatibility is impossible to maintain. Luckily no C library ever has become
binary incompatible.

...

Well obviously that's all bunk, but I do wonder what the next reason will be
why developing a cross-desktop interface is supposed to be so bad.

Regards,
- Michael Pyne
Kevin Krammer
2008-06-10 01:05:36 UTC
Permalink
Post by Michael Pyne
Post by Martin Konold
Hi,
Post by nf2
Post by Maksim Orlovich
Post by Aaron J. Seigo
C++ w/QtCore is also sensible these days.
* it is part of the LSB
* QtCore has no GUI dependencies
And before licensing is brought up, let me point out that it's
irrelevant if what's implemented is a DBus service.
That's a limitation though. Therefore QtCore is only a secondary option
for platform stuff i think.
Actually there is no limitation. If the service is offered via a DBUS
interface there are zero limitations. On the other hand QtCore offers
much for run-time and development time efficiency.
It's still bad because it's C++. C++ is evil. C is the One True Way to
go, well supported by even gcc 2.7!
Sarcasm aside, I think that the limitation Nobert refers to is the scope of
out-of-process functionality.
Regarding the thread content, single-sign-on/authentifcation service this is
obviously not a problem, however it might be in a different context where
functionality needs to be provided in-process.

Fortunately we see a move into service based infrastructure from basically all
desktop platform providers, so each software stack can provide the kind of
protocol implementation that makes most sense within the concepts the
developer of the respectice stack are used to (e.g. threaded I/O on stacks
like Java vs. event loop based I/O on stacks like GLib/GObject or Qt)

Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
nf2
2008-06-10 22:59:40 UTC
Permalink
Post by Kevin Krammer
Post by Michael Pyne
Post by Martin Konold
Hi,
Post by nf2
Post by Maksim Orlovich
Post by Aaron J. Seigo
C++ w/QtCore is also sensible these days.
* it is part of the LSB
* QtCore has no GUI dependencies
And before licensing is brought up, let me point out that it's
irrelevant if what's implemented is a DBus service.
That's a limitation though. Therefore QtCore is only a secondary option
for platform stuff i think.
Actually there is no limitation. If the service is offered via a DBUS
interface there are zero limitations. On the other hand QtCore offers
much for run-time and development time efficiency.
It's still bad because it's C++. C++ is evil. C is the One True Way to
go, well supported by even gcc 2.7!
Sarcasm aside, I think that the limitation Nobert refers to is the scope of
out-of-process functionality.
Regarding the thread content, single-sign-on/authentifcation service this is
obviously not a problem,
This might be a overhasty conclusion though. Keyring - for instance -
seems to require direct socket connections.
Post by Kevin Krammer
however it might be in a different context where
functionality needs to be provided in-process.
Yes - and don't forget that even code being developed for out-of-process
services could be reused in-process.
Post by Kevin Krammer
Fortunately we see a move into service based infrastructure from basically all
desktop platform providers, so each software stack can provide the kind of
protocol implementation that makes most sense within the concepts the
developer of the respectice stack are used to (e.g. threaded I/O on stacks
like Java vs. event loop based I/O on stacks like GLib/GObject or Qt)
This sounds all very nice in theory, but i doubt that the "lack (or
fragmentation) of platform" problem will ever be fixed that way. Maybe i
am impatient, but i got the impression that this DAPI model just doesn't
seem to be very successful in practice. Perhaps that's because it's
putting the cart before the donkey. Things need to be coded, and during
this process the APIs and interfaces start to consolidate. Therefore the
first thing necessary for collaboration is a decision on a standard
programming language, library stack and maybe API style for this layer.

Norbert
Thiago Macieira
2008-06-11 06:18:31 UTC
Permalink
Post by nf2
Therefore the
first thing necessary for collaboration is a decision on a standard
programming language, library stack and maybe API style for this layer.
Which is why I don't think such a layer will ever exist, because we will
never agree.
--
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
Michael Leupold
2008-06-11 06:35:40 UTC
Permalink
Post by Thiago Macieira
Post by nf2
Therefore the
first thing necessary for collaboration is a decision on a standard
programming language, library stack and maybe API style for this layer.
Which is why I don't think such a layer will ever exist, because we will
never agree.
Unfortunately even making first contact seems to be a hurdle regarding I
haven't even gotten any reply from the keyring maintainers :-(

I see ways we might find common grounds to start from though. I'll keep you
updated.

Regards,
Michael
nf2
2008-06-11 09:39:05 UTC
Permalink
Post by Thiago Macieira
Post by nf2
Therefore the
first thing necessary for collaboration is a decision on a standard
programming language, library stack and maybe API style for this layer.
Which is why I don't think such a layer will ever exist, because we will
never agree.
I know. But if developers are unable to create a single coherent
platform layer then i guess distributors are forced to make decisions.
And some of them have already flipped the coin, i'm afraid.

Norbert
Thiago Macieira
2008-06-11 13:14:20 UTC
Permalink
Post by nf2
Post by Thiago Macieira
Post by nf2
Therefore the
first thing necessary for collaboration is a decision on a standard
programming language, library stack and maybe API style for this layer.
Which is why I don't think such a layer will ever exist, because we will
never agree.
I know. But if developers are unable to create a single coherent
platform layer then i guess distributors are forced to make decisions.
And some of them have already flipped the coin, i'm afraid.
I don't see a problem with ISVs choosing whichever toolkit suits them best. As
long as they can integrate with the desktop whichever that is, it should be
fine.

That's why working with specifications and leaving the coding aside makes
sense.

Distributors that don't ship the essential libraries should be shot anyways
and deserve to die a horrible death. Both Qt and GTK are standardised in the
LSB 3.1, 3.2 and will be even more deep in 4.0.
--
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
Kevin Krammer
2008-06-11 12:27:51 UTC
Permalink
Post by nf2
Post by Kevin Krammer
Sarcasm aside, I think that the limitation Nobert refers to is the scope
of out-of-process functionality.
Regarding the thread content, single-sign-on/authentifcation service this
is obviously not a problem,
This might be a overhasty conclusion though. Keyring - for instance -
seems to require direct socket connections.
Hmm, I am afraid I don't understand that this would make any difference.
So Keyring has a D-Bus based control connection and a custom protocol based
data connection.
Assuming there is a reason why this approach is used, e.g. not transporting
sensitive information over D-Bus or whatever, I don't see any problem.
Socket communication is part of our technology stack, in fact we already do
use it for some of our infrastructure (e.g. IO slaves).
Post by nf2
Post by Kevin Krammer
however it might be in a different context where
functionality needs to be provided in-process.
Yes - and don't forget that even code being developed for out-of-process
services could be reused in-process.
Sure, there is always possibility for reusing stuff. It is a bonus though, not
a requirement.
Post by nf2
Post by Kevin Krammer
Fortunately we see a move into service based infrastructure from
basically all desktop platform providers, so each software stack can
provide the kind of protocol implementation that makes most sense within
the concepts the developer of the respectice stack are used to (e.g.
threaded I/O on stacks like Java vs. event loop based I/O on stacks like
GLib/GObject or Qt)
This sounds all very nice in theory, but i doubt that the "lack (or
fragmentation) of platform" problem will ever be fixed that way. Maybe i
am impatient, but i got the impression that this DAPI model just doesn't
seem to be very successful in practice.
Not sure why you are referring to DAPI, I am referring to the service based
infrastructure of desktop projects like GNOME and KDE, which at least on the
KDE side has worked nicely for years, so I have no reason to believe it did
not work for GNOME.

The service oriented approach (I apologize for the buzzwords) also works
nicely for desktop<->system interaction, giving us a good overall desktop
experience without sacrifising Unix goodies like multi user machines.
Post by nf2
Perhaps that's because it's
putting the cart before the donkey. Things need to be coded, and during
this process the APIs and interfaces start to consolidate. Therefore the
first thing necessary for collaboration is a decision on a standard
programming language, library stack and maybe API style for this layer.
Yes, of course! Which is why shared service are such a nice thing since it
avoids having to mix language, library stack or API style.

As a good example we can look at D-Bus, where it allowed managed code
environment like Java and Mono to use it without having to do tons of
managed<->native code bridging.

Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
Aaron J. Seigo
2008-06-04 16:44:09 UTC
Permalink
Post by nf2
Post by Aaron J. Seigo
Post by Maksim Orlovich
Sharing the file format would be sufficient.
along with he implied shared location and locking mechanism, you're quite
right: that would be sufficient indeed.
The word "sufficient" somehow suggests that this would be the easier and
more realistic approach.
the dictionary defines it as "enough to meet the needs of a situation or a
proposed end". don't read into words what i'm not saying =)
Post by nf2
I'm afraid it's not. It makes the whole system more complex,
it doesn't make the individual desktop stacks more complex, however.
Post by nf2
takes ages to formulate and implement (twice) and after
of course, we already have implemented these things twice. *shrug*
Post by nf2
all has no advantages compared to just adopting and improving *one*
existing implementation.
there are scenarios where adopting an implementation and improving it is the
better option, and scenarios where it isn't.

it is impossible to have this discussion in vague terms and have any
meaningful outcome. so let's just not =)

instead, let's discuss specifics scenarios. in this case the idea of adopting
libgnome-keyring. having looked at it, the api is really horrid (though
presumably that would be "fixed" by an API layer on top of it) and it seems to
offer only a subset of kwallet's features.

the API bit is concerning due to the feature subset issue: improving it would
mean both getting buy in from the libgnome-keyring developers (have you talked
to them at all about this?) and dealing with that API (not fun)

simply saying "we can wrap libs!" is not a substitute for actually having a
good relationship with the development team of the libraries in question and
feeling confident in our ability to work on those libs over the long term.
--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
nf2
2008-06-04 19:54:11 UTC
Permalink
Post by Aaron J. Seigo
Post by nf2
all has no advantages compared to just adopting and improving *one*
existing implementation.
there are scenarios where adopting an implementation and improving it is the
better option, and scenarios where it isn't.
it is impossible to have this discussion in vague terms and have any
meaningful outcome. so let's just not =)
instead, let's discuss specifics scenarios. in this case the idea of adopting
libgnome-keyring. having looked at it, the api is really horrid (though
presumably that would be "fixed" by an API layer on top of it) and it seems to
offer only a subset of kwallet's features.
I wouldn't call it "horrid", and i'm not sure about the "subset". But it
has a slightly different object model. Lets try to find out (but i'm not
an expert on this, so forgive me if i'm wrong):

multiple Wallets --> multiple Keyrings
every Wallet/Keyring contains multiple Folders/Items

I guess the standard Folders in KWallet (PasswordFolder and
FormDataFolder) are used for the Web-Browser?

Inside the Folders/Items both Systems provide Maps of Entries/Attributes
(with String keys).

* In Kwallet those Entries can be of the following Types: Password,
String, Map, ByteArray

* In Keyring only String and Int are supported at the moment (but this
could probably be extended easily), and there is only one Password per Item.

KWallet
+--- (n) Wallets
+----- (n) Folders
+----- (n) Entries (Password, String, Map or ByteArray)

Keyring
+---- (n) Keyrings
+---- (n) Items
+-------(1) ItemInfo (type and Password)
+------ (n) Attributes (String or Integer)

Keyring seems to have ACL on the Item level (and generally more
sophisticated regarding access control), and KWallet seems more flexible
regarding the data-types that can be stored.

I think the crunchpoint are those "object models" - which are similar
but not in the details, how they are used or supposed to be used, how
they can be mapped into a management UI (like gnome-keyring-manager)...

Cheers,
Norbert
Aaron J. Seigo
2008-06-04 23:58:08 UTC
Permalink
Post by nf2
I think the crunchpoint are those "object models" - which are similar
yes. perhaps we can draw the best from both (ACL ideas from libgnome-keyring,
data flexibility from kwallet) and come up with something that is better than
either alone and move towards that as something that could be used across
projects[1]; sort of like what d-bus attempted with IPC.

[1] personally, i think the term "cross-desktop" is simultaneously limiting
and tired
--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
nf2
2008-06-12 09:50:15 UTC
Permalink
Post by Aaron J. Seigo
Post by nf2
I think the crunchpoint are those "object models" - which are similar
yes. perhaps we can draw the best from both (ACL ideas from libgnome-keyring,
data flexibility from kwallet) and come up with something that is better than
either alone and move towards that as something that could be used across
projects[1]; sort of like what d-bus attempted with IPC.
I think i have read similar statements on xdg several times (DVFS...).
Unfortunately this "let's start from scratch and create something
better" approach never worked out. So i'd rather not consider it as an
option.

Norbert
Thiago Macieira
2008-06-12 11:05:44 UTC
Permalink
Post by nf2
Post by Aaron J. Seigo
Post by nf2
I think the crunchpoint are those "object models" - which are similar
yes. perhaps we can draw the best from both (ACL ideas from
libgnome-keyring, data flexibility from kwallet) and come up with
something that is better than either alone and move towards that as
something that could be used across projects[1]; sort of like what d-bus
attempted with IPC.
I think i have read similar statements on xdg several times (DVFS...).
Unfortunately this "let's start from scratch and create something
better" approach never worked out. So i'd rather not consider it as an
option.
Agreed. Let's standardise on KWallet then? :-)
--
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
Thiago Macieira
2008-06-12 11:23:05 UTC
Permalink
Post by nf2
Post by Aaron J. Seigo
Post by nf2
I think the crunchpoint are those "object models" - which are similar
yes. perhaps we can draw the best from both (ACL ideas from
libgnome-keyring, data flexibility from kwallet) and come up with
something that is better than either alone and move towards that as
something that could be used across projects[1]; sort of like what d-bus
attempted with IPC.
I think i have read similar statements on xdg several times (DVFS...).
Unfortunately this "let's start from scratch and create something
better" approach never worked out. So i'd rather not consider it as an
option.
The difference between the two cases are so big that it's even hard to see how
you'd be comparing the two.

In one case, you wanted KDE to replace its entire essential VFS infrastructure
with a new, unproven, unreleased one, which depended on libraries KDE
developers don't use/like and used a language that KDE developers don't
use/like.

On the other case, we're talking about *adding* (not replacing) a standard for
Inter-Process Communication over a standardised protocol used by KDE and
GNOME already. Or, alternatively, standardising the file format. And we're
also talking about an optional service of the desktop (many people don't like
to have the wallet).
--
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
nf2
2008-06-13 11:06:38 UTC
Permalink
Post by Thiago Macieira
In one case, you wanted KDE to replace its entire essential VFS infrastructure
with a new, unproven, unreleased one, which depended on libraries KDE
developers don't use/like and used a language that KDE developers don't
use/like.
That's the attitude i will never ever understand. Perhaps because i am
an outsider to both "projects".

Norbert
Michael Pyne
2008-06-13 18:17:27 UTC
Permalink
Post by nf2
Post by Thiago Macieira
In one case, you wanted KDE to replace its entire essential VFS
infrastructure with a new, unproven, unreleased one, which depended on
libraries KDE developers don't use/like and used a language that KDE
developers don't use/like.
That's the attitude i will never ever understand. Perhaps because i am
an outsider to both "projects".
Wait wait wait. You will never understand why developers do not want to
replace code which is working and well understood with code which is untested
and has a different interface?

Seriously?

Making GNOME VFS and KIO compatible is something I understand, as that would
increase the amount of compatibility between applications, and could lead to
unifying the code into a separate library worked on both all DEs, not just
GNOME or KDE if done right.

Doing this by gutting KIO in our case or by gutting GNOME VFS if you're a
GNOME developer is just foolhardiness.

Or is the part you don't understand language preference? I mean, maybe it
doesn't look like it to you but C is increasingly becoming a dinosaur for the
types of things most programmers are doing, and C++ is not much farther ahead.
Dynamic languages like Python and JavaScript are much easier to develop in and
"fast enough" for a lot of cases (and are getting faster everyday).

Even when C is what you want, whether for native code, library interfaces, or
what have you, you're still shouldn't be coding in it. :) Look at Vala
(http://live.gnome.org/Vala). It's a language which was created to bring a
C#-like interface to GObject. It compiles down to C so it's still compatible
but you're not using C, you're using a better language.

So if language doesn't matter why are there coders coming up with new
languages that essentially just write their program for them in a different
syntax?

So please get off your high horse about choosing a language. The reason we
don't use C is because anything C is good for, C++ is better for. We manage
to maintain both source and binary compatibility just fine, KDE runs
efficiently even on comparatively under-powered systems and if we really want
to write imperative programs, C++ does that too. Maybe C++ is not the best
language, which is why I'm glad we have kdebindings. But it's better than C
99% of the time, and C-compatible for the other 1%.

I'm glad that tools are increasingly being developed to allow GTK+ users to
focus less on correctly simulating subclassing using pure C and using macros
everywhere to cast to the right widget type, but we've had this at least fixed
for a very long time.

Regards,
- Michael Pyne
nf2
2008-06-14 10:25:48 UTC
Permalink
Post by nf2
Post by Thiago Macieira
In one case, you wanted KDE to replace its entire essential VFS
infrastructure with a new, unproven, unreleased one, which depended on
libraries KDE developers don't use/like and used a language that KDE
developers don't use/like.
That's the attitude i will never ever understand. Perhaps because i am
an outsider to both "projects".
Wait wait wait. You will never understand why developers do not want
to replace code which is working and well understood with code which
is untested and has a different interface?
No, i meant this programming language "don't use/like" statement. I do
understand some loyalty to KIO.

Norbert
Michael Pyne
2008-06-14 18:21:25 UTC
Permalink
Post by nf2
Post by nf2
Post by Thiago Macieira
In one case, you wanted KDE to replace its entire essential VFS
infrastructure with a new, unproven, unreleased one, which depended on
libraries KDE developers don't use/like and used a language that KDE
developers don't use/like.
That's the attitude i will never ever understand. Perhaps because i am
an outsider to both "projects".
Wait wait wait. You will never understand why developers do not want
to replace code which is working and well understood with code which
is untested and has a different interface?
No, i meant this programming language "don't use/like" statement. I do
understand some loyalty to KIO.
Well that has always been true since the dawn of time. Even back in the 60s
people fought over FORTRAN vs. Lisp. In the 80s it was Lisp and Smalltalk vs.
C.

You may not understand people's aversion to C (although I think I've tried to
explain it), and that's certainly not true of all KDE programmers in general
anyways. But you should be able to understand that people have preferences
for programming language, and based on the fact that KDE is written in C++ it
shouldn't be hard to see that the developers it would tend to attract would
also like C++, or a high level binding.

Regards,
- Michael Pyne
Jakob Petsovits
2008-06-15 19:12:00 UTC
Permalink
Post by nf2
Wait wait wait. You will never understand why developers do not want
to replace code which is working and well understood with code which
is untested and has a different interface?
No, i meant this programming language "don't use/like" statement.
Doing Free Software development is all about loving to write that code.
Now if you have to use constructs that are different to others used in that
same piece of code, with different concepts and object hierarchies, then that
increases the disgust about writing such code.

For KDE (and Qt) as a platform, pleasing the developers is an important goal,
one that might override other important goals even if those others have
direct advantages in terms of whatever user-visible stuff. Maybe some of that
gap can be closed with bindings like was nicely done for D-Bus, but the
developers need to stay happy with such a solution.

They are KDE's most important capital, and if they love writing code for
KDE/Qt then our platform and desktop environment will keep improving.
That's why seemingly irrational reasonings like the language one make sense
even though they can't be measured in "hard facts".

If you want to get KDE to adopt stuff then you need to find a way to make
KDE developers love your stuff. Not lots of end users, not fd.o, not GNOME.
Having those as additional backing is nice, but won't be enough.
nf2
2008-06-19 11:58:47 UTC
Permalink
Post by Jakob Petsovits
Post by nf2
Wait wait wait. You will never understand why developers do not want
to replace code which is working and well understood with code which
is untested and has a different interface?
No, i meant this programming language "don't use/like" statement.
Doing Free Software development is all about loving to write that code.
Now if you have to use constructs that are different to others used in that
same piece of code, with different concepts and object hierarchies, then that
increases the disgust about writing such code.
For KDE (and Qt) as a platform, pleasing the developers is an important goal,
one that might override other important goals even if those others have
direct advantages in terms of whatever user-visible stuff. Maybe some of that
gap can be closed with bindings like was nicely done for D-Bus, but the
developers need to stay happy with such a solution.
They are KDE's most important capital, and if they love writing code for
KDE/Qt then our platform and desktop environment will keep improving.
That's why seemingly irrational reasonings like the language one make sense
even though they can't be measured in "hard facts".
If you want to get KDE to adopt stuff then you need to find a way to make
KDE developers love your stuff. Not lots of end users, not fd.o, not GNOME.
Having those as additional backing is nice, but won't be enough.
Of course! But i guess those developers want their software to be
successful in the "consumer market" also. And for that a lot of
compromises need to be made and some paradigms need to be dropped. One
is the "desktop environment" paradigm. For historic reasons KIO and
KWallet landed in this "KDE desktop environment", only accessible for
KDE apps. But as a matter of fact KDE can't be successful without GTK+
and 3rd party applications (and the other way round). People - in the
first place - and more than they need beautiful Desktops - need apps
apps and more apps - and a single coherent platform to run those apps.

I think "desktop" (Plasma,...) and even "GUI-toolkit" competition is
good, but "desktop environment" competition has been destructive for the
goal of competing with commercial operating systems. That's why things
like KIO and KWallet (if they are more than language bindings or high
level APIs) have to go. Sorry. Also - i believe - the "just written
standards" approach of fd.o is too slow. But it was good to get started.
The shared services approach is better, and the next logical step is
also sharing more in-process libraries and APIs. And for both it's
necessary to pick a programming language & lib stack to collaborate,
which only in border cases will be the beloved Qt/C++.

That's how i think, but maybe it's because i'm rating certain goals too
high.

Norbert
Robert Knight
2008-06-19 16:45:11 UTC
Permalink
Post by nf2
For historic reasons KIO and
KWallet landed in this "KDE desktop environment"
Those 'historic reasons' presumably include the licensing issue that Qt is GPL - which,
as I understand it, would not be acceptable for gnome. If Nokia were prepared to re-license the non-GUI
components of Qt (eg. QtCore, QtNetwork) more permissively that might change. Of course it would not make
business sense for them to do that for the whole suite.

One alternative is writing the code with glib (using their type system) and then writing a C++ wrapper
which provides a Qt/KDE style interface to give a consistent feel for KDE programmers. Unfortunately
that means:

1) Writing more code in the first place because glib/C is less efficient that Qt in terms of features/lines-of-code
2) Writing lots of glue code between the two layers, which will have some performance hit.

Regards,
Robert.
Post by nf2
Post by Jakob Petsovits
Post by nf2
Wait wait wait. You will never understand why developers do not want
to replace code which is working and well understood with code which
is untested and has a different interface?
No, i meant this programming language "don't use/like" statement.
Doing Free Software development is all about loving to write that code.
Now if you have to use constructs that are different to others used in that
same piece of code, with different concepts and object hierarchies, then that
increases the disgust about writing such code.
For KDE (and Qt) as a platform, pleasing the developers is an important goal,
one that might override other important goals even if those others have
direct advantages in terms of whatever user-visible stuff. Maybe some of that
gap can be closed with bindings like was nicely done for D-Bus, but the
developers need to stay happy with such a solution.
They are KDE's most important capital, and if they love writing code for
KDE/Qt then our platform and desktop environment will keep improving.
That's why seemingly irrational reasonings like the language one make sense
even though they can't be measured in "hard facts".
If you want to get KDE to adopt stuff then you need to find a way to make
KDE developers love your stuff. Not lots of end users, not fd.o, not GNOME.
Having those as additional backing is nice, but won't be enough.
Of course! But i guess those developers want their software to be
successful in the "consumer market" also. And for that a lot of
compromises need to be made and some paradigms need to be dropped. One
is the "desktop environment" paradigm. For historic reasons KIO and
KWallet landed in this "KDE desktop environment", only accessible for
KDE apps. But as a matter of fact KDE can't be successful without GTK+
and 3rd party applications (and the other way round). People - in the
first place - and more than they need beautiful Desktops - need apps
apps and more apps - and a single coherent platform to run those apps.
I think "desktop" (Plasma,...) and even "GUI-toolkit" competition is
good, but "desktop environment" competition has been destructive for the
goal of competing with commercial operating systems. That's why things
like KIO and KWallet (if they are more than language bindings or high
level APIs) have to go. Sorry. Also - i believe - the "just written
standards" approach of fd.o is too slow. But it was good to get started.
The shared services approach is better, and the next logical step is
also sharing more in-process libraries and APIs. And for both it's
necessary to pick a programming language & lib stack to collaborate,
which only in border cases will be the beloved Qt/C++.
That's how i think, but maybe it's because i'm rating certain goals too
high.
Norbert
nf2
2008-07-25 13:17:14 UTC
Permalink
Post by Robert Knight
Post by nf2
For historic reasons KIO and
KWallet landed in this "KDE desktop environment"
Those 'historic reasons' presumably include the licensing issue that Qt is GPL - which,
as I understand it, would not be acceptable for gnome. If Nokia were prepared to re-license the non-GUI
components of Qt (eg. QtCore, QtNetwork) more permissively that might change.
Even then i don't know if QtCore based libraries would work in-process
outside Qt based applications. I guess you need to instantiate
QCoreApplication for the event loop etc...
Post by Robert Knight
One alternative is writing the code with glib (using their type system) and then writing a C++ wrapper
which provides a Qt/KDE style interface to give a consistent feel for KDE programmers.
Yeah - i am currently playing with Qt/C++ bindings for the GIO API to
investigate this. It's a bit tricky, particularly with interfaces,
multiple inheritance... For instance this case:

WrappedObject (carries the GObject)
| |
InputSteam Seekable(Interface)
\ /
FileInputStream

I tried to solve this by deriving from WrappedObject with the virtual
keyword, but i don't know whether this is good or evil. ;-)

Another problem is copy-constructors/operators. Passing around wrapped
GObjects that way works quite nicely, cause you don't need to care about
garbage collection, but Qt Signal connections are lost when copying the
object.

The third problem i got is thread-safe unregistering C-callback-handlers
(which emit the QSignals). But for the moment i don't care, as the async
operations will most likely be used from the main-thread only.
Post by Robert Knight
Unfortunately
1) Writing more code in the first place because glib/C is less efficient that Qt in terms of features/lines-of-code
Fortunately a lot of code already exists, but for new things i agree.

I wonder if a kind of mixed style would work: libraries with public
GObject/C APIs, but internally stdc++. Staying with GObject/C for the
API's probably makes sense for language bindings (AFAIK lot's of them
can be auto-generated), C is still the lowest common denominator,
abstract interfaces can be modeled with GInterfaces easily (like GIO
does a lot) ...
Post by Robert Knight
2) Writing lots of glue code between the two layers, which will have some performance hit.
I guess mostly it won't matter a lot - only if a method is called really
often (and doesn't do "slow" things like IPC internally anyway). QString
to char* conversion in getters and setters has some performance hit
maybe... And of course symbol tables are becoming a little bit fatter.

Cheers,
Norbert
Richard Dale
2008-07-25 15:48:08 UTC
Permalink
Post by nf2
I wonder if a kind of mixed style would work: libraries with public
GObject/C APIs, but internally stdc++.
Staying with GObject/C for the
API's probably makes sense for language bindings (AFAIK lot's of them
can be auto-generated), C is still the lowest common denominator,
abstract interfaces can be modeled with GInterfaces easily (like GIO
does a lot) ...
Well I don't have much of a personal interest in the rest of this issue, but
in terms of auto-generation, KDE bindings are way, way ahead of anything that
GObject based binding generators can do.

-- Richard
Kevin Krammer
2008-07-25 16:47:38 UTC
Permalink
Post by nf2
Post by Robert Knight
Post by nf2
For historic reasons KIO and
KWallet landed in this "KDE desktop environment"
Those 'historic reasons' presumably include the licensing issue that Qt
is GPL - which, as I understand it, would not be acceptable for gnome.
If Nokia were prepared to re-license the non-GUI components of Qt (eg.
QtCore, QtNetwork) more permissively that might change.
Even then i don't know if QtCore based libraries would work in-process
outside Qt based applications. I guess you need to instantiate
QCoreApplication for the event loop etc...
Probably the same requirements for the other way around, i.e. Qt being built
with GLib mainloop support and a QEventLoop object.
Post by nf2
Yeah - i am currently playing with Qt/C++ bindings for the GIO API to
investigate this. It's a bit tricky, particularly with interfaces,
WrappedObject (carries the GObject)
InputSteam Seekable(Interface)
\ /
FileInputStream
I tried to solve this by deriving from WrappedObject with the virtual
keyword, but i don't know whether this is good or evil. ;-)
Not sure if you actually have to do all this, e.g. streams, having a GIO data
source/sink as a QIODevice will most likely be enough.
Post by nf2
Another problem is copy-constructors/operators. Passing around wrapped
GObjects that way works quite nicely, cause you don't need to care about
garbage collection, but Qt Signal connections are lost when copying the
object.
Assuming you mean connections of some internal object (since QObjects
themselves can't be copied anyway), why not just have this shared object in a
shared (reference counted) private?
Post by nf2
I wonder if a kind of mixed style would work: libraries with public
GObject/C APIs, but internally stdc++. Staying with GObject/C for the
I think TagLib and libpoppler are examples of C++ based libraries which are
used in GLib based applications, so they could probably serve as an example
how the GLib Wrapper is done for programmers using C.

Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
Pino Toscano
2008-07-25 17:02:47 UTC
Permalink
Post by Kevin Krammer
Post by nf2
I wonder if a kind of mixed style would work: libraries with public
GObject/C APIs, but internally stdc++. Staying with GObject/C for the
I think TagLib and libpoppler are examples of C++ based libraries which are
used in GLib based applications, [...]
I confirm those two, and add also DjVuLibre (C API, not even GLib, in a C++
implementation).
And to make the example even more concrete, poppler and djvulibre are already
used by a "GLib-based application", named Evince.
--
Pino Toscano
nf2
2008-07-27 15:33:16 UTC
Permalink
Post by Kevin Krammer
Post by nf2
Yeah - i am currently playing with Qt/C++ bindings for the GIO API to
investigate this. It's a bit tricky, particularly with interfaces,
WrappedObject (carries the GObject)
InputSteam Seekable(Interface)
\ /
FileInputStream
I tried to solve this by deriving from WrappedObject with the virtual
keyword, but i don't know whether this is good or evil. ;-)
Not sure if you actually have to do all this, e.g. streams, having a GIO data
source/sink as a QIODevice will most likely be enough.
I already got a simple QIODevice implementation called "FileDevice"
which wraps FileInputStream.

Here is an example:

http://websvn.kde.org/trunk/playground/libs/kommodity/samples/kgio-iodevice-sample.cpp

But i'm not really satisfied yet. Don't know how to implement the
QIODevice::atEnd() and bytesAvailable () functions. GIO is a pull API so
i can't really "answer" those methods. Perhaps with some read-ahead, but
then seeking is difficult.

And of course this should work non-blocking - using the GIO-async
methods. I guess this also needs reading ahead into a buffer, cause
otherwise i don't know when to emit the QIODevice::readyRead () signal.

Perhaps Qt/GIO bindings should provide both - a QIODevice implementation
- and a thin wrapper for all the GIO classes: Directory listings,
file-info, drive/mount management, launching apps, and also the GIO
streams (maybe useful for the advanced users, dunno).
Post by Kevin Krammer
Post by nf2
Another problem is copy-constructors/operators. Passing around wrapped
GObjects that way works quite nicely, cause you don't need to care about
garbage collection, but Qt Signal connections are lost when copying the
object.
Assuming you mean connections of some internal object (since QObjects
themselves can't be copied anyway), why not just have this shared object in a
shared (reference counted) private?
Well - actually most of the public KGIO classes can be copied. And they
do derive from QObject.
Post by Kevin Krammer
Post by nf2
I wonder if a kind of mixed style would work: libraries with public
GObject/C APIs, but internally stdc++. Staying with GObject/C for the
I think TagLib and libpoppler are examples of C++ based libraries which are
used in GLib based applications, so they could probably serve as an example
how the GLib Wrapper is done for programmers using C.
Thanks for the hint. I'll have a look.

Cheers,
Norbert
Kevin Krammer
2008-07-27 17:45:13 UTC
Permalink
Post by nf2
Post by Kevin Krammer
Not sure if you actually have to do all this, e.g. streams, having a GIO
data source/sink as a QIODevice will most likely be enough.
I already got a simple QIODevice implementation called "FileDevice"
which wraps FileInputStream.
What I meant is that it might not be necessary to wrap the GIO stream just to
use it internally.
Might be easier to just access the API directly.
Post by nf2
But i'm not really satisfied yet. Don't know how to implement the
QIODevice::atEnd() and bytesAvailable () functions. GIO is a pull API so
i can't really "answer" those methods. Perhaps with some read-ahead, but
then seeking is difficult.
I guess this depends on the actual data source. If it cannot report sizes,
your device implementation just returns true in isSequential().
bytesAvailable() can then also only report the amount of data you have already
received, i.e. how much can be read without blocking.

See the behavior of Qt's sockets or QProcess
Post by nf2
Perhaps Qt/GIO bindings should provide both - a QIODevice implementation
- and a thin wrapper for all the GIO classes: Directory listings,
file-info, drive/mount management, launching apps, and also the GIO
streams (maybe useful for the advanced users, dunno).
I'd say it make sense to wrap stuff that has no respective Qt API. As for the
streams it might make more sense to keep this as a low priority later-on
feature once all the needed work is in place.
Post by nf2
Post by Kevin Krammer
Assuming you mean connections of some internal object (since QObjects
themselves can't be copied anyway), why not just have this shared object
in a shared (reference counted) private?
Well - actually most of the public KGIO classes can be copied. And they
do derive from QObject.
QObject has copying disabled (Q_DISABLE_COPY macro), so nobody expects
QObject's to be copyable anyway.

Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
Thiago Macieira
2008-07-27 17:48:24 UTC
Permalink
Post by nf2
But i'm not really satisfied yet. Don't know how to implement the
QIODevice::atEnd() and bytesAvailable () functions. GIO is a pull API so
i can't really "answer" those methods. Perhaps with some read-ahead, but
then seeking is difficult.
Implement it in sequential mode then, instead of random access:

bytesAvailable() returns the number of bytes you have buffered, the
maximum amount that calling read() can return. In other words, if you try
to read more than bytesAvailable(), you will get bytesAvailable() bytes.

atEnd() = true ←→ bytesAvailable() = 0
Post by nf2
And of course this should work non-blocking - using the GIO-async
methods. I guess this also needs reading ahead into a buffer, cause
otherwise i don't know when to emit the QIODevice::readyRead () signal.
True. QIODevice is a push API: you must read as fast as you can from your
lower-level device, unless you fill up your buffer (see
QAbstractSocket::setReadBufferSize) and then emit readyRead() whenever
you get more data.
Post by nf2
Perhaps Qt/GIO bindings should provide both - a QIODevice implementation
- and a thin wrapper for all the GIO classes: Directory listings,
file-info, drive/mount management, launching apps, and also the GIO
streams (maybe useful for the advanced users, dunno).
That makes sense. Those other functionalities aren't streams, so they
don't make sense as QIODevice, clearly. That functionality is also
present in KIO: the directory listings, mount requests, etc., are not
descendants of KIO::TransferJob.

It should be possible to write an abstracted layer of I/O, one that can
use KIO as well as GIO (and even QNetworkAccessManager, but that's a lot
more limited in scope). It could, in the future, replace KIO -- i.e., be
the cleanup of KIO that didn't happen for KDE 4.

As for launching apps... there's klauncher. Or are you talking about
launching applications in a remote host?
Post by nf2
Post by Kevin Krammer
Post by nf2
Another problem is copy-constructors/operators. Passing around
wrapped GObjects that way works quite nicely, cause you don't need to
care about garbage collection, but Qt Signal connections are lost
when copying the object.
Assuming you mean connections of some internal object (since QObjects
themselves can't be copied anyway), why not just have this shared
object in a shared (reference counted) private?
Well - actually most of the public KGIO classes can be copied. And they
do derive from QObject.
That's not possible.

Either they are copiable, or they derive from QObject. Doing both is not
possible.

Remember: in the copy constructor and in operator=, you *always* call the
base classes' implementations. And you can't do that with QObject.

I urge you not to try to make QObject-descendant classes copiable. That
would open up for thinking the QObject connections, QPointers, etc., do
transfer, but they can't.

If you want copiable things, use pointers. I'm implementing a generic
pointer-holding class with atomic reference-counting for Qt 4.5, so you
don't have to write anything.
--
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
nf2
2008-07-28 23:03:38 UTC
Permalink
Post by Thiago Macieira
Post by nf2
But i'm not really satisfied yet. Don't know how to implement the
QIODevice::atEnd() and bytesAvailable () functions. GIO is a pull API so
i can't really "answer" those methods. Perhaps with some read-ahead, but
then seeking is difficult.
bytesAvailable() returns the number of bytes you have buffered, the
maximum amount that calling read() can return. In other words, if you try
to read more than bytesAvailable(), you will get bytesAvailable() bytes.
atEnd() = true ←→ bytesAvailable() = 0
Thanks for the help - i'll try sequential mode with buffering and
read-ahead then. :-) If people want random access (which is a rare case
i guess) they can still use the GIO streams.
Post by Thiago Macieira
Post by nf2
Perhaps Qt/GIO bindings should provide both - a QIODevice implementation
- and a thin wrapper for all the GIO classes: Directory listings,
file-info, drive/mount management, launching apps, and also the GIO
streams (maybe useful for the advanced users, dunno).
That makes sense. Those other functionalities aren't streams, so they
don't make sense as QIODevice, clearly. That functionality is also
present in KIO: the directory listings, mount requests, etc., are not
descendants of KIO::TransferJob.
It should be possible to write an abstracted layer of I/O, one that can
use KIO as well as GIO (and even QNetworkAccessManager, but that's a lot
more limited in scope). It could, in the future, replace KIO -- i.e., be
the cleanup of KIO that didn't happen for KDE 4.
Yeah - that would be cool. I wonder how i could make my KGIO API more
abstract, that you don't necessarily have to plug GIO.

Some thoughts:

* Should a next-generation KIO be simplified, only providing the
convenience-, high-level APIs (like KIO::Netaccess) and GUI related
functions (password, file dialogs, progress bars), backed with a more
GIO style library for the basic types (File, FileInfo, Errors), advanced
operations (streaming, seeking) and low-level features? I guess the
second library could sit below KDE - on the same layer as Phonon, QtDBus...

* Aligning some things with GIO (FileInfo/UDS fields and error codes)
would be good probably...

* Should all calls go through GIO - at least on Unixes? Because then all
apps get access to the same IO system. If so, i wonder which of the
current KIO protocols/features can not be provided through the GIO
interface and what to do with them? This seems pretty delicate.

* Would there still be need for the Slaves system, cause GVFS will
handle most of the protocols anyway?
Post by Thiago Macieira
As for launching apps... there's klauncher. Or are you talking about
launching applications in a remote host?
Launching apps. As GIO provides that feature - why hide it. Might still
be useful for Qt-only apps.
Post by Thiago Macieira
Post by nf2
Post by Kevin Krammer
Post by nf2
Another problem is copy-constructors/operators. Passing around
wrapped GObjects that way works quite nicely, cause you don't need to
care about garbage collection, but Qt Signal connections are lost
when copying the object.
Assuming you mean connections of some internal object (since QObjects
themselves can't be copied anyway), why not just have this shared
object in a shared (reference counted) private?
Well - actually most of the public KGIO classes can be copied. And they
do derive from QObject.
That's not possible.
Either they are copiable, or they derive from QObject. Doing both is not
possible.
I guess it's technically possible, but if it's not the common Qt style i
agree that it shouldn't be done. Probably i need to think over the KGIO
design. Either i need to split off lots of little job-classes for the
async operations, or make the classes non-copyable. Kind of sad, because
things like

QList<Mount> VolumeMonitor::getMounts()

have to become

QList<Mount*> VolumeMonitor::getMounts()

which seems less convenient.
Post by Thiago Macieira
If you want copiable things, use pointers. I'm implementing a generic
pointer-holding class with atomic reference-counting for Qt 4.5, so you
don't have to write anything.
That's cool. Taking the above example, would something like this be
possible?

QList<QRefCountedPointer<QMount>> VolumeMonitor::getMounts()


Cheers,
Norbert
Thiago Macieira
2008-07-29 06:43:14 UTC
Permalink
Post by nf2
Post by Thiago Macieira
bytesAvailable() returns the number of bytes you have buffered, the
maximum amount that calling read() can return. In other words, if you
try to read more than bytesAvailable(), you will get bytesAvailable()
bytes.
atEnd() = true ←→ bytesAvailable() = 0
Thanks for the help - i'll try sequential mode with buffering and
read-ahead then. :-) If people want random access (which is a rare case
i guess) they can still use the GIO streams.
Don't forget to add the QIODevice buffer size too:

qint64 MyClass::bytesAvailable() const
{
return QIODevice::bytesAvailable() + sizeOfMyBuffer;
}
Post by nf2
Yeah - that would be cool. I wonder how i could make my KGIO API more
abstract, that you don't necessarily have to plug GIO.
* Should a next-generation KIO be simplified, only providing the
convenience-, high-level APIs (like KIO::Netaccess) and GUI related
functions (password, file dialogs, progress bars), backed with a more
GIO style library for the basic types (File, FileInfo, Errors), advanced
operations (streaming, seeking) and low-level features? I guess the
second library could sit below KDE - on the same layer as Phonon, QtDBus...
KIO::NetAccess is definitely not enough. The API we provide must be
asynchronous. Just like today, there's a convenience API on top of it for
synchronous operation (KIO::NetAccess is it).

I don't understand the GIO basic types are. Are those filesystem-local? Or
are they like KIO::mimetype()? The API should be fully network
transparent.

Seeking and streaming are only used today in a few places.
Post by nf2
* Aligning some things with GIO (FileInfo/UDS fields and error codes)
would be good probably...
If it's an abstraction layer on top of GIO, I don't see why.

It has to have concepts that map to GIO concepts, but it shouldn't use GIO
names or expose GIO API at all.
Post by nf2
* Should all calls go through GIO - at least on Unixes? Because then all
apps get access to the same IO system. If so, i wonder which of the
current KIO protocols/features can not be provided through the GIO
interface and what to do with them? This seems pretty delicate.
If possible, the backend should be changeable.

I don't know which KIO features cannot be provided, but you can also
wonder if those slaves should be there in the first place. For example,
KMail is having problems today with its old structure of using pop3,
imap4 and smtp as ioslaves -- when they are clearly not.
Post by nf2
Post by Thiago Macieira
As for launching apps... there's klauncher. Or are you talking about
launching applications in a remote host?
Launching apps. As GIO provides that feature - why hide it. Might still
be useful for Qt-only apps.
Because we shouldn't complicate the API.

If the recommended way of launching apps is klauncher, then that's what
people should use.
Post by nf2
Post by Thiago Macieira
That's not possible.
Either they are copiable, or they derive from QObject. Doing both is
not possible.
I guess it's technically possible, but if it's not the common Qt style i
agree that it shouldn't be done.
No, it's not possible at all. You can fake it, but it's not a real copy in
the C++ sense of it.
Post by nf2
Probably i need to think over the KGIO
design. Either i need to split off lots of little job-classes for the
async operations, or make the classes non-copyable. Kind of sad, because
things like
QList<Mount> VolumeMonitor::getMounts()
have to become
QList<Mount*> VolumeMonitor::getMounts()
which seems less convenient.
Post by Thiago Macieira
If you want copiable things, use pointers. I'm implementing a generic
pointer-holding class with atomic reference-counting for Qt 4.5, so
you don't have to write anything.
That's cool. Taking the above example, would something like this be
possible?
QList<QRefCountedPointer<QMount>> VolumeMonitor::getMounts()
Yes.

But the current way Qt and KDE API is designed is that we divide things
into two main groups:

- "value type" classes: they are implicit shared, detach atomically on
write, never used as pointers, never use QObject. Can be implemented
using QSharedData/QSharedDataPointer.

- "object type" classes: cannot be copied, usually derive from QObject,
used both on the stack and as pointers to the heap.

The use of automatic pointers has never been an issue for us:
QObject-based objects' lifetimes can be tracked using the parent-child
relationship.
--
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
Ingo Klöcker
2008-07-29 19:25:57 UTC
Permalink
Post by Thiago Macieira
Post by nf2
* Should all calls go through GIO - at least on Unixes? Because then
all apps get access to the same IO system. If so, i wonder which of
the current KIO protocols/features can not be provided through the
GIO interface and what to do with them? This seems pretty delicate.
If possible, the backend should be changeable.
I don't know which KIO features cannot be provided, but you can also
wonder if those slaves should be there in the first place. For
example, KMail is having problems today with its old structure of
using pop3, imap4 and smtp as ioslaves -- when they are clearly not.
FWIW, pop3 isn't really a problem (except for the "Check what the server
supports" functionality) and smtp also works. It is mainly imap4 which
does not really map to kioslave.


Regards,
Ingo
nf2
2008-07-30 00:32:18 UTC
Permalink
Post by Thiago Macieira
Post by nf2
Post by Thiago Macieira
If you want copiable things, use pointers. I'm implementing a generic
pointer-holding class with atomic reference-counting for Qt 4.5, so
you don't have to write anything.
That's cool. Taking the above example, would something like this be
possible?
QList<QRefCountedPointer<QMount>> VolumeMonitor::getMounts()
Yes.
But the current way Qt and KDE API is designed is that we divide things
- "value type" classes: they are implicit shared, detach atomically on
write, never used as pointers, never use QObject. Can be implemented
using QSharedData/QSharedDataPointer.
- "object type" classes: cannot be copied, usually derive from QObject,
used both on the stack and as pointers to the heap.
I wonder if i made a mistake when designing my API. Perhaps many of the
async functions in my GFile and GInputStream wrappers

http://library.gnome.org/devel/gio/stable/GFile.html#g-file-read-async
http://library.gnome.org/devel/gio/stable/GInputStream.html#g-input-stream-read-async

shouldn't emit signals, but rather just take a slot as an argument?

In this case - do i still need to derive my wrapper classes from QObject?

Cheers,
Norbert
Thiago Macieira
2008-07-30 06:29:07 UTC
Permalink
Post by nf2
Post by Thiago Macieira
But the current way Qt and KDE API is designed is that we divide
 - "value type" classes: they are implicit shared, detach atomically
on write, never used as pointers, never use QObject. Can be
implemented using QSharedData/QSharedDataPointer.
 - "object type" classes: cannot be copied, usually derive from
QObject, used both on the stack and as pointers to the heap.
 
I wonder if i made a mistake when designing my API. Perhaps many of the
async functions in my GFile and GInputStream wrappers
http://library.gnome.org/devel/gio/stable/GFile.html#g-file-read-async
http://library.gnome.org/devel/gio/stable/GInputStream.html#g-input-stre
am-read-async
shouldn't emit signals, but rather just take a slot as an argument?
In this case - do i still need to derive my wrapper classes from QObject?
I haven't looked at the links.

But remember this: a value-type class usually simply holds information:
QString, QRect, QNetworkCookie, for example, come to mind. They don't
*do* anything, so they don't have signals, slots or callbacks.

Object-type classes, on the other hand, do. Signals generally include a
verb in the past tense, actions are verbs in the imperative. These
objects are not ref-counted and are not copiable.

If you were to copy an object that represents a file, it would not copy
the file. The two objects would still represent the same file. Even if
you allowed the two to write to different portions of the file, it's
still a bad idea.
--
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
Kevin Krammer
2008-07-30 08:56:14 UTC
Permalink
Post by nf2
I wonder if i made a mistake when designing my API. Perhaps many of the
async functions in my GFile and GInputStream wrappers
http://library.gnome.org/devel/gio/stable/GFile.html#g-file-read-async
http://library.gnome.org/devel/gio/stable/GInputStream.html#g-input-stream-
read-async
shouldn't emit signals, but rather just take a slot as an argument?
In this case - do i still need to derive my wrapper classes from QObject?
From the description of GFile it looks like it is not an active object in GIO
either, just a collection of information about a file
"...It is necessary to understand that GFile objects do not represent files,
merely an identifier for a file..."

Probably more like a QFileInfo

Which would put all the data related operations into a QFile/QIODevice like
class which does not need to be copied.

As for the stream: if you really need that in your top level API, signals
should be OK but you can of course also use a call back interface.
I don't think there will be any use case where you need to copy a stream
object, so inheriting from QObject should be no problem.

Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
nf2
2008-07-30 11:40:07 UTC
Permalink
Post by Kevin Krammer
Post by nf2
I wonder if i made a mistake when designing my API. Perhaps many of the
async functions in my GFile and GInputStream wrappers
http://library.gnome.org/devel/gio/stable/GFile.html#g-file-read-async
http://library.gnome.org/devel/gio/stable/GInputStream.html#g-input-stream-
read-async
shouldn't emit signals, but rather just take a slot as an argument?
In this case - do i still need to derive my wrapper classes from QObject?
From the description of GFile it looks like it is not an active object in GIO
either, just a collection of information about a file
"...It is necessary to understand that GFile objects do not represent files,
merely an identifier for a file..."
Probably more like a QFileInfo
Perhaps also a bit like KUrl, but with methods to start various file
operations.
Post by Kevin Krammer
Which would put all the data related operations into a QFile/QIODevice like
class which does not need to be copied.
As for the stream: if you really need that in your top level API, signals
should be OK but you can of course also use a call back interface.
I don't think there will be any use case where you need to copy a stream
object, so inheriting from QObject should be no problem.
It's quite tricky. Have a look at my "readfileasync" example:

http://websvn.kde.org/trunk/playground/libs/kommodity/samples/kgio-readfileasync-sample.h
http://websvn.kde.org/trunk/playground/libs/kommodity/samples/kgio-readfileasync-sample.cpp

The first async operation read() (Actually it's an "open") is started
from File (i have split off the async operations from File to
FileasyncOperation, but that doesn't matter).

m_fileAsyncOperation = FileAsyncOperation(file);
connect(&m_fileAsyncOperation, SIGNAL(inputStreamReady(*const* File&, *const* FileInputStream &, *const* Error &)),
*this*, SLOT(inputStreamReady(*const* File&, *const* FileInputStream &, *const* Error &)));

m_fileAsyncOperation.read();


On sucess a FileInputStream will be returned by the signal. Then i
connect signals to the inputstream and start reading. The problem is
that here i'm saving the FileInputStream to a member variable of my
application object. Perhaps it's not necessary to keep a reference to
the FileInputStream - Hmm...

*void* *MyDemoApplication::inputStreamReady*(*const* File & file, *const* FileInputStream & inputStream, *const* Error & error)
{
m_fileInputStream = inputStream;

...

connect(&m_fileInputStream, SIGNAL(readAsyncReady(InputStream * , *const* qint64, *const* Error &)),
*this*, SLOT(readAsyncReady(InputStream * , *const* qint64, *const* Error &)));
connect(&m_fileInputStream, SIGNAL(closeAsyncReady(InputStream *, *const* Error &)),
*this*, SLOT(closeAsyncReady(InputStream *, *const* Error &)));

m_fileInputStream.readAsync(buffer, 80, 100, m_cancellable);

}


If FileInputStream wasn't a copyable explicitly sharing wrapper this
would be difficult. Storing the pointer somewhere else doesn't increment
the reference count.

Cheers,
Norbert
Kevin Krammer
2008-07-30 17:06:42 UTC
Permalink
Post by nf2
Post by Kevin Krammer
Probably more like a QFileInfo
Perhaps also a bit like KUrl, but with methods to start various file
operations.
Right.
Though the functions to create operations on it might also be better somewhere
else, e.g. in a namespace like KIO's operations.
Post by nf2
Post by Kevin Krammer
Which would put all the data related operations into a QFile/QIODevice
like class which does not need to be copied.
As for the stream: if you really need that in your top level API, signals
should be OK but you can of course also use a call back interface.
I don't think there will be any use case where you need to copy a stream
object, so inheriting from QObject should be no problem.
http://websvn.kde.org/trunk/playground/libs/kommodity/samples/kgio-readfile
async-sample.h
http://websvn.kde.org/trunk/playground/libs/kommodity/samples/kgio-readfile
async-sample.cpp
The first async operation read() (Actually it's an "open") is started
from File (i have split off the async operations from File to
FileasyncOperation, but that doesn't matter).
m_fileAsyncOperation = FileAsyncOperation(file);
connect(&m_fileAsyncOperation, SIGNAL(inputStreamReady(*const* File&,
*const* FileInputStream &, *const* Error &)), *this*,
SLOT(inputStreamReady(*const* File&, *const* FileInputStream &, *const*
Error &)));
m_fileAsyncOperation.read();
Hmm,
A couple of comments:
1) why does the signal transport a file? Is it not also accessible through the
stream?

2) If the stream object is intended to be kept after the slot ends, it should
perhaps be a pointer

3) error in a "ready" signal looks very wrong
Post by nf2
On sucess a FileInputStream will be returned by the signal. Then i
connect signals to the inputstream and start reading. The problem is
that here i'm saving the FileInputStream to a member variable of my
application object. Perhaps it's not necessary to keep a reference to
the FileInputStream - Hmm...
It seems the stream's signals also transport the stream itself, so probably
not. Depends on whether you need to call stream methods outside signals
connected to it.
Post by nf2
If FileInputStream wasn't a copyable explicitly sharing wrapper this
would be difficult. Storing the pointer somewhere else doesn't increment
the reference count.
You could probably use a boost shared_ptr or something similar if you really
need a "value" object, though using a real pointer should work as well, since
its lifetime currently seems to be controlled by the FileAsyncOperation
object (it emit a reference so it stays the owner of whatever pointer it uses
internally if it uses one at all)

Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
nf2
2008-07-30 16:08:07 UTC
Permalink
Post by nf2
Post by Thiago Macieira
If you want copiable things, use pointers. I'm implementing a generic
pointer-holding class with atomic reference-counting for Qt 4.5, so
you don't have to write anything.
That's cool. Taking the above example, would something like this be
possible?
QList<QRefCountedPointer<QMount>> VolumeMonitor::getMounts()
Yes.
Will the refcounter be inside QObject or inside the pointer-holding class?

Because in the latter case you would loose the refcount as soon as you
just pass the pointer to a function or try to cast the pointer:

QRefCountedPointer<A> a = new A();

call_some_function(a.p);

or

QRefCountedPointer<B> = dynamic_cast<B*> a.p;



Norbert
Alexander Neundorf
2008-07-30 19:38:28 UTC
Permalink
Hi Norbert,

On Wednesday 30 July 2008, nf2 wrote:
...
Post by nf2
Will the refcounter be inside QObject or inside the pointer-holding class?
Because in the latter case you would loose the refcount as soon as you
QRefCountedPointer<A> a = new A();
call_some_function(a.p);
or
QRefCountedPointer<B> = dynamic_cast<B*> a.p;
I didn't really follow the thread and actually I don't know whether I like
what you want to do or not.

But, I find it really cool that you are very persistently working on these
things and actually also get results :-)

Alex

P.S. will you be at Akademy ?
nf2
2008-08-01 14:58:13 UTC
Permalink
Post by Alexander Neundorf
Hi Norbert,
...
Post by nf2
Will the refcounter be inside QObject or inside the pointer-holding class?
Because in the latter case you would loose the refcount as soon as you
QRefCountedPointer<A> a = new A();
call_some_function(a.p);
or
QRefCountedPointer<B> = dynamic_cast<B*> a.p;
I didn't really follow the thread and actually I don't know whether I like
what you want to do or not.
I'm not that sure whether what i'm proposing is good or bad either.
Maybe it's good to keep things separate and just have fd.o standards on
file-formats or D-Bus interfaces. Maybe that's not sufficient. Should
there be a kind or "winapi" for the freedesktop platform? Dunno. It's
still exciting trying to find out how things could fit together.
Post by Alexander Neundorf
But, I find it really cool that you are very persistently working on these
things and actually also get results :-)
I'm not sure about the results ;-). I tried lot's of things (vio,
libfusi, xdg-vfs) that never got anywhere. Why did i pick the VFS as my
favorite topic? Maybe because i think it's symptomatic for the problems
of the free desktops. Actually my first "contact" with this stuff were
those annoying "unmount - device is busy" messages and i wanted to find
out why this sucks so much...

Years ago i tried to get the GLib main loop into Qt by writing a really
terrible prototype. I don't know whether this has inspired TT, or if
they already planned to do this earlier. What i learned is that one
actually has to write code when trying to convince people. Although my
C++ and C is still quite clumsy...
Post by Alexander Neundorf
Alex
P.S. will you be at Akademy ?
I'd love to. But unfortunately i don't have time this year.

Cheers,
Norbert

Thiago Macieira
2008-07-30 21:29:45 UTC
Permalink
Post by nf2
Will the refcounter be inside QObject or inside the pointer-holding class?
QObjects don't have an internal reference counter. So the counter has to
be outside.

I'm trying to make it so that QSharedPointer supports both pointers
internal and external.
Post by nf2
Because in the latter case you would loose the refcount as soon as you
QRefCountedPointer<A> a = new A();
call_some_function(a.p);
call_some_function(a);

This is C++, we have cast operators :-)
Post by nf2
or
QRefCountedPointer<B> = dynamic_cast<B*> a.p;
QSharedPointer<B> = a.dynamicCast<B>();
QSharedPointer<B> = qSharedPointerDynamicCast<B>(a);


In any case, if the object passes itself as pointers to other points (such
as in a signal emission or in "return this"), then the reference counting
has to be internal to the object. That's the only way to keep a
consistent count.

Also be careful if any object that can be reference counted holds an
object by reference counting. Eventually that may lead to cyclic
reference counting.
--
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
Aaron J. Seigo
2008-07-25 17:08:31 UTC
Permalink
Post by nf2
Post by Robert Knight
Post by nf2
For historic reasons KIO and
KWallet landed in this "KDE desktop environment"
Those 'historic reasons' presumably include the licensing issue that Qt
is GPL - which, as I understand it, would not be acceptable for gnome.
If Nokia were prepared to re-license the non-GUI components of Qt (eg.
QtCore, QtNetwork) more permissively that might change.
Even then i don't know if QtCore based libraries would work in-process
outside Qt based applications. I guess you need to instantiate
QCoreApplication for the event loop etc...
of course they would.

a) many of the classes in Qt don't use the event loop at all (collection
classes, string class, etc)

b) by using the glib event loop, the rest is a non-issue

note that the use of the blig event loop was done specifically to address this
issue because nobody else in this Mexican Standoff had the guts to do what was
necessary.

for that reason alone, it's obvious, at least to me, that if you want to find
the group that will get you furthest for project agnostic work, it's Qt. if we
relied on other projects, we still wouldn't even have a share event loop.
that's a massive indictment of non-Qt toolkits, imho.
Post by nf2
I wonder if a kind of mixed style would work: libraries with public
GObject/C APIs, but internally stdc++.
the phrase "disgustingly ugly" comes to mind.
Post by nf2
Staying with GObject/C for the
API's probably makes sense for language bindings
as Richard already pointed out, this is not true.
Post by nf2
(AFAIK lot's of them
can be auto-generated), C is still the lowest common denominator,
a lowest common denominator, besides implying it's the least worst thing
everyone can agree to, only matters if there is buy in from others. i honestly
don't see that at this point.
Post by nf2
abstract interfaces can be modeled with GInterfaces easily (like GIO
does a lot) ...
the same can be done with other frameworks. glib isn't magical in this regard.
--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
Stefan Teleman
2008-07-25 17:20:43 UTC
Permalink
Post by Aaron J. Seigo
the same can be done with other frameworks. glib isn't magical in this regard.
http://www.gtkmm.org/download.shtml

GLib-2 and Gtk+-2 already have C++ wrappers (and so do pango, atk and cairo).

My question is: instead of to writing OO in C (which has been fondly
described by some as "putting makeup on a pig: the pig doesn't enjoy
it, and the end result is frightening" :-), wouldn't it be more
efficient to use the already existing C++ wrappers ?

Just my 0.02 question.

--Stefan
--
Stefan Teleman
KDE e.V.
***@gmail.com
koos vriezen
2008-07-25 19:42:23 UTC
Permalink
Post by Stefan Teleman
Post by Aaron J. Seigo
the same can be done with other frameworks. glib isn't magical in this regard.
http://www.gtkmm.org/download.shtml
GLib-2 and Gtk+-2 already have C++ wrappers (and so do pango, atk and cairo).
My question is: instead of to writing OO in C (which has been fondly
described by some as "putting makeup on a pig: the pig doesn't enjoy
it, and the end result is frightening" :-), wouldn't it be more
efficient to use the already existing C++ wrappers ?
No, because when we need something that uses another toolkit to play
nicely in KDE, the dependencies should be as small as possible. Just a
quick example:
$ nm -D /usr/lib/libgtkmm-2.4.so.1.0.30 |grep ' T ' |wc -l
8932
$ nm -D /usr/lib/libgtk-x11-2.0.so |grep ' T ' |wc -l
3535
so almost a triple extra symbols to resolve at load time.

Maybe some 'use Qt for every job' may dislike gtk or plain C in
general, but a. they either have no clue what happening beneath it
and/or b. are too stubborn to look over their horizon anyhow. Others
will pick up the job.
Btw. Vala is a nice alternative to get a nice OO language w/o extra
dependencies (for as long as it takes of course)

Koos
Post by Stefan Teleman
Just my 0.02 question.
--Stefan
--
Stefan Teleman
KDE e.V.
koos vriezen
2008-07-25 20:12:13 UTC
Permalink
Post by koos vriezen
Post by Stefan Teleman
Post by Aaron J. Seigo
the same can be done with other frameworks. glib isn't magical in this regard.
http://www.gtkmm.org/download.shtml
GLib-2 and Gtk+-2 already have C++ wrappers (and so do pango, atk and cairo).
My question is: instead of to writing OO in C (which has been fondly
described by some as "putting makeup on a pig: the pig doesn't enjoy
it, and the end result is frightening" :-), wouldn't it be more
efficient to use the already existing C++ wrappers ?
No, because when we need something that uses another toolkit to play
nicely in KDE, the dependencies should be as small as possible. Just a
$ nm -D /usr/lib/libgtkmm-2.4.so.1.0.30 |grep ' T ' |wc -l
8932
$ nm -D /usr/lib/libgtk-x11-2.0.so |grep ' T ' |wc -l
3535
so almost a triple extra symbols to resolve at load time.
Maybe some 'use Qt for every job' may dislike gtk or plain C in
general, but a. they either have no clue what happening beneath it
and/or b. are too stubborn to look over their horizon anyhow. Others
will pick up the job.
Oops, this sounds a bit to harsh I guess. With 'no clue' I meant 'no
clue or interests'. We all have our thing, whether it's GUI, databases
or system programming.
The point I wanted to make is that putting synthetic sugar over lower
level API's makes only things slower, while a pure GUI developer
doesn't maintain this code anyhow. For the one who does, wrappers
probably more confuse than help.

Koos
Post by koos vriezen
Btw. Vala is a nice alternative to get a nice OO language w/o extra
dependencies (for as long as it takes of course)
Koos
Post by Stefan Teleman
Just my 0.02 question.
--Stefan
--
Stefan Teleman
KDE e.V.
Stefan Teleman
2008-07-25 20:18:29 UTC
Permalink
Post by koos vriezen
No, because when we need something that uses another toolkit to play
nicely in KDE, the dependencies should be as small as possible. Just a
$ nm -D /usr/lib/libgtkmm-2.4.so.1.0.30 |grep ' T ' |wc -l
8932
$ nm -D /usr/lib/libgtk-x11-2.0.so |grep ' T ' |wc -l
3535
so almost a triple extra symbols to resolve at load time.
Maybe some 'use Qt for every job' may dislike gtk or plain C in
general, but a. they either have no clue what happening beneath it
and/or b. are too stubborn to look over their horizon anyhow. Others
will pick up the job.
Btw. Vala is a nice alternative to get a nice OO language w/o extra
dependencies (for as long as it takes of course)
Yes, and duplicating already existing work -- especially when backed
by the "too many symbols in shared library" argument -- is *always*
the best alternative. Even more so when said existing work does have
some successful history of being maintained, and being used in other
applications.

--Stefan
--
Stefan Teleman
KDE e.V.
***@gmail.com
koos vriezen
2008-07-25 20:51:05 UTC
Permalink
Post by Stefan Teleman
Post by koos vriezen
No, because when we need something that uses another toolkit to play
nicely in KDE, the dependencies should be as small as possible. Just a
$ nm -D /usr/lib/libgtkmm-2.4.so.1.0.30 |grep ' T ' |wc -l
8932
$ nm -D /usr/lib/libgtk-x11-2.0.so |grep ' T ' |wc -l
3535
so almost a triple extra symbols to resolve at load time.
Maybe some 'use Qt for every job' may dislike gtk or plain C in
general, but a. they either have no clue what happening beneath it
and/or b. are too stubborn to look over their horizon anyhow. Others
will pick up the job.
Btw. Vala is a nice alternative to get a nice OO language w/o extra
dependencies (for as long as it takes of course)
Yes, and duplicating already existing work -- especially when backed
by the "too many symbols in shared library" argument -- is *always*
the best alternative. Even more so when said existing work does have
I don't understand. Why is that argument special?
Post by Stefan Teleman
some successful history of being maintained, and being used in other
applications.
Well, maybe I missed the point and is it about nice API for end
application developers. My impression though was syntactic (yes no
synthetic :) sugar for the GIO <-> KIO layer. In which I wonder how
many hack on this anyhow. So the best alternative IMO is not to wrap.

Koos
Post by Stefan Teleman
--Stefan
--
Stefan Teleman
KDE e.V.
Stefan Teleman
2008-07-25 21:52:37 UTC
Permalink
Post by koos vriezen
Post by Stefan Teleman
Yes, and duplicating already existing work -- especially when backed
by the "too many symbols in shared library" argument -- is *always*
the best alternative. Even more so when said existing work does have
I don't understand. Why is that argument special?
Because:

1. The original argument against lib*mm ("there are more symbols in
the C++ wrapper Library than in the original C Library") is bogus.
Yes, writing a C++ wrapper around a C library and maintaining the
original C functionality will end up generating more symbols in the
C++ library ratio to the original C implementation.
Hint: C++ generates a whole bunch of symbols which have no place in C
in the first place.

Also, i didn't realize that counting the number of symbols in a
particular library implementation is a design choice consideration in
the first place. If the number of symbols was indeed a design choice
consideration, one could easily make this argument with QT4 vs. QT3.

Are there any guidelines for the "number of acceptable symbols" in a
C++ shared library, other than "i don't like this number" ? Is there a
C equivalent for these hypothetical guidelines ?

2. Work has already been done. It works (for any given value of
"works"). It is used in other apps. Is "existing, reusable code" no
longer a design consideration ? I thought this is what C++ was
supposed to be about. But maybe i am old fashioned and i have no kept
up with the latest and greatest software development trends.

Other than the "my
C++-wrapper-API-is-better-than-your-C++-wrapper-API" argument, what is
the point of creating yet another C++ wrapper around GLib/Gtk+/bla ?

I can name off the top of my head two major applications which use the
lib*mm frameworks: Kino and Inkscape.

Can you name one app written in Vala, or in the
"as-of-yet-unwritten-but-gooder-C++-wrapper-around-glib-gtk-atk-pango-cairo"
?

--Stefan
--
Stefan Teleman
KDE e.V.
***@gmail.com
koos vriezen
2008-07-25 22:14:39 UTC
Permalink
Post by Stefan Teleman
Post by koos vriezen
Post by Stefan Teleman
Yes, and duplicating already existing work -- especially when backed
by the "too many symbols in shared library" argument -- is *always*
the best alternative. Even more so when said existing work does have
I don't understand. Why is that argument special?
1. The original argument against lib*mm ("there are more symbols in
the C++ wrapper Library than in the original C Library") is bogus.
Yes, writing a C++ wrapper around a C library and maintaining the
original C functionality will end up generating more symbols in the
C++ library ratio to the original C implementation.
Yes that, but for all those symbols are extra, ie. you don't loose the
C symbols.
Post by Stefan Teleman
Hint: C++ generates a whole bunch of symbols which have no place in C
in the first place.
Yes
Post by Stefan Teleman
Also, i didn't realize that counting the number of symbols in a
particular library implementation is a design choice consideration in
the first place. If the number of symbols was indeed a design choice
consideration, one could easily make this argument with QT4 vs. QT3.
That was exactly what TT did with Qt4, reduce the number of symbols by
splitting up the library so that an editor don't drag along SQL
symbols, reduce the API in general and enable the visibility-hidden
for internal functions.
Post by Stefan Teleman
Are there any guidelines for the "number of acceptable symbols" in a
C++ shared library, other than "i don't like this number" ? Is there a
C equivalent for these hypothetical guidelines ?
The less the better, I would say ...
Post by Stefan Teleman
2. Work has already been done. It works (for any given value of
"works"). It is used in other apps. Is "existing, reusable code" no
longer a design consideration ? I thought this is what C++ was
supposed to be about. But maybe i am old fashioned and i have no kept
up with the latest and greatest software development trends.
Not using that code is even better, no?
Post by Stefan Teleman
Other than the "my
C++-wrapper-API-is-better-than-your-C++-wrapper-API" argument, what is
the point of creating yet another C++ wrapper around GLib/Gtk+/bla ?
Yes exactly my argument, why wrap?
Post by Stefan Teleman
I can name off the top of my head two major applications which use the
lib*mm frameworks: Kino and Inkscape.
And there are many more that run on plain Gtk
Post by Stefan Teleman
Can you name one app written in Vala, or in the
"as-of-yet-unwritten-but-gooder-C++-wrapper-around-glib-gtk-atk-pango-cairo"
?
But why should we, that's my point. The nice thing about C++ is that
you can use any C library out-of-the-box.

Koos
Post by Stefan Teleman
--Stefan
--
Stefan Teleman
KDE e.V.
Aaron J. Seigo
2008-07-25 20:56:40 UTC
Permalink
Post by koos vriezen
Btw. Vala is a nice alternative to get a nice OO language w/o extra
dependencies (for as long as it takes of course)
yes, after all, who needs to debug their apps.

(for those who don't get the joke: you can't debug vala code as it compiles
down to C, so your gdb'ing is in a completely different codebase that doesn't
map nicely to the original sources. oops.)
--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
Ariya Hidayat
2008-07-25 21:04:48 UTC
Permalink
Post by Aaron J. Seigo
yes, after all, who needs to debug their apps.
(for those who don't get the joke: you can't debug vala code as it compiles
down to C, so your gdb'ing is in a completely different codebase that doesn't
map nicely to the original sources. oops.)
Not perfect yet, but going there:
http://blogs.gnome.org/juergbi/2007/09/05/vala-and-nemiver/
--
Ariya Hidayat, Software Engineer, Trolltech (a Nokia company)
http://www.google.com/search?q=ariya+hidayat
Thiago Macieira
2008-07-25 17:46:59 UTC
Permalink
Post by Aaron J. Seigo
Post by nf2
Even then i don't know if QtCore based libraries would work in-process
outside Qt based applications. I guess you need to instantiate
QCoreApplication for the event loop etc...
of course they would.
a) many of the classes in Qt don't use the event loop at all (collection
classes, string class, etc)
You don't need QCoreApplication for its event loop, but you do need it for its
initialisation.

QString::fromLocal8Bit doesn't work if QCoreApplication wasn't instantiated.
--
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
nf2
2008-07-27 00:37:37 UTC
Permalink
Post by Aaron J. Seigo
Post by nf2
I wonder if a kind of mixed style would work: libraries with public
GObject/C APIs, but internally stdc++.
the phrase "disgustingly ugly" comes to mind.
Why? I think a lot of things that are tiring with plain C - like
strings, containers and garbage collection might be a bit easier with a
bit of C++. For instance a simple GObjectWrapper<T> which automatically
g_object_un_ref's in the destructor - and g_object_refs on copy might
help. Or a C++ wrapper for GError (that you don't need g_error_free()s
all over the place)... If someone wants to write a GObject based library
in C++, perhaps it's worth looking for an appropriate (but still
simplistic) style.

Btw, another reason why GLib/GObject might be more suitable than Qt for
the basic platform stuff is simply that it's moving slowly (actually it
will stay as is for long, almost like winapi). The point i'm trying to
make is that what's good for the higher layers (GUI, desktop and apps) -
where Qt seems to fit perfect, might not be ideal further below.

Let's take the KDE desktop environment as an example: Because it's all
monolithic Qt/C++ the whole infrastructure had to be ported from Qt3 to
Qt4 as well. So when you run a KDE3 app on KDE4 you actually have two
desktop environments running (with all the daemons etc). Good? Or
wouldn't it be better if "the platform" could move at a slower/different
pace?

Just like coding Nautilus in plain C seems a bit baroque, writing things
like KIO on top of a UI-Toolkit wasn't perfect either IMHO.
Post by Aaron J. Seigo
Post by nf2
(AFAIK lot's of them
can be auto-generated), C is still the lowest common denominator,
a lowest common denominator, besides implying it's the least worst thing
everyone can agree to, only matters if there is buy in from others. i honestly
don't see that at this point.
Well - for a long time plain C has been the lowest common denominator
(and in rare cases C++). With no main-loop integretion, no signals, no
type system,...
Post by Aaron J. Seigo
Post by nf2
abstract interfaces can be modeled with GInterfaces easily (like GIO
does a lot) ...
the same can be done with other frameworks. glib isn't magical in this regard.
Yeah - but which one would you suggest?

Regards,
Norbert
Aaron J. Seigo
2008-07-27 00:55:20 UTC
Permalink
Post by nf2
Post by Aaron J. Seigo
Post by nf2
I wonder if a kind of mixed style would work: libraries with public
GObject/C APIs, but internally stdc++.
the phrase "disgustingly ugly" comes to mind.
Why? I think a lot of things that are tiring with plain C - like
strings, containers and garbage collection might be a bit easier with a
bit of C++.
so write in C++ but hobble it with an API designed to make up for C's
shortcomings? that's what i meant by "disgustingly ugly"
Post by nf2
Let's take the KDE desktop environment as an example: Because it's all
monolithic Qt/C++ the whole infrastructure had to be ported from Qt3 to
Qt4 as well.
it isn't monolithic anymore, and neither is Qt. nor does Qt have any near term
scheduled changes.

so if you feel that the Qt3 issues were bad, you're a few years too late to be
complaining about them. Qt4 is a different animal.
Post by nf2
So when you run a KDE3 app on KDE4 you actually have two
desktop environments running (with all the daemons etc). Good? Or
wouldn't it be better if "the platform" could move at a slower/different
pace?
besides the current state not really mapping to what you describe here all
(look at HAL and it's proposed replacement), we made a lot of decisions to
help make this "slow/different" pace possible.
--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
nf2
2008-07-27 02:27:00 UTC
Permalink
Post by Aaron J. Seigo
Post by nf2
Post by Aaron J. Seigo
Post by nf2
I wonder if a kind of mixed style would work: libraries with public
GObject/C APIs, but internally stdc++.
the phrase "disgustingly ugly" comes to mind.
Why? I think a lot of things that are tiring with plain C - like
strings, containers and garbage collection might be a bit easier with a
bit of C++.
so write in C++ but hobble it with an API designed to make up for C's
shortcomings? that's what i meant by "disgustingly ugly"
I think you are a bit undervaluing GObject. I think it does a lot more
than reinventing C++... things which are quite difficult with plain C++
as well.
Post by Aaron J. Seigo
besides the current state not really mapping to what you describe here all
(look at HAL and it's proposed replacement), we made a lot of decisions to
help make this "slow/different" pace possible.
Don't misunderstand me. I really appreciate all that :-)

Cheers,
Norbert
Aaron J. Seigo
2008-07-27 02:40:50 UTC
Permalink
Post by nf2
Post by Aaron J. Seigo
Post by nf2
Post by Aaron J. Seigo
Post by nf2
I wonder if a kind of mixed style would work: libraries with public
GObject/C APIs, but internally stdc++.
the phrase "disgustingly ugly" comes to mind.
Why? I think a lot of things that are tiring with plain C - like
strings, containers and garbage collection might be a bit easier with a
bit of C++.
so write in C++ but hobble it with an API designed to make up for C's
shortcomings? that's what i meant by "disgustingly ugly"
I think you are a bit undervaluing GObject. I think it does a lot more
than reinventing C++... things which are quite difficult with plain C++
as well.
... and that's where Qt comes in. it has a very clean, consistent and powerful
API that makes up for things that are quite difficult with plain C++.

the GObject stuff is understandable when dealing with C. but when dealing with
C++, it really isn't the API the to mimic / use. there's much better Free
Software alternatives that exist right now.

the Qt world has become quite comfortable with using glib when it comes to C
related stuff out of pragmatism. the rest of the world ought to learn simiar
pragmatism; it's nonsense to uglify code when the only reason is to molify a
bunch who lack similar pragmatism.
--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
nf2
2008-07-27 09:38:24 UTC
Permalink
Post by Aaron J. Seigo
Post by nf2
Post by Aaron J. Seigo
Post by nf2
Post by Aaron J. Seigo
Post by nf2
I wonder if a kind of mixed style would work: libraries with public
GObject/C APIs, but internally stdc++.
the phrase "disgustingly ugly" comes to mind.
Why? I think a lot of things that are tiring with plain C - like
strings, containers and garbage collection might be a bit easier with a
bit of C++.
so write in C++ but hobble it with an API designed to make up for C's
shortcomings? that's what i meant by "disgustingly ugly"
I think you are a bit undervaluing GObject. I think it does a lot more
than reinventing C++... things which are quite difficult with plain C++
as well.
... and that's where Qt comes in. it has a very clean, consistent and powerful
API that makes up for things that are quite difficult with plain C++.
Great!
koos vriezen
2008-07-27 15:49:02 UTC
Permalink
Why? I think a lot of things that are tiring with plain C - like strings,
containers and garbage collection might be a bit easier with a bit of C++.
For instance a simple GObjectWrapper<T> which automatically
g_object_un_ref's in the destructor - and g_object_refs on copy might help.
Or a C++ wrapper for GError (that you don't need g_error_free()s all over
the place)... If someone wants to write a GObject based library in C++,
perhaps it's worth looking for an appropriate (but still simplistic) style.
I don't think there is that much to gain, whether you do
glib_type_new/g_object_unref vs. new GFoo/delete gfoo. Only you can
create the object on the stack, which saves you the delete call (not
for QObject's though)

Of course this very much depends on the use case. Eg. I maintain a
program both for KDE as for Maemo, and being able to apply patches
easy, I did do some C++ wrapping on simple types as QString and KUrl
(the GUI is completely different anyhow).
A common code pattern might be a class candidate, often a function
will do as well. But doing heavy wrapping in the beginning of the
coding often shows unwanted frictions later, turning to hacks and the
code gets uglier and uglier.
Wrapping toolkits to others is just a pain, Luckily we can use C
directly like glib, expat, libjpeg you-name-it.

Stick with the toolkit API.

Koos
nf2
2008-07-27 18:26:36 UTC
Permalink
Post by koos vriezen
Why? I think a lot of things that are tiring with plain C - like strings,
containers and garbage collection might be a bit easier with a bit of C++.
For instance a simple GObjectWrapper<T> which automatically
g_object_un_ref's in the destructor - and g_object_refs on copy might help.
Or a C++ wrapper for GError (that you don't need g_error_free()s all over
the place)... If someone wants to write a GObject based library in C++,
perhaps it's worth looking for an appropriate (but still simplistic) style.
I don't think there is that much to gain, whether you do
glib_type_new/g_object_unref vs. new GFoo/delete gfoo. Only you can
create the object on the stack, which saves you the delete call (not
for QObject's though)
Of course this very much depends on the use case. Eg. I maintain a
program both for KDE as for Maemo, and being able to apply patches
easy, I did do some C++ wrapping on simple types as QString and KUrl
(the GUI is completely different anyhow).
A common code pattern might be a class candidate, often a function
will do as well. But doing heavy wrapping in the beginning of the
coding often shows unwanted frictions later, turning to hacks and the
code gets uglier and uglier.
Wrapping toolkits to others is just a pain, Luckily we can use C
directly like glib, expat, libjpeg you-name-it.
Stick with the toolkit API.
I thought of really lightweight wrapping. Very minimalistic. See the
example below. Mainly that you can put GObjects into C++ containers and
for garbage collection...

I believe heavy wrapping - like gtkmm is more interesting for library
"end-users" like application developers, but not here.

Norbert

-------------------- C Code ------------------------

GError * err = NULL;
GFile * gFile = g_file_new_for_uri("ftp://***@server/file");

GFileInfo* gFileInfo = g_file_query_info( gFile,
"*",
G_FILE_QUERY_INFO_NOFOLLOW_SYMLINKS,
NULL,
&err);

if (err)
{
printf("error %s\n", err->message);
g_error_free(err);

g_object_unref (gFile);
return;
}


----------------- C++ Code -------------------

GOError err;
GO<GFile> gFile = g_file_new_for_uri("ftp://***@server/file");

GO<GFileInfo> gFileInfo = g_file_query_info( gFile.p,
"*",
G_FILE_QUERY_INFO_NOFOLLOW_SYMLINKS,
NULL,
err.pp());

if (err.hasError())
{
cout << "error " << err.message();
return;
}
koos vriezen
2008-07-27 18:49:22 UTC
Permalink
I thought of really lightweight wrapping. Very minimalistic. See the example
below. Mainly that you can put GObjects into C++ containers and for garbage
collection...
But you also need to add a copy constructor then and think about
either implicit sharing the GFile object or copying ... GFile doesn't
seem to have ref counting only g_file_dup, so for sharing you must do
your own ref counting.
But if you can easily track the file objects, why not simply store the
pointers in the C++ containers.
-------------------- C Code ------------------------
GError * err = NULL;
GFileInfo* gFileInfo = g_file_query_info( gFile,
"*",
G_FILE_QUERY_INFO_NOFOLLOW_SYMLINKS,
NULL,
&err);
g_file_new_for_uri doesn't have an GError argument.
if (err)
{
printf("error %s\n", err->message);
g_error_free(err);
g_object_unref (gFile);
return;
}
----------------- C++ Code -------------------
GOError err;
GO<GFileInfo> gFileInfo = g_file_query_info( gFile.p,
"*",
G_FILE_QUERY_INFO_NOFOLLOW_SYMLINKS,
NULL,
err.pp());
You could even add a 'operator GError *()' to the GOError class,
instead of the pp()
if (err.hasError())
{
cout << "error " << err.message();
return;
}
Note that not all gfoo's use g_object_unref, eg. GFile uses
g_file_delete. Makes it rather hard to templete this.

I think you should look where exactly this saves code.

Koos
nf2
2008-07-27 19:43:43 UTC
Permalink
Post by koos vriezen
I thought of really lightweight wrapping. Very minimalistic. See the example
below. Mainly that you can put GObjects into C++ containers and for garbage
collection...
But you also need to add a copy constructor then and think about
either implicit sharing the GFile object or copying ... GFile doesn't
seem to have ref counting only g_file_dup, so for sharing you must do
your own ref counting.
GFile inherits from GObject. Therefore it does have ref-counting.
Post by koos vriezen
But if you can easily track the file objects, why not simply store the
pointers in the C++ containers.
Again - garbage collection.

The attached example implements the "GO" template class and tests it a
little - valgrind reports 0 leaks :-)
A bit like a C++ class with QExplicitlySharedDataPointer.

Norbert
koos vriezen
2008-07-27 20:15:22 UTC
Permalink
Post by nf2
Post by koos vriezen
But you also need to add a copy constructor then and think about
either implicit sharing the GFile object or copying ... GFile doesn't
seem to have ref counting only g_file_dup, so for sharing you must do
your own ref counting.
GFile inherits from GObject. Therefore it does have ref-counting.
Ah right, thanks! It's a GInterface ... so it's a GLocalFile for local files.
Post by nf2
Post by koos vriezen
But if you can easily track the file objects, why not simply store the
pointers in the C++ containers.
Again - garbage collection.
The attached example implements the "GO" template class and tests it a
little - valgrind reports 0 leaks :-)
A bit like a C++ class with QExplicitlySharedDataPointer.
Looks clean, if you think you need gc this looks pretty nice.
Btw. for const correctness, should 'T *p' be declared mutable? The
copy constructor does change p by adding a ref count. I'm not into
this precise programming, so dunno

Just a quick thought about this ref counting, there is also
g_object_weak_ref, that could be used to set the p pointer to zero (in
which case only one storage object may exist).
Haven't looked in your code, but having closed/deleted files still in
some container because of the ref counting, may require some extra
code to verify the p pointer is still valid.

Koos
Ingo Klöcker
2008-07-27 20:51:53 UTC
Permalink
Post by nf2
Post by koos vriezen
Post by nf2
I thought of really lightweight wrapping. Very minimalistic. See
the example below. Mainly that you can put GObjects into C++
containers and for garbage collection...
But you also need to add a copy constructor then and think about
either implicit sharing the GFile object or copying ... GFile
doesn't seem to have ref counting only g_file_dup, so for sharing
you must do your own ref counting.
GFile inherits from GObject. Therefore it does have ref-counting.
Post by koos vriezen
But if you can easily track the file objects, why not simply store
the pointers in the C++ containers.
Again - garbage collection.
The attached example implements the "GO" template class and tests it
a little - valgrind reports 0 leaks :-)
A bit like a C++ class with QExplicitlySharedDataPointer.
There's no need to reinvent the wheel:

http://www.boost.org/doc/libs/1_35_0/libs/smart_ptr/intrusive_ptr.html


I doubt people would be happy if you'd introduce a dependency on boost,
but you could still copy the well-tried implementation of
boost::intrusive_ptr<T> instead of rolling your own implementation.


Regards,
Ingo
Thiago Macieira
2008-07-27 21:05:55 UTC
Permalink
Post by Ingo Klöcker
Post by nf2
Post by koos vriezen
Post by nf2
I thought of really lightweight wrapping. Very minimalistic. See
the example below. Mainly that you can put GObjects into C++
containers and for garbage collection...
But you also need to add a copy constructor then and think about
either implicit sharing the GFile object or copying ... GFile
doesn't seem to have ref counting only g_file_dup, so for sharing
you must do your own ref counting.
GFile inherits from GObject. Therefore it does have ref-counting.
Post by koos vriezen
But if you can easily track the file objects, why not simply store
the pointers in the C++ containers.
Again - garbage collection.
The attached example implements the "GO" template class and tests it
a little - valgrind reports 0 leaks :-)
A bit like a C++ class with QExplicitlySharedDataPointer.
http://www.boost.org/doc/libs/1_35_0/libs/smart_ptr/intrusive_ptr.html
I doubt people would be happy if you'd introduce a dependency on boost,
but you could still copy the well-tried implementation of
boost::intrusive_ptr<T> instead of rolling your own implementation.
I'm rolling out QSharedPointer which will have both shared_ptr and
intrusive_ptr functionality for Qt 4.5.

There's no need for a Boost dependency.
--
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
Ingo Klöcker
2008-07-27 21:23:09 UTC
Permalink
Post by Thiago Macieira
Post by Ingo Klöcker
Post by nf2
The attached example implements the "GO" template class and tests
it a little - valgrind reports 0 leaks :-)
A bit like a C++ class with QExplicitlySharedDataPointer.
http://www.boost.org/doc/libs/1_35_0/libs/smart_ptr/intrusive_ptr.ht
ml
I doubt people would be happy if you'd introduce a dependency on
boost, but you could still copy the well-tried implementation of
boost::intrusive_ptr<T> instead of rolling your own implementation.
I'm rolling out QSharedPointer which will have both shared_ptr and
intrusive_ptr functionality for Qt 4.5.
Why do you Trolls have to do everything by yourself? ;-)
Post by Thiago Macieira
There's no need for a Boost dependency.
Sometimes a Boost dependency is acceptable while a Qt dependency is not.
In particular, in case of an LGPL'd library a Qt dependency is not an
option.


Regards,
Ingo
Aaron J. Seigo
2008-07-27 21:30:27 UTC
Permalink
Post by Ingo Klöcker
In particular, in case of an LGPL'd library a Qt dependency is not an
option.
/me looks at kdelibs, then at Ingo

i understand what you're meaning to say here (that if someone wants to write
an LGPL'd library that anyone can use with no GPL strings due to dependencies,
then Qt isn't an option at this point), but the way you phrased it is a bit
misleading to the more innocent reader =)
--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
Ingo Klöcker
2008-07-27 22:10:50 UTC
Permalink
Post by Aaron J. Seigo
Post by Ingo Klöcker
In particular, in case of an LGPL'd library a Qt dependency is not
an option.
/me looks at kdelibs, then at Ingo
i understand what you're meaning to say here (that if someone wants
to write an LGPL'd library that anyone can use with no GPL strings
due to dependencies, then Qt isn't an option at this point), but the
way you phrased it is a bit misleading to the more innocent reader =)
Indeed. Thanks for clarifying what I meant to write.

I owe you a cookie or beer redeemable at Akademy. ;-)


Regards,
Ingo
Kevin Krammer
2008-07-27 22:45:21 UTC
Permalink
On Sunday 27 July 2008, nf2 wrote:

[snip]
    GO &operator=(const GO &other)
    {
        if (p != NULL)
        {
            g_object_unref(p);
        }
        p = other.p;
        g_object_ref(p);
        return *this;
    }
Assignment operators should always check for self-assignment first, otherwise
bad things might happen, like in this case where p gets deleted if the object
is the only reference to it.

Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
Kevin Krammer
2008-06-04 18:07:18 UTC
Permalink
Post by nf2
Post by Aaron J. Seigo
Post by Maksim Orlovich
Sharing the file format would be sufficient.
along with he implied shared location and locking mechanism, you're quite
right: that would be sufficient indeed.
The word "sufficient" somehow suggests that this would be the easier and
more realistic approach. I'm afraid it's not. It makes the whole system
more complex, takes ages to formulate and implement (twice) and after
all has no advantages compared to just adopting and improving *one*
existing implementation.
One issue here is that this is about two separate problems.

One problem is the authentification service, the process a user
authentificates against and with which then other processes exchange
authentification requests. Basically a trustee of the users.

Since there are already capable implementations for that, it is a "low-hanging
fruit" for interoperability, as I already described before.

The second problem is the persistant storage of the authentifaction data.
I agree that having a shared library for dealing with that uniformly would be
benefitial, though there is still need for proper documentation of locations,
formats and crypto algorithms involved.

A nice aspect of these two problem is that they are orthogonal, so they can
but don't have to be tackled concurrently.

Lets say that the final goal is to have a single, probably cooperatively
maintained, service implementation, then there are a couple of approaches to
reach this goal.

One is to design and then write this ultimate solution from scratch, covering
all use cases of all currently exisiting implementations, etc.
Evaluation all these use cases will take some time, though it is quite
possible that doing this will really result in a great implementation.
Drawback is that it takes longer until applications and therefore the users
can actually use it.

Another one is to define a couple of milestones between now and the goal,
where at each milestone something new fades in and something old fades out.
There will almost immediately be a noticable benefit for the users, they can
even likely understand the progress along the road when additional
improvements take effect.
The drawback is that none of the milestones will be an ideal implementation.

Regarding the interface, the two approaches differm mainly in when it has to
be specified.
The first approach allows to postpone the interface definition to the the
moment of release, while the second approach basically depends on it being
available as the first milestone.

Fortunately there are way to detect capabilities of runtime dependencies, so
in the worst case they can be tried in parallel if no agreement can be
reached beforehand.

Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
Thiago Macieira
2008-06-04 21:55:44 UTC
Permalink
Post by nf2
Post by Aaron J. Seigo
along with he implied shared location and locking mechanism, you're
quite right: that would be sufficient indeed.
 
The word "sufficient" somehow suggests that this would be the easier and
more realistic approach. I'm afraid it's not. It makes the whole system
more complex, takes ages to formulate and implement (twice) and after
all has no advantages compared to just adopting and improving *one*
existing implementation.
I don't think either approach would be sufficient.

If the goal is to type the password once, you need a central daemon that
keeps the wallet/keyright/whatchacallit open. It doesn't matter if KDE
knows how to read the GNOME keyright file format or vice-versa, if the
password to decrypt it can't be obtained from somewhere.

Or am I missing something?

I guess you could store the password centrally and then leave it to each
individual program to open the file, lock it for reading, decrypt and
then unlock, but that looks like a suboptimal approach.

I would prefer a standardised interface via D-Bus and a non-standardised
file format.
--
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
Rafael Fernández López
2008-06-05 00:08:58 UTC
Permalink
Hi,
Post by Thiago Macieira
I guess you could store the password centrally and then leave it to each
individual program to open the file, lock it for reading, decrypt and
then unlock, but that looks like a suboptimal approach.
I would prefer a standardised interface via D-Bus and a non-standardised
file format.
From my understanding of this issue I also think this is the best solution
nowadays.

For sure I prefer to maintain code that I'm used to, rather than a mixture of
different flavours, what in the end, becomes unmaintainable.


Regards,
Rafael Fernández López.
Oswald Buddenhagen
2008-06-04 10:23:56 UTC
Permalink
Post by nf2
I was also pondering about sharing the password storage.
for the record:
http://marc.info/?l=freedesktop-xdg&m=117278185111302&w=2
--
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Confusion, chaos, panic - my work here is done.
Sebastian Sauer
2008-06-04 21:23:32 UTC
Permalink
Post by Kevin Krammer
Post by nf2
Post by Aaron J. Seigo
Post by nf2
well... Things in this - call it "application infrastructure" or
"platform layer" - can only be written in GLib+C,
this is complete and utter rubbish. if you mean that there are people
out there who will only accept things written in glib+c because they
are completely inflexible and stuck mentally in the last century, then
i'd agree.
so? which language and dependency stack would you suggest? do we have
that much choice?
I think Aaron was mostly referring to the "only" part of your previous
posting, given that there are already widely accepted solutions e.g.
implemented in C++, like TagLib or libpoppler.
isn't glib even only optional?
Richard Moore
2008-06-04 21:44:26 UTC
Permalink
Post by Sebastian Sauer
isn't glib even only optional?
It's definitely just an optional dependency to Qt (just the
eventloop). It doesn't help that the glib guys have packaged external
stuff into the same release tar ball recently.

Cheers

Rich.
nf2
2008-06-04 22:40:04 UTC
Permalink
Post by Richard Moore
Post by Sebastian Sauer
isn't glib even only optional?
It's definitely just an optional dependency to Qt (just the
eventloop). It doesn't help that the glib guys have packaged external
stuff into the same release tar ball recently.
I think it's because they want to push GIO as *the* standard API for
network transparent file-management - to get it widely adopted quickly.
If they succeed with this strategy, it will be good for everyone.

Norbert
Eduardo Robles Elvira
2008-06-04 23:25:37 UTC
Permalink
Post by nf2
I think it's because they want to push GIO as *the* standard API for
network transparent file-management - to get it widely adopted quickly.
If they succeed with this strategy, it will be good for everyone.
Yeah, I think maybe we should just ditch this old weird KIO thingie (which
have been here in KDE land for years) and just use the Gnome "new" shinny
technology called GIO. What's going on here, seriously?
--
"The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man." (George Bernard Shaw)
Michael Leupold
2008-06-04 21:49:31 UTC
Permalink
[...]
Sorry for re-hijacking this thread :-)

I think talking to the keyring maintainers would be a good start to determine
what they'd be interested to cooperatively work on. So I'll do.

So with this solution still being a long-term goal - probably post-4.2 - what
do you think about adding either of the qca plugins as a dependency to reduce
code and choose a secure hash a little more future-proof than sha-1?

Regards,
Michael
Aaron J. Seigo
2008-06-04 23:59:29 UTC
Permalink
Post by Michael Leupold
[...]
Sorry for re-hijacking this thread :-)
I think talking to the keyring maintainers would be a good start to
determine what they'd be interested to cooperatively work on. So I'll do.
great =)
Post by Michael Leupold
So with this solution still being a long-term goal - probably post-4.2 -
right
Post by Michael Leupold
what do you think about adding either of the qca plugins as a dependency to
reduce code and choose a secure hash a little more future-proof than sha-1?
+1 from me. it's in kdesupport, we ought to use what we have at hand imho.
--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
Continue reading on narkive:
Loading...