Hi,
I have made some minor changes to the Color Schemes menu, I wanted to see if they look ok. One of my concerns is that maybe opening/reading each color scheme file like this might be "too slow", but it seems to only happen once, so I'm not sure whether it's significant. It "feels" fine when I use it with all of the geany-themes color schemes.
I wasn't sure how to regenerate the other formats after editing doc/geany.txt so that is not done in these patches.
Cheers, Matthew Brush
On 4 April 2011 16:54, Matthew Brush mbrush@codebrainz.ca wrote:
Hi,
I have made some minor changes to the Color Schemes menu, I wanted to see if they look ok. One of my concerns is that maybe opening/reading each color scheme file like this might be "too slow", but it seems to only happen once, so I'm not sure whether it's significant. It "feels" fine when I use it with all of the geany-themes color schemes.
I wasn't sure how to regenerate the other formats after editing doc/geany.txt so that is not done in these patches.
:-D RTFM, its in geany.txt
Do "make doc" in the doc subdirectory, you need python docutils to get the Rest tools.
Cheers Lex
On 04/04/11 00:25, Lex Trotman wrote:
On 4 April 2011 16:54, Matthew Brushmbrush@codebrainz.ca wrote:
Hi,
I have made some minor changes to the Color Schemes menu, I wanted to see if they look ok. One of my concerns is that maybe opening/reading each color scheme file like this might be "too slow", but it seems to only happen once, so I'm not sure whether it's significant. It "feels" fine when I use it with all of the geany-themes color schemes.
I wasn't sure how to regenerate the other formats after editing doc/geany.txt so that is not done in these patches.
:-D RTFM, its in geany.txt
Do "make doc" in the doc subdirectory, you need python docutils to get the Rest tools.
Sorry, I should've said "I wasn't sure how to regenerate ... without installing extra software". I did try `make doc`, but I didn't have the above mentioned software and gave up. But you're right, I didn't RTFM enough, even though I was actually even editing it :)
Cheers, Matthew Brush
On 04/03/11 23:54, Matthew Brush wrote:
I wasn't sure how to regenerate the other formats after editing doc/geany.txt so that is not done in these patches.
I've amended my last commit with the generated geany.html if this is needed. Fixed patch is attached to use instead of previous #0003.
Cheers, Matthew Brush
On 4 April 2011 17:37, Matthew Brush mbrush@codebrainz.ca wrote:
On 04/03/11 23:54, Matthew Brush wrote:
I wasn't sure how to regenerate the other formats after editing doc/geany.txt so that is not done in these patches.
I've amended my last commit with the generated geany.html if this is needed. Fixed patch is attached to use instead of previous #0003.
Yeah, we keep the geany.html in SVN updated so people just building Geany only need the C tools and not the Python tools as well.
Cheers Lex
Cheers, Matthew Brush
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Am 04.04.2011 09:37, schrieb Matthew Brush:
On 04/03/11 23:54, Matthew Brush wrote:
I wasn't sure how to regenerate the other formats after editing doc/geany.txt so that is not done in these patches.
I've amended my last commit with the generated geany.html if this is needed.
I guess adding the generated html to a patch is not needed. This can be done by the one who is submitting it to subversion.
Cheers, Frank
On Sun, 03 Apr 2011 23:54:03 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
Hi,
I have made some minor changes to the Color Schemes menu, I wanted to see if they look ok. One of my concerns is that maybe opening/reading each color scheme file like this might be "too slow", but it seems to only happen once, so I'm not sure whether it's significant. It "feels" fine when I use it with all of the geany-themes color schemes.
Sorry for the late response.
I think the color scheme menu should probably be replaced with a dialog instead. That way the color scheme files don't need to be read unless the dialog is shown. Although this is not a noticeable performance problem, I think it would be good practice to do this, and using a dialog is more flexible.
Regards, Nick
On 04/29/11 09:59, Nick Treleaven wrote:
On Sun, 03 Apr 2011 23:54:03 -0700 Matthew Brushmbrush@codebrainz.ca wrote:
Hi,
I have made some minor changes to the Color Schemes menu, I wanted to see if they look ok. One of my concerns is that maybe opening/reading each color scheme file like this might be "too slow", but it seems to only happen once, so I'm not sure whether it's significant. It "feels" fine when I use it with all of the geany-themes color schemes.
Sorry for the late response.
I think the color scheme menu should probably be replaced with a dialog instead. That way the color scheme files don't need to be read unless the dialog is shown. Although this is not a noticeable performance problem, I think it would be good practice to do this, and using a dialog is more flexible.
I have actually started a little bit with this previously, I've added a new tab under Editor tab called Colors, which has a combo box to select a theme, below that is a list view (GtkTreeView) which lists the lexer states for each theme to be edited in the list for; use default, fg color, bg color, bold, italic, underline columns in each row. So far I have only edited the glade file to add the UI elements, I wrote very little actual code for it so far. This would be quite an ambitious undertaking, which is why I didn't proceed much further yet.
Tomorrow I will try and find what I have and push a branch to at least serve as some ideas and/or starting point.
In the interim, assuming that the performance isn't an issue, and that it only occurs on load (where all the tags for open files and stuff are being loaded anyway), the main patch (0001-...) is, imo, pretty clean and low-impact, could it be applied? It's nice to see a proper name for the themes, like 'Slush and Poppies' rather than something like 'slush_and_poppies.conf' and it allows a description of the theme in the tooltip.
The main patch is applied in my 'colorschemes_fixup' branch on GitHub[1] if you want to try it out and also see the state of the merging of geany-themes into the main Geany code.
Cheers, Matthew Brush
[1] https://github.com/codebrainz/geany/tree/colorscheme_fixup
On Fri, 29 Apr 2011 23:49:00 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
I think the color scheme menu should probably be replaced with a dialog instead. That way the color scheme files don't need to be read unless the dialog is shown. Although this is not a noticeable performance problem, I think it would be good practice to do this, and using a dialog is more flexible.
I have actually started a little bit with this previously, I've added a new tab under Editor tab called Colors, which has a combo box to select a theme, below that is a list view (GtkTreeView) which lists the lexer states for each theme to be edited in the list for; use default, fg color, bg color, bold, italic, underline columns in each row. So far I have only edited the glade file to add the UI elements, I wrote very little actual code for it so far. This would be quite an ambitious undertaking, which is why I didn't proceed much further yet.
I was just thinking a dialog listing all color schemes and descriptions visible at once. I'm not keen on adding GUI editing of styles really.
But the menu items could stay, they're not bad.
In the interim, assuming that the performance isn't an issue, and that it only occurs on load (where all the tags for open files and stuff are being loaded anyway), the main patch (0001-...) is, imo, pretty clean and low-impact, could it be applied? It's nice to see a proper name for the themes, like 'Slush and Poppies' rather than something like 'slush_and_poppies.conf' and it allows a description of the theme in the tooltip.
I've now applied it, with changes. The patch only read the keys from the user config file, not system one. Also it used g_key_file_get_locale_string - we use g_key_file_get_string everywhere else.
I also used ui_widget_set_tooltip_text(), which works on GTK 2.8.
Regards, Nick
On 04/30/11 09:29, Nick Treleaven wrote:
On Fri, 29 Apr 2011 23:49:00 -0700 Matthew Brushmbrush@codebrainz.ca wrote:
I think the color scheme menu should probably be replaced with a dialog instead. That way the color scheme files don't need to be read unless the dialog is shown. Although this is not a noticeable performance problem, I think it would be good practice to do this, and using a dialog is more flexible.
I have actually started a little bit with this previously, I've added a new tab under Editor tab called Colors, which has a combo box to select a theme, below that is a list view (GtkTreeView) which lists the lexer states for each theme to be edited in the list for; use default, fg color, bg color, bold, italic, underline columns in each row. So far I have only edited the glade file to add the UI elements, I wrote very little actual code for it so far. This would be quite an ambitious undertaking, which is why I didn't proceed much further yet.
I was just thinking a dialog listing all color schemes and descriptions visible at once. I'm not keen on adding GUI editing of styles really.
But the menu items could stay, they're not bad.
Agreed that the menu items are ok, but it would be nice to have it in the preferences dialog. Also editing of the themes through the GUI/Prefs Dialog would be an *amazing* feature, but unless someone is willing to actually do it, there's no point discussing it further.
In the interim, assuming that the performance isn't an issue, and that it only occurs on load (where all the tags for open files and stuff are being loaded anyway), the main patch (0001-...) is, imo, pretty clean and low-impact, could it be applied? It's nice to see a proper name for the themes, like 'Slush and Poppies' rather than something like 'slush_and_poppies.conf' and it allows a description of the theme in the tooltip.
I've now applied it, with changes. The patch only read the keys from the user config file, not system one. Also it used g_key_file_get_locale_string - we use g_key_file_get_string everywhere else.
I personally think since the values are directly displayed as UI elements/text that they should be allowed to be translated the way GKeyFile allows for. Breaking this just to keep consistent with other code that doesn't read in UI element text directly seems odd to me.
I also used ui_widget_set_tooltip_text(), which works on GTK 2.8.
Cool, I didn't realize there was a wrapper for this.
Cheers, Matthew Brush
On Sat, 30 Apr 2011 15:52:59 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
On 04/30/11 09:29, Nick Treleaven wrote:
On Fri, 29 Apr 2011 23:49:00 -0700 Matthew Brushmbrush@codebrainz.ca wrote:
In the interim, assuming that the performance isn't an issue, and that it only occurs on load (where all the tags for open files and stuff are being loaded anyway), the main patch (0001-...) is, imo, pretty clean and low-impact, could it be applied? It's nice to see a proper name for the themes, like 'Slush and Poppies' rather than something like 'slush_and_poppies.conf' and it allows a description of the theme in the tooltip.
I've now applied it, with changes. The patch only read the keys from the user config file, not system one. Also it used g_key_file_get_locale_string - we use g_key_file_get_string everywhere else.
I personally think since the values are directly displayed as UI elements/text that they should be allowed to be translated the way GKeyFile allows for. Breaking this just to keep consistent with other code that doesn't read in UI element text directly seems odd to me.
Agree, I just failed to understand what g_key_file_get_locale_string did at the time. The docs for it maybe could have been clearer, but my fault. Now added.
Regards, Nick
On 04/30/11 09:29, Nick Treleaven wrote:
I've now applied it, with changes. The patch only read the keys from the user config file, not system one. Also it used
Sorry, I had fixed the user vs system issue in a later commit to my Geany repository[1] a few days ago, but I didn't send a new patch for that to the mailing list. Probably your implementation is better anyway :)
Cheers, Matthew Brush
[1] https://github.com/codebrainz/geany/commit/54e16841a1d0a177241aa6d3d06b7de7f...