dbus-cxx-users Mailing List for dbus-cxx (Page 3)
Status: Beta
Brought to you by:
rvinyard
Menu
▾
▴
dbus-cxx-users — For those using the dbus-cxx library in their applications
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(11) |
Jul
(3) |
Aug
(1) |
Sep
(11) |
Oct
(2) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(4) |
Feb
(2) |
Mar
(3) |
Apr
(1) |
May
|
Jun
(7) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2012 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(3) |
Nov
(3) |
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
|
From: <vas...@gm...> - 2009-09-16 16:52:30
|
Hello, I'm trying to generate some bindings from the xml attached and the StartRMNode method is ignored and the code for it is not present in the controller_proxy, controller_adapter. If I remove any three parameters from the method the generation works fine. Best, Vasile |
|
From: Kees J. <kee...@gm...> - 2009-09-10 07:54:20
|
Hi, I would like to use the dbus-cxx bindings in a commercial app. while libdbus is released under a more permissive license (LGPLV2) allowing it to link against close source components the cxx bindings are license under GPLV3 (not LGPL) was that a conscious choice? are there other licensing option available? Greetings |
|
From: Rick L. V. Jr. <rvi...@cs...> - 2009-09-02 21:14:07
|
vas...@gm... wrote:
> Sorry about replying to my own post but maybe someone may use this. The
> problem was in the constructor of the Controller
> class, I had this code in place which I assumed messed with the copy
> constructor creation in the code generated by XML:
>
> Controller::Controller() {
> //initialize logger
> //TODO move outside the constructor
> logger = log4cxx::Logger::getLogger("Controller");
> BasicConfigurator::configure();
> logger->setLevel(log4cxx::Level::getTrace());
>
> }
>
> Vasile
>
Sounds like you got it figured out then?
I'm surprised that the Controller's constructor would effect the adapter
though, since the only thing that is really stored is a pointer to the
adaptee.
|
|
From: <vas...@gm...> - 2009-09-02 16:20:02
|
On Wednesday 02 September 2009 15:58:05 Vas...@so... wrote:
> Hi, I am trying to use dbus-cxx 0.4.2 with a project and I have run into
> some trouble. I'm using the code from the calculator example, modified for
> what I am doing:
>
> DBus::init();
>
> int ret;
>
> DBus::Dispatcher dispatcher;
>
> DBus::Connection::pointer conn =
> dispatcher.create_connection(DBus::BUS_SESSION); std::cout << "Requesting
> name" << endl;
> // request a name on the bus
> ret = conn->request_name( "pa.agent.controller",
> DBUS_NAME_FLAG_REPLACE_EXISTING ); if
> (DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER != ret) {
> cout << "Shit happened" << endl;
> }
> std::cout << "Declaring adapter" << endl;
>
> Controller controller;
> std::cout << "Creating adapter" << controller.startnode()<< endl;
>
>
> DBus::ControllerAdapter::pointer adapter =
> DBus::ControllerAdapter::create(&controller);
>
>
> The program gets stuck at
> DBus::ControllerAdapter::pointer adapter =
> DBus::ControllerAdapter::create(&controller);
>
> With this output:
>
> Requesting name
> Declaring adapter
> Creating adapter0
> terminate called after throwing an instance of 'DBus::Error'
> what(): Did not receive a reply. Possible causes include: the remote
> application did not send a reply, the message bus security policy blocked
> the reply, the reply timeout expired, or the network connection was
> broken.
>
> Thanks,
> Vasile
>
Sorry about replying to my own post but maybe someone may use this. The problem was in the constructor of the Controller
class, I had this code in place which I assumed messed with the copy constructor creation in the code generated by XML:
Controller::Controller() {
//initialize logger
//TODO move outside the constructor
logger = log4cxx::Logger::getLogger("Controller");
BasicConfigurator::configure();
logger->setLevel(log4cxx::Level::getTrace());
}
Vasile
|
|
From: <Vas...@so...> - 2009-09-02 12:58:17
|
Hi, I am trying to use dbus-cxx 0.4.2 with a project and I have run into some trouble. I'm using the code from the
calculator example, modified for what I am doing:
DBus::init();
int ret;
DBus::Dispatcher dispatcher;
DBus::Connection::pointer conn = dispatcher.create_connection(DBus::BUS_SESSION);
std::cout << "Requesting name" << endl;
// request a name on the bus
ret = conn->request_name( "pa.agent.controller", DBUS_NAME_FLAG_REPLACE_EXISTING );
if (DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER != ret) {
cout << "Shit happened" << endl;
}
std::cout << "Declaring adapter" << endl;
Controller controller;
std::cout << "Creating adapter" << controller.startnode()<< endl;
DBus::ControllerAdapter::pointer adapter = DBus::ControllerAdapter::create(&controller);
The program gets stuck at
DBus::ControllerAdapter::pointer adapter = DBus::ControllerAdapter::create(&controller);
With this output:
Requesting name
Declaring adapter
Creating adapter0
terminate called after throwing an instance of 'DBus::Error'
what(): Did not receive a reply. Possible causes include: the remote application did not send a reply, the message
bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Thanks,
Vasile
|
|
From: SourceForge.net <no...@so...> - 2009-08-24 15:43:45
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7580652 By: rvinyard There are no code changes in this release. This release adds support for building debian packages. You can use 'make deb' to build the debian packages. The debian build files are in the typical debian/ directory. As this is my first attempt at a debian cdbs package there are bound to be issues, but it was tested on Ubuntu-Jaunty-i386 and all seemed well enough. Also, this release splits the docs into their own download file. This should make it a bit easier for those without broadband. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=943815 |
|
From: Rick L. V. Jr. <rvi...@cs...> - 2009-07-29 18:17:12
|
Darrell Schiebel wrote: > > I tried to enter a new bug report, but apparently only members of the > project may report bugs... You should be able to enter a bug report if you are logged into Sourceforge. I got tired of false bug reports filed by spammers. > dbus-cxx fails to compile on osx because osx does not implement POSIX > timers. Apple claims that these timers are an *optional* POSIX > extension and that programs should check to see if they are available: > > http://lists.apple.com/archives/unix-porting/2006/Apr/msg00010.html > http://lists.apple.com/archives/unix-porting/2006/Apr/msg00012.html > http://lists.apple.com/archives/unix-porting/2009/May/msg00004.html > > I explored a bit to see what would be the next roadblock and that > seems to be gcc/g++ issues: > > g++ -DHAVE_CONFIG_H -I. -I.. -I../. -I../. -I/opt/local/include/ > dbus-1.0 -I/opt/local/lib/dbus-1.0/include -I/opt/local/include/sigc+ > +-2.0 -I/opt/local/lib/sigc++-2.0/include -g -O2 -MT connection.lo -MD > -MP -MF .deps/connection.Tpo -c connection.cpp -fno-common -DPIC - > o .libs/connection.o > In file included from ../dbus-cxx/object.h:14, > from connection.h:32, > from connection.cpp:20: > ../dbus-cxx/interface.h:75: error: default template arguments may not > be used in function templates > ../dbus-cxx/interface.h:201: error: default template arguments may not > be used in function templates > In file included from connection.h:32, > from connection.cpp:20: > > so I assume this is some new feature of gcc/g++ which my version (gcc > 4.2.1) does not yet support? > Possible. Most of the development was done on gcc 4.4, but I know it compiles on gcc 4.3 because that's what Fedora 9 uses. > In file included from ../dbus-cxx/object.h:14, > from connection.h:32, > from connection.cpp:20: > ../dbus-cxx/interface.h:75: error: default template arguments may not > be used in function templates > ../dbus-cxx/interface.h:201: error: default template arguments may not > be used in function templates > In file included from connection.h:32, > from connection.cpp:20: > > so I assume this is some new feature of gcc/g++ which my version (gcc > 4.2.1) does not yet support? > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. > http://p.sf.net/sfu/bobj-july_______________________________________________ > Dbus-cxx-users mailing list > Dbu...@li... > https://lists.sourceforge.net/lists/listinfo/dbus-cxx-users > |
|
From: Darrell S. <dr...@nr...> - 2009-07-29 16:27:33
|
I tried to enter a new bug report, but apparently only members of the project may report bugs... dbus-cxx fails to compile on osx because osx does not implement POSIX timers. Apple claims that these timers are an *optional* POSIX extension and that programs should check to see if they are available: http://lists.apple.com/archives/unix-porting/2006/Apr/msg00010.html http://lists.apple.com/archives/unix-porting/2006/Apr/msg00012.html http://lists.apple.com/archives/unix-porting/2009/May/msg00004.html I explored a bit to see what would be the next roadblock and that seems to be gcc/g++ issues: g++ -DHAVE_CONFIG_H -I. -I.. -I../. -I../. -I/opt/local/include/ dbus-1.0 -I/opt/local/lib/dbus-1.0/include -I/opt/local/include/sigc+ +-2.0 -I/opt/local/lib/sigc++-2.0/include -g -O2 -MT connection.lo -MD -MP -MF .deps/connection.Tpo -c connection.cpp -fno-common -DPIC - o .libs/connection.o In file included from ../dbus-cxx/object.h:14, from connection.h:32, from connection.cpp:20: ../dbus-cxx/interface.h:75: error: default template arguments may not be used in function templates ../dbus-cxx/interface.h:201: error: default template arguments may not be used in function templates In file included from connection.h:32, from connection.cpp:20: so I assume this is some new feature of gcc/g++ which my version (gcc 4.2.1) does not yet support? |
|
From: SourceForge.net <no...@so...> - 2009-07-06 14:29:58
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7482748 By: rvinyard This release adds support to dbus-cxx-xml2cpp allowing proxies to multiply inherit virtual interfaces. An example demonstrating how to use this feature can be found in examples/xml2cpp/calculator-interface. Additionally, a few warnings were cleaned up including one regarding unused values when debugging output is turned off. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=943815 |
|
From: SourceForge.net <no...@so...> - 2009-06-18 15:18:07
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7451765 By: rvinyard This release introduces the dbus-cxx-glibmm library to provide a means of integrating dbus-cxx with glibmm. The key class is DBus::Glib::Dispatcher which performs exactly like DBus::Dispatcher except all actual dispatching occurs in the Glibmm main loop. Since Gtkmm uses Glibmm for it's main loop this also provides a mechanism for integrating dbus-cxx into Gtkmm. To enable glibmm support pass --enable-glibmm to configure. There are also a few new changes to DBus::Dispatcher. The constructor now accepts a boolean parameter is_running (defaults to true) that will automatically start the dispatcher when constructed. Also, the dispatcher will call stop() on destruction to effect an orderly shutdown. DBus::Dispatcher has had a few bugs fixed and a few missing pieces filled in. The watch thread finally has support for the case where there are no watches. Instead, the watch thread will use sleep for the same timeout period as select() was using and upon reawakening will check for new watches. A missing mutex was also added to DBus::Dispatcher::create_connection(), and a hack was removed from the dispatch thread that called flush() on each connection (the auto-start on the Dispatchers revealed the source of the problem and the need for the hack). Finally, the standard pointer typedef and static create() methods were added to the dispatcher classes to standardize across all dbus-cxx classes. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=943815 |
|
From: SourceForge.net <no...@so...> - 2009-06-17 14:44:41
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7449646 By: rvinyard This is primarily a bugfix release. The introspection method in signal_base now returns a null string. In the proxy/adapter generator dbus-cxx-xml2cpp the castable types now are individually guarded in #defines to alleviate the case where more than one proxy or adapter defines the same message iterator overloads. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=943815 |
|
From: SourceForge.net <no...@so...> - 2009-06-16 16:56:32
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7447736 By: rvinyard This release introduces a new macro DBUS_CXX_ITERATOR_SUPPORT to support types that are not natively supported by dbus-cxx but can be static_cast<> to a supported type. This is typically most useful for supporting enumeration types. dbus-cxx-xml2cpp has been modified to use DBUS_CXX_ITERATOR_SUPPORT to support castable types when generating proxy and adapter interfaces for both methods and signals. The example computer-is-a has been modified to demonstrate the use of dbus-cxx-xml2cpp and enums with both methods and signals. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=943815 |
|
From: SourceForge.net <no...@so...> - 2009-06-15 19:51:31
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7445954 By: rvinyard This release adds support to dbus-cxx-xml2cpp which generates C++ proxies and adapters from DBus XML introspection-like files. The 'cpptype' attribute to 'arg' nodes now allows specific types to be associated with an argument when the proxy and adapter are generated. This is particularly useful for generating methods that have enumeration types. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=943815 |
|
From: SourceForge.net <no...@so...> - 2009-06-12 16:01:11
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7441108 By: rvinyard This is a bugfix release that corrects an issue with the Dispatcher that caused 100% cpu utilization. Thanks to Patrick Allison for hunting this one down. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=943815 |
|
From: Rick L. V. Jr. <rvi...@cs...> - 2009-06-12 15:54:58
|
Hello Patrick, Thanks for looking into this one. It's fixed in 0.3.1. Patrick Allison wrote: > Hi: > > watch_thread_main reuses its struct timeval timeout after passing a > pointer to it to select(). Under Linux, the timeout is modified to reflect > the amount of time remaining before timeout (i.e. zero after a timeout). > POSIX allows either behavior (modifying or not modifying), and recommends > that timeout be considered undefined after the select() call. > > Since the timeout's reduced to zero after the first call, the dispatcher's > watch thread consumes 100% of the CPU. > > A simple fix is just > struct timeval timeout = m_responsiveness; > .. select(... , &timeout); > > instead of just passing &m_responsiveness. > > Patrick > |
|
From: Patrick A. <pa...@ph...> - 2009-06-11 22:11:13
|
Hi: watch_thread_main reuses its struct timeval timeout after passing a pointer to it to select(). Under Linux, the timeout is modified to reflect the amount of time remaining before timeout (i.e. zero after a timeout). POSIX allows either behavior (modifying or not modifying), and recommends that timeout be considered undefined after the select() call. Since the timeout's reduced to zero after the first call, the dispatcher's watch thread consumes 100% of the CPU. A simple fix is just struct timeval timeout = m_responsiveness; .. select(... , &timeout); instead of just passing &m_responsiveness. Patrick |
|
From: Rick L. V. Jr. <rvi...@cs...> - 2009-06-08 22:12:47
|
Hello Patrick: Patrick Allison wrote: > Hi: > > I've just started using dbus-cxx, and I'm having a bit of difficulty. I'm > trying to replicate the "callee_object"/"caller_object" example: in my > case, the class method looks like > > char saw(time_t sec); > > That gave me errors compiling the "callee" portion: > > /usr/local/include/dbus-cxx-0.1/dbus-cxx/method.h: In member function > DBus::HandlerResult DBus::Method<T_return, T_arg1, sigc::nil, sigc::nil, > sigc::nil, sigc::nil, sigc::nil, > sigc::nil>::handle_call_message(std::shared_ptr<DBus::Connection>, > std::shared_ptr<const DBus::CallMessage>) [with T_return = char, T_arg1 = > long int]: > > /usr/local/include/dbus-cxx-0.1/dbus-cxx/method.h:176: error: ambiguous > overload for operator>> in i >> _val_1 > /usr/local/include/dbus-cxx-0.1/dbus-cxx/method.h:176: note: candidates > are: operator>>(int32_t, long int) <built-in> > /usr/local/include/dbus-cxx-0.1/dbus-cxx/method.h:176: note: > operator>>(uint32_t, long int) <built-in> > /usr/local/include/dbus-cxx-0.1/dbus-cxx/method.h:176: note: > operator>>(uint64_t, long int) <built-in> > /usr/local/include/dbus-cxx-0.1/dbus-cxx/method.h:176: note: > operator>>(int64_t, long int) <built-in> > > I got around that problem by replacing "time_t" with an unsigned int, so > that's not that big a deal, though I'd like to know if that can be fixed. > I then hit a snag in the "caller" portion, > > /usr/local/include/dbus-cxx-0.1/dbus-cxx/message.h: In function > DBus::MessageIterator DBus::operator>>(std::shared_ptr<const > DBus::Message>, T&) [with T = signed char]: > /usr/local/include/dbus-cxx-0.1/dbus-cxx/methodproxy.h:109: instantiated > from T_return DBus::MethodProxy<T_return, T_arg1, sigc::nil, sigc::nil, > sigc::nil, sigc::nil, sigc::nil, sigc::nil>::operator()(T_arg1) [with > T_return = signed char, T_arg1 = unsigned int] > > /usr/local/include/dbus-cxx-0.1/dbus-cxx/message.h:182: error: no matching > function for call to DBus::Message::operator>>(signed char&) const > > which then lists a bunch of operator>> with bool, uint8_t, > int16_t,uint16_t,int32_t,uint32_t,int64_t,uint64_t,double, const char*, > and std::string. It looks like int8_t is missing from that list. > > Anyway, I wasn't sure if this was a bug or something related to allowable > DBus types, so I figured I'd ask. I can work around it by passing > something larger than a char, obviously, but it seems strange for int8_t > to be the only one that's missing. > Largely, it's related to the dbus types. DBus doesn't have a direct type for char or int8_t but there is a BYTE type. I added support for both since they are fundamental C types. I also added support for floats. The problem with the long int was due to the fact that nothing in the DBus types maps directly to it. On i386 int32_t maps to to int and int64_t maps to long long skipping long. I added support for long ints on 32-bit architectures only (since they're already supported as int64_t on x86_64). I also added an example that demonstrates how to overload the << and >> operators for MessageIterator and MessageAppendIterator to support additional types. In this example a timeval (with microsecond resolution) is overloaded. --- Rick |
|
From: SourceForge.net <no...@so...> - 2009-06-08 22:06:31
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7433044 By: rvinyard This release adds support for char, int8_t and float types as well as long int and unsigned long int on 32-bit architectures. There is also a new example demonstrating how to extend Message::iterator and Message::append_iterator with operators << and >> to support new types. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=943815 |
|
From: Patrick A. <pa...@ph...> - 2009-06-05 18:47:21
|
Hi: I've just started using dbus-cxx, and I'm having a bit of difficulty. I'm trying to replicate the "callee_object"/"caller_object" example: in my case, the class method looks like char saw(time_t sec); That gave me errors compiling the "callee" portion: /usr/local/include/dbus-cxx-0.1/dbus-cxx/method.h: In member function DBus::HandlerResult DBus::Method<T_return, T_arg1, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>::handle_call_message(std::shared_ptr<DBus::Connection>, std::shared_ptr<const DBus::CallMessage>) [with T_return = char, T_arg1 = long int]: /usr/local/include/dbus-cxx-0.1/dbus-cxx/method.h:176: error: ambiguous overload for operator>> in i >> _val_1 /usr/local/include/dbus-cxx-0.1/dbus-cxx/method.h:176: note: candidates are: operator>>(int32_t, long int) <built-in> /usr/local/include/dbus-cxx-0.1/dbus-cxx/method.h:176: note: operator>>(uint32_t, long int) <built-in> /usr/local/include/dbus-cxx-0.1/dbus-cxx/method.h:176: note: operator>>(uint64_t, long int) <built-in> /usr/local/include/dbus-cxx-0.1/dbus-cxx/method.h:176: note: operator>>(int64_t, long int) <built-in> I got around that problem by replacing "time_t" with an unsigned int, so that's not that big a deal, though I'd like to know if that can be fixed. I then hit a snag in the "caller" portion, /usr/local/include/dbus-cxx-0.1/dbus-cxx/message.h: In function DBus::MessageIterator DBus::operator>>(std::shared_ptr<const DBus::Message>, T&) [with T = signed char]: /usr/local/include/dbus-cxx-0.1/dbus-cxx/methodproxy.h:109: instantiated from T_return DBus::MethodProxy<T_return, T_arg1, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>::operator()(T_arg1) [with T_return = signed char, T_arg1 = unsigned int] /usr/local/include/dbus-cxx-0.1/dbus-cxx/message.h:182: error: no matching function for call to DBus::Message::operator>>(signed char&) const which then lists a bunch of operator>> with bool, uint8_t, int16_t,uint16_t,int32_t,uint32_t,int64_t,uint64_t,double, const char*, and std::string. It looks like int8_t is missing from that list. Anyway, I wasn't sure if this was a bug or something related to allowable DBus types, so I figured I'd ask. I can work around it by passing something larger than a char, obviously, but it seems strange for int8_t to be the only one that's missing. Thanks! Patrick |
|
From: SourceForge.net <no...@so...> - 2009-06-04 21:49:34
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7427535 By: rvinyard This release introduces several new changes to both the main library as well as the dbus-cxx-xml2cpp proxy/adapter generator. The changes to the main library include a new class DBus::Path to encapsulate and validate dbus paths. Also new in the main library is support for introspection, including the DBus introspection interface now supported by DBus::Object. Also new is support for child nodes in DBus::Object. Changes to dbus-cxx-xml2cpp include support for both inheritance and containment with examples of both in the has-a and is-a xml2cpp examples. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=943815 |
|
From: SourceForge.net <no...@so...> - 2009-05-28 23:01:36
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7415337 By: rvinyard This release fixes a few minor bugs. The generator now uses the ::DBus:: namespace rather than DBus:: to allow the use of the namespace DBus in other nested hierarchies without ambiguity. The m4 generated files have also been cleaned up to eliminate several no-op compiler warnings. The documentation has been updated to reflect the fact that dbus-cxx is now available in Fedora directly and also includes a short synopsis on dbus-cxx-xml2cpp. Finally, an autoconf macro has been added (ax_dbus_cxx_xml2cpp.m4) to streamline using dbus-cxx-xml2cpp in downstream projects. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=943815 |
|
From: SourceForge.net <no...@so...> - 2009-05-14 19:02:33
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7392278 By: rvinyard This release cleans up a bit of the build system (the first release had trouble on Ubuntu i386) and fixes a bug on Fedora 12 (rawhide) related to a change in the C library strstr(). The rpm package also now contains a separate doc subpackage. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=943815 |
1 message has been excluded from this view by a project administrator.
