Re: regression from 2.6.5 to 2.6.6 ?
On Sun, Oct 23, 2016 at 02:23 (+0100), Dominik Vogt wrote: > On Sat, Oct 22, 2016 at 10:00:16PM -0300, zli...@ns.sympatico.ca wrote: >> On Sun, Oct 23, 2016 at 01:21 (+0100), Dominik Vogt wrote: >>> On Sat, Oct 22, 2016 at 08:36:10PM -0300, zli...@ns.sympatico.ca wrote: On Sun, Oct 23, 2016 at 00:20 (+0100), Thomas Adam wrote: > On Sat, Oct 22, 2016 at 07:56:31PM -0300, zli...@ns.sympatico.ca wrote: >> I cloned the git version about 15 minutes ago and compiled it, and >> acroread still does not go full-screen correctly. > Can you reproduce this using a more accessible program, please? I'm using > FreeBSD. No, I can't. That is, all other programs I use which have a "full-screen" mode work fine. >>> All right, I can see that acroread generates some weird requests >>> for new size and position. For me, the size is good, but the >>> position is totally screwed (x=65600, y=66000). >>> In fvwm/events.c at line 1077 there is this debug statement: >>> #if 0 >>> fprintf(stderr, >>> "cre: %d(%d) %d(%d) %d(%d)x%d(%d) fw 0x%08x w 0x%08x " >>> ... >>> #endif >>> Can you please replace the "#if 0" with "#if 1", rebuild and post >>> the output that going fullscreen causes on the console? (Don't >>> move or resize any windows when doing this to reduce the amount of >>> output.) Also, please add this line to the fvwm config file (or >>> type it in FvwmConsole before starting acroread) >>> bugopts explainwindowplacement >>> This will produce some more output that may be helpful. >> I trust this is what you were looking for? >> cre: 0(0) 0(0) 48(4)x96(8) fw 0x00400cb3 w 0x0201 ew 0x0201 >> 'stalonetray' >> [fvwm][__execute_function]: <> No such command >> 'explainwindowplacement' > The command is > bugopts explainwindowplacement My bad. I tried FvwmCommand bugopts explainwindowplacement as a replacement since I don't have a menu item to start up FvwmConsole, and that was wrong. But after I sent my previous message I saw my error and started up the FvwmConsole, but I didn't see anything which I thought was more interesting. However, I don't know what I am looking at, so here is the output *after* giving "bugopts explainwindowplacement" to FvwmConsole: cre: 0(1) 0(2) 1910(0)x1048(0) fw 0x00401cd3 w 0x06400031 ew 0x06400031 'Adobe Reader' cre: 0(1) 0(2) 200(0)x200(0) fw 0x00401e30 w 0x064005c8 ew 0x064005c8 'acroread' cre: 0(1) 0(2) 3276(4)x1048(8) fw 0x00401cd3 w 0x06400031 ew 0x06400031 'zshguide.pdf - Adobe Reader' cre: 0(1) 0(2) 3286(4)x1080(8) fw 0x00401cd3 w 0x06400031 ew 0x06400031 'zshguide.pdf - Adobe Reader' cre: 65529(1) 65481(2) 3300(4)x1142(8) fw 0x00401cd3 w 0x06400031 ew 0x06400031 'zshguide.pdf - Adobe Reader' cre: 0(0) 0(0) 3300(4)x1142(8) fw 0x00401cd3 w 0x06400031 ew 0x06400031 'zshguide.pdf - Adobe Reader' cre: 0(1) 0(2) 200(0)x200(0) fw 0x00401ed2 w 0x064005f1 ew 0x064005f1 'acroread' cre: 1165(1) 44(2) 1910(4)x1048(8) fw 0x00401cd3 w 0x06400031 ew 0x06400031 'zshguide.pdf - Adobe Reader' > Uh, even stranger than on my box. I don't know of anything particularly weird on my machine, unless it is my screen config: xrandr Screen 0: minimum 8 x 8, current 3286 x 1080, maximum 32767 x 32767 LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 340mm x 190mm 1366x768 60.01*+ 1280x720 60.00 1024x768 60.00 1024x576 60.00 960x540 60.00 800x600 60.3256.25 864x486 60.00 640x480 59.94 720x405 60.00 680x384 60.00 640x360 60.00 DP1 disconnected (normal left inverted right x axis y axis) HDMI1 connected 1920x1080+1366+0 (normal left inverted right x axis y axis) 520mm x 290mm 1920x1080 60.00*+ 1680x1050 59.88 1280x1024 75.0260.02 1440x900 59.90 1280x960 60.00 1152x864 75.00 1024x768 75.0870.0760.00 832x624 74.55 800x600 72.1975.0060.3256.25 640x480 75.0072.8166.6760.00 720x400 70.08 VGA1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) Earlier this evening I tried turning off the external monitor and trying acroread in full screen, but even in that situation it still doesn't do full-screen correctly. >> Anything else I can provide? > Yes, a couple of things please: > 1. What size are your pages, and how many pages do you use on the > desktop? On which page do you do this? Do you have FvwmPager > running and can see more of the window on other pages? As it is not, I have 7 desks, each of which has 1 page. With two screens as above, the pages are 3286 x 1080. > If you have multiple monitors, please describe the geometry of > this setup (coordinates and size of each monitor and on which one > you expect the fullscreen window to appear). Acroread
Re: Final long term stable version
On Sun, Oct 23, 2016 at 03:12:19AM +0100, Dominik Vogt wrote: > On Sat, Oct 22, 2016 at 01:19:57PM +0100, Thomas Adam wrote: > > On Mon, Oct 17, 2016 at 11:20:25PM +0100, Dominik Vogt wrote: > > I am looking at releasing 2.6.7 this weekend. AFAIAC, this release will be > > the last stable/supported version. Up to this point I've installed all > > optional libraries and fixed all the warnings for the versions I have > > available (FreeBSD) -- so that's something. I think it's in a good state to > > be left behind, and allowing it to receive minor fixes, etc. > > Hm, is it actually a good idea to remove half the modules and > GNOME hints support in the last stable fvwm2 release? Could the > commits be rearranged so that this stuff stays in 2.6.7 and is > removed immediately after that? > > Or maybe start the long term stable branch at 2.6.6 and > cherry-pick only the patches that add something from master. Hmm. Why? I put this out for discussion ages ago. The modules I identified for removal were because: * They're broken: - FvwmSave - FvwmSaveDesk - FvwmDragWell - FvwmGTK * They're surpassed by other---more established modules---which people are * already using: - FvwmWharf -> FvwmButtons - FvwmTaskBar -> FvwmIconMan - FvwmWinList -> WindowList command and/or FvwmIconMan * They're old and/or were only ever written as a proof-of-concept: - FvwmScroll (nice, but...) - FvwmTabs - FvwmWindowMenu (WindowList command) Given all of this, I think it's safe to do this. I have heard nothing from anyone in recent years who are using the above, and/or who haven't already migrated to FvwmButtons or FvwmTaskbar for the most part. As for GNOME hints support -- that's reduced code, and isn't used in the wild at all. Should enough people complain loudly enough, sure, I might add it back in, but I really don't think they will. So I still think going ahead with 2.6.7 in this state--whereby we've made the best effort to leave it with *useful* stuff that we then don't have to fix in the future, can only been a good thing. -- Thomas Adam
Re: Final long term stable version
On Sat, Oct 22, 2016 at 01:19:57PM +0100, Thomas Adam wrote: > On Mon, Oct 17, 2016 at 11:20:25PM +0100, Dominik Vogt wrote: > I am looking at releasing 2.6.7 this weekend. AFAIAC, this release will be > the last stable/supported version. Up to this point I've installed all > optional libraries and fixed all the warnings for the versions I have > available (FreeBSD) -- so that's something. I think it's in a good state to > be left behind, and allowing it to receive minor fixes, etc. Hm, is it actually a good idea to remove half the modules and GNOME hints support in the last stable fvwm2 release? Could the commits be rearranged so that this stuff stays in 2.6.7 and is removed immediately after that? Or maybe start the long term stable branch at 2.6.6 and cherry-pick only the patches that add something from master. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
[fvwmorg/fvwm] 58d1a6: NEWS: formatting tweaks
Branch: refs/heads/master Home: https://github.com/fvwmorg/fvwm Commit: 58d1a64671c12e93554dd48e6112f6c6e0d921ed https://github.com/fvwmorg/fvwm/commit/58d1a64671c12e93554dd48e6112f6c6e0d921ed Author: Thomas AdamDate: 2016-10-23 (Sun, 23 Oct 2016) Changed paths: M NEWS Log Message: --- NEWS: formatting tweaks
Re: [fvwmorg/fvwm] 58d1a6: NEWS: formatting tweaks
On Sat, Oct 22, 2016 at 06:42:08PM -0700, GitHub wrote: > Branch: refs/heads/ta/reluctant-news > Home: https://github.com/fvwmorg/fvwm > Commit: 58d1a64671c12e93554dd48e6112f6c6e0d921ed > > https://github.com/fvwmorg/fvwm/commit/58d1a64671c12e93554dd48e6112f6c6e0d921ed > Author: Thomas Adam> Date: 2016-10-23 (Sun, 23 Oct 2016) > > Changed paths: > M NEWS > > Log Message: > --- > NEWS: formatting tweaks I had always used an Xemacs highlighting mode for the NEWS file (to highlight formatting inconsistencies). If we make format changes, it needs to be adapted. Anyway, it may be useful to others, and it might even be put in the git repo. (attached) Ciao Dominik ^_^ ^_^ -- Dominik Vogt ;; NEWS file Major Mode for XEmacs (draft) ; ; (C) 2004 Dominik Vogt ; This program is free software; you can redistribute it and/or modify ; it under the terms of the GNU General Public License as published by ; the Free Software Foundation; either version 2 of the License, or ; (at your option) any later version. ; ; This program is distributed in the hope that it will be useful, ; but WITHOUT ANY WARRANTY; without even the implied warranty of ; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ; GNU General Public License for more details. ; ; You should have received a copy of the GNU General Public License ; along with this program; if not, write to the Free Software ; Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA ; Note: The major mode was designed for xemacs and may or may not work with ; plain emacs. ; ; Copy this file to a lisp library directory, for example ; /usr/share/xemacs/site-lisp or $HOME/share/xemacs/site-lisp ; To acticate put this line in your xemacs configuration file: ; ; (load-library "news-file.el") ; ; or ; ; (load-library "/news-file.el") ;; basic mode setup ; option group (defgroup news-file nil "NEWS file mode." :tag "NEWS file" :group 'wp) ; mode hook (defcustom news-file-mode-hook nil "Hook to be run when `news-file-mode' is entered." :type 'hook :group 'news-file) ;!!!how do you do this the right way? (add-hook 'news-file-mode-hook (lambda () (setq fill-column 66))) (add-hook 'news-file-mode-hook 'auto-fill-mode) ; mode map (defvar news-file-mode-map () "Keymap used in `news-file-mode' buffers.") (if news-file-mode-map () (setq myws-mode-map (make-sparse-keymap)) ;; So far there aren't any news-file-mode specific functions ) ; auto mode definition (add-to-list 'auto-mode-alist '("O*NEWS$" . news-file-mode)) ;; syntax highlighting (defconst news-file-font-lock-keywords (list ; complain about tabs '(" " . highlight) ; separator '("^--*$" . font-lock-keyword-face) ; title + date '("^\\(Changes in \\)\\(.*\\)$" (1 font-lock-keyword-face t) (2 highlight t t)) '("^Changes in \\(alpha\\|beta\\|official\\|stable\\|development\\).*$" 1 font-lock-variable-name-face t) '("^Changes in [a-z]*\\( release \\).*$" 1 font-lock-keyword-face t) '("^Changes in [a-z]* release \\([0-9]+\\(\\.[0-9]+\\)*\\).*$" (1 font-lock-variable-name-face t t)) '("^Changes in [a-z]* release [0-9.]*\\( (\\).*$" 1 font-lock-keyword-face t) '("^Changes in [a-z]* release [0-9.]*\\( (\\)\\(\\([0-9][0-9]?-\\(Jan\\|Feb\\|Mar\\|Apr\\|May\\|Jun\\|Jul\\|Aug\\|Sep\\|Oct\\|Nov\\|Dec\\)-[1-9][0-9][0-9][0-9][0-9]*\\)\\|\\(not released yet\\)\\)).*$" (1 font-lock-keyword-face t) (2 font-lock-variable-name-face t t)) '("^Changes in [a-z]* release [0-9.]* ([-a-z0-9 ]*\\()\\).*$" 1 font-lock-keyword-face t) ; section '("^\\(\\* \\)?[a-z][ a-z]*[a-z]:$" . font-lock-preprocessor-face) ; bullets '("^\\(\\* \\).*$" 1 font-lock-keyword-face) '("^\\( +- \\).*$" 1 font-lock-keyword-face) ; faulty lines '("^[^ \n].*[^:]$" . highlight) '("^.$" . highlight) ) "Minimal highlighting expressions for NEWS file mode") (defun news-file-mode () "Major mode for editing NEWS files" (interactive) (kill-all-local-variables) (use-local-map news-file-mode-map) (setq major-mode 'news-file-mode) (setq mode-name "NEWS file") (set (make-local-variable 'font-lock-defaults) '(news-file-font-lock-keywords nil t)) (run-hooks 'news-file-mode-hook) ) (provide 'news-file-mode)
Re: [fvwmorg/fvwm] 64d424: DEVELOPERS: mention NEWS file
On Sat, Oct 22, 2016 at 06:32:12PM -0700, GitHub wrote: > Branch: refs/heads/ta/reluctant-news > Home: https://github.com/fvwmorg/fvwm > Commit: 64d4244746754610a64ed35de9ca69e557d3e25a > > https://github.com/fvwmorg/fvwm/commit/64d4244746754610a64ed35de9ca69e557d3e25a > Author: Thomas Adam> Date: 2016-10-23 (Sun, 23 Oct 2016) > > Changed paths: > M docs/DEVELOPERS.md > > Log Message: > --- > DEVELOPERS: mention NEWS file Thanks. > Let's try and get patches which introduce changes to also include changes to > the NEWS file. That's what I've always done (for user visible changes or internal changes with a high risk of breaking things). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: regression from 2.6.5 to 2.6.6 ?
As a little bit of explanation how to read this output: On Sat, Oct 22, 2016 at 10:00:16PM -0300, zli...@ns.sympatico.ca wrote: > cre: 935(1) 0(2) 985(0)x1080(0) fw 0x00401005 w 0x06200031 ew 0x06200031 > 'Adobe Reader' ^^^ ^^^ ^^^ ^^ X Y Width HeightInternal window id These are the values from the COnfigureRequest, i.e. the message that was generated when the application tried to change the window geometry. If the number is parentheses after the value if zero, that bit of information is unused, if it's non-zero, that part of the geometry was requested. This request looks sensible, and from that I guess your screen is 1920x1080 pixels (16:9). > cre: 0(1) 0(2) 3276(4)x1048(8) fw 0x00401005 w 0x06200031 ew 0x06200031 > 'zshguide.pdf - Adobe Reader' "Move window to +0+0 and resize to 3276x1048" The width looks weird. > cre: 0(1) 0(2) 3286(4)x1080(8) fw 0x00401005 w 0x06200031 ew 0x06200031 > 'zshguide.pdf - Adobe Reader' Similar, but some decorations seem to have been taken into account. From the requested height I assume your window window border is 5 pixels thick and the window title is 22 pixels high. > cre: 65529(1) 65481(2) 3300(4)x1142(8) fw 0x00401005 w 0x06200031 ew > 0x06200031 'zshguide.pdf - Adobe Reader' ^^ The program has added space for another border around the window by subtracting some pixels from X and Y and adding some to Width and Height. The coordinates have become negative, but the program seems to store them as "unsigned short", not as signed int as it should. So it gets a wraparound and requests some astronomically huge coordinates (which the X server limits to 16 bits again). > cre: 0(0) 0(0) 3300(4)x1142(8) fw 0x00401005 w 0x06200031 ew 0x06200031 > 'zshguide.pdf - Adobe Reader' "Resize window (without actually changing its size) > cre: 1433(1) 65517(2) 985(4)x1080(8) fw 0x00401005 w 0x06200031 ew 0x06200031 > 'zshguide.pdf - Adobe Reader' Back to the original size with what looks like random coordinates: 1433/18. So, is this what you see, a window starting at X=1433 with a page that is about 3300 pixels wide? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
[fvwmorg/fvwm] 58d1a6: NEWS: formatting tweaks
Branch: refs/heads/ta/reluctant-news Home: https://github.com/fvwmorg/fvwm Commit: 58d1a64671c12e93554dd48e6112f6c6e0d921ed https://github.com/fvwmorg/fvwm/commit/58d1a64671c12e93554dd48e6112f6c6e0d921ed Author: Thomas AdamDate: 2016-10-23 (Sun, 23 Oct 2016) Changed paths: M NEWS Log Message: --- NEWS: formatting tweaks
[fvwmorg/fvwm] abed4e: NEWS: changes since 2.6.6
Branch: refs/heads/master Home: https://github.com/fvwmorg/fvwm Commit: abed4eae18d0852f3a1b5a943221bb2147328417 https://github.com/fvwmorg/fvwm/commit/abed4eae18d0852f3a1b5a943221bb2147328417 Author: Thomas AdamDate: 2016-10-23 (Sun, 23 Oct 2016) Changed paths: M NEWS Log Message: --- NEWS: changes since 2.6.6 Commit: 64d4244746754610a64ed35de9ca69e557d3e25a https://github.com/fvwmorg/fvwm/commit/64d4244746754610a64ed35de9ca69e557d3e25a Author: Thomas Adam Date: 2016-10-23 (Sun, 23 Oct 2016) Changed paths: M docs/DEVELOPERS.md Log Message: --- DEVELOPERS: mention NEWS file Let's try and get patches which introduce changes to also include changes to the NEWS file. Compare: https://github.com/fvwmorg/fvwm/compare/f160e7806648...64d424474675
[fvwmorg/fvwm] 64d424: DEVELOPERS: mention NEWS file
Branch: refs/heads/ta/reluctant-news Home: https://github.com/fvwmorg/fvwm Commit: 64d4244746754610a64ed35de9ca69e557d3e25a https://github.com/fvwmorg/fvwm/commit/64d4244746754610a64ed35de9ca69e557d3e25a Author: Thomas AdamDate: 2016-10-23 (Sun, 23 Oct 2016) Changed paths: M docs/DEVELOPERS.md Log Message: --- DEVELOPERS: mention NEWS file Let's try and get patches which introduce changes to also include changes to the NEWS file.
[fvwmorg/fvwm] abed4e: NEWS: changes since 2.6.6
Branch: refs/heads/ta/reluctant-news Home: https://github.com/fvwmorg/fvwm Commit: abed4eae18d0852f3a1b5a943221bb2147328417 https://github.com/fvwmorg/fvwm/commit/abed4eae18d0852f3a1b5a943221bb2147328417 Author: Thomas AdamDate: 2016-10-23 (Sun, 23 Oct 2016) Changed paths: M NEWS Log Message: --- NEWS: changes since 2.6.6
Re: [fvwmorg/fvwm] b753a0: Remove stale files
On Sun, Oct 23, 2016 at 01:55:38AM +0100, Dominik Vogt wrote: > On Sun, Oct 23, 2016 at 01:32:17AM +0100, Thomas Adam wrote: > > On Sun, Oct 23, 2016 at 01:28:17AM +0100, Dominik Vogt wrote: > > > On Thu, Aug 11, 2016 at 04:23:47PM -0700, GitHub wrote: > > > > Branch: refs/heads/ta/install > > > > Home: https://github.com/fvwmorg/fvwm > > > > Commit: b753a06d2eb0325fd682563fcc127acbd6cf7813 > > > > > > > > https://github.com/fvwmorg/fvwm/commit/b753a06d2eb0325fd682563fcc127acbd6cf7813 > > > > Author: Thomas Adam> > > > Date: 2016-08-11 (Thu, 11 Aug 2016) > > > > > > > > Changed paths: > > > > R ChangeLog > > > > R ChangeLog-pre-2.4 > > > > R ChangeLog-pre-2.6.6 > > > > R NEWS > > > > > > Hm, what's the logic behind removing the NEWS file? Is it > > > somewhere else now? > > > > It's mostly here: http://fvwm.org/features/ (because stuff hasn't changed), > > > and its successor will be release notes for the next version on Github > > anyway. > > Okay, and where is the source for the release notes? This needs > to be kept in the fvwm source tree. I don't see me writing up any > decent quality release notes, say, half a year after committing a > patch. This stuff needs to be written down when the work is done, > not at some indefinite time in the future. > > (I see fvwm more as a GNU style project rather than a Github style > project. Using features of git or Github is fine, but I don't > think we should give up the GNU project standards, where > applicable: https://www.gnu.org/prep/standards/standards.txt Specifically, it won't cost much to to stick to the following: 3.5 Conditional Compilation 4.4 Formatting Error Messages -> future work 4.5 Standards for Interfaces Generally 4.6 Standards for Graphical Interfaces 4.7 Standards for Command Line Interfaces 4.8 Standards for Dynamic Plug-in Interfaces 4.9 Table of Long Options 5.5 Portability between System Types 5.6 Portability between CPUs 5.7 Calling System Functions 5.8 Internationalization 5.9 Character Set 5.10 Quote Characters 6.7 The NEWS File 6.8 Change Logs -> now kept in Git 6.9 Man Pages 7.1 How Configuration Should Work 7.2 Makefile Conventions Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: regression from 2.6.5 to 2.6.6 ?
On Sat, Oct 22, 2016 at 10:00:16PM -0300, zli...@ns.sympatico.ca wrote: > On Sun, Oct 23, 2016 at 01:21 (+0100), Dominik Vogt wrote: > > > On Sat, Oct 22, 2016 at 08:36:10PM -0300, zli...@ns.sympatico.ca wrote: > >> On Sun, Oct 23, 2016 at 00:20 (+0100), Thomas Adam wrote: > > >>> On Sat, Oct 22, 2016 at 07:56:31PM -0300, zli...@ns.sympatico.ca wrote: > I cloned the git version about 15 minutes ago and compiled it, and > acroread still does not go full-screen correctly. > > >>> Can you reproduce this using a more accessible program, please? I'm using > >>> FreeBSD. > > >> No, I can't. That is, all other programs I use which have a > >> "full-screen" mode work fine. > > > All right, I can see that acroread generates some weird requests > > for new size and position. For me, the size is good, but the > > position is totally screwed (x=65600, y=66000). > > > In fvwm/events.c at line 1077 there is this debug statement: > > > #if 0 > > fprintf(stderr, > > "cre: %d(%d) %d(%d) %d(%d)x%d(%d) fw 0x%08x w 0x%08x " > > ... > > #endif > > > Can you please replace the "#if 0" with "#if 1", rebuild and post > > the output that going fullscreen causes on the console? (Don't > > move or resize any windows when doing this to reduce the amount of > > output.) Also, please add this line to the fvwm config file (or > > type it in FvwmConsole before starting acroread) > > > bugopts explainwindowplacement > > > This will produce some more output that may be helpful. > > I trust this is what you were looking for? > > cre: 0(0) 0(0) 48(4)x96(8) fw 0x00400cb3 w 0x0201 ew 0x0201 > 'stalonetray' > [fvwm][__execute_function]: <> No such command 'explainwindowplacement' The command is bugopts explainwindowplacement > cre: 935(1) 0(2) 985(0)x1080(0) fw 0x00401005 w 0x06200031 ew 0x06200031 > 'Adobe Reader' > cre: 0(1) 0(2) 200(0)x200(0) fw 0x00401166 w 0x0620086b ew 0x0620086b > 'acroread' > cre: 0(1) 0(2) 3276(4)x1048(8) fw 0x00401005 w 0x06200031 ew 0x06200031 > 'zshguide.pdf - Adobe Reader' > cre: 0(1) 0(2) 3286(4)x1080(8) fw 0x00401005 w 0x06200031 ew 0x06200031 > 'zshguide.pdf - Adobe Reader' > cre: 65529(1) 65481(2) 3300(4)x1142(8) fw 0x00401005 w 0x06200031 ew > 0x06200031 'zshguide.pdf - Adobe Reader' > cre: 0(0) 0(0) 3300(4)x1142(8) fw 0x00401005 w 0x06200031 ew 0x06200031 > 'zshguide.pdf - Adobe Reader' > cre: 0(1) 0(2) 200(0)x200(0) fw 0x004012ac w 0x06200899 ew 0x06200899 > 'acroread' > cre: 1433(1) 65517(2) 985(4)x1080(8) fw 0x00401005 w 0x06200031 ew 0x06200031 > 'zshguide.pdf - Adobe Reader' Uh, even stranger than on my box. > Anything else I can provide? Yes, a couple of things please: 1. What size are your pages, and how many pages do you use on the desktop? On which page do you do this? Do you have FvwmPager running and can see more of the window on other pages? If you have multiple monitors, please describe the geometry of this setup (coordinates and size of each monitor and on which one you expect the fullscreen window to appear). 2. Please do this again (and post the new output), and then, without movind or resizing the window, run FvwmIdent on the reader window and post the contents of the FvwmIdent window (a small screenshot is fine). (I need the new console output so that I can relate the information in FvwmIdent to the debug output on the console.) 3. Is this really a regression between 2.6.6 and 2.6.5, or did you also switch to a different acroread release? (If so, which one did work with 2.6.5?) And please, (unless you write sensitive information), reply to fvm-work...@fvwm.org, not to me personally. (This should happen automatically if you hit the "reply" button in your mail porogram.) It might also help to include your config file or at least the commands not refering to modules. (You can send that to me directly if you don't want to write it to the list.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
[zli...@ns.sympatico.ca: Re: regression from 2.6.5 to 2.6.6 ?]
- Forwarded message from zli...@ns.sympatico.ca - Date: Sat, 22 Oct 2016 22:00:16 -0300 From: zli...@ns.sympatico.ca To: Dominik VogtSubject: Re: regression from 2.6.5 to 2.6.6 ? User-Agent: Mutt/1.6.1 (2016-04-27) On Sun, Oct 23, 2016 at 01:21 (+0100), Dominik Vogt wrote: > On Sat, Oct 22, 2016 at 08:36:10PM -0300, zli...@ns.sympatico.ca wrote: >> On Sun, Oct 23, 2016 at 00:20 (+0100), Thomas Adam wrote: >>> On Sat, Oct 22, 2016 at 07:56:31PM -0300, zli...@ns.sympatico.ca wrote: I cloned the git version about 15 minutes ago and compiled it, and acroread still does not go full-screen correctly. >>> Can you reproduce this using a more accessible program, please? I'm using >>> FreeBSD. >> No, I can't. That is, all other programs I use which have a >> "full-screen" mode work fine. > All right, I can see that acroread generates some weird requests > for new size and position. For me, the size is good, but the > position is totally screwed (x=65600, y=66000). > In fvwm/events.c at line 1077 there is this debug statement: > #if 0 > fprintf(stderr, > "cre: %d(%d) %d(%d) %d(%d)x%d(%d) fw 0x%08x w 0x%08x " > ... > #endif > Can you please replace the "#if 0" with "#if 1", rebuild and post > the output that going fullscreen causes on the console? (Don't > move or resize any windows when doing this to reduce the amount of > output.) Also, please add this line to the fvwm config file (or > type it in FvwmConsole before starting acroread) > bugopts explainwindowplacement > This will produce some more output that may be helpful. I trust this is what you were looking for? cre: 0(0) 0(0) 48(4)x96(8) fw 0x00400cb3 w 0x0201 ew 0x0201 'stalonetray' [fvwm][__execute_function]: <> No such command 'explainwindowplacement' cre: 935(1) 0(2) 985(0)x1080(0) fw 0x00401005 w 0x06200031 ew 0x06200031 'Adobe Reader' cre: 0(1) 0(2) 200(0)x200(0) fw 0x00401166 w 0x0620086b ew 0x0620086b 'acroread' cre: 0(1) 0(2) 3276(4)x1048(8) fw 0x00401005 w 0x06200031 ew 0x06200031 'zshguide.pdf - Adobe Reader' cre: 0(1) 0(2) 3286(4)x1080(8) fw 0x00401005 w 0x06200031 ew 0x06200031 'zshguide.pdf - Adobe Reader' cre: 65529(1) 65481(2) 3300(4)x1142(8) fw 0x00401005 w 0x06200031 ew 0x06200031 'zshguide.pdf - Adobe Reader' cre: 0(0) 0(0) 3300(4)x1142(8) fw 0x00401005 w 0x06200031 ew 0x06200031 'zshguide.pdf - Adobe Reader' cre: 0(1) 0(2) 200(0)x200(0) fw 0x004012ac w 0x06200899 ew 0x06200899 'acroread' cre: 1433(1) 65517(2) 985(4)x1080(8) fw 0x00401005 w 0x06200031 ew 0x06200031 'zshguide.pdf - Adobe Reader' Anything else I can provide? - End forwarded message - Ciao Dominik ^_^ ^_^ -- Dominik Vogt
[fvwmorg/fvwm] f160e7: Reinstate NEWS file
Branch: refs/heads/master Home: https://github.com/fvwmorg/fvwm Commit: f160e7806648e7a1cc5b7f42eba393ed30913d4a https://github.com/fvwmorg/fvwm/commit/f160e7806648e7a1cc5b7f42eba393ed30913d4a Author: Thomas AdamDate: 2016-10-23 (Sun, 23 Oct 2016) Changed paths: A NEWS Log Message: --- Reinstate NEWS file Useful to track changes between versions, rather than relying on other means (such as git commit messages, and per-release information) which would otherwise have to be generated at time of the release. This also helps establish that FVWM is a GNU project.
[fvwmorg/fvwm] f160e7: Reinstate NEWS file
Branch: refs/heads/ta/reluctant-news Home: https://github.com/fvwmorg/fvwm Commit: f160e7806648e7a1cc5b7f42eba393ed30913d4a https://github.com/fvwmorg/fvwm/commit/f160e7806648e7a1cc5b7f42eba393ed30913d4a Author: Thomas AdamDate: 2016-10-23 (Sun, 23 Oct 2016) Changed paths: A NEWS Log Message: --- Reinstate NEWS file Useful to track changes between versions, rather than relying on other means (such as git commit messages, and per-release information) which would otherwise have to be generated at time of the release. This also helps establish that FVWM is a GNU project.
Re: [fvwmorg/fvwm] b753a0: Remove stale files
On Sun, Oct 23, 2016 at 01:55:38AM +0100, Dominik Vogt wrote: > The NEWS file has been a readable summary of user visible changes. > I don't see how this could be generated from commit information > and diffs in git. It's back. -- Thomas Adam
Re: [fvwmorg/fvwm] b753a0: Remove stale files
On Sun, Oct 23, 2016 at 01:32:17AM +0100, Thomas Adam wrote: > On Sun, Oct 23, 2016 at 01:28:17AM +0100, Dominik Vogt wrote: > > On Thu, Aug 11, 2016 at 04:23:47PM -0700, GitHub wrote: > > > Branch: refs/heads/ta/install > > > Home: https://github.com/fvwmorg/fvwm > > > Commit: b753a06d2eb0325fd682563fcc127acbd6cf7813 > > > > > > https://github.com/fvwmorg/fvwm/commit/b753a06d2eb0325fd682563fcc127acbd6cf7813 > > > Author: Thomas Adam> > > Date: 2016-08-11 (Thu, 11 Aug 2016) > > > > > > Changed paths: > > > R ChangeLog > > > R ChangeLog-pre-2.4 > > > R ChangeLog-pre-2.6.6 > > > R NEWS > > > > Hm, what's the logic behind removing the NEWS file? Is it > > somewhere else now? > > It's mostly here: http://fvwm.org/features/ (because stuff hasn't changed), > and its successor will be release notes for the next version on Github anyway. Okay, and where is the source for the release notes? This needs to be kept in the fvwm source tree. I don't see me writing up any decent quality release notes, say, half a year after committing a patch. This stuff needs to be written down when the work is done, not at some indefinite time in the future. (I see fvwm more as a GNU style project rather than a Github style project. Using features of git or Github is fine, but I don't think we should give up the GNU project standards, where applicable: https://www.gnu.org/prep/standards/standards.txt ) I don't care much about the other files (ChangeLogs and such), but fvwm should have a NEWS file like other GNU projects. > If people really want more detail they can look in git. The point of removing > these files is duplicating these things when git provides most of them is a > good thing. The NEWS file has been a readable summary of user visible changes. I don't see how this could be generated from commit information and diffs in git. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Final long term stable version
On Sat, Oct 22, 2016 at 01:19:57PM +0100, Thomas Adam wrote: > On the back of the current TODO.md file, I'll draft a list of key-features as > I see them and send it out for review/discussion here. I've tentatively started a skeleton file to collate ideas. See the 'ta/next' branch in git, hence: https://github.com/fvwmorg/fvwm/blob/ta/next/FVWM3.md -- Thomas Adam
[fvwmorg/fvwm] 3e33ca: FVWM.md: WIP for ideas...
Branch: refs/heads/ta/next Home: https://github.com/fvwmorg/fvwm Commit: 3e33ca238ecf4a42dbf45238a0575db2b2399326 https://github.com/fvwmorg/fvwm/commit/3e33ca238ecf4a42dbf45238a0575db2b2399326 Author: Thomas AdamDate: 2016-10-23 (Sun, 23 Oct 2016) Changed paths: A FVWM3.md Log Message: --- FVWM.md: WIP for ideas...
Re: [fvwmorg/fvwm] b753a0: Remove stale files
On Sun, Oct 23, 2016 at 01:28:17AM +0100, Dominik Vogt wrote: > On Thu, Aug 11, 2016 at 04:23:47PM -0700, GitHub wrote: > > Branch: refs/heads/ta/install > > Home: https://github.com/fvwmorg/fvwm > > Commit: b753a06d2eb0325fd682563fcc127acbd6cf7813 > > > > https://github.com/fvwmorg/fvwm/commit/b753a06d2eb0325fd682563fcc127acbd6cf7813 > > Author: Thomas Adam> > Date: 2016-08-11 (Thu, 11 Aug 2016) > > > > Changed paths: > > R ChangeLog > > R ChangeLog-pre-2.4 > > R ChangeLog-pre-2.6.6 > > R NEWS > > Hm, what's the logic behind removing the NEWS file? Is it > somewhere else now? It's mostly here: http://fvwm.org/features/ (because stuff hasn't changed), and its successor will be release notes for the next version on Github anyway. If people really want more detail they can look in git. The point of removing these files is duplicating these things when git provides most of them is a good thing. -- Thomas Adam
Re: [fvwmorg/fvwm] b753a0: Remove stale files
On Thu, Aug 11, 2016 at 04:23:47PM -0700, GitHub wrote: > Branch: refs/heads/ta/install > Home: https://github.com/fvwmorg/fvwm > Commit: b753a06d2eb0325fd682563fcc127acbd6cf7813 > > https://github.com/fvwmorg/fvwm/commit/b753a06d2eb0325fd682563fcc127acbd6cf7813 > Author: Thomas Adam> Date: 2016-08-11 (Thu, 11 Aug 2016) > > Changed paths: > R ChangeLog > R ChangeLog-pre-2.4 > R ChangeLog-pre-2.6.6 > R NEWS Hm, what's the logic behind removing the NEWS file? Is it somewhere else now? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: regression from 2.6.5 to 2.6.6 ?
On Sat, Oct 22, 2016 at 08:36:10PM -0300, zli...@ns.sympatico.ca wrote: > On Sun, Oct 23, 2016 at 00:20 (+0100), Thomas Adam wrote: > > > On Sat, Oct 22, 2016 at 07:56:31PM -0300, zli...@ns.sympatico.ca wrote: > >> I cloned the git version about 15 minutes ago and compiled it, and > >> acroread still does not go full-screen correctly. > > > Can you reproduce this using a more accessible program, please? I'm using > > FreeBSD. > > No, I can't. That is, all other programs I use which have a > "full-screen" mode work fine. All right, I can see that acroread generates some weird requests for new size and position. For me, the size is good, but the position is totally screwed (x=65600, y=66000). In fvwm/events.c at line 1077 there is this debug statement: #if 0 fprintf(stderr, "cre: %d(%d) %d(%d) %d(%d)x%d(%d) fw 0x%08x w 0x%08x " ... #endif Can you please replace the "#if 0" with "#if 1", rebuild and post the output that going fullscreen causes on the console? (Don't move or resize any windows when doing this to reduce the amount of output.) Also, please add this line to the fvwm config file (or type it in FvwmConsole before starting acroread) bugopts explainwindowplacement This will produce some more output that may be helpful. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: regression from 2.6.5 to 2.6.6 ?
On Sun, Oct 23, 2016 at 00:20 (+0100), Thomas Adam wrote: > On Sat, Oct 22, 2016 at 07:56:31PM -0300, zli...@ns.sympatico.ca wrote: >> I cloned the git version about 15 minutes ago and compiled it, and >> acroread still does not go full-screen correctly. > Can you reproduce this using a more accessible program, please? I'm using > FreeBSD. No, I can't. That is, all other programs I use which have a "full-screen" mode work fine. For example, -> firefox -> xournal -> evince -> chrome -> opera are all OK. I may use other programs which work fine too, but acroread is the one which does not go into full-screen mode correctly.
Re: Need of a "devel" branch?
On Sat, Oct 22, 2016 at 11:41:54PM +0100, Dominik Vogt wrote: > Unless we're doing lots of disruptive stuff I'd prefer to > propagate completed patchsets into master early so they get more > testing. Yup. Well, that's what we have enforced right now, so I think it's working as intended. Of course, during development on a given feature, there's nothing stopping a few developers working against a common topic integration branch of their own, which is then used as the topic-branch for review before it hits master. I suspect we'll never get there though, given the low number of developers, alas. -- Thomas Adam
Re: regression from 2.6.5 to 2.6.6 ?
On Sat, Oct 22, 2016 at 07:56:31PM -0300, zli...@ns.sympatico.ca wrote: > I cloned the git version about 15 minutes ago and compiled it, and > acroread still does not go full-screen correctly. Can you reproduce this using a more accessible program, please? I'm using FreeBSD. -- Thomas Adam
Re: regression from 2.6.5 to 2.6.6 ?
On Sat, Oct 22, 2016 at 23:29 (+0100), Thomas Adam wrote: > On Sat, Oct 22, 2016 at 07:26:50PM -0300, zli...@ns.sympatico.ca wrote: >> On Sun, Jul 17, 2016 at 15:08 (+0100), Thomas Adam wrote: >>> On Sun, Jul 17, 2016 at 08:38:10AM -0300, zli...@ns.sympatico.ca wrote: On Sat, Jul 16, 2016 at 23:27 (+0100), Thomas Adam wrote: > On Sat, Jul 16, 2016 at 07:10:24PM -0300, zli...@ns.sympatico.ca wrote: >> I recently upgraded a computer from Slackware64 14.1 to 14.2, which >> bumped by fvwm version from 2.6.5 to 2.6.6. >> With the new system, when I ask Adobe reader 9.5.5 to go full-screen, >> I get a window with no decorations, but it only occupies about 3/4 of >> the screen, off to the lower right. > I'm hearing reports of this problem, yes. Can you try this with > the version from git (master branch)? And send me your fvwm > configuration file, since I can't reproduce this problem. The git version as of 10 minutes ago still has this problem, unfortunately. >>> Thanks; I'll put a fix in later on. >> Any chance of this getting in to 2.6.7, if it isn't already in? > I thought I had. The fact that you're asking suggests it would be > helpful if you could test 'master' and report back any problems. I cloned the git version about 15 minutes ago and compiled it, and acroread still does not go full-screen correctly. If you have a fix you would like me to try, or if there is something specific I can report from my system which you need, just let me know.
Re: Need of a "devel" branch?
On Sat, Oct 22, 2016 at 11:23:17PM +0100, Thomas Adam wrote: > On Sat, Oct 22, 2016 at 11:12:58PM +0100, Dominik Vogt wrote: > > A "devel" branch could come in handy. When a feature is complete > > or ready for reviews, the patches are placed on the devel branch > > and then every ambitious user can try them out and report > > problems. The "devel" branch would receive the same automatic > > testing as master, but can be rebased or rewritten at any time. > > > > Releasing commits drom devel to master just means to do a fast > > forward rebase of the master's tip to a commit on devel. > > > > Of course, devel must never be rebased past the current master, > > and merge commits on the devel branch should be avoided (so it can > > be reabes without disrupting things). > > What you're fundamentally describing is what the git project does, although > they call their next-release-branch "next", rather than "devel" (the name > really doesn't matter). See: > > https://git-scm.com/docs/gitworkflows > > I suspect that's overkill for us, Yes, you're right. We're not a project with dozens of developers, so most of it is overkill. > although we could adopt some of this --- > namely, a devel branch which we rewind against master after every release. Unless we're doing lots of disruptive stuff I'd prefer to propagate completed patchsets into master early so they get more testing. > Topic branches still apply, and if any fixes are needed, they have to come > from those branches and nowhere else. Yes, nobody should be working on the integration or release branches directly. Although it's a bit more typing, I like it that all changes go through mandatory topic branches. Makes you work more carefully. > I don't think we need anything like their 'pu' concept since we don't have > enough development. Yep. After all, it's not possible to completely prevent bad commits from creeping into master. Things can be changed on master, but then it's the old CVS-like ways of undoing old commits. It's not the end of the world though. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: regression from 2.6.5 to 2.6.6 ?
On Sat, Oct 22, 2016 at 07:26:50PM -0300, zli...@ns.sympatico.ca wrote: > On Sun, Jul 17, 2016 at 15:08 (+0100), Thomas Adam wrote: > > > On Sun, Jul 17, 2016 at 08:38:10AM -0300, zli...@ns.sympatico.ca wrote: > >> On Sat, Jul 16, 2016 at 23:27 (+0100), Thomas Adam wrote: > > >>> On Sat, Jul 16, 2016 at 07:10:24PM -0300, zli...@ns.sympatico.ca wrote: > I recently upgraded a computer from Slackware64 14.1 to 14.2, which > bumped by fvwm version from 2.6.5 to 2.6.6. > > With the new system, when I ask Adobe reader 9.5.5 to go full-screen, > I get a window with no decorations, but it only occupies about 3/4 of > the screen, off to the lower right. > > >>> I'm hearing reports of this problem, yes. Can you try this with the > >>> version > >>> from git (master branch)? And send me your fvwm configuration file, > >>> since I > >>> can't reproduce this problem. > > >> The git version as of 10 minutes ago still has this problem, unfortunately. > > > Thanks; I'll put a fix in later on. > > Any chance of this getting in to 2.6.7, if it isn't already in? I thought I had. The fact that you're asking suggests it would be helpful if you could test 'master' and report back any problems. -- Thomas Adam
Re: regression from 2.6.5 to 2.6.6 ?
On Sun, Jul 17, 2016 at 15:08 (+0100), Thomas Adam wrote: > On Sun, Jul 17, 2016 at 08:38:10AM -0300, zli...@ns.sympatico.ca wrote: >> On Sat, Jul 16, 2016 at 23:27 (+0100), Thomas Adam wrote: >>> On Sat, Jul 16, 2016 at 07:10:24PM -0300, zli...@ns.sympatico.ca wrote: I recently upgraded a computer from Slackware64 14.1 to 14.2, which bumped by fvwm version from 2.6.5 to 2.6.6. With the new system, when I ask Adobe reader 9.5.5 to go full-screen, I get a window with no decorations, but it only occupies about 3/4 of the screen, off to the lower right. >>> I'm hearing reports of this problem, yes. Can you try this with the version >>> from git (master branch)? And send me your fvwm configuration file, since I >>> can't reproduce this problem. >> The git version as of 10 minutes ago still has this problem, unfortunately. > Thanks; I'll put a fix in later on. Any chance of this getting in to 2.6.7, if it isn't already in? Thanks.
Re: Need of a "devel" branch?
On Sat, Oct 22, 2016 at 11:12:58PM +0100, Dominik Vogt wrote: > A "devel" branch could come in handy. When a feature is complete > or ready for reviews, the patches are placed on the devel branch > and then every ambitious user can try them out and report > problems. The "devel" branch would receive the same automatic > testing as master, but can be rebased or rewritten at any time. > > Releasing commits drom devel to master just means to do a fast > forward rebase of the master's tip to a commit on devel. > > Of course, devel must never be rebased past the current master, > and merge commits on the devel branch should be avoided (so it can > be reabes without disrupting things). What you're fundamentally describing is what the git project does, although they call their next-release-branch "next", rather than "devel" (the name really doesn't matter). See: https://git-scm.com/docs/gitworkflows I suspect that's overkill for us, although we could adopt some of this --- namely, a devel branch which we rewind against master after every release. Topic branches still apply, and if any fixes are needed, they have to come from those branches and nowhere else. I don't think we need anything like their 'pu' concept since we don't have enough development. -- Thomas Adam
Need of a "devel" branch?
In the times of CVS we've pushed every dirty commit to the one CVS branch we had, undoing things if need be. Nowadays using Git I feel really unconfortable doing this, not everything should be pushed to the stable branch right away. Although we do have topic branches with proposed changes now and everybody could test them easily, I suspect there would be very few people who would actually try out a topic branch. A "devel" branch could come in handy. When a feature is complete or ready for reviews, the patches are placed on the devel branch and then every ambitious user can try them out and report problems. The "devel" branch would receive the same automatic testing as master, but can be rebased or rewritten at any time. Releasing commits drom devel to master just means to do a fast forward rebase of the master's tip to a commit on devel. Of course, devel must never be rebased past the current master, and merge commits on the devel branch should be avoided (so it can be reabes without disrupting things). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] c0ae18: Fix Gcc warnings.
On Sat, Oct 22, 2016 at 11:02:16PM +0100, Dominik Vogt wrote: > On Sat, Oct 22, 2016 at 10:55:39PM +0100, Thomas Adam wrote: > > OK, this looks better. Thanks! > > > > GCC/Clang don't moan at these changes, which is good. The changes built via > > travis-ci just fine. > > > > I say you're good to merge to master. > > Good. I think I've also figured out how these safety measures on > master work. Thanks for your patience, Thomas. Not at all, you're the first person who's actually had to go through this process who wasn't me so it's really important we get this right. I hope things are clearer now; if DEVELOPERS.md needs to change, feel free so that it helps the next person who comes along. -- Thomas Adam
Re: [fvwmorg/fvwm] c0ae18: Fix Gcc warnings.
On Sat, Oct 22, 2016 at 10:55:39PM +0100, Thomas Adam wrote: > OK, this looks better. Thanks! > > GCC/Clang don't moan at these changes, which is good. The changes built via > travis-ci just fine. > > I say you're good to merge to master. Good. I think I've also figured out how these safety measures on master work. Thanks for your patience, Thomas. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
[fvwmorg/fvwm] c0ae18: Fix Gcc warnings.
Branch: refs/heads/master Home: https://github.com/fvwmorg/fvwm Commit: c0ae18064466425f3864bd1e3baf03815cae4a44 https://github.com/fvwmorg/fvwm/commit/c0ae18064466425f3864bd1e3baf03815cae4a44 Author: Dominik VogtDate: 2016-10-22 (Sat, 22 Oct 2016) Changed paths: M configure.ac M fvwm/add_window.c M fvwm/events.c M fvwm/frame.c M fvwm/icons.c M fvwm/menus.c M fvwm/session.c M libs/FGettext.c M libs/FImage.c M libs/FRender.c M libs/FScreen.c M libs/Fft.c M libs/Ficonv.c M libs/fsm.c M modules/FvwmConsole/getline.c Log Message: --- Fix Gcc warnings. * fvwm/session.c (SessionInit, set_sm_properties): Fix warnings. * fvwm/frame.c (frame_prepare_animation_shape) (frame_setup_shape): Fix warnings. * fvwm/icons.c (CreateIconWindow): Fix warnings. * fvwm/add_window.c (setup_style_and_decor): Fix warnings. * fvwm/events.c (_handle_cr_on_shaped): Fix warnings. * configure.ac: Add helper macro SUPPRESS_UNUSED_VAR_WARNING to fake using a variable and its value in certain hard to fix places. * fvwm/menus.c (size_menu_vertically): Fix write access to read-only location with gettext. libs: * fsm.c (SaveYourselfPhase2ReqProc, SaveYourselfDoneProc) (NewConnectionMsg): Fix warnings. * FGettext.c (FGettextInit): Fix warnings. * FImage.c (FGetFImage): Fix warnings. * Fft.c (FftGetFont): Fix warnings. * FRender.c (FRenderVisualInit, FRenderCreateShadePicture) (FRenderTintPicture, FRenderTintRectangle, FRenderRender): Fix warnings. * FScreen.c (FScreenInit): Fix warnings. * Ficonv.c (is_translit_supported, convert_charsets): Fix warnings.
Re: [fvwmorg/fvwm] c0ae18: Fix Gcc warnings.
On Sat, Oct 22, 2016 at 10:53:10PM +0100, Dominik Vogt wrote: > Different approach at fixing the warning. Hopefully this one > works without removing any "uninitialised variable" warnings. The > macro SUPPRESS_UNUSED_VAR_WARNING(var) from config.h is used to > remove the "set but not used" warning in the discussed case. > > I've forced a new version of the branch replacing the old one. > > Plese double check this is sensible. OK, this looks better. Thanks! GCC/Clang don't moan at these changes, which is good. The changes built via travis-ci just fine. I say you're good to merge to master. -- Thomas Adam
Re: [fvwmorg/fvwm] c0ae18: Fix Gcc warnings.
Different approach at fixing the warning. Hopefully this one works without removing any "uninitialised variable" warnings. The macro SUPPRESS_UNUSED_VAR_WARNING(var) from config.h is used to remove the "set but not used" warning in the discussed case. I've forced a new version of the branch replacing the old one. Plese double check this is sensible. > * fvwm/session.c (SessionInit, set_sm_properties): Fix warnings. > * fvwm/frame.c (frame_prepare_animation_shape) > (frame_setup_shape): Fix warnings. > * fvwm/icons.c (CreateIconWindow): Fix warnings. > * fvwm/add_window.c (setup_style_and_decor): Fix warnings. > * fvwm/events.c (_handle_cr_on_shaped): Fix warnings. > * configure.ac: Add helper macro SUPPRESS_UNUSED_VAR_WARNING to fake > using a variable and its value in certain hard to fix places. > * fvwm/menus.c (size_menu_vertically): Fix write access to read-only > location with gettext. > > libs: > * fsm.c (SaveYourselfPhase2ReqProc, SaveYourselfDoneProc) > (NewConnectionMsg): Fix warnings. > * FGettext.c (FGettextInit): Fix warnings. > * FImage.c (FGetFImage): Fix warnings. > * Fft.c (FftGetFont): Fix warnings. > * FRender.c (FRenderVisualInit, FRenderCreateShadePicture) > (FRenderTintPicture, FRenderTintRectangle, FRenderRender): Fix > warnings. > * FScreen.c (FScreenInit): Fix warnings. > * Ficonv.c (is_translit_supported, convert_charsets): Fix warnings. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
[fvwmorg/fvwm] c0ae18: Fix Gcc warnings.
Branch: refs/heads/dv-gcc-warning-fixes Home: https://github.com/fvwmorg/fvwm Commit: c0ae18064466425f3864bd1e3baf03815cae4a44 https://github.com/fvwmorg/fvwm/commit/c0ae18064466425f3864bd1e3baf03815cae4a44 Author: Dominik VogtDate: 2016-10-22 (Sat, 22 Oct 2016) Changed paths: M configure.ac M fvwm/add_window.c M fvwm/events.c M fvwm/frame.c M fvwm/icons.c M fvwm/menus.c M fvwm/session.c M libs/FGettext.c M libs/FImage.c M libs/FRender.c M libs/FScreen.c M libs/Fft.c M libs/Ficonv.c M libs/fsm.c M modules/FvwmConsole/getline.c Log Message: --- Fix Gcc warnings. * fvwm/session.c (SessionInit, set_sm_properties): Fix warnings. * fvwm/frame.c (frame_prepare_animation_shape) (frame_setup_shape): Fix warnings. * fvwm/icons.c (CreateIconWindow): Fix warnings. * fvwm/add_window.c (setup_style_and_decor): Fix warnings. * fvwm/events.c (_handle_cr_on_shaped): Fix warnings. * configure.ac: Add helper macro SUPPRESS_UNUSED_VAR_WARNING to fake using a variable and its value in certain hard to fix places. * fvwm/menus.c (size_menu_vertically): Fix write access to read-only location with gettext. libs: * fsm.c (SaveYourselfPhase2ReqProc, SaveYourselfDoneProc) (NewConnectionMsg): Fix warnings. * FGettext.c (FGettextInit): Fix warnings. * FImage.c (FGetFImage): Fix warnings. * Fft.c (FftGetFont): Fix warnings. * FRender.c (FRenderVisualInit, FRenderCreateShadePicture) (FRenderTintPicture, FRenderTintRectangle, FRenderRender): Fix warnings. * FScreen.c (FScreenInit): Fix warnings. * Ficonv.c (is_translit_supported, convert_charsets): Fix warnings.
Re: [fvwmorg/fvwm] 5b3250: Fix gettext write to read only string; fix warning...
On Sat, Oct 22, 2016 at 10:04:39PM +0100, Thomas Adam wrote: > On Sat, Oct 22, 2016 at 07:55:01PM +0100, Dominik Vogt wrote: > > Yes, but that does not fix the warning. "x" is unused because of > > the dummy replacement of the function call. The compiler does not > > see that if "x = 0" is ever executed, Fxyz_some_func always has a > > non-empty definition. > > > > I've always used > > > > if (FEATURE) > > { > > ... > > } > > > > Instead of > > > > #if FEATURE > > ... > > #endif > > > > so that the conditional code is always compiled, even if the > > feature is disabled (so we would catch compile errors earlier). > > But in this case, it introduces a warning. > > Yes -- which makes this impossible to fix unless the code is changed to be > #ifdef'd out, rather than using 'if (FEATURE)', which makes things harder to > read anyway. In that case I'd rather have a warning in a rare corner case than the code becoming un-compileable over time because nobody ever bothers to disable all optional configure features before building a release. Ifdefs are a maintenance nightmare. But of course it is fixable, we'd just have to replace the dummy macros with real functions that do nothing. A decent compiler will remove the dead code anyway. But I won't do that unless I really find no better way. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] 5b3250: Fix gettext write to read only string; fix warning...
On Sat, Oct 22, 2016 at 07:55:01PM +0100, Dominik Vogt wrote: > Yes, but that does not fix the warning. "x" is unused because of > the dummy replacement of the function call. The compiler does not > see that if "x = 0" is ever executed, Fxyz_some_func always has a > non-empty definition. > > I've always used > > if (FEATURE) > { > ... > } > > Instead of > > #if FEATURE > ... > #endif > > so that the conditional code is always compiled, even if the > feature is disabled (so we would catch compile errors earlier). > But in this case, it introduces a warning. Yes -- which makes this impossible to fix unless the code is changed to be #ifdef'd out, rather than using 'if (FEATURE)', which makes things harder to read anyway. -- Thomas Adam
Re: [fvwmorg/fvwm] 5b3250: Fix gettext write to read only string; fix warning...
On Sat, Oct 22, 2016 at 06:19:46PM +0100, Thomas Adam wrote: > On Sat, Oct 22, 2016 at 03:42:13PM +0100, Dominik Vogt wrote: > > Proof reading this patch would also be helpful. > > I've taken a look. It's fine. I can't say I like the void casts all over the > place -- what's wrong with giving a default value? It results in "set but not used" messages (gcc-4.7.2). This is in some functions where a feature is disabled with a macro: void foo(void) { int x; if (!FEATURE_XYZ) { return; } x = 0; Fxyz_some_func(); return; } Where #if FEATURE_XYZ #define Fxyz_some_function(a) Xyz_some_sunction(a) #else #define Fxyz_some_function(a) do { } while (0) #fi If FEATURE_XYZ is disabled, the preprocessed code is just ... x = 0; do { } while (0); ... And the least invasive way to prevent this is faking a read with the coid-cast. > However, since I'm using FreeBSD and hence clang, here's a further diff I'd > like you to include (to shut up clang): > > diff --git a/fvwm/icons.c b/fvwm/icons.c > index a3cb0cd..a6cc234 100644 > --- a/fvwm/icons.c > +++ b/fvwm/icons.c > @@ -754,7 +754,7 @@ void CreateIconWindow(FvwmWindow *fw, int def_x, int > def_y) > /* when fvwm is using the non-default visual client > * supplied icon pixmaps are drawn in a window with no > * relief */ > - int off ; > + int off = 0; > > (void)off; > if (Pdefault || fw->iconDepth == 1 || Ouch. So, the void casts are really bad because they actualy hide real bugs. This is not just a warning fix, the patch really breaks code that was fine before, except for the warning. There must be another way then... > Incidentally, you can always check to see what the different compilers are > doing (gcc/clang) by looking at the output from the travis-ci builds. In the > Clang case, your build looks are here: > > https://travis-ci.org/fvwmorg/fvwm/jobs/169749072 Hm, I just see a summary on top and below the heading "Job log" a "loading" icon that never finishes. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] 5b3250: Fix gettext write to read only string; fix warning...
On Sat, Oct 22, 2016 at 03:42:13PM +0100, Dominik Vogt wrote: > Proof reading this patch would also be helpful. I've taken a look. It's fine. I can't say I like the void casts all over the place -- what's wrong with giving a default value? However, since I'm using FreeBSD and hence clang, here's a further diff I'd like you to include (to shut up clang): diff --git a/fvwm/icons.c b/fvwm/icons.c index a3cb0cd..a6cc234 100644 --- a/fvwm/icons.c +++ b/fvwm/icons.c @@ -754,7 +754,7 @@ void CreateIconWindow(FvwmWindow *fw, int def_x, int def_y) /* when fvwm is using the non-default visual client * supplied icon pixmaps are drawn in a window with no * relief */ - int off ; + int off = 0; (void)off; if (Pdefault || fw->iconDepth == 1 || Incidentally, you can always check to see what the different compilers are doing (gcc/clang) by looking at the output from the travis-ci builds. In the Clang case, your build looks are here: https://travis-ci.org/fvwmorg/fvwm/jobs/169749072 Kindly, Thomas
Broken code spans in DEVELOPERS.md
With markdown-1.0.1 the code spans in DEVELOPERS.md come out all broken when converting the file to html, and I don't get how to do it right. Viewed with seamonkey they looks like this. -- git checkout topic/branch git rebase origin/master git checkout master git merge topic/branch git push -- without indentation and line breaks. -- ``` include "config.h" ``` -- The backticks have not been recognized, there's no indentation, an extra blank line and the font is HUGE. Seems to be misunderstood as a chapter heading. -- make CFLAGS="-g -O2 -Wall -Wpointer-arith -fno-strict-aliasing -Werror" -- without indentation. -- git clone g...@github.com:fvwmorg/fvwmorg.github.io.git -- without indentation. For me, this ``` construct doesn't do anything useful. Markdown documentation says a preformatted code block ist started by adding an additional level of indentation. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] 5b3250: Fix gettext write to read only string; fix warning...
Proof reading this patch would also be helpful. On Sat, Oct 22, 2016 at 07:36:12AM -0700, GitHub wrote: > Branch: refs/heads/dv-gcc-warning-fixes > Home: https://github.com/fvwmorg/fvwm > Commit: 5b325057dc569621230a2326d1640dcb07cacdb1 > > https://github.com/fvwmorg/fvwm/commit/5b325057dc569621230a2326d1640dcb07cacdb1 > Author: Dominik Vogt> Date: 2016-10-22 (Sat, 22 Oct 2016) > > Changed paths: > M fvwm/add_window.c > M fvwm/events.c > M fvwm/frame.c > M fvwm/icons.c > M fvwm/menus.c > M fvwm/session.c > M libs/FGettext.c > M libs/FImage.c > M libs/FRender.c > M libs/FScreen.c > M libs/Fft.c > M libs/Ficonv.c > M libs/fsm.c > M modules/FvwmConsole/getline.c > > Log Message: > --- > Fix gettext write to read only string; fix warnings. > > * modules/FvwmConsole/getline.c (get_line): Fix warnings. > * fvwm/session.c (set_sm_properties, SessionInit): Fix warnings. > * fvwm/frame.c (frame_prepare_animation_shape) > (frame_setup_shape): Fix warnings. > * fvwm/icons.c (CreateIconWindow): Fix warnings. > * fvwm/add_window.c (setup_style_and_decor): Fix warnings. > * fvwm/events.c (_handle_cr_on_shaped): Fix warnings. > * fvwm/menus.c (size_menu_vertically): Fix write access to read-only > location with gettext. > > libs: > * fsm.c (SaveYourselfPhase2ReqProc, SaveYourselfDoneProc) > (NewConnectionMsg): Fix warnings. > * FGettext.c (FGettextInit): Fix warnings. > * FImage.c (FGetFImage): Fix warnings. > * Fft.c (FftGetFont): Fix warnings. > * Ficonv.c (is_translit_supported, convert_charsets): Fix warnings. > * FRender.c (FRenderCreateShadePicture, FRenderVisualInit) > (FRenderTintRectangle, FRenderTintPicture, FRenderRender): Fix > warnings. > * FScreen.c (FScreenInit): Fix warnings. > > > > Ciao Dominik ^_^ ^_^ -- Dominik Vogt
[fvwmorg/fvwm] 5b3250: Fix gettext write to read only string; fix warning...
Branch: refs/heads/dv-gcc-warning-fixes Home: https://github.com/fvwmorg/fvwm Commit: 5b325057dc569621230a2326d1640dcb07cacdb1 https://github.com/fvwmorg/fvwm/commit/5b325057dc569621230a2326d1640dcb07cacdb1 Author: Dominik VogtDate: 2016-10-22 (Sat, 22 Oct 2016) Changed paths: M fvwm/add_window.c M fvwm/events.c M fvwm/frame.c M fvwm/icons.c M fvwm/menus.c M fvwm/session.c M libs/FGettext.c M libs/FImage.c M libs/FRender.c M libs/FScreen.c M libs/Fft.c M libs/Ficonv.c M libs/fsm.c M modules/FvwmConsole/getline.c Log Message: --- Fix gettext write to read only string; fix warnings. * modules/FvwmConsole/getline.c (get_line): Fix warnings. * fvwm/session.c (set_sm_properties, SessionInit): Fix warnings. * fvwm/frame.c (frame_prepare_animation_shape) (frame_setup_shape): Fix warnings. * fvwm/icons.c (CreateIconWindow): Fix warnings. * fvwm/add_window.c (setup_style_and_decor): Fix warnings. * fvwm/events.c (_handle_cr_on_shaped): Fix warnings. * fvwm/menus.c (size_menu_vertically): Fix write access to read-only location with gettext. libs: * fsm.c (SaveYourselfPhase2ReqProc, SaveYourselfDoneProc) (NewConnectionMsg): Fix warnings. * FGettext.c (FGettextInit): Fix warnings. * FImage.c (FGetFImage): Fix warnings. * Fft.c (FftGetFont): Fix warnings. * Ficonv.c (is_translit_supported, convert_charsets): Fix warnings. * FRender.c (FRenderCreateShadePicture, FRenderVisualInit) (FRenderTintRectangle, FRenderTintPicture, FRenderRender): Fix warnings. * FScreen.c (FScreenInit): Fix warnings.
Re: Make output
On Sat, Oct 22, 2016 at 02:42:06PM +0100, Dominik Vogt wrote: > What has happened to the make output, and how do I get it back. Either: ./configure --disable-silent-rules or: make V=1 -- Thomas Adam
Re: Final long term stable version
On Sat, Oct 22, 2016 at 02:25:53PM +0100, Dominik Vogt wrote: > On Sat, Oct 22, 2016 at 01:19:57PM +0100, Thomas Adam wrote: > > On Mon, Oct 17, 2016 at 11:20:25PM +0100, Dominik Vogt wrote: > > > * From version X+1 onwards, no guarantees are made about > > >continued support of obscure features, until there's an > > >official fvwm-3.0. > > > > I am looking at releasing 2.6.7 this weekend. AFAIAC, this release will be > > the last stable/supported version. Up to this point I've installed all > > optional libraries and fixed all the warnings for the versions I have > > available (FreeBSD) -- so that's something. I think it's in a good state to > > be left behind, and allowing it to receive minor fixes, etc. > > I'm fixing the warnings I discovered through building with all > configurable features switched off. The result should probably > make it into 2.6.7. Cool -- I'll wait until that happens then. Thanks. -- Thomas Adam
Re: Final long term stable version
On Sat, Oct 22, 2016 at 01:19:57PM +0100, Thomas Adam wrote: > On Mon, Oct 17, 2016 at 11:20:25PM +0100, Dominik Vogt wrote: > > * From version X+1 onwards, no guarantees are made about > >continued support of obscure features, until there's an > >official fvwm-3.0. > > I am looking at releasing 2.6.7 this weekend. AFAIAC, this release will be > the last stable/supported version. Up to this point I've installed all > optional libraries and fixed all the warnings for the versions I have > available (FreeBSD) -- so that's something. I think it's in a good state to > be left behind, and allowing it to receive minor fixes, etc. I'm fixing the warnings I discovered through building with all configurable features switched off. The result should probably make it into 2.6.7. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Final long term stable version
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. I've given this a lot of thought, and certainly with the changes I am looking to make, it's a lot of work to do that without radically changing things for existing users. To be clear, I mean such changes are compounded by trying to be backwards compatible. Having a clean break means it allows us to architect things differently; to really think about things, and to not let so many of the feature we have now, grow organically, obtrusively, and more importantly, without discussion. This was something I struggled with when looking at mvwm---ripping out all of the things which were getting in the way of having something cleaner to allow changes was impossible given how everything inter-relates. On the back of the current TODO.md file, I'll draft a list of key-features as I see them and send it out for review/discussion here. > * From version X+1 onwards, no guarantees are made about >continued support of obscure features, until there's an >official fvwm-3.0. I am looking at releasing 2.6.7 this weekend. AFAIAC, this release will be the last stable/supported version. Up to this point I've installed all optional libraries and fixed all the warnings for the versions I have available (FreeBSD) -- so that's something. I think it's in a good state to be left behind, and allowing it to receive minor fixes, etc. Questions? Do please ask. Kindly, Thomas
[fvwmorg/fvwm] 6afa5b: PNG support: complain if --disable-png missing
Branch: refs/heads/master Home: https://github.com/fvwmorg/fvwm Commit: 6afa5b34640eba525e3586f0735c0ddab78487d7 https://github.com/fvwmorg/fvwm/commit/6afa5b34640eba525e3586f0735c0ddab78487d7 Author: Thomas AdamDate: 2016-10-22 (Sat, 22 Oct 2016) Changed paths: M configure.ac Log Message: --- PNG support: complain if --disable-png missing PNG support is required for the default configuration so that icons are displayed. It's also required from third-party meny generators to provide icons in generated menus. * If libpng is found at compile time, use it. * If libpng is NOT found, and --disable-png is NOT given, complain with good reason.
[fvwmorg/fvwm] 6afa5b: PNG support: complain if --disable-png missing
Branch: refs/heads/ta/revamp-png-support Home: https://github.com/fvwmorg/fvwm Commit: 6afa5b34640eba525e3586f0735c0ddab78487d7 https://github.com/fvwmorg/fvwm/commit/6afa5b34640eba525e3586f0735c0ddab78487d7 Author: Thomas AdamDate: 2016-10-22 (Sat, 22 Oct 2016) Changed paths: M configure.ac Log Message: --- PNG support: complain if --disable-png missing PNG support is required for the default configuration so that icons are displayed. It's also required from third-party meny generators to provide icons in generated menus. * If libpng is found at compile time, use it. * If libpng is NOT found, and --disable-png is NOT given, complain with good reason.