dbus-cplusplus-devel — Internal development and usage of the dbus-c++ API

[dbus-cplusplus-devel] HAL support?

[Andreas V. <li...@br...>]

Hello,

while playing with HAL support I get a segfault while mounting or
unmounting a USB device:

modified property volume.mount_point in /org/freedesktop/Hal/devices/volume_uuid_A047_F357
process 8894: You can't recurse into an empty array or off the end of a message body
terminate called after throwing an instance of 'DBus::ErrorInvalidArgs'
  what():  type mismatch

Program received signal SIGABRT, Aborted.
0xb7f3f410 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7f3f410 in __kernel_vsyscall ()
#1  0xb7c86085 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7c87a01 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb7e95480 in __gnu_cxx::__verbose_terminate_handler ()
   from /usr/lib/libstdc++.so.6
#4  0xb7e92d05 in ?? () from /usr/lib/libstdc++.so.6
#5  0xb7e92d42 in std::terminate () from /usr/lib/libstdc++.so.6
#6  0xb7e92e6a in __cxa_throw () from /usr/lib/libstdc++.so.6
#7  0xb7f25fa3 in DBus::MessageIter::get_basic (this=0xbfb6f20c, type_id=115, 
    ptr=0xbfb6f1c4) at message.cpp:79
#8  0xb7f2604a in DBus::MessageIter::get_string (this=0xbfb6f20c)
    at message.cpp:201
#9  0x080523b1 in operator>> (iter=@0xbfb6f20c, val=@0xbfb6f284)
    at ../../include/dbus-c++/types.h:400
#10 0x08052497 in operator>><std::string, bool, bool, DBus::Invalid, DBus::Invalid, DBus::Invalid, DBus::Invalid, DBus::Invalid> (iter=@0xbfb6f298, 
    val=@0xbfb6f284) at ../../include/dbus-c++/types.h:492
#11 0x0804e403 in HalDeviceProxy::PropertyModifiedCb (this=0x805cb98, 
    sig=@0xbfb6f440) at hal-listen.cpp:92
#12 0x08050bfb in DBus::Callback<HalDeviceProxy, void, DBus::SignalMessage const&>::call (this=0x805cd90, param=@0xbfb6f440)
    at ../../include/dbus-c++/util.h:263
#13 0xb7f0f24b in DBus::Slot<void, DBus::SignalMessage const&>::call (
---Type <return> to continue, or q <return> to quit---
    this=0x805cce4, param=@0xbfb6f440) at ../include/dbus-c++/util.h:237
#14 0xb7f0e478 in DBus::InterfaceProxy::dispatch_signal (this=0x805cb98, 
    msg=@0xbfb6f440) at interface.cpp:138
#15 0xb7f13e89 in DBus::ObjectProxy::handle_message (this=0x805cbb8, 
    msg=@0xbfb6f440) at object.cpp:365
#16 0xb7f17a31 in DBus::Callback<DBus::ObjectProxy, bool, DBus::Message const&>::call (this=0x805cc20, param=@0xbfb6f440) at ../include/dbus-c++/util.h:263
#17 0xb7f20291 in DBus::Slot<bool, DBus::Message const&>::call (
    this=0x805cbd4, param=@0xbfb6f440) at ../include/dbus-c++/util.h:237
#18 0xb7f1ed1e in DBus::Connection::Private::message_filter_stub (
    conn=0x8058b78, dmsg=0x8058db0, data=0x805cbd4) at connection.cpp:163
#19 0xb7c329f7 in dbus_connection_dispatch () from /usr/lib/libdbus-1.so.3
#20 0xb7f1ede4 in DBus::Connection::Private::do_dispatch (this=0x80583e8)
    at connection.cpp:131
#21 0xb7f224ad in DBus::Dispatcher::dispatch_pending (this=0x8057460)
    at dispatcher.cpp:174
#22 0xb7f2a70f in DBus::BusDispatcher::do_iteration (this=0x8057460)
    at eventloop-integration.cpp:92
#23 0xb7f2a3e7 in DBus::BusDispatcher::enter (this=0x8057460)
    at eventloop-integration.cpp:79
#24 0x0804f41a in main () at hal-listen.cpp:126

See here the root of the Exception:

void MessageIter::get_basic(int type_id, void *ptr)
{
	if (type() != type_id)
		throw ErrorInvalidArgs("type mismatch");

	dbus_message_iter_get_basic((DBusMessageIter *)_iter, ptr);
}
	
