After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 168761 - make magnification source/target and size parameters non-instant-apply
make magnification source/target and size parameters non-instant-apply
Status: RESOLVED FIXED
Product: gnopernicus
Classification: Deprecated
Component: magnifier
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Dragan Sarbut
Dragan Sarbut
AP2
Depends on:
Blocks:
 
 
Reported: 2005-02-28 14:28 UTC by John Crawley
Modified: 2005-04-11 12:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch for non instant apply changes (16.29 KB, patch)
2005-03-22 11:43 UTC, Alexandra Telescu
accepted-commit_after_freeze Details | Review
it seems that it was a problem with the last patch (16.42 KB, patch)
2005-03-22 14:05 UTC, Alexandra Telescu
none Details | Review
updated patch (18.85 KB, patch)
2005-04-07 09:19 UTC, Dragan Sarbut
none Details | Review

Description John Crawley 2005-02-28 14:28:32 UTC
Distribution/Version: JDS Rel3 B29

Using gnopernicus 0.10

The default for magnification is split screen, with the source and target
both set to 0.0 and the 'left' boundry value at half way across the screen
(around the 600 mark for me).

To implement full screen magnification the user must set the Source textfield
vale to 0.1 and set the 'left' value to 0.

The problem lies in the fact that the magnification Source value is updated
when the user presses 'Apply' or 'OK', whereas the 'left' value updates almost
immediately.

 This means that if the user changes the Source and then the 'left'
value, the whole screen will be taken up by the magnifier before the user has
a chance to press "Apply" or "OK". Since the Source and Target are still set to
the same value,(and there is no more Source to magnify) this is just a grey screen. 

Gnopernicus shouldn't let the user change the 'left' value past a certain
distance if the Source and Target values are the same.
Comment 1 Dragan Sarbut 2005-03-01 07:20:00 UTC
The workarround for this is to changes the source/target then press apply, and
then change the "left" zoomer placement.

Changing the left value implies that the user knows what he/she is doing.

I think that this is not a bug.
Also this is related to bug #159334.
Comment 2 John Crawley 2005-03-01 09:40:02 UTC
I think this is a bug. It can not always be assumed that the user knows what
he/she is doing. Anyway, the system should not punish a user for a mistake made.
Once the 'left' value is set to 0 in split-screen magnification, the only thing
a user can do is to login through a virtual terminal and kill the magnifier process.
Comment 3 bill.haneman 2005-03-01 12:23:06 UTC
John:  I agree with Dragan that this is not a bug, it is a user error.
It is also possible to reset the magnification value via gconftool-2.  At most,
this is an RFE for a gnopernicus setup script to turn fullscreen magnification
on/off and change settings (since magnification settings are among the most
difficult to configure initially).
Comment 4 korn 2005-03-07 17:17:12 UTC
We should consider making all of this dialog NON-instant apply.  Another
suggestion: if you change the source/target displays, Gnopernicus could see this
and move the dialog to the correct (visible) display.
Comment 5 Alexandra Telescu 2005-03-22 11:43:26 UTC
Created attachment 39064 [details] [review]
proposed patch for non instant apply changes

This patch makes the changes to the dialog's objects non instant apply.
Comment 6 bill.haneman 2005-03-22 12:57:46 UTC
Comment on attachment 39064 [details] [review]
proposed patch for non instant apply changes

Looks OK to me, but please test each option before committing. 
If we branch anytime soon, we should probably commit this to HEAD and not 2.10,
since it's a significant UI change.
Comment 7 Alexandra Telescu 2005-03-22 14:05:27 UTC
Created attachment 39070 [details] [review]
it seems that it was a problem with the last patch
Comment 8 Dragan Sarbut 2005-04-07 09:19:41 UTC
Created attachment 39792 [details] [review]
updated patch

No big changes on this one. The names of some functions were changed to be more
explicit and a small fix on the magui_set_zoomfactor_lock_on_off funtion.
Comment 9 Dragan Sarbut 2005-04-07 10:01:11 UTC
Patch commited to CVS HEAD,..closing bug.
Comment 10 bill.haneman 2005-04-07 10:51:28 UTC
I think we should reopen this bug, since the 'non instant apply' change is only
part of the suggested solution.  Maybe we should split this into two bugs?
Comment 11 korn 2005-04-07 19:38:37 UTC
I think two bugs makes more sense than keeping this one open.
Comment 12 bill.haneman 2005-04-07 23:06:56 UTC
The original plan and request from RE was for a script to do this.  We agreed to
provide one, but one has not been forthcoming.
Comment 13 Dragan Sarbut 2005-04-08 05:58:58 UTC
Bill, i thought that the final decision from our meeting(s) was to make this
dialog not instant apply and add a note in the README file, although I remember
discussing a script.

What should that script do? Just reset the magnifier settings to default if the
user looses visibility of the widgets?
Comment 14 bill.haneman 2005-04-08 11:16:12 UTC
One idea was to have a 'restore defaults' script, but I personally don't think
that solves the main problem in this bug.  Another idea, which I much prefer, is
to have a simple command-line interface (probably implemented via a simple
script) for making major changes to magnifier source/target parameters.  To some
extent this can be done by executing srcore with the right parameters, but the
interface is quite complex, I think it is better for the user to have a simple
command such as:

gnopernicus-mag-config --fullscreen --source=:0.1 --target=:0.0

or

gnopernicus-mag-config --splitscreen [--source ]

I don't know whether there are other parts of the configuration that are
difficult to do via the GUI; personally my opinion is that the source/target and
fullscreen/splitscreen parameters are the only ones likely to ruin the user's day.
Comment 15 Dragan Sarbut 2005-04-11 12:07:18 UTC
Bug 300178 was opened to handle the last item.
Closing this bug