I think that my (new) problem is that some colorsets does not apply completelly at startup.
I made another panel. Frame 1, Colorset 10, being the colorset 10 this:
Colorset 10 RootTransparent, Tint #26476F 50, fg lightsteelblue, IconAlpha 50, sh #26476F, hi #26476F
Due to the fact thar sh=hi the frame should appear flat, and it does… When I load this panel and restart the wm all is fine. The problem is when I go out X and start again. Then the thing is not the same.
The right picture:
The wrong picture:
You can see the 3d border in the wrong picture and the flat ones in the good picture. This happens when I enter fvwm from a new X session, and goes away if I just restart the wm or do "Read " into a FvwmConsole. I tried loading the colorset at the very first line of my config and copied also the line to the end of the config but it does not make any different at all. Ill keep trying but since the problem lasts since yesterday I suposed that I’d better put this here, in case someone had a similar problem and knows what could be causing it.
Interesting. I suggest you ask on the FVWM mailing-list. It might be a possible bug. But before than, I assume that’s FvwmButtons? What happens if you change the padding and relief of that button, first?
Yes, it is. FvwmButtons, with a FvwmIconMan, another panelized FvwmButtons (that is the problematic button) and a FvwmScript (the clock).
The panel is this:
I know, too much divisions, but that is just an experiment. I tried with a grid of 32 columns x 30 rows and the problem is the same (anyway the problem seems to be related only to the colorset). As you see, the padding is not defined for that button, the panel button is centered due to the fact that I define some empty spaces using my hyper-grid. I tried to play with many setting, but, unvariably the result is always the same, for some strange reason, the colorset is only applied partially, so the grey lines appear giving the 3d look. As you can see in the shots, it is not only that button that is affected, but also the FvwmScript (the text shadow is not supposed to be coloured in such a weird manner. Although, they may be two separate issues. I have to confirm if FvwmIconMan draws ok, not sure since I always restarted before running any app. I will restart X when I finish what Im doing and post here.
Now I’m busy but later I will post in the mailing lists.
Some interesting results from the mailing list. It seems that, indeed, there is something buggy in the colorsets handler. There are two possible workarounds (that I know of). Thanks goes to Mikhael Goikman
This is the relevant part of the discussion, along with the two workarounds.
On 05 Nov 2005 13:21:39 +0000, Mikhael Goikhman wrote:
>
> On 05 Nov 2005 04:13:35 +0100, 6thpink@terra.es wrote:
> >
> > Thanks for the tip, but unfortunatelly I can reproduce it even with
> > a minimal configuration file. For example this one, that essentially
> > is a background picture, and the two panels along with the colorsets
> > that they use:
>
> I can reproduce the problem with your config. Even if Exec fvwm-root is
> replaced with PipeRead `fvwm-root`. The problem "goes away" if to prefix
> the "Colorset 10" line with "Schedule 3000", but this is not the real
> solution, of course.
FYI, the problem also goes away if you replace "Exec" with "PipeRead"
and prefix the "Colorset 10" line with "AddToFunc StartFunction I".
So, maybe you should use this as the current workaround.
Basically the first one schedules the colorset definition many seconds, so it gets into scene when all is up and running (it is like to simulate a manual "Read " from FvwmConsole). The second forces synchronouly reads in the relevant parts of the code. For me the solution that works better is the scheduling, because I have the colorsets into another file and dont want to cross references between several files (i.e. adding things to StartFunction from other files).
Thanks to you also, Thomas Adam, for your help and suggestions
