At Thu, 05 Dec 2024 14:12:07 -0800, "Greg A. Woods" <[email protected]> wrote:
Subject: Re: titlebar and map window color should be reset when title changes
>
> So, I found some commented out code in win_utils.c:apply_window_name()
> that seemed to try to reload the color pairs for window titles.
>
> It was marked "/* Experimental, not yet working. */", so I enabled it
> anyway to see what would happen.
>
> Initially nothing seemed to happen so I did some more fiddling around to
> move the SetupWindow() call below the ColorPair fetching:

I had to further add some lookups of the default color values else
things got messy using uninitialised data, but now I think I have
dynamic colors working for most things that can change names, though
the icon manager still confuses the heck out of me.

I've pushed a branch "dynamic-colors", already merged into my bsdmake
fork, with all the changes I'm using:

        https://github.com/robohack/ctwm-mirror

> Perhaps this confusion has something to do with the dump of errors
> related to colors that I see on startup.  Hundreds like these (only a
> few, including the first two, are X_FreeColors -- all the rest are
> X_StoreColors, with a jump in serial numbers somewhere in the middle of
> the mess near another X_FreeColors related message):
>
> X Error of failed request:  BadAccess (attempt to access private resource 
> denied)
>   Major opcode of failed request:  88 (X_FreeColors)
>   Serial number of failed request:  5356
>   Current serial number in output stream:  5494
> X Error of failed request:  BadAccess (attempt to access private resource 
> denied)
>   Major opcode of failed request:  88 (X_FreeColors)
>   Serial number of failed request:  5357
>   Current serial number in output stream:  5494
> X Error of failed request:  BadAccess (attempt to access private resource 
> denied)
>   Major opcode of failed request:  89 (X_StoreColors)
>   Serial number of failed request:  5358
>   Current serial number in output stream:  5494

I still get these errors -- but oddly they don't seem to cause anything
to break.

--
                                        Greg A. Woods <[email protected]>

Kelowna, BC     +1 250 762-7675           RoboHack <[email protected]>
Planix, Inc. <[email protected]>     Avoncote Farms <[email protected]>

Attachment: pgpNfaRNY0l3A.pgp
Description: OpenPGP Digital Signature

Reply via email to