Re: Removing libstroke support?

[Viktor Griph]

Den 17 okt. 2016 11:56 PM skrev "Dominik Vogt" :
>
> Does anybody really use libstroke support?

I've been using it in my configs since I started using fvwm.

> It's resonsible for
> quite some hardly readably code, and I suspect nobody uses it
> anymore.  If there's a need for mouse gesture or touchpad support,
> there must certainly be some other library around that does a
> better job.

I haven't looked for alternatives, but it feels like the functionality
really should live in a separate application. It's not about managing
windows, but being able to execute commands on gestures.

//Viktor

Re: Future image support

[Dan Espen]

Dominik Vogt  writes:

> During the discussion of mandarory or optional PNG support I've
> started wondering if we *really* need a multitude of different
> image format support in the core and the modules.
>
> At the moment, there's a plugin like image loading and maintenance
> layer in the library that takes care or reading images into
> memory.  When this is done, all images are actually the same.
>
>   +---+   +---+   +---+
>   | PNG file  |   | XPM file  |   | SVG file  |
>   +---+   +---+   +---+
> |___|___|
> |
> | load
> |
>   +---+
>   | | PNG lib   | | XPM lib   | | SVG lib   | |
>   | +---+ +---+ +---+ |
>   |   |_|_|   |
>   | | |
>   |   +---+   |^
>   |   | Picture code using Pixmap |   ||
>   |   +---+   | library code
>   |-|-|
>   | | |
>   |fvwm core or module using Pixmaps  |
>   |   |
>   +---+
>
> It would be possible to rip out image loading support from the
> library except for a single format and rely on external tools to
> provide that format if necessary.  Possible approaches:
>
>  * Use e.g. Imagemagick to convert the image file to the target
>format.  We'd get support for many image formats for free
>while linking fvwm with only one image library.
>
>  * Have our own tool similar to fvwm-root to read the image into
>memory (on the X server, as shared memory or whatever).  Only
>that tool would know about image formats,  Fvwm and the modules
>would simply work with the Pixmaps from memory.  As a bonus,
>the Pixmaps could be shared between modules and the core.
>
> The Imagemagick approach is probably too slow and unreliable, but
> the second should be doable with well designed inter process
> communication (which needs a redesign anyway).  Uploading Pixmaps
> to the server before they can be used may not be a good idea for
> remote servers.
>
> Thoughts?

I don't see XPMs in the XDG libraries, but I do see them still
being shipped with Emacs 24.5.  I don't think Fvwm would need
XPM support in order to allow Emacs to supply it's
own icon as it likes to do.

At minimum Fvwm needs to support the icons supplied by XDG.

-- 
Dan Espen

Re: Final long term stable version

[Dominik Vogt]

On Mon, Oct 17, 2016 at 11:25:47PM +0100, Thomas Adam wrote:
> On Mon, Oct 17, 2016 at 11:20:25PM +0100, Dominik Vogt wrote:
> > While the enthusiasm to remove outdated stuff (strokes, Xinerama,
> > colourmaps, old parser etc.) is an important step towards a
> > maintainable and nice future fvwm3, there are certainly some old
> > systems still running that use some obscure features.
> > 
> > In order to not alienate long time users from fvwm we may need to
> > make a clean cut at some time:
> > 
> >  * Up to version X, the old feature set and syntax is supported
> >"forever".  There won't be any new features anymore, but if
> >need be, we'll look into fixes like to new library versions and
> >such, so that the old version will continue to run on old boxes.
> >Patches fixing such problems are welcome, and once in a while a
> >new maintenance release is made.
> > 
> >  * From version X+1 onwards, no guarantees are made about
> >continued support of obscure features, until there's an
> >official fvwm-3.0.
> > 
> > Is that doable?  WIth X == 2.6.7?  (Of course this is all depends
> > on people actually doing that work.)
> 
> It's doable from a code/maintenance point of view, yes.  But I hope that
> there's no real expectation that developers or future developers (chance would
> be a fine thing!) who might be working on this mythical fvwm-3, should care
> about fvwm-legacy.
> 
> Oh, and I love the idea---but I am incredibly skpetical about it coming to
> fruition, given that there are so few people developing fvwm these days.

Well, developers or not is one thing, but the first step would be
to *announce* that fvwm2 is not going to be disposed off on the
compost heap.  That anybody is welcome if she wants to take care
of the fvwm2 branch for a while, and that the "fvwm3" developers
are not going to put a spoke in her wheel, and support that
maintenance work if possible.

