Kazunobu Kuriyama wrote: > TLDR; Attached are two patches to address the same issue as that of Patch > 7.4.1792 by Christian Brabandt, but for the Athena, Motif, GTK2 and GTK3 > GUIs. All those patches are about removal of code duplication and hence > share the same purpose in common. > > (The rest of this message is for reviewers...) > > As for the Athena and Motif GUIs, there’s a discrepancy between the color > name database hardcoded in gui_mch_get_color() of gui_x11.c and that in > gui_get_color_cmn() of term.c. One of the proposed patches addresses this > issue. In particular, the pixel values of lightred and lightmagenta are > corrected. > > The same patch removes the code block for a locale-dependent search, which > becomes unnecessary once we adopt our own color name decoding of term.c. > > It also removes a static function called find_closest_color(). > > The current implementation calls the function when XAllocColor() fails. > > According to XAllocColor(1), however, this function “allocates a read-only > colormap entry corresponding to the closest RGB value supported by the > hardware” for a given RGB value passed across to as an argument of the > function. > > Therefore, at least in theory, in case XAllocColor() should fail, there > would be no chance for find_closest_color() to find and allocate another > “closest color.” That’s why it should be removed. > > As for GTK2 and GTK3 GUIs, the most remarkable difference that will be > resulted from another proposed patch is the differences in the pixel values > of gray, green, maroon and purple. > > Fortunately, Patch 7.4.2073 was included yesterday, which makes the > explanation below easier. > > If you skim the updated rgb.txt, you’ll find there’re new names such as > X11<color name>s and Web<color name>s. > > Although GDK’s color allocation function accepts the same color names as > X11’s, it uses the values for Web<color name>s. > > That’s why :runtime syntax/colortest.vim shows the green that is darker > than the dark green on the GTK2 and GTK3 GUIs. > > By making use of our own color name decoding, the patch addresses this > issue as well as other colors’. > > In addition, as for the GTK3 code, the deprecated GdkColor is replaced with > GdkRGBA. As a result, GdkVisual (an abstraction of the visual > characteristics of a display monitor in use) is completely eliminated from > the code. This allows us to assume that guicolor_T is always in the form > of 0x00rrggbb and not to be worried about stuff like monochrome, gray > scale, static color, pseudo color, true color, direct color, bits per > pixel, masks, and significant bit, i.e., characteristics of the underlying > hardware.
Most systems have 8 bit color now anyway. Unless someone objects I'll include this soon. -- Courtroom Quote #19: Q: Doctor, how many autopsies have you performed on dead people? A: All my autopsies have been performed on dead people. /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
