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

Re: [dbus-cplusplus-devel] dbusxx-xml2cpp bug (gitorious branch)

[David K. <zu...@li...>]

Yeah, I noticed the commit. Thanks. :)

Best regards,

David
zu...@li...


On Sat, 28 Mar 2009, Andreas Volz wrote:

> Date: Sat, 28 Mar 2009 13:52:10 +0100
> From: Andreas Volz <li...@br...>
> To: dbu...@li...
> Subject: Re: [dbus-cplusplus-devel] dbusxx-xml2cpp bug (gitorious branch)
> 
> Am Thu, 19 Mar 2009 23:24:47 +0100 (CET) schrieb David Kozub:
>
> Hello David,
>
> ==> Fixed in gitorious branch
>
> I tested many combinations of single and multiple in and out
> parameters. I tested also simple types, complex types and object types.
> It seems to generate good code. I've not yet tested the functionality
> itself.
>
> Hint for me: Write unit tests! :-)
>
> Thanks for reporting that bug!
>
> regards
> Andreas
>
>> Hi,
>>
>> I grabbed dbus-c++ from the gitorious branch and started playing with
>> the examples. I actually stopped right at the simplest example -
>> examples/echo.
>>
>> Invoking the Hello method as mentioned in README results in an empty
>> string. When I looked into the issue, it seems to be a bug in the
>> server glue (generated by dbusxx-xml2cpp), specifically, the
>> marshaller:
>>
>>      ::DBus::Message _Hello_stub(const ::DBus::CallMessage &call)
>>      {
>>          ::DBus::MessageIter ri = call.reader();
>>
>>          std::string argin1;
>>          ri >> argin1;
>>          std::string argout1;
>>          Hello(argin1);
>>          ::DBus::ReturnMessage reply(call);
>>          ::DBus::MessageIter wi = reply.writer();
>>          wi << argout1;
>>          return reply;
>>      }
>>
>> changing the Hello() invocation into "argout1 = Hello(argin1)" fixes
>> the issue.
>>
>> Looking at the stub (and at the generator), this is a general
>> problem. Being all new to this... I see where in generator is this
>> code output, but I don't really know how to fix this.
>>
>> Best regards,
>>
>> David Kozub
>> zu...@li...
>>
>> ------------------------------------------------------------------------------
>> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM)
>> are powering Web 2.0 with engaging, cross-platform capabilities.
>> Quickly and easily build your RIAs with Flex Builder, the
>> Eclipse(TM)based development software that enables intelligent coding
>> and step-through debugging. Download the free 60 day trial.
>> http://p.sf.net/sfu/www-adobe-com
>> _______________________________________________ dbus-cplusplus-devel
>> mailing list dbu...@li...
>> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> dbus-cplusplus-devel mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
>

Re: [dbus-cplusplus-devel] dbusxx-xml2cpp bug (gitorious branch)

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

Am Thu, 19 Mar 2009 23:24:47 +0100 (CET) schrieb David Kozub:

Hello David,

==> Fixed in gitorious branch

I tested many combinations of single and multiple in and out
parameters. I tested also simple types, complex types and object types.
It seems to generate good code. I've not yet tested the functionality
itself.

Hint for me: Write unit tests! :-)

Thanks for reporting that bug!

regards
Andreas

> Hi,
> 
> I grabbed dbus-c++ from the gitorious branch and started playing with
> the examples. I actually stopped right at the simplest example - 
> examples/echo.
> 
> Invoking the Hello method as mentioned in README results in an empty 
> string. When I looked into the issue, it seems to be a bug in the
> server glue (generated by dbusxx-xml2cpp), specifically, the
> marshaller:
> 
>      ::DBus::Message _Hello_stub(const ::DBus::CallMessage &call)
>      {
>          ::DBus::MessageIter ri = call.reader();
> 
>          std::string argin1;
>          ri >> argin1;
>          std::string argout1;
>          Hello(argin1);
>          ::DBus::ReturnMessage reply(call);
>          ::DBus::MessageIter wi = reply.writer();
>          wi << argout1;
>          return reply;
>      }
> 
> changing the Hello() invocation into "argout1 = Hello(argin1)" fixes
> the issue.
> 
> Looking at the stub (and at the generator), this is a general
> problem. Being all new to this... I see where in generator is this
> code output, but I don't really know how to fix this.
> 
> Best regards,
> 
> David Kozub
> zu...@li...
> 
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM)
> are powering Web 2.0 with engaging, cross-platform capabilities.
> Quickly and easily build your RIAs with Flex Builder, the
> Eclipse(TM)based development software that enables intelligent coding
> and step-through debugging. Download the free 60 day trial.
> http://p.sf.net/sfu/www-adobe-com
> _______________________________________________ dbus-cplusplus-devel
> mailing list dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> 

