Which only differed in some property settings.
Change-Id: Ie844c32709ebe719a5b749fd2ef828b64086ba9a
Reviewed-by: hjk <hjk@theqtcompany.com>
Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
The methods are only relevant for documents without a filePath, and
there was a mix of different irrelevant implementations present in
subclasses.
Change-Id: I4f57d306e5ddd913974cfe6ed0b4db062eb907a1
Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
To fallbackSaveAsPath and fallbackSaveAsFileName. That makes it clearer
what they are for, and that they actually belong to each other.
Change-Id: Ie5b83b9db77d39a7fe9e979cc8f22b7f5b9101a3
Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
A theme is supposed to provide colors, flags and images. This change
removes functions from Theme which do not just return simple data.
Also ManhattanStyle and Theme get separated a bit.
Change-Id: I2fab26ee38b858fefb55920eb219f84abcfaac18
Reviewed-by: hjk <hjk121@nokiamail.com>
Adds a 'Theme' tab to the environment settings and a '-theme' command
line option.
A theme is a combination of colors, gradients, flags and style
information.
There are two themes:
- 'default': preserves the current default look
- 'dark': uses a more flat for many widgets, dark color theme
for everything
This does not use a stylesheet (too limited), but rather sets
the palette via C++ and modifies drawing behavior.
Overall, the look is more flat (removed some gradients and bevels).
Tested on Ubuntu 14.04 using Qt 5.4 and running on a KDE
Desktop (Oxygen base style).
For a screenshot, see
https://gist.github.com/thorbenk/5ab06bea726de0aa7473
Changes:
- Introduce class Theme, defining the interface how to access theme
specific settings. The class reads a .creatortheme file (INI file, via
QSettings)
- Define named colors in the [Palette] section
(see dark.creatortheme for example usage)
- Use either named colors of AARRGGBB (hex) in the [Colors]
section
- A file ending with .creatortheme may be supplied
to the '-theme' command line option
- A global Theme instance can be accessed via creatorTheme()
- Query colors, gradients, icons and flags from the theme
were possible (TODO: use this in more places...)
- There are very many color roles. It seems better to me
to describe the role clearly, and then to consolidate later
in the actual theme by assigning the same color.
For example, one can set the text color of the output pane button
individualy.
- Many elements are also drawn differently.
For the dark theme, I wanted to have a flatter look.
- Introduce Theme::WidgetStyle enum, for now {Original, Flat}.
- The theme specifies which kind of widget style it wants.
- The drawing code queries the theme's style flag and
switches between the original, gradient based look and
the new, flat look.
- Create some custom icons which look better on dark background
(wip, currently folder/file icons)
- Let ManhattanStyle draw some elements for non-panelwidgets, too
(open/close arrows in QTreeView, custom folder/file icons)
- For the welcomescreen, pass the WelcomeTheme class.
WelcomeTheme exposes theme colors as Q_PROPERTY accessible from
.qml
- Themes can be modified via the 'Themes' tab in the environment
settings.
TODO:
* Unify image handling
* Avoid style name references
* Fix gradients
Change-Id: I92c2050ab0fb327649ea1eff4adec973d2073944
Reviewed-by: Thomas Hartmann <Thomas.Hartmann@digia.com>
Reviewed-by: hjk <hjk121@nokiamail.com>
... to the editor factories and pass it to the document, not the widget.
Saves some code, puts fewer objects into the object pool.
Change-Id: Iaaf250af74dc4e0c62700873accbb40ba88b7d9e
Reviewed-by: Christian Stenger <christian.stenger@digia.com>
Reviewed-by: David Schulz <david.schulz@digia.com>
The editor factories are already a central place to associate
hover handlers with editors, no need to retrieve them later from
the object pool again. This also allows for easy handling of
more than one active handler per editor.
Change-Id: Ie716b96f5ce6b526ee897468635e03e909d81538
Reviewed-by: David Schulz <david.schulz@digia.com>
... and some of the related implementation details
Change-Id: I1f03aa5acf2d3fb2cfc2a6a7845f3d3578b0408d
Reviewed-by: David Schulz <david.schulz@digia.com>
First step of some more 'Base' removal in TextEditor.
s/Core::TextDocument/Core::BaseTextDocument/
s/TextEditor::BaseTextDocument/TextEditor::TextDocument/
Change-Id: I71ba325a2f0ad72ec9dae0d96846cbae72d326f7
Reviewed-by: hjk <hjk121@nokiamail.com>
opt-out now, for all editors created by BaseTextEditorFactories.
Change-Id: I01d0a9ff26320fcd0b84ff90ff22c747cf84b84c
Reviewed-by: hjk <hjk121@nokiamail.com>
Only used there, and avoids back-links to editors.
Change-Id: I81206057ce89d42aef7febb840cf9e44b869df0e
Reviewed-by: Christian Stenger <christian.stenger@digia.com>
This removes the ones that were not to be used anymore.
The fallback in the base class is left in for now.
Change-Id: I5e7ab16497a83eff9b11deb9e1feb390757eac0e
Reviewed-by: Christian Stenger <christian.stenger@digia.com>
Use a BaseEditorFactory derived class, move some code around.
Change-Id: I051ae55d106610ca818abdd3a5f6fd9f17131af2
Reviewed-by: Christian Stenger <christian.stenger@digia.com>
In preparation of moving the .pro editor over to new
editor construction scheme.
Change-Id: I429683c523e22bf874e25528eb7d9c13c7989628
Reviewed-by: Christian Stenger <christian.stenger@digia.com>
All editors did that manually, with varying approaches. Connect once
when the document is made known to the EditorWidget instead.
Change-Id: Ib0828b08158539859f6f89c8080435a027aa06ed
Reviewed-by: Christian Stenger <christian.stenger@digia.com>
In most cases, the *Editor constructor does not need to
access the *EditorWidget.
Change-Id: I1f5c076a0f723d5d82b398e8c250c7bd1d47eb17
Reviewed-by: Christian Stenger <christian.stenger@digia.com>
There was document(), textDocument() and baseTextDocument().
Two should be enough...
Change-Id: Id9e41c8d857c5cb3269a9fce5ab594d34448c982
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
In case of the CppEditor a direct member is not possible due
to setup restrictions inside the CppEditor machinery. I'd expect
that to be fixable when the editor base system is in good shape.
Change-Id: I184e219ca2dff6f67c9b58c182212eb12972cc84
Reviewed-by: Christian Stenger <christian.stenger@digia.com>
No need for most of the machinery.
Change-Id: I9078174582d83da94c6c7f20282fd3a5f1742911
Reviewed-by: Christian Stenger <christian.stenger@digia.com>
Reviewed-by: hjk <hjk121@nokiamail.com>
Also when duplicating editors, we don't want to change the document
after construction. Actually at some places (e.g. CppEditorSupport
creation) we don't handle document changes correctly, and we are only
lucky that things still (more or less?) work. Get rid of
BaseTextEditorWidget::duplicateFrom and use copy-constructor style instead.
Change-Id: I7f688b7fcc51d1bb5e222bb333f0d28479b597a6
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
First step in never changing the text document after construction,
because that is actually not really supported.
Second step will be to fix that for the editor duplicate() methods too.
Change-Id: I3d112ba0895e7ee7ac6dd8ae2318f0de7d2cebc9
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
Can be set directly from the document constructor, no need to do that
later.
Change-Id: I4326757e1b1cb1e48c157c4b330ccb2abb8f3b1f
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
It was never called with a sensible value anyhow, and only complicates things.
Change-Id: I005848700b6c00114d91495670d4a0e15a2d2e64
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Doesn't really make sense to have the additional IDocument *editorDocument()
method.
Change-Id: I0a7420eb1afaa76f63c3f7e9c4b373acf624ffb9
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
The action handler already knows which editors to handle through the
context. It only needs to receive signals for updating the actions from
the current editor. So there is no need to tell the action handler about
every individual editor. This also removes some noise from the text
editor implementations.
Change-Id: I76dc5b1559cc8cf54ff313e6cdba4e789a3108aa
Reviewed-by: David Schulz <david.schulz@digia.com>
