[kepler-dev] _windowsProperty x and y checked against screen size

Christopher Brooks cxh at eecs.berkeley.edu
Wed Jun 7 10:49:28 PDT 2006


Yep, there are a number of issues.

Currently, if the x or y value of the window location is greater than
the screen width or height, we relocate the window 30 pixels into the
visible screen so that just a portion is visible.  This gives the user
the option of dragging it.  I think this is the Apple style.

If the x or y value is less than 0, then the window gets relocated so
that it is all visible. This is sort of the style Matt proposes.  I
tried offsetting the window so that just a little bit of the left edge
of the window was visible, but this caused problems, since the Close
Window Red X box was what was visible.

Currently, when we change the window location, the model is not
marked as dirty, so we are not prompted to save upon closing.

I think there are lots of different policies we could implement here.
My main concern is for new users and then for people with multiple
screens.

Anyway, I'm open to suggestions . . .

_Christopher 

--------

    Relocating an off-screen window so that only part of it shows is the 
    solution that Apple uses on Macs. It lets you know that the window was 
    saved in a certain direction and perhaps should be resaved.
    
    Dan
    
    Matt Jones wrote:
    > I think it's a good idea to move the window.  Once you've determined 
    > the window is offscreen and you're going to move it, moving it so only 
    > 10 pixels show isn't so useful -- why not relocate it to someplace 
    > where the user can see most of the the window, such as the upper left 
    > corner of the display?
    >
    > Matt
    >
    > Christopher Brooks wrote:
    >> Hi Dan,
    >> Good point, we now check for negative values of x and y.  This could
    >> cause problems with dual monitors, but I feel it is less wrong to
    >> move the window than it is to have a window that the user cannot
    >> access at all.
    >>
    >> Let's see how this unfolds.  I'd entertain setting yet another
    >> property that if set would not change the values.
    >> Basically, I'm trying to optimize the experience of the new user who
    >> gets a model that was created on a machine with a large screen or dual
    >> monitors.
    >>
    >> _Christopher
    >>
    >>
    >> --------
    >>
    >>     Christopher,
    >>         I have seen the problem with dual monitors also. But I have 
    >> also     seen the case where the saved window has NEGATIVE locations 
    >> (i.e. when x     or y is too small rather than too large! (probably 
    >> due to dual monitors     with primary set to the right) So you might 
    >> consider tests for that also.
    >>             And maybe you should lobby for you and Edward to get 
    >> bigger monitors     ;-)
    >>     But as can be seen from my comment, that doesn't always help either!
    >>         Dan
    >>         Christopher Brooks wrote:
    >>     > Edward and I have 1024x768 laptops and I've run up against user
    >>     > submitted models that have the _windowsProperty attribute set
    >>     > such that the window is placed off the edge of the screen.      >
    >>     > I think this can also happen when the user has a two headed 
    >> display.
    >>     >
    >>     > The fix is to     > 
    >> ptolemy/actor/gui/WindowPropertiesAttribute.java
    >>     >
    >>     > 175a181,189
    >>     >       >>             // If x or y is greater than the width or 
    >> height of the
    >>     >>             // screen, then offset them by 30 pixels so the 
    >> user can
    >>     >>             // drag the window.
    >>     >>             Toolkit tk = Toolkit.getDefaultToolkit();
    >>     >>             x = (x > tk.getScreenSize().width
    >>     >>                     ? tk.getScreenSize().width - 30 : x);
    >>     >>             y = (y > tk.getScreenSize().height
    >>     >>                     ? tk.getScreenSize().height - 30 : y);
    >>     >>
    >>     >>         >
    >>     > I'm not sure if this should go into the release branch or not.
    >>     >
    >>     > Technically, it is a bug, because it is easy to have a model 
    >> that will
    >>     > not appear on the user's screen if the user has a small screen.
    >>     >
    >>     > _Christopher
    >>     > _______________________________________________
    >>     > Kepler-dev mailing list
    >>     > Kepler-dev at ecoinformatics.org
    >>     > 
    >> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
    >>     >
    >>     >               --     
    >> *******************************************************************
    >>     Dan Higgins                                  higgins at nceas.ucsb.edu
    >>     http://www.nceas.ucsb.edu/    Ph: 805-893-5127
    >>     National Center for Ecological Analysis and Synthesis (NCEAS) 
    >> Marine Scienc
    >>    e Building - Room 3405
    >>     Santa Barbara, CA 93195
    >>     *******************************************************************
    >>     --------
    >> _______________________________________________
    >> Kepler-dev mailing list
    >> Kepler-dev at ecoinformatics.org
    >> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
    >>
    >
    
    
    -- 
    *******************************************************************
    Dan Higgins                                  higgins at nceas.ucsb.edu
    http://www.nceas.ucsb.edu/    Ph: 805-893-5127
    National Center for Ecological Analysis and Synthesis (NCEAS) Marine Scienc
   e Building - Room 3405
    Santa Barbara, CA 93195
    *******************************************************************
    
--------


More information about the Kepler-dev mailing list