Re: minor UI bug?

Posted by Kenneth Sloan-2 on
URL: http://imagej.273.s1.nabble.com/minor-UI-bug-tp5023271p5023273.html

Thanks for the quick reply.  I like the idea of snapping to a coarse grid.
That should satisfy all but the most picky user.  I’ll round to 60.

Interesting that in some systems the difference between SET and GET is
positive and in others it is negative.  Does ANY implementation of
Component get it right?

On Wed, Apr 29, 2020 at 03:22 Michael Schmid <[hidden email]>
wrote:

> Hi Kenneth,
>
> looks like a java.awt bug.
>
> On Linux with the Unity window manager (the default for Ubuntu 11-16)
> [but not with Gnome, which is shipped with Ubuntu >=17], windows with
> saved locations (including the main ImageJ panel) wander down by the
> height of the title bar (28 pixels).
> On Linux with Unity, this is because getLocation() reports the position
> of the interior (below the title bar), but setLocation() sets the top of
> the title bar.
>
> One workaround could be rounding to a multiple of a number slightly
> larger than twice the increment.
> In your case round to an integer multiple of 44, and it will move a bit,
> but then stay the same. On Linux, one would have to round to at least an
> integer multiple of 57.
> For positions in the interior of the window, this will hardly hurt. It
> would be not so nice if one wants an exact y position, e.g. for windows
> at the very top it will be obvious that the position is not really where
> the user wants it. The same might be true if the user wants to have
> exact relative positions of windows (e.g. I have an action panel that I
> want directly below the main ImageJ panel).
>
> Another workaround might be saving the position only if it differs from
> the previous position by a certain amount (>22 in the Mac case),
> otherwise keeping the previous default. It will be shifted, but not
> wander progressively.
>
>
> Michael
> ________________________________________________________________
>
> On 28.04.20 23:11, Kenneth Sloan wrote:
> > In today's Java plugin, I decided to be extra nice, and ran into a minor
> problem that I don't quite understand.
> >
> > Context: Mac, latest OSX, up-to-date FIJI
> >
> > I have a couple of Dialog boxes which appear repeatedly.  I have them
> placed in a location that makes sense to me, on my machine - but it
> occurred to me that some users might prefer to move them (different
> resolution screens, different preferences as to where the dialogs should
> appear, etc.)
> >
> > So, I tried this:
> >
> >
> > NonBlockingGenericDialog gd;
> > int gdLocationX = defaultX;
> > int gdLocationX = defaultY;
> > while(true)
> > {
> >    gd = new NonBlockingGenericDialog(...);
> >    ...  add fields to gd ...
> >    gd.setLocation(gdLocationX, gdLocationY); // put it where we want it
> >    gd.showDialog();
> >    // find out where it is now
> >    gdLocationX = gd.getLocation().x;  // getLocation returns a Point
> >    gdLocationX = gd.getLocation().y;
> >    ...process results from the dialog...
> > }
> >
> > Which works perfectly, EXCEPT that the  dialog box creeps slowly up the
> screen.  The x-coordinate remains constant, but the y-coordinate gets
> smaller and smaller...until it reaches the top of the screen, where
> (mercifully) it stops.
> >
> > Experimentation reveals that (on my machine, today...) the upward creep
> is 21 (I think that's correct) pixels, which appears to be the height of
> the banner added to the top of the dialog.
> >
> > I "fixed" it with:
> >
> >    gdLocationX = gd.getLocation().y  + 21; // hack alert!
> >
> > but this seems unprincipled.
> >
> > Does anyone know how to determine the size of the banner added to the
> dialog window (I suspect it differs on other platforms)?   This may
> require  java.awt knowledge rather than ImageJ knowledge - the
> getLocation() method is inherited from java.awt.Component.
> >
> > I'm also confused, because there is a (very small) frame surrounding the
> dialog box horizontally,< but the x-coordinate does not change over time -
> it is perfectly stable).
> >
> > Is it reasonable to request a fix to ImageJ to correct for this "drift"?
> >
> > Clearly, I have too much time on my hands, and am woefully ignorant of
> java.awt internals.
> >
> > --
> > Kenneth Sloan
> > [hidden email]
> > Vision is the art of seeing what is invisible to others.
> >
> > --
> > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
--
-Kenneth Sloan

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html