Review Request 120235: restore ResizeOrigin
Marco Martin
notmart at gmail.com
Tue Sep 16 17:04:59 UTC 2014
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140916/3e99139a/attachment.html>
More information about the Plasma-devel
mailing list