Re: [dwm] [dzen] Color support for arbitrary parts of the input

> > If i have some free time i would like to write some dzens with color
> > running together with mesure.
>
> That'll be great, though mesure outputs some control characters like
> '\r'. Would it be possible to supress those?

 -n :)

If you continue getting noisy chars with -n please send me a patch.

> > > There is one known problem in menu mode, i.e. colored text will be
> > > printed as is. I'll look into solving this issue in the next couple of
> > > days.
> >
> > colored text? what do you mean?
>
> I meant that the actions 'menuexec' and 'menuprint' will not output only
> the text but also the color commands :(.
>
> > Sorry, i was thinking about the format for images but didn't get a final
> > decision yet. I'll see how you allocate these colors and i can probably
> > get a similar idea for xicon.
>
> Well, if you want multi color icons you'd need to use some larger libs
> which means more dependencies that's why I tend to support only 2 color
> icons (fg, bg) like xicon does. That would keep things small and i guess
> is just enough for most cases.

Then, if we play with 2 colors for images and texts it remains simple and with
no deps, and 1bit encoding is rather simple, so we could add a simple binary
compressor algorithm or so to make strings shorter (humans can memorize bitmaps :)

btw the format can be something like:

 ^bitmap(83d783abc80018)

The 'problem' is that we should be able to define the size of the icon. And this
must be problematic and make the code more difficult with variable length strings,
buffers and so, code will be larger and not more useful.

What we can do is to define the color palete and the depth before providing the bitmap
in a format like:

 ^bitmap(4:83dbc78a69087)

 We can get the foreground color with ^fg() and the background one with ^bg(). But
what about the rest?

The resolution also anoyis me because i don't know how to manage this. probable to make
this stuff easier and simpler we can just provide proportional bitmaps (N x N) and not
(M x N). And only 2 colors:

 ^bitmap(32:832u84jf03847u8219ru1083471203)

  ^.---- this is 32x32 pixels image with the content defined by the following string.

The string can be encoded in base64 or something more optimal than plain hexadecimal.

The problematic I see with 2 color images is that it's not very nice graphically talking
and if you're drawing a diagonal line you'll get an ugly stairs effect.

Another random idea is to provide a multiple color layer pushing one color on top of the
previous one, like splitting the image per colors and serialize each color:

^bitmap(red:jksldafjaskldfjasklf,blue:jaklsdfjaklsfjslk)

So, only the defined bits will be colorized, the other will be ignored (alpha-like)

arf arf arf :) let me know what do you think about all these things.

--pancake
Received on Tue Jul 17 2007 - 12:35:04 UTC