(If it turns out that there are no developers for fvwm this
discussion is moot anyway.)

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: Final long term stable version

[Thomas Adam]

On Mon, Oct 17, 2016 at 11:20:25PM +0100, Dominik Vogt wrote:
> While the enthusiasm to remove outdated stuff (strokes, Xinerama,
> colourmaps, old parser etc.) is an important step towards a
> maintainable and nice future fvwm3, there are certainly some old
> systems still running that use some obscure features.
> 
> In order to not alienate long time users from fvwm we may need to
> make a clean cut at some time:
> 
>  * Up to version X, the old feature set and syntax is supported
>"forever".  There won't be any new features anymore, but if
>need be, we'll look into fixes like to new library versions and
>such, so that the old version will continue to run on old boxes.
>Patches fixing such problems are welcome, and once in a while a
>new maintenance release is made.
> 
>  * From version X+1 onwards, no guarantees are made about
>continued support of obscure features, until there's an
>official fvwm-3.0.
> 
> Is that doable?  WIth X == 2.6.7?  (Of course this is all depends
> on people actually doing that work.)

It's doable from a code/maintenance point of view, yes.  But I hope that
there's no real expectation that developers or future developers (chance would
be a fine thing!) who might be working on this mythical fvwm-3, should care
about fvwm-legacy.

Oh, and I love the idea---but I am incredibly skpetical about it coming to
fruition, given that there are so few people developing fvwm these days.

But, yeah, I'm all for this.

-- Thomas Adam

Final long term stable version

[Dominik Vogt]

While the enthusiasm to remove outdated stuff (strokes, Xinerama,
colourmaps, old parser etc.) is an important step towards a
maintainable and nice future fvwm3, there are certainly some old
systems still running that use some obscure features.

In order to not alienate long time users from fvwm we may need to
make a clean cut at some time:

 * Up to version X, the old feature set and syntax is supported
   "forever".  There won't be any new features anymore, but if
   need be, we'll look into fixes like to new library versions and
   such, so that the old version will continue to run on old boxes.
   Patches fixing such problems are welcome, and once in a while a
   new maintenance release is made.

 * From version X+1 onwards, no guarantees are made about
   continued support of obscure features, until there's an
   official fvwm-3.0.

Is that doable?  WIth X == 2.6.7?  (Of course this is all depends
on people actually doing that work.)

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: FVWM: [dominik.v...@gmx.de: Removing libstroke support?]

[Thomas Adam]

On Mon, Oct 17, 2016 at 10:57:58PM +0100, Dominik Vogt wrote:
> - Forwarded message from Dominik Vogt  -
> 
> Date: Mon, 17 Oct 2016 22:55:56 +0100
> From: Dominik Vogt 
> To: fvwm-workers 
> Subject: Removing libstroke support?
> User-Agent: Mutt/1.5.21 (2010-09-15)
> 
> Does anybody really use libstroke support?  It's resonsible for
> quite some hardly readably code, and I suspect nobody uses it
> anymore.  If there's a need for mouse gesture or touchpad support,
> there must certainly be some other library around that does a
> better job.
> 
> Opinions?

Ditch it.

-- Thomas Adam

Re: Removing colour map support

[Thomas Adam]

On Mon, Oct 17, 2016 at 10:53:46PM +0100, Dominik Vogt wrote:
> The last time I've had a system where private colourmap support
> was useful was back in 1991 or so.  Many people nowadays probably
> don't even know what it is:  On systems with a limited number of
> colours (anybody remembers graphics cards that could only display
> 256 colours in parallel) every window could have its own set of
> colours to use, and when it got the focus, that map would be
> installed, rendering all other windows in funny colours.
> 
> I've honestly no ideas if there are still applications around that
> do that (Netscape was one).  Is there a reason to keep it?

I asked about this months ago.  I think Dan said there was perhaps an aging
Sun machine somewhere which needed it; presumably also running Netscape4, or
more likely Moasic.

I say remove it.

-- Thomas Adam

FVWM: [dominik.v...@gmx.de: Removing libstroke support?]

[Dominik Vogt]

- Forwarded message from Dominik Vogt  -

Date: Mon, 17 Oct 2016 22:55:56 +0100
From: Dominik Vogt 
To: fvwm-workers 
Subject: Removing libstroke support?
User-Agent: Mutt/1.5.21 (2010-09-15)

