[Geany-devel] Geany-Plugins: git@github
Hi folks, I've just created the geany-plugins repos on github inside our geany structure. I will *not* add any code until 0.21 has been released, but you might want to add it to your watchlist. You can find it at https://github.com/geany/geany-plugins *Please note*: All changes for 0.21 release will need to go into svn at sourceforge. After this has been made we will do the transition Jiri did already some good work in background in terms of preparation of git-repo. Cheers, Frank ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Python message parsing (bug 3411489)
It appears that Python error message formatting has changed from what is used in msgwin.c/parse_compiler_error_line() I havn't found anything in the Python docs or google that describes what it should be, does anyone have more knowledge so we can set a regex? Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Additional C++ file extensions
Hi All, The OP on bug 3410977 requested adding the .inl extension for C++. IIUC this is a Visual C++ file extension for inline functions. @Nick, since you are marooned on Windows are there any others while I am there. Also the .tcc suffix is recognised by g++ as C++ template code and should be added. It is also becoming common to use .ipp as template implementation code, for example in the Boost libraries and should also be added. Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Scintilla update?
Hey, What about updating our Scintilla copy? There is at least 2 fixes that would be particularly interesting to have: * C++ lexer fixed a bug with raw strings being recognised too easily. Bug #3388122. [1], [2] * On recent GTK+ 2.x versions when using Cairo, bug fixed where wrong colours were drawn. [3] So, have you anything against an update to Scintilla 2.29? Regards, Colomban PS: if you're not a core dev, no need to answer if you don't have a particular point to raise ;) [1] https://sourceforge.net/tracker/?func=detail&atid=102439&aid=3388122&group_id=2439 [2] https://sourceforge.net/tracker/index.php?func=detail&aid=3425107&group_id=153444&atid=787791 [3] would probably fix https://sourceforge.net/tracker/?func=detail&atid=787791&aid=3423425&group_id=153444 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Scintilla update?
On 18 October 2011 22:16, Colomban Wendling wrote: > Hey, > > What about updating our Scintilla copy? There is at least 2 fixes that > would be particularly interesting to have: > > * C++ lexer fixed a bug with raw strings being recognised too easily. > Bug #3388122. [1], [2] > * On recent GTK+ 2.x versions when using Cairo, bug fixed where wrong > colours were drawn. [3] > There have also been a number of Ruby fixes that might address some issues raised on the ML. > So, have you anything against an update to Scintilla 2.29? +1 Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Scintilla update?
On 11-10-18 04:16 AM, Colomban Wendling wrote: Hey, What about updating our Scintilla copy? There is at least 2 fixes that would be particularly interesting to have: * C++ lexer fixed a bug with raw strings being recognised too easily. Bug #3388122. [1], [2] * On recent GTK+ 2.x versions when using Cairo, bug fixed where wrong colours were drawn. [3] Plus GTK+ 3 support :) So, have you anything against an update to Scintilla 2.29? My only concern is the effects of switching to only supporting Cairo for the drawing backend. Will this leave any users unable to run Geany? Otherwise, I say we roll the dice and see what the new set of bugs ends up being :) Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] gtkbuilder branch and ui_lookup_widget functions
On 18/10/2011 00:09, Matthew Brush wrote: On 11-10-17 05:22 AM, Nick Treleaven wrote: Hi Matthew, I'm a bit concerned about the changed ui_lookup_widget (and hookup) functions - these are in the plugin API and can be used independently from Glade. (plugin) API function behaviour should not normally change, but it seems the owner parameter is now ignored. If we are caching lookups this is probably wrong as the widget may get destroyed. I haven't looked at the new implementation but perhaps you could help explain the changes. Long story short: compatibility is the reason. I understand that, but see below. Typical short story long: I didn't want to break all the existing code in core and plugins that were using ui_lookup_widget/ui_hookup_widget() functions, so I dropped the (now) pointless first parameter. There's no need to associate things with a parent/owner widget since all objects are required to have unique names in GtkBuilder (and the GHashTable). Here I think is the problem. As I mentioned earlier, ui_[lh]ookup_widget can be used *without* Glade or GtkBuilder! This is mentioned in the 'GUI example' for Stash (scroll down): http://www.geany.org/manual/reference/stash_8h.html#_details There is no reason why the owner dialog can't be destroyed, and also no reason why plugin API users have to use globally unique names for widgets. So this change breaks existing API behaviour, and in addition I think those features are things that are good to support anyway. So I think we need to restore this behaviour for those functions. ui_[lh]ookup_object should either be updated similarly or renamed to something like ui_builder_lookup to be clear about the difference. I'm not 100% sure what you mean by caching lookups or widgets being destroyed. Hopefully I've explained this above. So the first function called is ui_init_builder() and what it does is to initialize the GtkBuilder so that it creates all of the GObjects. Then it iterates over all of the objects in the GtkBuilder and stores their pointers into a GHashTable (also ref'ing them) using their names as the key. This is basically a "drop-in" replacement for the old Glade 2 generated code. Replacing the hookup and lookup functions are the new ui_lookup_object() and ui_hookup_object() functions. The former just does a g_hash_table_lookup() to find the GObject with the associated key(name). The latter just inserts the object into the hash table using the name as the key (and ref'ing it). It's my understanding that all objects that were hooked up were eternal until program close, though if this is not the case, we'll be leaking exactly 1 GObject per object that the user/plugin code destroys/unrefs since the GHashTable is holding a ref on it. It would be quite trivial to add a function to remove objects from the hash table, but existing code wouldn't be using this obviously. We could also not ref user-added object and only ref those from GtkBuilder if we wanted. In a perfect world, we could drop the GHashTable and use GtkBuilder directly to track the objects, but it seems GtkBuilder can only add objects from an XML string. Actually, in a perfect world, we wouldn't be creating widgets outside of the GUI file at all and so we could use GtkBuilder to track all the objects. So the basic plan I had thought up is to do these steps: 1. Convert the Glade 2 to Glade 3 (done) 2. Get rid of the old generated code with some compat code (done) 3. Separate out all the hard-coded GUI stuff and move it into the proper place, the GtkBuilder file (not even remotely done) 4. Stop adding new code that mixes UI and business logic (todo) Only the first 2 are essential to do now to actually switch to GtkBuilder, the next two can be done gradually over time. I hope this clears up somewhat how the GtkBuilder stuff is currently Thanks for explaining, but I think my suspicions were correct. working. If you want to review the implementation, it's quite trivial really, you can get a pretty clear view of the meat of it by using: $ git diff master..gtkbuilder src/ui_utils.c That should show pretty much only the implementation and a few other minor changes that have happened since. Thanks for that command, I hadn't learnt how to do that yet ;-) ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] project build tab - Re: GTK+ Version Bump to 2.18 - gtkbuilder and 2.16
On 18/10/2011 00:36, Matthew Brush wrote: On 11-10-17 04:27 PM, Lex Trotman wrote: On 18 October 2011 10:17, Matthew Brush wrote: I also noticed some issues with defaults in the project dialog where some stuff doesn't have a default and some of the combo boxes have two columns showing so it looks like: "Item 1 Item 1" "Item 2 Item 2" IMO, it would *really* be nice to get all of the Project dialog ported to GtkBuilder since currently only the Editor and Indentation tabs are in GtkBuilder, the "Project" tab and the Build tab are both hard-coded and added to the dialog at runtime it seems. Hi Matthew, Yes, the build tab is generated at runtime because it has variable length (set by the number_xx_menu_items prefs). Possibly it could be a treeview, but that would change the whole operation of the build tabs and would need discussion with Nick who has strong ideas on the subject :) Not really, I'm just opposed to replacing groups of commands with a list of commands as I think this is worse usability. I think a treeview for each command group wouldn't really change things and might look better. Is there a way to show a label with mnemonic in a treeview column? Not crucial but nice to have. +1. I actually started tinkering with making it a treeview in Glade, since it makes way more sense to not have a hardcoded number and types of build commands, but of course as we discussed before, there needs to be a fixed number of commands at startup due to the limitations in the keybinding system. Not necessarily, but sort of. Keybindings that map to a non existent command could just do nothing. Anyway, for now, we could add the whole UI into Glade except the dynamic part and just append/insert rows for more commands at run-time for the parts that change. At least 95% of it would go into the UI file. Sounds good, but maybe it's best to wait until after the merge into master. I think branches should stay focused on one thing; that sounds like a bigger change. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Speed up & simplify stash tree display/update
Hi, Now that StashTreeValue has an entry pointer, value->setting_type and value->key_name can be dropped. Also, the stash_tree_action:_get_iter_first, _iter_next should be written as gtk_tree_model_foreach(model, stash_tree_handle_pref, action). It's ~15% slower, but that doesn't matter any more. And of course, stash_foreach_various_pref can be inlined into stash_tree_setup, and call stash_tree_append_pref directly, or even inline it too. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Glade 3 Translations (was Re: Team Translation)
On Mon, 17 Oct 2011 18:58:35 +0200, Colomban wrote: >Le 16/10/2011 12:07, Matthew Brush a écrit : >> Hi, >> >> Does anyone know what effect merging the `gtkbuilder` branch would >> have on translations for the UI stuff? >> >> IIUC there is some translation capability build into >> Glade/GtkBuilder, so would we need to start using this? >> >> Do the current translations for Glade 2 strings work on the >> auto-generated C code (interface.[ch]) or are they on the Glade 2 >> file (geany.glade) directly? > >AFAIK, currently translated strings should be OK as far as we set the Well, I just checked po/POTFILES.in and there is src/interface.c listed, so this one is used for picking the translatable strings. And in po/POTFILES.skip geany.glade is explicitly listed to not be used for translatable strings with a comment that intltool would use it otherwise. So, I guess, as Colomban, that using the gtkbuilder XMl will work fine for intltool as well. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc pgpGgw5UpxJvA.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Speed up & simplify stash tree display/update
On 18/10/2011 18:31, Dimitar Zhekov wrote: Hi, Now that StashTreeValue has an entry pointer, value->setting_type and value->key_name can be dropped. Yes. Also, the stash_tree_action:_get_iter_first, _iter_next should be written as gtk_tree_model_foreach(model, stash_tree_handle_pref, action). It's ~15% slower, but that doesn't matter any more. I'm not sure that's really neater. If C had lambda support then yes. Casting to gpointer is ugly. And of course, stash_foreach_various_pref can be inlined into stash_tree_setup, and call stash_tree_append_pref directly, or even inline it too. Not sure it's worth it, maybe. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] GIT commit mails format
Hey guys, right now, we use the stock email commit hook from Github and let it send commit mails to the geany-commits mailing list. However, compared to the old Subversion commit mails, they are quite different: First, they are not really commit mails but rather "push" mails, that is all commits which are transmitted within one push are combined into one mail instead of one mail per commit as it was previously. Secondly, the commit mails only include the commit message and a link to the commit diff at Github. I personally would prefer to have the diff included (also as before). So, I'm tempted to use something else for sending out commit mails. For example, the Xfce guys have a simple Shell script to do the job and it does it as I would wish: http://git.xfce.org/admin/xfce-git-hooks/tree/hooks/update-03-send-commit-mails An example mail: http://mail.xfce.org/pipermail/xfce4-commits/2011-October/023580.html What do you think? Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc pgpooArssUrZI.pgp Description: PGP signature ___ 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 18/10/2011 19:52, Enrico Tröger a écrit : > Hey guys, > > > right now, we use the stock email commit hook from Github and let it > send commit mails to the geany-commits mailing list. > > However, compared to the old Subversion commit mails, they are quite > different: > > First, they are not really commit mails but rather "push" mails, that > is all commits which are transmitted within one push are combined into > one mail instead of one mail per commit as it was previously. > > Secondly, the commit mails only include the commit message and a link > to the commit diff at Github. I personally would prefer to have the > diff included (also as before). > > > So, I'm tempted to use something else for sending out commit mails. > > For example, the Xfce guys have a simple Shell script to do the job and > it does it as I would wish: > http://git.xfce.org/admin/xfce-git-hooks/tree/hooks/update-03-send-commit-mails > > An example mail: > http://mail.xfce.org/pipermail/xfce4-commits/2011-October/023580.html > > > What do you think? Nothing but a big "+1" ;) The resulting email looks good to me -- quite like a `git show` :) --, just maybe it could include the GitHub link too if of any interest. Cheers, Colomban ___ 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
On Tue, 18 Oct 2011 20:03:09 +0200, Colomban wrote: >Le 18/10/2011 19:52, Enrico Tröger a écrit : >> Hey guys, >> >> >> right now, we use the stock email commit hook from Github and let it >> send commit mails to the geany-commits mailing list. >> >> However, compared to the old Subversion commit mails, they are quite >> different: >> >> First, they are not really commit mails but rather "push" mails, that >> is all commits which are transmitted within one push are combined >> into one mail instead of one mail per commit as it was previously. >> >> Secondly, the commit mails only include the commit message and a link >> to the commit diff at Github. I personally would prefer to have the >> diff included (also as before). >> >> >> So, I'm tempted to use something else for sending out commit mails. >> >> For example, the Xfce guys have a simple Shell script to do the job >> and it does it as I would wish: >> http://git.xfce.org/admin/xfce-git-hooks/tree/hooks/update-03-send-commit-mails >> >> An example mail: >> http://mail.xfce.org/pipermail/xfce4-commits/2011-October/023580.html >> >> >> What do you think? > >Nothing but a big "+1" ;) > >The resulting email looks good to me -- quite like a `git show` :) --, >just maybe it could include the GitHub link too if of any interest. Yup, that'd be easy and useful. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc pgpHXZT2tc25X.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Geany-Plugins: Automake warning - Something bad?
Hi folks, I just tried autotools build for geany-plugins and received geanypg/Makefile.am:1: ENABLE_GEANYCFP does not appear in AM_CONDITIONAL Is this something we need to worry about? Cheers, Frank -- Frank Lanitz pgpLUkrg6QzcM.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins: Automake warning - Something bad?
On Tue, 18 Oct 2011 20:51:56 +0200 Frank Lanitz wrote: > Hi folks, > > I just tried autotools build for geany-plugins and received > geanypg/Makefile.am:1: ENABLE_GEANYCFP does not appear in AM_CONDITIONAL > Is this something we need to worry about? Another one on running configure config.status: error: cannot find input file: `geanyprj/Makefile.in' Cheers, Frank -- Frank Lanitz pgpLAiaR7VXOG.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] gtkbuilder branch and ui_lookup_widget functions
On 11-10-18 09:05 AM, Nick Treleaven wrote: On 18/10/2011 00:09, Matthew Brush wrote: I didn't want to break all the existing code in core and plugins that were using ui_lookup_widget/ui_hookup_widget() functions, so I dropped the (now) pointless first parameter. There's no need to associate things with a parent/owner widget since all objects are required to have unique names in GtkBuilder (and the GHashTable). Here I think is the problem. As I mentioned earlier, ui_[lh]ookup_widget can be used *without* Glade or GtkBuilder! This is mentioned in the 'GUI example' for Stash (scroll down): http://www.geany.org/manual/reference/stash_8h.html#_details ui_[hl]ookup_object() are not used with GtkBuilder or Glade[1], they access an internal hash table. GtkBuilder is completely out of the picture by the end of the ui_init_builder()[2] function. Glade3/GtkBuilder does require unique names (as did glade 2 IIUC, since all the names were unique), but the only reason those two functions currently do also is because the names are used as the key in a hash table, and so must be unique. If you look back in the history you should see where I started out with using a GList but eventually moved to a GHashTable since it's a better data structure for the purpose. There is no reason why the owner dialog can't be destroyed, and also no reason why plugin API users have to use globally unique names for widgets. I still don't understand what destroying the owner dialog has to do with anything. TBH I don't even know what use the owner widget parameter had in those functions, was it just to provide a "namespace" so that widget names didn't clash between plugins? As for the globally unique names, I guess this could be a problem if some new code was using the pointless ui_[hl]ookup_object() functions to associate a completely arbitrary "name" with a GObject (not *it's* name like gtk_widget_set_name(), just *a* name - used to lookup the object in the GHashTable). So this change breaks existing API behaviour, and in addition I think those features are things that are good to support anyway. It might yes, especially if different plugins were calling ui_hookup_widget() with clashing names (which they don't). So I think we need to restore this behaviour for those functions. ui_[lh]ookup_object should either be updated similarly or renamed to something like ui_builder_lookup to be clear about the difference. It used to be called ui_add_object() but then I renamed it :) ui_builder_lookup() is misleading since it's not looking up anything in the builder, which has long since been destroyed. It's looking up in the GHashTable which is only there to provide backwards compatibility with old code. I'm not 100% sure what you mean by caching lookups or widgets being destroyed. Hopefully I've explained this above. Not really (I'm kinda stupid remember :) I think I'm confused about how it used to work and you're confused about how it works now :) I'm not too familiar with the stash library, but aside from it, what other purpose do the ui_[lh]ookup_widget() functions serve that couldn't be accomplished with the way plugins typically use widgets[3]? I know glade generated code used to have lookup/hookup functions for some reason, is it to do with that? I looked in the Geany-Plugin code, and there's no use of ui_hookup_widget() and most uses of ui_lookup_widget() are using a geany->main_widgets->foo widget as the owner, which is fine since the widgets that came from Geany's Glade file are guaranteed to have unique names. P.S. Are you ever on IRC or IM? It's hard to have this type of discussion in 1 message per day email communications :) Cheers, Matthew Brush [1] here's the lifecycle of the GtkBuilder instance: - enter the ui_init_builder() function - initialize a gtkbuilder instance - add the xml file to parse to the gtkbuilder - extract all the newly parsed/initialized gobjects - add those objects to the ghashtable - destroy the gtkbuilder instance - leave ui_init_builder() [2] https://github.com/geany/geany/blob/gtkbuilder/src/ui_utils.c#L2116 [3] that is, holding a pointer and destroying the widget when the plugin is unloaded. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Glade 3 Translations (was Re: Team Translation)
On 11-10-18 10:43 AM, Enrico Tröger wrote: On Mon, 17 Oct 2011 18:58:35 +0200, Colomban wrote: Le 16/10/2011 12:07, Matthew Brush a écrit : Hi, Does anyone know what effect merging the `gtkbuilder` branch would have on translations for the UI stuff? IIUC there is some translation capability build into Glade/GtkBuilder, so would we need to start using this? Do the current translations for Glade 2 strings work on the auto-generated C code (interface.[ch]) or are they on the Glade 2 file (geany.glade) directly? AFAIK, currently translated strings should be OK as far as we set the Well, I just checked po/POTFILES.in and there is src/interface.c listed, so this one is used for picking the translatable strings. And in po/POTFILES.skip geany.glade is explicitly listed to not be used for translatable strings with a comment that intltool would use it otherwise. So, I guess, as Colomban, that using the gtkbuilder XMl will work fine for intltool as well. Cool! Apparently by default gtk_builder_set_translation_domain() uses gettext(), so are we all set then or do we need to set this to something else? Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins: Automake warning - Something bad?
On 11-10-18 11:53 AM, Frank Lanitz wrote: On Tue, 18 Oct 2011 20:51:56 +0200 Frank Lanitz wrote: Hi folks, I just tried autotools build for geany-plugins and received geanypg/Makefile.am:1: ENABLE_GEANYCFP does not appear in AM_CONDITIONAL Is this something we need to worry about? Another one on running configure config.status: error: cannot find input file: `geanyprj/Makefile.in' I've had this lots of times with Autotools. I don't know what causes it, but I think I usually fix it by re-running ./autogen.sh or autoreconf -vfi. You might need to touch the missing Makefile.in so that it exists first. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Glade 3 Translations (was Re: Team Translation)
On Tue, 18 Oct 2011 13:51:03 -0700, Matthew wrote: >On 11-10-18 10:43 AM, Enrico Tröger wrote: >> On Mon, 17 Oct 2011 18:58:35 +0200, Colomban wrote: >> >>> Le 16/10/2011 12:07, Matthew Brush a écrit : Hi, Does anyone know what effect merging the `gtkbuilder` branch would have on translations for the UI stuff? IIUC there is some translation capability build into Glade/GtkBuilder, so would we need to start using this? Do the current translations for Glade 2 strings work on the auto-generated C code (interface.[ch]) or are they on the Glade 2 file (geany.glade) directly? >>> >>> AFAIK, currently translated strings should be OK as far as we set >>> the >> >> Well, I just checked po/POTFILES.in and there is src/interface.c >> listed, so this one is used for picking the translatable strings. >> And in po/POTFILES.skip geany.glade is explicitly listed to not be >> used for translatable strings with a comment that intltool would use >> it otherwise. So, I guess, as Colomban, that using the gtkbuilder >> XMl will work fine for intltool as well. >> > >Cool! > >Apparently by default gtk_builder_set_translation_domain() uses >gettext(), so are we all set then or do we need to set this to >something else? I don't think we need something else. Just needs to be tested. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc pgpf1Z0591wRS.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Glade 3 Translations (was Re: Team Translation)
Le 18/10/2011 22:51, Matthew Brush a écrit : > On 11-10-18 10:43 AM, Enrico Tröger wrote: >> On Mon, 17 Oct 2011 18:58:35 +0200, Colomban wrote: >> >>> Le 16/10/2011 12:07, Matthew Brush a écrit : Hi, Does anyone know what effect merging the `gtkbuilder` branch would have on translations for the UI stuff? IIUC there is some translation capability build into Glade/GtkBuilder, so would we need to start using this? Do the current translations for Glade 2 strings work on the auto-generated C code (interface.[ch]) or are they on the Glade 2 file (geany.glade) directly? >>> >>> AFAIK, currently translated strings should be OK as far as we set the >> >> Well, I just checked po/POTFILES.in and there is src/interface.c >> listed, so this one is used for picking the translatable strings. >> And in po/POTFILES.skip geany.glade is explicitly listed to not be used >> for translatable strings with a comment that intltool would use it >> otherwise. So, I guess, as Colomban, that using the gtkbuilder XMl will >> work fine for intltool as well. >> > > Cool! > > Apparently by default gtk_builder_set_translation_domain() uses > gettext(), so are we all set then or do we need to set this to something > else? Yep, it's enough for using the translated strings. We just need to make sure the strings are properly extracted from the .ui file (by intltool) so they new ones can be translated. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins: Automake warning - Something bad?
On Tue, 18 Oct 2011 13:54:59 -0700 Matthew Brush wrote: > On 11-10-18 11:53 AM, Frank Lanitz wrote: > > On Tue, 18 Oct 2011 20:51:56 +0200 > > Frank Lanitz wrote: > > > >> Hi folks, > >> > >> I just tried autotools build for geany-plugins and received > >> geanypg/Makefile.am:1: ENABLE_GEANYCFP does not appear in > >> AM_CONDITIONAL Is this something we need to worry about? > > > > Another one on running configure > > > > config.status: error: cannot find input file: `geanyprj/Makefile.in' > > > > I've had this lots of times with Autotools. I don't know what causes > it, but I think I usually fix it by re-running ./autogen.sh or > autoreconf -vfi. You might need to touch the missing Makefile.in so > that it exists first. OK. I will try. But...uhm...How can we fix that in general inside svn? Cheers, Frank -- http://frank.uvena.de/en/ pgpS6f3V20aP9.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] gtkbuilder branch and ui_lookup_widget functions
On 11-10-18 01:33 PM, Matthew Brush wrote: Not really (I'm kinda stupid remember :) I think I'm confused about how it used to work and you're confused about how it works now :) I think I see what you're talking about, ui_hookup_widget() is attaching the widget to the owner Gobject's datalist. Ok, I think to avoid fixing all of Geany's code that uses this, I will make the new ui_hookup_object() to do this same thing as well, then we can worry more about getting rid of what's left once we port the rest of the UI to GtkBuilder. I'll report back once I've got it working and we can go from there. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Python message parsing (bug 3411489)
On Tue, 18 Oct 2011 20:48:12 +1100, Lex wrote:
>It appears that Python error message formatting has changed from what
>is used in msgwin.c/parse_compiler_error_line()
>
>I havn't found anything in the Python docs or google that describes
>what it should be, does anyone have more knowledge so we can set a
>regex?
In Python 2.6 they introduced the doraise keyword argument to
py_compile.compile. Until then, always a stacktrace was printed and
Geany's builtin parsing matched one of the lines of the stacktrace.
Since Python 2.6, only an error message line is printed and so the
builtin code fails.
Example (from an embedded device which luckily has Python 2.5 and 2.6
installed :D):
[21:37] root@kalki (0): ~# python2.5 -t -c "import py_compile;
py_compile.compile('/tmp/test.py')" File "/tmp/test.py", line 5
df lala(la):
^
SyntaxError: invalid syntax
[21:37] root@kalki (0): ~# python2.6 -t -c "import py_compile;
py_compile.compile('/tmp/test.py')" SyntaxError: ('invalid syntax',
('/tmp/test.py', 5, 7, 'df lala(la):\n'))
This should be fixed in GIT master. However, I only tested it against
SyntaxErrors.
Good catch, Lex. I never noticed it as I almost always use pylint
with a regex for Python code checking :).
And if someone still has a regex for the Python 2.6+ format, feel free
to share it. It might help users with older versions of Geany.
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.asc
pgpV3WVhMANMa.pgp
Description: PGP signature
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Python message parsing (bug 3411489)
[...] > > This should be fixed in GIT master. However, I only tested it against > SyntaxErrors. Thanks Enrico. I was really asking what other errors are there, I never bother to compile Python so I've never seen them. :) > > Good catch, Lex. I never noticed it as I almost always use pylint > with a regex for Python code checking :). > That would be worth wiki-ing if you don't mind sharing it, Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Python message parsing (bug 3411489)
On Wed, 19 Oct 2011 09:11:29 +1100, Lex wrote: >[...] >> >> This should be fixed in GIT master. However, I only tested it against >> SyntaxErrors. > >Thanks Enrico. > >I was really asking what other errors are there, I never bother to >compile Python so I've never seen them. :) Well, the source at http://hg.python.org/cpython/file/2.7/Lib/py_compile.py line 47 suggests there are more possible error types though I can't remember to ever have seen anything else when compiling. >> Good catch, Lex. I never noticed it as I almost always use pylint >> with a regex for Python code checking :). >> > >That would be worth wiki-ing if you don't mind sharing it, It's already sort of shared, well, at least not totally hidden :). https://github.com/eht16/dotconf/blob/master/user/.config/geany/filedefs/filetypes.python But yeah, wiki'ing (heh, nice word) is a good idea. I'll write something about it sometime soon, I hope unless someone beats me to it. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc pgpOoxXxfqchI.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Python message parsing (bug 3411489)
2011/10/19 Enrico Tröger : > On Wed, 19 Oct 2011 09:11:29 +1100, Lex wrote: > >>[...] >>> >>> This should be fixed in GIT master. However, I only tested it against >>> SyntaxErrors. I asked on #python-dev and it shouldn't be doing this, it should still be "File blah line n" No conclusion yet. Will report if anything more comes up. Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
