WebUI: Dark Colorscheme

[GlancingMind]

This should close #573

[MichaelMure]

Just a tiny thing, see my comment.

I couldn't test it as I get the following error. But as the CI look happy, it's probably something on my machine.

Cannot find module '@apollo/react-common' or its corresponding type declarations.  TS2307

    3 | 
    4 | import gql from 'graphql-tag';
  > 5 | import * as ApolloReactCommon from '@apollo/react-common';
      |                                    ^
    6 | import * as ApolloReactHooks from '@apollo/react-hooks';
    7 | 
    8 | export type CurrentIdentityQueryVariables = {};

[MichaelMure]

After fighting with npm (water is wet), I finally could test. I believe there is an issue: on the first launch when the local cache is empty, the webUI default to the dark theme, but act as if it was the light theme (see screenshot below). When clicking on the button to change the theme, we stay on the dark theme the first time.

Can you make the light theme being the default?

Also, what about a less distractive button? The red attract a lot the eye. This is a button you will click once and hopefully forget.

[GlancingMind]

Oh no! I thought I fixed this error. 😭 Will take a look at it.

[GlancingMind]

Click Problem

Unfortunately I had to drop the support for the system preferred mode 😭 (for now).
Otherwise their are state problems with the current design.
I'll try another approach while working on the colorscheme editor, which requires a more sophisticated menu and could have an option for the system default mode.

PS: The default theme is set to light.

Icon color

Don't know if this color is more pleasing, but at least it's not as eye catching as the previous one.

Or maybe 'white' to fit the git-bug logo?

[MichaelMure]

Icon color looks good to me. I'm sure a proper designer would be able to pull the perfect one but that's good enough for me.

Can you expand a bit on what this colorscheme editor is? Is that a theme editor within the webUI? If that's the case, IMHO that looks a bit like avoiding making a choice and pushing the complexity to the user.

Being able to choose what the UI looks like is generally a good idea but if you look around at commonly used products, you will see that the choice is almost always very limited. You sometimes have 2 choices for light/dark, rarely have 3 or more. There is a good reason for that: almost nobody is able to choose colors properly and care enough about it to make a custom theme. Instead, having a full theme editor within the app is pushing detrimental complexity to almost all users.

As a maintainer, I would prefer to let the community of users come up with new themes by editing the theme file (that's easy enough) if there is an actual need for that. We can later include those theme if that make sense. That's the power of free software after all. Does that make sense? (sorry if I'm shutting down another idea, trying not to!)

Completely unrelated note about the storage for the selected theme. Eventually, we might have a property in the user identity (that is, stored in git) that define what theme the user would like to use. It would then be persistent across devices and sessions (if the webUI is hosted). It could even propagate across projects and repository. In the mean time, local storage is perfect.

[GlancingMind]

Can you expand a bit on what this color scheme editor is? Is that a theme editor within the WebUI? If that's the case, IMHO that looks a bit like avoiding making a choice and pushing the complexity to the user.

Honestly the linked Issue has an overambitious description
I thought it might be beneficial to let users change the overall theme without writing a theme file themself, by exposing some color pickers for the currently used theme colors.

E.g. a small company could use git-bug internally, but adjust the theme to closer fit their company website or company logo. The person in charge of this change isn't then required to install git-bug with the dev-WebUI to change the theme. Instead they just need to open the companies git-bug instance, change the colors with the color pickers and export the theme.ts file. This file could then be given to IT department which only have to put the file in the theme directory of git-bug. This could also be used by the open source community to create themes.
So this feature is more for "none"-developer users. For those who need more control over the theme, they could still use the dev-WebUI or change the WebUI completely.

As a maintainer, I would prefer to let the community of users come up with new themes by editing the theme file (that's easy enough) if there is an actual need for that. We can later include those theme if that make sense. That's the power of free software after all. Does that make sense? (sorry if I'm shutting down another idea, trying not to!)

Yes I understand and you don't have to feel sorry. :-)
I had to propose some Issues that could be useful while still being (hopefully) possible to implement within our knowledge and deadline. Furthermore I wasn't (and still am not completely) familiar with the code-base nor with React, GraphQL, Material-UI, Go. So these Issues seemed to be approachable. On top, our course focuses on web-technology that's why I had to limit the Issues to those which might not require go.

Completely unrelated note about the storage for the selected theme. Eventually, we might have a property in the user identity (that is, stored in git) that define what theme the user would like to use. It would then be persistent across devices and sessions (if the webUI is hosted). It could even propagate across projects and repository. In the mean time, local storage is perfect.

This sound good.

[MichaelMure]

Your reasoning make sense, but I think we are optimizing for a different demographic. To me, a company is the best suited to have either the skill or the money (that is, they can pay someone) to change a free software to their needs. No need to cater to them, especially if that can be harmful to other.

Would it help if I go over your issues and point those that would make sense to have in git-bug upstream? If you invite me in your repo I can tag them.

Anyway, back to business, this PR looks good now!

[GlancingMind]

Would it help if I go over your issues and point those that would make sense to have in git-bug upstream? If you invite me in your repo I can tag them.

@MichaelMure You may if you like. I added you as contributor.
Note, that our priorities are set. But maybe we can adjust them on our next meeting.
Nonetheless I would move the remaining issues after our deadline to the official issue tracker.