Re: Comparing gs-mag dbus with g-mag dbus



Hi Joseph, and thanks for this work!


On Thu, Aug 5, 2010 at 9:25 PM, Joseph Scheuhammer <clown idi gmail com> wrote:

> There was talk of using properties, but I'm not sure where g-mag does that.  Can someone > comment?

Yes, all Setters and Getters methods have been changed to dbus
properties, see API definition below.

> [2a]
> http://git.gnome.org/browse/gnome-mag/tree/xml/org.gnome.Magnifier.xml?h=bonobo-less
> [2b]
> http://git.gnome.org/browse/gnome-mag/tree/xml/org.gnome.ZoomRegion.xml?h=bonobo-less

Well, probably those two files are not updated. The real API
definition is stored in the introspection_xml string in magnifier.c
and zoom-region.c:

http://git.gnome.org/browse/gnome-mag/tree/magnifier/magnifier.c?h=bonobo-less&id=9627c9673411ffc389fec0c37c089fd8431c81c8#n1129

http://git.gnome.org/browse/gnome-mag/tree/magnifier/zoom-region.c?h=bonobo-less&id=9627c9673411ffc389fec0c37c089fd8431c81c8#n2962


> Here's the comparison, using JSON notation.  The first part notes the
> differences, and what gs-mag has to do to match g-mag.  The last shows the
> ones that are the same and nothing needs doing.

Some comments below some blocks:


> org.gnome.Magnifier:
> -------------------
>
> setActive():
> - { name: 'setActive', inSignature: 'b', outSignature: '' },
> - Changes to g-mag dbus:
> - *Non-existent in gnome-mag* -- is this a property?

no, gnome-mag implements it as a method, however it is void (the
magnifier is active when a zoom region is added). We should fix this
in gnome-mag if we really need this method from the application point
of view.


> createZoomRegion():
> - { name: 'createZoomRegion', inSignature: 'ddaiai', outSignature: 'o' },
> - Changes to gs-mag dbus:
> - No change, but the arrays of integer are RectBounds of the form
>  { left, top, right, bottom }, but gs-mag interprets them as
>  { left, top, width, height }.  Hence: need to change gs-mag implementation.
> - See bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=626123
> - Question: why isn't the signature in terms of structures?  Like this:
>  { name: 'createZoomRegion', inSignature: 'dd{iiii}{iiii}', outSignature:
> 'o' },

If we could used named field in structures I would like that solution,
because using something like region.left is much nicer than region[0].


> getZoomRegions():
> - { name: 'getZoomRegions', inSignature: '', outSignature: 'ao' },
> - Changes to gs-mag dbus:
> - *No change, but gnome-mag uses 'as' (array of string) as the return value,
> whereas
>  gs-mag uses 'ao' (array of object paths).*  The latter is "more accurate".

Yeah, we could change this in our side.


> org.gnome.Magnifier.ZoomRegion:
> ------------------------------
> setMagFactor():
> { name: 'setMagFactor', inSignature: 'dd', outSignature: ''},
> Changes to gs-mag dbus:
> { name: 'setMagFactor', inSignature: 'dd', outSignature: 'b'},
>
> Comment:  setMagFactor() now returns true/false.

Also gnome-mag retuns a 'b'


> shiftContentsTo():
> { name: 'shiftContentsTo', inSignature: 'ii', outSignature: 'b' },
> Changes to gs-mag dbus:
> No change, but *needs to be added to gnome-mag*.

What should this function do?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]