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 318132 - Gnopernicus - Magnifier not taking up full screen
Gnopernicus - Magnifier not taking up full screen
Status: RESOLVED FIXED
Product: gnopernicus
Classification: Deprecated
Component: magnifier
unspecified
Other Solaris
: Normal normal
: ---
Assigned To: remus draica
Adi Dascal
AP2
Depends on:
Blocks:
 
 
Reported: 2005-10-06 17:31 UTC by Patrick Wade
Modified: 2006-04-10 16:02 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch (7.03 KB, patch)
2006-02-28 15:50 UTC, remus draica
committed Details | Review

Description Patrick Wade 2005-10-06 17:31:21 UTC
Distribution/Version: S10U1 sparc

On a dual-head solaris sparc system:

(Set one screen's resolution to a particular resolution, and set the second
screen's resolution to a different resolution)

- Start gnopernicus with magnifier (dual-head full-screen).
Magnified screen does not take up the whole screen.

:0.0 has a real res of 1280x1024 and :0.1 has a real res of 1152x900.
Running full-screen magnifier *standalone* (i.e. outside of gnopernicus) works
correctly with these assymetrical screen resolutions, in BOTH directions.

Running standalone with -s :0.0 -t :0.1, the magnifier tells us "initial
viewport 1280 1024". Running standalone -s :0.1 -t :0.0, mag tells us "initial
viewport 1152 900". Which makes sense.

So, it appears that the problem is only seen when running mag through
Gnopernicus. With the example resolutions given above, a user loses 21% of the
potential zoomer size because of this problem (i.e. 1152x900 when it could fully
be 1280x1024).

Mag should intelligently handle differing physical resolutions for source and
target when run through Gnopernicus. Currently, it does not.
Comment 1 Patrick Wade 2005-10-06 17:32:36 UTC
Tracked in Sun's internal tracking system as bug# 6331830
Comment 2 bill.haneman 2005-11-01 15:36:09 UTC
downgraded to 'normal' severity, as the more common user scenarios involve a
target resolution which is _smaller than_, or equal to, the source.
Comment 3 Dragan Sarbut 2005-11-04 11:49:32 UTC
When gnopernicus is running on display :0.0 the screen size that gnopernicus is
using will be the screen size of the :0.0 display which in this case is
1280/1024. The same happens when gnopernicus runs on display :0.1... the
screen-size will be 1152/900.

A workaround for this would be to run gnopernicus on display :0.0. This way the
user would get the whole screen but he/she will not see the GUI since it's
covered by the magnifier. 

I think that a complete fix for this is not very easy to do and it would require
a lot of code rewritten in gnopernicus.
Comment 4 bill.haneman 2005-11-04 11:52:43 UTC
I don't understand why this is hard to fix, it appears to require only that
gnopernicus use the 'target display' bounds as the limits for the magnifier's
target zoom region, instead of the 'source display' bounds as it does now.
Comment 5 remus draica 2006-02-28 15:50:08 UTC
Created attachment 60324 [details] [review]
proposed patch
Comment 6 remus draica 2006-04-06 10:24:21 UTC
Comment on attachment 60324 [details] [review]
proposed patch

patch applied on cvs head.
Comment 7 remus draica 2006-04-10 16:02:56 UTC
Comment on attachment 60324 [details] [review]
proposed patch

patch applied on gnome-2-14 branch.