Disabling JavaFX minimise/maximise/etc buttons

Hi Jonathan,
I believe this has been neither requested nor discussed so far. I don't
see why this couldn't be added, it just might have to be a conditional
feature, we'll have to check. Feel free to file a feature request.
Regards,
Pavel

Post by Jonathan Giles
Hi all,
For once this is a request for more information from another JavaFX
team, rather than a review request, etc! :-)
I'm keen to see support in JavaFX Stage / Window classes for an API
that would allow for the minimize / maximize / full screen / etc
buttons to be disabled. I'm aware of the StageStyle.UTLITY option
(which does disable the minimize button), but sometimes you don't want
a utility stage style, but you do want to prevent minimizing a stage.
My particular use case is dialogs - you can see a discussion of the
issue at [1].
For example, I note that Stage has an iconfied property to represent
whether the stage is minimized, but no property to specify whether the
stage should be allowed to be iconified (setIconifiable(boolean),
boolean isIconifiable(), for example). Is there a reason for this or
just that this API hasn't been required yet?
In short, I would love API to allow me to specify whether a stage can
be minimised, maximised and made full screen, and for this to follow
through to the buttons available in the native titlebar area of the
stage. Does such an API exist, is there a valid reason why it doesn't,
or should I file a jira to request such API?
[1]
https://bitbucket.org/controlsfx/controlsfx/issue/49/dialogs-should-use-native-title-bars
Thanks!
-- Jonathan

Artem Ananiev

2013-07-22 15:20:10 UTC

Post by Pavel Safrata
Hi Jonathan,
I believe this has been neither requested nor discussed so far. I don't
see why this couldn't be added, it just might have to be a conditional
feature, we'll have to check. Feel free to file a feature request.

Some native platforms (mostly, X window managers) don't provide direct
APIs to enable/disable certain window decoration buttons. A library or
an application may provides some hints, which may or may not be
respected by WM.

I like what we have right now, StageStyle approach. Application defines
the purpose of the window and let the platform decide, what are
available actions for it.

Thanks,

Artem

Post by Pavel Safrata
Regards,
Pavel

Anthony Petrov

2013-07-22 17:17:39 UTC

Hi Artem,

Do you propose to add another StageStyle - namely, a DIALOG? Note that
styles cannot be combined in a mask, meaning that developers won't be
able to create e.g. transparent dialogs, or utility dialogs.

Generally, I like the idea of defining the purpose of a window and
letting the OS/GUI toolkit decide what works best for it, but I'm not
sure if we can apply it for this particular use case. Also, I think that
ability to disable maximization/minimization of a window might be useful
for purposes other than just displaying dialogs.

BTW, isn't the setResizable(false) a good approximation for our
requirements? You can still minimize such a window, but I think this is
reasonable. E.g. OS X will minimize both the dialog and its owner
window, allowing a user to perform other tasks unrelated to the dialog
and windows it blocks. Why do we want to disable minimization?

--
best regards,
Anthony

Some native platforms (mostly, X window managers) don't provide direct
APIs to enable/disable certain window decoration buttons. A library or
an application may provides some hints, which may or may not be
respected by WM.
I like what we have right now, StageStyle approach. Application defines
the purpose of the window and let the platform decide, what are
available actions for it.
Thanks,
Artem

Post by Pavel Safrata
Regards,
Pavel

Artem Ananiev

2013-07-23 10:39:40 UTC

Post by Anthony Petrov
Hi Artem,
Do you propose to add another StageStyle - namely, a DIALOG? Note that
styles cannot be combined in a mask, meaning that developers won't be
able to create e.g. transparent dialogs, or utility dialogs.

There is no need in yet another StageStyle, because we already have
this: Window.initOwner(). If we pass the owner to the platform, and set
appropriate hints for owned/ownerless windows, we should look and behave
similar to native apps.

Post by Anthony Petrov
Generally, I like the idea of defining the purpose of a window and
letting the OS/GUI toolkit decide what works best for it, but I'm not
sure if we can apply it for this particular use case. Also, I think that
ability to disable maximization/minimization of a window might be useful
for purposes other than just displaying dialogs.

