Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory

2016-10-16 Thread Dominik Vogt 
On Mon, Oct 17, 2016 at 01:58:10AM +0100, Dominik Vogt wrote:
> This may have gotten a bit out of hand (fvwm-2.6.7):
> 
>   $ ./configure --disable-nls --disable-mandoc --disable-sm --disable-shape 
> --disable-shm --disable-xrender --disable-xinerama --disable-iconv 
> --disable-xft --disable-bidi --disable-perllib --disable-gtk 
> --disable-gtktest --disable-imlibtest --with-png-library=no 
> --with-stroke-library=no --with-xpm-library=no --with-rplay-library=no 
> --with-readline-library=no
> 
>   (everything turned off)
> 
>   $ make CFLAGS="-O3"

Sorry ...

$ make CFLAGS="-Os"
$ cd fvwm
$ ls -s --si fvwm
697k fvwm*
$ strip fvwm 
$ ls -s --si fvwm
623k fvwm

Still too big for small systems.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory

2016-10-16 Thread Dominik Vogt 
On Mon, Oct 17, 2016 at 12:50:53AM +0100, Thomas Adam wrote:
> On Mon, Oct 17, 2016 at 12:01:14AM +0100, Dominik Vogt wrote:
> > On Sun, Oct 16, 2016 at 05:09:57PM +0100, Thomas Adam wrote:
> > > On Sun, Oct 16, 2016 at 04:48:34PM +0100, Dominik Vogt wrote:
> > > > Maybe it's a silly question, but *why* does fvwm need mandatory
> > > > image support at all?  Arent's images in a window manager just
> > > > gimmicks?
> > > 
> > > It's not a silly question, but I'd hoped the commit message said enough.
> > > Gimmick is a matter of perspective.  I'm trying to stike a balance through
> > > useability.  I don't think it's unreasonable to assume one image library 
> > > as
> > > the de facto; others are still available.  I'm trying to frame this in 
> > > terms
> > > of:
> > > 
> > > * Making the default config useable and useful (which from what I'm 
> > > seeing,
> > >   does entail some form of image loading (for icons im menus and 
> > > elsewhere)
> > > 
> > > * Integrating with other third-party applications which generate menus 
> > > (which
> > >   use PNG).
> > 
> > I completely understand that, and PNG seems to be a sensible
> > choice.  The thing I'm unsure about is whether it should be
> > possible to build fvwm without any libraries and expendable
> > features to have a lean, minimalistic WM.  But I've honestly no
> > idea whether anybody did that in the recent past or not.
> 
> These days you find two camps---those programs which are deliberately
> minimalistic in some way, and those which want to include a lot of things;
> size doesn't matter.
> 
> I suspect when FVWM was in its heyday, the cost of including certain features
> would have had an impact on resources and memory footprint, etc.  This
> explains why GNOME and KDE at the time had a bad press for resources.  It's
> worth bearing in mind though that keeping things minimal is always worthwhile.

But keep small and/or embedded systems in mind.  It's still
possible to use just the core without any libraries and modules
and have a very small WM that can even draw basic window
decoration and some graphical effects.

...

This may have gotten a bit out of hand (fvwm-2.6.7):

  $ ./configure --disable-nls --disable-mandoc --disable-sm --disable-shape 
--disable-shm --disable-xrender --disable-xinerama --disable-iconv 
--disable-xft --disable-bidi --disable-perllib --disable-gtk --disable-gtktest 
--disable-imlibtest --with-png-library=no --with-stroke-library=no 
--with-xpm-library=no --with-rplay-library=no --with-readline-library=no

  (everything turned off)

  $ make CFLAGS="-O3"
  $ cd fvwm
  $ ls -s --si fvwm
  979k fvwm
  $ ldd fvwm
linux-gate.so.1 =>  (0xb77d7000)
libSM.so.6 => /usr/lib/i386-linux-gnu/libSM.so.6 (0xb77bd000)
libICE.so.6 => /usr/lib/i386-linux-gnu/libICE.so.6 (0xb77a4000)
libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xb7791000)
libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xb7659000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb7633000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb74e1000)
libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xb74db000)
libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xb74b7000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb74b3000)
/lib/ld-linux.so.2 (0xb77d9000)
libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xb74b)
libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xb74aa000)

