> On Sept. 16, 2014, 4:08 p.m., Vishesh Handa wrote:
> > We currently have the following ways of changing the dialog size
> >
> > 1. By changing the mainItem size
> > 2. By actually changing the size of the dialog via QML
> > 3. Window Managers
> >
> > (3) is not something that is exposed to the user since the dialog never
> > actually has the border. I think we can safely ignore this one. Also, maybe
> > can explicitly set some window flags to tell the WM to never allow the
> > client to resize the window.
> >
> > (2) kind of makes sense except that then maybe we shouldn't have (1).
> > Example -
> >
> >
> > Dialog {
> > width: 500
> > height: 500
> >
> > mainItem : Rectangle {
> > width : 200
> > height: 200
> > }
> > }
> >
> > What do you think should be happening in this case? It's not obvious. I
> > propose we make the mainItem responsible for the dialog size. The 'width'
> > and 'height' properties of the Dialog can be made read only.
>
> Marco Martin wrote:
> "is not something that is exposed to the user since the dialog never
> actually has the border."
> That's not relevant, I never make assumptions on what is currently
> exposed to the user or what is the current use case, that can change at any
> moment.
> That's my policy for plasma-framework, that admittely may not be always
> followed in the current codebase, but that can always be improved, instead of
> going on the other side. "if it can happen, it has to be managed".
>
> In the example, I think we should make sure in this case is Dialog
> winning (and document that) even if the dialog size would have read only
> properties, window managers can always decide to resize it regardless.
>
> Vishesh Handa wrote:
> But we can explicily block the dialog class from allowing user based
> resizes with window flags. No? This way we are clearly defining what we
> allow. The moment the use case changes we can adapt our code.
>
> If you're still not keen on disabling external dialog resizing until we
> have a clear use case. We can also possibly do the following - Add an
> explicit flag as to what should be happening. QQuickView does something
> similar - It has an explicit ResizeMode. Anway, I would still really prefer
> us adapating to our current uses cases and making them work well instead of
> targetting everything when it complicates our code base.
I really want to allow extrenal resize.
The fact that QQuickView allows only one way or the other is a limitation i
never liked, especially because making it work both ways, is not hard at all
(and SizeWindowToRootItem is completely useless on desktop systems).
- Marco
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120235/#review66684
-----------------------------------------------------------
On Sept. 16, 2014, 3:52 p.m., Marco Martin wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120235/
> -----------------------------------------------------------
>
> (Updated Sept. 16, 2014, 3:52 p.m.)
>
>
> Review request for Plasma.
>
>
> Repository: plasma-framework
>
>
> Description
> -------
>
> A dialog can be resize for two reasons: the mainItem size changes, or the
> dialog size changes.
>
> the first can happen programmatically, caused by the Layout, or just by
> assigning the width.
>
> the second can be caused either programmatically, assigning the size of the
> dialog or externally by the windowmanager, that is the only one theat in the
> end has the only final control of the window size
>
>
> Diffs
> -----
>
> src/plasmaquick/dialog.cpp 79a871b
> tests/dialog_minWidthHeightRepositioning.qml 37bd622
>
> Diff: https://git.reviewboard.kde.org/r/120235/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Marco Martin
>
>
_______________________________________________
Plasma-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/plasma-devel