To me, making a window non-resizable is a good way to make the window
unmaximizable. Do you see any cases, when a window should be resizable,
but not maximizable?

Post by Anthony Petrov
BTW, isn't the setResizable(false) a good approximation for our
requirements? You can still minimize such a window, but I think this is
reasonable. E.g. OS X will minimize both the dialog and its owner
window, allowing a user to perform other tasks unrelated to the dialog
and windows it blocks. Why do we want to disable minimization?

Unminimizable windows are annoying. If we disable that, we'll likely get
some weirdness, e.g. Win+M or Win+D on Windows will leave the window on
the desktop, which is not what users expect.

Thanks,

Artem

Post by Anthony Petrov
--
best regards,
Anthony

Some native platforms (mostly, X window managers) don't provide direct
APIs to enable/disable certain window decoration buttons. A library or
an application may provides some hints, which may or may not be
respected by WM.
I like what we have right now, StageStyle approach. Application defines
the purpose of the window and let the platform decide, what are
available actions for it.
Thanks,
Artem

Post by Pavel Safrata
Regards,
Pavel

Werner Lehmann

2013-07-23 11:19:19 UTC

Post by Artem Ananiev
To me, making a window non-resizable is a good way to make the window
unmaximizable. Do you see any cases, when a window should be resizable,
but not maximizable?

I create resizable modal dialogs on a frequent basis. To me, sizability
is a convenience for the user. At the same time, modal dialogs should
not be maximized. My opinion.

Post by Artem Ananiev
Unminimizable windows are annoying. If we disable that, we'll likely get
some weirdness, e.g. Win+M or Win+D on Windows will leave the window on
the desktop, which is not what users expect.

Minimizing a modal dialog does not achieve much because the owning
window is still blocked. Unless that window is minimized along. At least
Windows usually disables the window decoration buttons of the owning
window though.

Werner

Fabrizio Giudici

2013-07-23 20:33:29 UTC

On Tue, 23 Jul 2013 13:19:19 +0200, Werner Lehmann

Post by Werner Lehmann
Minimizing a modal dialog does not achieve much because the owning
window is still blocked. Unless that window is minimized along. At least
Windows usually disables the window decoration buttons of the owning
window though.

I just tried initOwner() on Mac OS X. The dialog "bounces" in the
minimized state off and on; I mean, I see first the Genie effect "out" and
the dialog is minimized, and immediately after I see the Genie effect "in"
and the dialog is restored. At the very end, the whole application window
is pushed back (that is, other application windows get over it).

I presume it doesn't make much sense :-) But it actually disables the
"full screen" and maximize buttons as expected.

--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - ***@tidalwave.it

Anthony Petrov

2013-07-23 20:34:48 UTC

Hi Werner,

Post by Artem Ananiev
To me, making a window non-resizable is a good way to make the window
unmaximizable. Do you see any cases, when a window should be resizable,
but not maximizable?

I create resizable modal dialogs on a frequent basis. To me, sizability
is a convenience for the user. At the same time, modal dialogs should
not be maximized. My opinion.

I don't agree. IMO, it's annoying when I'm able to resize a window
freely but unable to maximize it. This just doesn't look logical or
convenient.

Indeed. I was thinking about implementing the behavior that OS X
provides for native windows: if you iconify an owned modal dialog, its
owner gets iconified as well. This looks very convenient. We might try
to implement this in Glass for other platforms as well. Or
alternatively, we could provide an API to disable window iconification.

--
best regards,
Anthony

Fabrizio Giudici

2013-07-23 20:45:47 UTC

On Tue, 23 Jul 2013 22:34:48 +0200, Anthony Petrov

Post by Anthony Petrov
I don't agree. IMO, it's annoying when I'm able to resize a window
freely but unable to maximize it. This just doesn't look logical or
convenient.

I'm with Werner here. Maximixing a dialog is usually ugly from the
aesthetic point of view, but sometimes I'm annoyed by dialogs that are
just a bit too narrow for entering a text, or something else
(incidentally, e.g. the Java control panel seems to be filled with
non-resizable windows designed just to annoy people :-). I'd just like to
stretch them a bit.