I just debugged that type() return a '0' and type_id is '115'.

We've no bug system at the moment. I'll setup one on sourceforge in the future.

regards
Andreas

Re: [dbus-cplusplus-devel] libhal++?

[Andreas V. <and...@tu...>]

Am Sat, 8 Nov 2008 01:21:03 +0100 schrieb Milosz Derezynski:

Hello Milosz,

maybe you should correct the link on freshmeat.net. I didn't find that
site with google.

In the past I did some changes in dbus-c++. Not sure if talk about the
same wrapper. But this on is the most mature C++ wrapper in my eyes.

http://www.freedesktop.org/wiki/Software/dbus-c++
http://sourceforge.net/projects/dbus-cplusplus/

There're currently two different repos that I try to sync from time to
time.

There's the "hal-listen" example beside the source. I tried it and it
works nice, but no idea how complete the hal support is. Maybe you take
a look into it and tell us what's missing for the current libhal++
features. The example shows me a list of devices and when I add or
remove devices it prints that on the terminal. Sounds good for me.

regards
Andreas

BTW: dbus-c++ has a mailing list. I send this mail to the list too.
Maybe you join the list if you're interested.

> Hey!
> 
> Our website has moved, so the repositories and minisite moved too.
> All infos are available at:
> http://projects.backtrace.info/pmwiki.php?n=Main.Hal
> 
> You probably know that this is a wrapping of the C API, and it's not
> done with gmmproc. (saying it just in case)
> 
> There is a plan to reimplement libhal in C++ using dbusmm, but it has
> only recently become possible to
> do so because of the maturity of dbusmm; when i get the time i will
> attempt this as it's better than
> simply wrapping the C API.
> 
> If you have any questions please let me know!
> 
> Regards,
> M.
> 
> On Sat, Nov 8, 2008 at 12:06 AM, Andreas Volz
> <and...@tu...>wrote:
> 
> > Hello Milosz,
> >
> > any idea what's about libhal++? All links seems to be broken.
> >
> > Could you tell me about the current status? Do you still have the
> > source code and could send it to me?
> >
> > regards
> > Andreas
> >
> > --
> > Technical Blog <http://andreasvolz.wordpress.com/>
> >
> 
> 
> 
> -- 
> Please note that according to the German law on data retention,
> information on every electronic information exchange with me is
> retained for a period of six months.
> [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung
> zufolge jeder elektronische Kontakt mit mir sechs Monate lang
> gespeichert wird.]


-- 
Technical Blog <http://andreasvolz.wordpress.com/>

Re: [dbus-cplusplus-devel] Annotations?

[Andreas V. <li...@br...>]

Am Tue, 9 Sep 2008 23:13:33 +0200 schrieb Andreas Volz:

> Hello,
> 
> now I found out about annotations in dbus-glib XML:
> 
> http://dbus.freedesktop.org/doc/dbus-tutorial.html#glib-annotations
> 
> So I've some questions:
> 
> - Do you think we should use the same concept for dbus-c++?
> 
> - Any ideas why the name is e.g. org.freedesktop.DBus.GLib.Async? I
> think if the name would be org.freedesktop.DBus.Async it wouldn't be
> GLib specific.
> 
> - Refering to my proposal:
> 
>     <signal name="onButtonListener">
>       <arg type="(inyb)" name="eventButton" direction="out"
>       object="KeyEvent"/> 
>     </signal>
> 
> This may better be written:
> 
>     <signal name="onButtonListener">
>       <arg type="(inyb)" name="eventButton" direction="out"> 
>         <annotation name="org.freedesktop.DBus.Object"
>                     value="KeyEvent"/>
>       </arg>
>     </signal>

I changed the code generator in the gitorious repo to the new behaviour
with:

<annotation name="org.freedesktop.DBus.Object" value="KeyEvent"/>

It's tested in one application here and working well. But we need more
testing to include this in the official distribution. You're invited to
test the gitorious branch.

regards
Andreas

Re: [dbus-cplusplus-devel] strange behavior when using gtkmm

[Jesús R. de I. <jes...@ha...>]

I have prepared a quick and dirty version of my testgtkclient in C,
using dbus-glib, and all works as expected.
Could this be a bug in dbus-c++? What am I doing wrong?

-- 
Mit freundlichen Grüßen

Jesus Ruiz de Infante
(Entwicklung)
HALE electronic GmbH
Eugen-Müller-Straße 18, 5020 Salzburg, Austria
Tel:  +43 (662) 439011 0
Fax:  +43 (662) 439011 9
jes...@ha...
Firmenbuchnummer: FN 66801m HG Salzburg


--
Scanned by MailScanner.



--
Scanned by MailScanner.

Re: [dbus-cplusplus-devel] strange behavior when using gtkmm

[Jesús R. de I. <jes...@ha...>]

I have prepared a quick and dirty version of my testgtkclient in C, using dbus-glib, and all works as expected.
Could this be a bug in dbus-c++? What am I doing wrong?

-- 
Mit freundlichen Grüßen

Jesus Ruiz de Infante
(Entwicklung)
HALE electronic GmbH
Eugen-Müller-Straße 18, 5020 Salzburg, Austria
Tel:  +43 (662) 439011 0
Fax:  +43 (662) 439011 9
jes...@ha...
Firmenbuchnummer: FN 66801m HG Salzburg


--
Scanned by MailScanner.

Re: [dbus-cplusplus-devel] strange behavior when using gtkmm

[Jesús R. de I. <jes...@ha...>]

Oops, I attached the wrong test client!

Here are the sources again.

Also, I forgot to clarify that the point of starting two clients is that only one of them
gets to call the sigc callback after receiving the dbus signal, namely the one that didn't start
talking with the server.

The result is the same independently of the number of clients. All work as supposed except the one
calling handle_key_pressed_event() on the server.

Thanks,


-- 
Mit freundlichen Grüßen

Jesus Ruiz de Infante
(Entwicklung)
HALE electronic GmbH
Eugen-Müller-Straße 18, 5020 Salzburg, Austria
Tel:  +43 (662) 439011 0
Fax:  +43 (662) 439011 9
jes...@ha...
Firmenbuchnummer: FN 66801m HG Salzburg


--
Scanned by MailScanner.

[dbus-cplusplus-devel] strange behavior when using gtkmm

[Jesús R. de I. <jes...@ha...>]

It seems that there is a problem when the glib main loop must attend a dbus signal just after it
called a dbus method.

If that dbus signal handler emits a sigc signal, the last signal is actually never emitted (or at least,
a slot connected to it is never executed)

I have the following scenario:

Actors:
- testserver: A server of a simple service
- testclient 1 & testclient 2


                                   test svc server
                           .------------------------------------.
                           |  .-------------------------------. |
                           |  | handle_key_pressed_event      | |
                     .------->|   dbus: _signal_mode_switched | |
                     |     |  |                               | |
                     |     |  '-------------------------------' |
                     |     |                  |                 |
                     |     '------------------|-----------------'
                     |                        |
                     |                        |
      .----------------------------.          |        .----------------------------.
      | sigc: signal_mode_switched |<----------------->| sigc: signal_mode_switched |
      |                            |                   |                            |
      |       .-------------------.|                   |      .-------------------. |
      |       |                   ||                   |      |                   | |
      |       | on_mode_switched: ||                   |      | on_mode_switched: | |
      |       |   change label    ||                   |      |   change label    | |
      |       '-------------------'|                   |      '-------------------' |
      |                            |                   |                            |
      '----------------------------'                   '----------------------------'
             test svc client 1                               test svc client 2




- When the user clicks on the single program button, the client 1 calls the handle_key_pressed_event
dbus method of the server.

- Then the server emits the _signal_mode_switched dbus signal, which is received by both clients.

- On the clients, the _signal_mode_switched signal emits the sigc signal_mode_switched.

- on_mode_switched, which is connected to the signal_mode_switched, simply changes
a gtk label.


The problem is, on_mode_switch is only called on the client that didn't sent signal_mode_switched.

I have attached some sample code.


System Info:
Centos 5.2

dbus-python-0.70-7.el5
dbus-1.0.0-7.el5
dbus-glib-0.70-5
dbus-glib-devel-0.70-5
dbus-devel-1.0.0-7.el5
dbus-x11-1.0.0-7.el5


