Geany Dev Team:
As for the Scintilla lexers, you make a good point. What if "additional" lexers were made optional, i.e. they are only added if chosen during the configuration and build process (--enable-scintilla-LEXER)? This way, the "default" Geany is lightweight, but users have the final decision as to whether additional lexers are added or used. Is this a feasible idea?
Well, it is my understanding that most users do not compile Geany, they use binaries. This would not help them.
And since many who do build from scratch just use the default configure;make;make install incantation the lexers would have to be enabled by default, so it would be --disable-scintilla-LEXER.
As for how feasible it would be? Well, you have to leave out the filetype file from install, and not link the lexer, and make the code in highlightingmappings.h all wrapped in #ifdefs and the code in filetypes.c wrapped in #ifdefs and all the other places I have forgotten where filetypes are hard coded. It is of course *possible* but potentially not simple.
As for the image "compression", it is not at all like "typical compression" (i.e. Gzip). Rather, the images I am able to make smaller due to the color-map. The PNG images contain a color-map (or a palette that matches a 32-bit number to a color). "Default" PNG files (with an Alpha-channel) support 32-bit RGBA colors which is 2^32 = 4294967296 colors. In addition, "default" PNG images (with the Alpha-channel) have four channels and at least 96 bits per pixel (32 bits for the color, 64 bits or more for additional purposes). For instance, the "geany-save-all.png" file only uses less than 128 colors, so why store information on colors that are not used? That is how I reduced the size ( http://dcjtech.info/wp-content/uploads/2015/11/geany-save-all-compressed.png ). Plus, I disable interlacing, and I ensure that all metadata is stripped. Many video-games (like SuperTux) use this principle to reduce the program size, src size, and memory usage. Plus, this size and memory-usage reduction will help "make up" for all of the recent additions to Geany. True, saving several kilobytes (perhaps a whole megabyte, if we are lucky) may not be much, but every optimization adds up when we apply many optimizations and improvements. I understand that many developers dislike "micro-optimizations". However, I have seen for myself (in other programming projects) that many "micro-optimizations" can help.
Well, if you are only talking about external files then I don't think it matters, when GTK loads them they will still expand into a full bitmap. And I am *not* interested in saving a few kb, even a Mb, of disk space.
True, nothing stops me from making a PR, but why make a PR and spend time coding something that the Geany Team may not like or want? I want to ensure that I hear the team's concerns and feedback before I do anything.
Thats a good approach, and as you notice on your WTFPL query, there is often no agreement between us, so its best for you to know that up front. But also sometimes it depends on the implementation, everybody can agree on the principle, but when its implemented it can be a big change, or cause other problems and thats often not obvious until the PR stage, like the "enable lexers" suggestion above.
Cheers Lex
-- Thanks, Devyn Collier Johnson DevynCJohnson@Gmail.com
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel