I've filed https://javafx-jira.kenai.com/browse/RT-31903
Thanks,
-- Jonathan
On 24/07/2013 11:28 p.m., Anthony Petrov wrote:
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
On 07/24/13 00:36, Jonathan Giles wrote:
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
On 24/07/2013 8:27 a.m., Anthony Petrov wrote:
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
On 07/23/2013 02:39 PM, Artem Ananiev wrote:
On 7/22/2013 9:17 PM, Anthony Petrov wrote:
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.
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?
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
--
best regards,
Anthony
On 07/22/2013 07:20 PM, Artem Ananiev wrote:
On 7/22/2013 11:14 AM, Pavel Safrata wrote:
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
Regards,
Pavel
On 21.7.2013 4:44, Jonathan Giles wrote:
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
