@b4n commented on this pull request.
In data/geany.gtkrc:
> @@ -56,8 +56,8 @@ style "geany-compiler-error-style" { fg[ACTIVE] = "#ffff00000000" } style "geany-compiler-context-style" { - fg[NORMAL] = "#888800000000" - fg[ACTIVE] = "#888800000000" + fg[NORMAL] = "#7f7f00000000" + fg[ACTIVE] = "#7f7f00000000"
Odd choice? AFAIK these are 3 16bits values, not 6 8bits ones. (BTW, AFAIK it's also possible to use the short 8bit values instead of the 16bits ones)
In doc/geany.txt:
> @@ -494,6 +494,27 @@ An example of a simple ``.gtkrc-2.0``:: widget "GeanyPrefsDialog" style "geanyStyle" +Customizing Geany's appearance using GTK+ 3 CSS +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To override GTK+ CSS styles, you can use traditional mechanisms or you +can create a file named ``geany.css`` in the user configuration directory +(usually ``~/.config/geany``) which will be loaded after other CSS styles
might be interesting linking http://www.geany.org/manual/#configuration-file-paths
In src/msgwindow.c:
> @@ -112,6 +117,40 @@ void msgwin_set_messages_dir(const gchar *messages_dir) } +GdkColor load_color(gchar *color_name) {
could this avoid returning an aggregate and "return" through an arg? Yeah I know it's valid C and all, but it's copying at least twice the data (well, 12 instead of 8 bytes on a Linux 64), and it's common to return "by reference" (don't lynch me :]) in such cases.
I don't mind so much, but I build with -Waggregate-return
-- and yeah, it did spot some meaningful issue once or twice (ok, in other ppl's code generally, but still)
In src/ui_utils.c:
> + theme_fn = g_build_filename(app->datadir, "geany.css", NULL); + load_css_theme(theme_fn, GTK_STYLE_PROVIDER_PRIORITY_APPLICATION); + g_free(theme_fn); + + // load themes to handle breakage between various GTK+ versions + const struct + { + guint min_version; + guint max_version; + const gchar *file; + } + css_files[] = + { + { 20, G_MAXUINT, "geany-3.20.css" }, + { 0, 19, "geany-3.0.css" }, + };
Any reason why you still change how it's loaded? I don't really mind both seem OK, but AFAIK there's no more point in changing it, and I fairly like the in-CSS flexibility of the @import
. No biggie though.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.