But I don't know how this stands with the various operating system design
guidelines.

--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - ***@tidalwave.it

Artem Ananiev

2013-07-24 07:59:07 UTC

Post by Fabrizio Giudici
On Tue, 23 Jul 2013 22:34:48 +0200, Anthony Petrov

Post by Anthony Petrov
I don't agree. IMO, it's annoying when I'm able to resize a window
freely but unable to maximize it. This just doesn't look logical or
convenient.

Could you identify the boundary between just making a window larger and
maximizing it? I can't. What about Windows 7 "snap" feature, is it
resizing or maximizing? In other words, my understanding is that if a
window is resizable, it should be maximizable as well. However, as I
wrote in my previous emails, sometimes it's out of Java control: we can
say if a window should be resizable or not, and the platform decides if
it is minimizable/maximizable or not.

Thanks,

Artem

Post by Fabrizio Giudici
But I don't know how this stands with the various operating system
design guidelines.

Fabrizio Giudici

2013-07-24 08:29:01 UTC

On Wed, 24 Jul 2013 09:59:07 +0200, Artem Ananiev

Post by Fabrizio Giudici
On Tue, 23 Jul 2013 22:34:48 +0200, Anthony Petrov

Post by Anthony Petrov
I don't agree. IMO, it's annoying when I'm able to resize a window
freely but unable to maximize it. This just doesn't look logical or
convenient.

The boundary is when you feel the look is ugly, thus it's related to the %
of size increase. That's why "snap" is not a problem. Of course I can't
tell you a precise threshold, it depends. But it's ok when I just enlarge
a window because it lacks the room for say 5-10 characters of input, while
I don't like to see a maximized window where there's just a small content
and large amounts of empty space.

Also: sometimes you want a modal, that is the main window is blocked, but
perhaps you need to read something in the main window, that would help to
answer to the question of the modal. If the modal is just resizable (and
draggable) there's no problem. If the modal has been maximized, you can't.
Of course, it's up to the user to avoid maximizing it if it's a problem -
there are no showstoppers here. But UI design is all about driving the
user in the right direction and minimizing the number of interaction items
needed to accomplish a task.

--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - ***@tidalwave.it

Anthony Petrov

2013-07-24 10:52:27 UTC

Post by Fabrizio Giudici
On Wed, 24 Jul 2013 09:59:07 +0200, Artem Ananiev

Post by Fabrizio Giudici
On Tue, 23 Jul 2013 22:34:48 +0200, Anthony Petrov

Post by Anthony Petrov
I don't agree. IMO, it's annoying when I'm able to resize a window
freely but unable to maximize it. This just doesn't look logical or
convenient.

Could you identify the boundary between just making a window larger
and maximizing it? I can't. What about Windows 7 "snap" feature, is it
resizing or maximizing? In other words, my understanding is that if a
window is resizable, it should be maximizable as well. However, as I
wrote in my previous emails, sometimes it's out of Java control: we
can say if a window should be resizable or not, and the platform
decides if it is minimizable/maximizable or not.
Thanks,

Then just don't push the Maximize button! :) I mean, you can easily
achieve the state of ugliness by resizing the window as well, but you
still want it to be resizable. So what's the big deal with the Maximize
button then? Let it be there for people who want/need it.

Post by Fabrizio Giudici
Also: sometimes you want a modal, that is the main window is blocked,
but perhaps you need to read something in the main window, that would
help to answer to the question of the modal. If the modal is just
resizable (and draggable) there's no problem. If the modal has been
maximized, you can't. Of course, it's up to the user to avoid maximizing
it if it's a problem - there are no showstoppers here. But UI design is
all about driving the user in the right direction and minimizing the
number of interaction items needed to accomplish a task.

I doubt an app would maximize a dialog initially (and if it does, it's a
problem in the app itself). Otherwise, it's up to the user to
maximize/unmaximize the dialog, or only resize it whenever and however
it is needed/convenient at the moment.

