summaryrefslogtreecommitdiff
path: root/src/dialogs/qquickabstractdialog_p.h
Commit message (Collapse)AuthorAgeFilesLines
* Rename QQuickDialog to QQuickDialog1v5.8.0-beta1Jake Petroules2016-10-061-1/+1
| | | | | | | | | | | | This fixes a linking error when Qt is built statically and both Qt Quick Controls 1 and Qt Quick Controls 2 are used in the same application, due to Qt Quick Controls 2 also containing a class named QQuickDialog. Change-Id: I16ad8b1a3c75d0fa3e4ba1c3ab54a63caf05bbea Reviewed-by: J-P Nurmi <jpnurmi@qt.io> Reviewed-by: Alex Leutgöb <alex@v-play.net> Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
* Merge remote-tracking branch 'origin/5.6' into 5.7Liang Qi2016-02-161-1/+3
|\ | | | | | | | | | | | | | | | | Conflicts: .qmake.conf src/dialogs/qquickabstractfiledialog.cpp src/dialogs/qquickfiledialog.cpp Change-Id: I60aab7c7e819f82f82fc30f473b36a7a57d9a91a
| * Android: fix Dialog window decorations' dismiss-on-click behaviorVladimir Moolle2016-01-221-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes the case when a modal dialog is instantiated in a visible state, which often means, the window decoration component has not been loaded yet. Previously, this led to dismissOnOuterClick property in DefaultWindowDecoration keeping its initial value of "true" and thus allowing dismissing the dialog via an outside click *the first time the dialog was hidden* (next times, the property would get updated and the behavior would be correct). Task-number: QTBUG-47369 Change-Id: I24c7c8a1eb785203a3b3f1d889b7e22480ea952f Reviewed-by: Mitch Curtis <mitch.curtis@theqtcompany.com>
* | Unify license header usageAntti Kokko2016-02-041-12/+15
|/ | | | | | | Update old header.LGPL3 to header.LGPL Change-Id: I3c851bc24da89f6300b94199387d1adf16ca4f48 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Dialogs: redo calculations depending on __maximumDimension before showShawn Rutledge2015-03-301-1/+2
| | | | | | | | | | | | | Once again the old problem recurs that on Android the primaryScreen has invalid geometry at the time the dialog's QML implementation is loaded. So if the loading occurs before the main window is shown, the dialog was resized to 0x0 and stayed that way. The fix is to make __maximumDimension a notifying property and artificially emit a change signal each time before the dialog is shown. Task-number: QTBUG-45092 Change-Id: Ie86eb7f7bd3cbe8401ccc98c9cc8829c788a71dd Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@theqtcompany.com>
* Dialogs: if dialog helper fails showing, fall back to use QMLRichard Moe Gustavsen2015-03-181-0/+1
| | | | | | | | | | By doing this, we respect if the dialog helper returns false on show, and use QML as fall back if possible. This opens up for the possibility that platforms can offer native dialogs for certain dialog configurations, and otherwise fall back to use QML/widgets when none exists. Change-Id: I7c8c691ff024051ecf3a8d2c91cdd6d55cec5730 Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
* Dialogs: update license headersJ-P Nurmi2015-02-111-16/+19
| | | | | | Change-Id: I1abdce308929507416b5f24b4442d0b978886a46 Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@theqtcompany.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
* Dialogs: added private maximumDimension property for initial sizeShawn Rutledge2014-10-131-0/+2
| | | | | | | | | | | The Screen.attached property does not know which screen will be used until the dialog is shown, but we need to know how big the desktop is before it is shown in order to constrain a reasonable dialog size, before the Flow lays out the buttons. Otherwise it will be too tall. Task-number: QTBUG-41734 Change-Id: I44349fab4ad0254d2c6faf30c759fb9e52eebf03 Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com>
* Dialogs: if implicitHeight becomes smaller, ensure the minimum does tooShawn Rutledge2014-10-131-0/+1
| | | | | | | | | | Initial implicitHeight of the content can be wrong, but after showing the window, there's still a chance to get it right, for example to avoid showing MessageDialog larger than it needs to be. Task-number: QTBUG-41734 Change-Id: Ib6db8d0ebe4a3d29bfc6bc36c46caba6955a2294 Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com>
* Merge remote-tracking branch 'origin/5.3' into 5.4Frederik Gladhorn2014-08-281-0/+1
|\ | | | | | | Change-Id: I4aa5c960a03616d95f9e1d10b4c8ba222997a24d
| * Dialogs must know when they are closed by the operating systemShawn Rutledge2014-08-251-0/+1
| | | | | | | | | | | | | | | | | | | | The dialog cannot be opened again if it does not know that it was closed. So whenever there is a native window, the visibleChanged signal must be connected. Task-number: QTBUG-40855 Change-Id: I0726b7568937a19deba067d43ce72b0579f7c4c5 Reviewed-by: Liang Qi <liang.qi@digia.com>
* | Update license headers and add new license filesAntti Kokko2014-08-251-19/+11
|/ | | | | | | | | - Renamed LICENSE.LGPL to LICENSE.LGPLv21 - Added LICENSE.LGPLv3 & LICENSE.GPLv2 - Removed LICENSE.GPL Change-Id: I470909ba0980db33ab551790d619c59a35978590 Reviewed-by: Jani Heikkinen <jani.heikkinen@digia.com>
* Dialogs: implementation prop renamed to contentItem; API cleanupShawn Rutledge2014-04-151-4/+3
| | | | | | | | | | | | | | | | | | | | | - contentItem is a common name for an item inside something such as a window or a flickable. We now consider it adequate API that you can directly set this to some item which you want to fill the whole dialog instead of adding an item as a child of the default property and being subject to the dialog's margins and space reservation for buttons. - contentItem MUST be an Item. Allowing the old "implementation" property to alternatively be a ready-made Window was just a hypothetical use case, but if anyone made use of that, then it would be a problem to have that kind of dialog on a GUI that cannot have windows (such as Android or EGLFS). So there's no point in having the possibility as long as we cannot emulate windows as items. - standardButtonsRightModel and standardButtonsLeftModel are implementation details so they should not be exposed as properties which Creator can discover; users shouldn't depend on them. Task-number: QTBUG-38056 Change-Id: Iefa3def314353495cfe8d1ef9f775a8e46d5bcf4 Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
* Replace module includes in dialogsAndrew Knight2014-03-111-1/+1
| | | | | | | | Replace a number of QtQml module inclusions with their more specific counterparts, possibly leading to decreased compilation time. Change-Id: I9b48b06e884d46c6440725a704951dc87e2e93db Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
* QtQuick.Dialogs: added Dialog: wrapper for arbitrary contentShawn Rutledge2014-02-151-0/+31
| | | | | | | | | | | | It provides only a button box, so the application developer can supply the rest of the dialog contents. This is useful for various kinds of dialogs that prompt the user for input. [ChangeLog][QtQuickDialogs][Dialog] Dialog is a new wrapper component for dialogs with standard buttons and custom content items. Change-Id: I0434bed5f504820dc0a668cb993a94980f99852a Reviewed-by: Liang Qi <liang.qi@digia.com>
* move QtQuick.Dialogs from qtdeclarative to qtquickcontrolsShawn Rutledge2014-01-031-0/+145
This will enable using Controls in the QML dialog implementations. For now, Controls are used only as drop-in replacements for the Button, Checkbox, and TextField which were custom implementations in the qtdeclarative module before. Change-Id: Ic79e9e8e5715a72ce51f4c724bfdfd33653300f2 Reviewed-by: Liang Qi <liang.qi@digia.com>
View Lorry Controller Status