Re: [dbus-cplusplus-devel] dbusxx-xml2cpp bug (gitorious branch)

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

Am Thu, 19 Mar 2009 23:24:47 +0100 (CET) schrieb David Kozub:

Hello David,

this was reported yet in the past and I know how to fix it. I simply
work currently on another task. But it's on the TODO list. You may also
add a bug in the sf.net bug tracker if you like.

regards
Andreas

> Hi,
> 
> I grabbed dbus-c++ from the gitorious branch and started playing with
> the examples. I actually stopped right at the simplest example - 
> examples/echo.
> 
> Invoking the Hello method as mentioned in README results in an empty 
> string. When I looked into the issue, it seems to be a bug in the
> server glue (generated by dbusxx-xml2cpp), specifically, the
> marshaller:
> 
>      ::DBus::Message _Hello_stub(const ::DBus::CallMessage &call)
>      {
>          ::DBus::MessageIter ri = call.reader();
> 
>          std::string argin1;
>          ri >> argin1;
>          std::string argout1;
>          Hello(argin1);
>          ::DBus::ReturnMessage reply(call);
>          ::DBus::MessageIter wi = reply.writer();
>          wi << argout1;
>          return reply;
>      }
> 
> changing the Hello() invocation into "argout1 = Hello(argin1)" fixes
> the issue.
> 
> Looking at the stub (and at the generator), this is a general
> problem. Being all new to this... I see where in generator is this
> code output, but I don't really know how to fix this.
> 
> Best regards,
> 
> David Kozub
> zu...@li...
> 
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM)
> are powering Web 2.0 with engaging, cross-platform capabilities.
> Quickly and easily build your RIAs with Flex Builder, the
> Eclipse(TM)based development software that enables intelligent coding
> and step-through debugging. Download the free 60 day trial.
> http://p.sf.net/sfu/www-adobe-com
> _______________________________________________ dbus-cplusplus-devel
> mailing list dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> 

[dbus-cplusplus-devel] dbusxx-xml2cpp bug (gitorious branch)

[David K. <zu...@li...>]

Hi,

I grabbed dbus-c++ from the gitorious branch and started playing with the 
examples. I actually stopped right at the simplest example - 
examples/echo.

Invoking the Hello method as mentioned in README results in an empty 
string. When I looked into the issue, it seems to be a bug in the server 
glue (generated by dbusxx-xml2cpp), specifically, the marshaller:

     ::DBus::Message _Hello_stub(const ::DBus::CallMessage &call)
     {
         ::DBus::MessageIter ri = call.reader();

         std::string argin1;
         ri >> argin1;
         std::string argout1;
         Hello(argin1);
         ::DBus::ReturnMessage reply(call);
         ::DBus::MessageIter wi = reply.writer();
         wi << argout1;
         return reply;
     }

changing the Hello() invocation into "argout1 = Hello(argin1)" fixes the 
issue.

Looking at the stub (and at the generator), this is a general problem. 
Being all new to this... I see where in generator is this code output, but 
I don't really know how to fix this.

Best regards,

David Kozub
zu...@li...

[dbus-cplusplus-devel] Connection::request_name return value

[Konishchev D. <kon...@gm...>]

Please, say why dbus-c++ method
       void Connection::request_name(const char *name, int flags)
has void return type? The return value is very usable to prevent race
conditions while requesting DBus name. Please, fix this method to return
dbus_bus_request_name() value.

Thanks for your attention.

Re: [dbus-cplusplus-devel] Dbus-c++ timeout example

[Schmottlach, G. <gle...@ha...>]

I hope this will help you. The lack of documentation really hurts in
this instance.

class TimeoutHandler
{
public:
   void onTimeout(DBus::SimpleTimeout& t)
   {
      cout << "onTimeout called!" << endl;
   }
};

int main(int argc, char* argv[])
{
	TimeoutHandler timeoutHandler;

	DBus::SimpleTimeout timer(250 /*msec*/, true /*repeat*/,
	
&DBus::DefaultDispatcher::instance);
	timer.expired =
	      new DBus::Callback<TimeoutHandler, void,
			DBus::SimpleTimeout &>(&timeoutHandler,
			&TimeoutHandler::onTimeout);
	   
	// Enter the global dispatch loop
	DBus::DefaultDispatcher::instance.enter();

	// The timer should repeatedly fire every ~250 msec
}

