Re: regression from 2.6.5 to 2.6.6 ?

2016-10-22 Thread zlists 
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

2016-10-22 Thread Thomas Adam 
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

2016-10-22 Thread Dominik Vogt 
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

2016-10-22 Thread GitHub 
  Branch: refs/heads/master
  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

Re: [fvwmorg/fvwm] 58d1a6: NEWS: formatting tweaks

2016-10-22 Thread Dominik Vogt 
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

2016-10-22 Thread Dominik Vogt 
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 ?

2016-10-22 Thread Dominik Vogt 
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

2016-10-22 Thread GitHub 
  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

[fvwmorg/fvwm] abed4e: NEWS: changes since 2.6.6

2016-10-22 Thread GitHub 
  Branch: refs/heads/master
  Home:   https://github.com/fvwmorg/fvwm
  Commit: abed4eae18d0852f3a1b5a943221bb2147328417
  
https://github.com/fvwmorg/fvwm/commit/abed4eae18d0852f3a1b5a943221bb2147328417
  Author: Thomas Adam 
  Date:   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

2016-10-22 Thread GitHub 
  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

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

2016-10-22 Thread GitHub 
  Branch: refs/heads/ta/reluctant-news
  Home:   https://github.com/fvwmorg/fvwm
  Commit: abed4eae18d0852f3a1b5a943221bb2147328417
  
https://github.com/fvwmorg/fvwm/commit/abed4eae18d0852f3a1b5a943221bb2147328417
  Author: Thomas Adam 
  Date:   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

2016-10-22 Thread Dominik Vogt 
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 ?

2016-10-22 Thread Dominik Vogt 
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 ?]

2016-10-22 Thread Dominik Vogt 
- Forwarded message from zli...@ns.sympatico.ca -

Date: Sat, 22 Oct 2016 22:00:16 -0300
From: zli...@ns.sympatico.ca
To: Dominik Vogt 
Subject: 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

2016-10-22 Thread GitHub 
  Branch: refs/heads/master
  Home:   https://github.com/fvwmorg/fvwm
  Commit: f160e7806648e7a1cc5b7f42eba393ed30913d4a
  
https://github.com/fvwmorg/fvwm/commit/f160e7806648e7a1cc5b7f42eba393ed30913d4a
  Author: Thomas Adam 
  Date:   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

2016-10-22 Thread GitHub 
  Branch: refs/heads/ta/reluctant-news
  Home:   https://github.com/fvwmorg/fvwm
  Commit: f160e7806648e7a1cc5b7f42eba393ed30913d4a
  
https://github.com/fvwmorg/fvwm/commit/f160e7806648e7a1cc5b7f42eba393ed30913d4a
  Author: Thomas Adam 
  Date:   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

2016-10-22 Thread Thomas Adam 
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

2016-10-22 Thread Dominik Vogt 
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

2016-10-22 Thread Thomas Adam 
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...

2016-10-22 Thread GitHub 
  Branch: refs/heads/ta/next
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 3e33ca238ecf4a42dbf45238a0575db2b2399326
  
https://github.com/fvwmorg/fvwm/commit/3e33ca238ecf4a42dbf45238a0575db2b2399326
  Author: Thomas Adam 
  Date:   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

2016-10-22 Thread Thomas Adam 
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

2016-10-22 Thread Dominik Vogt 
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 ?

2016-10-22 Thread Dominik Vogt 
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 ?

2016-10-22 Thread zlists 
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?

2016-10-22 Thread Thomas Adam 
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 ?

2016-10-22 Thread Thomas Adam 
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 ?

2016-10-22 Thread zlists 
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?

2016-10-22 Thread Dominik Vogt 
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 ?

2016-10-22 Thread Thomas Adam 
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 ?

2016-10-22 Thread zlists 
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?

2016-10-22 Thread Thomas Adam 
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?

2016-10-22 Thread Dominik Vogt 
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.

2016-10-22 Thread Thomas Adam 
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.

2016-10-22 Thread Dominik Vogt 
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.

2016-10-22 Thread GitHub 
  Branch: refs/heads/master
  Home:   https://github.com/fvwmorg/fvwm
  Commit: c0ae18064466425f3864bd1e3baf03815cae4a44
  
https://github.com/fvwmorg/fvwm/commit/c0ae18064466425f3864bd1e3baf03815cae4a44
  Author: Dominik Vogt 
  Date:   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.

2016-10-22 Thread Thomas Adam 
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.

2016-10-22 Thread Dominik Vogt 
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.

2016-10-22 Thread GitHub 
  Branch: refs/heads/dv-gcc-warning-fixes
  Home:   https://github.com/fvwmorg/fvwm
  Commit: c0ae18064466425f3864bd1e3baf03815cae4a44
  
https://github.com/fvwmorg/fvwm/commit/c0ae18064466425f3864bd1e3baf03815cae4a44
  Author: Dominik Vogt 
  Date:   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: FVWM: [dominik.v...@gmx.de: Removing libstroke support?]

2016-10-22 Thread David Niklas 
On Mon, 17 Oct 2016 23:01:00 tho...@fvwm.org wrote:
> On Mon, Oct 17, 2016 at 10:57:58PM +0100, Dominik Vogt wrote:
> > On Mon, 17 Oct 2016 22:55:56  wrote:
> > 
> > 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.
Same here.

Re: FVWM: pull requests

2016-10-22 Thread Thomas Adam 
On Sun, Oct 23, 2016 at 07:21:55AM +1000, Stuart Longland wrote:
> On Git flow projects, master branch is always the latest stable release.

I'm aware of git-flow, and it sucks.  A solution to a problem which for most
project won't exist.

If you were to do:

% git checkout master && git pull

