Adaptive UI Colors

[fjl]

This PR is supposed to make dark themes usable with Vico. I find the light gray UI elements very distracting when working with a dark theme, especially in full screen mode.

Don't merge this yet. My current plan is to do the same thing to the dividers and maybe even the sidebars. Would you accept such a change?

Without adaptive line number colors:

With adaptive number colors:

[fjl]

Ahh, just saw that I'm not the only one who wants this. Both #48 and #70 seem related.

[Shadowfiend]

Nice! It may be worth peering into what e.g. TextMate and Sublime do in these cases (i.e., do they have separate settings that set the foreground/bg color, or do they use the theme's bg for the line number bgs and the default theme foreground for the line number foreground?) and following that approach first (I see that right now we're crafting our own fg/bg based solely on whether the theme is dark or not).

Looking good though, and yes, I'm absolutely willing to accept changes like this. It's also fine to do it piecewise (i.e., one PR for line numbers, one PR for dividers, etc). I think each incremental step is better than having nothing :)

[fjl]

Sublime Text uses the color scheme background color and uses 'invisibles' or so for the foreground.

TextMate 2 has a separate key for this, it's called gutterSettings. Not all themes define this, though. The defaults are a bit more sophisticated than mine, but it does mostly the same thing.

[Shadowfiend]

What do you think about using gutterSettings if present, and if not using Sublime's approach? That seems like it would blend best, maybe?

[jordwalke]

That sounds very reasonable @Shadowfiend. This is great!

[Shadowfiend]

That said, thoughts on getting this in in current form and iterating on it? It seems like it's already usable…

[fjl]

I'm working on it. The current diff is a rough prototype. There are a few issues that need to be resolved before this can go in. (It paints over the fold view, KVO observer is not deregistered...).

I will do this during the week.

On 18 Feb 2014, at 22:30, Antonio Salazar Cardozo notifications@github.com wrote:

That said, thoughts on getting this in in current form and iterating on it? It seems like it's already usable…

— Reply to this email directly or view it on GitHub.

[Shadowfiend]

Ok, rockin'. Hadn't taken it out for a test drive yet, sorry :)

[Shadowfiend]

(The fold view is kind of nasty-sauce, not gonna lie…)

[fjl]

I believe that the ViRulerView code would become much cleaner if ViLineNumberView and ViFoldMarginView were folded :wink: into it. But that is for another time.

[Shadowfiend]

I think there's some danger there. Perhaps they should be folded in as categories or as implementors that are called from ViRulerView's draw routines (which is somewhat similar to how it's done now, but not entirely), but folding them in wholesale will lead to a view that is trying to do multiple things at once, and is therefore a bit less maintainable. But if you get a chance to play with a refactoring sometime in the future I'd love to see it :)

[jordwalke]

I would have loved to see this make its way in. Did you ever end up cleaning up the diff to your liking?

[Shadowfiend]

Was waiting to see if the original poster would reply, but it seems like no further work has been done on this as far as I can tell :/

[fjl]

I gave up working on this because my ObjC skills aren't very good.

[Shadowfiend]

Sad :/ Well, my plan is sometime in March to get back to Vico and start doing some things in Swift, so… Perhaps that will help. Not that it'll be a small undertaking hehe.

[Shadowfiend]

Didn't ever fully circle back here; closing this PR for now.