Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

qBittorrent icons on macOS #6957

Closed
vit9696 opened this issue Jun 13, 2017 · 15 comments
Closed

qBittorrent icons on macOS #6957

vit9696 opened this issue Jun 13, 2017 · 15 comments
Labels
autoCloseOldIssue OS: macOS Issues specific to macOS

Comments

@vit9696
Copy link
Contributor

vit9696 commented Jun 13, 2017

Following the discussion in #6952 I would like to get some opinions in regards to qBittorrent icon usage on macOS. Below follows my personal opinion, so please do not take it heartly :)

The current version of qBittorrent, which is 3.3.13, uses the icon set that causes nothing but eye cancer when one looks at it on the mac — screenshot. It may not be bad, it is just unsuitable for the design of the operating system.

Fortunately the current trunk version of qBittorrent offers the toolbar and preferences icons with much dimmer colours (screenshot 1 and screenshot 2), and thus looks by far better. (Notably #6952 changes are applied to eliminate a ton of other issues).

However, there still are certain major icon issues even with the new set.

  1. Sidebar icons are simply unreadable when selected (example 1, example 2).
  2. Statusbar icons still look quite out of place, particularly with that black and red speed limiting icon in the middle (example), yellow arrow is also pretty out of place in my opinion.
  3. Torrent status icons are just as unreadable as the sidebar ones (example), and with red ones it gets even worse.

If you check this page, you will see that for most cases Apple uses greyscale and black icons for their products. I have a version with a black/greyscale iconset, and these issues are generally resolved there:

  1. For sidebar dark black icons are used, and they are just readable now: example.
  2. For statusbar the middle icon is replaced, and the rest are uncoloured except the one with connection status (green/red is a good and unintrusive idea, that quickly gives a hint on what is wrong): example.
  3. For torrent status the sidebar icons are used, so they will be automatically fixed once replaced.

These issues do not look to me like a subject of preference but careless design with bad UX (after all, you cannot like an unreadable icon), and therefore I am ready to prepare a pull request to replace all these icons by pure ifdefs for macOS.

What is a question of a preference are preferences and toolbar icons (the ones at screenshots 1 and 2 in the beginning of the post). Except the lock icon, which to me feels rather questionable in both necessity and visual appearance, the rest are not intrusive and do not feel too much outside of overall macOS look.

Personally I would prefer seeing this and this, but this feels like a matter of taste, and I think it won't be ok to replace those unconditionally unless most of the audience here agrees.

For this reason I want:
— to hear your approval in regards to fixing issues 1, 2, 3;
— to hear your opinion on toolbar/preferences icon replacement choice.

Ideally you should be a macOS user, because what looks for other operating systems often is unsuitable and looks disgusting on macOS. Thank you for understanding.

@zeule
Copy link
Contributor

zeule commented Jun 13, 2017

I'm working on this in #6698, skin icons decolonization is part of the plan.

@vit9696
Copy link
Contributor Author

vit9696 commented Jun 13, 2017

@evsh, yes, I saw it, and I am not so sure that these are related.

From what I can tell your change brings the ability to support skins, and the first 3 issues I mentioned are not really about somebody installing a custom skin into qBittorrent, but about awful default appearance on macOS.

On macOS one should hardly use any skin but the default macOS ui skin from Qt, since it more or less attempts to represent the general interface same across all the applications.

Did I misunderstand your intention somehow?

@zeule
Copy link
Contributor

zeule commented Jun 13, 2017

I saw it, and I am not so sure that these are related.

Related code is not published yet, I plan to push it out this week. I just wanted to let you know in case you plan to work on the same subject.

My plans include optional de-colorisation of all icons from the qBt bundled icon pack. Plasma also moved to monochrome icons long time ago, and since not all icons that we use can be found in standard icon theme, qBt aesthetic can be improved by making current icons monochrome.

@vit9696
Copy link
Contributor Author

vit9696 commented Jun 13, 2017

Oh, that would be great indeed.

Some icons may not be decolorised programmatically and remain properly looking though. E.g. that most annoying speed limit icon from here.

I can see it here, but somehow it has not made its way into the merge. cc @bertyhell

Do you have any plans for dealing with these tasks?

@zeule
Copy link
Contributor

zeule commented Jun 13, 2017

Yeah, that connection icon can not be handled automatically. I plan to replace it with another one. Can not find it in the #4253, could you point me, please? Or, maybe you can suggest another free icon for a replacement?

The other set of problematic icons are status icons for the search tab. I plan to borrow Breeze icons (https://github.com/KDE/breeze-icons/tree/master/icons/status/16, see "state-" ones).

@vit9696
Copy link
Contributor Author

vit9696 commented Jun 13, 2017

Looks like fifth in the first row? See this shot

The state ones look more or less fine actually =)

@zeule
Copy link
Contributor

zeule commented Jun 13, 2017

Looks like fifth in the first row?

But we need two icons for limits (we have regular and alternative limit modes).

The state ones look more or less fine actually =)

Are you talking about search tab? They are from KDE Oxygen theme, colourful as a Christmas tree.

@vit9696
Copy link
Contributor Author

vit9696 commented Jun 13, 2017

@evsh you could just flip it…? (left / right)

