This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Add ability to position/size the MDI window on first start | ||
---|---|---|---|
Product: | platform | Reporter: | iformanek <iformanek> |
Component: | Window System | Assignee: | mslama <mslama> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | dsimonek, jrojcek, jtulach, ttran |
Priority: | P2 | Keywords: | UI |
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Windows ME/2000 | ||
Issue Type: | TASK | Exception Reporter: | |
Attachments: |
Patch
Example of window manager xml |
Description
iformanek
2002-06-05 16:00:00 UTC
Changing to task as agreed with Marek, adding UI keyword Changing to Task as agreed with Marek, adding UI keyword 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. > 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. 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!!! > 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.
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. 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). 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.) 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) Created attachment 6150 [details]
Patch
Created attachment 6151 [details]
Example of window manager xml
The patch seems to work as requested. Marek, commit the patch, please. It is integrated to main trunk. (WindowManagerData r.1.31 plus r.1.32) Also new DTD for windowmanagerdata 1.1 is added - new attributes was added. issue doesn't apply to new window system - verified |