pygtk2-2.10.1-12.el5
gtk2-engines-2.8.0-3.el5
pygtk2-libglade-2.10.1-12.el5
libgtk-java-2.8.7-3.el5
gtkspell-2.0.11-2.1
gtksourceview-1.8.0-1.fc6
gtk2-2.10.4-20.el5
gtk2-devel-2.10.4-20.el5
gtkhtml3-3.16.3-1.el5
gtk-doc-1.7-1.fc6
gtkhtml2-2.11.0-3
gtkmm24-2.10.10-1.el5
pygtk2-codegen-2.10.1-12.el5
usermode-gtk-1.88-3.el5.1
authconfig-gtk-5.3.21-3.el5
gtkmm24-devel-2.10.10-1.el5
gnome-python2-gtksourceview-2.16.0-2.el5
pygtk2-devel-2.10.1-12.el5

latest dbus-c++ from git repo

-- 
Mit freundlichen Grüßen

Jesus Ruiz de Infante
(Entwicklung)
HALE electronic GmbH
Eugen-Müller-Straße 18, 5020 Salzburg, Austria
Tel:  +43 (662) 439011 0
Fax:  +43 (662) 439011 9
jes...@ha...
Firmenbuchnummer: FN 66801m HG Salzburg


--
Scanned by MailScanner.

[dbus-cplusplus-devel] org.freedesktop.DBus.NoReply annotation implemented

[Andreas V. <li...@br...>]

Hello,

I implemented a org.freedesktop.DBus.NoReply annotation for the
dbusxx-xml2cpp in the gitorious reop.

Now this is possible:

<?xml version="1.0" ?>
<node name="/org/oicf/MapViewer">
  <interface name="org.oicf.MapViewer">

    <method name="moveMapSteps">
      <annotation name="org.freedesktop.DBus.NoReply" value="yes"/>
      <arg type="i" name="direction" direction="in"/>
      <arg type="i" name="steps" direction="in"/>
    </method>

    <method name="incrementMapZoomLevel">
      <annotation name="org.freedesktop.DBus.NoReply" value="yes"/>
    </method>

    <method name="decrementMapZoomLevel">
      <annotation name="org.freedesktop.DBus.NoReply" value="yes"/>
    </method>

    <method name="updateGPSPositionWGS84Test">
      <annotation name="org.freedesktop.DBus.NoReply" value="yes"/>
      <arg type="(dddd)" name="pos" direction="in" object="CoordWGS84"/>
    </method>

  </interface>
</node>

It ignores the annotation and warns if any 'out' variables exists. This
features needs also the invoke_method_noreply() implementation in the
gitorious repo.

This way it's possible to implement async calls.

Hint: The object="..." syntax is deprecated. I'll change it soon to
annotations syntax.

regards
Andreas

[dbus-cplusplus-devel] Annotations?

[Andreas V. <li...@br...>]

Hello,

now I found out about annotations in dbus-glib XML:

http://dbus.freedesktop.org/doc/dbus-tutorial.html#glib-annotations

So I've some questions:

- Do you think we should use the same concept for dbus-c++?

- Any ideas why the name is e.g. org.freedesktop.DBus.GLib.Async? I
think if the name would be org.freedesktop.DBus.Async it wouldn't be
GLib specific.

- Refering to my proposal:

    <signal name="onButtonListener">
      <arg type="(inyb)" name="eventButton" direction="out"
      object="KeyEvent"/> 
    </signal>

This may better be written:

    <signal name="onButtonListener">
      <arg type="(inyb)" name="eventButton" direction="out"> 
        <annotation name="org.freedesktop.DBus.Object"
                    value="KeyEvent"/>
      </arg>
    </signal>

What do you think?

regards
Andreas

[dbus-cplusplus-devel] configure and default CXXFLAGS

[Ignacy G. <sf...@qu...>]

Hi again,

While integrating the package in a project of mine, I noticed a strange way of
dealing with the CXXFLAGS variable.  The problem I see there is that if I set
CXXFLAGS in the environment during the run of configure, I expect it to
override the CXXFLAGS (default) settings, pretty much the same way make does
treat variable definitions on the command line to have precedence over the
ones inside the makefile (unless you specify "override" explicitly).  My
problem was mainly about my default optimization level being eventually
overridden by the defaults inside configure.ac .

Please take a look at the attached patch.  The idea is to set those "default"
flags iff the CXXFLAGS variable wasn't set in the environment and to always
add the -fvisibility-hidden flag if needed *afterwards*.

-- 
I drive way too fast to worry about cholesterol.

[dbus-cplusplus-devel] Connection::request_name() and errors

[Ignacy G. <sf...@qu...>]

Hi,

Is there a particular reason for the return value of dbus_bus_request_name()
not to be checked "deliberately"?  It would be nice to be able to know when a
request has failed because the name is already owned.  Couldn't the return
flags be wrapped in an Error exception?

-- 
Writing non-free software is not an ethically legitimate activity, so if
people who do this run into trouble, that's good!  All businesses based
on non-free software ought to fail, and the sooner the better.
        -- Richard Stallman

Re: [dbus-cplusplus-devel] send / send_blocking / send_async

[P. D. <sh...@gm...>]

On Mon, Sep 8, 2008 at 11:43 PM, Andreas Volz <li...@br...> wrote:
> Hello,
>
> I noticed that if I call a message with dbus-c++ that the caller
> blocks.
>
of course

> How could I realize a async communication like I would expect with
> dbus-c++?
>
> I could for sure put something on top of dbus-c++, but better would be
> to place that into the library.
>

libdbus already has logic to do that, it just needs to be properly
wrapped in c++

http://dbus.freedesktop.org/doc/api/html/group__DBusPendingCall.html

[dbus-cplusplus-devel] send / send_blocking / send_async

[Andreas V. <li...@br...>]

Hello,

I noticed that if I call a message with dbus-c++ that the caller
blocks.

My application logic has everywhere a Caller and a listener:

    <method name="getWindowList">
      <arg type="i" name="start" direction="in"/>
      <arg type="i" name="end" direction="in"/>
    </method>

    <signal name="getWindowListResult">
      <arg type="as" name="titleList" direction="out"/>
      <arg type="i" name="start" direction="out"/>
      <arg type="i" name="end" direction="out"/>
      <arg type="i" name="size" direction="out"/>
    </signal>

So my idea was to handle a asynchronous communication. The client calls
a getWindowList and after calculation that list the system should
answer with a getWindowListResult. But my idea failed because the
client blocks the method call.

How could I realize a async communication like I would expect with
dbus-c++?

I could for sure put something on top of dbus-c++, but better would be
to place that into the library.

Thanks for your answer.

regards
Andreas

Re: [dbus-cplusplus-devel] Proposal: Give objects through dbus-c++

[Andreas V. <li...@br...>]

Am Wed, 3 Sep 2008 00:45:17 +0200 schrieb Andreas Volz:

> Am Tue, 2 Sep 2008 00:20:15 +0200 schrieb Andreas Volz:
> 
> > Am Sun, 31 Aug 2008 18:16:13 +0200 schrieb P. Durante:
> > 
> > Hello Paolo,
> > 
> > currently I work on a example implementation that explains all my
> > ideas. I hope tomorrow it's finished and ready to show. Then we talk
> > again about it.
> 
> Here is the result of my proposal. I modified the dbusxx-xml2cpp tool
> to generate the object binding. See here:
> 
> http://gitorious.org/projects/dbus-cplusplus/repos/mainline/blobs/master/tools%2Fxml2cpp.cpp
> 
> As result it parses the object="MyObject" code in the XML and
> generates code based on it. See here a prototype of my communication
> library:
> 
> http://www.tux-style.de/tmp/dbus-cplusplus/oicf-0.1.tar.gz
> 
> and here the dbus-c++ code generated with it:
> 
> http://www.tux-style.de/tmp/dbus-cplusplus/oicf-0.1_bin.tar.gz
> 
> It seems to work for signals and methods, but it's not extreme tested
> for in and out values. I need to write more tests for it.
> 
> It works well and is 100% compatible to other dbus bindings. You even
> don't need to do it in dbus-c++ if you fear of more object creations
> while communications. Simply don't use the "object" tag.
> 
> What do you think?
> 
> I would like to see it integrated into the official repo.
> 
> BTW: As I noticed the tabs aren't perfect. In both source code and
> generated code. But I think that's a minor problem.
> 
> BTW2: Maybe you noticed that I added some more comments for
> dbusxx-xml2cpp while understanding it. So the next new person will
> faster understand it.

Did you've some time to look into my proposal?

regards
Andreas

Re: [dbus-cplusplus-devel] Makefile.am in examples/properties/

[Ignacy G. <sf...@qu...>]

On Mon, Sep 08, 2008 at 07:12:15PM +0200, thus spake P. Durante:
> thanks!

