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
On 23.07.13 22: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
>>>>>>
>
