Make the group box a registered subwidget of the BoolAspect, so it
properly triggers the necessary behavior in BaseAspect::isDirty.
Change-Id: I9f6291d87ef7ce4067e0d235de8b5be24de79a93
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... and add a 'void applied()' signal.
I actually wanted to avoid that, but it seems to be a recurring
pattern of usage to do something on top of plain apply for all
children, like triggering IVersionControl::configurationChanged
in the VCS plugins.
Change-Id: Ib64c3147c6ba30b178237e51a3a377a291c550f2
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The generic update that is triggered on all major interactions
did not take a explicitly set disabled flag into account.
Change-Id: I026bc0817ce534e92cfdd631beebcb80ddf7e6dd
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Analog to BoolAspect::volatileChanged for cases when the availability
of some other aspect, line edit, ... is governed by a specific state
of a combobox.
Change-Id: I5c7903dde21ab997e799568b20a01308a25c4397
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
They were quite similar, largest difference was the ownership of
subaspects, which is now handled by a bool property.
Change-Id: Ib3f2f20b9a84ef40ea8a9eb59da9c89c9a281750
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Items deleted in finish() trigger via the connect in registerAspect their
own removal from m_subWidgets, invalidating container iterators used
by deleteAll().
The re-ordering to back-to front does not make a difference, I'd
still to destroy things in reverse construction order.
Change-Id: Ibb17da7cdc67013d744b159aa33fd1d119080e3b
Reviewed-by: David Schulz <david.schulz@qt.io>
Similar to what BoolAspect already has. Will help with the NimSettings
page.
Change-Id: Id373cd21769c129fb8329d9102ccfd97675e8d24
Reviewed-by: David Schulz <david.schulz@qt.io>
Resets line edit contents to defaultValue(), disabled if current
contents is the default.
Usable later for BuildPropertySettings
Change-Id: I1fcbcfb8664eb7f66de62a6606d8d7556026f468
Reviewed-by: David Schulz <david.schulz@qt.io>
In the context of option pages, finish() means that the dialog is
dismissed somehow. Keeping the widgets around for subsequent re-use
is ok in principle, on the other hand it's a matter of hygiene and
give a defined clean slate next time addToLayout() is used.
This has not much practical impact yet as most option pages do not
forward finish() to their aspects right now.
Change-Id: Ifd591e3fa0d07c7943e86eb5474429efae2887f9
Reviewed-by: David Schulz <david.schulz@qt.io>
Register subwidgets to make non-autoapply work.
Also delete the parent-less button group on destruction.
Change-Id: If6fb306a812c8aa950535dd138a2020145d80c34
Reviewed-by: David Schulz <david.schulz@qt.io>
This is in line with what the other aspects do. Without this,
non-auto-apply aspects behave as auto-apply, even if marked with
setAutoApply(false).
Change-Id: I39192f63bb3b6e47ee181527938c19ee5044a5ec
Reviewed-by: David Schulz <david.schulz@qt.io>
In some cases it is useful when the persistent value is not the
internally used actual value, e.g. Having the displayed string
of a SelectionAspect instead of a numerical index makes
the settings more readable for a human.
Change-Id: I11ecb8e75ab041ace2358cc45972ce9ee965b24d
Reviewed-by: David Schulz <david.schulz@qt.io>
Merge it with the read/writeSettings implementation that was already
there.
Change-Id: I25dfbdf6fd1cf122b17f89eae82cb2598d8470c8
Reviewed-by: David Schulz <david.schulz@qt.io>
This lets us using & shortcut e.g. in settings pages.
Change-Id: If630ba221298374c9a59820e7955ded80b4166cc
Reviewed-by: David Schulz <david.schulz@qt.io>
For single configuration projects if you change the build type
aspect you will change the CMAKE_BUILD_TYPE variable.
When switching the build directory the existing CMAKE_BUILD_TYPE
will be set as build type aspect.
Fixes: QTCREATORBUG-25451
Change-Id: I13519e95c316c556cc1348fba6121637d2fd4275
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
This is not advised use, but helps to avoid an awful hack in the
AppManager plugin.
Change-Id: If40535dfb2c7bd15ff6d4fe49f4fa45d68150ef6
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Also do not access Aspect::volatileValue if aspect was never shown
In this case, user-induced unsaved changes cannot exist. This also
avoids QTC_ASSERT in the volatileValue() implementations in these cases.
Silences the contained QTC_ASSERTs properly and avoids returning
a null-variant that's likely not identical to the default value.
Change-Id: Idba89997d0b0b4f9b7dcac0881afe36b35ccdf7c
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Amends b7acf45c1. The primary connection was already there, and
correctly if'd, and the patch added accidentally a second connection
which was harmless in the auto-apply case, but effectively made the
manual-apply case also auto-apply.
Change-Id: I5ee72ff4715fb0077a47f71e8d45a5b6251c4121
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
So it applies to all subsequently registered subaspects.
Change-Id: I9cc215b6ed9637eefc3b1721db778d4097809faa
Reviewed-by: David Schulz <david.schulz@qt.io>
In most cases, the layout constructed in the builder was set
on a widget which in turn was put into a vbox in the actual
widget. This is not necessary, but needs some re-ordering.
Also make sure that using not-yet-parented widgets during
layout construction does not cause visible artifacts.
Change-Id: I75727a571da093d3131ea6fba467c2c646cdb6f1
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Makes the code on the user side somewhat more symmetric and is a
bit more flexible, even if that's not used right now.
Change-Id: I29a5182463ead0e4a39fcb51ecf4fdd5adf2a203
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This was a workaround from a time where BaseAspect didn't know about
subwidgets created by derived aspects. That's not the case anymore.
Subwidgets registered with registerSubWidget() get their visibility
adjusted by BaseAspect::setVisibility() nowadays.
Subwidgets not registered with registerSubWidget() should not exist.
Change-Id: I8cdf72e5ea1f93c519f606913e084c78afecb56f
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Turns out to get into the way more often than it helps, e.g.
'setAutoApply' operated on the base class' m_autoAspect flag
instead of spreading it over the items in the container.
Change-Id: I2711f2a488d1a6c30ec21d3fc481563cec6e55d4
Reviewed-by: David Schulz <david.schulz@qt.io>
The same pattern as used in DoubleAspect to avoids the asserts on autoapply
state in apply().
Change-Id: Ie06bac7fd8ec24ad461dc932c8eb85fa043a6fb7
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
setValue() has to be called after setRange(), otherwise the value will
by cut at the initial default 99 maximum.
Change-Id: Id4a7cf1db0e3044f32022d6de8f66810f9cd6b4e
Reviewed-by: David Schulz <david.schulz@qt.io>
... when triggered via base class setValue().
The pattern would probably be useful for other aspects, too, but e.g.
for actions in a menu (like switching on/off FakeVim) this already
covers most cases.
Change-Id: I7886f4b845883edb6d337df0fa53f989ae893f65
Reviewed-by: David Schulz <david.schulz@qt.io>
To be used with doubles (and QDoubleSpinbox as representation)
Change-Id: I0ad8ce1e495c48a305a42328c48e226ab3d4278c
Reviewed-by: David Schulz <david.schulz@qt.io>
Useful for toggles in tool buttons, as used e.g. in valgrind.
Change-Id: I61f5d4ba86d1f39d0071e4c0e37d2447f408a91e
Reviewed-by: David Schulz <david.schulz@qt.io>
The current aspect implementation directly couples ui element
changes with aspect value changes. This is appropriate in situations
like the Build or Run Settings, where configuration changes are
automatically applied.
This change here makes these connections configurable to potentially
re-use aspects in Ok/Apply/Cancel scenarios, as a first step only
for {Bool,Integer,String}Aspect.
The change is source-compatible, but changes the behavior of
BaseAspect::setDefaultValue(): This now _always_ sets also the
value, silently.
Change-Id: I2acd66b42c2251134658d35bb31b5d938149de4f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