Re: [dbus-cplusplus-devel] Bug. xml2cpp structure including several simple array.

[Redouane S. <red...@fr...>]

Hi,

Did you have time to check the patch ?

Regards.

-----Original Message-----
From: Andreas Volz [mailto:li...@br...] 
Sent: Tuesday, February 10, 2009 7:17 PM
To: dbu...@li...
Subject: Re: [dbus-cplusplus-devel] Bug. xml2cpp structure including several
simple array.

Am Wed, 21 Jan 2009 17:41:50 +0100 schrieb Redouane SOUM:

Hello Redouane,

sorry for not answering your mail. I'll try it in the next days. The
problem is that in I work mainly on base of the gitorious branch. The
generator there differs much from the fdo one. So I think it doesn't
apply on my modified generator. But I think it has this bug also.

I search for a way to combine the source of both so that I only have to
work on one source.

I've not yet tried your patch, but will do in the next days.

A good idea for the future would be a set of generator unit tests. Then
one could apply patches and after passing all unit test it could be
applied. Currently I've to test or review that patch. Because if I
apply it with my account I've to "guarantee" for it's correctness.

regards
Andreas

> If we use complex structure that include simple array, the type isn't
> generated properly.
> Exemple : (iiiua(ayayayiiiii))
>  
> Generated type (with current version of xml2cpp):
>  
> ::DBus::Struct< int32_t, int32_t, int32_t, uint32_t,
> std::vector< ::DBus::Struct< std::vector< uint8_t, std::vector<
> uint8_t, std::vector< uint8_t, int32_t, int32_t, int32_t, int32_t,
> int32_t > > > >,
> >
> >, & evt
>  
>  
> Type expected:
>  
>  ::DBus::Struct< int32_t, int32_t, int32_t, uint32_t,
> std::vector< ::DBus::Struct< std::vector< uint8_t >, std::vector<
> uint8_t >, std::vector< uint8_t >, int32_t, int32_t, int32_t,
> int32_t, int32_t > > > evt;
>  
>  
>  
> I would like to submit a patch fixing this problem and adding some
> features:
> 
>  
>  
> Xml2cpp
>         Bug fix:
>              Problem in type generation with complex array
>  
>         Feature:
>             Add nonblock function for each method in the proxy
> generation 
> Dispatcher/connection
>  
>         Feature:
>             Add constructor to create a connection passing a
> dispatcher (instead of creating a connection with default dispatcher
> and use setup after)
>             Add fd to allow dispatcher to leave directly when leave
> method is called (instead of waiting for the timeout on the select)
>  
> Red1
> 
>  
> 
>  
> 
> Ps : see bug https://bugs.freedesktop.org/show_bug.cgi?id=19518
> 
>  
> 

----------------------------------------------------------------------------
--
Create and Deploy Rich Internet Apps outside the browser with
Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code
to
build responsive, highly engaging applications that combine the power of
local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
dbus-cplusplus-devel mailing list
dbu...@li...
https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel

[dbus-cplusplus-devel] DBus server implementation

[Schmottlach, G. <gle...@ha...>]

 

Has anyone attempted creating a DBus server using the DBus-C++ binding?
I'd like to create a service that a client can call directly and bypass
the dbus-daemon. I see an (apparently) incomplete implementation of a
server in server.h.

 

I have managed to create a server that detects a new connection from the
client. I then create a service inheriting from a generated adaptor but
it appears my adaptor does not provide the basic interface(s) exposed by
org.freedesktop.DBus. To remedy this I used dbusxx-xml2cpp to generate
an org.freedesktop.DBus adaptor which my service inherited from as well,
e.g.

 

class SimpleServiceImpl

   :

   public com::SimpleService_adaptor,

   public org::freedesktop::DBus_adaptor,

   public DBus::IntrospectableAdaptor,

   public DBus::ObjectAdaptor

{

...

}

 

The SimpleService adaptor describes the services I'm trying to implement
while the DBus_adaptor contains those methods that must be implemented
to support the "stock" DBus server interface. I provided a generic
implementation of the DBus server methods. When I run the client I keep
getting an exception that the "AddMatch" method was not found although I
do provide an implementation in DBus adaptor class. It's as if the
methods in the DBus_adaptor have not been registered. Normally a service
would register its interface with the dbus-daemon but for a local server
this won't occur (because there is no daemon running to register with).
Likewise, the client does not attempt to connect directly to a
system/session/activation bus but instead does a direct connect to the
server I have written.

 

