2010/4/26 Joseph Scheuhammer :
> ...
> The Proposed shiftContentsTo(x,y) DBus Method
> --- --
> I wrote:
>
>> A related, detailed aside: Will made a specific request for a Dbus
>> method that, given a point on the desktop, centres the magnified view on
>> that point. The signature in pseudo C is : void shiftContentsTo (int x,
>> int y); Or, in JSON/Dbus: { name: "shiftContentsTo", inSignature:
>> "ii", outSignature: "" }. There was such a method in GS-mag's Dbus
>> implementation at one point, but I removed it to be in sync with
>> gnome-mag. It would be trivial to put back into gs-mag, but it might be
>> tricky for gnome-mag. Carlos would have a better idea here.
>
> Joanie replied:
>>
>> I think that functionality would be good to have, ideally in both, but
>> if it's only doable in one so be it. Please put it back in GS-mag. If
>> it's tricky or impossible to implement in gnome-mag, gnome-mag could
>> always add a stub method which returns NULL or False.
>>
>
> I vote for it to return True/False.
Okay.
>
> About shiftContentsTo(), Carlos asked:
>>
>> It's possible in gnome-mag. How it must be implemented, the magnified
>> area must center to the x and y values passed?
>
> It's sort of the flip of setRoi(). For setRoi(), Orca passes a rectangle in
> screen coordinates that defines the region on the desktop to magnify, and
> the magnifier places that rectangle in the magnified view.
>
> shiftContentsTo() takes a coordinate that is the centre of the
> region-of-interest. The magnifier shifts the contents in the magnified
> view such that the given point is now centred within it. As a consequence,
> the (left, top, width, height) of the magnified view is the new roi. Note
> that the actual roi is not calculated, it simply follows from the size of
> the magnified view.
Okay, it's was exactly what I want to know.
>
>
> GConf/GSettings and On-the-fly Changes
> --- --- -- ---
> Joanie wrote:
>>
>> but what about "on the fly" changes? For instance, a
>> user might prefer 3x magnification with inversed brightness. These
>> settings would presumably be saved in GConf. Then along comes this web
>> page with fixed, and very tiny white text on a black background. 3x is
>> not enough magnification to read it comfortably and inversing the page's
>> inversed colors makes the content hard to read at any size. If I'm
>> following what you propose above, when this user gives the Orca command
>> to increase the magnification factor and turn off inversed brightness,
>> these functionally-temporary values are going to be changed in GConf
>> becoming the new, stored settings. This is not desirable as it requires
>> either the user or the app to store the original values before making
>> any changes on the fly and then restore them all in the end. I'm all for
>> using GConf, but I **think** that we'll need DBus methods for these sorts
>> of things as well.
>
> Okay... from this I conclude that "on the fly" changes are to be done using
> DBus, whereas persistent changes are done with GConf. As a point of
> reference, GS-mag is already sensitive to some user preferences via GConf --
> magnification factor is one of them. GS-mag is listening for changes in
> these GConf settings. Thus, if any app changes a GConf setting, the
> magnifier will react as appropriate. Concrete example: if the GConf
> setting for magnification factor changes, then the magnifier live-updates
> appropriately. But... GS-mag is also supporting changes to some of these
> preferences via DBus. Again, magnification factor is one of them.
>
> Thus, there are two ways to make GS-mag change: via GConf, and via DBus.
> Given that, and your "on the fly" example, it follows that if Orca wants to
> make a persistent change in magnification factor, it should call upon GConf.
> If Orca wants to make an on-the-fly change to magnification factor, it uses
> the DBus method. Similarly for any other setting. That sounds like there
> is complete duplication between GConf and DBus -- the only difference is
> their intended use: on-the-fly vs. persistent. If this is what follows, I
> can provide both.
>
> Still, an issue is how Orca knows when it's "on-the-fly" vs. persistent?
> But, I guess that's Orca's problem :-).
>
> Aside: for what it's worth, specifically for magnification factor, I think
> one handles "on-the-fly" changes with a quick gesture, like a keystroke, or
> some form of mouse wheel event. If it's that easy for the user to quickly
> change magnification factor -- no dialog required -- then using GConf for it
> is fine since the user can rapidly switch back and forth. Alas, I doubt one
> can do that for all the preferences since (1) one would run out of
> keystrokes, (2) some changes are more complex that just a change in a
> number.
What about this scenario:
The magnifier is the only one responsible to store it's configuration
in GConf. So, wh
