Optimise status colours and icons. Closes #6174. #6186

magao · 2017-01-01T03:04:55Z

This pull request addresses issue #6174.

Swaps the colours used for the paused downloading and stalled states, and makes the stalled state use maroon for a light theme (which I find easier to read).

The reasoning here is that paused downloading is a "normal" state, whereas stalled is a "warning" state, so the colours should reflect that.

Chocobo1 · 2017-01-02T06:04:38Z

@magao
Could you post a screenshot?

magao · 2017-01-03T01:04:44Z

I'm not sure how to make it use the dark theme colours - changing my theme in Mint Mate to a dark one didn't appear to do it.

magao · 2017-01-03T21:20:28Z

Urgh! That requires getting qBittorrent compiling on Windows ... definitely not the trivial task it is on Linux and something I was hoping to avoid.

On the plus side, my Windows machine should be much faster at compiling than my qBittorrent Linux VM.

Any chance someone who already has a Windows compile setup or dark theme could fork and pull this changeset and post a screenshot? If not, I'll see if I can set it up on the weekend.

thalieht · 2017-01-05T14:01:17Z

Breeze dark theme

magao · 2017-01-05T19:37:18Z

Thanks!

Would you be able to change it to use maroon for the dark theme as well so we can compare? I suspect maroon will be too dark.

thalieht · 2017-01-05T20:48:00Z

Indeed

thalieht · 2017-01-05T23:10:14Z

You could use something like http://contrastchecker.com/ to test colors if you want.

magao · 2017-01-06T01:13:12Z

OK - so I think the colours in the pull request work as they are, so it's just a question of whether the change is desirable or not.

magao · 2017-01-08T03:16:33Z

Rebased on top of #6212 and uncrustified.

magao · 2017-01-16T19:44:26Z

The new icon scheme #4253 is based on the existing colours - stalled and paused look a little weird in my build. If this PR gets merged then might want to adjust the icon colours to match.

Balls0fSteel · 2017-01-21T22:59:25Z

I am pretty sure it's impossible to find a scheme that will fit every distribution's default colors. Maybe allow color customization via the config file, so the distribution packagers can set it up correctly? Then again, that's just another added load of bloat.

magao · 2017-01-22T06:53:09Z

Rebased on top of master.

I'll see if I can work out how to change the colours of the icons to match to include in this PR, but I'm not a graphical person ...

Balls0fSteel · 2017-01-22T08:54:58Z

@magao The easiest method is using Hue/Saturation in Paint.net/GIMP. (But yeah, see my previous comment, if you match one theme/platform, it will look weird on the other one. Maybe just a new ini for the colors?)

magao · 2017-01-25T21:25:37Z

I've gone with a different approach - when loading the icons, set the icon colour to match the state colour. This will handle both light and dark themes. Doesn't require any changes to the icon files - just creates a new solid-colour pixmap masked by the transparent pixels.

I've also got an alternative that I prefer that I've included in the PR for discussion (72399d3) - inverting the icons. This also doesn't require any changes to the icon files (just inverts the mask).

If you like 1ea2539 and aren't sure about the others yet (or don't want them) I can split 1ea2539 out into its own PR.

@Balls0fSteel Whilst I think allowing customisation of the colours might be a nice feature, I think it's outside the scope of this PR (but 1ea2539 would be a step towards it as then the icons will follow the customised colours).

magao · 2017-01-26T00:39:14Z

Interesting - I just realised that my change doesn't invert the status icons in the sidebar (I don't normally display them). I'll work out how to fix that and re-push.

Although if this is desirable then the icon files themselves should be changed IMO - this would only be a stopgap.

magao · 2017-01-26T02:56:00Z

I've got a new series of commits (not pushed to github yet) which I could either leave as a single PR, or split them up. This PR should not be merged in its current state. In the options below, if the final one is where we want to end up then I think it would be best to just have everything in this single PR.

For the transfer filter list, I've special-cased All to use the same colour as in the icon file (since there's no corresponding torrent state). All other filters use the colour from one of the torrent states. Resumed and Active use the same colour as Downloading, Inactive uses the same colour as Stalled Downloading.

