[g-a-devel]gnome-mag IDL



Hi:

In response to some requests from the BAUM team regarding gnopernicus
magnification needs, we are drafting some new/revised IDL for gnome-mag.

One thing that is desired is the ability to do things such as specify
smoothing algorithms, possibly on a per-region basis, and specify
contrast/inversion, also possibly on a per-region basis.

We also need to be able to specify magnification factors for the 'mouse
cursor' (or 'pointer') independent of the "magnifiaction factor" of the
zoom regions.  Likewise we may wish to choose between various mouse
cursor types or sets (for instance, a crosshair cursor on the magnifier,
or a specific set of cursor shapes mapped onto the X cursor-numbers). 
Here again, the specific mapping of values onto cursors (other than some
standards such as "crosshair") may not be practical to specify in IDL
since new magnifiers may offer new cursor sets and/or capabilities.

Since it's quite possible that various magnifier implementations which
wish to conform to "gnome-mag" IDL may have different, even
as-yet-not-thought-of smoothing algorithms, making the smoothing setting
an enum or other known set of values doesn't seem appropriate.

So this seems to suggest use of a generic API for properties, for
instance Bonobo::PropertyBag, with keys such as "contrast", "icon-set",
"cursor-set".

In order to do this on a per-zoomer basis, however, we would need to
expose the PropertyBag API on individual zoomer objects.  This may make
good sense anyhow, but it means an (incompatible) API change; the
methods currently exposed on the Magnifier service instance that take an
integer 'zoom region number' would instead be exposed on a ZoomRegion
object.  Thus, for instance:

public interface Magnifier:

	boolean createZoomRegion ()

	ZoomRegion Magnifier:getZoomRegion ()

	public interface ZoomRegion : Bonobo::PropertyBag

		setMagFactor ()

etc. which would also provide, via PropertyBag

		setValue ("contrast", some-contrast-value-as-CORBA-any)

etc.

-----

We would prefer, I suppose, not to have to call the Bonobo::PropertyBag
API via a getInterface() call on the ZoomRegion (for both convenience
anc code clarity).  However, making ZoomRegion derive from PropertyBag
directly seems a little unusual; 

Michael, what is your suggestion here?

suggestions welcome; I'll post complete draft IDL a little later today,
perhaps some discussion will have taken place by then which I can
incorporate, so don't worry if the IDL methods you need are not listed
above.  The above discussion is just regarding structure, not specifics.

thanks and best regards,

Bill




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