Re: [Geany-devel] encoding combo boxes bug
On 01/20/2012 10:39 AM, Colomban Wendling wrote: Le 20/01/2012 00:07, Lex Trotman a écrit : On Fri, Jan 20, 2012 at 9:58 AM, Lex Trotman wrote: On Thu, Jan 19, 2012 at 11:53 PM, Nick Treleaven wrote: Hi, I'm seeing wrong encoding names in the encoding combo boxes on the Files tab of the Prefs dialog. E.g. where it should say UTF-8 I see Hebrew. Another Glade-related bug? Sort of, according to glade combo_new_encoding, combo_open_encoding and combo_eol all share the same underlying list model. So when we initialise them, all the entries go in the same list, so all three show the encodings twice and the end of line entries at the bottom. Two of these need to be pointed to different list models. PS the two encodings combos could probably share the same list, so long as we only initialise it once in prefs.c, but eol needs its own list Thanks for the catch & analysis, it's now fixed -- actually I did broke it in ca922e0ddc8022283ec3c1f49aaa15ab7c5ba213, stupid me. @All: I added ui_builder_get_object() to be able to fetch a non-widget (list store here) from prefs.c, but I'm not completely sure it's the prefect fix. If you have any idea on how to improve this, spread them! :) IMO, it'd be better to just move the builder object to the header file (maybe in a suitable struct), so that all files can access it. Then there's no need to add 1 line wrapper functions for every function we use from GtkBuilder's API. This isn't unprecedented, I think there's at least a handful of globals like this in Geany already (even in ui_utils.h). Alternatively, we could add a function called `ui_get_builder()` to get access to the builder to use with GtkBuilder API. Otherwise, it's not too big of a deal, maybe we don't need much more from the GtkBuilder API. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] GIT commit mails format
Le 15/01/2012 23:53, Enrico Tröger a écrit : On Sun, 15 Jan 2012 13:35:35 -0800, Matthew wrote: On 01/15/2012 12:03 PM, Lex Trotman wrote: [...] What do you think? If we agree to change the commit mails to this format, I'd deploy the script soon. I'd very much like it, and I'm fine with the format :) Hi Enrico, Actually I've become used to the standard github commit emails and clicking on the link for the diff. Especially for large changes like geany.html or geany.glade (despite Matthew and Colomban "promising" the diffs will get smaller with 3.8.1) not being blasted by large diffs is good. I can choose what I want to see, and don't get the two line diff of geany.txt cut off because the huge geany.html diff exceeds the size limit. I don't suppose that you could let registration for the commit ML allow a choice of which we want? Nope. The only option would be two separate mailing lists. Though the general idea about the diffs was to limit the diff size to something like 100kb (as it was before in the SF SVN commit mails) or any other value which we consider reasonable. Or make it so no diff is shown for autogenerated files like geany.html and geany.glade ? It'd be the best of both worlds then, IMO. Yeah, a little hackish but would solve the problem probably well enough together with a general max commit diff size limit. Why not, until we finally understand how the $@!% Glade choose to output in one order or another. But please keep the info the file got modified, don't drop it entirely :) Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] encoding combo boxes bug
Le 20/01/2012 00:07, Lex Trotman a écrit : On Fri, Jan 20, 2012 at 9:58 AM, Lex Trotman wrote: On Thu, Jan 19, 2012 at 11:53 PM, Nick Treleaven wrote: Hi, I'm seeing wrong encoding names in the encoding combo boxes on the Files tab of the Prefs dialog. E.g. where it should say UTF-8 I see Hebrew. Another Glade-related bug? Sort of, according to glade combo_new_encoding, combo_open_encoding and combo_eol all share the same underlying list model. So when we initialise them, all the entries go in the same list, so all three show the encodings twice and the end of line entries at the bottom. Two of these need to be pointed to different list models. PS the two encodings combos could probably share the same list, so long as we only initialise it once in prefs.c, but eol needs its own list Thanks for the catch & analysis, it's now fixed -- actually I did broke it in ca922e0ddc8022283ec3c1f49aaa15ab7c5ba213, stupid me. @All: I added ui_builder_get_object() to be able to fetch a non-widget (list store here) from prefs.c, but I'm not completely sure it's the prefect fix. If you have any idea on how to improve this, spread them! :) @Nick: how did you generate the Glade file for 21cd7bb2139fd67644e5777bb8e6387d34473d09 "Add Project overrides for 'Saving files' checkbox options"? When I do use Glade 3.8.1 do modify the file it keeps reordering prefs/project dialogs... Just wondering, actually committing the move isn't really harmful -- apart that it renders the diff unreadable, stupid Glade. Regards, Colomban Cheers Lex I don't have Glade 3.8.1 (need 3.10 for another project) so I shouldn't do it, someone with the right Glade care to create two new list models. Cheers Lex Nick ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins: MAINTAINERS file
On Wed, 11 Jan 2012 19:05:30 -0800 Matthew Brush wrote: > On 01/11/2012 05:13 AM, Frank Lanitz wrote: > > Am 10.01.2012 23:46, schrieb Matthew Brush: > >> On 01/07/2012 07:20 AM, Colomban Wendling wrote: > >>> Le 07/01/2012 16:00, Frank Lanitz a écrit : > On Fri, 6 Jan 2012 23:42:39 +0100 > Frank Lanitz wrote: > > >> * What's the exact difference between Supported and > >> Maintained? The only difference I see is that "supported" has > >> the word "paid" in the description, but I doubt that most of > >> us get paid for this in particular, and I also doubt it > >> changes anything on how good is the support (hobby vs. job). > > > > My fault. I wanted to change this but missed it. I wanted to > > s/supported/paid for ... (Even I don't know anybody at the > > moment who is getting paid with Geany stuff ;) ) > > I suggest to use paid instead of supported and change current > usage of supported to maintained. > >>> > >>> I'm still not sure what that fact someone is paid or not changes, > >>> but otherwise it looks fine and clearer to me. > >> > >> +1 > >> > >> Whether paid or volunteer, it's still "Maintained". > >> > >> I suggest dropping the "Paid" status altogether if no one has used > >> it by the time all the plugins' info is filled in. > > > > I disagree. Currently there might be no plugin maintainer being > > paid to work on a plugin, but: > > - this might change (...) > > - is something user should be able to see to resynch there > > demandings with reality. > > > > Hehehe, well said. OK, it's not a big deal, though I still feel it's > not very useful for Geany-Plugins. Well, I will purge it for the meanwhile. We can add it once it comes back up again. Cheers, Frank -- http://frank.uvena.de/en/ pgp3xlRoFRnD0.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