--
best regards,
Anthony

Fabrizio Giudici

2013-07-24 11:52:30 UTC

On Wed, 24 Jul 2013 12:52:27 +0200, Anthony Petrov

Otherwise, it's up to the user to maximize/unmaximize the dialog, or
only resize it whenever and however it is needed/convenient at the
moment.

As I said, to me UI design is also constraining the user in the set of
meaningful actions. The more useless freedom you give him, the more damage
he will do :-)

--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - ***@tidalwave.it

Artem Ananiev

2013-07-24 07:54:21 UTC

Post by Anthony Petrov
Hi Werner,

Post by Artem Ananiev
To me, making a window non-resizable is a good way to make the window
unmaximizable. Do you see any cases, when a window should be resizable,
but not maximizable?

I create resizable modal dialogs on a frequent basis. To me, sizability
is a convenience for the user. At the same time, modal dialogs should
not be maximized. My opinion.

I don't agree. IMO, it's annoying when I'm able to resize a window
freely but unable to maximize it. This just doesn't look logical or
convenient.

Post by Anthony Petrov

Modal dialogs are (or should be) used to get some input from user.
Window closing confirmation is a good example. Application cannot
proceed further, until it have the input, so it doesn't make sense to
minimize the modal dialog and leave application in the "suspended" state.

Thanks,

Artem

Post by Anthony Petrov
--
best regards,
Anthony

Anthony Petrov

2013-07-24 10:46:27 UTC

Post by Anthony Petrov

This sounds reasonable. As I said, we can go and implement the
setMinimizable(boolean) in Glass/FX. The spec would just state that in
rare cases on some platforms this hint may not be taken into account by
the native OS GUI toolkit (I mean some strange X11 window managers here).

--
best regards,
Anthony

Anthony Petrov

2013-07-23 20:27:37 UTC

Hi Artem, Jonathan,

I agree with what you say, except for using the initOwner() to imply
some particular (and implicit) style that is going to be applied to the
window. We should evaluate first whether the current implementation is
sufficient. And no, I don't see a reason to disable maximization for a
resizable window.

Jonathan: what is your opinion on using the setResizable(false) for the
use cases that you outlined?

--
best regards,
Anthony

To me, making a window non-resizable is a good way to make the window
unmaximizable. Do you see any cases, when a window should be resizable,
but not maximizable?

Post by Anthony Petrov
--
best regards,
Anthony

Some native platforms (mostly, X window managers) don't provide direct
APIs to enable/disable certain window decoration buttons. A library or
an application may provides some hints, which may or may not be
respected by WM.
I like what we have right now, StageStyle approach. Application defines
the purpose of the window and let the platform decide, what are
available actions for it.
Thanks,
Artem

Post by Pavel Safrata
Regards,
Pavel

Jonathan Giles

2013-07-23 20:36:10 UTC

To be clear, are you proposing that setResizable(false) on a Stage
(where its owner is non-null) will be used to specify both that the
stage can not be resized and that it can not be minimised?

I don't have a big opinion on the best approach, except of course the
discoverability of the functionality might be somewhat questionable. If
it were me (and without all the insights your team has), my alternative
suggestion would be to introduce a setIconifiable(boolean) method (along
with isIconifiable() and iconifiableProperty()). I only recommend this
to have some degree of symmetry with the iconfied property that is used
to represent (I believe) whether the stage is currently minimised.

In my use case for dialogs, specifying the owner is an optional
property, but in general it is one of those properties that people
should not leave as null. In other words, I'm comfortable enforcing a
non-null owner requirement for people who do not want the minimize
button, for example.

Thanks,
-- Jonathan

Post by Anthony Petrov
Hi Artem, Jonathan,
I agree with what you say, except for using the initOwner() to imply
some particular (and implicit) style that is going to be applied to
the window. We should evaluate first whether the current
implementation is sufficient. And no, I don't see a reason to disable
maximization for a resizable window.
Jonathan: what is your opinion on using the setResizable(false) for
the use cases that you outlined?
--
best regards,
Anthony

