Re: Do we still need color-limit/visual options in fvwm?

[Dan Espen]

Thomas Adam  writes:

> Hi all,
>
> Just looking through a few things, and I thought I'd ask whether fvwm needs to
> stlil support color limiting, and color depths for XServers with less than
> TrueColor?
>
> These days, 24-bit seems to be the standard, and indeed, I've never yet come
> across a server still using only 256 colours.  Whilst I appreciate you can
> still go and find such things, do we actually need fvwm to supprort it?

It's not the server, it's the hardware in the workstation
graphics card.

Back when I was using Sun hardware it was required.
I put the original code in that tried to force colors to
familiar named colors with the idea that colors with common
names would be already be in use.

A while later the old code was ifdef'd with the current
color cube logic.  I think there is no risk in removing
the common name logic but that won't reduce executable size.

I don't think the color limiting stuff is large enough to
make any difference.  If you think otherwise, consider
making it a build option.

-- 
Dan Espen

Re: Do we still need color-limit/visual options in fvwm?

[Thomas Adam]

On 7 May 2016 14:46, "Thomas Funk"  wrote:
>
> On 05/07/2016 12:40 PM, Thomas Adam wrote:
>>
>> Hi all,
>>
>> Just looking through a few things, and I thought I'd ask whether fvwm
needs to
>> stlil support color limiting, and color depths for XServers with less
than
>> TrueColor?
>>
>> These days, 24-bit seems to be the standard, and indeed, I've never yet
come
>> across a server still using only 256 colours.  Whilst I appreciate you
can
>> still go and find such things, do we actually need fvwm to supprort it?
>
>
> I would suggest to swap out the functionality into a module like bidi but
> don't know how hard it is to do that ...

That's not the point, and wouldn't help here. Shuffling code around like
this isn't an option and wouldn't achieve anything. Furthermore, there's no
need to libify depth/colour limiting, such a thing doesn't make sense. It's
a capability, not something to be used directly.

> Does removing color limiting affecting things like remote connections?

No, it wouldn't.

-- Thomas Adam

Re: Do we still need color-limit/visual options in fvwm?

[Thomas Funk]

On 05/07/2016 12:40 PM, Thomas Adam wrote:

Hi all,

Just looking through a few things, and I thought I'd ask whether fvwm needs to
stlil support color limiting, and color depths for XServers with less than
TrueColor?

These days, 24-bit seems to be the standard, and indeed, I've never yet come
across a server still using only 256 colours.  Whilst I appreciate you can
still go and find such things, do we actually need fvwm to supprort it?


I would suggest to swap out the functionality into a module like bidi but
don't know how hard it is to do that ...

Does removing color limiting affecting things like remote connections?

If so, it shouldn't be removed.

Best,
Thomas

--
--
"Two things are infinite: the universe and human stupidity; and I'm not sure about 
the the universe."   --   Albert Einstein

Do we still need color-limit/visual options in fvwm?

[Thomas Adam]

Hi all,

Just looking through a few things, and I thought I'd ask whether fvwm needs to
stlil support color limiting, and color depths for XServers with less than
TrueColor?

These days, 24-bit seems to be the standard, and indeed, I've never yet come
across a server still using only 256 colours.  Whilst I appreciate you can
still go and find such things, do we actually need fvwm to supprort it?

Kindly,
Thomas