[Geany-Devel] More Contributions (DevynCJohnson)

[Devyn Collier Johnson]

On 11/11/2015 06:36 PM, Lex Trotman wrote:
> On 12 November 2015 at 02:07, Devyn Collier Johnson
> <devyncjohnson at gmail.com> wrote:
>> Geany Dev Team:
>>
>> I would like to provide more contributions to Geany. Is there an up-to-date
>> "to do list"?
> The github issues is a good place to start.
>
> For instance, I saw https://github.com/geany/geany/issues/742
>> ( Add AutoHotkey (*.ahk) Lexer to Geany #742); are there any objections to
>> me adding additional normal/standard Scintilla lexers to Geany?
>
> Well, nothing stops you providing a PR, but note again the comments I
> have made about demand and support, and that lexer still isn't in
> Scintilla AFAICT.  It being in Scintilla means it has passed the Neil
> quality test, increasing our confidence that it won't crash all the
> time.  You talk below about going to the trouble of trimming stuff
> like icon sizes for a few kb saving, but adding lexers *adds* to the
> size because they are compiled in, so its a cost everybody pays even
> if only a few use the language.
>
>
>> Would you
>> like me to manually update the "Credits" in the "About" window?
> Probably best if it was updated at release time as part of the release
> process.  That way it will get everyone.  And having everybody start
> updating the same string as part of their PR is likely to cause merge
> conflicts.
>
>> I remember someone on GitHub in the Geany project (I do not remember who or
>> where) mentioned something about adding WTFPL to the license templates. Is
>> that still desirable? Are there other licenses any of you would like me to
>> add in the future?
> No.  Its not really a "license" to be encouraged IMHO.
>
>> I see that http://www.geany.org/Download/Releases has binary downloads for
>> Windows and Mac OS X. Would the team like me to create pre-compiled x86-64
>> binaries (or *.deb files) for Ubuntu and Debian (for Geany v1.26)? I know
>> how to make Debian files (*.deb) that work and flawlessly pass lintian's
>> tests. I could also use "Alien" ( https://wiki.debian.org/Alien &&
>> http://joeyh.name/code/alien/ ) to make an RPM for Red-Hat-based distros.
> You can provide anything on your own site or the wiki.
>
> There is a Geany web page pointing to various other places people have
> offered various builds over the years.  Check out how many are up to
> date, and you will understand that (with the best belief in you
> persistence) we want things offered on the official site to be
> provided by us as part of the release process so they stay up to date.
>
> Of the third party sites only the Ubuntu PPA is up to date that I
> could find, but thats because its managed by the guy who does the
> Ubuntu official packages too, so he gets reminded each release.
>
> If you were to automate the process that might help, but if it has
> manual inputs then its unlikely that Colomban will want more to do
> during the release process.
>
> And even if its automated he may not want to wait for the building of
> these during the rush of release.
>
>> To reduce Geany's size and memory usage, does the team think it would be a
>> good idea for me to compress the PNG files under
>> https://github.com/geany/geany/tree/master/icons . By "compress", I do not
>> mean "Gzip" compression. Rather, I can use GIMP to re-create PNG files that
>> are smaller while still retaining the same image appearance and image
>> quality. For instance,
>> https://github.com/geany/geany/blob/master/icons/48x48/geany-save-all.png is
>> 2565bytes while I "compressed" the image to 1222bytes (
>> http://dcjtech.info/wp-content/uploads/2015/11/geany-save-all-compressed.png
>> ). This is a 52.4% size reduction (1343bytes smaller). Here are my
>> calculations: 2565 - 1222 = 1343; (1343 / 2565) * 100 = 52.4%
>>
> IMHO its not worth it, they get expanded when they are loaded so they
> still consume the same memory, all it does is add time to loading
> them.
>
>> By the way, I spent some time studying Geany's src. I hope to reduce the
>> amount of errors I make that relate to not updating related files (like when
>> I committed those new licenses without changing the related files).
> NP, nobody is expected to get it all right every time (or any time,
> except Colomban, who has to catch all the errors the rest of us make
> :).
>
>> If I
>> make another error like that in the future, please feel free to let me know
>> which additional files must be modified/updated.
> Oh we will :)
>
>> I am skilled at programming
>> (especially C and Python3). My main issue with the Geany project is knowing
>> how Geany's src is setup and what files need to be updated. However, now
>> that I looked over most of the code, I hope to reduce such errors.
>>
>> Here is a link to additional information about me and my skills -
>> http://dcjtech.info/about-the-crew/#devyncjohnson . NOTE: My website has
>> ads, but they will not harm your computer or browser.
>>
>> --
>> Thanks,
>> Devyn Collier Johnson
>> DevynCJohnson at Gmail.com
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.geany.org
>> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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?

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.

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.

--
Thanks,
Devyn Collier Johnson
DevynCJohnson at Gmail.com