@b4n commented on this pull request.

In data/geany-3.0.css:

> @@ -1,10 +0,0 @@
-@import "geany.css";
-
-/* make close button on the editor's tabs smaller */
-#geany-close-tab-button {
-	-GtkWidget-focus-padding: 0;
-	-GtkWidget-focus-line-width: 0;
-	-GtkButton-default-border: 0;
-	-GtkButton-default-outside-border: 0;
-	-GtkButton-inner-border: 0;
-}

IIUC this was conditional and not loaded on 3.20 because it was redundant, and would possibly lead to runtime deprecation warnings. Why drop it?

In src/ui_utils.c:

>  	}
 
-	g_object_unref(css);
-	g_free(css_file);
-#else
-	/* see setup_gtk2_styles() in main.c */
+	// if the user provided a geany.css file in their config dir, try and load that

Do we really need that? Isn't ~/.config/gtk-3.0/gtk.css enough? AFAIK all our styles can easily be applied to Geany only, so I don't see why we'd need extra stuff?

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
+are applied to allow overriding the default styles.
+
+Geany offers a number of CSS classes which can be overridden to taylor its

Those are CSS IDs (#name), not classes (.name)

In src/msgwindow.c:

> @@ -83,6 +83,11 @@ enum
 };
 
 
+static GdkColor color_error = {0, 65535, 0, 0};
+static GdkColor color_context = {0, 65535 / 2, 0, 0};
+static GdkColor color_message = {0, 0, 0, 0xD000};

different literals look odd, I'd rather use 0xFFFF and 0x7FFF

In src/ui_utils.c:

> @@ -2097,7 +2097,9 @@ static void on_config_file_clicked(GtkWidget *widget, gpointer user_data)
 		if (g_file_test(global_file, G_FILE_TEST_EXISTS))
 			g_file_get_contents(global_file, &global_content, NULL, NULL);
 
-		document_new_file(utf8_filename, ft, global_content);
+		// open or create the document and mark it as changed if it didn't already exist
+		GeanyDocument *doc = document_new_file(utf8_filename, ft, global_content);
+		document_set_text_changed(doc, ! g_file_test(file_name, G_FILE_TEST_EXISTS));

Why? saving an empty file, or a copy of the system version, doesn't seem to useful?

In data/geany.css:

> @@ -36,6 +36,17 @@
 	color: #007f00;
 }
 
+/* compiler message colors */
+#geany-compiler-error {
+    color: #ff0000;
+}
+#geany-compiler-context {
+    color: #880000;

shouldn't that be 0x7f0000 to be the same as the hardcoded one? Not that it matters too much though, I don't imagine anybody will really see the difference

In data/geany.gtkrc:

> @@ -50,5 +50,22 @@ widget "*.geany-document-status-changed" style "geany-document-status-changed-st
 widget "*.geany-document-status-disk-changed" style "geany-document-status-disk-changed-style"
 widget "*.geany-document-status-readonly" style "geany-document-status-readonly-style"
 
+# compiler message colors
+style "geany-compiler-error-style" {
+    fg[NORMAL] = "#ffff00000000"
+    fg[ACTIVE] = "#ffff00000000"
+}
+style "geany-compiler-context-style" {
+    fg[NORMAL] = "#888800000000"
+    fg[ACTIVE] = "#888800000000"

same pickyness than for the GTK3 variant, for me 65535 / 2 is 7fff

In src/msgwindow.c:

>  	switch (msg_color)
 	{
 		case COLOR_RED: return &color_error;
-		case COLOR_DARK_RED: return &dark_red;
-		case COLOR_BLUE: return &blue;
+		case COLOR_DARK_RED: return &color_context;
+		case COLOR_BLUE: return &color_message;

We really should rename those color names someday to something semantic. But well.

In src/msgwindow.c:

> @@ -83,6 +83,11 @@ enum
 };
 
 
+static GdkColor color_error = {0, 65535, 0, 0};
+static GdkColor color_context = {0, 65535 / 2, 0, 0};
+static GdkColor color_message = {0, 0, 0, 0xD000};

OK I see it comes from the old code. Well, as you want then, but could be the occasion to make that less odd :)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.