Does anybody really use libstroke support?  It's resonsible for
quite some hardly readably code, and I suspect nobody uses it
anymore.  If there's a need for mouse gesture or touchpad support,
there must certainly be some other library around that does a
better job.

Opinions?

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt



- End forwarded message -


Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

FVWM: [dominik.v...@gmx.de: Removing colour map support]

[Dominik Vogt]

- Forwarded message from Dominik Vogt  -

Date: Mon, 17 Oct 2016 22:53:46 +0100
From: Dominik Vogt 
To: fvwm-workers 
Subject: Removing colour map support
User-Agent: Mutt/1.5.21 (2010-09-15)

The last time I've had a system where private colourmap support
was useful was back in 1991 or so.  Many people nowadays probably
don't even know what it is:  On systems with a limited number of
colours (anybody remembers graphics cards that could only display
256 colours in parallel) every window could have its own set of
colours to use, and when it got the focus, that map would be
installed, rendering all other windows in funny colours.

I've honestly no ideas if there are still applications around that
do that (Netscape was one).  Is there a reason to keep it?

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt



- End forwarded message -


Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Removing colour map support

[Dominik Vogt]

The last time I've had a system where private colourmap support
was useful was back in 1991 or so.  Many people nowadays probably
don't even know what it is:  On systems with a limited number of
colours (anybody remembers graphics cards that could only display
256 colours in parallel) every window could have its own set of
colours to use, and when it got the focus, that map would be
installed, rendering all other windows in funny colours.

I've honestly no ideas if there are still applications around that
do that (Netscape was one).  Is there a reason to keep it?

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: FVWM: Update of fvwm infrastructure

[Thomas Adam]

On Mon, Oct 17, 2016 at 10:48:14PM +0100, Dominik Vogt wrote:
> Just two more; where's the weg page now, and what's the most up to
> date todo list?  Is it todo.md?

You can see all the repositories under the fvwmorg site here:

https://github.com/fvwmorg

The website lives here:

https://github.com/fvwmorg/fvwmorg.github.io

Using Jekyll and Markdown.

As for the fvwm TODO list, yes, it's here:

https://github.com/fvwmorg/fvwm/blob/master/TODO.md

It's mostly my own brain dump, with a few items from other sporadic TODOs
which now no longer make sense, and I've annexed them.

-- Thomas Adam

Re: Future image support

[Thomas Adam]

On Mon, Oct 17, 2016 at 10:33:00PM +0100, Dominik Vogt wrote:
> The Imagemagick approach is probably too slow and unreliable, but
> the second should be doable with well designed inter process
> communication (which needs a redesign anyway).  Uploading Pixmaps
> to the server before they can be used may not be a good idea for
> remote servers.
> 
> Thoughts?

You could also use a library which offers access to many different image
formats (without requiring those individual libraries themselves).  For
instance:

https://github.com/nothings/stb

Or use ImageMagick directly (faster than using its CLI to conver things):

http://www.imagemagick.org/script/magick-wand.php

Or use libgd:

https://libgd.github.io/

-- Thomas Adam

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

[Dominik Vogt]

On Mon, Oct 17, 2016 at 10:30:37PM +0100, Thomas Adam wrote:
> On Mon, Oct 17, 2016 at 10:05:04PM +0100, Dominik Vogt wrote:
> > The intention of having a show off or default config using PNG is
> > a good idea, but one can still have an option "--disable-png" and
> > tell people:
> 
> [...]
> 
> OK -- so what if we do that, but it defaults to using PNG if it's on the
> system?

Fine with me, even if it produces an error message if libpng-devel
is not found and --disable-png is not explicitly used.

> Would that make things easier for everyone?  If so, I'm happy to do that.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Future image support

[Dominik Vogt]

During the discussion of mandarory or optional PNG support I've
started wondering if we *really* need a multitude of different
image format support in the core and the modules.

At the moment, there's a plugin like image loading and maintenance
layer in the library that takes care or reading images into
memory.  When this is done, all images are actually the same.

  +---+   +---+   +---+
  | PNG file  |   | XPM file  |   | SVG file  |
  +---+   +---+   +---+
|___|___|
|
| load
|
  +---+
  | | PNG lib   | | XPM lib   | | SVG lib   | |
  | +---+ +---+ +---+ |
  |   |_|_|   |
  | | |
  |   +---+   |^
  |   | Picture code using Pixmap |   ||
  |   +---+   | library code
  |-|-|
  | | |
  |fvwm core or module using Pixmaps  |
  |   |
  +---+