Has anyone been able to create a true server that listen's on a
local-socket and allows a client to connect to it directly (bypassing
the dbus-daemon)? It seems like I'm close to my goal but it appears the
dbusxx-xml2cpp generator creates a proxy used by the client that
"assumes" it will be talking to the daemon rather than a direct
connection to a server. How do I make my server appear to be a daemon?

 

Any suggestions would be helpful . . .

[dbus-cplusplus-devel] Dbus-c++ timeout example

[Tyler C. <tc...@ta...>]

Is there an example for the use of timeouts in DBus-c++. It looks like I need to provide a dbus_timeout struct, but this doesn't seem right. Could someone point me in the right direction.

Thanks,
-Tyler

Re: [dbus-cplusplus-devel] dbus-c++ patch

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

Am Wed, 18 Feb 2009 18:24:08 +0100 schrieb Jiri Moskovcak:

Hello Jiri,

I forgot a comment. Please provide doxygen comments for the new call.

Hint: Use dbus docu as base for the DBus-C++ comments. This will help
us to improve quality.

Thanks
Andreas

> Hi,
> I couldn't find out how to get unix UID from dbus-c++, so I wrote a
> simple patch to add this functionality and it would be great to
> include this to upstream.
> 
> Thank you,
> J.Moskovcak

Re: [dbus-cplusplus-devel] dbus-c++ patch

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

Am Wed, 18 Feb 2009 18:24:08 +0100 schrieb Jiri Moskovcak:

Hello Jiri,

thanks for your contribution.

fdo branch: added
gitorious branch: added

regards
Andreas

> Hi,
> I couldn't find out how to get unix UID from dbus-c++, so I wrote a
> simple patch to add this functionality and it would be great to
> include this to upstream.
> 
> Thank you,
> J.Moskovcak

[dbus-cplusplus-devel] dbus-c++ patch

[Jiri M. <jmo...@re...>]

Hi,
I couldn't find out how to get unix UID from dbus-c++, so I wrote a
simple patch to add this functionality and it would be great to include
this to upstream.

Thank you,
J.Moskovcak

Re: [dbus-cplusplus-devel] Bug. xml2cpp structure including several simple array.

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

Am Wed, 21 Jan 2009 17:41:50 +0100 schrieb Redouane SOUM:

Hello Redouane,

sorry for not answering your mail. I'll try it in the next days. The
problem is that in I work mainly on base of the gitorious branch. The
generator there differs much from the fdo one. So I think it doesn't
apply on my modified generator. But I think it has this bug also.

I search for a way to combine the source of both so that I only have to
work on one source.

I've not yet tried your patch, but will do in the next days.

A good idea for the future would be a set of generator unit tests. Then
one could apply patches and after passing all unit test it could be
applied. Currently I've to test or review that patch. Because if I
apply it with my account I've to "guarantee" for it's correctness.

regards
Andreas

> If we use complex structure that include simple array, the type isn't
> generated properly.
> Exemple : (iiiua(ayayayiiiii))
>  
> Generated type (with current version of xml2cpp):
>  
> ::DBus::Struct< int32_t, int32_t, int32_t, uint32_t,
> std::vector< ::DBus::Struct< std::vector< uint8_t, std::vector<
> uint8_t, std::vector< uint8_t, int32_t, int32_t, int32_t, int32_t,
> int32_t > > > >,
> >
> >, & evt
>  
>  
> Type expected:
>  
>  ::DBus::Struct< int32_t, int32_t, int32_t, uint32_t,
> std::vector< ::DBus::Struct< std::vector< uint8_t >, std::vector<
> uint8_t >, std::vector< uint8_t >, int32_t, int32_t, int32_t,
> int32_t, int32_t > > > evt;
>  
>  
>  
> I would like to submit a patch fixing this problem and adding some
> features:
> 
>  
>  
> Xml2cpp
>         Bug fix:
>              Problem in type generation with complex array
>  
>         Feature:
>             Add nonblock function for each method in the proxy
> generation 
> Dispatcher/connection
>  
>         Feature:
>             Add constructor to create a connection passing a
> dispatcher (instead of creating a connection with default dispatcher
> and use setup after)
>             Add fd to allow dispatcher to leave directly when leave
> method is called (instead of waiting for the timeout on the select)
>  
> Red1
> 
>  
> 
>  
> 
> Ps : see bug https://bugs.freedesktop.org/show_bug.cgi?id=19518
> 
>  
> 