I am talking about the ones you suggested of course ^^;

@zeule
Copy link
Contributor

zeule commented Jun 14, 2017

you could just flip it…?

Indeed! I was so concentrated on the idea of two different icons and did not realise that the current icons are almost symmetrical.

I am talking about the ones you suggested of course ^^;

OK

@LordNyriox
Copy link
Contributor

LordNyriox commented Jun 14, 2017

@vit9696: Continuing the discussion from [#6952]:

I am a reasonably old macOS user

  1. Snow Leopard (10.6) is not that old. My first computer was a Mac G3 tower running Mac OS 8—and I first upgraded to Mac OS X in Jaguar (10.2). Most of my years running a Mac were with Tiger (10.4), on a first-generation Intel Mac Mini running a 32-bit CPU (1.66 GHz Core Duo). I did upgrade to Snow Leopard at one point, but had to take my computer to a friend of a friend to do so.

from what I remember even in the days of 10.6 colouring was not something to appear in the toolbar

  1. That depends entirely on the style of the toolbar in question. The photos you linked show buttons textured to match the window-frame—but not all toolbar buttons are designed to blend like that.

Disk Utility (first-party):
[https://i.stack.imgur.com/beo4X.png]

OnyX (third-party, very popular):
[http://download.softwsp.com/sites/12/2015/10/onyx-mac-002.png]


*EDIT:* Old comment from #6952: Regarding making the icons greyscale:
  1. For me, personally, that was one of the silliest changes in Lion. Mac OS X was so colorful that I could identify icons from color alone—then Lion comes out with its UI simplification and suddenly the only difference between sidebar icons is shape? Ugh.

  2. As for how to do it, two approaches are possible: generate a greyscale version of each icon used in Mac, and use an #ifdef to use those on Mac OS—or paint the icons grey in-process, using an #ifdef to define when to do so.

  3. If you do pursue using greyscale icons on Mac, please make it optional (perhaps reusing the Linux Use system icons option or something similar).

  4. Actually, most Mac users I know would suggest you leave the icons colored. The greyscale change was relatively recent, after all, and not all apps adhere to it (including some first-party apps, in fact). Mind you, I have not tested Sierra (only El Capitan), so I cannot speak to any UI changes it has—but I doubt I am the only one using an older and more colorful version of the OS.

  5. As for discussing this on a separate thread, go ahead! That would really be a better place to discuss such a drastic change than here.

Thanks again!

@vit9696
Copy link
Contributor Author

vit9696 commented Jun 14, 2017

@LordNyriox well, I could feel some nostalgic mood of yours, and I will likely agree that in the past macOS design was a little more thoughtful in some areas. Or probably better to say in many areas.

However, as of today I do not know any people using production systems with anything below 10.6.8. That does not mean they do not exist, but even 10.9 is no longer supported, and it was the last system that offered a somewhat similar ui to at least lion.

Your Disk Utility screenshot is outdated, it does not look like that since 10.11 if I remember correctly: screenshot.

As for OnyX, I am not sure why to suggest third-party stuff which to be frank is not very good looking, when there is a similar bar in Xcode.

Even so, the example is invalid, because what is shown is not a toolbar, but a tabbar. The difference is that the native macOS toolbar implies that you can put and/or rearrange any icons there, and this coloured tabbar is just… a tabbar, which performs tab switching, not a toolbar.

but not all toolbar buttons are designed to blend like that

Pretty much all the software updated to recent macOS versions… is designed like that. To sum it up, like it or not, but the application should stick to OS interface. Regardless of the taste of certain users, because otherwise it creates random chaos and confusion.

@thalieht
Copy link
Contributor

Have you guys finished this discussion? (Should i close it)

@thalieht thalieht added the Waiting info Waiting for participants to supply more info/fulfill template requirements label Jul 27, 2018
@vit9696
Copy link
Contributor Author

vit9696 commented Jul 27, 2018

Well, everything mentioned in the first post is still valid and pretty much a bug, although it is stated in a fairly mild way.

@thalieht
Copy link
Contributor

Oops, i didn't read it thoroughly. I thought it was a discussion about that PR you made and i assumed it's over now.

@thalieht thalieht removed the Waiting info Waiting for participants to supply more info/fulfill template requirements label Jul 27, 2018
@ngosang ngosang added the OS: macOS Issues specific to macOS label Sep 22, 2018
@sledgehammer999
Copy link
Member

This issue has been closed and locked for being too old, and thus either most likely resolved in recent versions or no longer applicable.
If you experience the reported problem or similar in the latest version, please open a new issue report with the requested information in the issue template.

A new issue report with relevant updated data gathered from the latest version is preferable to necroing an old report with a comment like "still happens in version x.y.z", even if you think the bug is the same, or suspect of a regression.
Due to the changes made to the qBittorrent code and its dependencies over time, the exact cause of your problem could be totally different than the original one, despite the visible symptoms of the bug being similar.
Thus, providing relevant updated information is crucial to find and fix the root cause of a recurrent problem or regression.

Thank you for your contributions.

@qbittorrent qbittorrent locked and limited conversation to collaborators Oct 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
autoCloseOldIssue OS: macOS Issues specific to macOS
Projects
None yet
Development

No branches or pull requests

6 participants