Re: updating the html docs in fvwm-web?
On Mon, 7 Jan 2008, Dan Espen wrote: Viktor Griph <[EMAIL PROTECTED]> writes: On Mon, 7 Jan 2008, Dan Espen wrote: Dominik Vogt <[EMAIL PROTECTED]> writes: Hi Scott, On Sat, Sep 01, 2007 at 12:38:34PM +0200, Dominik Vogt wrote: Now that we have the html docs, someone has to write down detailed instructions in docs/DEVELOPER how to get the html files into fvwm-web during the release process. I can't do that. I *really* need instruction in the docs/DEVELOPER file if we want the man pages on the web page to be up to date. I don't have the slightest idea what I have to do. Help! There does seem to be an issue. I was able to build with --enable-htmldoc. That gave me some pretty nice man pages in fvwm/share/2.5.25/doc/fvwm/fvwm. Then I looked in fvwm-web and was surprised to see the manpages2php script was still in there. Then I looked at the Fvwm web site and I see we still have the old web pages online at fvwm.org. I think it's time to put the new pages in place. I'll take care of this if you want. I think we need to change the manpages2php script so it doesn't do anything for the "unstable" branch. There are currently two places with online manpages. And the manpages2html does still work on the generated manpage. (But all links are lost.) Document the new procedure which should just be: build with --enable-htmldoc then copy the whole hierarchy created in /share over to fvwm-web/documentation/manpages/unstable. Then update/commit. In theory that is good. But right now the documentation seems to be missing some files in the installed directory. (Which is a bug.) And it also adds the need to actually install the source once except from within the distcheck in order to update the documentation. Files currently not properly installed are: modules/FvwmTabs.html commands/WindowsDesk.html modules/images/FvwmTabs/*.png So, are you recommending we just continue with generating the php files from the generated man pages until the problem is fixed? Are the FvwmTabs etc. man pages still OK? I recommend that we keep generating the manpages using man2php until we have removed that section of the homepage, or made the new gtenerated manpage appear in there. (Preferrable using the homepage theme.) As long as outdated manpages are deleted from the tree the manpages2php script will find the man pages generated from docbook when updating. I've fixed the installation issues and added a script to update the html documentation without having to install the documentation. /Viktor
CVS griph fvwm-web: * update HTML documentation
CVSROOT:/home/cvs/fvwm Module name:fvwm-web Changes by: griph 08/01/07 18:02:10 Modified files: . : ChangeLog doc/unstable : allCommands.html groupedCommands.html modules.html style.css doc/unstable/commands: AddButtonStyle.html AddTitleStyle.html AddToDecor.html AddToFunc.html AddToMenu.html All.html AnimatedMove.html Any.html Asterisk.html Beep.html BorderStyle.html Break.html BugOpts.html BusyCursor.html ButtonState.html ButtonStyle.html ChangeDecor.html ChangeMenuStyle.html CleanupColorsets.html ClickTime.html Close.html ColorLimit.html ColormapFocus.html Colorset.html CopyMenuStyle.html Current.html CursorMove.html CursorStyle.html DefaultColors.html DefaultColorset.html DefaultFont.html DefaultIcon.html DefaultLayers.html Delete.html Deschedule.html Desk.html DesktopName.html DesktopSize.html Destroy.html DestroyDecor.html DestroyFunc.html DestroyMenu.html DestroyMenuStyle.html DestroyModuleConfig.html DestroyStyle.html DestroyWindowStyle.html Direction.html Echo.html EchoFuncDefinition.html EdgeCommand.html EdgeLeaveCommand.html EdgeResistance.html EdgeScroll.html EdgeThickness.html Emulate.html EscapeFunc.html EwmhBaseStruts.html EwmhNumberOfDesktops.html Exec.html ExecUseShell.html FakeClick.html FakeKeypress.html FlipFocus.html Focus.html FocusStyle.html Function.html GlobalOpts.html GnomeButton.html GnomeShowDesks.html GotoDesk.html GotoDeskAndPage.html GotoPage.html HideGeometryWindow.html HilightColor.html HilightColorset.html IconFont.html IconPath.html Iconify.html IgnoreModifiers.html ImagePath.html KeepRc.html Key.html KillModule.html Layer.html LocalePath.html Lower.html Maximize.html Menu.html MenuStyle.html Module.html ModuleListenOnly.html ModulePath.html ModuleSynchronous.html ModuleTimeout.html Mouse.html Move.html MoveThreshold.html MoveToDesk.html MoveToPage.html MoveToScreen.html Next.html NoWindow.html None.html Nop.html OpaqueMoveSize.html Pick.html PipeRead.html PixmapPath.html PlaceAgain.html Plus.html PointerKey.html PointerWindow.html Popup.html Prev.html PrintInfo.html Quit.html QuitScreen.html QuitSession.html Raise.html RaiseLower.html Read.html Recapture.html RecaptureWindow.html Refresh.html RefreshWindow.html Repeat.html Resize.html ResizeMaximize.html ResizeMove.html ResizeMoveMaximize.html RestackTransients.html Restart.html SaveQuitSession.html SaveSession.html ScanForWindow.html Schedule.html Scroll.html SendToModule.html SetAnimation.html SetEnv.html Silent.html SnapAttraction.html SnapGrid.html State.html Stick.html StickAcrossDesks.html StickAcrossPages.html Stroke.html StrokeFunc.html Style.html TearMenuOff.html Test.html TestRc.html ThisWindow.html
CVS griph: install missing html documentation files
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 08/01/07 16:54:53 Modified files: . : ChangeLog NEWS doc: ChangeLog doc/commands : Makefile.am doc/modules: Makefile.am doc/modules/images/FvwmTabs: Makefile.am Log message: install missing html documentation files
Re: updating the html docs in fvwm-web?
Viktor Griph <[EMAIL PROTECTED]> writes: > On Mon, 7 Jan 2008, Dan Espen wrote: > > > Dominik Vogt <[EMAIL PROTECTED]> writes: > >> Hi Scott, > >> > >> On Sat, Sep 01, 2007 at 12:38:34PM +0200, Dominik Vogt wrote: > >>> Now that we have the html docs, someone has to write down detailed > >>> instructions in docs/DEVELOPER how to get the html files into > >>> fvwm-web during the release process. I can't do that. > >> > >> I *really* need instruction in the docs/DEVELOPER file if we want > >> the man pages on the web page to be up to date. I don't have the > >> slightest idea what I have to do. Help! > > > > There does seem to be an issue. > > I was able to build with --enable-htmldoc. > > > > That gave me some pretty nice man pages in > > fvwm/share/2.5.25/doc/fvwm/fvwm. > > > > Then I looked in fvwm-web and was surprised to see > > the manpages2php script was still in there. > > Then I looked at the Fvwm web site and I see we still have > > the old web pages online at fvwm.org. > > > > I think it's time to put the new pages in place. > > > > I'll take care of this if you want. > > I think we need to change the manpages2php script so it doesn't > > do anything for the "unstable" branch. > > There are currently two places with online manpages. And the manpages2html > does still work on the generated manpage. (But all links are lost.) > > > > > Document the new procedure which should just be: > > > > build with --enable-htmldoc > > then copy the whole hierarchy created in /share over to > > fvwm-web/documentation/manpages/unstable. > > > > Then update/commit. > > In theory that is good. But right now the documentation seems to be > missing some files in the installed directory. (Which is a bug.) And it > also adds the need to actually install the source once except from within > the distcheck in order to update the documentation. > > Files currently not properly installed are: > modules/FvwmTabs.html > commands/WindowsDesk.html > modules/images/FvwmTabs/*.png So, are you recommending we just continue with generating the php files from the generated man pages until the problem is fixed? Are the FvwmTabs etc. man pages still OK? -- Dan Espen E-mail: [EMAIL PROTECTED]
Re: updating the html docs in fvwm-web?
Hi Dominik, > I *really* need instruction in the docs/DEVELOPER file if we want > the man pages on the web page to be up to date. I don't have the > slightest idea what I have to do. Help! H, I did start writing some ... not sure if I finished it. Here's what I had - I'll check/commit it soon (bit busy right at this instant). How to upload HTML documentation to www.fvwm.org export web=$HOME/fvwm/fvwm-web/doc/unstable cd $HOME/fvwm/cvs.1/fvwm/doc for f in $(find . -name '*.html' -o -name '*.png' -o -name '*.jpg') ; do dest=$web/$f if [ ! -f $dest ] ; then echo "$dest does not exist in fvwm-web" continue fi diff -q $f $dest > /dev/null if (( $? != 0 )) ; then cp -p --parents $f $web fi done I'll comment it too! :) Scott. :)
Re: updating the html docs in fvwm-web?
On Mon, 7 Jan 2008, Dan Espen wrote: Dominik Vogt <[EMAIL PROTECTED]> writes: Hi Scott, On Sat, Sep 01, 2007 at 12:38:34PM +0200, Dominik Vogt wrote: Now that we have the html docs, someone has to write down detailed instructions in docs/DEVELOPER how to get the html files into fvwm-web during the release process. I can't do that. I *really* need instruction in the docs/DEVELOPER file if we want the man pages on the web page to be up to date. I don't have the slightest idea what I have to do. Help! There does seem to be an issue. I was able to build with --enable-htmldoc. That gave me some pretty nice man pages in fvwm/share/2.5.25/doc/fvwm/fvwm. Then I looked in fvwm-web and was surprised to see the manpages2php script was still in there. Then I looked at the Fvwm web site and I see we still have the old web pages online at fvwm.org. I think it's time to put the new pages in place. I'll take care of this if you want. I think we need to change the manpages2php script so it doesn't do anything for the "unstable" branch. There are currently two places with online manpages. And the manpages2html does still work on the generated manpage. (But all links are lost.) Document the new procedure which should just be: build with --enable-htmldoc then copy the whole hierarchy created in /share over to fvwm-web/documentation/manpages/unstable. Then update/commit. In theory that is good. But right now the documentation seems to be missing some files in the installed directory. (Which is a bug.) And it also adds the need to actually install the source once except from within the distcheck in order to update the documentation. Files currently not properly installed are: modules/FvwmTabs.html commands/WindowsDesk.html modules/images/FvwmTabs/*.png /Viktor
Re: updating the html docs in fvwm-web?
Dominik Vogt <[EMAIL PROTECTED]> writes: > Hi Scott, > > On Sat, Sep 01, 2007 at 12:38:34PM +0200, Dominik Vogt wrote: > > Now that we have the html docs, someone has to write down detailed > > instructions in docs/DEVELOPER how to get the html files into > > fvwm-web during the release process. I can't do that. > > I *really* need instruction in the docs/DEVELOPER file if we want > the man pages on the web page to be up to date. I don't have the > slightest idea what I have to do. Help! There does seem to be an issue. I was able to build with --enable-htmldoc. That gave me some pretty nice man pages in fvwm/share/2.5.25/doc/fvwm/fvwm. Then I looked in fvwm-web and was surprised to see the manpages2php script was still in there. Then I looked at the Fvwm web site and I see we still have the old web pages online at fvwm.org. I think it's time to put the new pages in place. I'll take care of this if you want. I think we need to change the manpages2php script so it doesn't do anything for the "unstable" branch. Document the new procedure which should just be: build with --enable-htmldoc then copy the whole hierarchy created in /share over to fvwm-web/documentation/manpages/unstable. Then update/commit. -- Dan Espen E-mail: [EMAIL PROTECTED]
Re: FLCXOMCharset again
On Mon, 7 Jan 2008 21:13:16 +0100 Dominik Vogt <[EMAIL PROTECTED]> wrote: > On Sat, Jul 28, 2007 at 01:12:08PM +0200, Jesús Guerrero wrote: > > On Sat, 28 Jul 2007 11:36:09 +0200 > > Dominik Vogt <[EMAIL PROTECTED]> wrote: > > > See below. > > > > > > > --- libs/FlocaleCharset.c 2006-12-09 19:43:39.0 +0100 > > > > +++ libs/FlocaleCharset.c 2006-12-09 19:46:38.0 +0100 > > > > @@ -522,7 +522,7 @@ > > > > } > > > > > > > > if (FLCXOMCharsetList_num > 0 && FLCXOMCharsetList[0]) > > > > - FLCXOMCharset = FLCXOMCharsetList[0]; > > > > + FLCXOMCharset = FLCXOMCharsetList[FLCXOMCharsetList_num > > > > - 1]; > > > > #endif > > > > } > > > > > > What is special about the last entry in the charset list? Or are > > > we just picking some random entry and hope that it works? > > > > Well, this is the output of "PrintInfo Locale 1" on my system: > > > > *** > > FVWM info on locale: > > locale: es_ES.utf8, Modifier: > > Default Charset: X: ISO10646-1, Iconv: UTF-8, Bidi: No > > XOM Charsets: ISO8859-1 ISO8859-1 JISX0208.1983-0 KSC5601.1987-0 > > GB2312.1980-0 JISX0201.1976-0 ISO10646-1 > > Number of loaded font: 4 > > * Font number 0 > > fvwm info: > > Name: Shadow=0 0:xft:DejaVu Sans:style=Bold:size=7 > > Cache count: 9 > > Type: XftFont > > Charset: X: ISO10646-1, Iconv: UTF-8, Bidi: No > > height: 13, ascent: 11, descent: 3 > > shadow size: 0, shadow offset: 0, shadow direction:0 > > * Font number 1 > > fvwm info: > > Name: Shadow=0 0:xft:DejaVu Sans:size=7:styName: Shadow=0 > > 0:xft:DejaVu Sans:size=7:style=Bold > > Cache count: 1 > > Type: XftFont > > Charset: X: ISO10646-1, Iconv: UTF-8, Bidi: No > > height: 13, ascent: 11, descent: 3 > > shadow size: 0, shadow offset: 0, shadow direction:0 > > * Font number 2 > > fvwm info: > > Name: Shadow=0 0:xft:DejaVu Sans:style=Condensed:size=7.2 > > Cache count: 1 > > Type: XftFont > > Charset: X: ISO10646-1, Iconv: UTF-8, Bidi: No > > height: 13, ascent: 11, descent: 3 > > shadow size: 0, shadow offset: 0, shadow direction:0 > > * Font number 3 > > fvwm info: > > Name: 0 > > Cache count: 1 > > Type: XftFont > > Charset: X: ISO10646-1, Iconv: UTF-8, Bidi: No > > height: 13, ascent: 11, descent: 3 > > shadow size: 0, shadow offset: 0, shadow direction:0 > > *** > > > > I don't know how the XOM charsets are usually ordered. In case that someone > > known, drop me a note. I will research about it, and try to find an > > all-cases > > solution. But, it is crystal-clear to me that the actual state of the things > > is not the correct one either. It is not less random than the choice that > > the > > patch makes, it just takes the other extreme of the array, but, as shown in > > the links I posted, and my own case, this is not correct, at least, not for > > utf8 systems. > > > > For now, I just have the empiric note that it works on all systems I tried, > > better than [0], but I did not try non-alphabetic languages, nor Arabic... > > so, that belief of mine might be completely false. > > > > If someone has some info about the issue that could be helpful, let > > me know. I will research about the patch, and try to explain how it works > > so we can discard it. If that happens, I will try to design a better patch > > that can handle all the locales properly. > > I'd really want to have this problem fixed. If all else fails, > it would be allright to just add an option that tells fvwm which > entry to use: > > +n = n'th entry > -n = n'th entry counted from the end of the array > 0 = default = either first or last entry > > Ciao > > Dominik ^_^ ^_^ > > -- > Dominik Vogt I supposed that could be a good thing. At least, it could give the user a chance to make it work. I mean, I've had a need to patch fvwm since I started to use non standard characters on my fvwm. No other way around it. I lack both, the knowledge about xlib/fvwm and the time to research on this. If no one can do it, then that could be a good solution in the meantime. I suppose. -- Jesús Guerrero <[EMAIL PROTECTED]>
Re: updating the html docs in fvwm-web?
Hi Scott, On Sat, Sep 01, 2007 at 12:38:34PM +0200, Dominik Vogt wrote: > Now that we have the html docs, someone has to write down detailed > instructions in docs/DEVELOPER how to get the html files into > fvwm-web during the release process. I can't do that. I *really* need instruction in the docs/DEVELOPER file if we want the man pages on the web page to be up to date. I don't have the slightest idea what I have to do. Help! Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FLCXOMCharset again
On Sat, Jul 28, 2007 at 01:12:08PM +0200, Jesús Guerrero wrote: > On Sat, 28 Jul 2007 11:36:09 +0200 > Dominik Vogt <[EMAIL PROTECTED]> wrote: > > See below. > > > > > --- libs/FlocaleCharset.c 2006-12-09 19:43:39.0 +0100 > > > +++ libs/FlocaleCharset.c 2006-12-09 19:46:38.0 +0100 > > > @@ -522,7 +522,7 @@ > > > } > > > > > > if (FLCXOMCharsetList_num > 0 && FLCXOMCharsetList[0]) > > > - FLCXOMCharset = FLCXOMCharsetList[0]; > > > + FLCXOMCharset = FLCXOMCharsetList[FLCXOMCharsetList_num - 1]; > > > #endif > > > } > > > > What is special about the last entry in the charset list? Or are > > we just picking some random entry and hope that it works? > > Well, this is the output of "PrintInfo Locale 1" on my system: > > *** > FVWM info on locale: > locale: es_ES.utf8, Modifier: > Default Charset: X: ISO10646-1, Iconv: UTF-8, Bidi: No > XOM Charsets: ISO8859-1 ISO8859-1 JISX0208.1983-0 KSC5601.1987-0 > GB2312.1980-0 JISX0201.1976-0 ISO10646-1 > Number of loaded font: 4 > * Font number 0 > fvwm info: > Name: Shadow=0 0:xft:DejaVu Sans:style=Bold:size=7 > Cache count: 9 > Type: XftFont > Charset: X: ISO10646-1, Iconv: UTF-8, Bidi: No > height: 13, ascent: 11, descent: 3 > shadow size: 0, shadow offset: 0, shadow direction:0 > * Font number 1 > fvwm info: > Name: Shadow=0 0:xft:DejaVu Sans:size=7:styName: Shadow=0 0:xft:DejaVu > Sans:size=7:style=Bold > Cache count: 1 > Type: XftFont > Charset: X: ISO10646-1, Iconv: UTF-8, Bidi: No > height: 13, ascent: 11, descent: 3 > shadow size: 0, shadow offset: 0, shadow direction:0 > * Font number 2 > fvwm info: > Name: Shadow=0 0:xft:DejaVu Sans:style=Condensed:size=7.2 > Cache count: 1 > Type: XftFont > Charset: X: ISO10646-1, Iconv: UTF-8, Bidi: No > height: 13, ascent: 11, descent: 3 > shadow size: 0, shadow offset: 0, shadow direction:0 > * Font number 3 > fvwm info: > Name: 0 > Cache count: 1 > Type: XftFont > Charset: X: ISO10646-1, Iconv: UTF-8, Bidi: No > height: 13, ascent: 11, descent: 3 > shadow size: 0, shadow offset: 0, shadow direction:0 > *** > > I don't know how the XOM charsets are usually ordered. In case that someone > known, drop me a note. I will research about it, and try to find an all-cases > solution. But, it is crystal-clear to me that the actual state of the things > is not the correct one either. It is not less random than the choice that the > patch makes, it just takes the other extreme of the array, but, as shown in > the links I posted, and my own case, this is not correct, at least, not for > utf8 systems. > > For now, I just have the empiric note that it works on all systems I tried, > better than [0], but I did not try non-alphabetic languages, nor Arabic... > so, that belief of mine might be completely false. > > If someone has some info about the issue that could be helpful, let > me know. I will research about the patch, and try to explain how it works > so we can discard it. If that happens, I will try to design a better patch > that can handle all the locales properly. I'd really want to have this problem fixed. If all else fails, it would be allright to just add an option that tells fvwm which entry to use: +n = n'th entry -n = n'th entry counted from the end of the array 0 = default = either first or last entry Ciao Dominik ^_^ ^_^ -- Dominik Vogt
CVS domivogt: * Updated NEWS.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt08/01/07 14:08:07 Modified files: . : NEWS Log message: * Updated NEWS.
CVS domivogt: * Slightly cleaned up the ChangeLog.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt08/01/07 14:07:38 Modified files: . : ChangeLog Log message: * Slightly cleaned up the ChangeLog.
CVS domivogt: * Fixed parsing of the screen argument of the SnapAttraction style.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt08/01/07 14:05:48 Modified files: . : ChangeLog fvwm : style.c Log message: * Fixed parsing of the screen argument of the SnapAttraction style.