The following are all on a light theme - the screenshots in earlier comments show what would happen for a dark theme (in particular, Paused will be Gray 80 and Inactive will be Salmon).

Original state colours, current icons

Modified state colours, current icons

Original state colours, inverted icons

Modified state colours, inverted icons (this is what I'll be using no matter the decision)

Balls0fSteel · 2017-01-26T08:51:53Z

@magao Very nice job. 👍

magao · 2017-01-26T12:26:19Z

Note that this doesn't change anything for the web UI - the icon files will need to be changed for that (or an equivalent to what I've done be implemented in javascript).

zeule · 2017-01-26T14:08:31Z

While joining the others who like the icons look, I would like to raise a couple of concerns regarding the code in this PR.

You, in fact, use a singleton to manage all the icons, but you do it implicitly, and this is not good. One can benefit from a proper implementation. For example, it can be used in the web UI as well. A singleton

class Skin {
public:
    QIcon icon(SkinIconEnum icon); // or maybe QString &iconName
    QIcon stateIcon(TorrentState state);
    QColor stateColor(TorrentState state)
};

might be a much cleaner solution. Perhaps you wanted to change the current code as little as possible, but your changes make the code even uglier. Plus, your code can not react to colour theme changes in principle. While now icons are readable when switching from light to dark colour theme (and vise-versa), with these changes reading them would become problematic.

Replacing colours in pixmaps will lead to problems if an icon is rendered with anti-aliasing (you kill it). At least I do see the icons in this PR aliased on 128 DPI screen. It would be much better to replace colours in SVG and render an icon afterwards.

