> 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.
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.
- Vishesh
-----------------------------------------------------------
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
