Subject: FvwmBanner: PNG or Colorset support and more

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 5 Jun 2003 15:39:45 +0000

We don't seem to have the png or colorset support in FvwmBanner.

So if a logo with an alpha channel wins, we will not be able to show it
as nicely as we could with such support.

Is it hard to add the colorset or png support to FvwmBanner?

Additionally, I would like to have the following in FvwmBanner.

  * add the logo that we have right now on the web like Dan suggested
  * add options -0 and -c --colorful, -r --reduced, -m --mono that mean:
     -c - use colorful banner (from the web, will be the default for now)
     -r - use up to 20 colors banner (it is used in FvwmBanner right now)
     -m - use b&w xbm banner (it is used right now if needed)
  * when we have a winner logo, we will add option -1 (the new default),
    we may also add more nice logos in the future (options -2, -3 etc)

For each built-in logo, 3 images are supplied. If color options are not
specified, then -c is used on good video, falling to -r on 8bpp, and to
-m on 1bpp.

Is this acceptable?

Regards,
Mikhael.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 5 Jun 2003 18:16:24 +0200

> Is it hard to add the colorset or png support to FvwmBanner?

Probably not difficult.  Keep in mind that if the image comes from
a colöour set, the reserved space is not freed when the banner
closes.

> Is this acceptable?

Only if the various logos can be downloaded separately.  We don't
want to distribute 3x3 or even more images in the tarball.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 5 Jun 2003 16:52:00 +0000

On 05 Jun 2003 18:16:24 +0200, Dominik Vogt wrote:
> a col?our set, the reserved space is not freed when the banner
> closes.

Yes, the colorset support is not really needed if there is PNG support.

> want to distribute 3x3 or even more images in the tarball.

If we don't build-in several logos, then it is useless to speak about
these options, the current hardcoded logic already handles xpm/xbm.
And the user may just supply the image he downloaded, no options needed.

I don't see a problem to distribute 2-3 logos in 3 variants (or include
them all into C source if they are xpm/xbm). My FvwmBanner binary is
677052 bytes with -g used (default), adding 3 more 10-40Kb images does
not make an appreciable difference. I am more than sure not everyone will
like the new FvwmBanner logo, so we may include several nice logos.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 6 Jun 2003 09:15:10 +0200

> like the new FvwmBanner logo, so we may include several nice logos.

I'm speaking about tarball size, not executable size.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 6 Jun 2003 07:38:12 +0000

> I'm speaking about tarball size, not executable size.

So it will be 2283442 instead of 2243442 for each new logo. Why not?
It is still much less than some applications like emacs, perl, mozilla,
linux kernel. Even the size of zsh sources (one single executable) are
comparable with fvwm. And one may think fvwm does more than all these
together. (Yes, this last sentence is a joke.)

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 6 Jun 2003 10:12:57 +0200

> So it will be 2283442 instead of 2243442 for each new logo. Why not?

Because the gain you get for the additional size is close to zero.
It's against the philosophy fvwm development always hung on to.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 6 Jun 2003 10:42:33 +0000

> It's against the philosophy fvwm development always hung on to.

Well, for me it is vice versa, the gain is big (more happy users) and the
cost is close to zero (we already build in a logo in several variants).
But I don't want to force it.

Regards,
Mikhael.

---

From: Alex Wallis <[email-masked]>
Date: Fri, 06 Jun 2003 20:56:12 +0930

> But I don't want to force it.

How about including new banners in an updated fvwm-icons package? Then
it is left up to the users themselves if they want to upgrade those or
not?

Alex

---

From: Dan Espen <[email-masked]>
Date: Fri, 06 Jun 2003 07:56:55 -0400

> it is left up to the users themselves if they want to upgrade those or

I think Mikhael is trying to upgrade the builtin banner
which I think is a good idea.

I also agree with Dominik, we should strive to
keep the base package as small as possible.

-- 
Dan Espen                           E-mail: [email-masked]

---

From: Alex Wallis <[email-masked]>
Date: Fri, 06 Jun 2003 21:50:40 +0930

Dan Espen wrote:
> > > them all into C source if they are xpm/xbm). 
> >

I agree with both of them too, but I thought the disagreement was about
extra banners and not the default built-in. Sorry if I misunderstood.

Alex

---

From: Dan Espen <[email-masked]>
Date: Fri, 06 Jun 2003 08:34:14 -0400

> extra banners and not the default built-in. Sorry if I misunderstood.

Oops.  Too early for me.

Yep, rereading the original proposal, I don't see the need either.
One banner will do.  The builtin color limiting should take care
of the color options.

I only really care about the default banner looking better.

---

From: Olivier Chapuis <[email-masked]>
Date: Fri, 6 Jun 2003 17:41:24 +0200

> We don't seem to have the png or colorset support in FvwmBanner.

There is png "support" in FvwmBanner. There is just a bug ... fixed
soon (I hope).

However, the support is limited: no alpha blending! if a point has
an alpha of <= 130 then the point is removed and if the alpha > 130
the point is fully displayed ...

Now, we can add alpha blending but on what? X has no translucent
support ... So, we can either (if the image has some alpha):

1 - blend vs the Root window (need ParentalRelativity Style)
2 - or over a colorset background
3 - or over a colorset background without the shape from the image.

1 and 2 may look ugly under certains situations. For example,
with 1 and FvwmBanner over an other window than the root window.
So, 3 can be a default (with colorset 0). This leads to new options:

*FvwmBanner: Colorset cs
Specifies a colorset for the bg of FvwmBanner (default 0).
This is only useful if the image has a transparent part
and the Shaped option is used or if the image has an alpha channel.

*FvwmBanner: Shaped bool
Shape or not the FvwmBanner window with the transparent part of the image.
Default is false if the image has an alpha channel, true otherwise.

With these two options we can do 1, 2 and 3. 

Regards, Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 6 Jun 2003 19:01:22 +0000

> There is png "support" in FvwmBanner. There is just a bug ... fixed

Thanks, it is fixed.

> With these two options we can do 1, 2 and 3. 

I agree with your analyze.

I just commited 2 png banners in fvwm-themes for your testing, one with
and one without alpha channel (maybe it is even too much alpha-ish).
The one without alpha was created by applying on the black background,
converting to transparent xpm, manual editing and converting back to png.

Currently the banner without alpha channel looks definitely better,
because the flattening threshold of 130 is bad for this specific png.

Regards,
Mikhael.