By the way, speaking of packaging dbus-c++ for distributions (great idea
indeed), there are a few things that need to be fixed in order to make these
sources usable on a large scale.  Some of these have apparently been already
fixed in the forked branch (gitorious.org).  I think particularly about the
#include <config.h> stanzas in header files that should be in the .cpp files
instead.  Otherwise, packages build with autotools and including these headers
will explode in mid-flight (read: won't compile properly since because of
conflicting defines).

-- 
Information wants to be beer, or something like that.

Re: [dbus-cplusplus-devel] Makefile.am in examples/properties/

[P. D. <sh...@gm...>]

On Mon, Sep 8, 2008 at 6:14 PM, Ignacy Gawedzki <sf...@qu...> wrote:
> Hi,
>
> There are apparently a few errors that pop up in make dist in the current
> Makefile.am of examples/properties/ .
>
> Here's a patch.
>
> --
> Everything is more fun naked except cooking with grease.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> dbus-cplusplus-devel mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
>
>

thanks!

[dbus-cplusplus-devel] Makefile.am in examples/properties/

[Ignacy G. <sf...@qu...>]

Hi,

There are apparently a few errors that pop up in make dist in the current
Makefile.am of examples/properties/ .

Here's a patch.

-- 
Everything is more fun naked except cooking with grease.

Re: [dbus-cplusplus-devel] dbus-cplusplus on Opensuse Build Service

[Christopher L. <chr...@ac...>]

Paolo,

yes, I know that Novell requires registration to use the build service, but I 
have to say, that I never received spam or similar offensive stuff from them 
because of that registration.

It is not an ideal situation, but the usefulness of their build sevice many 
times outweighs the small inconvenience of registering. I am tempted to say, 
that the build service is so great, I am ok to give them my email adress for 
using it.

Furthermore the folks from the build sevice mailing list are very helpful, and 
having up to date dbus-c++ builds will really give dbus-c++ a push forward, 
which is a good thing.

So if I convinced you, just send me your build service login name and I will 
add you to the dbus-c++ build service project.
:-)

Of course you also can start your own build service project...

best regards
Chris



Am Montag, 8. September 2008 16:58 schrieb P. Durante:
> Hi,
>
> On Mon, Sep 8, 2008 at 12:59 PM, Christopher Lang
>
> <chr...@ac...> wrote:
> > Hi,
> >
> > I am still too busy to do some work on this project. However, I set up
> > dbus-c++ (Original 0.5.0 code) on opensuse build Service some time ago
> > and it builds for quite an impressive list of distributions. It needs
> > verification of the content of the built packages though. If somebody is
> > interested, pls email me, I will add you to the project on the opensuse
> > build server.
>
> that's very interesting, I'd like to put a more updated version to test
>
> > https://build.opensuse.org/package/show?package=dbus-c%2B%2B&project=home
> >%3Achris144
>
> compulsory registration needed :-\
>
> > cheers
> > Chris
>
> regards
> Paolo

Re: [dbus-cplusplus-devel] dbus-cplusplus on Opensuse Build Service

[P. D. <sh...@gm...>]

Hi,

On Mon, Sep 8, 2008 at 12:59 PM, Christopher Lang
<chr...@ac...> wrote:
>
> Hi,
>
> I am still too busy to do some work on this project. However, I set up
> dbus-c++ (Original 0.5.0 code) on opensuse build Service some time ago and it
> builds for quite an impressive list of distributions. It needs verification
> of the content of the built packages though. If somebody is interested, pls
> email me, I will add you to the project on the opensuse build server.
>
that's very interesting, I'd like to put a more updated version to test

> https://build.opensuse.org/package/show?package=dbus-c%2B%2B&project=home%3Achris144
>
compulsory registration needed :-\

>
> cheers
> Chris
>
regards
Paolo

[dbus-cplusplus-devel] dbus-cplusplus on Opensuse Build Service

[Christopher L. <chr...@ac...>]

Hi,

I am still too busy to do some work on this project. However, I set up 
dbus-c++ (Original 0.5.0 code) on opensuse build Service some time ago and it 
builds for quite an impressive list of distributions. It needs verification 
of the content of the built packages though. If somebody is interested, pls 
email me, I will add you to the project on the opensuse build server.

https://build.opensuse.org/package/show?package=dbus-c%2B%2B&project=home%3Achris144


cheers
Chris