To me, making a window non-resizable is a good way to make the window
unmaximizable. Do you see any cases, when a window should be resizable,
but not maximizable?

Post by Anthony Petrov
--
best regards,
Anthony

Post by Pavel Safrata
Hi Jonathan,
I believe this has been neither requested nor discussed so far. I don't
see why this couldn't be added, it just might have to be a
conditional
feature, we'll have to check. Feel free to file a feature request.

Some native platforms (mostly, X window managers) don't provide direct
APIs to enable/disable certain window decoration buttons. A library or
an application may provides some hints, which may or may not be
respected by WM.
I like what we have right now, StageStyle approach. Application defines
the purpose of the window and let the platform decide, what are
available actions for it.
Thanks,
Artem

Post by Pavel Safrata
Regards,
Pavel

Tom Schindl

2013-07-23 21:18:03 UTC

Hi,

The question for me is what we want:

* disable iconification / maxification completely (even through
code) => then an iconifiable property is appropriate

* disable iconification / maxification through trimbar buttons
=> then I'd vote for the possibility to set the buttons enabled on
stage through a list-property and an enum

In code this would be:
Stage s = new Stage();
s.setTrimButtons(TrimButton... buttons)

IIRC in SWT one can set them individually no matter if the parent is set
or not, Steve would know better I guess.

Tom

Post by Jonathan Giles
To be clear, are you proposing that setResizable(false) on a Stage
(where its owner is non-null) will be used to specify both that the
stage can not be resized and that it can not be minimised?
I don't have a big opinion on the best approach, except of course the
discoverability of the functionality might be somewhat questionable. If
it were me (and without all the insights your team has), my alternative
suggestion would be to introduce a setIconifiable(boolean) method (along
with isIconifiable() and iconifiableProperty()). I only recommend this
to have some degree of symmetry with the iconfied property that is used
to represent (I believe) whether the stage is currently minimised.
In my use case for dialogs, specifying the owner is an optional
property, but in general it is one of those properties that people
should not leave as null. In other words, I'm comfortable enforcing a
non-null owner requirement for people who do not want the minimize
button, for example.
Thanks,
-- Jonathan

To me, making a window non-resizable is a good way to make the window
unmaximizable. Do you see any cases, when a window should be resizable,
but not maximizable?

Post by Anthony Petrov
--
best regards,
Anthony

Some native platforms (mostly, X window managers) don't provide direct
APIs to enable/disable certain window decoration buttons. A library or
an application may provides some hints, which may or may not be
respected by WM.
I like what we have right now, StageStyle approach. Application defines
the purpose of the window and let the platform decide, what are
available actions for it.
Thanks,
Artem

Post by Pavel Safrata
Regards,
Pavel

s***@oracle.com

2013-07-24 07:28:01 UTC

Tom is correct. They can be set individually and a best effort is made
to honor them. If you create an SWT stage whose parent is another SWT
stage without specifying the trim buttons, the default for the operating
system is chosen.

Steve

Post by Tom Schindl
Hi,
* disable iconification / maxification completely (even through
code) => then an iconifiable property is appropriate
* disable iconification / maxification through trimbar buttons
=> then I'd vote for the possibility to set the buttons enabled on
stage through a list-property and an enum
Stage s = new Stage();
s.setTrimButtons(TrimButton... buttons)
IIRC in SWT one can set them individually no matter if the parent is set
or not, Steve would know better I guess.
Tom

To me, making a window non-resizable is a good way to make the window
unmaximizable. Do you see any cases, when a window should be resizable,
but not maximizable?

Post by Anthony Petrov
--
best regards,
Anthony

Some native platforms (mostly, X window managers) don't provide direct
APIs to enable/disable certain window decoration buttons. A library or
an application may provides some hints, which may or may not be
respected by WM.
I like what we have right now, StageStyle approach. Application defines
the purpose of the window and let the platform decide, what are
available actions for it.
Thanks,
Artem

Post by Pavel Safrata
Regards,
Pavel

Werner Lehmann

2013-07-24 10:29:32 UTC

