Re: [Geany-devel] Glade Code Generation and GtkBuilder
On 30 August 2011 11:35, Matthew Brush wrote: > On 08/29/2011 05:20 PM, Lex Trotman wrote: >> >> [...] > >> Well, I don't think there is anything wrong with looking at GTK-3 but >> it *is* too early to remove support for GTK-2. I've not looked at >> what changed for GTK-3, can we support both without much work (after >> gtkbuilder is incorporated)? Lots of #ifdefs would be bad. >> > > Until the snag with the deprecated widgets used in the Glade generated code, > the changes were extremely trivial and wouldn't at all break the current > GTK+ version support. All of them were documented in the migration > guide[1]. > > A quick list of the changes I had to make: > - Update Scintilla since it now supports GTK+ 3. Yes, although IIUC GTK-3 support is still experimental > - Replace a few direct member accesses with accessor functions. So long as the accessors are available in GTK 2.12 otherwise #if hell begins > - Switch from using GtkComboBoxEntry to GtkComboBox. Well, a ComboBox created with new_with_entry that is. > - Replace GtkNotebookPage with gpointer. Mostly it seems to be GtkWidget * not gpointer but also some of notebook.c might need a bit more changed since it fakes GtkNotebookPage. > - Fix use of GDK_ and include of gdkkeysyms.h. Shouldn't be too hard > - Add some alternate #ifdef'd code for "Height-for-width" layout in the > GeanyWrapLabel widget[2] With the new layout capabilities we should first look if we need our own widget any more, less to maintain but more #if. > > The last two are the only ones that require some version checking/different > code handling. Actually, some of the changes should probably be made even > without thinking of GTK+ 3, since they are considered good practice even > with GTK+ 2. True. Other things to think about: How to ensure that users download the correct version, since the one executable can't do both, you can only compile and link against one version of GTK. This increases the Geany maintenance workload as there now needs to be two versions supported, tested etc. How to ensure plugins are linked against the right version, or determine which version they support, that might need two sets of API/ABI say <1000 for GTK2 and >1000 for GTK3. This looks like a lot more work than the current Geany contributors can handle so I would suggest it will take a while. In the meantime I guess you can either try to make your plugin not require GTK-3 or maintain your own GTK-3 git branch. And of course Geany would also be grateful for patches with those changes that are GTK-2 compatible good practice to start the main project down the road. Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Glade Code Generation and GtkBuilder
On 08/29/2011 05:20 PM, Lex Trotman wrote: [...] Well, I don't think there is anything wrong with looking at GTK-3 but it *is* too early to remove support for GTK-2. I've not looked at what changed for GTK-3, can we support both without much work (after gtkbuilder is incorporated)? Lots of #ifdefs would be bad. Until the snag with the deprecated widgets used in the Glade generated code, the changes were extremely trivial and wouldn't at all break the current GTK+ version support. All of them were documented in the migration guide[1]. A quick list of the changes I had to make: - Update Scintilla since it now supports GTK+ 3. - Replace a few direct member accesses with accessor functions. - Switch from using GtkComboBoxEntry to GtkComboBox. - Replace GtkNotebookPage with gpointer. - Fix use of GDK_ and include of gdkkeysyms.h. - Add some alternate #ifdef'd code for "Height-for-width" layout in the GeanyWrapLabel widget[2] The last two are the only ones that require some version checking/different code handling. Actually, some of the changes should probably be made even without thinking of GTK+ 3, since they are considered good practice even with GTK+ 2. [1] http://developer.gnome.org/gtk3/3.0/migrating.html [2] http://developer.gnome.org/gtk3/3.0/ch25s02.html#id1525688 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: Please update documentation
On 08/29/2011 08:35 AM, Frank Lanitz wrote: Hi plugin maintainer of geany-plugins, As 0.21 is near I like to ask you to update your documentation for your plugin. Some of them are pretty out of date and not very useful to the user. Just a reminder also, someone should update the Plugins page on geany.org as it lists some but not all of the current plugins and also lists the recently removed GeanyEmbrace. Might be a good time before the release to review all the content on that page[1]. [1] http://www.geany.org/Support/Plugins 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 Code Generation and GtkBuilder
[...] > Heh, ok, it wasn't fun, just trying to avoid the inevitable "it's too early! > we only just switched to 2.12!!". I'm writing a plugin for fun, and it's > going to require GTK+ 3. > Well, I don't think there is anything wrong with looking at GTK-3 but it *is* too early to remove support for GTK-2. I've not looked at what changed for GTK-3, can we support both without much work (after gtkbuilder is incorporated)? Lots of #ifdefs would be bad. > I'm not sure if you've used Glade 3, especially newer versions of it, but > it's pretty great IMO. And they wisely got rid of that pesky code > generation feature which had the potential to cause some serious grief down > the road :) > Only used older glade 3, but a quick look at docs doesn't say a huge amount changed. > Out of curiosity, what's the alternative to Glade? If it can only build LCD > UIs, what would you use to build a non-LCD UI in GTK+? Surely not hand/hard > coded widget building code? Sadly yes, you deleted my example from build.c where it is needed. [...] > Was it going from raw generated C code to LibGlade/GtkBuilder, or was it > going from LibGlade to GtkBuilder? I think the former is a more daunting > task than the latter, though I could be mistaken. Same as Geany, glade generated code to builder. Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] New messages/output parsing proposition
>> Thats easy to avoid, don't do it :) > > Yes, it can be easily avoided by by writing the expressions to require > one of the known extensions for the file type, and classifying the > filename-line-column match as "Good". So the "Best" becomes absolute. > Good point, the expression could handle multiple extensions too, eg ^(?.+?(?:cpp|hpp|h|cxx|hxx)):(?\d+):(?\d+)? this makes it deterministic. [...] > What is the "default (is currently blank)"?.. I searched Geany for > global fallback expression(s) short time ago, but all I could find > was parse_compiler_error_line(). > Sorry, build_get_regex() used to also look at default, but I forgot it got removed. [...] > I imagine myself navigating thru the build dialog, copy-pasting all > filetype expressions that can be relevant to the project, for every > project. And then changing all of them on each slightly different > outout... And then I'll finally sit back and say: "There is nobody > to blameth, cause I brouth this on myself". :) Indeed, but its better that shouting, "Where the [long string of expletives deleted] is it getting that from ..." :-) [...] > With enough | expressions, anything will work. I'll can very long, but > a regex limit is 64K... Just how many languages do you mix? You only need the ones you use in the project. Most sane people tend to limit themselves to only a few, one or two code plus one or two documentation. Like Geany does. People who don't limit themselves become insane :-D > >> Then if you really want the fun, the fallback when no regex is >> specified could be upgraded from the current hardcoded routine to use >> your multiple language search, best match, super dooper[1] >> technology, but with a preference to turn it on/off in case it >> produces unwanted results. > > You saved me even more work. With a single regex defined in 54 system > filetypes, and 4 mentions of the message parsing in 1320 tracker items, > It odesn't look like anybody needs a new parser, much less anyone is > going to define complex new-style regex-es. Good analysis, as I said in the past, there is only a single filetype regex because the hard coded method came first and no-one has had time to change anything. Its not because they think the current system is best. Of course we don't know how many user defined regexes are out there working perfectly and silently. > > So I'd better head to more practical things: column support and > optional underlining for the Messages tab, and optional mark all Find > Usage matches. Well, using named captures and so allowing multi-language regexes is a useful improvement. Having to select a C++ file before building is annoying (Python only throws one error at a time so its better to get the C++ errors parsed). The named captures also helps your column support be more robust. > > BTW, how about closing 3039654, and writing some comment for 3156609? Sure, I'm currently behind a corporate firewall which doesn't let me login to sourceforge (or the wiki) and looks like being another couple of weeks before I'm finished. So if someone else wants to close the first and note on the second that the documentation already says new entries override old ones, see http://www.geany.org/manual/current/index.html#old-settings then it won't be forgotten, thanks. > [...] > In the Message Window, the "Messages" tab on the left. It's parsing is > completely different from the "Compiler" tab. Ahhh, I had forgotten that the messages window parsed anything. Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] New messages/output parsing proposition
On Mon, 29 Aug 2011 11:16:05 +1000 Lex Trotman wrote: > >> Whats anon for? [...] > > > > To have it colored as error or warning. A bit of FX. :) > > Bet we get bug reports that users can't click on it :-) I can trust them that much... :) > > Best ::= one of the matches defined as Best, which are unlikely to > > produce wrong results. Primary purpose: avoid matching against all > > filetype expressions on build. > > Thats easy to avoid, don't do it :) Yes, it can be easily avoided by by writing the expressions to require one of the known extensions for the file type, and classifying the filename-line-column match as "Good". So the "Best" becomes absolute. > >> Only the regex associated with the command should be used, that > >> is whatever is shown in the configuration GUI for the command. > > > > I know how the project / filetype / default hierarhy works, but > > should have been more clear: > > > > User regex for the file type ::= project, fallback filetype file > > Sorry whats a fallback filetype file? The hierarchy is project > filetype setting, user filetype file setting, system filetype file > setting, default (is currently blank). The home filetype or the system filetype file. What is the "default (is currently blank)"?.. I searched Geany for global fallback expression(s) short time ago, but all I could find was parse_compiler_error_line(). > I should have been clear that I think that the current behavior is > wrong, it should be: if there is a regex use it, otherwise use some > default fallback. > >> The filetype independent (make) commands are the ones that might > >> run into multiple languages. [...] Better to assume developers > >> working with mixed languages are competent enough to select the > >> right expressions and or them together. > > I imagine myself navigating thru the build dialog, copy-pasting all filetype expressions that can be relevant to the project, for every project. And then changing all of them on each slightly different outout... And then I'll finally sit back and say: "There is nobody to blameth, cause I brouth this on myself". :) > > Why even write a new parser then? With enough | separated patterns, > > even the current one will work just fine. It would be nice to have > > warn/anon/copy, but they are only extras. > > > > Well, I am coming to the conclusion after these discussions that you > don't need to write a whole new parser (just saved you lots of work > :), rather add the ability to use multiple occurrences of named > captures to regexes. Without that the | can't work. With enough | expressions, anything will work. I'll can very long, but a regex limit is 64K... > Then if you really want the fun, the fallback when no regex is > specified could be upgraded from the current hardcoded routine to use > your multiple language search, best match, super dooper[1] > technology, but with a preference to turn it on/off in case it > produces unwanted results. You saved me even more work. With a single regex defined in 54 system filetypes, and 4 mentions of the message parsing in 1320 tracker items, It odesn't look like anybody needs a new parser, much less anyone is going to define complex new-style regex-es. So I'd better head to more practical things: column support and optional underlining for the Messages tab, and optional mark all Find Usage matches. BTW, how about closing 3039654, and writing some comment for 3156609? > >> > The list model will be removed. Default Messages regex-es plus the > >> > plugin defined ones should soffice. > >> > >> Plugins can't set regexes ATM because none of build.h is in the API, > >> see other thread. This is something to be re-visited. > > > > That's for the Messages only, "On messages tab". > > I don't understand what you mean, sorry. In the Message Window, the "Messages" tab on the left. It's parsing is completely different from the "Compiler" tab. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Geany-Plugins: Please fix compiler warnings
Hi plugin maintainer, A couple of month ago we discussed about adding more code quality to the plugins. During this discussion we added the make check target to autotools build environment for geany-plugins project to get a more pedantic compiler, preventing segfaults, memory leaks and other unwanted behavior. However, a long time passed by since we did the discussion and I'm not very happy about the progress we made. Still a lot of plugins do have a huge number of compiler warnings in special on AMD64 architecture. So I'm asking you with having 0.21 in view to fix as many as possible compiler warnings and errors at your plugins to ensure to have the users a good release working with. Maybe you can also install check and cppcheck for some static code analysis. Cheers, Frank -- http://frank.uvena.de/en/ pgpM0zi5iB0bD.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: Please update documentation
Hi plugin maintainer of geany-plugins, As 0.21 is near I like to ask you to update your documentation for your plugin. Some of them are pretty out of date and not very useful to the user. Please check that they include the latest information as e.g. authors mail addresses, web pages, features, know issues, bug tracker links etc. But also make sure the user is understanding how the plugin works and how he can make usage of it. Thanks in advance, Frank P.S. I'm honestly personally thinking about to don't include a plugin which is not having a minimum of good documentation to upcoming releases... -- http://frank.uvena.de/en/ pgp4lZdX9IiKf.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 on github; why not?
On Mon, 29 Aug 2011 13:17:38 +0200 Thomas Martitz wrote: > Am 28.08.2011 23:33, schrieb Jiří Techet: > > On Sat, Aug 27, 2011 at 20:50, Frank Lanitz > > wrote: > >> So I suggest this: Jiri can you help to do so (or does maybe the > >> github svn clone tools does this correct?) we surely can also > >> offer something like that from git.geany.org. But here import is > >> needed FMPOV. > > I could, but it needs some manual work and I'd like to do it just > > before the switch because I'm not sure if I could easily add the > > commits (commits on different branches and especially merges) you do > > between now and the switch. I was too missing a few committer names > > - see the original email here > > > > http://lists.uvena.de/geany-devel/2010-June/002672.html > > > > which I'd need to get first before performing the conversion. > > > > I could also ask the one that successfully converted our Rockbox svn > repo to git, including proper branch, tag and author conversion, to > write up the steps it needed. I think it was less than a day of work > for him (and the Rockbox tree and history is considerably larger and > more complicated than Geany's). Well, good idea I guess. Maybe you can get some hints from him or even him to help ;) Cheers, Frank -- http://frank.uvena.de/en/ pgppQYYjr5uJx.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 Code Generation and GtkBuilder
On 08/29/2011 03:00 AM, Lex Trotman wrote: On 29 August 2011 17:53, Matthew Brush wrote: I was messing around with Geany code to see what it would take to compile it against GTK+ 3 (just for fun). There doesn't seem to be too many changes needed, with one *massive* exception: the old code generated by old glade versions. You have some weird concept of fun :-) Heh, ok, it wasn't fun, just trying to avoid the inevitable "it's too early! we only just switched to 2.12!!". I'm writing a plugin for fun, and it's going to require GTK+ 3. Personally I am not a big fan of Glade, it seems to me to only build lowest common denominator UIs, but that may be just me. I'm not sure if you've used Glade 3, especially newer versions of it, but it's pretty great IMO. And they wisely got rid of that pesky code generation feature which had the potential to cause some serious grief down the road :) Out of curiosity, what's the alternative to Glade? If it can only build LCD UIs, what would you use to build a non-LCD UI in GTK+? Surely not hand/hard coded widget building code? Can we fix the names, please please, foo1 foo2 foo3 is really annoying, its hard to tell which is the one I want, if we need to break the thing lets put it back together properly. +1 Maybe I'm over-estimating the scope of the change. Is there some silver-bullet approach that will make this trivial? I've only been involved in doing this once, it wasn't too bad, but I think that UI was a bit better put together than Geany, but Geany is much smaller than it was. It is a couple of years ago so the memory is a bit hazy. Was it going from raw generated C code to LibGlade/GtkBuilder, or was it going from LibGlade to GtkBuilder? I think the former is a more daunting task than the latter, though I could be mistaken. 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 on github; why not?
Am 28.08.2011 23:33, schrieb Jiří Techet: On Sat, Aug 27, 2011 at 20:50, Frank Lanitz wrote: So I suggest this: Jiri can you help to do so (or does maybe the github svn clone tools does this correct?) we surely can also offer something like that from git.geany.org. But here import is needed FMPOV. I could, but it needs some manual work and I'd like to do it just before the switch because I'm not sure if I could easily add the commits (commits on different branches and especially merges) you do between now and the switch. I was too missing a few committer names - see the original email here http://lists.uvena.de/geany-devel/2010-June/002672.html which I'd need to get first before performing the conversion. I could also ask the one that successfully converted our Rockbox svn repo to git, including proper branch, tag and author conversion, to write up the steps it needed. I think it was less than a day of work for him (and the Rockbox tree and history is considerably larger and more complicated than Geany's). Best regards. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Glade Code Generation and GtkBuilder
Hey Matthew, On 29 August 2011 17:53, Matthew Brush wrote: > Hi, > > I was messing around with Geany code to see what it would take to compile it > against GTK+ 3 (just for fun). There doesn't seem to be too many changes > needed, with one *massive* exception: the old code generated by old glade > versions. You have some weird concept of fun :-) > > At some point in the (possibly distant) future, Geany will (I think) either > need to switch to using GtkBuilder or just hack-by-hand the `interface.c` > file (eww), since the old Glade version generates what will be deprecated > code, and newer Glade versions don't generate code. As Geany only just went to GTK 2.12 this is the first time that the problem can be considered. Already the old glade needs a patch help to compile (the tool itself) on modern machines. So it may not be so far away. Personally I am not a big fan of Glade, it seems to me to only build lowest common denominator UIs, but that may be just me. > > Has anyone thought about what would be needed to switch from using the > current generated C UI code to using GtkBuilder? You can actually open the > old Glade file in Glade3 and resave it as GtkBuilder XML (with minor > issues), but it seems like there would need to be a whole lot of work to > actually use it. Well IIRC so long as the Glade file was properly laid out most of interface.c functionality was done by the builder. > > At a glance, it seems like most widgets are accessed through > `ui_lookup_widget()`, so it seems like it would make sense to have that > function somehow call `gtk_builder_get_object()` to find the widget. If all > the Glade widgets are lookup up through this single function, that will > probably work to our advantage. I'm not sure how else widgets are accessed, > or how many are added outside of the `interface.c` file (vte?) or if that > matters. Rather a lot are added outside of glade since the Glade built interface isn't flexible, eg all of build menu and build commands dialogs since their length can change. But I don't think thats a problem, they don't care where the other widgets came from, so long as the pointer to the widget they attach to is still there then they are happy. I'm not sure how much is done by ui_lookup_widget() and how much by global pointers, but so long as the pointers are still there... > > It seems like the callbacks should get connected when > `gtk_builder_connect_signals()` is called since they seem to stick around > fine in the GtkBuilder XML file. I guess this part might not be too much > problem. > Can we fix the names, please please, foo1 foo2 foo3 is really annoying, its hard to tell which is the one I want, if we need to break the thing lets put it back together properly. > I was hoping to start gathering some ideas on the best way to make this > transition, even though it may be far off in the future. It seems to me > like it will require quite extensive changes, potentially producing tons of > non-obvious bugs popping up in obscure corners of the code. Sounds like a case for an experimental branch, do you know a good VCS? > > Maybe I'm over-estimating the scope of the change. Is there some > silver-bullet approach that will make this trivial? I've only been involved in doing this once, it wasn't too bad, but I think that UI was a bit better put together than Geany, but Geany is much smaller than it was. It is a couple of years ago so the memory is a bit hazy. I'm afraid the only bullets involved, silver or otherwise, were the ones we shot into our own feet :-) Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Glade Code Generation and GtkBuilder
Hi, I was messing around with Geany code to see what it would take to compile it against GTK+ 3 (just for fun). There doesn't seem to be too many changes needed, with one *massive* exception: the old code generated by old glade versions. At some point in the (possibly distant) future, Geany will (I think) either need to switch to using GtkBuilder or just hack-by-hand the `interface.c` file (eww), since the old Glade version generates what will be deprecated code, and newer Glade versions don't generate code. Has anyone thought about what would be needed to switch from using the current generated C UI code to using GtkBuilder? You can actually open the old Glade file in Glade3 and resave it as GtkBuilder XML (with minor issues), but it seems like there would need to be a whole lot of work to actually use it. At a glance, it seems like most widgets are accessed through `ui_lookup_widget()`, so it seems like it would make sense to have that function somehow call `gtk_builder_get_object()` to find the widget. If all the Glade widgets are lookup up through this single function, that will probably work to our advantage. I'm not sure how else widgets are accessed, or how many are added outside of the `interface.c` file (vte?) or if that matters. It seems like the callbacks should get connected when `gtk_builder_connect_signals()` is called since they seem to stick around fine in the GtkBuilder XML file. I guess this part might not be too much problem. I was hoping to start gathering some ideas on the best way to make this transition, even though it may be far off in the future. It seems to me like it will require quite extensive changes, potentially producing tons of non-obvious bugs popping up in obscure corners of the code. Maybe I'm over-estimating the scope of the change. Is there some silver-bullet approach that will make this trivial? Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