http://www.acurana.de/

Re: [dbus-cplusplus-devel] Server's copy-constructor

[P. D. <sh...@gm...>]

On Fri, Sep 5, 2008 at 6:21 PM, Ignacy Gawedzki <sf...@qu...> wrote:
> Quite frankly, I don't really see the point in hiding these Private instances, but
> nevermind. =)
>
it hides the dependency on <dbus/dbus.h> which is only used in the
implementation
(in theory you could reimplement the protocol without changing the c++
api and avoid libdbus altogether, if you had a good reason to do so)

Re: [dbus-cplusplus-devel] Server's copy-constructor

[Ignacy G. <sf...@qu...>]

On Fri, Sep 05, 2008 at 05:39:57PM +0200, thus spake P. Durante:
> On Fri, Sep 5, 2008 at 1:29 PM, Ignacy Gawedzki <sf...@qu...> wrote:
> > Hi,
> >
> > A little question while I'm skimming the source code: what's the point with
> > the protected copy-constructor of Server?  I'm not asking why it is protected,
> > but why doesn't it do anything with the _pvt attribute, which remains 0.
> >
> it's just the C++ way of disallowing copies (but it should be private
> and not protected to make it clear, sorry)

Okay, then it should be private and should not have any body defined (just
declared).

> since there can't be copies around (they won't even work since their
> on_new_connection() would never be called, and honestly i can't see a
> use case where you'd need to do that anyway) the private smart pointer
> is useless, it could be a regular pointer

Or even a regular attribute, composited and not aggregated.  The only problem
would be that then it could not be hidden away in that _p.h file.  Quite
frankly, I don't really see the point in hiding these Private instances, but
nevermind. =)

> feel free to throw that class away and rewrite it :-)

I'm actually changing it in some ways to make it work.  There are few things
that need to be done in order to make writing an actual server possible.

First, oddly enough, I need to instantiate a dummy DBus object, so that
messages like Hello and AddWatch from clients (which are apparently sent
automatically by libdbus, regardless of whether the connection is to a
dbus-daemon or a private one) are successfully received.

Second, I need as many instances of exported objects as I have open
connections and I need to be able to destroy all the ones associated with a
connection that I'm closing.  For this purpose I need to be able to retrieve
all the instances that have been constructed with a given connection.

I could of course keep a container with my objects, but then I would have to
iterate through all its elements in search of the ones that have been
constructed with a given connection.  So here it would be helpful to keep a
collection of pointers to the objects in instances of Connection themselves.
Here arises the question of whether the objects should be composited (i.e.
owned by the connection) or simply aggregated.  Since each instance of Object
owns its instance of Connection, making the Connection own its objects doesn't
make much sense.

-- 
NO CARRIER

Re: [dbus-cplusplus-devel] Server's copy-constructor

[P. D. <sh...@gm...>]

On Fri, Sep 5, 2008 at 1:29 PM, Ignacy Gawedzki <sf...@qu...> wrote:
> Hi,
>
> A little question while I'm skimming the source code: what's the point with
> the protected copy-constructor of Server?  I'm not asking why it is protected,
> but why doesn't it do anything with the _pvt attribute, which remains 0.
>
it's just the C++ way of disallowing copies (but it should be private
and not protected to make it clear, sorry)

since there can't be copies around (they won't even work since their
on_new_connection() would never be called, and honestly i can't see a
use case where you'd need to do that anyway) the private smart pointer
is useless, it could be a regular pointer

feel free to throw that class away and rewrite it :-)

[dbus-cplusplus-devel] Server's copy-constructor

[Ignacy G. <sf...@qu...>]

Hi,

A little question while I'm skimming the source code: what's the point with
the protected copy-constructor of Server?  I'm not asking why it is protected,
but why doesn't it do anything with the _pvt attribute, which remains 0.

-- 
 "The whole problem with the world is that fools and fanatics are
   always so certain of themselves, and wiser people so full of doubts."
                                                 - Bertrand Russell

Re: [dbus-cplusplus-devel] Server and closing connections (corrected patch, sorry)

[Ignacy G. <sf...@qu...>]

On Fri, Sep 05, 2008 at 03:42:23AM +0200, thus spake Ignacy Gawedzki:
> It's a bit late I guess...
> 
> Here comes the patch that actually should work.

It's definitely too late.

-- 
If you're not living on the edge, you're taking up too much space.