Re: [dbus-cplusplus-devel] [PATCH] Add libtool file to rpm package

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

Am Thu, 5 Feb 2009 11:31:48 +0100 schrieb Daniel Wagner:

> Hi,
> 
> Attached is a patch which I needed in order to build a rpm
> package. dbus-c++ is a fresh copy from git.

Thanks Daniel:

fdo branch : applied
gitorious branch: applied

regards
Andreas

[dbus-cplusplus-devel] [PATCH] Add libtool file to rpm package

[Daniel W. <wa...@mo...>]

Hi,

Attached is a patch which I needed in order to build a rpm
package. dbus-c++ is a fresh copy from git.

cheers,
daniel

[dbus-cplusplus-devel] HALmm

[Milosz D. <int...@gm...>]

Hello,

The halmm repository can now be found at the following location. It is
Mercurial repository, located at:

http://hg.backtrace.info/halmm

It should be noted that I have for now created a local fork of dbus-c++,
with, for now, no plans of
actually forking it but since we're having communication problems and I
needed to continue
working I thought it best to use my own version of dbus-c++.

The repository for the dbus-c++ variant is here:

http://hg.backtrace.info/dbusmm

Any comments or critique (if appropriately stated) is welcome.

Thanks,
Regards,
M.

-- 
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.]

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

[Milosz D. <int...@gm...>]

Hey Andreas,

After a long time i'm reporting back in.

I've now started developing libhalmm, which is a reimplementation of
libhal and libhal-storage
using dbus-c++. I expect to publish the first version of the source
code with an estimated
completion of the code of 90% end of coming week (there are some
obscurities in libhal
about which i need to talk about with the hal developers).

I've mailed to the dbus-c++ mailing list with a few questions, but
Paolo was not very forthcoming
and finally outright ignored me; I don't know why he was being so
offensive after me just
having asked a few questions. Anyway, i'll quote the original questions here:

> Hello,
>
> I've got 2 questions and one announcement.
>
> First the announcement: I've finally started writing the libhalmm rewrite,
> as a reimplementation of libhal,
> instead of being a wrapper around the C libhal and libhal-storage.
>
> Since the basic work is straightforward I expect that I can make an
> announcement of the source code
> within 1-2 weeks; I'll post again then with the checkout URL, etc.
>
> Two questions:
>
> 1.) Is it OK to post git diffs for dbus-c++ here? (I assume yes, but just
> wanted to ask)
>
> 2.) Is the policy for inclusion of DBus C headers still "No DBus C headers
> in the public dbus-c++ headers"?
> I thought we could get rid of some (IMO) stupid things in the DBus C API,
> e.g. introduce an enum for the
> message type. However, to take the values from the C API, the C header
> dbus-protocol.h would need to
> be included? How is the stance on this policy by now?

Would be nice if you could tell me how the state of this is currently.

Regards,
M.

> On Sat, Nov 8, 2008 at 4:05 PM, Milosz Derezynski <int...@gm...> wrote:
> Hey Andreas,
>
> I will definitely look into the example, and into reimplementing libhal++
> instead of wrapping
> it in the next coming time.
>
> I've subscribed to dbus-cplusplus-devel now also.
>
> Thanks for the information!
>
> Cheers,
> M.
>
> On Sat, Nov 8, 2008 at 10:52 AM, Andreas Volz <and...@tu...>
> wrote:
>>
>> 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/>
>
>
>
> --
> 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.]
>



-- 
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.]

Re: [dbus-cplusplus-devel] Question about patches / Question about DBus C header inclusion policies

[Milosz D. <int...@gm...>]

Yes sorry I meant type().

What has led me to wanting to do this is this code from libhal:

static DBusHandlerResult
filter_func (DBusConnection * connection,
         DBusMessage * message, void *user_data)
{
    const char *object_path;
    DBusError error;
    LibHalContext *ctx = (LibHalContext *) user_data;

    if (ctx->is_shutdown)
        return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;

    dbus_error_init (&error);

    object_path = dbus_message_get_path (message);

...

}



A few things to observe:

get_path() is implemented on dbus_message_ directly. Is there a specific
reason this is only implemented on
SignalMessage in dbus-c++?

Furthermore, the object path is used further down this code, for some cases
of the message, for some cases not.

I'm not sure how to elaborate on that since you have


On Sat, Jan 17, 2009 at 4:39 AM, P. Durante <sh...@gm...> wrote:

> On Sat, Jan 17, 2009 at 3:03 AM, Milosz Derezynski
> <int...@gm...> wrote:
> > I just realized that DBus::Message::get_type() also returns just an int.
> For
> > this to make any sense, that is,
> > so API consumers can compare this to the known message types, they have
> to
> > include the dbus-protocol.h
> > anyway, or they (bad!) just hardcode the numbers.
> >
> > So either way it seems that header is needed. But aside from that, the
> > question about whether C headers
> > can generally be included or not still stands :)
> >
>

Since I'm not sure right now why you avoid my entire main message I won't
comment on that further,
it's just that no matter whether I currently understand everything (or maybe
you just don't understand
what I am doing), I would have expected a nicer welcome for someone who is
trying to help out,
unless you don't welcome people helping out in general, i.e. prefer to work
alone on it.


> What I'm wondering is where you're getting these messages from and why
> you have to manually cast them to the appropriate message type.


Well since you're wondering so much, I'm getting the message from a filter
handler
installed by using add_filter().

This is code from C libhal:

static DBusHandlerResult
filter_func (DBusConnection * connection, DBusMessage * message, void
*user_data)
{
    const char *object_path;
    DBusError error;
    LibHalContext *ctx = (LibHalContext *) user_data;

    if (ctx->is_shutdown)
        return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;

    dbus_error_init (&error);

    object_path = dbus_message_get_path (message)

...

}

The object path is used for some callbacks i.e. for some handlers for
specific signals from HAL, for example:

...

if (dbus_message_is_signal (message,
"org.freedesktop.Hal.Device","InterfaceLockAcquired")) {
        char *lock_name;
        char *lock_owner;
                int num_locks;
        if (dbus_message_get_args (message, &error,
                       DBUS_TYPE_STRING, &lock_name,
                       DBUS_TYPE_STRING, &lock_owner,
                       DBUS_TYPE_INT32, &num_locks,
                       DBUS_TYPE_INVALID)) {
            if (ctx->interface_lock_acquired != NULL) {
                ctx->interface_lock_acquired (ctx, object_path, lock_name,
lock_owner, num_locks);
            }
        } else {
            LIBHAL_FREE_DBUS_ERROR(&error);
        }
        return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
}

...

Now I'm not sure how to ask this because there are a few angles possible
from which to approach it,
so I'll ask it from this one: Why is ::path() not implemented in Message,
but only in SignalMessage?

And if that is the right way to do it, and the message in the filter
function is in fact always a SignalMessage
(which it will not always be but let's assume it were), then the filter
function signature surely should be
bool (*func) (const SignalMessage&) no?

OK, but it's not, so I guess you can see my reasoning for wanting to cast
it, since all types of messages can
arrive at the filtering function.


> The way I see it Message::type() (there's no such thing as get_type())
> shouldn't be in the public API at all since the returned value is only
> used internally to route the message appropriately.
>

Yes i meant type(). Well, maybe so, but in the filtering function this
clearly doesn't work out.


>
> Paolo


Regards,
M.

It's OK to assume that I don't know everything, but assuming that I
understand
nothing is maybe not the right approach.

Re: [dbus-cplusplus-devel] Question about patches / Question about DBus C header inclusion policies

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

On Sat, Jan 17, 2009 at 3:03 AM, Milosz Derezynski
<int...@gm...> wrote:
> I just realized that DBus::Message::get_type() also returns just an int. For
> this to make any sense, that is,
> so API consumers can compare this to the known message types, they have to
> include the dbus-protocol.h
> anyway, or they (bad!) just hardcode the numbers.
>
> So either way it seems that header is needed. But aside from that, the
> question about whether C headers
> can generally be included or not still stands :)
>

What I'm wondering is where you're getting these messages from and why
you have to manually cast them to the appropriate message type.
The way I see it Message::type() (there's no such thing as get_type())
shouldn't be in the public API at all since the returned value is only
used internally to route the message appropriately.

Paolo

> Thanks
> Milosz
>
> On Sat, Jan 17, 2009 at 3:02 AM, Milosz Derezynski <int...@gm...>
> wrote:
>>
>> Hello,
>>
>> I've got 2 questions and one announcement.
>>
>> First the announcement: I've finally started writing the libhalmm rewrite,
>> as a reimplementation of libhal,
>> instead of being a wrapper around the C libhal and libhal-storage.
>>
>> Since the basic work is straightforward I expect that I can make an
>> announcement of the source code
>> within 1-2 weeks; I'll post again then with the checkout URL, etc.
>>
>> Two questions:
>>
>> 1.) Is it OK to post git diffs for dbus-c++ here? (I assume yes, but just
>> wanted to ask)
>>
>> 2.) Is the policy for inclusion of DBus C headers still "No DBus C headers
>> in the public dbus-c++ headers"?
>> I thought we could get rid of some (IMO) stupid things in the DBus C API,
>> e.g. introduce an enum for the
>> message type. However, to take the values from the C API, the C header
>> dbus-protocol.h would need to
>> be included? How is the stance on this policy by now?
>>
>>
>> Cheers
>> Milosz
>>
>> --
>> 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.]
>
>
>
> --
> 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.]
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> dbus-cplusplus-devel mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
>
>

