Geany Dev Team:
I have various ideas for Geany (that do not pertain to the file-extensions and language support) that I would like to share before I write or submit any code.
Also, I found an issue on Geany.org. On http://wiki.geany.org/config/scripts/shell , there is a deadlink ( https://svn.enlightenment.org/svn/e/trunk/devs/discomfitor/geany_tagger.sh ).
By the way, thank you again, Matthew Brush, for the link to QML on Geany. I then found http://wiki.geany.org/config/start . Why are many of these "goodies" not in the mainstream Geany release?
Unless I over-looked it in http://www.geany.org/Contribute/Developers , I assume discussion on plugin and color-scheme development are allowed in this mailing list, or is there a separate mailing list?
*Ideas*
I noticed that on Geany's GitHub page under ./data/templates, there are two license templates ("gpl" and "bsd"). These templates appear in the "Edit > Insert Comments" menu. I would like to add some more license templates and include them in the menu. Does anyone disagree with this idea? I would like to add agpl, lgpl2, lgpl3, gpl3, cc0, and others. To make it easier to add menu items, could Geany be re-programmed to dynamically create that menu based on the templates included in ./data/templates and ~/.config/geany/templates , thus allowing users to add licenses to their own systems?
In my opinion, ./data/templates/gpl be renamed to ./data/templates/gpl2 to indicate that this is version 2 of the GNU General Public License. Also, should the menu entry explicitly indicate version 2?
To improve the highlighting used by C source-code, could "bool" be added to "primary=" in ./data/filetypes.c? "bool" existed since C99 ( http://pubs.opengroup.org/onlinepubs/9699919799/ && https://en.wikipedia.org/wiki/C_data_types#stdbool.h ). Also, what about "true" and "false" (lowercase) as seen in the <stdbool.h>? Currently, in Geany, "bool" looks like a variable (no highlighting) while other data-types use highlighting. True, "bool" is not in the "core" C-language without libraries, but it seems to me that "bool" should be added.
Could more "Independent commands" and "Filetype commands" be added to the "Set Build Commands" window opened under "Build > Set Build Commands"? On my system, for C and Python, I have all of the entries filled, but I need to add more.
I would also like to add additional "Build > Set Build Commands" commands to various languages. Are there any objections to me doing so? Obviously, I will share such ideas and apply the given feedback before submitting a PR.
Soon, I will experiment with compiling Geany using various GCC compiler flags and parameters. When I perform such an experiment, would you like me to share my results about successful, unsuccessful, and optimized compiling options (with included benchmarks)? For instance, I have configured and compiled the Linux kernel src for my system, and I have seen significant improvements in memory usage, speed, boot-up time, etc.. Afterwards, I had become interested in compiling source code myself rather than using the pre-compiled *.deb files. I would like to see if I can make Geany faster and more light-weight (on RAM). Since I will be doing such an experiment, the Geany Dev Team may find the results of my experiment to be beneficial to the project.
On 10 November 2015 at 03:08, Devyn Collier Johnson devyncjohnson@gmail.com wrote:
Geany Dev Team:
I have various ideas for Geany (that do not pertain to the file-extensions and language support) that I would like to share before I write or submit any code.
Also, I found an issue on Geany.org. On http://wiki.geany.org/config/scripts/shell , there is a deadlink ( https://svn.enlightenment.org/svn/e/trunk/devs/discomfitor/geany_tagger.sh ).
The wiki is, well a wiki, that means pages can be added by anyone who has registered (registration required to discourage spammers). The Geany dev team does not spend much time looking at the wiki and does not necessarily check it for accuracy. It would be best to try to contact the page author.
By the way, thank you again, Matthew Brush, for the link to QML on Geany. I then found http://wiki.geany.org/config/start . Why are many of these "goodies" not in the mainstream Geany release?
Because the authors or devs don't want to have to support them. You will notice contributions from Geany devs on the wiki, not in geany, thats because they do not have the time and inclination to test and support these things, but are happy for them to be available to others.
Unless I over-looked it in http://www.geany.org/Contribute/Developers , I assume discussion on plugin and color-scheme development are allowed in this mailing list, or is there a separate mailing list?
The dev list is more for development details, ie how something needs to be implemented. Discussions of user facing stuff (colour schemes, new plugins) should probably be on the user list where it might get more contributions about its usefullness or how it should work.
Ideas
I noticed that on Geany's GitHub page under ./data/templates, there are two license templates ("gpl" and "bsd"). These templates appear in the "Edit > Insert Comments" menu. I would like to add some more license templates and include them in the menu. Does anyone disagree with this idea? I would like to add agpl, lgpl2, lgpl3, gpl3, cc0, and others. To make it easier to add menu items, could Geany be re-programmed to dynamically create that menu based on the templates included in ./data/templates and ~/.config/geany/templates , thus allowing users to add licenses to their own systems?
There was a discussion in the past about what licenses to add, try searching the MLs (user and dev) and the issues (and the olde sourceforge issues if you can) to find the discussion. Whatever is in Geany is the result of those discussions.
In my opinion, ./data/templates/gpl be renamed to ./data/templates/gpl2 to indicate that this is version 2 of the GNU General Public License. Also, should the menu entry explicitly indicate version 2?
Probably, and which BSD too. Pull requests are welcome.
To improve the highlighting used by C source-code, could "bool" be added to "primary=" in ./data/filetypes.c? "bool" existed since C99 ( http://pubs.opengroup.org/onlinepubs/9699919799/ && https://en.wikipedia.org/wiki/C_data_types#stdbool.h ). Also, what about "true" and "false" (lowercase) as seen in the <stdbool.h>? Currently, in Geany, "bool" looks like a variable (no highlighting) while other data-types use highlighting. True, "bool" is not in the "core" C-language without libraries, but it seems to me that "bool" should be added.
It is defined by the tags made from parsing the system headers into C99.tags. Perhaps its not defined as a type in stdbool.h?
Could more "Independent commands" and "Filetype commands" be added to the "Set Build Commands" window opened under "Build > Set Build Commands"? On my system, for C and Python, I have all of the entries filled, but I need to add more.
See the manual, that is already possible.
I would also like to add additional "Build > Set Build Commands" commands to various languages. Are there any objections to me doing so? Obviously, I will share such ideas and apply the given feedback before submitting a PR.
Or you can submit a PR and the discussion can be there. Just keep the PR tightly focussed. Of course if its a general idea applicable to multiple PRs, discuss it on the ML first.
Soon, I will experiment with compiling Geany using various GCC compiler flags and parameters. When I perform such an experiment, would you like me to share my results about successful, unsuccessful, and optimized compiling options (with included benchmarks)?
Its not a problem to share them, just don't be disappointed if your ideas are not used. The (few) options set by default in the Geany configure are ones that will work in a wide range of places and I suspect we would be reluctant to add any specific ones in case they caused issues in some places (I can't even get --no-deprecated added :). Since distribution packagers set their own flags and options to suit their distro, defaults in Geany may not have any effect on actual distributed versions of Geany anyway.
Again this is something you may want to add to the wiki so those few users interested in building their own highly optimised Geany can see what worked for you.
Also I suspect most work in Geany is in GTK so your results might not be significant.
For instance, I have configured and
compiled the Linux kernel src for my system, and I have seen significant improvements in memory usage, speed, boot-up time, etc.. Afterwards, I had become interested in compiling source code myself rather than using the pre-compiled *.deb files. I would like to see if I can make Geany faster and more light-weight (on RAM).
The RAM for code is pretty small, my 64 bit libgeany is 18Mb *including symbols and debugging data*, which is a fraction of the memory used for the files I have open. And *most* of the memory for files is used in Scintilla and GTK, again things we can't influence.
Cheers Lex
Since I will be doing such an experiment, the Geany Dev Team may find the results of my experiment to be beneficial to the project.
-- Thanks, Devyn Collier Johnson DevynCJohnson@Gmail.com
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
...
To make it easier to add menu items, could Geany be re-programmed to dynamically create that menu based on the templates included in ./data/templates and ~/.config/geany/templates , thus allowing users to add licenses to their own systems?
PS Since you really should add the license when the file is created, not paste it into a file later, what I do is to add licenses as file templates http://www.geany.org/manual/current/index.html#file-templates which appear in the create dropdown list. Things like apache.hpp and apache.cpp for example.
Cheers Lex
On 10/11/2015 02:32, Lex Trotman wrote:
On 10 November 2015 at 03:08, Devyn Collier Johnson
To improve the highlighting used by C source-code, could "bool" be added to "primary=" in ./data/filetypes.c? "bool" existed since C99 ( http://pubs.opengroup.org/onlinepubs/9699919799/ && https://en.wikipedia.org/wiki/C_data_types#stdbool.h ). Also, what about "true" and "false" (lowercase) as seen in the <stdbool.h>? Currently, in Geany, "bool" looks like a variable (no highlighting) while other data-types use highlighting. True, "bool" is not in the "core" C-language without libraries, but it seems to me that "bool" should be added.
It is defined by the tags made from parsing the system headers into C99.tags. Perhaps its not defined as a type in stdbool.h?
`bool` is not really a type in C, it's a macro expanding to _Bool -- and even, applications are explicitly allowed to undefine `bool`, `false` and `true` at their convenience.
This said, we could probably indeed have `bool`, `false` and `true` in filetypes.c's `primary=` list (especially as we do have `FALSE` and `TRUE` which aren't even defined in standard C). Technically those aren't keywords [1], but I guess it'd be convenient to have them -- yet one has to remember those are library extensions only available through stdbool.h.
Regards, Colomban
[1] see i.e. section 6.4.1§1 in the ISO/IEC 9899:201x n1570 draft
On 11/10/2015 09:50 AM, Colomban Wendling wrote:
On 10/11/2015 02:32, Lex Trotman wrote:
On 10 November 2015 at 03:08, Devyn Collier Johnson
To improve the highlighting used by C source-code, could "bool" be added to "primary=" in ./data/filetypes.c? "bool" existed since C99 ( http://pubs.opengroup.org/onlinepubs/9699919799/ && https://en.wikipedia.org/wiki/C_data_types#stdbool.h ). Also, what about "true" and "false" (lowercase) as seen in the <stdbool.h>? Currently, in Geany, "bool" looks like a variable (no highlighting) while other data-types use highlighting. True, "bool" is not in the "core" C-language without libraries, but it seems to me that "bool" should be added.
It is defined by the tags made from parsing the system headers into C99.tags. Perhaps its not defined as a type in stdbool.h?
`bool` is not really a type in C, it's a macro expanding to _Bool -- and even, applications are explicitly allowed to undefine `bool`, `false` and `true` at their convenience.
This said, we could probably indeed have `bool`, `false` and `true` in filetypes.c's `primary=` list (especially as we do have `FALSE` and `TRUE` which aren't even defined in standard C). Technically those aren't keywords [1], but I guess it'd be convenient to have them -- yet one has to remember those are library extensions only available through stdbool.h.
Regards, Colomban
[1] see i.e. section 6.4.1§1 in the ISO/IEC 9899:201x n1570 draft _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Geany Dev Team:
Thank you everyone for your insightful and helpful feedback and comments.
I understand that package maintainers compile the code themselves. I am mainly referring to the default compiling options used by Geany or the suggested compilation process used in README files. However, I did some testing, and I did not see any noticeable performance improvements. In other words, my tests show that the defaults are fine. Even when compiling with flags that disable or remove debugging, the Geany executable is not smaller and the memory usage is the same (even when using "strip --strip-debug --strip-unneeded ./geany"). When compiling Geany, I did see many deprecation and pointer warnings (mainly with GTK).
By the way, what does "--enable-force" do to the building process? Is it simply a joke?
I am not disappointed if my code is not merged. I understand that the team needs to ensure that Geany is fast, stable, and lightweight. Plus, this is not "my" project, so I do not expect to have all my ideas implemented just because "I" suggest something.
I will be sure to consider contributing to the Wiki.
Lex, true, licenses could be added as file templates. However, using "Edit > Insert Comments > SOME-LICENSE" is not dependent on the programming language.
Matthew and Lex, so which mailing list is the correct one for plugin development? You each suggested a different mailing list.
Matthew, as far as adding license templates, I think must be added to Geany because placing a license template in ~/.config/geany/filedefs/templates and /usr/share/geany/templates does not add the new license to "Edit > Insert Comments". I even tried closing Geany and re-opening it and reloading the configuration.
I strongly agree with Colomban Wendling about adding "bool", "true", and "false" to "primary=" in filetypes.c.
-- Thanks, Devyn Collier Johnson DevynCJohnson@Gmail.com
Geany Dev Team:
Thank you everyone for your insightful and helpful feedback and comments.
I understand that package maintainers compile the code themselves. I am mainly referring to the default compiling options used by Geany or the suggested compilation process used in README files. However, I did some testing, and I did not see any noticeable performance improvements. In other words, my tests show that the defaults are fine. Even when compiling with flags that disable or remove debugging, the Geany executable is not smaller and the memory usage is the same (even when using "strip --strip-debug --strip-unneeded ./geany").
It may not strip much, the symbols are needed for plugins to work, so they won't strip (or if they did plugins would probably fail).
When compiling Geany, I did see many deprecation and pointer warnings (mainly with GTK).
There are heaps of deprecation warnings with GTK3, hence my previous comment about adding --no-deprecate, but there shouldn't be any with GTK2.
What pointer warnings do you get?
By the way, what does "--enable-force" do to the building process? Is it simply a joke?
Probably, maybe it should be updated to a newer meme, although there is a new star wars coming soon :).
I am not disappointed if my code is not merged. I understand that the team needs to ensure that Geany is fast, stable, and lightweight. Plus, this is not "my" project, so I do not expect to have all my ideas implemented just because "I" suggest something.
I will be sure to consider contributing to the Wiki.
Lex, true, licenses could be added as file templates. However, using "Edit > Insert Comments > SOME-LICENSE" is not dependent on the programming language.
The templates can be given an extension, and that will even create the file with that extension, and set the filetype from it. Thats why I said I have apache.hpp and apache.cpp as templates.
Matthew and Lex, so which mailing list is the correct one for plugin development? You each suggested a different mailing list.
Actually we are saying the same thing in differing ways :)
See http://www.geany.org/Support/MailingList, the development list is for development, the user list is for stuff users might care about. Many users are not subscribed to the devel list so if you want comments from the general user community (like how should the UI work) you should use that.
But its the same lists for both plugins and geany itself, sorry for the confusion.
Matthew, as far as adding license templates, I think must be added to Geany because placing a license template in ~/.config/geany/filedefs/templates and /usr/share/geany/templates does not add the new license to "Edit > Insert Comments". I even tried closing Geany and re-opening it and reloading the configuration.
Yes, the templates are added to the "create file" dropdown, they are *file* templates, ie a template for a new file.
I strongly agree with Colomban Wendling about adding "bool", "true", and "false" to "primary=" in filetypes.c.
What you mean they won't change stdbool.h just for us :)
-- Thanks, Devyn Collier Johnson DevynCJohnson@Gmail.com
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 11/10/2015 06:04 PM, Lex Trotman wrote:
Geany Dev Team:
Thank you everyone for your insightful and helpful feedback and comments.
I understand that package maintainers compile the code themselves. I am mainly referring to the default compiling options used by Geany or the suggested compilation process used in README files. However, I did some testing, and I did not see any noticeable performance improvements. In other words, my tests show that the defaults are fine. Even when compiling with flags that disable or remove debugging, the Geany executable is not smaller and the memory usage is the same (even when using "strip --strip-debug --strip-unneeded ./geany").
It may not strip much, the symbols are needed for plugins to work, so they won't strip (or if they did plugins would probably fail).
When compiling Geany, I did see many deprecation and pointer warnings (mainly with GTK).
There are heaps of deprecation warnings with GTK3, hence my previous comment about adding --no-deprecate, but there shouldn't be any with GTK2.
What pointer warnings do you get?
By the way, what does "--enable-force" do to the building process? Is it simply a joke?
Probably, maybe it should be updated to a newer meme, although there is a new star wars coming soon :).
I am not disappointed if my code is not merged. I understand that the team needs to ensure that Geany is fast, stable, and lightweight. Plus, this is not "my" project, so I do not expect to have all my ideas implemented just because "I" suggest something.
I will be sure to consider contributing to the Wiki.
Lex, true, licenses could be added as file templates. However, using "Edit > Insert Comments > SOME-LICENSE" is not dependent on the programming language.
The templates can be given an extension, and that will even create the file with that extension, and set the filetype from it. Thats why I said I have apache.hpp and apache.cpp as templates.
Matthew and Lex, so which mailing list is the correct one for plugin development? You each suggested a different mailing list.
Actually we are saying the same thing in differing ways :)
See http://www.geany.org/Support/MailingList, the development list is for development, the user list is for stuff users might care about. Many users are not subscribed to the devel list so if you want comments from the general user community (like how should the UI work) you should use that.
But its the same lists for both plugins and geany itself, sorry for the confusion.
Matthew, as far as adding license templates, I think must be added to Geany because placing a license template in ~/.config/geany/filedefs/templates and /usr/share/geany/templates does not add the new license to "Edit > Insert Comments". I even tried closing Geany and re-opening it and reloading the configuration.
Yes, the templates are added to the "create file" dropdown, they are *file* templates, ie a template for a new file.
I strongly agree with Colomban Wendling about adding "bool", "true", and "false" to "primary=" in filetypes.c.
What you mean they won't change stdbool.h just for us :)
-- Thanks, Devyn Collier Johnson DevynCJohnson@Gmail.com
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Geany Dev Team:
When running "strip --strip-debug --strip-unneeded ./FILE", only symbols related to debugging and unused symbols are removed. I use this strip command on all shared/dynamic libraries and executable programs that I make as well as some of my system binaries (like /usr/bin/python3.4 and my custom compiled Linux kernel and modules). I have not yet had any problems. True, removing all symbols (strip --strip-all) would cause issues with some applications and most (if not all) shared libraries.
As for the license templates, I think you and I are thinking of two different things. I am not referring to /usr/share/geany/templates/files . I am talking about /usr/share/geany/templates . True, your apache.cpp would go in /usr/share/geany/templates/files to appear in the "File > New (with template)" sub-menu. However, I want to add licenses to the "Edit > Insert Comments" sub-menu. Then, in a file with code, I could select a license to insert. Geany automatically adds the multi-line comment for the detected language. If a language is not detected by Geany, I could make a multi-line comment and select a license to insert. (Example below)
/* Place cursor here, choose a license under "Edit > Insert Comments", and the license info is instantly inserted. Such license templates under "Edit > Insert Comments" */
I tested the "gpl" and "bsd" license templates that are already in the mainstream Geany release in the "Edit > Insert Comments" sub-menu. These license templates are "universal". In other words, they work in any computer language's source code. However, this feature would be more beneficial if there were more licenses to choose from. I like to use LGPLv3 in many of my libraries, but Geany does not have that in the license list.
I get dozens of deprecated warnings when using GTK2 (that is not a typo, I do indeed mean "GTK2").
As for the pointer warnings, I saw several (but they relate to GTK2 rather than Geany itself). Below is one such warning. By the way, the displayed errors in this email were generated with "./configure -v --enable-html-docs=no --prefix=$HOME/Geany --exec-prefix=$HOME/Geany --disable-nls".
dialogs.c:1001:15: warning: assignment makes pointer from integer without a cast [-Wint-conversion] data->combo = gtk_combo_box_text_new_with_entry();
There were also a few "implicit declaration of function" warnings. One is seen below.
dialogs.c: In function 'dialogs_show_input_full': gtkcompat.h:57:44: warning: implicit declaration of function 'gtk_combo_box_entry_new_text' [-Wimplicit-function-declaration] # define gtk_combo_box_text_new_with_entry gtk_combo_box_entry_new_text ^ dialogs.c:1001:17: note: in expansion of macro 'gtk_combo_box_text_new_with_entry' data->combo = gtk_combo_box_text_new_with_entry();
If you would like the complete terminal output from the building process, I would be happy to put it on the ML as an attached text-file as well as a detailed list of information about my libraries, compiler, Linux system, etc. Below is some of the most relevant information.
Ubuntu 15.10 (Willy) x86-64 Little-Endian; Intel i5 (Haswell) 2.5GHz
$ uname -somr Linux 4.2.399-dcj-20151017 x86_64 GNU/Linux
$ gcc --version gcc (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010
$ ldd --version ldd (Ubuntu GLIBC 2.21-0ubuntu4) 2.21
$ dpkg -s libgtk2.0-0|grep '^Version' Version: 2.24.28-1ubuntu1
# Available CPU flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_go
-- Thanks, Devyn Collier Johnson DevynCJohnson@Gmail.com
Geany Dev Team:
When running "strip --strip-debug --strip-unneeded ./FILE", only symbols related to debugging and unused symbols are removed. I use this strip command on all shared/dynamic libraries and executable programs that I make as well as some of my system binaries (like /usr/bin/python3.4 and my custom compiled Linux kernel and modules). I have not yet had any problems. True, removing all symbols (strip --strip-all) would cause issues with some applications and most (if not all) shared libraries.
Not sure if the standard build uses -g so maybe there is not much debug stuff to strip.
As for the license templates, I think you and I are thinking of two different things.
Possibly, see the pull request comment.
I am not referring to /usr/share/geany/templates/files . I am talking about /usr/share/geany/templates . True, your apache.cpp would go in /usr/share/geany/templates/files to appear in the "File > New (with template)" sub-menu. However, I want to add licenses to the "Edit > Insert Comments" sub-menu. Then, in a file with code, I could select a license to insert. Geany automatically adds the multi-line comment for the detected language. If a language is not detected by Geany, I could make a multi-line comment and select a license to insert. (Example below)
/* Place cursor here, choose a license under "Edit > Insert Comments", and the license info is instantly inserted. Such license templates under "Edit > Insert Comments" */
I tested the "gpl" and "bsd" license templates that are already in the mainstream Geany release in the "Edit > Insert Comments" sub-menu. These license templates are "universal". In other words, they work in any computer language's source code. However, this feature would be more beneficial if there were more licenses to choose from. I like to use LGPLv3 in many of my libraries, but Geany does not have that in the license list.
I get dozens of deprecated warnings when using GTK2 (that is not a typo, I do indeed mean "GTK2").
Strange, none of the devs get any (AFAIK) with GTK2. Thats why I checked. Can you paste the messages in a gist somewhere. And exactly the CFLAGS/CPPFLAGS and options you used.
As for the pointer warnings, I saw several (but they relate to GTK2 rather than Geany itself). Below is one such warning. By the way, the displayed errors in this email were generated with "./configure -v --enable-html-docs=no --prefix=$HOME/Geany --exec-prefix=$HOME/Geany --disable-nls".
dialogs.c:1001:15: warning: assignment makes pointer from integer without a cast [-Wint-conversion] data->combo = gtk_combo_box_text_new_with_entry();
There were also a few "implicit declaration of function" warnings. One is seen below.
These sound like something in gtkcompat isn't working right, maybe some flag is not set right. I'm not an expert in that area, Colomban is, but wait until after this weekends release :)
dialogs.c: In function 'dialogs_show_input_full': gtkcompat.h:57:44: warning: implicit declaration of function 'gtk_combo_box_entry_new_text' [-Wimplicit-function-declaration] # define gtk_combo_box_text_new_with_entry gtk_combo_box_entry_new_text ^ dialogs.c:1001:17: note: in expansion of macro 'gtk_combo_box_text_new_with_entry' data->combo = gtk_combo_box_text_new_with_entry();
If you would like the complete terminal output from the building process, I would be happy to put it on the ML as an attached text-file as well as a detailed list of information about my libraries, compiler, Linux system, etc. Below is some of the most relevant information.
Stick it in a gist, don't spam everybody watching the ML with big attachments :)
Ubuntu 15.10 (Willy) x86-64 Little-Endian; Intel i5 (Haswell) 2.5GHz
$ uname -somr Linux 4.2.399-dcj-20151017 x86_64 GNU/Linux
$ gcc --version gcc (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010
$ ldd --version ldd (Ubuntu GLIBC 2.21-0ubuntu4) 2.21
$ dpkg -s libgtk2.0-0|grep '^Version' Version: 2.24.28-1ubuntu1
# Available CPU flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_go
-- Thanks, Devyn Collier Johnson DevynCJohnson@Gmail.com _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 11/10/2015 11:03 PM, Lex Trotman wrote:
Geany Dev Team:
When running "strip --strip-debug --strip-unneeded ./FILE", only symbols related to debugging and unused symbols are removed. I use this strip command on all shared/dynamic libraries and executable programs that I make as well as some of my system binaries (like /usr/bin/python3.4 and my custom compiled Linux kernel and modules). I have not yet had any problems. True, removing all symbols (strip --strip-all) would cause issues with some applications and most (if not all) shared libraries.
Not sure if the standard build uses -g so maybe there is not much debug stuff to strip.
As for the license templates, I think you and I are thinking of two different things.
Possibly, see the pull request comment.
I am not referring to /usr/share/geany/templates/files . I am talking about /usr/share/geany/templates . True, your apache.cpp would go in /usr/share/geany/templates/files to appear in the "File > New (with template)" sub-menu. However, I want to add licenses to the "Edit > Insert Comments" sub-menu. Then, in a file with code, I could select a license to insert. Geany automatically adds the multi-line comment for the detected language. If a language is not detected by Geany, I could make a multi-line comment and select a license to insert. (Example below)
/* Place cursor here, choose a license under "Edit > Insert Comments", and the license info is instantly inserted. Such license templates under "Edit > Insert Comments" */
I tested the "gpl" and "bsd" license templates that are already in the mainstream Geany release in the "Edit > Insert Comments" sub-menu. These license templates are "universal". In other words, they work in any computer language's source code. However, this feature would be more beneficial if there were more licenses to choose from. I like to use LGPLv3 in many of my libraries, but Geany does not have that in the license list.
I get dozens of deprecated warnings when using GTK2 (that is not a typo, I do indeed mean "GTK2").
Strange, none of the devs get any (AFAIK) with GTK2. Thats why I checked. Can you paste the messages in a gist somewhere. And exactly the CFLAGS/CPPFLAGS and options you used.
As for the pointer warnings, I saw several (but they relate to GTK2 rather than Geany itself). Below is one such warning. By the way, the displayed errors in this email were generated with "./configure -v --enable-html-docs=no --prefix=$HOME/Geany --exec-prefix=$HOME/Geany --disable-nls".
dialogs.c:1001:15: warning: assignment makes pointer from integer without a cast [-Wint-conversion] data->combo = gtk_combo_box_text_new_with_entry();
There were also a few "implicit declaration of function" warnings. One is seen below.
These sound like something in gtkcompat isn't working right, maybe some flag is not set right. I'm not an expert in that area, Colomban is, but wait until after this weekends release :)
dialogs.c: In function 'dialogs_show_input_full': gtkcompat.h:57:44: warning: implicit declaration of function 'gtk_combo_box_entry_new_text' [-Wimplicit-function-declaration] # define gtk_combo_box_text_new_with_entry gtk_combo_box_entry_new_text ^ dialogs.c:1001:17: note: in expansion of macro 'gtk_combo_box_text_new_with_entry' data->combo = gtk_combo_box_text_new_with_entry();
If you would like the complete terminal output from the building process, I would be happy to put it on the ML as an attached text-file as well as a detailed list of information about my libraries, compiler, Linux system, etc. Below is some of the most relevant information.
Stick it in a gist, don't spam everybody watching the ML with big attachments :)
Ubuntu 15.10 (Willy) x86-64 Little-Endian; Intel i5 (Haswell) 2.5GHz
$ uname -somr Linux 4.2.399-dcj-20151017 x86_64 GNU/Linux
$ gcc --version gcc (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010
$ ldd --version ldd (Ubuntu GLIBC 2.21-0ubuntu4) 2.21
$ dpkg -s libgtk2.0-0|grep '^Version' Version: 2.24.28-1ubuntu1
# Available CPU flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_go
-- Thanks, Devyn Collier Johnson DevynCJohnson@Gmail.com _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Here is the Gist URL - https://gist.github.com/DevynCJohnson/28ab4a66c7e29795b084
On 2015-11-10 9:51 PM, Devyn Collier Johnson wrote:
[...] Here is the Gist URL - https://gist.github.com/DevynCJohnson/28ab4a66c7e29795b084
You can ignore deprecation warnings. GLib/GTK+ deprecate stuff at the drop of a hat and you could drive yourself mad trying to stay on top of it before mandatory. The (somehow valid) excuse from G* team is that a deprecation is just giving information about the future, not breaking the interface. It's a bummer that this GCC attribute causes such noisy warnings often with G* libs, but it's basically the intended purpose.
On the bright side, it looks like just a single function that was deprecated this time and the same fix/workaround should stifle all those warnings at once.
Cheers, Matthew Brush
On 11 November 2015 at 16:23, Matthew Brush mbrush@codebrainz.ca wrote:
On 2015-11-10 9:51 PM, Devyn Collier Johnson wrote:
[...] Here is the Gist URL - https://gist.github.com/DevynCJohnson/28ab4a66c7e29795b084
You can ignore deprecation warnings. GLib/GTK+ deprecate stuff at the drop of a hat and you could drive yourself mad trying to stay on top of it before mandatory. The (somehow valid) excuse from G* team is that a deprecation is just giving information about the future, not breaking the interface. It's a bummer that this GCC attribute causes such noisy warnings often with G* libs, but it's basically the intended purpose.
On the bright side, it looks like just a single function that was deprecated this time and the same fix/workaround should stifle all those warnings at once.
And wonder of wonders, they actually suggested what to use instead :)
Cheers Lex
Cheers, Matthew Brush
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 11/11/2015 02:03 AM, Lex Trotman wrote:
On 11 November 2015 at 16:23, Matthew Brush mbrush@codebrainz.ca wrote:
On 2015-11-10 9:51 PM, Devyn Collier Johnson wrote:
[...] Here is the Gist URL - https://gist.github.com/DevynCJohnson/28ab4a66c7e29795b084
You can ignore deprecation warnings. GLib/GTK+ deprecate stuff at the drop of a hat and you could drive yourself mad trying to stay on top of it before mandatory. The (somehow valid) excuse from G* team is that a deprecation is just giving information about the future, not breaking the interface. It's a bummer that this GCC attribute causes such noisy warnings often with G* libs, but it's basically the intended purpose.
On the bright side, it looks like just a single function that was deprecated this time and the same fix/workaround should stifle all those warnings at once.
And wonder of wonders, they actually suggested what to use instead :)
Cheers Lex
Cheers, Matthew Brush
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Yes, I know that I can ignore "warnings". I just wanted to help ensure that Geany remains flawless and awesome. I enjoy helping this team and project.
On 2015-11-09 9:08 AM, Devyn Collier Johnson wrote:
[...]
Unless I over-looked it in http://www.geany.org/Contribute/Developers , I assume discussion on plugin and color-scheme development are allowed in this mailing list, or is there a separate mailing list?
Correct, there is no separate mailing list for Geany-Plugins or Geany-Themes development, they share with main devel list.
*Ideas*
I noticed that on Geany's GitHub page under ./data/templates, there are two license templates ("gpl" and "bsd"). These templates appear in the "Edit > Insert Comments" menu. I would like to add some more license templates and include them in the menu. Does anyone disagree with this idea? I would like to add agpl, lgpl2, lgpl3, gpl3, cc0, and others. To make it easier to add menu items, could Geany be re-programmed to dynamically create that menu based on the templates included in ./data/templates and ~/.config/geany/templates , thus allowing users to add licenses to their own systems?
It definitively should be improved to make it user-extensible, something like adding a license template shouldn't require source code and GUI modifications.
A long time ago I made a patch to add a few more licenses, but the patch doesn't improve the extensibility, it only adds to the existing hard-coded templates, and is also severely out of date, and wouldn't apply on Geany's current master branch. It is here, for reference:
https://gist.github.com/codebrainz/2353163
(Lines 1 to 11,212 are just noise caused by the GUI designer making unnecessary changes to the XML file.)
Cheers, Matthew Brush