It would be possible to rip out image loading support from the
library except for a single format and rely on external tools to
provide that format if necessary.  Possible approaches:

 * Use e.g. Imagemagick to convert the image file to the target
   format.  We'd get support for many image formats for free
   while linking fvwm with only one image library.

 * Have our own tool similar to fvwm-root to read the image into
   memory (on the X server, as shared memory or whatever).  Only
   that tool would know about image formats,  Fvwm and the modules
   would simply work with the Pixmaps from memory.  As a bonus,
   the Pixmaps could be shared between modules and the core.

The Imagemagick approach is probably too slow and unreliable, but
the second should be doable with well designed inter process
communication (which needs a redesign anyway).  Uploading Pixmaps
to the server before they can be used may not be a good idea for
remote servers.

Thoughts?

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

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

[Thomas Adam]

On Mon, Oct 17, 2016 at 10:05:04PM +0100, Dominik Vogt wrote:
> The intention of having a show off or default config using PNG is
> a good idea, but one can still have an option "--disable-png" and
> tell people:

[...]

OK -- so what if we do that, but it defaults to using PNG if it's on the
system?

Would that make things easier for everyone?  If so, I'm happy to do that.

-- Thomas Adam

Re: FVWM: Update of fvwm infrastructure

[Thomas Adam]

On Mon, Oct 17, 2016 at 10:08:43PM +0100, Dominik Vogt wrote:
> Hi Thomas,
> 
> sorry, I've really lost track of recent fvwm activities, could you
> please give me an update of where the relevant git repos are and
> what branches to look at?  And what are your plas for version
> numbers and releases on the way to fvwm3?

Hi Dominik,

Sure.  See here:

https://github.com/fvwmorg/fvwm

Workflow instructions, etc., are here:

https://github.com/fvwmorg/fvwm/blob/master/docs/DEVELOPERS.md

All the branches I'm working on are in the main fvwm repo.  In fact, so far,
it's been just me.

Right now, I'm looking at replacing Xinerama with RandR (See ta/randr) -- this
is in a state of extreme flux though.

Everything on master right now is going towards 2.6.7 -- not much to tell
really, but the git logs should help you as I can't remember since it's been a
while.

HTH -- any questions, shout.

-- Thomas Adam

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

[Dominik Vogt]

