minor UI bug?

[Kenneth Sloan-2]

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

[Michael Schmid]

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-2]

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

[Kenneth Sloan-2]

Here’s a solution that works for me.

Most of my Java plugins have a “splash screen” announcing the name of the plugin, the version, etc.  This has been displayed with showMessage(). There is little reason for the user to do anything other than click “OK”.

So…instead of showMessage(message), I now use:

        // announce version
        String message = ...
        String title = ...
        Point dialogLocation = new Point(dialogLocationX,
                                         dialogLocationY);
        Point dialogDrift = measureDialogDrift(programName,
                                               message,
                                               dialogLocation);


And

    private Point measureDialogDrift(String title,
                                     String message,
                                     Point location)
    {
        int setX = location.x;
        int setY = location.y;
        int getX;
        int getY;
        NonBlockingGenericDialog gd
             = new NonBlockingGenericDialog(title);
        gd.addMessage(message);
        gd.setLocation(setX, setY);
        gd.showDialog();
        getX = gd.getLocation().x;
        getY = gd.getLocation().y;
        Point result = new Point(getX-setX, getY-setY);
        return result;
    }


In my development environment (MacBook Pro), measureDialogDrift reliably returns (0, -21).

Heaven help the user who moves the splash screen before clicking on “OK”!

I had a dream that this would work without the showDialog(), but (of course?) that doesn’t work.  The displayed location of the dialog depends on the screen boundaries.  It would be *nice* if this were fixed at either the java.awt level or the ImageJ level, but I won’t hold my breath.  Perhaps someone with a deep understanding of java.awt can suggest a method that does not require run-time experimentation, and works on all platforms.

Ah…it occurs to me that the reason there is no drift in X is that the size of the borders on the left and right is fixed, while the height of the banner at the top may depend on the font used.

On to more important issues...

--
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