Then you'd be running something that was stable, plus code in development for
the next release.  That's fine.  The only criteria for code making it onto
master is that it has gone through some testing.

If you want to use the latest stable version, you'd checkout that tag:

% git checkout -b 2.6.6 something/2.6.6

Beyond that, there's not much more to say about how branching and tagging
works.

-- Thomas Adam

Re: [fvwmorg/fvwm] 5b3250: Fix gettext write to read only string; fix warning...

2016-10-22 Thread Dominik Vogt 
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...

2016-10-22 Thread Thomas Adam 
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: FVWM: pull requests

2016-10-22 Thread Thomas Adam 
On Sun, Oct 23, 2016 at 06:52:46AM +1000, Stuart Longland wrote:
> On 23/10/16 02:54, Thomas Adam wrote:
> > On Sat, Oct 22, 2016 at 05:11:46PM +0100, Dominik Vogt wrote:
> >> > Yes, but that's actually not the part I was asking about.  How the
> >> > "git pull-request" should look like is not in the docs.
> > OK.  For that, you'd have to use their web interface.  See:
> > 
> > https://help.github.com/articles/about-pull-requests/
> 
> `git merge --no-ff ${BRANCH}` seems to be more-or-less equivalent.

No, it's the opposite.

Again, DEVELOPERS.md outlines why, and how to do this.  If it's not clear,
then I need to know so it can be improved.

> Is there going to be some sort of naming and usage convention around
> branches, e.g. like Git flow¹?  Or is 'master' where the action happens?

Did you read DEVELOPERS.md?  Don't misunderstand me, it's in that document,
and if it's not clear, I again need to know so I can improve it.  But what I
don't want to do is have to keep repeating the same bits of information when I
can point people towards that file.

-- Thomas Adam

Re: FVWM: pull requests

2016-10-22 Thread Stuart Longland 
On 23/10/16 02:54, Thomas Adam wrote:
> On Sat, Oct 22, 2016 at 05:11:46PM +0100, Dominik Vogt wrote:
>> > Yes, but that's actually not the part I was asking about.  How the
>> > "git pull-request" should look like is not in the docs.
> OK.  For that, you'd have to use their web interface.  See:
> 
> https://help.github.com/articles/about-pull-requests/

`git merge --no-ff ${BRANCH}` seems to be more-or-less equivalent.

Is there going to be some sort of naming and usage convention around
branches, e.g. like Git flow¹?  Or is 'master' where the action happens?
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

1. http://nvie.com/posts/a-successful-git-branching-model/

Re: FVWM: problems with png support

2016-10-22 Thread Thomas Adam 
On Fri, Oct 21, 2016 at 10:12:01AM +0200, Volker wrote:
> I updated (from cvs) to the latest version in git, but
> unfortunately lost png support under the transition.

This should be fixed now on master; please check.

-- Thomas Adam

Re: [fvwmorg/fvwm] 5b3250: Fix gettext write to read only string; fix warning...

2016-10-22 Thread Dominik Vogt 
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...

2016-10-22 Thread Thomas Adam 
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

2016-10-22 Thread Dominik Vogt 
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: FVWM: pull requests

2016-10-22 Thread Thomas Adam 
On Sat, Oct 22, 2016 at 05:11:46PM +0100, Dominik Vogt wrote:
> Yes, but that's actually not the part I was asking about.  How the
> "git pull-request" should look like is not in the docs.

OK.  For that, you'd have to use their web interface.  See:

https://help.github.com/articles/about-pull-requests/

Or there's a command-line wrapper:

https://hub.github.com/

Or, I've mentioned in the docs about using 'git send-email'.

The reason it's not in the docs is because it's generally not a question that
gets asked, and that I'd rather try and keep what we have to document as
fvwm-specific as possible, due to the way GH changes, etc.

I'll review your diff right now.

-- Thomas Adam

Re: FVWM: pull requests

2016-10-22 Thread Thomas Adam 
Hi,

Ensure master is up to date in your checkout, then on you topic branch:

git rebase master

If there were changes on master which weren't on your branch you'll have to
force push your topic branch out again to build in Travis. Then:

git checkout master
git merge topic-branch
git push

It's all in DEVELOPERS.md

HTH,
Thomas
On Sat, 22 Oct 2016, 15:42 Dominik Vogt,  wrote:

> Hi Thomas,
>
> I've actually never used pull requests, so what would be the
> correct command to generate a pull request for the
> dv-gcc-warning-fixes branch I've just pushed, to get it onto the
> master branch?  (Preferrably not using github.)
>
> Ciao
>
> Dominik ^_^  ^_^
>
> --
>
> Dominik Vogt
>

Re: [fvwmorg/fvwm] 5b3250: Fix gettext write to read only string; fix warning...

2016-10-22 Thread Dominik Vogt 
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...

2016-10-22 Thread GitHub 
  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.

Re: Make output

2016-10-22 Thread Thomas Adam 
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

2016-10-22 Thread Thomas Adam 
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

2016-10-22 Thread Dominik Vogt 
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

2016-10-22 Thread 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.

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

2016-10-22 Thread GitHub 
  Branch: refs/heads/master
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 6afa5b34640eba525e3586f0735c0ddab78487d7
  
https://github.com/fvwmorg/fvwm/commit/6afa5b34640eba525e3586f0735c0ddab78487d7
  Author: Thomas Adam 
  Date:   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

2016-10-22 Thread GitHub 
  Branch: refs/heads/ta/revamp-png-support
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 6afa5b34640eba525e3586f0735c0ddab78487d7
  
https://github.com/fvwmorg/fvwm/commit/6afa5b34640eba525e3586f0735c0ddab78487d7
  Author: Thomas Adam 
  Date:   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.