On Mon, Oct 17, 2016 at 07:36:28PM +0100, Thomas Adam wrote:
> On Mon, Oct 17, 2016 at 07:01:52PM +0100, Dominik Vogt wrote:
> I'm saying that as an image format used in the wild, all of the projects
> I can see don't support XPMs.  I'm not saying it's being removed at all.  It's
> an example showing that FVWM is carrying around optional support for it.
> *That's* a maintainer burden in that the cost of removing it is high because
> someone out there (presumably with a long beard, I couldn't say), is still
> using it.

Only if you ever want to remove it, which you said you wouldn't
do.

> > Making PNG support mandatory is not going to have any positive
> > effect on code size or maintainability unless something else is
> > removed in favour of PNG.
> 
> You mean making it optional?  I disagree there.  We already _support_ it.  Go
> look at all the Linux distros which package FVWM.  You'll quickly see what
> they chose to compile in.

Then what is the gain of making it mandatory if every distro has
it anyway?  With that line of argumwnt the only effect of making
it mandatory is making fvwm harder to build for some people.

> You'll have to prove to me there's a negative impact on FVWM.  You'll have to
> prove to me the size increase is hampering something important, and you'll
> definitely have to tell me how this is a problem for maintainability, when we
> already support PNG image loading.  No additional code is being added or taken
> away here, it's just a compile-time change.

> This change is additive, and helps FVWM out-of-the-box. 

In what way does it help fvwm, or us developers or the users if
PNG support is now guaranteed to be there while it just happened
to be there unless the user compiled fvwm herself?

> And sorry, embedded systems don't count because as you've also seen, FVWM is
> too large anyway, even with all the optional libraries taken out and the
> binary stripped.

> That's also not taking into account modules as well---which,
> by the way, you also have with FVWM as a consequence.

Modules are optional.  That's the only point of the module
concept (everything they do could be done easier in the core).  If
you don't want them, you don't have to install them (which is a
bit of manual work with the current Makefiles).  No vital
functionality is or should ever be in a module.

So, let's forget about embedded systems, but people do use it in
environments where simplicity and small installation size counts
(e.g. a buddy of mine who uses it as the interface of his home
grown media/entertainment setup, and he is explicitly happy that
he did now have to have any image support but could do with simple
menus and vector buttons).

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

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

[Thomas Adam]

On Mon, Oct 17, 2016 at 07:01:52PM +0100, Dominik Vogt wrote:
> And the logical consequence of this statement is to hard code
> image formats and remove the library code, no?

No.  The logic stops in saying that out-of-the-box, PNG image support is
available.  At a minimum.  Other renderers are available, and from what I can
tell, pretty much every single FVWM installation which is packaged includes
all image renderes FVWM supports.  That's telling in and of itself.  Perhaps
the only exception to this is Gentoo.

> When you say that XPM is dead, does this mean XPM support is on
> the remove list in favour of PNG?  What other change could affect

No.  I'm saying that as an image format used in the wild, all of the projects
I can see don't support XPMs.  I'm not saying it's being removed at all.  It's
an example showing that FVWM is carrying around optional support for it.
*That's* a maintainer burden in that the cost of removing it is high because
someone out there (presumably with a long beard, I couldn't say), is still
using it.

> Making PNG support mandatory is not going to have any positive
> effect on code size or maintainability unless something else is
> removed in favour of PNG.

You mean making it optional?  I disagree there.  We already _support_ it.  Go
look at all the Linux distros which package FVWM.  You'll quickly see what
they chose to compile in.

You'll have to prove to me there's a negative impact on FVWM.  You'll have to
prove to me the size increase is hampering something important, and you'll
definitely have to tell me how this is a problem for maintainability, when we
already support PNG image loading.  No additional code is being added or taken
away here, it's just a compile-time change.  This change is additive, and
helps FVWM out-of-the-box. 

And sorry, embedded systems don't count because as you've also seen, FVWM is
too large anyway, even with all the optional libraries taken out and the
binary stripped.  That's also not taking into account modules as well---which,
by the way, you also have with FVWM as a consequence.

Kindly,

-- Thomas Adam

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

[Dominik Vogt]

On Mon, Oct 17, 2016 at 02:04:54AM +0100, Dominik Vogt wrote:
> 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.

  $ cd fvwm
  $ ls -s -S --si *.o
   58k style.oC, S, P!
   54k menus.oC, P
   50k move_resize.o  C, P
   50k builtins.o P!
   41k events.o   C
   41k fvwm.o C
   37k add_window.o   C
   37k borders.o  C, D
   29k virtual.o  C
   25k icons.oD
   25k ewmh.o I
   21k conditional.o  C
   21k menustyle.oC, P, S
   21k placement.oC
   21k colorset.o D
   17k stack.oC
   17k module_list.o  C
   17k functable.oC
   17k frame.oC, D
   17k windowlist.o   C
   17k functions.oC
   17k session.o  I
   13k ewmh_events.o  I
   13k expand.o   C
   13k geometry.o C
   13k focus.oC
   13k module_interface.o C
   13k menuitem.o C
   13k menubindings.o C
   13k update.o   C
   13k gnome.oI
  8.2k bindings.o C
  8.2k ewmh_icons.o   I
  8.2k misc.o ?
  8.2k cursor.o   D
  8.2k decorations.o  D
  8.2k read.o C
  8.2k colormaps.o<--- candidate for removal
  8.2k menucmd.o  C
  8.2k ewmh_conf.oI
  4.1k modconf.o  C
  4.1k icccm2.o   I
  4.1k schedule.o C
  4.1k windowshade.o  D
  4.1k infostore.o?
  4.1k execcontext.o  C
  4.1k focus_policy.o C
  4.1k repeat.o   <--- candidate for removal, never really worked
  4.1k menugeometry.o C
  4.1k ewmh_names.o   I
  4.1k menudim.o  C
  4.1k condrc.o   C

C = important core functionality
D = decorations related core code
I = Interfacing code (external standards)
P! = lots of parsing code
P  = considerable amount of parsing code
S = lots of hard coded strings

Really not a lot of potential for removing code from the core.
The colourmap code is probably unnecessary nowadays, and the
"repeat" feature is mostly a source of hard to debug crashes.

Personally I'm very unhappy about the interfaces which
traditionally cause more trouble than anything, but I guess people
want them as long as there are applications around using them.

  $ cd fvwm
  $ ls -s -S --si *.o
   46k PictureUtils.o
   25k Flocale.o
   17k Graphics.o
   17k CombineChars.o
   17k PictureGraphics.o
   13k FScreen.o
   13k FEvent.o
   13k FlocaleCharset.o
   13k Colorset.o
  8.2k FTips.o
  8.2k Parse.o
  8.2k ColorUtils.o
  8.2k Bindings.o
  8.2k XError.o
  8.2k PictureImageLoader.o
  8.2k gravity.o
  8.2k Module.o
  8.2k PictureBase.o
  4.1k Picture.o
  4.1k XResource.o
  4.1k Cursor.o
  4.1k envvar.o
  4.1k Target.o
  4.1k System.o
  4.1k WinMagic.o
  4.1k Strings.o
  4.1k queue.o
  4.1k Grab.o
  4.1k safemalloc.o
  4.1k FImage.o
  4.1k charmap.o
  4.1k FRenderInit.o
  4.1k Fft.o
  4.1k fvwmrect.o
  4.1k flist.o
  4.1k wcontext.o
  4.1k fvwmsignal.o
  4.1k timeout.o
  4.1k Rectangles.o
  4.1k modifiers.o
  4.1k FGettext.o
  4.1k Ficonv.o
  4.1k wild.o
  4.1k ClientMsg.o
  4.1k fio.o
  4.1k fsm.o
  4.1k Event.o
  4.1k fvwmlib.o
  4.1k FRender.o
  4.1k setpgrp.o
  4.1k BidiJoin.o
  4.1k FShape.o
  4.1k FBidi.o

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

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

[Dominik Vogt]

On Mon, Oct 17, 2016 at 07:53:17AM +0100, Thomas Adam wrote:
> On Mon, Oct 17, 2016 at 01:58:10AM +0100, Dominik Vogt wrote:
> > 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.
> 
> Of course, but that was never FVWM's design goal,
> and it's a little unsuaul to > suddenly make it one,

Keeping it small always was a design goal, although of course
having a lot of functionality counteracts this somewhat.  Maybe
not aiming at embedded systems.

> given that it's not currently possible.  I'm all for
> making things smaller (I already am), but I am not going to sacrifice anything
> else in FVWM to the point where the goals of giving something to the user are
> from the point of view of an arbitrary embedded system.  That's not happening.
> 
> > 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.
> 
> I wasn't saying that.  I was pointing out that in order to support many image
> formats (why?), it meant that this abstraction layer had to be written, for no
> real purpose other than to give people as much flexibility as possible, but
> putting a slight burden on the maintainer(s) of the code.

And the logical consequence of this statement is to hard code
image formats and remove the library code, no?

> The same example can be used in many other places in FVWM, and that's the
> trade-off between functionality and letting the design of FVWM grow
> organically through many different people, over a long period of time.  Trying
> to reign that back, whilst still providing the same or similar functionality
> is important.
> 
> > > 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.
> 
> Well, we'll see, but given everything else in FVWM, I suspect this  won't even
> be a blip on the radar.

When you say that XPM is dead, does this mean XPM support is on
the remove list in favour of PNG?  What other change could affect
and possibly annoy more people at once?  While it may be possible
to convert the configuration files mostly automatically,
converting system installed XPM icon libraries during is certainly
not.

Making PNG support mandatory is not going to have any positive
effect on code size or maintainability unless something else is
removed in favour of PNG.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

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

[Thomas Adam]

On Mon, Oct 17, 2016 at 01:58:10AM +0100, Dominik Vogt wrote:
> 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.

Of course, but that was never FVWM's design goal, and it's a little unsuaul to
suddenly make it one, given that it's not currently possible.  I'm all for
making things smaller (I already am), but I am not going to sacrifice anything
else in FVWM to the point where the goals of giving something to the user are
from the point of view of an arbitrary embedded system.  That's not happening.

> 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.

I wasn't saying that.  I was pointing out that in order to support many image
formats (why?), it meant that this abstraction layer had to be written, for no
real purpose other than to give people as much flexibility as possible, but
putting a slight burden on the maintainer(s) of the code.

The same example can be used in many other places in FVWM, and that's the
trade-off between functionality and letting the design of FVWM grow
organically through many different people, over a long period of time.  Trying
to reign that back, whilst still providing the same or similar functionality
is important.

> > 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.

Well, we'll see, but given everything else in FVWM, I suspect this  won't even
be a blip on the radar.

Kindly,

-- Thomas Adam