Re: [dbus-cplusplus-devel] Question about patches / Question about DBus C header inclusion policies

[Milosz D. <int...@gm...>]

I just realized that DBus::Message::get_type() also returns just an int. For
this to make any sense, that is,
so API consumers can compare this to the known message types, they have to
include the dbus-protocol.h
anyway, or they (bad!) just hardcode the numbers.

So either way it seems that header is needed. But aside from that, the
question about whether C headers
can generally be included or not still stands :)

Thanks
Milosz

On Sat, Jan 17, 2009 at 3:02 AM, Milosz Derezynski
<int...@gm...>wrote:

> Hello,
>
> I've got 2 questions and one announcement.
>
> First the announcement: I've finally started writing the libhalmm rewrite,
> as a reimplementation of libhal,
> instead of being a wrapper around the C libhal and libhal-storage.
>
> Since the basic work is straightforward I expect that I can make an
> announcement of the source code
> within 1-2 weeks; I'll post again then with the checkout URL, etc.
>
> Two questions:
>
> 1.) Is it OK to post git diffs for dbus-c++ here? (I assume yes, but just
> wanted to ask)
>
> 2.) Is the policy for inclusion of DBus C headers still "No DBus C headers
> in the public dbus-c++ headers"?
> I thought we could get rid of some (IMO) stupid things in the DBus C API,
> e.g. introduce an enum for the
> message type. However, to take the values from the C API, the C header
> dbus-protocol.h would need to
> be included? How is the stance on this policy by now?
>
>
> Cheers
> Milosz
>
> --
> 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.]
>



-- 
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.]

[dbus-cplusplus-devel] Question about patches / Question about DBus C header inclusion policies

[Milosz D. <int...@gm...>]

Hello,

I've got 2 questions and one announcement.

First the announcement: I've finally started writing the libhalmm rewrite,
as a reimplementation of libhal,
instead of being a wrapper around the C libhal and libhal-storage.

Since the basic work is straightforward I expect that I can make an
announcement of the source code
within 1-2 weeks; I'll post again then with the checkout URL, etc.

Two questions:

1.) Is it OK to post git diffs for dbus-c++ here? (I assume yes, but just
wanted to ask)

2.) Is the policy for inclusion of DBus C headers still "No DBus C headers
in the public dbus-c++ headers"?
I thought we could get rid of some (IMO) stupid things in the DBus C API,
e.g. introduce an enum for the
message type. However, to take the values from the C API, the C header
dbus-protocol.h would need to
be included? How is the stance on this policy by now?


Cheers
Milosz

-- 
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.]

[dbus-cplusplus-devel] Merged gitorious branch into fdo branch

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

Hello,

now that I have a fdo account I merged the uncritical changes from
gitorious into fdo. See here the log:

----
commit 13281b395b3b030b031c140938f2cf2fe4e61b8f
Author: Andreas Volz <andreas@frodo.mittelerde>
Date:   Thu Jan 8 21:58:42 2009 +0100

    - removed include of config.h in header files
      - never include config.h in a installed header file!
    - added config.h to cpp and private (not installed) headers
    - don't install config.h
    - don't use any defines from config.h in a installed header file
    - added new API documentation in various classes
      - mostly copied and adapted from C API
    - implemented invoke_method_noreply() to enable asyncronous
      function calls
----

I tested the changes and detected no problem. But I had no chance to
test it on win32. Maybe someone who uses it on win32 could do this.

If I broke something with my changes than please flame me. :-P

There're still two big changes that aren't merged from gitorious:

1. The ecore eventloop integration
   Reason: Not yet cleaned up

2. The new introspection XML format (for C++ object transfer and
noreply functions)
   Reason: Not yet 100% tested

I thought about maintaining the ecore eventloop and the alternative XML
generator as separate projects.

