Re: Request to increase 1024 char/line limit in read.c

[Stefan Blachmann]

Ooops, didn't think of that!

Then the only correct solution is to drop my request and leave things
as they are.
I'll then just store the parameters otherwhere (file).

Thank you guys for explaining!
Stefan

On 3/5/18, Dominik Vogt  wrote:
> On Mon, Mar 05, 2018 at 11:57:27AM +, Thomas Adam wrote:
>> Hi,
>>
>> On Mon, Mar 05, 2018 at 04:38:08AM +0100, Stefan Blachmann wrote:
>> > Hi fvwm-workers,
>> >
>> > the 1024 char limit in the read line buffer in fvwm/read.c has become
>> > too small.
>> > This caused a breakage in my MissingSubmenuFunction menu generator
>> > after after addition of programs + update; the Popup did not display.
>> >
>> > Could the buffer be extended to, say, 4096 chars?
>>
>> We'd be chasing stack limits if we do this.
>>
>> I'd much rather see that fgets() loop replaced with fparseln() instead,
>> which
>> would also solve this problem indefinitely.
>
> The reson for commnd line limitation is mostly the size limit of
> pipes (pipereas command and module communication).  In the past we
> used the largest value that every system guaranteed to support
> (256) and then increased that to 1024 at some time.
>
> Ciao
>
> Dominik ^_^  ^_^
>
> --
>
> Dominik Vogt
>

Re: Request to increase 1024 char/line limit in read.c

[Dominik Vogt]

On Mon, Mar 05, 2018 at 11:57:27AM +, Thomas Adam wrote:
> Hi,
> 
> On Mon, Mar 05, 2018 at 04:38:08AM +0100, Stefan Blachmann wrote:
> > Hi fvwm-workers,
> > 
> > the 1024 char limit in the read line buffer in fvwm/read.c has become too 
> > small.
> > This caused a breakage in my MissingSubmenuFunction menu generator
> > after after addition of programs + update; the Popup did not display.
> > 
> > Could the buffer be extended to, say, 4096 chars?
> 
> We'd be chasing stack limits if we do this.
> 
> I'd much rather see that fgets() loop replaced with fparseln() instead, which
> would also solve this problem indefinitely.

The reson for commnd line limitation is mostly the size limit of
pipes (pipereas command and module communication).  In the past we
used the largest value that every system guaranteed to support
(256) and then increased that to 1024 at some time.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: Next Steps

[Thomas Adam]

On Mon, Mar 05, 2018 at 07:17:53AM -0500, Dan Espen wrote:
> It would be nice to see Fvwm actually work with RandR.

Hi Dan,

> Working would be sensing the change and moving windows into the new
> screen dimensions.  Every once and a while I get the urge to try my
> 1600x1200 panel as 1200x1600.

Definitely.  :)  I had started some of the groundwork for this:

https://github.com/fvwmorg/fvwm/commits/ta/randr

I've just rebased it against master, and pushed the result out.  I can't
remember what state I left it in, but I suppose none of the reflection work
has been done yet.

It should though detect different monitors, etc.

-- Thomas Adam

[fvwmorg/fvwm] a93ce9: Xinerama: Remove support for SLS and Solaris

[Thomas Adam]

  Branch: refs/heads/ta/randr
  Home:   https://github.com/fvwmorg/fvwm
  Commit: a93ce952f7c0d96bf796e78022037a91405a4b98
  
https://github.com/fvwmorg/fvwm/commit/a93ce952f7c0d96bf796e78022037a91405a4b98
  Author: Thomas Adam 
  Date:   2018-03-05 (Mon, 05 Mar 2018)

  Changed paths:
M configure.ac
M fvwm/functable.c
M fvwm/fvwm.c
M fvwm/placement.c
M fvwm/virtual.c
M libs/FScreen.c
M libs/FScreen.h

  Log Message:
  ---
  Xinerama:  Remove support for SLS and Solaris


  Commit: be11e53ecc59af9bb9c136c541997ca137962e70
  
https://github.com/fvwmorg/fvwm/commit/be11e53ecc59af9bb9c136c541997ca137962e70
  Author: Thomas Adam 
  Date:   2018-03-05 (Mon, 05 Mar 2018)

  Changed paths:
M configure.ac
M fvwm/Makefile.am
M fvwm/expand.c
M fvwm/fvwm.h
M fvwm/icons.c
M fvwm/menus.c
M fvwm/module_list.h
M fvwm/move_resize.c
M fvwm/placement.c
M fvwm/schedule.c
M fvwm/style.c
M fvwm/virtual.c
M fvwm/windowlist.c
M libs/FScreen.c
M libs/FScreen.h
M libs/FTips.c
M libs/Makefile.am
M libs/XError.c
M libs/queue.c
M modules/FvwmAuto/Makefile.am
M modules/FvwmBacker/Makefile.am
M modules/FvwmButtons/Makefile.am
M modules/FvwmIconMan/Makefile.am
M modules/FvwmIconMan/x.c
M modules/FvwmIdent/Makefile.am
M modules/FvwmPager/Makefile.am

  Log Message:
  ---
  Support XRandR and remove Xinerama

This crudely rips out Xinerama and in its place adds support for XrandR
instead.

Screens are no longer referenced by a number, instead the display name of
the output is needed, as defined by xrandr(1).  The same goes for any
geometry string specifiers in FVWM which might have referenced a screen,
such as:

PositionPlacement 100+200x10+10@0

The "@0" part of that must be changed.

The API is kept intact as much as possible in libs/FScreen.[ch]; with a few
deprecations which were Xinerama-specific and no longer needed.  Previous
screen specifiers used to differentiate at the API level:

FSCREEN_XYPOS
FSCREEN_CURRENT
FSCREEN_PRIMARY
FSCREEN_GLOBAL

Global is now referenced by the output name of "global", and is also the
monitor used in the case where XRandR is not used.  There is no longer the
concept of a primary output (which was only ever used in cases where it was
not known which monitor a window should be placed on.)  CURRENT and XYPOS
now also collapse into the same meaning, but the API hasn't (yet) been
updated to reflect that.

There is also (at present), no support for XRRUpdateConfiguration() on the
root window, hence unplugging and changing the rotation of monitor is not
supported at this time.


  Commit: 3f93e18e16d98930431daeccf7fdfb0a1d16d2c9
  
https://github.com/fvwmorg/fvwm/commit/3f93e18e16d98930431daeccf7fdfb0a1d16d2c9
  Author: Thomas Adam 
  Date:   2018-03-05 (Mon, 05 Mar 2018)

  Changed paths:
M configure.ac
M libs/Makefile.am
A libs/fqueue.c
A libs/fqueue.h
R libs/queue.c
M libs/queue.h

  Log Message:
  ---
  Move libs/queue.[ch] to libs/fqueue.[ch]

This makes way for BSD's TAILQ definitions in queue.h


  Commit: 38067538b29673a80abe9542a385ed5f9f65b04f
  
https://github.com/fvwmorg/fvwm/commit/38067538b29673a80abe9542a385ed5f9f65b04f
  Author: Thomas Adam 
  Date:   2018-03-05 (Mon, 05 Mar 2018)

  Changed paths:
M fvwm/add_window.c
M fvwm/borders.c
M fvwm/builtins.c
M fvwm/colorset.c
M fvwm/conditional.c
M fvwm/events.c
M fvwm/ewmh.c
M fvwm/ewmh_icons.c
M fvwm/ewmh_names.c
M fvwm/execcontext.c
M fvwm/expand.c
M fvwm/frame.c
M fvwm/functions.c
M fvwm/fvwm.c
M fvwm/infostore.c
M fvwm/menuitem.c
M fvwm/menus.c
M fvwm/menustyle.c
M fvwm/modconf.c
M fvwm/module_interface.c
M fvwm/module_list.c
M fvwm/move_resize.c
M fvwm/read.c
M fvwm/schedule.c
M fvwm/session.c
M fvwm/stack.c
M fvwm/style.c
M fvwm/virtual.c
M fvwm/windowlist.c
M fvwm/windowshade.c
M libs/BidiJoin.c
M libs/Bindings.c
M libs/Colorset.c
M libs/CombineChars.c
M libs/FBidi.c
M libs/FEvent.c
M libs/FGettext.c
M libs/FImage.c
M libs/FTips.c
M libs/Fft.c
M libs/Ficonv.c
M libs/Flocale.c
M libs/FlocaleCharset.c
M libs/Graphics.c
M libs/Module.c
M libs/Parse.c
M libs/Picture.c
M libs/PictureBase.c
M libs/PictureGraphics.c
M libs/PictureImageLoader.c
M libs/PictureUtils.c
M libs/Strings.c
M libs/System.c
M libs/XResource.c
M libs/charmap.c
M libs/envvar.c
M libs/flist.c
M libs/fqueue.c
M libs/fsm.c
M libs/safemalloc.c
M libs/safemalloc.h
M libs/timeout.c
M modules/FvwmAuto/FvwmAuto.c
M modules/FvwmBacker/FvwmBacker.c
M modules/FvwmButtons/FvwmButtons.c
M modules/FvwmButtons/FvwmButtons.h
M modules/FvwmButtons/button.c

Re: Next Steps

[Dan Espen]

Thomas Adam  writes:

> Hi,
>
> Now that the copyright issue has been sorted out, and we're largely able to
> resume things, I can't remember what we said about what the next steps were
> with fvwm.
>
> I know we had some conversations around the state of fvwm2, with this odd
> split between my deprecating a bunch of modules, and fvwm2-stable being a
> branch which undoes this, but I recall we've drawn a line under this now.  Or
> rather, I will no longer personally be touching fvwm2 in any guise.  AFAIAC,
> I'm done with that.
>
> So it begs the question what to do next and how to approach doing that work.
> There's a list of ideas I'd started either to write or collate from elsewhere,
> and I know that Dominik has been kind enough to comment on some of those:
>
> https://github.com/fvwmorg/fvwm/blob/master/TODO.md
>
> There's some really good ideas there -- and there's the core of fvwm which
> will really lend itself well to trying to improve and modernise things.  I'm
> keen on that point -- with a 20+ year old project, it's always good to take
> the opportunity to weed/prune/modernise what's there when the opportunity
> presents itself.  It's something I tried to do in part with fvwm2, and failed.
>
> Thoughts welcome.

It would be nice to see Fvwm actually work with RandR.
Working would be sensing the change and moving windows into the new
screen dimensions.  Every once and a while I get the urge to try my
1600x1200 panel as 1200x1600.

-- 
Dan Espen

Re: Request to increase 1024 char/line limit in read.c

[Thomas Adam]

Hi,

On Mon, Mar 05, 2018 at 04:38:08AM +0100, Stefan Blachmann wrote:
> Hi fvwm-workers,
> 
> the 1024 char limit in the read line buffer in fvwm/read.c has become too 
> small.
> This caused a breakage in my MissingSubmenuFunction menu generator
> after after addition of programs + update; the Popup did not display.
> 
> Could the buffer be extended to, say, 4096 chars?

We'd be chasing stack limits if we do this.

I'd much rather see that fgets() loop replaced with fparseln() instead, which
would also solve this problem indefinitely.


-- Thomas Adam

[fvwmorg/fvwm]

[ThomasAdam]

  Branch: refs/heads/origin/dv/stable-fvwm2
  Home:   https://github.com/fvwmorg/fvwm