I'd like this the most, assuming that a "trim button" is the same as a
button on the window decoration (not familiar with the term trim
button). Other than that, I'd also like the ability to minimize a modal
dialog if that actually minimizes the main window... It is not common on
Windows but makes a lot of sense.

Werner

Post by Tom Schindl
* disable iconification / maxification through trimbar buttons
=> then I'd vote for the possibility to set the buttons enabled on
stage through a list-property and an enum
Stage s = new Stage();
s.setTrimButtons(TrimButton... buttons)

Tom Schindl

2013-07-24 10:37:03 UTC

I called it TrimButton because this is the term used in SWT - maybe
StageButton is the better word. StageButton should be an enum.

enum StageButton {
MIN,
MAX,
CLOSE
}

Tom

Post by Werner Lehmann
I'd like this the most, assuming that a "trim button" is the same as a
button on the window decoration (not familiar with the term trim
button). Other than that, I'd also like the ability to minimize a modal
dialog if that actually minimizes the main window... It is not common on
Windows but makes a lot of sense.
Werner

Anthony Petrov

2013-07-24 11:28:21 UTC

Hi Jonathan,

setResizable(false) only disables the Maximize button (for obvious
reasons.) And this should already be implemented.

As to the setIconifiable(boolean) functionality, I agree it would be
fine to have it. Please file a JIRA issue and we'll implement it.

To address Tom's suggestion on adding fine-grained control for trim
buttons: I don't support this idea for the following reason: you can
access, say, the Iconify action via the trim button. But you can also
right-click the window's titlebar and choose it from the menu. Moreover,
you can right-click the taskbar button associated with the window and
open the same menu from there. In those menus the Iconify is not a
button but a menu item. However, both the trim button and the menu item
represent the Iconify action. Therefore, from API perspective I'd prefer
to be able to disable the Iconify action itself (i.e. the higher level
concept) rather than disable individual native GUI items responsible for
firing the event.

I understand that most likely you're referring to a case when you want
to maximize a window pogramatically and disallow a user to get the
window back to the normal state. I believe you can achieve this using an
UNDECORATED window more easily.

--
best regards,
Anthony

To me, making a window non-resizable is a good way to make the window
unmaximizable. Do you see any cases, when a window should be resizable,
but not maximizable?

Post by Anthony Petrov
--
best regards,
Anthony

Some native platforms (mostly, X window managers) don't provide direct
APIs to enable/disable certain window decoration buttons. A library or
an application may provides some hints, which may or may not be
respected by WM.
I like what we have right now, StageStyle approach. Application defines
the purpose of the window and let the platform decide, what are
available actions for it.
Thanks,
Artem

Post by Pavel Safrata
Regards,
Pavel

Jonathan Giles

2013-07-24 19:52:04 UTC

I've filed https://javafx-jira.kenai.com/browse/RT-31903

Thanks,
-- Jonathan

Post by Pavel Safrata
Hi Jonathan,
setResizable(false) only disables the Maximize button (for obvious
reasons.) And this should already be implemented.
As to the setIconifiable(boolean) functionality, I agree it would be
fine to have it. Please file a JIRA issue and we'll implement it.
To address Tom's suggestion on adding fine-grained control for trim
buttons: I don't support this idea for the following reason: you can
access, say, the Iconify action via the trim button. But you can also
right-click the window's titlebar and choose it from the menu.
Moreover, you can right-click the taskbar button associated with the
window and open the same menu from there. In those menus the Iconify
is not a button but a menu item. However, both the trim button and the
menu item represent the Iconify action. Therefore, from API
perspective I'd prefer to be able to disable the Iconify action itself
(i.e. the higher level concept) rather than disable individual native
GUI items responsible for firing the event.
I understand that most likely you're referring to a case when you want
to maximize a window pogramatically and disallow a user to get the
window back to the normal state. I believe you can achieve this using
an UNDECORATED window more easily.
--
best regards,
Anthony

To me, making a window non-resizable is a good way to make the window
unmaximizable. Do you see any cases, when a window should be resizable,
but not maximizable?

Post by Anthony Petrov
--
best regards,
Anthony