12:06 a.m.
Hi,
it would be great of the D-Bus interface XML files would be installed into
/usr/share/dbus-1/interfaces (or to whatever directory that is configured).
The KDE frontend is using them to generate Qt classes directly from the
interface definition rather than by tinkering with the glib-centric syncevo-
dbus-* headers. Currently we simply copy those XML files from the Git source.
--
Sascha Peilicke
http://saschpe.wordpress.com
12:15 a.m.
On Friday 04 June 2010 16:06:53 Sascha Peilicke wrote:
Hi,
it would be great of the D-Bus interface XML files would be installed into
/usr/share/dbus-1/interfaces (or to whatever directory that is configured).
The KDE frontend is using them to generate Qt classes directly from the
interface definition rather than by tinkering with the glib-centric
syncevo- dbus-* headers. Currently we simply copy those XML files from the
Git source.
Preferably in that form:
/usr/share/dbus-1/interfaces/org.syncevolution.Server.xml
/usr/share/dbus-1/interfaces/org.syncevolution.Session.xml
/usr/share/dbus-1/interfaces/org.syncevolution.Connection.xml
--
Sascha Peilicke
http://saschpe.wordpress.com
12:41 a.m.
On Fri, 2010-06-04 at 15:15 +0100, Sascha Peilicke wrote:
On Friday 04 June 2010 16:06:53 Sascha Peilicke wrote:
> Hi,
>
> it would be great of the D-Bus interface XML files would be installed into
> /usr/share/dbus-1/interfaces (or to whatever directory that is configured).
> The KDE frontend is using them to generate Qt classes directly from the
> interface definition rather than by tinkering with the glib-centric
> syncevo- dbus-* headers.
That's indeed the approach that I would suggest.
> Currently we simply copy those XML files from the
> Git source.
Preferably in that form:
/usr/share/dbus-1/interfaces/org.syncevolution.Server.xml
/usr/share/dbus-1/interfaces/org.syncevolution.Session.xml
/usr/share/dbus-1/interfaces/org.syncevolution.Connection.xml
That belongs into a development package, right? I don't want to disrupt
the work already done on packaging 1.0, so I'll put this change into a
1.0.1 update.
As far as I know, Qt D-Bus needs annotations to define the corresponding
local types. How do you intend to add them to the installed files?
FYI, I have asked whether we can get at least that part of the work
which was already done for a Qt app published quickly.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
1:30 a.m.
On Friday 04 June 2010 16:41:29 you wrote:
On Fri, 2010-06-04 at 15:15 +0100, Sascha Peilicke wrote:
> On Friday 04 June 2010 16:06:53 Sascha Peilicke wrote:
> > Hi,
> >
> > it would be great of the D-Bus interface XML files would be installed
> > into /usr/share/dbus-1/interfaces (or to whatever directory that is
> > configured). The KDE frontend is using them to generate Qt classes
> > directly from the interface definition rather than by tinkering with
> > the glib-centric syncevo- dbus-* headers.
That's indeed the approach that I would suggest.
> > Currently we simply copy those XML files from the
> > Git source.
>
> Preferably in that form:
>
> /usr/share/dbus-1/interfaces/org.syncevolution.Server.xml
> /usr/share/dbus-1/interfaces/org.syncevolution.Session.xml
> /usr/share/dbus-1/interfaces/org.syncevolution.Connection.xml
That belongs into a development package, right? I don't want to disrupt
the work already done on packaging 1.0, so I'll put this change into a
1.0.1 update.
I'm fine with that, thanks.
As far as I know, Qt D-Bus needs annotations to define the
corresponding
local types. How do you intend to add them to the installed files?
Uhm, currently I
added those locally. I agree, we'd have to parse those XML
files and add corresponding annotations. Maybe someone already wrote a tool
for that. As an alternative, we could simply add those annotations to the
provided files as they shouldn't hurt.
FYI, I have asked whether we can get at least that part of the work
which was already done for a Qt app published quickly.
That would be awesome and
for sure save some work for Ravi.
--
Sascha Peilicke
http://saschpe.wordpress.com
2:31 a.m.
> As far as I know, Qt D-Bus needs annotations to define the
corresponding
> local types. How do you intend to add them to the installed files?
Uhm, currently I added those locally. I agree, we'd have to parse those XML
files and add corresponding annotations. Maybe someone already wrote a tool
for that. As an alternative, we could simply add those annotations to the
provided files as they shouldn't hurt.
Seems like dbus-binding-tool doesn't allow annotations in XML files altough
they're in the DTD. So I'm attaching my (resulting) files for reference as
well as the patch for the original files (won't work though).
Also I had to change the parameter name 'template' of the GetConfig() and
GetConfigs() methods of the session and server definition as this is a keyword
in C++ and won't compile. I simply changed it to 'templates' (patch
attached).
--
Sascha Peilicke
http://saschpe.wordpress.com
4:20 p.m.
On 06/04/2010 07:31 PM, Sascha Peilicke wrote:
>> As far as I know, Qt D-Bus needs annotations to define the
corresponding
>> local types. How do you intend to add them to the installed files?
>
> Uhm, currently I added those locally. I agree, we'd have to parse those XML
> files and add corresponding annotations. Maybe someone already wrote a tool
> for that. As an alternative, we could simply add those annotations to the
> provided files as they shouldn't hurt.
Seems like dbus-binding-tool doesn't allow annotations in XML files altough
they're in the DTD. So I'm attaching my (resulting) files for reference as
well as the patch for the original files (won't work though).
These annotations should be in the source xml in my opinion.
There is already a script that strips docs -- it could also strip
annotations if needed (and if the qt parser can read the *-full.xml
versions). Fixing dbus-binding-tool is another option.
Jussi
1:17 a.m.
On Fri, 2010-06-04 at 17:31 +0100, Sascha Peilicke wrote:
> > As far as I know, Qt D-Bus needs annotations to define the
corresponding
> > local types. How do you intend to add them to the installed files?
>
> Uhm, currently I added those locally. I agree, we'd have to parse those XML
> files and add corresponding annotations. Maybe someone already wrote a tool
> for that. As an alternative, we could simply add those annotations to the
> provided files as they shouldn't hurt.
Seems like dbus-binding-tool doesn't allow annotations in XML files altough
they're in the DTD. So I'm attaching my (resulting) files for reference as
well as the patch for the original files (won't work though).
I've fixed this by filtering out these elements in the files that
dbus-binding-tool is invoked on. See the new qt-binding branch in the
SyncEvolution repo.
These are the annotations as they were made by Carl Wong, not the ones
that you added - sorry for the duplication of effort. Please let's use
the ones from Carl because there is more code (not public yet) which
depends on them. He also added some annotations which were not possible
out-of-the-box without defining some custom types for them.
On the other hand, some new methods and signals were not annotated yet
by Carl. Further patches for those are welcome.
Also I had to change the parameter name 'template' of the
GetConfig() and
GetConfigs() methods of the session and server definition as this is a keyword
in C++ and won't compile. I simply changed it to 'templates' (patch
attached).
That's also in Carl's patch, except that he renamed it to "tmplate".
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
2:51 a.m.
On Tuesday 08 June 2010 17:17:42 you wrote:
On Fri, 2010-06-04 at 17:31 +0100, Sascha Peilicke wrote:
> > > As far as I know, Qt D-Bus needs annotations to define the
> > > corresponding local types. How do you intend to add them to the
> > > installed files?
> >
> > Uhm, currently I added those locally. I agree, we'd have to parse those
> > XML files and add corresponding annotations. Maybe someone already
> > wrote a tool for that. As an alternative, we could simply add those
> > annotations to the provided files as they shouldn't hurt.
>
> Seems like dbus-binding-tool doesn't allow annotations in XML files
> altough they're in the DTD. So I'm attaching my (resulting) files for
> reference as well as the patch for the original files (won't work
> though).
I've fixed this by filtering out these elements in the files that
dbus-binding-tool is invoked on. See the new qt-binding branch in the
SyncEvolution repo.
Great, thanks.
These are the annotations as they were made by Carl Wong, not the
ones
that you added - sorry for the duplication of effort. Please let's use
the ones from Carl because there is more code (not public yet) which
depends on them. He also added some annotations which were not possible
out-of-the-box without defining some custom types for them.
Sounds good, I'll
have a look at it.
On the other hand, some new methods and signals were not annotated
yet
by Carl. Further patches for those are welcome.
> Also I had to change the parameter name 'template' of the GetConfig() and
> GetConfigs() methods of the session and server definition as this is a
> keyword in C++ and won't compile. I simply changed it to 'templates'
> (patch attached).
That's also in Carl's patch, except that he renamed it to "tmplate".
This maybe nit-picky but 'templates' maybe more appropriate, as the intend
is
to return a list of strings.
--
Sascha Peilicke
http://saschpe.wordpress.com
3:14 a.m.
On Tue, 2010-06-08 at 17:51 +0100, Sascha Peilicke wrote:
On Tuesday 08 June 2010 17:17:42 you wrote:
> On Fri, 2010-06-04 at 17:31 +0100, Sascha Peilicke wrote:
> On the other hand, some new methods and signals were not annotated yet
> by Carl. Further patches for those are welcome.
>
> > Also I had to change the parameter name 'template' of the GetConfig()
and
> > GetConfigs() methods of the session and server definition as this is a
> > keyword in C++ and won't compile. I simply changed it to
'templates'
> > (patch attached).
>
> That's also in Carl's patch, except that he renamed it to
"tmplate".
This maybe nit-picky but 'templates' maybe more appropriate, as the intend is
to return a list of strings.
But it only returns one config or template, never more than one. So I
still think singular "tmplate" is appropriate.
About installing the .xml files in /usr/share/dbus-1/interfaces, does
that still make sense? For example, which files should get installed -
with or without <annotation>, or both under different names? What about
<doc:*>?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
7:54 a.m.
About installing the .xml files in /usr/share/dbus-1/interfaces,
does
that still make sense? For example, which files should get installed -
with or without <annotation>, or both under different names? What about
<doc:*>?
Interface descriptions placed there seem to have <annotation>
but not <doc:*>.
IMHO these are intended to be read only by code. Doc stuff should go
elsewhere.
--
Sascha Peilicke
http://saschpe.wordpress.com
8:38 p.m.
On Tue, 2010-06-08 at 22:54 +0100, Sascha Peilicke wrote:
> About installing the .xml files in /usr/share/dbus-1/interfaces,
does
> that still make sense? For example, which files should get installed -
> with or without <annotation>, or both under different names? What about
> <doc:*>?
Interface descriptions placed there seem to have <annotation> but not
<doc:*>.
IMHO these are intended to be read only by code. Doc stuff should go
elsewhere.
Okay, patch committed to qt-binding branch on gitorious.org.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
4484
days inactive
4489
days old
syncevolution@synevolution.org
10 comments
3 participants
participants (3)
-
Jussi Kukkonen -
Patrick Ohly -
Sascha Peilicke