What do you think about separating the XML generator and the eventloop
integrations (currently glib and ecore) from the main library in
separate packages?

regards
Andreas

Re: [dbus-cplusplus-devel] open wengo c++ bindings?

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

Am Wed, 07 Jan 2009 14:06:18 +1000 schrieb Ben Martin:

> > You don't have permission to
> > access /~martin/halwithstubs-2008nov25.tar.gz on this server.
> 
> The machine at the university had some hardware issues recently and it
> looks like they are back. I've attached this file to this email. Being
> only 150kb its not a *huge* attachment. For future stuff I'll find
> another dumping ground for tar.gz files.

http://binaryshare.com/

> > Did you make many changes on dbus-c++ for wengophone? Do you like to
> > provide a patch?
> 
> There is a small collection of things I'd like to do to dbus-c++. For
> example, if you have something that generates a class and a namespace
> with the same names the bindings generator will produce bad output at
> the moment. This happens for some of the HAL XML files.
> 
> Also, being able to make a "default" client class that is usable would
> stop the need for a fair bit of boilerplate coding just to make use of
> existing dbus services.
> 
> I notice you mentioned that you now have an fdo account. Was the
> procedure painful? I would like to get write access to the mainline
> dbusc++ source repository if my work is acceptable.

It wasn't painful. I followed the "howto get an account" somewhere on
fdo. After requesting for the account, it took several weeks without any
activity. Then I got an account.

regards
Andreas

Re: [dbus-cplusplus-devel] open wengo c++ bindings?

[Ben M. <mon...@us...>]

On Tue, 2009-01-06 at 13:15 +0100, Andreas Volz wrote:
> Am Sat, 06 Dec 2008 00:10:29 +1000 schrieb Ben Martin:
> 
> > Hi,
> >   Is this an ongoing development of the C++ DBus bindings from?
> > http://dev.openwengo.org/svn/openwengo/wengophone-ng/branches/wengophone-dbus-api/libs/dbus/
> > 
> >   Looking over the code, it seems very similar. I have a new example
> > to complement the existing hal one. My new version using the Client
> > stubs instead of using the DBus::CallMessage and invoke_method() etc.
> > 
> >   I have put my example up here for now:
> > http://kvo.cs.uow.edu.au/~martin/halwithstubs-2008nov25.tar.gz
> > 
> >   See the README file included for some issues and build information.
> > 
> >   Comments are welcome.
> 
> Hello Ben,
> 
> first sorry for not responding such a long time. Now I liked to view
> your example, but:

Hey, no problem. Everybody get busy :)

> 
> You don't have permission to
> access /~martin/halwithstubs-2008nov25.tar.gz on this server.

The machine at the university had some hardware issues recently and it
looks like they are back. I've attached this file to this email. Being
only 150kb its not a *huge* attachment. For future stuff I'll find
another dumping ground for tar.gz files.

> 
> Did you make many changes on dbus-c++ for wengophone? Do you like to
> provide a patch?

There is a small collection of things I'd like to do to dbus-c++. For
example, if you have something that generates a class and a namespace
with the same names the bindings generator will produce bad output at
the moment. This happens for some of the HAL XML files.

Also, being able to make a "default" client class that is usable would
stop the need for a fair bit of boilerplate coding just to make use of
existing dbus services.

I notice you mentioned that you now have an fdo account. Was the
procedure painful? I would like to get write access to the mainline
dbusc++ source repository if my work is acceptable.

Re: [dbus-cplusplus-devel] open wengo c++ bindings?

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

Am Sat, 06 Dec 2008 00:10:29 +1000 schrieb Ben Martin:

> Hi,
>   Is this an ongoing development of the C++ DBus bindings from?
> http://dev.openwengo.org/svn/openwengo/wengophone-ng/branches/wengophone-dbus-api/libs/dbus/
> 
>   Looking over the code, it seems very similar. I have a new example
> to complement the existing hal one. My new version using the Client
> stubs instead of using the DBus::CallMessage and invoke_method() etc.
> 
>   I have put my example up here for now:
> http://kvo.cs.uow.edu.au/~martin/halwithstubs-2008nov25.tar.gz
> 
>   See the README file included for some issues and build information.
> 
>   Comments are welcome.

Hello Ben,

first sorry for not responding such a long time. Now I liked to view
your example, but:

You don't have permission to
access /~martin/halwithstubs-2008nov25.tar.gz on this server.

Did you make many changes on dbus-c++ for wengophone? Do you like to
provide a patch?

regards
Andreas