My suggestion, therefore, is to implement the aforementioned Skin singleton, edit SVG skin icons to make them monochrome with simple colours (e.g. black on transparent) and then do simple text replacement (without fiddling around with Qt's SVG modules).

magao · 2017-01-26T20:56:21Z

I've worked out how to change the original SVG files (externally) to invert them (using masks - thank you text-based graphics format). So I'll do that (and modify the colours to match my new light theme) and then use the instructions to regenerate the PNG files.

@evsh Could you post a screenshot of both the icons on a dark theme, and with anti-aliasing artifacts? I may be able to find a method of doing the fill without the artifacts.

I think making more drastic changes such as how the caching works (i.e. allowing swapping between light and dark themes dynamically) needs to be a separate issue. For example, the transfer filter list is only built once - we would need to detect the theme change and then rebuild the transfer filter list.

If the code is to be refactored, it should probably be done by someone who has a better grasp of the whole picture. For example, I have no idea how the web UI fits in other than the image files being used. That's the main reason I want to have as light a touch as possible.

magao · 2017-01-26T22:27:20Z

WebUI with modified icons - inverted and matching new state colours.

Does the WebUI support dark themes? I did a text search for "dark" and the only thing I could find was in progressbar.js which seems unrelated.

zeule · 2017-01-27T00:41:17Z

@evsh Could you post a screenshot of both the icons on a dark theme, and with anti-aliasing artifacts?

Here is the screenshot, please:

I have to admit that I was wrong regarding the antialiasing: the original icons are 256 by 256 pixels and that is enough when downscaling. What I do see is the absence of the sub-pixel rendering (compare with the letters at the right). But that is a completely different story.

P.S. Most of my torrents are in stalled state. Therefore, I would prefer a neutral colour for them, but now it is too reddish.

magao · 2017-01-27T01:09:46Z

@evsh I do feel that the Salmon is too light. It used to be used for paused as you can see in my earlier comments, and changing that was the whole point of this PR. I think we need some red in it, and I like the Maroon for the light theme, but we'd need something better for the dark theme then (as can also be seen in earlier comments, Maroon is too dark).

You're probably best placed to come up with a colour you like on a dark theme. The good thing is that with the PR in its current state you can experiment just by modifying TorrentModel::getColorByState(). Post a screenshot with your preference (+ the RGB values).

I'm glad the antialiasing isn't a problem - I was afraid that QPixmap was doing something weird when I made the masked solid colour. I'm not surprised there's no sub-pixel antialiasing as that's usually only a feature of the font system (but maybe there's a flag for Qt to do it for icons ... I'll have a look).

This looks relevant (though still talking about text):
https://bugreports.qt.io/browse/QTBUG-22334

I see that your stalled torrents are uploading. That's not really an undesirable condition (unlike stalled downloading) - just means no one is leeching. So maybe we should give stalled uploading the same colour as uploading?

magao · 2017-01-27T01:13:34Z

@LordNyriox I'll compare your SVG files with mine, and take the simplest (e.g. if yours aren't done with masking, that's probably simpler for someone else to modify in the future).

Just took a look ... Inkscape added a lot of gunk to the files ... maybe I can combine the 2 sets by just taking the paths from yours ...

zeule · 2017-01-27T02:04:07Z

My point is: the most common status (stalled) should be mapped to a neutral colour (a shade of grey). I use my own modification (#3936) for the colour theme cause I don't think a single set of colours can satisfy everyone. That is why my only suggestion is to be conservative: as little different colours as possible and prefer low saturated ones, especially for elements that fill a significant part of a window.

Update: and please bear in mind that on a dark background colours look more saturated than on a light one.

magao · 2017-01-27T02:36:40Z

@evsh Your most common status (stalled) is different to my most common status (paused). In my case, I have a lot of RSS filtering, and I have all torrents paused by default so I can pick and choose (there's often several options available). As you said, no theme is going to satisfy everyone.

Stalled uploading is generally an inconsequential status, and so IMO should be either a neutral colour or the same as active uploading (royal blue on light theme, steel blue on dark theme). I'm going to implement having both uploading states be the same in my next version of the PR.

Edit: tried this, disconnected my VPN, started seeding but for some reason it stayed in Seeding instead of Stalled Uploading - with zero traffic.

Stalled downloading is almost always undesirable e.g. if all my torrents are stalled downloading for a while it might indicate that my VPN connection has gone down. I think it definitely deserves a warning colour (i.e. reddish).

Note that there are cases that stalled uploading could indicate a problem (e.g. a networking issue).

zeule · 2017-01-27T02:45:45Z

@sledgehammer999, would you accept a PR which implements skin colours selection by a user adding a new options page "Appearance" (possibly merging with #6196)?

zeule · 2017-02-06T08:09:08Z

src/base/iconprovider.cpp

@@ -35,7 +36,9 @@ IconProvider::IconProvider(QObject *parent)
 {
 }

-IconProvider::~IconProvider() {}
+IconProvider::~IconProvider()


Why don't we put = default here and in GuiProvider?

I don't understand. This was just a reformatting via uncrustify. Same for other places you've mentioned this.

I see what you mean though - c++11 = default. Still catching up on c++11 - much of this stuff wasn't around last time I used c++ (~10 years ago). And it's been over 20 years since I hung around on comp.std.c++ :)

zeule · 2017-02-06T08:10:51Z

src/gui/guiiconprovider.h

    static void initInstance();
    static GuiIconProvider *instance();

+    int getThemeFlags();


QFlags<ThemeFlags>?

Again, didn't know what to look for. Thanks.

zeule · 2017-02-06T08:12:35Z

src/gui/guiiconprovider.h

+    enum ThemeFlags
+    {
+        LightTheme = 1,
+        DarkTheme = 2,


There should be only one from each pair (Dark or Light, Large or Small), because one can not have both set or cleared at a time.

~~Yep.~~ Not exactly. I needed to be able to distinguish between not yet knowing the theme or icon size. But if I can hook into the events (configure does it for the icon size) then that's not an issue.

zeule · 2017-02-06T08:22:03Z

src/gui/guiiconprovider.cpp

+{
+    static int cachedIconFlags = 0;
+    static QHash<QPair<QString, BitTorrent::TorrentState>, QIcon> cache;
+    int theme = getThemeFlags();


Why on every icon request? Why don't you handle QEvent::PaletteChange?

Because that's how the dark theme was detected previously, and I simply extended it. Didn't know about QEvent::PaletteChange - I tried to find some event that would indicate a theme change but didn't know what to look for.

Now I'll see about hooking into it.

Not sure how to hook it. GuiIconProvider doesn't have a parent, so it doesn't seem to receive events.

I'm wondering if maybe mainwindow should notice QEvent::ApplicationPaletteChange and then forward it as a Preferences::changed() signal - or maybe a new Preferences::themeChanged signal.

I would catch that event in the application object. Like the Preferences::themeChanged signal.

My current prototype does that, except it's caught in MainWindow::event() which already existed.

zeule · 2017-02-06T08:27:06Z

src/gui/guiiconprovider.cpp

+        return icon;
+
+    QPixmap pixmap(path);
+    QPixmap &iconPixmap(pixmap);


what was that?

Reference to pixmap which may be reassigned to colored below, rather than unnecessarily copying objects. But I think I messed it up as colored goes out of scope ...

And I introduced a bug when I fixed up the #ifdef stuff so it didn't resize ...

which may be reassigned to colored below, rather than unnecessarily copying objects.

This is wrong in C++. One needs a pointer for this kind of things.

Yes - as I updated my comment, I messed this up. A reference is actually usable for it - the problem was referencing (or pointing to) an object that went out of scope ... I've fixed this in my not-yet-pushed version.

In C++ a reference can not be reassigned, that is what I wanted to say.

Yes - now I think about it further, which I think was happening is that operator=() was being called (hence safe, but no performance advantage).

So many potential gotchas in C++ - it's no wonder I prefer python these days :)

zeule · 2017-02-06T10:20:25Z

src/base/iconprovider.h

@@ -43,7 +44,7 @@ class IconProvider : public QObject
    static void freeInstance();
    static IconProvider *instance();

-    virtual QString getIconPath(const QString &iconId);
+    virtual QString getIconPath(const QString &iconId, const QString &overrideTheme = QString());


Don't like this API. And don't like the fact that our icons are split onto two parts while they naturally form the single theme. UNIX users would benefit from merging them together and distributing them as individual files but not resources. Perhaps we better merge these icons into the main theme right away (for instance into a subdir "status", as per FDO specification)? Because the proposed API looks like it allows to mix icons from different themes, which shall not happen and certainly may not be encouraged by an API.

I wasn't intending to change the file layout at all, but there is already a src/icons/flags/ directory, so there's precedence for doing this.

@sledgehammer999 Do you want me to reorganise so there's a src/icons/status/ directory?

zeule · 2017-02-06T10:20:51Z

src/base/preferences.cpp


-Preferences::Preferences() {}
+Preferences::Preferences()


= default too?

zeule · 2017-02-06T10:54:14Z

src/gui/guiiconprovider.cpp

 #endif

-QString GuiIconProvider::getIconPath(const QString &iconId)
+QString GuiIconProvider::getIconPath(const QString &iconId, const QString &overrideTheme)


Your changes seem to need a rebasing on top of the current master (the signature of this function is old).

This was after rebasing, and I didn't see any changes. Will become moot if @sledgehammer999 wants me to reorganise the icon hierarchy.

My bad, this is another function.

zeule · 2017-02-06T10:57:02Z

src/gui/torrentmodel.h

@@ -33,15 +34,20 @@
 #define TORRENTMODEL_H

 #include <QAbstractListModel>
+#include <QColor>
+#include <QIcon>
+#include <QPixmap>


Alphabetical order?

https://github.com/qbittorrent/qBittorrent/blob/master/CODING_GUIDELINES.md#8-header-inclusion-order

Oh - <QList> is out of order - is that what you meant?

zeule · 2017-02-06T11:01:42Z

src/gui/torrentmodel.h

 #include <QList>

+#include "base/bittorrent/torrenthandle.h"


You are adding a bunch of libtorrent headers for the sake of what? Those static functions below do not need access to the private members of the class. Then why?

So that BitTorrent::TorrentState is a complete type. But I could get around that by the parameter instead being const BitTorrent::TorrentState & - then a forward declaration would be enough. Because TorrentState isn't actually an enum as I just realised ...

I was wondering are these function need to be in the class interface. BTW, you may make TorrentState an enum class with explicit underlying type and then forward declare it, eliminating the include.

magao · 2017-02-07T21:03:34Z

@LordNyriox My current prototype removes the direct manipulation of mainwindow and replaces it with capturing the palette change and forwarding a signal. The widgets then connect to that signal and update their icons.

zeule · 2017-02-07T21:26:12Z

My current prototype...

Eager to see it :)

--HG-- branch : magao-dev

magao · 2017-02-08T06:12:19Z

@sledgehammer999 @evsh @LordNyriox @Chocobo1 Rebased on top of master and hopefully addressed all comments (either in discussion or code).

I've included commit 417ec61 which moves the status icons out to their own directory - let me know if you don't want it @sledgehammer999 and I'll remove it from the PR.

I've simplified the API somewhat, and in particular IconProvider::getIconPath() no longer takes an optional parameter. Instead, the icon path is hard-coded to :icons/skin/ (or :/icons/status/ with 417ec61).

Theme detection now takes place in GuiIconProvider::configure(), which emits GuiIconProvider::themeChanged() if there actually was a change. This will either be called from MainWindow::event() (via GuiIconProvider::updateTheme()) in response to a palette change, or due to a Preferences::changed() signal (for small/large status icons). Anything which needs to be notified of a theme change simply connects to GuiIconProvider::themeChanged().

BTW I've kept the "large" status icon terminology as the current votes are currently 2 in favour (@magao, @LordNyriox) to 1 against (@evsh).

I've also used static const QLatin1String and QColor inside TorrentModel::getIconId() and TorrentModel::getColorByState(). I think it makes the code more self-documenting (and potentially slightly more efficient, though unlikely to be significant).

At one point this was a simple 6-line PR ...

zeule · 2017-02-08T10:20:12Z

src/gui/guiiconprovider.cpp

+#include <QApplication>
+#include <QBitmap>
+#include <QDebug>
+#include <QEvent>


Had not found where this include is used in the code. Is it needed at all?

Leftover from my prototype.

zeule · 2017-02-08T13:49:38Z

src/gui/guiiconprovider.h

 #include "base/iconprovider.h"

+class QEvent;


Leftover from my prototype.

zeule · 2017-02-08T13:49:54Z

src/gui/guiiconprovider.h

 class QIcon;
+template <class T, class U> class QPair;


template <class T, class U> struct QPair;

zeule · 2017-02-08T14:10:28Z

src/gui/optionsdlg.ui

@@ -213,6 +213,16 @@
                </widget>
               </item>
               <item>
+                <widget class="QCheckBox" name="checkLargeStatusIcons">


Does this little tune really belong to the main options page? I would put it into the advanced page (where we have some icons-related settings already).

I thought about that, but the transfer list UI options seemed like an obvious place for it. It's about as significant as hiding zero and infinity values IMO.

zeule · 2017-02-08T14:14:06Z

src/gui/torrentmodel.h

@@ -33,15 +34,19 @@
 #define TORRENTMODEL_H

 #include <QAbstractListModel>
+#include <QColor>


All these new includes are unneeded. You can forward declare these classes and move the includes into the .cpp file.

I was thinking that because they were being returned from functions they needed to be complete types. But you can declare functions which accept or return incomplete types. Rusty C++.

https://stackoverflow.com/questions/553682/when-can-i-use-a-forward-declaration

zeule · 2017-02-08T14:17:36Z

src/gui/transferlistfilterswidget.h

@@ -88,6 +90,8 @@ private slots:
    virtual void applyFilter(int row);
    virtual void handleNewTorrent(BitTorrent::TorrentHandle *const);
    virtual void torrentAboutToBeDeleted(BitTorrent::TorrentHandle *const);
+
+    int m_currentThemeFlags;


Whoops - forgot to remove this.

zeule · 2017-02-08T14:29:36Z

At one point this was a simple 6-line PR ...

BTW, there is an unanswered question from that times: this PR floods the main window with a lot of bright colours, effectively colourising all the strings in the torrent list, not only making them hard to read, but also making the main window look tasteless.

I again suggest to colourise only the torrents that are in an active state which implies quick changes, i.e. those under checksum computations and maybe actively downloaded and the ones with errors. For the rest of them leave a neutral text and colourise icons only.

magao · 2017-02-08T20:46:06Z

BTW, there is an unanswered question from that times: this PR floods the main window with a lot of bright colours, effectively colourising all the strings in the torrent list, not only making them hard to read, but also making the main window look tasteless.

In my main window, it massively reduces the amount of colour as all the paused torrents go from salmon -> black.

I changed StalledUploading to be the same colour as Uploading - did that not fix your problem? If not, what state are the torrents in that you're complaining about?

I would suggest that once this is eventually merged you create a PR with your suggested changes. It would need a separate TorrentModel::getIconColorByState() I would think.

Or thinking about this further - maybe have all the text neutral, and just rely on the icon colour?

I've currently got both versions side-by-side (light theme), and I think I like the text being coloured.

sledgehammer999 · 2017-02-08T21:03:45Z

Let me say, that I didn't read any of this while it happened. So the discussion is pretty huge for me. I skimmed through it and I realize that it involves changes to font colors, icons(shape and color) and skins?

So @magao can you give me a summary on what is happening here?

magao · 2017-02-08T21:39:15Z

@sledgehammer999 As the PR currently stands:

Torrent state colour changes (the original PR with some modifications):

Paused -> black/gray 80
Stalled Downloading -> maroon/salmon
Stalled Uploading -> royal blue/steel blue 1 (same as uploading)

The idea is that stalled downloading indicates an undesirable state (e.g. you're not receiving data, so may wish to switch to a different torrent), whereas paused is a normal state and stalled uploading probably just indicates no one leeching (not sure if that's the case though).

But see earlier comment.

Torrent status icons have been inverted - screenshots (thought the actual method of doing it has changed since).
Recoloured the icon files to match the new light theme states so they display correctly in the web UI - screenshot.
Torrent status icons are modified in-memory to be the same colour as the text - screenshot (though doesn't actually show the text).
Dark/light theme is detected and the icons switched to the corresponding colours automatically (the text was already changing) - screenshot.
Option in the preferences to display larger version of the status icons (mainly for people with hi-DPI screens). The icons are modified in-memory by trimming off excess transparent space. Same screenshot as (5).

Note: I've though about reversing this - make the icons files be the larger size, then add transparent space in memory. That way we wouldn't be relying on the amount of excess space in the icon files. Thoughts? One issue is that the icons would then always be larger in the web UI.

Moved the status icon files into their own directory src/icons/status (waiting on your decision).

--HG-- branch : magao-dev

magao · 2017-02-08T22:20:38Z

@sledgehammer999 @evsh @LordNyriox @Chocobo1 Rebased on top of master. Addressed review comments. Top two commits are for discussion:

beb94e9: status icons in own directory
4a571de: all text in torrent list black (light theme) or gray 80 (dark theme).

sledgehammer999 · 2017-02-08T22:49:29Z

Quick review from your #6186 (comment):
I think I like the icon changes. The font color changes, I am not so sure.
In any case, I want to focus on some other PRs this week and the next one. So don't wonder why I won't comment on this PR.

magao · 2017-02-08T22:59:03Z

If I create the Appearance options tab as discussed in PR #6196 then the issue could become moot by having options to override the colours.

sledgehammer999 · 2017-02-08T23:01:01Z

If I create the Appearance options tab as discussed in PR #6196 then the issue could become moot by having options to override the colours.

True. So we can keep the current defaults and user can change them.

magao · 2017-02-08T23:07:56Z

True. So we can keep the current defaults and user can change them.

In that case do you want me to resubmit this PR without the colour change, and if so do you want the status icons in their own directory? I think at that point it should be ready for merging.

sledgehammer999 · 2017-02-08T23:14:05Z

In that case do you want me to resubmit this PR without the colour change, and if so do you want the status icons in their own directory? I think at that point it should be ready for merging.

For the moment keep it as it is. Let's see how the Appearance tab implementation will go.

zeule · 2017-02-09T00:49:29Z

4a571de: all text in torrent list black (light theme) or gray 80 (dark theme).

To me, the new look is superb (with smaller icons)!

ghost · 2017-05-14T09:36:35Z

Will this be ready for 3.4?

glassez · 2019-08-10T20:01:44Z

What is the status of this PR? Is it still relevant?

magao force-pushed the issue6174 branch from 23e6fd9 to 8b417a3 Compare January 8, 2017 03:16

magao force-pushed the issue6174 branch from 8b417a3 to 7d04518 Compare January 22, 2017 06:52

magao force-pushed the issue6174 branch from 7d04518 to 72399d3 Compare January 25, 2017 20:59

zeule suggested changes Feb 6, 2017

View reviewed changes

Move status icons to own directory.

beb94e9

--HG-- branch : magao-dev

magao force-pushed the issue6174 branch 3 times, most recently from 789e295 to 417ec61 Compare February 8, 2017 06:06

zeule suggested changes Feb 8, 2017

View reviewed changes

sledgehammer999 mentioned this pull request Feb 8, 2017

Changeable fonts in torrent list, torrent properties and execution log. #6196

Closed

Torrent state text always neutral (black or grey).

4a571de

--HG-- branch : magao-dev

magao force-pushed the issue6174 branch from 417ec61 to 4a571de Compare February 8, 2017 22:17

zeule mentioned this pull request Feb 8, 2017

Configurable UI appearance and corresponding options page #6363

Closed

LordNyriox approved these changes Apr 21, 2017

View reviewed changes

zeule mentioned this pull request Apr 26, 2017

Color and font themes #6698

Closed

12 tasks

LordNyriox mentioned this pull request May 25, 2017

Steps for version 3.4 release #6767

Closed

glassez closed this Nov 3, 2019


		Preferences::Preferences() {}
		Preferences::Preferences()

Optimise status colours and icons. Closes #6174. #6186

Optimise status colours and icons. Closes #6174. #6186

Conversation

magao commented Jan 1, 2017

Chocobo1 commented Jan 2, 2017

magao commented Jan 3, 2017

magao commented Jan 3, 2017 • edited

thalieht commented Jan 5, 2017

magao commented Jan 5, 2017

thalieht commented Jan 5, 2017

thalieht commented Jan 5, 2017

magao commented Jan 6, 2017

magao commented Jan 8, 2017

magao commented Jan 16, 2017

Balls0fSteel commented Jan 21, 2017

magao commented Jan 22, 2017

Balls0fSteel commented Jan 22, 2017

magao commented Jan 25, 2017 • edited

magao commented Jan 26, 2017 • edited

magao commented Jan 26, 2017 • edited

Balls0fSteel commented Jan 26, 2017

magao commented Jan 26, 2017

zeule commented Jan 26, 2017 • edited

magao commented Jan 26, 2017 • edited

magao commented Jan 26, 2017

zeule commented Jan 27, 2017

magao commented Jan 27, 2017 • edited

magao commented Jan 27, 2017 • edited

zeule commented Jan 27, 2017 • edited

magao commented Jan 27, 2017 • edited

zeule commented Jan 27, 2017

Choose a reason for hiding this comment

magao Feb 7, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

magao Feb 7, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

magao Feb 7, 2017 • edited

Choose a reason for hiding this comment

magao Feb 7, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

magao Feb 7, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

magao Feb 7, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

magao commented Feb 7, 2017

zeule commented Feb 7, 2017

magao commented Feb 8, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

magao commented Jan 3, 2017 •

edited

magao commented Jan 25, 2017 •

edited

magao commented Jan 26, 2017 •

edited

magao commented Jan 26, 2017 •

edited

zeule commented Jan 26, 2017 •

edited

magao commented Jan 26, 2017 •

edited

magao commented Jan 27, 2017 •

edited

magao commented Jan 27, 2017 •

edited

zeule commented Jan 27, 2017 •

edited

magao commented Jan 27, 2017 •

edited

magao Feb 7, 2017 •

edited

magao Feb 7, 2017 •

edited

magao Feb 7, 2017 •

edited

magao Feb 7, 2017 •

edited

magao Feb 7, 2017 •

edited

magao Feb 7, 2017 •

edited

magao commented Feb 8, 2017 •

edited

magao commented Feb 8, 2017 •

edited