dbus-cxx-devel Mailing List for dbus-cxx
Status: Beta
Brought to you by:
rvinyard
Menu
▾
▴
dbus-cxx-devel — For development of dbus-cxx itself
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(7) |
Jul
(5) |
Aug
(4) |
Sep
(13) |
Oct
(1) |
Nov
|
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(13) |
Feb
(12) |
Mar
(10) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Kimmy P. <xth...@gm...> - 2018-01-15 21:31:42
|
I'm creating a bitbake recipe to build dbus-cxx under yocto. However, the configuration as-is doesn't work for a separate build directory. The Yocto project has a workaround for this, but I was wondering if it might make sense to fix it here in the upstream repo. I understand it would be fairly trivial to do,, though I know nada about autoconf. Just going by the word around the campfire on #yocto. Apparently there are many other packages that are broken in this way. Thx - KDP |
|
From: Stipan R. <Sti...@ne...> - 2017-03-29 06:02:41
|
Hi there,
Just tried to build dbus-cxx library from the latest tar-ball (0.9.0). It didn't make it ...
connection.cpp:22:30: fatal error: dbus-cxx-private.h: No such file or directory
The file is indeed missing in the tar-ball; while I found it in the repo. Fixing that problem brought the following one.
In file included from connection.cpp:22:0:
dbus-cxx-private.h:28:26: fatal error: simplelogger.h: No such file or directory
That file is also available in the repo. Likely, no other file was missing and the make made it!
Hope it helps to others. Cheers,
Stipan Ruzicka
|
|
From: Karoline H. <kar...@ya...> - 2014-01-31 14:47:35
|
Hi I'm really interested in using dbus-cxx but I was wondering if the project is actually still under active development? It seems the last commits to the source code have been in 2011. Regards Karoline |
|
From: <nim...@ac...> - 2011-10-20 10:51:13
|
Has anyone succesfully used dbus-cxx succesfully on Meego? ________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. |
|
From: Michał 'K. R. <mi...@rz...> - 2010-04-09 12:05:33
|
Hi folks, To get arrays of strings working, I've come up with the attached patch. No real tests, but it seems to be doing the job. -- Michał 'Khorne' Rzechonek http://rzechonek.net |
|
From: Michał 'K. R. <mi...@rz...> - 2010-04-09 10:22:40
|
Hi folks,
String arrays work on the server side, the only needed addition is
namespace DBus
{
template<>
std::string signature<std::vector<std::string> >()
{
std::string t; return DBUS_TYPE_ARRAY_AS_STRING + signature(t);
}
}
After that I am able to register a method returning
std::vector<std::string> > and d-feet dbus debugger is able to call it
and get the correct result.
What I can't get to work is the client side. Without additional
specializations, calling a method proxy
::DBus::MethodProxy<std::vector<std::string> >::pointer f;
// ...
return (*f)();
causes the compiler to complain:
/usr/include/dbus-cxx-0.7/dbus-cxx/types.h:61: error: cannot convert
‘std::string’ to ‘DBus::Type’ in return
but after adding the following (weird) specialization:
namespace DBus
{
template<> inline Type type<std::string>() { return TYPE_STRING; }
}
It compiles, but cannot call the method because of an exception:
MessageIterator: Extracting non fixed array into std::vector
I am new to DBus, but from this message I can guess that array of
strings is quite different than array of primitives, which in glib
bindings is reflected by G_TYPE_STRV as opposed to G_FOO_ARRAY. If I
guess right, this requires the implementation to use
dbus_message_iter_open_container() instead of
dbus_message_iter_get_fixed_array() to read data.
This seems to be implemented in MessageAppendIterator
template <typename T>
void append( const std::vector<T>& v ) {
this->open_container( CONTAINER_ARRAY,
DBus::signature<T>().c_str() );
for ( size_t i=0; i < v.size(); i++ )
*m_subiter << v[i];
this->close_container();
}
but not in MessageIterator, as the default
template <typename T>
std::vector<T> get_array()
uses forementioned dbus_message_iter_get_fixed_array().
Is specializing MessageIterator::get_array method a correct way to
implement reading string arrays from the message?
cheers
--
Michał 'Khorne' Rzechonek
http://rzechonek.net
|
|
From: Rick L. V. Jr. <rvi...@cs...> - 2010-03-23 15:24:06
|
I added a quick start guide to dbus-cxx-xml2cpp and cleaned up the doxygen generated output for the previous quick start guide. I also added a small section on using pkgconfig as well as the ax_dbus_cxx_xml2cpp.m4 macro. It's available on the dbus-cxx website at sourceforge and will also be in the docs when the next dbus-cxx release happens. -- Rick |
|
From: Patrick A. <pa...@ph...> - 2010-03-18 18:36:01
|
On Thu, 2010-03-18 at 10:02 -0600, Rick L. Vinyard, Jr. wrote: > However, I did noticed that in the newest release of dbus (1.2.22) there > is a fix for a race condition in the watch handlers. Sadly, it's the wrong fix. There are two threads, of course, and so the bug happens in two ways: 1) watch thread calls watch_handle while another thread has I/O path 2) another thread calls dbus_connection_send while watch thread has I/O path That patch fixes case #1. Case #2 is still unhandled. > I keep hoping to "acquire" a test case by stumbling across it, but I > haven't been bitten by the bug yet. I can try to write one up soon. The best way to have it happen is to have D-Bus method A emit D-Bus signal B, and then call method A a bajillion times. Needs to be run on an SMP machine, obviously. Still takes about 5-10 minutes, though. Patrick |
|
From: Rick L. V. Jr. <rvi...@cs...> - 2010-03-18 16:02:44
|
Patrick Allison wrote:
>> > There are two ways to actually fix this (well, 3 really):
>> > 1) Set a mutex between the watch thread and the dispatch thread such
>> > that you never dispatch while handling watches, and you never handle
>> > watches while dispatching. For some reason I couldn't get this to
>> work.
>> > It should be simple: just a mutex lock around each if (FD_ISSET()) {}
>> > block, and a mutex lock around the (*ci)->dispatch() calls. I probably
>> > just screwed it up simply somehow.
>> >
>>
>> I'd prefer the simpler approach, but it may be a week or two before I
>> have
>> time to look into it. Things are pretty hectic right now.
>>
>
> Well, which one is the "simpler approach" is debatable. The downside to
> putting mutexes around the watch/dispatch is of course that if a
> dispatch takes a fair amount of time, you won't be able to handle reads
> or writes during that time.
>
> But it is probably best right now to implement it that way - I've been
> getting intermittent weirdness (once every few days) where the watch
> thread blows up in an infinite loop inside the sigc++ library when it
> tries to emit the "dispatch_status_changed" signal, and so I hacked the
> dispatch/watch threads to move the actual watch handling inside the
> dispatch thread (the watch thread just wakes the dispatch thread when a
> file descriptor is ready, and then waits for the dispatch thread to
> handle it).
>
> That fixed the problem, so I think there might be other problems inside
> libdbus with trying to dispatch at the same time as watch handling. But
> I don't recommend my approach because it's godawful, and a simple mutex
> should solve that.
>
> I'll try to actually write up an simple example piece of code which
> blows up this way in a few days, which should help. Sadly I can't just
> reuse the code in the application I'm using because it's waay too
> complex.
>
> Definitely understand the "pretty hectic" bit, though - that's why I
> hadn't had time to even check the current code for a long while!
>
> Personally I just wish we'd hear *anything* from the D-Bus developers
> regarding this issue, though, considering it's definitely a bug in
> libdbus and not a bug in dbus-cxx. It's not even really a bug involving
> watch handling/dispatching at the same time - it's just that there's
> only a very narrow window for the bug to happen.
>
I just pushed out a new release, but I still haven't addressed the race
condition.
I'd like to find something that would allow us to simultaneously handle
watches and dispatch without having to modify too much.
However, I did noticed that in the newest release of dbus (1.2.22) there
is a fix for a race condition in the watch handlers.
The old code was:
_dbus_connection_acquire_io_path (connection, -1);
And the new code checks the return value and unlocks the connection:
if (!_dbus_connection_acquire_io_path (connection, 1))
{
/* another thread is handling the message */
CONNECTION_UNLOCK (connection);
return TRUE;
}
I haven't traced the code to see if it's going to fix the issue we
currently have, or even developed a simple test case.
I keep hoping to "acquire" a test case by stumbling across it, but I
haven't been bitten by the bug yet.
--
Rick
|
|
From: Rick L. V. Jr. <rvi...@cs...> - 2010-03-18 15:47:26
|
dbus-cxx is a C++ wrapper for the dbus library http://dbus-cxx.sourceforge.net ===== 0.7.0 ===== This release primarily features code cleanup, but in doing so there were several minor feature additions, added documentation, bug fixes and minor API changes. == New Documentation and Tutorial == A quickstart guide has been added to the documentation. This will take you through a simple client/server example. The quickstart tutorial can be found in the documentation or on the dbus-cxx website here: http://dbus-cxx.sourceforge.net/quick_start.html Also, documentation has been added for many of the m4 generated templates. == Cleanup == A significant portion of the cleanup related to the headers. As the library grew and evolved the headers became messy, from old includes that are no longer needed to templates that had very touchy include orders. These have been significantly cleaned up and several key template headers have been split into two parts with the first part declarations and the second part definitions and specializations. The utility.h header had also grown to include many things beyond simple utility functions. The dbus typing functions have been split out into types.h and the introspect() function has been properly incorporated into the DBus::Connection class. The functions related to signatures in utility.h have been moved into the header signature.h along where DBus::Signature is. == New API == * In cleaning up the macros that generate the sigc++ slot based DBus::Method templates support for void methods has been added. * A force parameter was added to DBus::Object::add_child() to allow a child with a similar name to be forced into the hierarchy replacing the old child == Key API Changes == * DBus::Dispatcher's constructor is now protected; use DBus::Dispatcher::create() to allocate a smart pointer * When a named object interface doesn't handle an incoming message, the default interface is tried before failing. -- Rick |
|
From: Rick L. V. Jr. <rvi...@cs...> - 2010-03-11 16:14:31
|
dbus-cxx has developed some cruft as recent things have been added. An example of this is the introspect() method in utility.h which really belongs as a method of the Connection class. Another example is the state of the headers. There are some very intricate interdependencies with the templates and the m4 generation code doesn't help matters. I've started cleaning things up a bit, and I'll gradually be committing code to the repository. In general I'll try not to break compilation of the svn repo, but there may be a few times I do. As things progress, feedback and testing are welcome. -- Rick |
|
From: Patrick A. <pa...@ph...> - 2010-03-04 20:27:03
|
> > There are two ways to actually fix this (well, 3 really):
> > 1) Set a mutex between the watch thread and the dispatch thread such
> > that you never dispatch while handling watches, and you never handle
> > watches while dispatching. For some reason I couldn't get this to work.
> > It should be simple: just a mutex lock around each if (FD_ISSET()) {}
> > block, and a mutex lock around the (*ci)->dispatch() calls. I probably
> > just screwed it up simply somehow.
> >
>
> I'd prefer the simpler approach, but it may be a week or two before I have
> time to look into it. Things are pretty hectic right now.
>
Well, which one is the "simpler approach" is debatable. The downside to
putting mutexes around the watch/dispatch is of course that if a
dispatch takes a fair amount of time, you won't be able to handle reads
or writes during that time.
But it is probably best right now to implement it that way - I've been
getting intermittent weirdness (once every few days) where the watch
thread blows up in an infinite loop inside the sigc++ library when it
tries to emit the "dispatch_status_changed" signal, and so I hacked the
dispatch/watch threads to move the actual watch handling inside the
dispatch thread (the watch thread just wakes the dispatch thread when a
file descriptor is ready, and then waits for the dispatch thread to
handle it).
That fixed the problem, so I think there might be other problems inside
libdbus with trying to dispatch at the same time as watch handling. But
I don't recommend my approach because it's godawful, and a simple mutex
should solve that.
I'll try to actually write up an simple example piece of code which
blows up this way in a few days, which should help. Sadly I can't just
reuse the code in the application I'm using because it's waay too
complex.
Definitely understand the "pretty hectic" bit, though - that's why I
hadn't had time to even check the current code for a long while!
Personally I just wish we'd hear *anything* from the D-Bus developers
regarding this issue, though, considering it's definitely a bug in
libdbus and not a bug in dbus-cxx. It's not even really a bug involving
watch handling/dispatching at the same time - it's just that there's
only a very narrow window for the bug to happen.
Patrick
|
|
From: Rick L. V. Jr. <rvi...@cs...> - 2010-03-03 23:14:30
|
Patrick Allison wrote:
> Hi all:
>
> The watch/dispatch race fix in dbus-cxx 0.6 still needs a bit more
> tweaking, unfortunately. The current fix does: after a watch is handled,
> it sets need_initiate_processing_hack, and then if that's set, it wakes
> up the dispatch thread.
>
> That's not exactly the problem, though - the dispatch thread will just
> wake up, see that it has nothing to do (since the dispatch status is
> complete) and go back to sleep. In fact, to remind, the problem is:
>
> 1) watch thread wakes up, select() says there's data to read
> 2) calls handle_read() on that Watch
> 3) This queues a message, which changes the dispatch status, which wakes
> the dispatch thread.
> 4) The dispatch thread dispatches the message, which calls
> Connection::send for the reply. The watch thread still holds the IO
> path, so this message gets silently queued
> 5) The watch thread finishes handle_read().
>
> In the current hack, all that happens next is that
> 6) the watch thread wakes up the dispatch thread again
> 7) the dispatch thread sees the dispatch status is DISPATCH_COMPLETE and
> wonders why it was woken up before going back to sleep.
>
> There are two ways to actually fix this (well, 3 really):
> 1) Set a mutex between the watch thread and the dispatch thread such
> that you never dispatch while handling watches, and you never handle
> watches while dispatching. For some reason I couldn't get this to work.
> It should be simple: just a mutex lock around each if (FD_ISSET()) {}
> block, and a mutex lock around the (*ci)->dispatch() calls. I probably
> just screwed it up simply somehow.
>
I'd prefer the simpler approach, but it may be a week or two before I have
time to look into it. Things are pretty hectic right now.
--
Rick
|
|
From: Patrick A. <pa...@ph...> - 2010-03-03 22:49:56
|
Hi all:
The watch/dispatch race fix in dbus-cxx 0.6 still needs a bit more
tweaking, unfortunately. The current fix does: after a watch is handled,
it sets need_initiate_processing_hack, and then if that's set, it wakes
up the dispatch thread.
That's not exactly the problem, though - the dispatch thread will just
wake up, see that it has nothing to do (since the dispatch status is
complete) and go back to sleep. In fact, to remind, the problem is:
1) watch thread wakes up, select() says there's data to read
2) calls handle_read() on that Watch
3) This queues a message, which changes the dispatch status, which wakes
the dispatch thread.
4) The dispatch thread dispatches the message, which calls
Connection::send for the reply. The watch thread still holds the IO
path, so this message gets silently queued
5) The watch thread finishes handle_read().
In the current hack, all that happens next is that
6) the watch thread wakes up the dispatch thread again
7) the dispatch thread sees the dispatch status is DISPATCH_COMPLETE and
wonders why it was woken up before going back to sleep.
There are two ways to actually fix this (well, 3 really):
1) Set a mutex between the watch thread and the dispatch thread such
that you never dispatch while handling watches, and you never handle
watches while dispatching. For some reason I couldn't get this to work.
It should be simple: just a mutex lock around each if (FD_ISSET()) {}
block, and a mutex lock around the (*ci)->dispatch() calls. I probably
just screwed it up simply somehow.
2a) At the end of the watch thread, loop over the connections, and if
there are messages pending, call Connection::flush on them. This is
sadly a bit brute force because there could be messages pending due to
the socket being full, in which case the thread will block
unnecessarily. It's also a pain because the watch thread doesn't loop
over connections at all, so it's not that elegant.
2b) Change DBus::Connection::signal_add_watch to take a Connection
object as well as the watch object, and add a DBus::Connection pointer
inside the Watch. Then, after the watch thread completes, loop over all
watches in m_write_watches, and then if
watch->connection()->has_messages_to_send && !watch->is_enabled() , call
watch->connection()->flush(). You could do this with no changes at all
currently, if you matched the watch->unix_fd() to the
connection->unix_fd() but that seems complex. Not sure it's as simple as
this, though, because the question of ownership of the DBus::Connection
object exists, so maybe matching via the unix_fd() etc. is needed (geh).
Patrick
|
|
From: Rick L. V. Jr. <rvi...@cs...> - 2010-03-01 19:53:24
|
Tyler Conant wrote: > I haven't moved forward on this because I was looking for some opinions > about adding a requirement for boost. I use boost heavily in most my > projects so it was my first choice, however adding a requirement to a > conveniently light package like dbus-cxx usually raises objections so I > was waiting for some feedback. You're right. I do want to keep dbus-cxx as light as possible for the default builds. But, I have no objection to something that adds an autoconf option such as --with-boost that would then pull in the boost library along with a define that would be in the code. > I believe dbus-cxx uses boost when > available for smart pointers and falls back to an internal implementation > when not available, but I could be wrong. Mostly correct. It looks for a c++0x implementation first, then a tr1, then boost. -- Rick |
|
From: Tyler C. <tc...@ta...> - 2010-03-01 18:07:15
|
I haven't moved forward on this because I was looking for some opinions about adding a requirement for boost. I use boost heavily in most my projects so it was my first choice, however adding a requirement to a conveniently light package like dbus-cxx usually raises objections so I was waiting for some feedback. I believe dbus-cxx uses boost when available for smart pointers and falls back to an internal implementation when not available, but I could be wrong. I'll start on the boost approach and if everyone likes it then great, if not we can look at an alternative. On 2/26/10 7:32 AM, "Rick L. Vinyard, Jr." <rvi...@cs...> wrote: Ramin Yaghoubzadeh wrote: > Tyler Conant wrote: >> I'm thinking about adding OS X support for this project. The immediate >> issue I run into when compiling is the use of timer_t. OS X doesn't >> support the TMR option of POSIX. One of the options would be to use the >> asio library from boost. Does anyone have any thoughts on this matter. >> It would probably mean not using signals but rather a separate thread to >> handle timers. > > Did you (or someone else) in the mean time reach any preliminary decision > about it, or even working code implementing this? > > Our workgroup would very much welcome any progress towards having > dbus-cxx (incl. dbus-cxx-glibmm) run on OSX - in fact, the lack of > support of D-Bus on OSX in C++ (as opposed to other languages) is the > only unaddressed (but essential) point left in our emerging D-Bus-based > communication layer. (I did already silently curse the OSX team for > omitting the practically omnipresent timer extension..) > I could probably contribute some time again working on / debugging > this as well! I agree with your approach, but I cannot contribute > any knowledge or assessment of the asio lib :( > > Would love to hear any news regarding this, > Regards, > Ramin Although I can't test it, I'd be happy to accept any patches into the mainline code as well. Especially if there are two or more people out there are testing it. -- Rick ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Dbus-cxx-devel mailing list Dbu...@li... https://lists.sourceforge.net/lists/listinfo/dbus-cxx-devel |
|
From: Rick L. V. Jr. <rvi...@cs...> - 2010-02-26 15:32:36
|
Ramin Yaghoubzadeh wrote: > Tyler Conant wrote: >> I'm thinking about adding OS X support for this project. The immediate >> issue I run into when compiling is the use of timer_t. OS X doesn't >> support the TMR option of POSIX. One of the options would be to use the >> asio library from boost. Does anyone have any thoughts on this matter. >> It would probably mean not using signals but rather a separate thread to >> handle timers. > > Did you (or someone else) in the mean time reach any preliminary decision > about it, or even working code implementing this? > > Our workgroup would very much welcome any progress towards having > dbus-cxx (incl. dbus-cxx-glibmm) run on OSX - in fact, the lack of > support of D-Bus on OSX in C++ (as opposed to other languages) is the > only unaddressed (but essential) point left in our emerging D-Bus-based > communication layer. (I did already silently curse the OSX team for > omitting the practically omnipresent timer extension..) > I could probably contribute some time again working on / debugging > this as well! I agree with your approach, but I cannot contribute > any knowledge or assessment of the asio lib :( > > Would love to hear any news regarding this, > Regards, > Ramin Although I can't test it, I'd be happy to accept any patches into the mainline code as well. Especially if there are two or more people out there are testing it. -- Rick |
|
From: Ramin Y. <rya...@te...> - 2010-02-26 14:37:32
|
Tyler Conant wrote: > I'm thinking about adding OS X support for this project. The immediate issue I run into when compiling is the use of timer_t. OS X doesn't support the TMR option of POSIX. One of the options would be to use the asio library from boost. Does anyone have any thoughts on this matter. It would probably mean not using signals but rather a separate thread to handle timers. Did you (or someone else) in the mean time reach any preliminary decision about it, or even working code implementing this? Our workgroup would very much welcome any progress towards having dbus-cxx (incl. dbus-cxx-glibmm) run on OSX - in fact, the lack of support of D-Bus on OSX in C++ (as opposed to other languages) is the only unaddressed (but essential) point left in our emerging D-Bus-based communication layer. (I did already silently curse the OSX team for omitting the practically omnipresent timer extension..) I could probably contribute some time again working on / debugging this as well! I agree with your approach, but I cannot contribute any knowledge or assessment of the asio lib :( Would love to hear any news regarding this, Regards, Ramin |
|
From: Rick L. V. Jr. <rvi...@cs...> - 2010-02-16 15:40:13
|
roland roland wrote: > Thanks Rick, > > How do I access interface properties in dbus c ? Can you point me to an > example that does that? I found many example that demonstrate methods and > signals, but none that access properties. I'm not sure. I haven't looked into them yet. Do you have control over the DBus interface, or do you need to access one that someone else has specified? If it's the former I would recommend using get/set methods as accessors. If it's the latter, I'm not sure. > I tried invoking "Get" method on "org.freedesktop.DBus.Properties", but > that > returned "Method "Get" with signature "ss" on interface > "org.freedesktop.DBus.Properties" doesn't exist" ??? > Possible. I haven't messed with properties yet. If you get it figured out you might post a follow up for others. |
|
From: roland r. <rro...@gm...> - 2010-02-12 04:03:39
|
Thanks Rick, How do I access interface properties in dbus c ? Can you point me to an example that does that? I found many example that demonstrate methods and signals, but none that access properties. I tried invoking "Get" method on "org.freedesktop.DBus.Properties", but that returned "Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist" ??? I might help contribute patches for this library. But first let me come up to the mark. On Thu, Feb 11, 2010 at 8:19 AM, Rick L. Vinyard, Jr. <rvi...@cs...>wrote: > roland roland wrote: > > Can someone help me understand, how I could access an Interfaces > > properties? > > There are Interface and InterfaceProxy classes depending on whether you're > on server or client side. > > I haven't written anything wrapping interface properties; just methods and > signals for now, since that's what I needed. > > > In general, I read that dbus-cxx attempts to provide high-level > > dbus-binding. What are its limitation? > > There are a number of aspects that still aren't wrapped... like properties > and Variants. > > > Given a DBus service, what things can I not do with dbus-cxx? > > I intentionally exposed the underlying dbus C library. Anything that isn't > supported yet in dbus-cxx can still be handled in the C library. > > > --- > > Rick > > > > |
|
From: Rick L. V. Jr. <rvi...@cs...> - 2010-02-11 16:34:26
|
> On 10/02/10 11:18 PM, pan son wrote:
>> I do not see any example showing implementation if an object method
>> accepts Variants or arrays of strings.
>> Moreover, the dbus-cxx-xml2cpp tool do not generate proxy methods for
>> such type of object methods.
>>
>> dbus-c++ use to support them by ::DBus::Variant and even std::map of
>> (string , variant).
>>
>> Can anyone throw some light on this please?
>> Any help is highly appreciated.
>>
>> thanks,
>> Pan Son
Julien Bonjean wrote:
> Hi Pan,
>
> AFAIK Variants and arrays are not supported by this library.
> Regards,
>
> Julien Bonjean
>
Variants aren't supported yet, but you should be able to use DBus arrays
on messages with a std::vector of primitives. std::string might work but I
haven't tested it yet.
It's not much of an example, but the unit tests:
call_message_append_extract_iterator_array_int()
call_message_iterator_insertion_extraction_operator_array_int()
in unit-tests/messageiteratortests.cpp should give some insight.
---
Rick
|
|
From: Rick L. V. Jr. <rvi...@cs...> - 2010-02-11 16:19:45
|
roland roland wrote: > Can someone help me understand, how I could access an Interfaces > properties? There are Interface and InterfaceProxy classes depending on whether you're on server or client side. I haven't written anything wrapping interface properties; just methods and signals for now, since that's what I needed. > In general, I read that dbus-cxx attempts to provide high-level > dbus-binding. What are its limitation? There are a number of aspects that still aren't wrapped... like properties and Variants. > Given a DBus service, what things can I not do with dbus-cxx? I intentionally exposed the underlying dbus C library. Anything that isn't supported yet in dbus-cxx can still be handled in the C library. --- Rick |
|
From: Rick L. V. Jr. <rvi...@cs...> - 2010-02-11 16:07:46
|
pan son wrote: > I do not see any example showing implementation if an object method > accepts > Variants or arrays of strings. > Moreover, the dbus-cxx-xml2cpp tool do not generate proxy methods for such > type of object methods. Variants aren't supported. Arrays are new enough that I'm not sure if the structure will support them. I've only tried primitives with arrays so far. > dbus-c++ use to support them by ::DBus::Variant and even std::map of > (string > , variant). > > Can anyone throw some light on this please? > Any help is highly appreciated. At some point I'd like dbus-cxx to also support those, but I haven't had time to come up with a clean implementation that I'm happy with. dbus-cxx is, for the most part, completely unrelated to dbus-c++. For anything in the dbus library that isn't supported by dbus-cxx (like variants) you would have to fall back to the dbus C library through the cobj() methods which returns a pointer to the underlying C object. But, if you wanted to implement Variants and or test/add an example of string arrays I'd be happy to accept a patch. --- Rick |
|
From: Rick L. V. Jr. <rvi...@cs...> - 2010-02-11 16:01:30
|
pan son wrote: > I installed the latest version 0.6.0 of dbus-cxx. I do not see the > executables dbus-cxx-xml2cpp and the introspect command for creating xmls. > Do I need to download them seperately? if yes, from where? > It depends on how you installed it (from the source tarball or from the rpm). If it was from the source tarball make sure you enabled the tools option on configure. ./configure --enable-tools To get a full listing of the options: ./configure --help --- Rick |
|
From: Julien B. <ju...@bo...> - 2010-02-11 14:47:41
|
Hi Pan, AFAIK Variants and arrays are not supported by this library. Regards, Julien Bonjean On 10/02/10 11:18 PM, pan son wrote: > I do not see any example showing implementation if an object method > accepts Variants or arrays of strings. > Moreover, the dbus-cxx-xml2cpp tool do not generate proxy methods for > such type of object methods. > > dbus-c++ use to support them by ::DBus::Variant and even std::map of > (string , variant). > > Can anyone throw some light on this please? > Any help is highly appreciated. > > thanks, > Pan Son > > > ------------------------------------------------------------------------------ > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > > > _______________________________________________ > Dbus-cxx-devel mailing list > Dbu...@li... > https://lists.sourceforge.net/lists/listinfo/dbus-cxx-devel > |
2 messages has been excluded from this view by a project administrator.
