Bug 24451 - Add ability to position/size the MDI window on first start
Add ability to position/size the MDI window on first start
Status: VERIFIED FIXED
Product: platform
Classification: Unclassified
Component: Window System
3.x
PC Windows ME/2000
: P2 (vote)
: 3.x
Assigned To: mslama
issues@platform
: UI
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-06-05 16:00 UTC by iformanek
Modified: 2008-12-23 09:24 UTC (History)
4 users (show)

See Also:
Issue Type: TASK
:


Attachments
Patch (34.21 KB, application/octet-stream)
2002-06-07 11:46 UTC, mslama
Details
Example of window manager xml (466 bytes, text/plain)
2002-06-07 11:47 UTC, mslama
Details

Note You need to log in before you can comment on or make changes to this bug.
Description iformanek 2002-06-05 16:00:00 UTC
According to what will be possible here are several 
options what we would like in priority order (most 
desirable first):

1. allow to open the window centered, plus specify size 
proportionally to the screen size (e.g. 90% width, 85% 
height). If below certain minimums (e.g. on 800x600), open 
maximized

2. allow to open the window centered, plus specify size 
proportionally to the screen size (e.g. 90% width, 85% 
height). 

3. allow to open the window centered, plus specify fixed 
size.  If below certain minimums (e.g. on 800x600), open 
maximized

4. allow to open the window centered, plus specify fixed 
size.

5 (not desirable, current state) specify fixed position 
and size and use it on all resolutions
Comment 1 iformanek 2002-06-05 16:00:39 UTC
Changing to task as agreed with Marek, adding UI keyword
Comment 2 iformanek 2002-06-05 16:01:08 UTC
Changing to Task as agreed with Marek, adding UI keyword
Comment 3 mslama 2002-06-06 14:57:03 UTC
Centering itself is not difficult. Some questions: Do you want to
support relative AND absolute size for centering?

I would add attributes relative-width and relative-height. Attributes
x and y remain. If any of these two attributes (x or y) will have
value 'center' main screen will be centered on screen.

Do you want threshold value for maximizing to be configurable in XML?
I would add attributes min-width and min-height. If ANY actual value
will be bellow minimum (width or height) window will be maximized.
Comment 4 iformanek 2002-06-06 17:16:27 UTC
> Some questions: Do you want to
> support relative AND absolute size for centering?

This sounds like the right thing to do

> I would add attributes relative-width and 
> relative-height. Attributes x and y remain.
> If any of these two attributes (x or y) will 
> have value 'center' main screen will be 
> centered on screen.

Sounds good.

> Do you want threshold value for maximizing 
> to be configurable in XML?
> I would add attributes min-width and min-height.
> If ANY actual value will be bellow minimum 
> (width or height) window will be maximized.

Sounds good, plus I would add add the check for 
actual screen bounds to prevent displaying the 
window bigger than the screen if absolute 
width/height is used.
Comment 5 David Simonek 2002-06-06 17:52:40 UTC
You might want to check our thoughts on nbdev.

my view:
- special value "center" will be individual for x and y axis, meaning
"center the window in this direction"
(special value can be also any negative number, as Yarda suggested for
width and height maximalization)
- relative-width and height is probably ok, it's consistent with other
winsys xml syntax
- I don't like min-width, min-height - I think they are misused for
maximalization, we shouln't do that, I think they are useless (am I
missing smt?)
- how to represent maximalization - with special value for
relative-width and height, either string "maximum" if "center" is used
for x,y or as each negative value. Maybe strings are better for
readability

Keep in mind that you'll have to document this heavily, don't check
the impl in without documentation, because you're extending the APIs
here, don't forget!!!
Comment 6 iformanek 2002-06-06 18:01:14 UTC
> I don't like min-width, min-height - I think they 
> are misused for maximalization, we shouln't do that,
> I think they are useless (am I missing smt?)

if we claim the width and height to be, say, 90%, on 
800x600 we do *not* want this because the result would be 
too small, on 800x600 the IDE should be maximized, thus 
the min w/h.
Comment 7 David Simonek 2002-06-06 18:39:15 UTC
when designing API, it's desirable to be general - so what you are
saying is that we need different sizes of main window for different
screen resolutions.
IMO this is overkill, too much complexity without much added value.
Only disadvantage I can think of is that welcome screen may look not
as nice as on higher res. However, several days ago you and J.Rojcek
explained me why is non-maximized is better then maximized initially
(people see what they have on desktop) and I found your reasoning
wise. Also remember we're unable to open main win maximized under 1.3.
I don't know, I don't have sharp opinion here, but I'd say relative
dimensions are enough.

In other case, API should communicate what's going on cleanly, so
there should be:
<!ELEMENT main-dimension   EMPTY >
<!ATTLIST main-dimension
    rel-value CDATA #REQUIRED
    maximize-if-below CDATA #IMPLIED
>
for both dimesions.
Comment 8 iformanek 2002-06-06 18:50:50 UTC
I am not sure I understand:
- I am not saying we want different sizes for different 
resolutions, I am saying that we want relative sizes, but 
not go under some minimums
- the problem is not looking bad on big resolutions, but 
looking bad on *small* resolutions
- this is no more about Welcome Screen.

I'll repeat again what is needed:

- The IDE window needs to open centered, not covering the 
whole screen area (this will be addressed by adding the 
ability to center the window, and specify relative 
width&height), unless the screen resolution is under 
certain minimum, in which case the IDE should open 
maximized (this will be addressed by specifying minimum 
window size). 
Comment 9 mslama 2002-06-07 09:47:16 UTC
I do not think it makes any sense to center window just by one
coordinate. Of course it is possible and more general. I will change
it to work this way.

Minimum size as I understand it and implement it works as follows:
Absolute size is computed if necessary or just taken from value (as
relative or absolute value of width/height is given). If any dimension
(width or heght) exceeds given minimum size for given dimension
(minimum width/minimum height allowed) window bounds are not set =>
window is maximized. I hope it is what is needed. Just clear name must
be selected for such optional attribute. maximize-if-bellow is fine
but there are two limits one for width and one for height so I suggest
'maximize-if-width-bellow'.

All this means new DTD version as Dafe said. (Only for reading, old
format will be used for saving.)
Comment 10 iformanek 2002-06-07 10:05:24 UTC
Two more notes:
- if the resulting size would be under the minimums, 
maximize to the minimums, not to the screen size
- the minimum should be a minimum of declared minimum and 
actual screen size (e.g. if I declare minimum width to be 
800 and the screen resolution is 640, the window should be 
opened at 640, not 800)
Comment 11 mslama 2002-06-07 11:46:43 UTC
Created attachment 6150 [details]
Patch
Comment 12 mslama 2002-06-07 11:47:19 UTC
Created attachment 6151 [details]
Example of window manager xml
Comment 13 jrojcek 2002-06-11 14:45:56 UTC
The patch seems to work as requested. Marek, commit the patch, please.
Comment 14 mslama 2002-06-13 15:52:52 UTC
It is integrated to main trunk. (WindowManagerData r.1.31 plus r.1.32)
Comment 15 mslama 2002-06-13 15:55:16 UTC
Also new DTD for windowmanagerdata 1.1 is added - new attributes was
added.
Comment 16 Marian Mirilovic 2004-03-01 08:53:01 UTC
issue doesn't apply to new window system - verified


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo