Re: Request to increase 1024 char/line limit in read.c
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
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
[fvwmorg/fvwm] 3eed60: TRAVIS: fix missing libxrandr
Branch: refs/heads/ta/randr Home: https://github.com/fvwmorg/fvwm Commit: 3eed605a9329ce674c7b45919e585bbd326b47b7 https://github.com/fvwmorg/fvwm/commit/3eed605a9329ce674c7b45919e585bbd326b47b7 Author: Thomas Adam Date: 2018-03-05 (Mon, 05 Mar 2018) Changed paths: M .travis.yml Log Message: --- TRAVIS: fix missing libxrandr
Re: Next Steps
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
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 M modules/FvwmButtons/parse.c M modules/FvwmCommand/FvwmCommand.c M m
Re: Next Steps
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
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]
Branch: refs/heads/origin/dv/stable-fvwm2 Home: https://github.com/fvwmorg/fvwm