Not exactly what I'd call small and with few dependencies.  libSM
linked although explicitly disabled.  This looks actually like a bug.
Hm.

> But having many options---even if they're things which you can opt in and out
> of, still carry with them a burden of responsibility on the maintainer(s).
> For example, we currently still carry around XPM and SVG.  Why?  XPM is dead,
> and I am <-> close to removing it.  SVG support is much more promising, it's a
> shame more things don't support it externally to make it more viable.
> 
> The image rendering code in FVWM is clever---overly complex in trying to
> abstract away the actual format so that FVWM doesn't care about it for things
> like menus and buttons, etc.  If we went with something modular, but
> extensible, we'd still be having to maintain these things.

I'd be very much against removing the plug-in image format and
hard coding PNG instead.  While there definitely is some
unpleasant to maintain bloat in fvwm, it's certainly not the image
library.

> It's a lot easier to cut out the chaff, and make a statement about the things
> we do support.

Sure, but I suspect in this specifice case we're going to regret
it in the future.

> That will be just as minimal and small, IMO, without
> sacrificing much else, if anything.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory

2016-10-16 Thread Thomas Adam 
On Mon, Oct 17, 2016 at 12:01:14AM +0100, Dominik Vogt wrote:
> On Sun, Oct 16, 2016 at 05:09:57PM +0100, Thomas Adam wrote:
> > On Sun, Oct 16, 2016 at 04:48:34PM +0100, Dominik Vogt wrote:
> > > Maybe it's a silly question, but *why* does fvwm need mandatory
> > > image support at all?  Arent's images in a window manager just
> > > gimmicks?
> > 
> > It's not a silly question, but I'd hoped the commit message said enough.
> > Gimmick is a matter of perspective.  I'm trying to stike a balance through
> > useability.  I don't think it's unreasonable to assume one image library as
> > the de facto; others are still available.  I'm trying to frame this in terms
> > of:
> > 
> > * Making the default config useable and useful (which from what I'm seeing,
> >   does entail some form of image loading (for icons im menus and elsewhere)
> > 
> > * Integrating with other third-party applications which generate menus 
> > (which
> >   use PNG).
> 
> I completely understand that, and PNG seems to be a sensible
> choice.  The thing I'm unsure about is whether it should be
> possible to build fvwm without any libraries and expendable
> features to have a lean, minimalistic WM.  But I've honestly no
> idea whether anybody did that in the recent past or not.

These days you find two camps---those programs which are deliberately
minimalistic in some way, and those which want to include a lot of things;
size doesn't matter.

I suspect when FVWM was in its heyday, the cost of including certain features
would have had an impact on resources and memory footprint, etc.  This
explains why GNOME and KDE at the time had a bad press for resources.  It's
worth bearing in mind though that keeping things minimal is always worthwhile.

But having many options---even if they're things which you can opt in and out
of, still carry with them a burden of responsibility on the maintainer(s).
For example, we currently still carry around XPM and SVG.  Why?  XPM is dead,
and I am <-> close to removing it.  SVG support is much more promising, it's a
shame more things don't support it externally to make it more viable.

The image rendering code in FVWM is clever---overly complex in trying to
abstract away the actual format so that FVWM doesn't care about it for things
like menus and buttons, etc.  If we went with something modular, but
extensible, we'd still be having to maintain these things.

It's a lot easier to cut out the chaff, and make a statement about the things
we do support.  That will be just as minimal and small, IMO, without
sacrificing much else, if anything.

-- Thomas Adam

Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory

2016-10-16 Thread Thomas Adam 
On Sun, Oct 16, 2016 at 05:36:51PM -0600, Jaimos Skriletz wrote:
> What about having libpng be default but having a --disable-libpng
> ./configure option to disable? Have it set up to error out if libpng and
> that option are not present with an error that says building without libpng
> may affect the default config and other applications. If you want to build
> without libpng use --disable-libpng.

I think having it compiled in is fine---that it might not be used in all cases
is also fine.  That's still down to the user.

-- Thomas Adam

Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory

2016-10-16 Thread Jaimos Skriletz 
On Sun, Oct 16, 2016 at 5:01 PM, Dominik Vogt  wrote:

> On Sun, Oct 16, 2016 at 05:09:57PM +0100, Thomas Adam wrote:
> > On Sun, Oct 16, 2016 at 04:48:34PM +0100, Dominik Vogt wrote:
> > > Maybe it's a silly question, but *why* does fvwm need mandatory
> > > image support at all?  Arent's images in a window manager just
> > > gimmicks?
> >
> > It's not a silly question, but I'd hoped the commit message said enough.
> > Gimmick is a matter of perspective.  I'm trying to stike a balance
> through
> > useability.  I don't think it's unreasonable to assume one image library
> as
> > the de facto; others are still available.  I'm trying to frame this in
> terms
> > of:
> >
> > * Making the default config useable and useful (which from what I'm
> seeing,
> >   does entail some form of image loading (for icons im menus and
> elsewhere)
> >
> > * Integrating with other third-party applications which generate menus
> (which
> >   use PNG).
>
> I completely understand that, and PNG seems to be a sensible
> choice.  The thing I'm unsure about is whether it should be
> possible to build fvwm without any libraries and expendable
> features to have a lean, minimalistic WM.  But I've honestly no
> idea whether anybody did that in the recent past or not.
> Perosnally, if I weren't too lazy to change the config, I could
> perfectly do without image support:  The menu logo is just
> decoration, icons work as well when done as text, and the
> FvwmButtons images could be replaced by thext or just menu
> entries.
>
>
What about having libpng be default but having a --disable-libpng
./configure option to disable? Have it set up to error out if libpng and
that option are not present with an error that says building without libpng
may affect the default config and other applications. If you want to build
without libpng use --disable-libpng.

This way if someone really wants to build without image support they can
without having to edit the configure script. Though the answer to having
such an option may be on what happens when fvwm hits the .png images in the
default config without support. I'm hoping it just throws a warning and
leaves a blank place where the image should be.

jaimos​

Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory

2016-10-16 Thread Dominik Vogt 
On Sun, Oct 16, 2016 at 05:09:57PM +0100, Thomas Adam wrote:
> On Sun, Oct 16, 2016 at 04:48:34PM +0100, Dominik Vogt wrote:
> > Maybe it's a silly question, but *why* does fvwm need mandatory
> > image support at all?  Arent's images in a window manager just
> > gimmicks?
> 
> It's not a silly question, but I'd hoped the commit message said enough.
> Gimmick is a matter of perspective.  I'm trying to stike a balance through
> useability.  I don't think it's unreasonable to assume one image library as
> the de facto; others are still available.  I'm trying to frame this in terms
> of:
> 
> * Making the default config useable and useful (which from what I'm seeing,
>   does entail some form of image loading (for icons im menus and elsewhere)
> 
> * Integrating with other third-party applications which generate menus (which
>   use PNG).

I completely understand that, and PNG seems to be a sensible
choice.  The thing I'm unsure about is whether it should be
possible to build fvwm without any libraries and expendable
features to have a lean, minimalistic WM.  But I've honestly no
idea whether anybody did that in the recent past or not.
Perosnally, if I weren't too lazy to change the config, I could
perfectly do without image support:  The menu logo is just
decoration, icons work as well when done as text, and the
FvwmButtons images could be replaced by thext or just menu
entries.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory

2016-10-16 Thread Thomas Adam 
On Sun, Oct 16, 2016 at 04:48:34PM +0100, Dominik Vogt wrote:
> Maybe it's a silly question, but *why* does fvwm need mandatory
> image support at all?  Arent's images in a window manager just
> gimmicks?

It's not a silly question, but I'd hoped the commit message said enough.
Gimmick is a matter of perspective.  I'm trying to stike a balance through
useability.  I don't think it's unreasonable to assume one image library as
the de facto; others are still available.  I'm trying to frame this in terms
of:

* Making the default config useable and useful (which from what I'm seeing,
  does entail some form of image loading (for icons im menus and elsewhere)

* Integrating with other third-party applications which generate menus (which
  use PNG).

XPMs are dead.  SVGs aren't as supported.  PNGs feel like the right thing to
support.

HTH,
Thomas Adam

Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory

2016-10-16 Thread Dominik Vogt 
On Sun, Oct 16, 2016 at 08:19:59AM -0700, GitHub wrote:
>   Make PNG support mandatory
> 
> Traditionally, FVWM has always had the option of not linking to any image
> renderer at all.
> 
> But, the entire world has moved on, and support for images is becoming more
> important, especially with third-party applications.  Indeed, FVWM itself will
> have a new default configuration soon which will make use of PNGs.  It's a
> good idea to support this out of the box.
> 
> Choosing the default image library is not easy -- and although there's a sway
> towards SVGs (which FVWM supports), PNGs are quite common still, so use that.

Maybe it's a silly question, but *why* does fvwm need mandatory
image support at all?  Arent's images in a window manager just
gimmicks?

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

[fvwmorg/fvwm] 9703d6: Make PNG support mandatory

2016-10-16 Thread GitHub 
  Branch: refs/heads/master
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 9703d649aa91c74dde1ac92caedc3145fa1d6f53
  
https://github.com/fvwmorg/fvwm/commit/9703d649aa91c74dde1ac92caedc3145fa1d6f53
  Author: Thomas Adam 
  Date:   2016-10-16 (Sun, 16 Oct 2016)

  Changed paths:
M configure.ac
M fvwm/fvwm.c

  Log Message:
  ---
  Make PNG support mandatory

Traditionally, FVWM has always had the option of not linking to any image
renderer at all.

But, the entire world has moved on, and support for images is becoming more
important, especially with third-party applications.  Indeed, FVWM itself will
have a new default configuration soon which will make use of PNGs.  It's a
good idea to support this out of the box.

Choosing the default image library is not easy -- and although there's a sway
towards SVGs (which FVWM supports), PNGs are quite common still, so use that.

[fvwmorg/fvwm] 9703d6: Make PNG support mandatory

2016-10-16 Thread GitHub 
  Branch: refs/heads/ta/png-default
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 9703d649aa91c74dde1ac92caedc3145fa1d6f53
  
https://github.com/fvwmorg/fvwm/commit/9703d649aa91c74dde1ac92caedc3145fa1d6f53
  Author: Thomas Adam 
  Date:   2016-10-16 (Sun, 16 Oct 2016)

  Changed paths:
M configure.ac
M fvwm/fvwm.c

  Log Message:
  ---
  Make PNG support mandatory

Traditionally, FVWM has always had the option of not linking to any image
renderer at all.

But, the entire world has moved on, and support for images is becoming more
important, especially with third-party applications.  Indeed, FVWM itself will
have a new default configuration soon which will make use of PNGs.  It's a
good idea to support this out of the box.

Choosing the default image library is not easy -- and although there's a sway
towards SVGs (which FVWM supports), PNGs are quite common still, so use that.

[fvwmorg/fvwm] d30479: Make PNG support mandatory

2016-10-16 Thread GitHub 
  Branch: refs/heads/ta/png-default
  Home:   https://github.com/fvwmorg/fvwm
  Commit: d304791e3600e3180c22418356dcd9bc45bb3a22
  
https://github.com/fvwmorg/fvwm/commit/d304791e3600e3180c22418356dcd9bc45bb3a22
  Author: Thomas Adam 
  Date:   2016-10-16 (Sun, 16 Oct 2016)

  Changed paths:
M bin/Makefile.am
M configure.ac
M fvwm/Makefile.am
M fvwm/fvwm.c
M libs/Makefile.am
M modules/FvwmAnimate/Makefile.am
M modules/FvwmBanner/Makefile.am
M modules/FvwmButtons/Makefile.am
M modules/FvwmIdent/Makefile.am
M modules/FvwmPager/Makefile.am
M modules/FvwmProxy/Makefile.am
M modules/FvwmScript/Makefile.am

  Log Message:
  ---
  Make PNG support mandatory

Traditionally, FVWM has always had the option of not linking to any image
renderer at all.

But, the entire world has moved on, and support for images is becoming more
important, especially with third-party applications.  Indeed, FVWM itself will
have a new default configuration soon which will make use of PNGs.  It's a
good idea to support this out of the box.

Choosing the default image library is not easy -- and although there's a sway
towards SVGs (which FVWM supports), PNGs are quite common still, so use that.

[fvwmorg/fvwm] 199f0b: Make PNG support mandatory

2016-10-16 Thread GitHub 
  Branch: refs/heads/ta/png-default
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 199f0b23156a3bf9c9d44d4b91c962b6f853247f
  
https://github.com/fvwmorg/fvwm/commit/199f0b23156a3bf9c9d44d4b91c962b6f853247f
  Author: Thomas Adam 
  Date:   2016-10-16 (Sun, 16 Oct 2016)

  Changed paths:
M bin/Makefile.am
M configure.ac
M fvwm/Makefile.am
M fvwm/fvwm.c
M libs/Makefile.am
M modules/FvwmAnimate/Makefile.am
M modules/FvwmBanner/Makefile.am
M modules/FvwmButtons/Makefile.am
M modules/FvwmIdent/Makefile.am
M modules/FvwmPager/Makefile.am
M modules/FvwmProxy/Makefile.am
M modules/FvwmScript/Makefile.am

  Log Message:
  ---
  Make PNG support mandatory

Traditionally, FVWM has always had the option of not linking to any image
renderer at all.

But, the entire world has moved on, and support for images is becoming more
important, especially with third-party applications.  Indeed, FVWM itself will
have a new default configuration soon which will make use of PNGs.  It's a
good idea to support this out of the box.

Choosing the default image library is not easy -- and although there's a sway
towards SVGs (which FVWM supports), PNGs are quite common still, so use that.

[fvwmorg/fvwm]

2016-10-16 Thread GitHub 
  Branch: refs/heads/ta/png-default
  Home:   https://github.com/fvwmorg/fvwm

[fvwmorg/fvwm] 22d79e: Make PNG support mandatory

2016-10-16 Thread GitHub 
  Branch: refs/heads/ta/png-default
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 22d79eb923fb3ae4489a57f26f688e58c6c09446
  
https://github.com/fvwmorg/fvwm/commit/22d79eb923fb3ae4489a57f26f688e58c6c09446
  Author: Thomas Adam 
  Date:   2016-10-16 (Sun, 16 Oct 2016)

  Changed paths:
M bin/Makefile.am
M configure.ac
M fvwm/Makefile.am
M fvwm/fvwm.c
M libs/Makefile.am
M modules/FvwmAnimate/Makefile.am
M modules/FvwmBanner/Makefile.am
M modules/FvwmButtons/Makefile.am
M modules/FvwmIdent/Makefile.am
M modules/FvwmPager/Makefile.am
M modules/FvwmProxy/Makefile.am
M modules/FvwmScript/Makefile.am

  Log Message:
  ---
  Make PNG support mandatory

Traditionally, FVWM has always had the option of not linking to any image
renderer at all.

But, the entire world has moved on, and support for images is becoming more
important, especially with third-party applications.  Indeed, FVWM itself will
have a new default configuration soon which will make use of PNGs.  It's a
good idea to support this out of the box.

Choosing the default image library is not easy -- and although there's a sway
towards SVGs (which FVWM supports), PNGs are quite common still, so use that.


  Commit: c1471bcb0ef40534b7689ad08ce2099910c47b23
  
https://github.com/fvwmorg/fvwm/commit/c1471bcb0ef40534b7689ad08ce2099910c47b23
  Author: Thomas Adam 
  Date:   2016-10-16 (Sun, 16 Oct 2016)

  Changed paths:
M .travis.yml

  Log Message:
  ---
  Test travis build


Compare: https://github.com/fvwmorg/fvwm/compare/1cd5594d7555...c1471bcb0ef4

[fvwmorg/fvwm] 1cd559: Test travis build

2016-10-16 Thread GitHub 
  Branch: refs/heads/ta/png-default
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 1cd5594d75556ef4961f95157cb71b67c9904fde
  
https://github.com/fvwmorg/fvwm/commit/1cd5594d75556ef4961f95157cb71b67c9904fde
  Author: Thomas Adam 
  Date:   2016-10-16 (Sun, 16 Oct 2016)

  Changed paths:
M .travis.yml

  Log Message:
  ---
  Test travis build