Hi, 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. Best regards, Kazunobu Kuriyama -- -- 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.
x11_color_name_decoding.patch
Description: Binary data
gtk_color_name_decoding.patch
Description: Binary data
