Re: Transparent Window Background Not Working

[Thomas Funk]

You can try Fvwm-Nightshade (http://fvwm-nightshade.github.io). It has 
compositor support for xcompmgr and compton.



Regards,
Thomas
Am 1. November 2018 22:23:09 schrieb "Jesús J. Guerrero Botella" 
:
Kwin and xfwm are compositors. Fvwm is not, so to use the compositing 
extension in fvwm you will need xcompmgr or some other standalone compositor.


El jue., 1 nov. 2018 15:21,  escribió:
I have tried lots of stuff, too much to list at this time,
but the following test program has a transparent background
in XFCE and KDE. (On Slackware 14.2 64-Bit, NVidia Video Card
and Driver).

https://stackoverflow.com/questions/39906128/how-to-create-semi-transparent-white-window-in-xlib

It does not work in FVWM, TWM, FluxBox, BlackBox nor WindowMaker.

In FVWM, transset does not work. (Works in KDE and XFCE).

The XComposite extension is in place.

The Visual (as far as I can tell) is 32-Bit True Color.

I cannot seem to get a transparent window, no matter what.


I also tried it on an Ubuntu system as well. Same problem.


Basically I just need a transparent terminal for text overlay.


I am sending this to the Workers mailing list as if there is
something I can contribute to fix this, I would like to try.


I am running: fvwm 2.6.8-4-g4e759d6 compiled on Oct 31 2018 at 08:54:15

I tried adding this to fvwm/fvwm.c:

2281 XMatchVisualInfo(dpy, DefaultScreen(dpy), 32, TrueColor, 
);


2291 XMatchVisualInfo(dpy, DefaultScreen(dpy), 32, TrueColor, 
);


No luck.

If a window shows up as transparent in XFCE, why would that
same application not be that way in FVWM?

Re: FVWM: Recommend Config for Fluxbox user

[Thomas Funk]

On 06/26/2016 12:00 AM, Brian wrote:

Thomas, I'm sorry to say that it's been a year since I tried
Nightshade, I'm not even sure which version at the time.  I do remember
trying to build the necessary dependencies from SlackBuilds.org.  There
was a optional package which wasn't available in the SBo but I
installed without that option.  What I remember was config didn't know
how to handle my two monitors of different sizes.  I believe at the time
I thought it might be a Xinemera issue, but  crystal was perfectly
happy to handle both monitors from the default config.


The 0.6.x version hasn't multi monitor support. Also the upcoming 0.8.

I'm working on it but it isn't finished yet. Probably available in 1.0 ...


I see perl-gtk2
1.2495 in the SBo, so it shouldn't be hard to install that dep.  Good
luck with your continued development.  Is nightshade still installing
in it's own directory folders?  I know crystal is still using its own,
as the old FVWM-Themes will also.


Yes :-)


Actually I really like themes, but
trying to customize the menus with XDG integration simply failed.  The
XDG menu integration is one thing I liked about crystal.


The XDG menu integration is available in Fvwm since 2.6.6. You can use
it if you replace fvwm-menu-desktop in 2.6.5 with that one from 2.6.6.
You need also the new man page and fvwm-menu-desktop-config.fpl which
should placed in /usr/share/fvwm/. Read the new man page how to integrate
it into the root menu.


I've since
converted to WindowMaker as my preferred window manager.  It is small
on resources, fast, EWMH compliant, and handles my two monitors with
multiple desktops, with XDG menu integration through a trick I found
on the WM forum. The only thing I miss is a right-click allowing me to
move applications to other virtual desktops with a click, instead I
have to drag them to the right or left edge. I'm following the FVWM
forums because I still see awesome potential that WMaker might fail in
the future.


Yeah, Fvwm rocks! ^^

Cheers,
Thomas


--
--
"Two things are infinite: the universe and human stupidity; and I'm not sure about 
the the universe."   --   Albert Einstein

Re: FVWM: Recommend Config for Fluxbox user

[Thomas Funk]

Hi Brian,

On 06/25/2016 07:47 PM, Brian wrote:

As for nightshade and crystal, don't they both have dependencies beyond
what FVWM normally has packaged?  On my Slackware system, I have
tried both and while Crystal was usable, nightshade totally failed.


Purely out of curiosity I'd like to know what was totally failed and
which version of Fvwm-Nightshade you've tested?

I know that FNS 0.6.9 works under Slackware64-14.1 but the biggest
problem with this distribution is that required packages needed for
proper work are not available under original Slackware like

pyxdg - for application menu building
conky - for cpu and clock
stalonetray - for system tray

Only found them under SlackBuilds.org.

For the upcoming 0.8 it's much more difficult because perl-gtk2 is
missing which is used for all FNS GUIs.

But anyway thanks for trying it :-)

-- Thomas --

--
--
"Two things are infinite: the universe and human stupidity; and I'm not sure about 
the the universe."   --   Albert Einstein

Re: FVWM: Recommend Config for Fluxbox user

[Thomas Funk]

"Tim Johnson"  wrote:
>   Sorry about the mixup. On my system, .fvwm is created on the first
>   invocation and file Version is contain in that directory.
> 
>   For those unfamiliar with fluxbox, I could just use some config
>   that enables easy access to window menus. With the vanilla config,
>   I couldn't even find a way to close a window (other than
>   terminating the child app).

Up to Fvwm version 2.6.6 you could use the "Setup Form" in the Builtin 
Menu (single left click anywhere on the desktop). A good starting 
configuration is
- FvwmIconMan
- FvwmPager
- FvwmTaskBar

or

- FvwmButtons

Mark them, click "Copy ...", "Restart ..." and you have it.
> 
>   But, from that I was not even able to grok how to close a window. Or get a
>   window menu. 

After a Fvwm restart the windows have now some buttons:
left:  a minus => shows a window menu
right: a dot => minimize and a square => maximize

Hope this helps.

Another possibility is to install Fvwm-Crystal or Fvwm-Nightshade to
get a full featured configuration of Fvwm.

-- Thomas --

Re: FVWM: Ideas for a new configration file

[Thomas Funk]

On 06/10/2016 03:06 PM, Thomas Adam wrote:

Hello all,

As some of you may be aware, the master branch in git now has code which not
only removes a lot of older modules, but also removes any mechanism for having
a default configuration.

There was a previous discussion on having a new default configuration file
here:

http://thread.gmane.org/gmane.comp.window-managers.fvwm.general/6611/focus=7214

I recommend reading it first as it does seem to contain a lot of useful
information.

I'd like to hear proposals from people about the sorts of things that might be
useful, as well as how we can use this new configuration file to guide new
users.  The point that I made in my original email in the aforementioned
thread still stands:  this configuration file has to be a tutorial for users.



After reading the discussion about a new default configuration file and
that one on the forums [0] I'll try to collect the main points and attach
my thoughts:

It should be minimal, but functional

* not depending on *any* external dependencies that do not come with
  FVWM itself.
  => No excludes? xload, xclock, ...?

* New FvwmButtons -- swallowing things like:
- FvwmIconMan
- FvwmScript (maybe a clock?)
- FvwmPager
  => I liked the old one [3] (on the right bottom) but that one Nick drawn
 here [4] (at the end of the post) looks also interesting

* The config file should be documented heavily -- as an example to look
  towards for new users.
  => I like the commenting Nick did [2] - perhaps with links to the
 Fvwm documentation (which increase the maintenance on the other hand).


It should look "modern"
---
* The colour scheme needs to be changed. The existing default one is
  horrible.
* Don't look like MWM by default
* Change the window decors a bit -- maybe use colorset gradients
* Using vector buttons for the titlebar buttons
  => There was a thread started on the list [1] where people discussed what
 is wanted from a "modern" theme:
 - 3 pixel window borders
 - 1 pixel borders for modules
 - Commenting the config is very important
 ... and much more but unfortunatelly the suggestions done in ietherpad
 are lost. Perhaps pebcack or someone else has written it down somewhere
 ...

The idea with a banner which tells the user to click everywhere to open
the RootMenu is pretty nice!

Best Regards,
Thomas

Btw ... Thomas, do you have already the latest tarball of Nicks and your work?
It would be very interesting to have a look at it :-)

[0] 
http://www.fvwmforums.org/phpBB3/viewtopic.php?f=40=205=77e5e5c2b1727d2ed26675290fbd27e1
[1] http://thread.gmane.org/gmane.comp.window-managers.fvwm.devel/4901
[2] 
http://www.fvwmforums.org/phpBB3/viewtopic.php?p=1085=9769496f2e3e5bbce284604c521cb0ea#p1085
[3] http://jerome.harckmans.be/wp-content/uploads/2009/04/fvwm_default.png
[4] http://www.fvwmforums.org/phpBB3/viewtopic.php?p=1343#p1343
--
--
"Two things are infinite: the universe and human stupidity; and I'm not sure about 
the the universe."   --   Albert Einstein

Re: Deprecation: Let's talk once more about removing $STUFF...

[Thomas Funk]

On 06/02/2016 10:53 PM, Thomas Adam wrote:

Perl is my $DAYJOB, I'm more than capable.  It's just low on my list.

I don't want to offend you with my offer ... I'm only want to relieve you

But hey, no prob ...

Best,
Thomas

--
--
"Two things are infinite: the universe and human stupidity; and I'm not sure about 
the the universe."   --   Albert Einstein

Re: Deprecation: Let's talk once more about removing $STUFF...

[Thomas Funk]

On 06/02/2016 10:39 PM, Thomas Adam wrote:

It has to transition to GTK3.  Otherwise it's just as stale as GTK1.x is now
in terms of how well it has not been maintained.


That's not completely true because Gtk3-Perl isn't that stable as Gtk2-perl.
That's the point why I decided to use Gtk2-perl for SimpleGtk2 [0]. There're
not much examples and documentation available as for Gtk2-perl. Gtk3-perl starts
to get better but Gtk2 will be the defacto Gtk GUI toolkit for the next years.


Since perllib was maintained by one person, I don't hold out much hope at all
that someone will come along and do that.  It could very well be me at some
point.


I would help you to maintain fvwm-perlib as you like. I think I have enough
experience with it.

Kindly,
Thomas

[0] http://thomasfunk.github.io/SimpleGtk2/files/SimpleGtk2-pm.html
--
--
"Two things are infinite: the universe and human stupidity; and I'm not sure about 
the the universe."   --   Albert Einstein

Re: Questions how to contribute to fvwmorg.github.io

[Thomas Funk]

On 06/02/2016 06:09 PM, Thomas Adam wrote:

You should read my previous emails on documentation to this list.


you refer to 
https://www.mail-archive.com/fvwm-workers@lists.math.uh.edu/msg15756.html ?


You should look at:

manpages/fvwm.rst


So the preferred format is rst, right?

Re: Questions how to contribute to fvwmorg.github.io

[Thomas Funk]

On 06/02/2016 05:49 PM, Thomas Adam wrote:

On 2 June 2016 at 16:38, Thomas Funk <t.f...@web.de> wrote:

Hi Jaimos,

I want to implement the missing 'allCommands' and the linkings in
fvwm.man to the website. I've cloned master and created a new branch
tf/allCommands-linked-fvwm.man


I'd rather you didn't do this just yet.  If anything, I'd much rather
you contributed to ta/docs-to-md in the fvwm repo, because once that's
done, the means by which we generate HTML documentation will be
different, and simpler.


No prob. Which documents you've meant? the manpages in bin ? Or others?
If so, how should I added the files? For example fvwm.bug.1.in ... create
a new one named fvwm.bug.md.in?

Another question is if there're some manpages which aren't important enough
to convert (e.g. fvwm.bug.1.in ;-) )?

-- Thomas --

--
--
"Two things are infinite: the universe and human stupidity; and I'm not sure about 
the the universe."   --   Albert Einstein

Re: Deprecation: Let's talk once more about removing $STUFF...

[Thomas Funk]

On 05/31/2016 09:30 PM, Thomas Adam wrote:


On 19 May 2016 4:18 p.m., "Thomas Adam" > wrote:
 >
 > Hey all,
 >
 > The last time this came up for conversation [0] things were far from ideal.  
I
 > want to have another conversation about this to see whether it's possible to
 > state the case why some modules in FVWM should be removed.

Anyone?

Thomas Adam


Perhaps you shouldn't remove FvwmTaskBar for the moment until someone creates a 
replacement
with FvwmPager/FvwmIconman.

All others (FvwmDragWell, FvwmGTK, FvwmIconBox, FvwmSave / FvwmSaveDesk, 
FvwmTheme, FvwmWharf,
FvwmWinList, FvwmTabs, FvwmWindowMenu) should be removed if code is broken, 
deprecated or
replaceable.


-- Thomas --

--
--
"Two things are infinite: the universe and human stupidity; and I'm not sure about 
the the universe."   --   Albert Einstein

Re: REWRITE: Help with memory corruption issue

[Thomas Funk]

Am 29.12.2014 um 22:11 schrieb Dominik Vogt:
 A while ago I stumbled across a memory corruption issue (with
 complex functions?) in the new parser branch, but I can't find the
 message I sent to the list.  Does anybody remember the message's
 subject?
 
 Ciao
 
 Dominik ^_^  ^_^
 

You've some cores mentioned:

11.09.2014, 1:13 PM - Re: REWRITE: Bugs in the master branch
12.09.2014  0:44 AM - Re: REWRITE: Bugs in the master branch
12.09.2014  1:19 AM - Re: REWRITE: Bugs in the master branch (the explanation 
of the previous)
13.09.2014  2:00 AM - Re: REWRITE: branch dv/new-parser is stable enough to be 
used

-- 
--
Two things are infinite: the universe and human stupidity; and I'm not sure 
about the the universe.   --   Albert Einstein

Re: FVWM: mvwm and xpm-support

[Thomas Funk]

Hi Thomas,
On Mon, Oct 13, 2014 at 01:35PM +0200 Thomas Adam wrote:
 Because many different image formats to support is just code for code's
 sake.  The trick is determining which one is best-suited to the things fvwm
 has to offer.  In my mind, I may bring back SVGs, say.  But XPMs and XBMs?
 No, I _really_ would rather not.  Converting images where necessary is
 trivial to do.
When would you bring back SVG support? Because then I can test mvwm with FNS.
Could be interesting for parsing ^^

Best,
Thomas 

Re: FVWM: REWRITE: Request for help -- parsing of command token

[Thomas Funk]

Dominik Vogt wrote:
 For testing pusposes I need to get an overwiev of what types of
 commands people use in fvwm.  Could everybody please look through
 their configuration files and post any commands:
 
 1) That contain whitespace, quoting characters or variables
(e.g. $[foo] or $w) in  the first word of the line.

PipeRead echo InfoStoreAdd ratio `perl -e 'printf 
\%.1f\,log($[vp.width]*$[vp.height])/log(10)-log(1024*768)/log(10)+1'`
= calculates a ratio for resolution dependent things

*

#---
# replacement for iconify. Creates a small thumb with little app icon
# on the upper right and the name of the app at the bottom
#---
DestroyFunc FuncThumbnail
AddToFunc   FuncThumbnail
+ I Raise
+ I ThisWindow (!Iconic) PipeRead echo SetEnv app_name `xprop -id $[w.id] 
WM_CLASS |cut -d',' -f2 |cut -d'\' -f2`
+ I PipeRead echo SetEnv Icon-$[w.id] `fns-find-icon -i $[w.id]`
+ I PipeRead 'test ! -d ${FVWM_USERDIR}/temp  mkdir ${FVWM_USERDIR}/temp'
+ I ThisWindow (!Shaded, Iconifiable, !Iconic) PipeRead \
sleep 0.001; xwd -silent -id $[w.id] | convert -scale 128x72! -frame 1x1 \
-mattecolor black -quality 0 xwd:- 
png:$[FVWM_USERDIR]/temp/icon.tmp.$[w.id].png \
 echo WindowStyle IconOverride, Icon 
$[FVWM_USERDIR]/temp/icon.tmp.$[w.id].png \
|| echo Nop
+ I TestRc (Match) Test (f $[Icon-$[w.id]], f 
$[FVWM_USERDIR]/temp/icon.tmp.$[w.id].png) PipeRead \
convert $[FVWM_USERDIR]/temp/icon.tmp.$[w.id].png \\\( $[Icon-$[w.id]] 
-scale 24x24 \\\) \
-gravity northeast -geometry +10+10 -compose multiply -composite \
-fill white -undercolor '#0080' -gravity south -annotate +0+5 \ 
$[app_name] \ \
$[FVWM_USERDIR]/temp/icon.tmp.$[w.id].png; echo Nop
+ I Iconify

#---
# replacement for deiconify.
#---
DestroyFunc FuncDeThumbnail
AddToFunc   FuncDeThumbnail
+ I Test (i $[Icon-$[w.id]]) WindowStyle Icon $[Icon-$[w.id]]
+ I TestRc (NoMatch) WindowStyle NoIconOverride, Icon
+ I Exec rm -f $[FVWM_USERDIR]/temp/icon.tmp.$[w.id].png
+ I All (Iconic, CurrentPage) PlaceAgain icon
+ I PipeRead 'if [ -O $[Icon-$[w.id]] ]; then rm -f $[Icon-$[w.id]];fi'
+ I UnsetEnv Icon-$[w.id]
+ I UnsetEnv app_name

*

#---
# Shows a FvwmForm Infobox with one or multiple message line(s)
# realized with shell commands over PipeRead
#---
# Example:
# FuncShowMessage title message_1 ... message_n
DestroyFunc FuncShowMessage
AddToFunc   FuncShowMessage
+ I PipeRead `echo 'DestroyModuleConfig  FvwmForm-Messages: *'  
${FVWM_USERDIR}/FvwmForm-Messages; \
  echo '*FvwmForm-Messages: Font 8x13'  
${FVWM_USERDIR}/FvwmForm-Messages; \
  echo '*FvwmForm-Messages: WarpPointer'  
${FVWM_USERDIR}/FvwmForm-Messages; \
  echo *FvwmForm-Messages: Title   $\[gt.$0\]\\  
${FVWM_USERDIR}/FvwmForm-Messages `
+ I PipeRead `start=0; for i in $*; do \
  if [ $start -gt 0 ]; then \
echo '*FvwmForm-Messages: Lineleft'  
${FVWM_USERDIR}/FvwmForm-Messages; \
msg=$i; \
echo *FvwmForm-Messages: Text  $\[gt.$msg\]\\  
${FVWM_USERDIR}/FvwmForm-Messages; \
  fi; \
  start=$(($start+1)); \
  done `
+ I PipeRead `echo '*FvwmForm-Messages: Line   center'  
${FVWM_USERDIR}/FvwmForm-Messages; \
  echo '*FvwmForm-Messages: Button  quit \\$\[gt. Ok \]\ ^M'  
${FVWM_USERDIR}/FvwmForm-Messages; \
  echo '*FvwmForm-Messages: Command !(rm -f 
${FVWM_USERDIR}/FvwmForm-Messages)'  ${FVWM_USERDIR}/FvwmForm-Messages `
+ I Schedule 100 Module FvwmForm FvwmForm-Messages

Example:
# ButtonContext Modifi  Function
Mouse 0 T   SCM FuncShowMessage  Mouse Bindings for 
Titlebar \
Mouse 1:   Drag moves window \
   Maximize on double click \
Mouse 2:   Drag moves window \
   Raise or lower with click \
Mouse 3:   WindowOpsTrimmed menu with click \
   WindowOpsFull menu with ALT + click \
Mouse 4/5: Shade/unshade window \
   with rolling wheel up/down

*

#---
# Wallpaper Browser by Taviso.
#---
DestroyFunc FuncWallpaperBrowser
AddToFunc   FuncWallpaperBrowser
+ I PipeRead 'test ! -d ${FVWM_USERDIR}/wallpapers  mkdir 
${FVWM_USERDIR}/wallpapers; \
test ! -d ${FVWM_USERDIR}/wallpapers/.thumbs  mkdir 

Re: mvwm - things I'd like to see

[Thomas Funk]

Michael Treibton wrote:
 On 3 September 2014 22:27, Dominik Vogt dominik.v...@gmx.de wrote:
 On Wed, Sep 03, 2014 at 10:01:37PM +0100, Michael Treibton wrote:
 Here's some of the things I'd like:

 - no more motif borders (horrible)

 With fvwm you can more or less configure every border style you
 want.  Have you tried the themes package?  Theming could be better
 integrated into the distribution, though.
 
 fvwm-themes? Seems old and didn't work well for me last time. is it
 still developed?

No, since years.

but you can try Fvwm-Nightshade. Have a look on the development branch:
https://github.com/Fvwm-Nightshade/Fvwm-Nightshade/tree/develop

 - fluxbox style window borders

 Borders in fluxbox are also very configurable.  Do you have a
 screenshot of what you mean?
 
 Here is one: http://files.samhart.net/img/misc/flux-tab-example.png -
 look at the bottom border.
 
 - diff. border colors for each side

 Can already be done with pixmap borders.
 
 but why must i make pixmaps for each color that i want? i have
 colorsets for this, don't i?
 
 Could you please elaborate on what you think fvwm is missing in
 terms of scripting flexibility?  (Other than fvwm's scripting
 language can be awkward - we're working on that.)
 
 That, and i don't like perl?  Everything is using dedicating embedded
 things like lua from the outset, so why can't this wm?

you can use every scripting language in FVWM via PipeRead but Perl is
best integrated.

There's exist a lua module but haven't tested it:
http://box-look.org/content/show.php/FvwmLua+0.4?content=127229

Also a Python library:
http://barry.warsaw.us/software/fvwm.html

 Note that mvwm is not going to be a brand new window manager that
 does everything from scratch.  It will be a very much improved fvwm
 with maybe a few antique things removed.  Regarding window
 handling and window decorations it won't change much for now.
 
 i think i understand that, yes. But i don't always see if this
 approach is good or not - why not write it from scratch? wasn't that
 the original intent?

The most part I am missing is dynamic parts like growing FvwmButtons
= add a button on the fly without restart the module.

But most things can be made with FVWM.

-- Thomas --


-- 
--
Two things are infinite: the universe and human stupidity; and I'm not sure 
about the the universe.   --   Albert Einstein

Re: REWRITE: Some removed features

[Thomas Funk]

Dominik Vogt dominik.v...@gmx.de wrote:
 2. Support for xpm, xbm and svg images.
 
   While I've no idea whether svg images are really usefull (in
   title buttons perhaps?), xpm images, and to a lesser extent xbm
   iamges, are still used a lot in old icon themes.  So I vote for
   reviving support for xpm and xbm format.
 
 I can take care of both.

In Fvwm-Nightshade I am using mostly svg's because of the flexibility
in conjunction with different display resolutions. Also the trend in
other DEs/WMs is in direction to svg (icon themes, decorations).

It would be a pitty if FVWM(3) loose this support. But to reduce the
core to an effective minimum it is ok for me. I suppose that Thomas
thought to implement those parts as modules which would be great 
because then other image formats can plugged to FVWM very easily.
Also it would reduce the maintenance ^^

-- Thomas --

Re: REWRITE: Docs conversion and introducing a new (humble) contributor

[Thomas Funk]

 On Mon, Aug 18, 2014 at 10:43:55PM +0400, Roman Grazhdan wrote:
 documentation conversion part - docbook to mdoc.

Thomas,

what about the documentation I had converted to asciidoc a year ago?

-- Thomas --

-- 
--
Two things are infinite: the universe and human stupidity; and I'm not sure 
about the the universe.   --   Albert Einstein

Re: FVWM: A way of putting a large number of menu items in an FVWM2 menu

[Thomas Funk]

Paul King wrote:
 Hi
 
 I wasn't planning to spend a lot of time on this, but what I had was a large 
 directory of graphics files (jpegs) that I wanted as screen backgrounds on an 
 X-Windows desktop running fvwm-2 somewhere on my PC. 
 
 I was handy with making menu entries in fvwm-2, but I was not too crazy about 
 making separate individual entries for each file by hand, so I created a perl 
 script that did this for me. It sends it to standard output, which I can 
 always 
 redirect into a file and read into the ~/.fvwm/menus file later. Then, it 
 takes 
 only a few minutes to make the submenus of about 20 files each.
 
 I offer the script to this list for what it's worth, and feel that most 
 people 
 here are handy with languages like Perl they can tweak values in the script 
 to 
 their liking. I've tailored the script so that you need only a casual perl 
 skill and casual UNIX skill.
 
 It's at: http://pjk.scripts.mit.edu/lab/src/index.html
 
 If you find it useful, go ahead and use it!
 
 Paul King
 

There's also another approach by Taviso to create menu entrys with 
fvwm-menu-directory 
on the fly:

It creates at first scan (when user opens the menu) a .thumbs directory with 
thumb icons 
of the files and shows them then. 

The only problem of the current listed solution is, that the wallpaper 
directory should 
be writable by the user. But it can be changed easily in function 
WallpaperBrowser that 
the .thumbs will be created at another location.

Needed applications: ImageMagick, xv


#---
# wallpaper directory path.
#---
InfoStoreAdd wallpaper_dir $[FVWM_USERDIR]/wallpapers

#---
# actual wallpaper
#---
InfoStoreAdd fvwm_wallpaper $[FVWM_USERDIR]/.wallpaper


#***
# 8.1.1 Start
#***
# The StartFunction is used at start and restart with or without a Session
# Manager.
DestroyFunc StartFunction
AddToFunc StartFunction
#---
# set the root background image with feh if available
+ I Test (I $[infostore.fvwm_wallpaper]) Exec exec feh --bg-scale 
$[infostore.fvwm_wallpaper]


#---
# Dynamic Configuration sub menu for setting a background with
# a picture realized with MissingSubmenuFunction (for the pictures)
#---
AddToMenu MenuWallpaperConfiguration DynamicPopupAction 
FuncMenuWallpaperConfiguration

DestroyFunc FuncMenuWallpaperConfiguration
AddToFunc FuncMenuWallpaperConfiguration
+ I DestroyMenu MenuWallpaperConfiguration
+ I AddToMenu MenuWallpaperConfiguration Backgrounds Title
+ I AddToMenu MenuWallpaperConfiguration DynamicPopupAction 
FuncMenuWallpaperConfiguration
+ I AddToMenu MenuWallpaperConfiguration MissingSubmenuFunction WallpaperBrowser
+ I AddToMenu MenuWallpaperConfiguration Set Wallpaper background Popup 
$[infostore.wallpaper_dir]


#---
# Wallpaper Browser by Taviso.
#---
DestroyFunc WallpaperBrowser
AddToFunc WallpaperBrowser
+ I PipeRead 'test ! -d ${FVWM_USERDIR}/wallpapers  mkdir 
${FVWM_USERDIR}/wallpapers; \
test ! -d ${FVWM_USERDIR}/wallpapers/.thumbs  mkdir 
${FVWM_USERDIR}/wallpapers/.thumbs; \
for i in $0/*; do \
test -f ${FVWM_USERDIR}/wallpapers/.thumbs/${i##*/} -a ${i} -ot 
${FVWM_USERDIR}/wallpapers/.thumbs/${i##*/} || { \
convert -quality 0 -sample 42 ${i} 
png:${FVWM_USERDIR}/wallpapers/.thumbs/${i##*/} 2/dev/null \
|| continue; \
}; \
done; \
fvwm-menu-directory --icon-title menu/folder-open.xpm --icon-file 
__PIXMAP__ --links \
--icon-dir menu/folder.xpm \
--dir $0 --command-file=FuncNewWallpaper \\%f\\ \
--exec-t=^xv -wait 2 * --func-name WallpaperBrowser | sed \

s#__PIXMAP__\\(.*\\)\(.*/\\)\\(.*\\)\\\#\\$[FVWM_USERDIR]/wallpapers/.thumbs/\\3\\1\\2\\3#g'


#---
# switch to chosen wallpaper picture
#---
DestroyFunc FuncNewWallpaper
AddToFunc   FuncNewWallpaper
+ I PipeRead 'ln -sf $* $[FVWM_USERDIR]/.wallpaper'
+ I Exec exec feh --bg-scale $[infostore.fvwm_wallpaper]


-- Thomas --

-- 
--
Two things are infinite: the universe and human stupidity; and I'm not sure 
about the the universe.   --   Albert Einstein

Re: FVWM: fvwm and mvwm? How is fvwm?

[Thomas Funk]

Stuart Longland wrote:
 On 11/05/14 19:39, Michael Treibton wrote:
 I recently read this:

 https://plus.google.com/+ThomasAdamXteddy/posts/H5dV9UM7Pbe

 And wondered what the status of fvwm is for definite, especially now
 one of the main developers has abandoned it.

 What do others think?

FVWM is still an active project as you can see it on the mailing lists
but it's true that there are many parts in the code which could be 
removed but that's not so easy. FVWM is over 20 years old and many things
were growed over the time and interlaced with each other.

If Thomas wants to clean up FVWM why not. It is free software and it is
his good right to do this. But this doesn't mean that FVWM is dead.

 It worries me a bit too.  

Don't worry. FVWM has a very active community. See
- Mailing lists
- Forums
- Projects (Fvwm-Crystal, Fvwm-Nightshade)

-- Thomas --

--
Two things are infinite: the universe and human stupidity; 
and I'm not sure about the the universe. -- Albert Einstein

Fwd: Re: fvwm-menu-desktop and mini icons

[Thomas Funk]

Am 25.04.2014 18:02, schrieb Dominique Michel:
 Le Fri, 25 Apr 2014 12:32:09 +0200,
 Dominique Michel dominique.mic...@vtxnet.ch a écrit :
 
 I think this is a bug.

Fixed.

-- Thomas --

Re: FVWM: FVWM Wiki

[Thomas Funk]

Am 16.04.2014 22:02, schrieb Jaimos F Skriletz:
 On 04/16/2014 01:40 PM, Thomas Funk wrote:
 Hi there!

 I am wondering what's happening with the FVWM wiki on 
 http://fvwmwiki.xteddy.org/ ?

 I remember there was a discussion to move it into FVWM's website or 
 something like that.

 But now the wiki is gone and never appears anywhere :-/

 Does anybody knows about that? Because it would be a pitty if these very 
 well information are lost.
 
 The information is not lost, I have a copy of it and need to add it to 
 the fvwmforums.org domain but the server didn't have new enough perl for 
 the ikiwiki and I wasn't able to get a clean html dump of it.
 
 I tried at http://zensites.net/wiki/fvwmwiki-html/ as a test, but it 
 didn't render the html correctly all the way
 
 Then I got distracted from learning ikiwiki
 
 jaimos

Thanks for the info Jaimos :-)

I would help but I am too busy at the moment ... :-(

Here's the last known link from the wayback machine - hope this helps others a 
little:
http://web.archive.org/web/20130918013213/http://fvwmwiki.xteddy.org/

Best,
Thomas

-- 
--
Two things are infinite: the universe and human stupidity; and I'm not sure 
about the the universe.   --   Albert Einstein

Re: fvwm-menu-desktop locale strangeness

[Thomas Funk]

Am 13.04.2014 17:31, schrieb Dominique Michel:
 Hi,
 
 with fvwm-crystal, I get an issue with a localized xdg menu. If I
 launch fvwm as a Xephyr session and use its default configuration (no
 config file), I get a very simple menu where it is a Desktop Menu. If I
 click on it, I get an applications menu with several menus in it:
 
 Fvwm Applications
 Suse Applications
 Xfce Applications
 Xfce Settings Manager
 
 which correspond to what I have in /etc/xdg/menus. The Fvwm
 Applications menu is my localized menu. If I browse it, only parts of
 it are localized, and other parts are not when the localization exist
 in /usr/share/directories.
 
 I made the following function:
 
 DestroyMenu FvwmMenu
 AddToMenu FvwmMenu
 + DynamicPopupAction PipeRead 'fvwm-menu-desktop \
 --desktop fvwm-applications \
 --enable-mini-icons \
 --mini-icon-dir $[FVWM_USERDIR]/icons/fvwm-desktop'
 

Try this:
DestroyMenu FvwmMenu
AddToMenu FvwmMenu
+ DynamicPopupAction PipeRead 'fvwm-menu-desktop \
--desktop fvwm \
--type applications \
--enable-mini-icons \
--mini-icon-dir $[FVWM_USERDIR]/icons/fvwm-desktop'


because --desktop defines not the menu name. fvwm-menu-desktop
assemble the menu name from the desktop type and the menu type.

 Key A A $[Mod1] Menu FvwmMenu
 
 With it, I get only the fvwm-applications menu, and it is entirely
 localized (the part which are already done, it's a work in progress).
 
 After that, I removed all the files in /etc/xdg/menus but
 fvwm-applications.menu, and after launching fvwm, I get an error
 instead of the menu:
 
 # fvwm-menu-desktop
 Traceback (most recent call last):
   File /usr/bin/fvwm-menu-desktop, line 634, in module
 main()
   File /usr/bin/fvwm-menu-desktop, line 232, in main
 menulist, desktop_temp = getmenulist(desktop, menu_type)
   File /usr/bin/fvwm-menu-desktop, line 400, in getmenulist
 desktop_dict[de_highest].add(menu)
 KeyError: 'xfce'
 
 What is strange is I don't have any xfce key into the menu. I try with

Would you please post the output of
$ fvwm-menu-desktop --version
and
$ fvwm-menu-desktop --get-menus all --verbose

whether all menus on place?

 
 # XDG_MENU_PREFIX=fvwm fvwm-menu-desktop
 
 and it work fine. 

Yes, because fvwm-menu-desktop is ignored. Correct:
XDG_MENU_PREFIX=fvwm

 It should be nice fvwm if fvwm-menu-desktop would be
 able to use by default a fvwm-applications.menu if it exist and is the
 only one in /etc/xdg/menus.
 
 I made another try, to issue 'SetEnv XDG_MENU_PREFIX fvwm' into the
 fvwm console in crystal, and with it, it work when I launch fvwm with
 Xephyr, that even if I move back the other menu files.
 
 So, to summarize, it should be nice fvwm if fvwm-menu-desktop would be
 able to use by default a fvwm-applications.menu if it exist and is the
 only one in /etc/xdg/menus. And without XDG_MENU_PREFIX defined and
 its default fvwm configuration (no fvwm config file at all),
 fvwm-menu-desktop localization seam to be confused when it is several
 menus in /etc/xdg/menus with different localizations or non
 localizations.

Hmm ... perhaps. what pyxdg version do you using?

-- Thomas --

-- 
--
Two things are infinite: the universe and human stupidity; and I'm not sure 
about the the universe.   --   Albert Einstein

Re: A few issues with fvwm-desktop-config.fpl and fvwm-menu-desktop

[Thomas Funk]

On 02/25/2014 05:16 PM, Dominique Michel wrote:
 Hi,
 
 I get a few issues with fvwm-desktop-config.fpl.
 
 First, the French translation is approximative, I get Sauvez les
 réglages for the 2 buttons at the bottom left. And the translation of
 a few other strings is not so good. I will see what I can do to fix
 that translation.
Would be fine. My business colleague hasn't the technical knowledge to
create the complete right translation.
So if you can fix it would be great :-)

 Second, with all check boxes, I get the same colour for the text of the
 check boxes than for the text of the buttons, which is a different
 colour than the text of the labels.
Hmmm  there are no colors set in between the FvwmForm (which will
created while execution of fvwm-desktop-config.fpl).

Check your FvwmForm Defaults file first.

 This work fine with some of my colour sets, but with other colour sets,
 I get almost the almost colour for the text of the checkboxes than the
 background of the form. It would be much better is the text for the
 check boxes use the same colour than the text for the labels, or if the
 text for the check boxes use the same background colour than the
 button. Is it possible to change that?
See above.

 Third, when I have
 
 *FvwmForm-Desktop-ConfigDefault: IconDir
 $FVWM_USERDIR/icons/fvwm-desktop
 
 in ~/.FvwmForm-Desktop-Config, the text is truncated in the
 corresponding edit box:
 
 $FVWM_USERDIR/icons/fvwm-desk
Probably it have to set in quotes. I will check this.

 Fourth, with fvwm-menu-desktop, gentoo only provide the icons from
 different icon-themes and these provided by the applications.
 
 I get a few warnings like:
 [fvwm][scanForPixmap]: WARNING Couldn't load image
 from /home/dom/.fvwm-crystal/icons/fvwm-desktop/24x24-xmahjongg.gif
 [fvwm][scanForPixmap]: WARNING Check that FVWM has support for the
 filetype it's being asked to load.
 
 The file formats that cause these warnings
 are .bmp, .gif, .ico, .jpg, .pcx, .ppm and .tga so far. It should be
 better to convert all of them into a format that is know to fvwm.
 Something like
 
 convert other options name.ext name.png
 
 can be used.
Yes, only svg icons will be changed to png. All others as is. Will fix it.

- Thomas -

-- 
--
Two things are infinite: the universe and human stupidity; and I'm not sure 
about the the universe.   --   Albert Einstein

Re: FvwmScript - WriteToFile seems not working

[Thomas Funk]

2013/12/14 Dominique Michel dominique.mic...@vtxnet.ch:
 Le Sat, 14 Dec 2013 00:34:38 +0100,
 Thomas Funk t.f...@web.de a écrit :

 Dan Espen wrote:
  Thomas Funk t.f...@web.de writes:
 
  Hi!
 
  I'm working on a composite configurator with FvwmScript and
  getting an issue with WriteToFile command. It only writes '#end'
  into the file.
 
  First I thought I've done something wrong but I do the same as in
  FvwmScript-BaseConfig. So I started a test with
  FvwmScript-BaseConfig and the same happens. Used FVWM is 2.6.5.
  This happens under Fedora 19, too.
 
  My next thought was something has changed in WriteToFile source
  since creation of FvwmScript-BaseConfig - 2007-08-07. So I
  compared the code from 2.5.22 and CVS but nothing has changed.
 
  So, what could be the problem?
 
  We'd probably have to see the script but you could always resort to
  adding printfs in Instructions.c.
 
  Start with determining if it gets NbArg right.
  Just seeing #end is an indication that it doesn't
  see the args after the filename.

 I have checked different VMs with different FVWM versions with
 FvwmScript-BaseConfig:

 Debian 4.x (2007) with FVWM 2.5.22 - ok, creates full config
 Debian 6.x (2011) with FVWM 2.6.0 - ok, creates full config
 Debian 7.1 (2013) with FVWM 2.6.6 - ok, creates full config
 Debian 7.1 (2013) with FVWM 2.6.5 - ok, creates full config
 Debian 8 (testing, 2013) with FVWM 2.6.5 - nok, creates '#end'
 Fedora 19 (2013) with FVWM 2.6.5 - nok, creates '#end'

 Dominique Michel wrote:
  I get the same issue yesterday.
  This is with fvwm-2.6.6 from cvs and gentoo.

 So, it seems it's not a script problem.

 Therefore I've starting your suggestion with 'printfs' in
 instructions.c under my Fedora VM. I used this FvwmScript with one
 WriteToFile:

 #WindowTitle   {Test WriteToFile}
 #WindowSize  470 415# Taille
 #
 #Init
 #Begin
 #Set $userDir = (GetOutput {echo $FVWM_USERDIR} 1 -1)
 #Set $configPath = $userDir{/bla}
 #
 #WriteToFile $configPath {This is a test}
 #Quit
 #End

 As I didn't knew what you meant with 'printfs' I used printf first
 and hoped that output went into .xsession-errors. No output appeared
 but WriteToFile worked. So I removed printf and compiled code
 suddenly worked!

 Same code, different behaviors...

 Therefore I did the same on my Debian 8 system and the compiled
 version of FvwmScript works also.

 Under Debian 8 and Fedora 19 I have distribution packages installed.
 All others are self compiled.

 Could it be a problem of code optimization? Because the FvwmScript
 executables has huge different sizes:
 package:   380K
 compiled:  1,5M

 The only thing that not fit in this to theory is Dominiques issue
 because his code is self compiled, too ...

 My ebuild is the same than the one in gentoo. I modified it to use the
 cvs and to be able some patches, but I don't apply them, so the code is
 the one from the cvs.

 The cflags are a little bit extensive, that was to be able to cross
 compile in my tower and be sure to get a consistent result, but the
 tower is dead now. The only ones that doesn't are for the processor are
 -O2 -pipe and they should be sure:

 CFLAGS=-march=amdfam10 -mcx16 -msahf -mpopcnt -mabm --param
 l1-cache-size=32 --param l1-cache-line-size=64 --param
 l2-cache-size=512 -mtune=amdfam10 -O2 -pipe
 CFLAGS_amd64=-m64

 CXXFLAGS=-march=amdfam10 -mcx16 -msahf -mpopcnt -mabm --param
 l1-cache-size=32 --param l1-cache-line-size=64 --param
 l2-cache-size=512 -mtune=amdfam10 -O2 -pipe

 LDFLAGS=-Wl,-O1 -Wl,--as-needed
 LDFLAGS_amd64=-m elf_x86_64

 The ebuild append -fno-strict-aliasing to the cflags.

 The result with my configure USE flags is:
 fvwm --version
 fvwm 2.6.6 (from cvs) compiled on Oct 27 2013 at 16:48:42
 with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm,
 SM, Bidi text, XRender, XCursor, XFT, NLS

 The size of FvwmScript executable is around 400.6k here.

Is it possible, that you compile FVWM normally with configure  make, copy
the FvwmScript executable to /usr/lib/fvwm/2.6.6/ and test it with the script
snippet above or yours?

Please deactivate the debugging while configure:
./configure --cflags=-O2 (or --CFLAGS? I don't know cause I am at work ...)

@Dan:  As '-g' is part of the default cflags this is the reason why my
executable
has 1,5M. Without it has around 450k. with '-O3' the size has increased and no
change of the behaviour - works as with '-O2'. So, it's not the optimize
parameter ...

- Thomas -

Re: FvwmScript - WriteToFile seems not working

[Thomas Funk]

Dan Espen wrote:
 Thomas Funk t.f...@web.de writes:
 
 Hi!

 I'm working on a composite configurator with FvwmScript and getting an
 issue with WriteToFile command. It only writes '#end' into the file.

 First I thought I've done something wrong but I do the same as in
 FvwmScript-BaseConfig. So I started a test with FvwmScript-BaseConfig
 and the same happens. Used FVWM is 2.6.5. This happens under Fedora 19,
 too.

 My next thought was something has changed in WriteToFile source since 
 creation of FvwmScript-BaseConfig - 2007-08-07. So I compared the code 
 from 2.5.22 and CVS but nothing has changed.

 So, what could be the problem?
 
 We'd probably have to see the script but you could always resort to
 adding printfs in Instructions.c.
 
 Start with determining if it gets NbArg right.
 Just seeing #end is an indication that it doesn't
 see the args after the filename.

I have checked different VMs with different FVWM versions with 
FvwmScript-BaseConfig:

Debian 4.x (2007) with FVWM 2.5.22 - ok, creates full config
Debian 6.x (2011) with FVWM 2.6.0 - ok, creates full config
Debian 7.1 (2013) with FVWM 2.6.6 - ok, creates full config
Debian 7.1 (2013) with FVWM 2.6.5 - ok, creates full config
Debian 8 (testing, 2013) with FVWM 2.6.5 - nok, creates '#end'
Fedora 19 (2013) with FVWM 2.6.5 - nok, creates '#end'

Dominique Michel wrote:
 I get the same issue yesterday.
 This is with fvwm-2.6.6 from cvs and gentoo.

So, it seems it's not a script problem.

Therefore I've starting your suggestion with 'printfs' in instructions.c
under my Fedora VM. I used this FvwmScript with one WriteToFile:

#WindowTitle   {Test WriteToFile}
#WindowSize  470 415# Taille
#
#Init
#Begin
#Set $userDir = (GetOutput {echo $FVWM_USERDIR} 1 -1)
#Set $configPath = $userDir{/bla}
#
#WriteToFile $configPath {This is a test}
#Quit
#End

As I didn't knew what you meant with 'printfs' I used printf first and 
hoped that output went into .xsession-errors. No output appeared but
WriteToFile worked. So I removed printf and compiled code suddenly 
worked!

Same code, different behaviors...

Therefore I did the same on my Debian 8 system and the compiled version
of FvwmScript works also.

Under Debian 8 and Fedora 19 I have distribution packages installed. 
All others are self compiled.

Could it be a problem of code optimization? Because the FvwmScript 
executables has huge different sizes:
package:   380K
compiled:  1,5M

The only thing that not fit in this theory is Dominiques issue because
his code is self compiled, too ...

- Thomas -

Re: FVWM: Launching Applications/Configuration Question

[Thomas Funk]

Am 10.12.2013 07:54, schrieb lee: Thomas Funk t.funk...@googlemail.com 
writes:
 
 2013/12/5 James Griffin j...@kontrol.kode5.net:
 I've got a load of functions defined in my configuration file using
 DestroyFunc/AddToFunc. What I would like to know, is how can use
 these functions to test if the application in question is already
 running? In particular, I have an FvwmButtons instance that starts a
 panel - I wouldn't want more than one instance of this panel
 running.

 Any help would be appreciated.

 Cheers, Jamie.


 Try this:

 DestroyFunc StartOnce
 AddToFunc   StartOnce
 + I PipeRead 'if [ `ps -ef |grep -v grep |grep -c $0` -lt 1 ]; then \
 echo Exec $0; \
   fi'

 The only thing is that you've got to set the command in quotes:
 StartOnce xterm -fg black -bg snow2 -g 80x40 -fn 7x14
 
 Since I recently ran into issues with quotes which resulted in reading
 /bin/ls instead of a configuration file:
 
 I notice that you are using three different types of quotes here.  Is
 there some documentation about when to use what kind of quotes?

No, not really. It depends what programming language you're using with 
PipeRead. In this example I use shell commands. The backticks (`) are 
for executing commands. To substitute a variable in shell you have to 
use double quotes (). Single quotes (') won't work because it tells 
the shell to use it as is:
$ bla=`ls`
$ echo '$bla'
prints only $bla. But
$ echo $bla
prints the content of ls

With PipeRead you can use all of the 3 types of quotes to enframe the
code you're using:
PipeRead `code`
PipeRead 'code'
PipeRead code

But, if you want to use variables (from FVWM or from within your code)
you need double quotes for substitution. In my example I use backticks,
too. Therefore I have taken single quotes to enframe because all others
were used.

If you need inside your code the same quotes as for the enframing then 
you have to escape them with one backslash (\) or sometime more then 
one:

DestroyFunc UpdateWindowOpacity
AddToFunc   UpdateWindowOpacity
+ I PipeRead echo SendToModule \
FvwmTransSet opac `perl -e 'printf \%.1f\,(100-$0/100)'`

In this example the function gets a percent value but the FvwmTransSet
module wants a float - 0.7 instead of 70. With the Perl code I convert
it. Unfortunately I need the backticks for execution and Perl wants
the command in single quotes and the printf wants %.1f in double quotes
because of the substitution. So I have to escape the double quotes.

 How do you test something like this StartOnce function in a save way?

First I test it part for part in a terminal without variables. Or if it
is a longer code in a script.
If it works I create the function in a file e.g. testem in FVMW_USERDIR.
Mostly with echo commands like

DestroyFunc StartOnce
AddToFunc   StartOnce
+ I PipeRead 'if [ `ps -ef |grep -v grep |grep -c $0` -lt 1 ]; then \
echo works!; \
  fi'

Next I open a terminal and run tail on ~/.xsession-errors to see errors:
$ tail -f ~/.xsession-errors

Then I start FvwmConsole and read the file:
FvwmConsole version 2.6.5
Read testem enter

If something is wrong you'll see it in your tail terminal. If nothing 
happens FVWM has accepted the syntax. Call the function in FvwmConsole:
StartOnce xterm -fg black -bg snow2 -g 80x40 -fn 7x14

That's it. Hope this helps a little.

- Thomas -

Btw. In this example you can use single quotes, too instead of double 
quotes. It doesn't matter.

Re: Patches for fvwm-menu-desktop to support py-xdg 0.19 and localization

[Thomas Funk]

2013/12/6 Jesús J. Guerrero Botella jesus.guerrero.bote...@gmail.com:
 Hi everyone, hi Thomas Funk :)

 I have some time now to do the work, if it's still needed. What's the
 po file I should be picking to review or do the translation? It's been
 some time since and my mind is a bit blurry...

fvwm.es.po

 Should I just pick the latest code from CVS and review it?

Yes, would be fine :-)

- Thomas -

 Thanks for your patience and regards :)


 2013/8/29 Jesús J. Guerrero Botella jesus.guerrero.bote...@gmail.com:
 Hi again.

 I just remembered about this, and wanted to say that I am still
 planning to do what I promised. It's just that I haven't got the time
 to do it yet, but I haven't fogotten about this. I've had a lot of
 work lately, I am finishing a program for a customer. Once I have
 finished that I'll probably have plenty of free time ;)

 It should take me no more than one month, counting from today. But,
 since the customer is always right (tm), so you never know for sure
 hehe...

 Sorry for being so late, and thanks to everyone for the patience.

 2013/6/18 Thomas Funk t.funk...@googlemail.com:
 2013/6/18 Jesús J. Guerrero Botella jesus.guerrero.bote...@gmail.com

 Hey!

 2013/6/15 Thomas Funk t.f...@web.de:
 
  @Jesús J. Guerrero Botella:
  Is it possible that you would do the translation for the Spanish po?
 

 Of course, sir, though I can't promise them to be ready at any given
 time schedule, so I'll just say ASAP :P


 :D ... that's asap enough, sir  ^^

 Thanks for helping!

 Cheers,
 Thomas


 Cheers.
 --
 Jesús Guerrero Botella





 --
 Jesús Guerrero Botella



 --
 Jesús Guerrero Botella

Re: FVWM: Launching Applications/Configuration Question

[Thomas Funk]

2013/12/5 James Griffin j...@kontrol.kode5.net:
 I've got a load of functions defined in my configuration file using 
 DestroyFunc/AddToFunc. What I would like to know, is how can use these 
 functions to test if the application in question is already running? In 
 particular, I have an FvwmButtons instance that starts a panel - I wouldn't 
 want more than one instance of this panel running.

 Any help would be appreciated.

 Cheers, Jamie.


Try this:

DestroyFunc StartOnce
AddToFunc   StartOnce
+ I PipeRead 'if [ `ps -ef |grep -v grep |grep -c $0` -lt 1 ]; then \
echo Exec $0; \
  fi'

The only thing is that you've got to set the command in quotes:
StartOnce xterm -fg black -bg snow2 -g 80x40 -fn 7x14


Best,
Thomas

Manpage for fvwm-menu-desktop GUI

[Thomas Funk]

-Desktop but inserts the 
found xdg menus dynamically into the Form before processed. Adapted by 
Thomas Funk.

.SH COPYING
The script is distributed by the same terms as fvwm itself. See GNU
General Public License for details.

Re: Restructured fvwm-menu-desktop-config and xdg menu question

[Thomas Funk]

2013/10/7 Dan Espen des...@verizon.net:
 Thomas Funk t.f...@web.de writes:

 Hi Dan,

 I have implemented two new options in fvwm-menu-desktop:
 --app-icon NAME   set default application icon if no others found.
   Default is gnome-applications.
 --dir-icon NAME   set default directory icon if no others found.
   Default is gnome-fs-directory.

 because gnome-applications' and 'gnome-fs-directory' not available in
 all icon themes.

 Therefore I have restructured fvwm-menu-desktop-config to reduce the
 window size to place the new options.

 Would you check my new placements please if it is understandable? I
 have removed some descriptions to hold the layout compactly. If all
 suits I will write a manpage for fvwm-menu-desktop-config.

 I see you've hard coded fonts for the FvwmForm:

 *${modname}: Font   7x13bold
 *${modname}: InputFont  7x13bold
 *${modname}: ButtonFont 7x13bold

 I don't think that's a good idea.
 I'm using much bigger fonts due to my high resolution monitor.
 Since we have a GUI for setting FvwmForm defaults, I don't think we
 should be overriding those fonts in one of our tools.

Ok, then I remove these lines.

 Everything else looks okay.

 Usage is misspelled on the first comment line in the .fpl file.

Will check it.

 Attached is fvwm-menu-desktop-config.fpl and the new fvwm-menu-desktop
 for testing.

 Had me confused there, I didn't think you had commit access set up yet.

I've sent you both for easy testing because of the two new options ;-)

 Another point is the thing with a xdg menu for Fvwm. Should we ship
 such menu with Fvwm generally? If so the question is what should we do:
 install it under /etc/xdg/menus/ or ship it as an example file and the
 user can decide by her/himself?

 I have created a common one with the needed directory files and it
 works fine on most systems. In some parts it could be changed but that
 is another point ;-)

 Not sure what you mean, I think you're talking about .desktop files with
 Fvwm options in it, like start/restart Fvwm, etc?  So that when someone
 installs Fvwm they get menu options to start Fvwm.

 If so, definitely yes, it's something I wanted to do but never got to it.

I don't ment fvwm.desktop placed in /usr/share/xsessions/. But that's no
problem - we could use fvwm.desktop from the Fedora package.

No, I mean a fvwm-applications.menu AND the needed directory files
located in /usr/share/desktop-directories/.

If you want it for testing I can send all as a tar.gz.

- Thomas -

 --
 Dan Espen

Restructured fvwm-menu-desktop-config and xdg menu question

[Thomas Funk]

Hi Dan,

I have implemented two new options in fvwm-menu-desktop:
--app-icon NAME   set default application icon if no others found.
  Default is gnome-applications.
--dir-icon NAME   set default directory icon if no others found.
  Default is gnome-fs-directory.

because gnome-applications' and 'gnome-fs-directory' not available in
all icon themes.

Therefore I have restructured fvwm-menu-desktop-config to reduce the
window size to place the new options.

Would you check my new placements please if it is understandable? I
have removed some descriptions to hold the layout compactly. If all
suits I will write a manpage for fvwm-menu-desktop-config.

Attached is fvwm-menu-desktop-config.fpl and the new fvwm-menu-desktop
for testing.


Another point is the thing with a xdg menu for Fvwm. Should we ship
such menu with Fvwm generally? If so the question is what should we do:
install it under /etc/xdg/menus/ or ship it as an example file and the
user can decide by her/himself?

I have created a common one with the needed directory files and it
works fine on most systems. In some parts it could be changed but that
is another point ;-)

Best,
Thomas


preview_fvwm-menu-desktop-config.tar.gz
Description: GNU Zip compressed data

Re: fvwm-xdg-menu: additonal FreeDesktop categories support

[Thomas Funk]

michel dominique wrote:
 Hi,

 I begun to made some work on a xdg menu for fvwm-menu-desktop
 that will provide FreeDesktop additional categories support out of the
 box.

 It will provide /etc/xdg/menus/fvwm-applications.menu and its
 associated files. This is a work in progress, for just it just
 give an idea of what I want to do. A few additional categories
 are already supported, and it will take some time until all are
 incorporated.

 It is a repository on github:
 https://github.com/domichel/fvwm-xdg-menu [1]
The xfce menu is the wrong one you've started with. It is too specific.
You have to use an applications.menu. It is more unique.
The other problem with your menu is that you have .desktop entries. A
unique menu should work without them.

Attached is my first test menu based on Ubuntus applications.menu with
some parts from openSuse. I have to test it on other distributions but
on Debian it works fine. Should work on Fedora, too because their
applications.menu is similar.
But Mageia/Mandriva for example has own directory named files besides of
the xdg specification, so there is much work to support such
distributions.

 It is no icon support for the categories at that time, maybe later if
 I find the time. But maybe they are already in fvwm-themes?
fvwm-menu-desktop supports icons by default.

Thomas

 Best,
 Dominique





  Applications
  X-GNOME-Menu-Applications.directory

  
  /etc/X11/applnk
  /usr/share/gnome/apps

  
  
  
  

  
  /usr/local/share/applications

  
  

  
  
Accessories
Utility.directory

  
Utility

Accessibility
System
  

   

  
  
Universal Access
Utility-Accessibility.directory

  
Accessibility
Settings
  

   

  
  
Development
Development.directory
suse-development.directory

  
Development
X-SuSE-Core-Development
Building
Debugger
IDE
GUIDesigner
X-SuSE-Design
Profiling
RevisionControl
Database
Translation
Documentation
WebDevelopment
  


  
  


  Building
  Building.directory
  suse-development-building.directory
  
Building
  


  Debugger
  Debugger.directory
  suse-development-debugger.directory
  
Debugger
  


  IDE
  IDE.directory
  suse-development-ide.directory
  
IDE
  


  GUIDesigner
  GUIDesigner.directory
  suse-development-guidesigner.directory
  
GUIDesigner
X-SuSE-Design
  


  Profiling
  Profiling.directory
  suse-development-profiling.directory
  
Profiling
  


  RevisionControl
  RevisionControl.directory
  suse-development-revisioncontrol.directory
  
RevisionControl
  


  Database
  Database.directory
  
Database
  


  Translation
  Translation.directory
  suse-development-translation.directory
  
Translation
  


WebDevelopment
WebDevelopment.directory
suse-internet-webdevelopment.directory


  WebDevelopment




Documentation
Documentation.directory
suse-documentation.directory


  Development
  Documentation



   

  
  
Education
Education.directory
suse-education.directory

  
Education
X-SuSE-Core-Education
X-KDE-Edu-Teaching
Science
X-SuSE-Core-Science
Art
Construction
Music
Languages
X-KDE-Edu-Language
Biology
Chemistry
Physics
Economy
Geography
Geology
History
Literature
Math
Sports
  


  
  


  Art
  Art.directory
  suse-education-art.directory
  
Art
  


  Construction
  Construction.directory
  suse-education-construction.directory
  
Construction
  


Music
Music.directory
suse-education-music.directory


  Education
  Music
  AudioVideo




  Languages
  Languages.directory
  suse-science-languages.directory
  
Languages
X-KDE-Edu-Language
  


Biology
Biology.directory


  Education
  Biology




Chemistry
Chemistry.directory
suse-education-chemical.directory


  Education
  Chemistry




Physics
  

Re: fvwm-xdg-menu: additonal FreeDesktop categories support

[Thomas Funk]

michel dominique wote:
 On lun. 16/09/13 22:41 , Thomas Funk t.f...@web.de wrote:

 michel dominique wrote:
 Hi,

 I begun to made some work on a xdg menu for fvwm-menu-desktop
 that will provide FreeDesktop additional categories support out of
 the box.

 It will provide /etc/xdg/menus/fvwm-applications.menu and its
 associated files. This is a work in progress, for just it just
 give an idea of what I want to do. A few additional categories
 are already supported, and it will take some time until all are
 incorporated.

 It is a repository on github:
 https://github.com/domichel/fvwm-xdg-menu [1] [1]
 The xfce menu is the wrong one you've started with. It is too
 specific. You have to use an applications.menu. It is more unique.

 I started from xfce applications menu. It is an xdg application menu,
 and as such, it is able to show any applications that have desktop
 files in /usr/share/applications.

Right, but if you haven't installed Xfce no .directory files exist like
Directoryxfce-education.directory/Directory

 The other problem with your menu is that you have .desktop entries.
 A unique menu should work without them.

 These .desktop files in /usr/share/desktop-directories are hare only
 for automatic translations of the category's names and comments.
 The menu work fine without them, exactly like yours, but will be in
 English only.

Most distributions have the main categories as .directory files in
/usr/share/desktop-directories so it is meaningless to create
fvwm-whatever directory entries. Use the xdg defaults. Then you have
translation per default.

 Attached is my first test menu based on Ubuntus applications.menu
 with some parts from openSuse. I have to test it on other
 distributions but on Debian it works fine. Should work on Fedora,
 too because their applications.menu is similar.

 Thank you, it is interesting.

Your welcome :-)

A bare application menu is attached. This was the base of my test
menu. It includes only the main categories. Perhaps this could
be the best start. Fedora have the same but with some Fedora
specific entries.

 Applications place their desktop files into
 /usr/share/applications. If these desktop files are compliant, all
 will be fine on any distribution. If they are not, this only mean
 these desktop files are buggy because they are not non-compliant.
 In gentoo, portage issue warnings about these buggy desktop files.

 But Mageia/Mandriva for example has own directory named files
 besides of the xdg specification, so there is much work to support
 such distributions.

 For me, this is their problem. The xdg specification exist for one
 good reason, to standardize menus. If some xyz distribution make non
 standard extensions to that norm, it is not my problem if they like
 to make extra work. I will not do it for them, but will accept
  patches.

Hmmm ... I don't think, that users accept a menu which has no entries
in it because the distribution they use doesn't use the xdg standard.
I will test it if these extra directory entries needed or not.

 Also, extra categories can be made with a X- prefix. Maybe this is
 for that they write:
 Category-based menu implementations SHOULD therefore provide a
 catch-all submenu for applications that cannot be appropriately
 placed elsewhere.

 In my menu, it is the following at the end:
   Menu
  NameOther/Name
  Directoryxfce-other.directory/Directory
  OnlyUnallocated/
  Include
  All/
  /Include
  /Menu


Ah, ok. That's a good entry. I am not at this point. I've built the
test menu today. So ... ;-)

 I didn't looked at it for now, so this is still the xfce-* Directory
 key. But it work in English with any locale.

 That imply for Fedora and the like, it can be enough to add some
 *Dir* statements at the beginning, and their apps will be matched
 into the relevant categories, and in Other otherwise. If they don't
 like it, they can send patches.


 It is no icon support for the categories at that time, maybe later
 if I find the time. But maybe they are already in fvwm-themes?
 fvwm-menu-desktop supports icons by default.

 I talk about categories icons here, not apps icons.
 Do you mean the Icon keys in the /usr/share/desktop-directories
 desktop files, because it is in these files the categories icons are
 specified, or icons in fvwm ImagePath?

No, fvwm-menu-desktop (from CVS) uses for top menu names the
'gnome-fs-directory' icon and for unknown application
'gnome-applications'. Also it gets the icons in the directory files if
available. if not it uses the folder icon. The choice of gnome icons
is not the best but if you know some others which are available on
each system, tell it to me.

Best,
Thomas

Re: fvwm-xdg-menu: additonal FreeDesktop categories support

[Thomas Funk]

Shit, forgot the file :-(




  Applications
  X-GNOME-Menu-Applications.directory

  
  /etc/X11/applnk
  /usr/share/gnome/apps

  
  
  

  
  

  
  
Accessories
Utility.directory

  
Utility
	
Accessibility
System
  

   

  
  
Universal Access
Utility-Accessibility.directory

  
Accessibility
Settings
  

   

  
  
Development
Development.directory

  
Development
  
  emacs.desktop

   

  
  
Education
Education.directory

  
Education
Science
  

   

  
  
Science
GnomeScience.directory

  
Education
Science
  

   

  
  
Games
Game.directory

  
Game
ActionGame
AdventureGame
ArcadeGame
BoardGame
BlocksGame
CardGame
KidsGame
LogicGame
Simulation
SportsGame
StrategyGame
  


  
  


  Action
  ActionGames.directory
  
ActionGame
  


  Adventure
  AdventureGames.directory
  
AdventureGame
  


  Arcade
  ArcadeGames.directory
  
ArcadeGame
  


  Board
  BoardGames.directory
  
BoardGame
  


  Blocks
  BlocksGames.directory
  
BlocksGame
  


  Cards
  CardGames.directory
  
CardGame
  


  Kids
  KidsGames.directory
  
KidsGame
  


  Logic
  LogicGames.directory
  
LogicGame
  


  Role Playing
  RolePlayingGames.directory
  
RolePlaying
  


  Simulation
  SimulationGames.directory
  
Simulation
  


  Sports
  SportsGames.directory
  
SportsGame
  


  Strategy
  StrategyGames.directory
  
StrategyGame
  

   

  
  
Graphics
Graphics.directory

  
Graphics
  

   

  
  
Internet
Network.directory

  
Network
	
	  X-GNOME-WebApplication
	
  

 

  
  
Web Applications
X-GNOME-WebApplications.directory

  
	Network
	X-GNOME-WebApplication
  

  

  
  
Multimedia
AudioVideo.directory

  
AudioVideo
  

 

  
  
Office
Office.directory

  
Office
  

   

  
  
System
System-Tools.directory

  
System
Settings
	Game
  


  Preferences
  Settings.directory
  

  Settings
  

  System
  X-GNOME-Settings-Panel

  

  


  Administration
  Settings-System.directory
  

  Settings
  System
  
X-GNOME-Settings-Panel
  

  

 

  
  
Other
X-GNOME-Other.directory


  
Core
Screensaver
X-GNOME-Settings-Panel
  

   

   
 
 Other
 
   

  
  
Debian
debian-menu.menu
Debian.directory
  


  ubuntu-software-center.desktop




  
  
  
  ubuntu-software-center.desktop


 

Re: Bugfix for fvwm-menu-desktop if only one XDG menu exist

[Thomas Funk]

On 14/09/2013 15:41, Thomas Funk wrote:
 I found another problem with unicode errors in menu names under
 XUbuntu. I will check this in the next time. So, forget the last
 patch. I will send a new one with the unicode error fix included.

I have now fixed this problem.
The attached patch includes:
- if only one xdg menu exists:
- no output appears with 'fvwm-menu-desktop --get-menus all|desktop'
- No entry Regenerate XDG menu(s) appears with
   'fvwm-menu-desktop --insert-in-menu MenuRoot'

- if an icon not found but the path was given convert errors occur.
  Fixed this with a path check.

- if an converted icon exists the conversion process will be skipped to
  reduce progress time.

- if an DecodeEncodeError occurs in menu/menu entry/file path it will be
  encoded before printing.

- exchanged all Tabs with spaces to prevent indention errors with the
  Python interpreter.

 On sam 14/09/13 19:56 , michel dominique  wrote:
 Until a certain extend. I think many experimented fvwm users will
 install a minimum system, and will not get more than 1 or 2 xdg menus.

 Also, many distributions don't have their own menu system like debian,
 so the chances are big they will get only 1 xdg menu with a minimum
 install.

 It is even worst, on a fresh gentoo install, with only fvwm,
 fvwm-crystal, xorg-server, stalonetray, mc and rxvt-unicode, I get no
 xdg menu file at all.

 On Debian, I experimented a little bit with xfce by modifying its menu
 file in /etc/xdg/menus

 For now, this is just a prove of concept. This have to be extended to
 all the other main categories. Eventually, files can be provided into
 /usr/share/desktop-directories for automatic translation. I commented
 it because otherwise all the sub-menus are named Multimedia, so
 files must be provided if we want to support the Directory tag.

I looked into different applications.menu files and they look mostly the 
same. There're possibilities to implement a skeleton

aplications.menu:
1) this file exists in FVWM and will be copied into /etc/xdg/menus/ e.g.
   as 'fvwm-applications.menu'
2) I implement a function in fvwm-menu-desktop which creates a
   fvwm-applications.menu in /home/user/.config/menus. Also
   fvwm-menu-desktop-config.fpl has to be modified to set a creation
   flag and shows a fake menu until it is created.

I prefer 1) but this is only because the overhead to write a menu from
scratch will blow up fvwm-menu-desktop much (the complete xml file
structure must pictured in code).

What is the best? 1), 2) or ... 3) no fvwm-applications.menu
Feedback, please ^^
--- fvwm-menu-desktop.in	2013-09-12 13:09:49.0 +0200
+++ fvwm-menu-desktop.in.new	2013-09-15 18:05:09.074888400 +0200
@@ -2,6 +2,14 @@
  
 # Modification History
 
+# Changed on 15/09/13 by Thomas Funk:
+# Some Bugfixes:
+# - DecodeEncodeErrors in menu names
+# - no output appears with 'fvwm-menu-desktop --get-menus all|desktop'
+# - No entry Regenerate XDG menu(s) appears with
+#   'fvwm-menu-desktop --insert-in-menu MenuRoot'
+# -  exchange all tabs with spaces to prevent indention errors
+
 # Changed on 15/06/13 by Thomas Funk:
 # support for python-xdg  0.19.
 # add gettext localization.
@@ -114,7 +122,7 @@
 sys.exit(2)
 global verbose, force, size, theme, icon_dir, top, install_prefix, menu_type, menu_list_length 
 global with_titles, menu_entry_count, get_menus, timestamp, set_menus, printmode, insert_in_menu
-version = 2.2
+version = 2.3
 verbose = False
 force = False
 desktop=''
@@ -274,9 +282,9 @@
 vprint(\n DE weighting search: DE = [user menus, system menus, overall])
 weight_dict = {}
 if desktop == '':
-		# first the desktops, then debian (shouldn't appear in others) then others holding
-		# all other non DE menus e.g. tools and at the end the nones without prefixes
-		# If there're other prefixes from other WMs - should be added BEFORE debian
+# first the desktops, then debian (shouldn't appear in others) then others holding
+# all other non DE menus e.g. tools and at the end the nones without prefixes
+# If there're other prefixes from other WMs - should be added BEFORE debian
 DEs = ['gnome', 'kde', 'xfce', 'lxde', 'cinnamon', 'mate', 'debian', 'others', 'none']
 else:
 DEs = [desktop]
@@ -298,9 +306,9 @@
 filled = True
 for name in menu_names:
 menus.add(path+'/'+name)
-# delete each found DE menu from the actual path. So, the menus will be reduced loop by loop.
+# delete each found DE menu from the actual path. So, the menus will be reduced loop by loop.
 menudict[path] = menudict[path]-set(menu_names)
-# count the menus found in the users and systems menu path for later weighting
+# count the menus found in the users and systems menu path for later weighting
 if not path

Re: Bugfix for fvwm-menu-desktop if only one XDG menu exist

[Thomas Funk]

Ouch! in line 144
+printmenu($[gt.Regenerate XDG Menu(s)], 
system-software-update, Module FvwmPerl -l 
fvwm-menu-desktop2-config.fpl )


please delete the '2' in fvwm-menu-desktop2-config

Sorry ...

Am 12.09.2013 13:53, schrieb Thomas Funk:

Hi Dan,

I've found a bug in fvwm-menu-desktop if only one xdg menu exists:
- no output appears with 'fvwm-menu-desktop --get-menus all|desktop'
- No entry Regenerate XDG menu(s) appears with
   'fvwm-menu-desktop --insert-in-menu MenuRoot'

Therefore the output in fvwm-menu-desktop-config.fpl is completely crappy.

Another problem was if an icon not found but the path was given convert
errors occur. Fixed this with a path check.

Also I have exchanged all Tabs with spaces to prevent indention errors
with the Python interpreter.

Attached is the patch for that.

Best,
Thomas

Re: FVWM: Forums and Wiki need new maintainers/homes

[Thomas Funk]

James Griffin wrote:
 !-- On Sat  7.Sep'13 at 22:46:45 BST, Thomas Adam (tho...@fvwm.org), 
wrote:


 Oh well.

 Note that I am not in any way interested in discussing the merits of 
forums
 versus mailing lists and vice versa.  I just want the responsibility 
taken

 away from me completely ASAP.

 You've missed the point. I couldn't give a shit about mailing lists
 and/or forums and which is better. I'm saying there won't be anyone to
 ask questions to, apart from Dan. It seems like the beginning of the end
 of the fvwm2.

It looks like ...

 You said on the OpenBSD mailing list some weeks ago you were the main
 developer for fvwm - so who's going to develop it now?

Dan Espen
Dominik Vogt
...

And a few contributors like me.

One point is that it's hard to come in in this elitist club of
conservatives. If anyone has an idea to change something or extend a
part it comes 'why?', 'That's not needed' or 'FVWM must work with old
distributions'  ... never change a running system ...
Examples:
Gtk1, Groff to Asciidoc, Debian installation, Python, CVS to Git,
FvwmScript extensions.

Another point is if anyone sends something to the mailing list e.g. a
module, no feedback comes back.

The same is with projects like FVWM-Crystal or Fvwm-Nightshade. They
will be ignored - for whatever reason - allthough they show what FVWM
can do and gives a start point for FVWM newbies.

On the other hand is the FVWM community ... it is not that small but
as Thomas Adam said:
'Past cries for someone to use that documentation to improve the man
page has fallen on deaf ears.  No one has done this yet. Patches
welcome.'
Does any patches come? ... No.

 I'm saying there won't be anyone to ask questions to, apart from Dan.
 It seems like the beginning of the end of the fvwm2.
On the mailing list - mostly. But not on the forum.

Best,
Thomas aka TF and main developer of Fvwm-Nightshade

Re: FVWM: Forums and Wiki need new maintainers/homes

[Thomas Funk]

Bert Geens wrote:
 It would be nice if there would be some more knowledgeable
 moderators, my personal use of Fvwm is, to say the least, pretty basic.
I would do it if it's ok ...

Kindly,
Thomas

Re: FVWM: Forums and Wiki need new maintainers/homes

[Thomas Funk]

Hi all,

Thomas Adam wrote:

Hi Dan,

On Thu, Sep 05, 2013 at 09:58:36PM -0400, Dan Espen wrote:

Thomas Adam tho...@fvwm.org writes:


Hi all,

Given my diminishing work on FVWM, I need to think about handing
over the FVWM Forums [1] and the FVWM Wiki [2].  I cannot devote
the time needed for their maintenance, nor do I want to act as a
point of contact for them anymore.


 From my point of view, I'd have no problem with closing them down.
If you could direct users to the mailing lists, that would be a good
thing.


That'd be the simplest solution, yes.  But I'm unclear how many users
of FVWM and the forums would welcome that.  I was always in favour of
closing it down, but it exists _because_ it's what people wanetd, and
still do, from what I can tell.  They're certainly a lot busier than
fvwm@ in terms of questions.

It is not a good idea to close the forum because it is a very good place
to get help and information. And from my point of view it signals that
Fvwm is on the way to it's end ...

I would take a moderators part if this is ok. Perhaps Bert aka
theBlackDragon would help, too ...

About the PhpBB3 maintenance I cannot help with it because I haven't any
experience with that.


The wiki is less important, but there's a lot of documentation which
I feel should make it in to the man pages somewhere if someone is
wanting to do that.

The content could be moved into the documentation site of Fvwm. There're
many parts which are very important about how Fvwm works, e.g. the start
up. The only thing is that the wiki is very confusing and find things
not that easy.

Best,
Thomas


So I can close them all down and keep the data kicking around, yes.
But I am not happy pissing users off in the process, hence the request
for a takeover.

-- Thomas Adam

Re: FVWM: FvwmScript scripts

[Thomas Funk]

2013/8/15 James Griffin j...@kontrol.kode5.net:
 Hi

 I am wondering if -- aside from the scripts that come with distribution
 -- there is a site where other scripts for FvwmScript can be
 obtained/downloaded? Maybe some fellow fvwm users have written some and
 there a repository of some sort available?

 Thanks, Jamie.
You can search in
http://www.fvwmforums.org/phpBB3/viewforum.php?f=7sid=3ea3d579d8ae5d3acffc5345aef8f3eb

or look into some configs
http://www.fvwmforums.org/phpBB3/viewtopic.php?f=39t=1700

or download Sebaros Minimoids under
http://box-look.org/content/show.php/Minimoids?content=137027

For the next release of Fvwm-Nightshade I've created some, too. At the
moment they are standalone. So you can use most of them:
https://github.com/Fvwm-Nightshade/Fvwm-Nightshade/tree/feature_nanomoids/fvwm


Thomas

Re: FVWM: Dynamic Panels to view contents of directories - i.e. Documents

[Thomas Funk]

2013/8/13 James Griffin j...@kontrol.kode5.net

 In my Dock at the bottom of my screen I have some panels to open browsers
 and other stuff. I'd like to have a panel that opens up and lists the
 contents of my Documents directory in my $HOME. Obviously, the contents
 of this directory will change as I add and remove items from it so, the
 panel would need to be able to work in a way that it updates the
 contents when pressed.

 I saw a nice example using FuncFvwmMenuDirectory for a *.jpg folder, on
 the fvwm site, usually used in menus. I do, in fact use
 fvwm-menu-directory in my menu for my documents directory and others too.
 But, I'd like use a similar way to implement this into FvwmButtons
 panels.

 Has anyone done this and able to explain how I might be able to do it?

 Thanks, Jamie.

You can open the menu with a click like

*FvwmButtons: (Title your_text, ActionOnPress, Action (Mouse 1)
`Menu YourFvwmMenu`)

I use this in some FvwmButtons in Fvwm-Nightshade like G2likeTopBar or
VerticalPanel.

Thomas

Re: More complex menu schortvuts

[Thomas Funk]

Dan Espen wrote:
 Dominik Vogt dominik.v...@gmx.de writes:

 Recently I find it annoying that hotkeys in menus can only be
 simple characters because of the menu item syntax, e.g.

   + FvwmConsole ToggleFvwmConsole
 ^^^

 I'd like to extend the hotkey logic so that it also works with
 moulti character key names like f1 and possibly sequences like
 ctrl-shift-space.  The code to allow this whoould be mostly
 there already, so the question of syntax remains.

 One option would be to somehow extend the existing syntax to allow
 longer key sequences, e.g.

   + FvwmConsole (f1) ...

 (resulting in FvwmConsole _f1_), which might break existing
 menus.  ANother option might be to add a separate hotkey menu
 command, e.g.

 Seems to me like the above is the simplest and most intuitive solution.
 I doubt we have a lot of existing menus using ( as a short cut.
 It's not real easy to use a shifted key as a shortcut key.

What about

   + FvwmConsole §{f1} ...

Or is '§' used anywhere in the menu syntax? I think not but I am not sure.
Also the curly brackets looks more intuitively than parentheses (for me).

Thomas

Re: Patches for fvwm-menu-desktop to support py-xdg 0.19 and localization

[Thomas Funk]

2013/6/18 Dominique Michel dominique.mic...@vtxnet.ch

  Gentoo is a source based distribution. That imply portage doesn't
  need tarballs and can also install directly from a code repository.
 
  I made the ebuild it was several months ago, but the ebuild download
  the code from the CVS at its first call, and update it with the last
  code from the CVS with each subsequent call. This is the point of a
  live ebuild:
 - to install a program from its source code repository with the
  last version of the code.
 
  It is scripts in portage for that, called eclass. They can be used
  used by the ebuilds for cvs, git, svn, ..., any kind of repository.
 
  In an overlay like the pro-audio one (the equivalent of multiple
  repositories with the binary based distributions - in gentoo this is
  just an ebuild (scripts) collection), it is a lot of such live
  ebuilds, and the only issue we get with them is, sometime we must
  update them when upstream change their build system or the
  dependencies.
 
  I am sure I have the last code. Last time I ran it for fwvm, I see
  that portage downloaded the last files committed to the CVS. They was
  your last patches from this thread.

Ah, ok I understand. I haven't used Gentoo anytime.


   BTW, I took a lock at the files in /etc/xdg/menus. They
   doesn't
   support the freedesktop additional categories. The
   freedesktop guys are amazing, they write a norm and don't
   respect it. Or I missed something, but the result is the
   generated menus in Fvwm-NightShade only use the main
   categories, which is a mess when you have a lot of apps in
   one category.
 Hmmm, sounds strange to me. I will test it on my Xubuntu VM
 whether this happens there also. On my Mint I have sub
 categories in the menus, so ...
   
I think some distributions can provide their own files
in /etc/xdg/menus, when gentoo policy is generally to not
interfere with what upstream provide. A notable exception to that
is gentoo eudev fork of udev, which is mature now, but that's
another subject...
   
   The easiest  way is to log in into KDE/Gnome/Xfce session and have a
   look in their menus. They build them from /etc/xdg/menus/, too.
 
  I get the same menus than in NightShade. That confirm this is an
  upstream issue and that some distributions improve these menus, and
  others not.
 
  And it is more, a lot of applications are missing. I guess this is why
  kde provide an utility to find and add them into its menu.
 
  As example, I didn't get alsaplayer in any of these menus, when
  alsaplayer do provide, and install, a compliant alsaplayer.desktop
  file.

   
 I just see it is not installed. I must search why.

  In consequence, the whole xdg menu thing is completely broken
  from the root, it have always been, and this have nothing to do with
  fvwm-menu-desktop.

 Well, the additional categories are broken. And this is mess.

Yes, if it so, then it is a big mess :(

Btw. you have listed in a last mail your menu files:
$ ls -R /etc/xdg/menus
/etc/xdg/menus:
applications-merged  kde-information.menu
xfce-applications.menu gnome-applications.menu
lxde-applications.menuxfce-settings-manager.menu
kde-4-applications.menu  lxlauncher-applications.menu

Did you have activated all checkboxes in fvwm-menu-desktop-config.fpl?
Sometimes you find sub menus in menus where you haven't think about.

Cheers,
Thomas

Re: Patches for fvwm-menu-desktop to support py-xdg 0.19 and localization

[Thomas Funk]

Dan Espen wrote:
 Sorry getting reject messages similar to the ones posted.
 These lines:

 --- ../cvs/fvwm/bin/fvwm-menu-desktop-config.fpl.in  2012-07-28 
20:20:30.0 +0200

 +++ fvwm-menu-desktop-config.fpl2013-06-15 17:41:33.654376217 +0200

 What's the .in part?
 How should they read in order to work?
Sorry, my fault ... the .in file is a relict from the problem with rpm
creation (http://www.mail-archive.com/fvwm-workers@fvwm.org/msg02956.html)

Attached is the correct patch against the right fvwm-menu-desktop-config.fpl

Best,
Thomas
--- ../../cvs/fvwm/bin/fvwm-menu-desktop-config.fpl	2012-09-07 23:58:20.271267700 +0200
+++ fvwm-menu-desktop-config.fpl	2013-06-17 00:09:03.015757741 +0200
@@ -4,7 +4,7 @@
 # Dan Espen but inserts the found xdg menus dynamically into the Form
 # before processed.
 # Author: Thomas Funk t.f...@web.de
-# Version: 1.2
+# Version: 1.3
 
 package MenuConfig;
 use File::Basename;
@@ -48,140 +48,153 @@
 
 my $fvwmform_commands = 
 DestroyModuleConfig  ${modname}: *
-*${modname}: Title	\Fvwm Menu Desktop Config\
+*${modname}: Title	\\$[gt.Fvwm Menu Desktop Config]\
 *${modname}: WarpPointer
 *${modname}: Line		center
-*${modname}: Text	\Fvwm Menu Desktop Config\
+*${modname}: Text	\\$[gt.Fvwm Menu Desktop Config]\
 *${modname}: Line
 *${modname}: Separator
 *${modname}: Line		center
-*${modname}: Text		\Multiple Menu\
+*${modname}: Text		\\$[gt.Multiple Menu]\
 *${modname}: Line 		
 ;
 
-foreach my $key (sort( keys %all_menus)) {
-$fvwmform_commands .= 
-*${modname}: Line	left
-*${modname}: Text	\Menus in $key\
-*${modname}: Line	left
-*${modname}: Selection meth multiple
-;
-my $m_count = 0;
-foreach my $count (sort(keys %{$all_menus{$key}})) {
-my @menu = @{$all_menus{$key}{$count}};
-my $newstring = $menu[0] . ' ' x eval($max_length-length($menu[0]));
-$fvwmform_commands .= *${modname}: Choice  $menu[1] $menu[1] $menu[2] \$newstring\
-	;
-	$m_count++;
-	if ($m_count == 3) {
-	$fvwmform_commands .= 
-	*${modname}: Line	left
-	*${modname}: Selection meth multiple
-	;
-	$m_count = 0;
+if (scalar keys %all_menus != 0) {
+	foreach my $key (sort( keys %all_menus)) {
+		$fvwmform_commands .= 
+			*${modname}: Line	left
+			*${modname}: Text	\\$[gt.Menus in]\
+			*${modname}: Text	\ $key\
+			*${modname}: Line	left
+			*${modname}: Selection meth multiple
+		;
+		my $m_count = 0;
+		foreach my $count (sort(keys %{$all_menus{$key}})) {
+			my @menu = @{$all_menus{$key}{$count}};
+			my $newstring = $menu[0] . ' ' x eval($max_length-length($menu[0]));
+			$fvwmform_commands .= *${modname}: Choice  $menu[1] $menu[1] $menu[2] \$newstring\
+			;
+			$m_count++;
+			if ($m_count == 3) {
+$fvwmform_commands .= 
+	*${modname}: Line	left
+	*${modname}: Selection meth multiple
+;
+$m_count = 0;
+			}
+		}
+		$fvwmform_commands .= 
+			*${modname}: Line 	left
+			*${modname}: Text 	\ \
+		;
 	}
-}
-$fvwmform_commands .= 
-*${modname}: Line 	left
-*${modname}: Text 	\ \
-;
+}
+else {
+	$fvwmform_commands .= 
+		*${modname}: Line	center
+		*${modname}: Text\\$[gt.No menus found! Check why from within a terminal with]\
+		*${modname}: Line	center
+		*${modname}: Text\'fvwm-menu-desktop -v'\
+		*${modname}: Line 	left
+		*${modname}: Text 	\ \
+	;
 }
 
 $fvwmform_commands .= 
 *${modname}: Line
 *${modname}: Separator
 *${modname}: Line		center
-*${modname}: Text \General Options\
+*${modname}: Text \\$[gt.General Options]\
 *${modname}: Line
 *${modname}: Line		Left
-*${modname}: Text \Use Icons in Menus?   \
+*${modname}: Text \\$[gt.Use Icons in Menus?   ]\
 *${modname}: SelectionSelItype single
-*${modname}: Choice   IconsOn  IconsOnon  \Yes\
-*${modname}: Choice   IconsOff IconsOff   off \No\
+*${modname}: Choice   IconsOn  IconsOnon  \\$[gt.Yes]\
+*${modname}: Choice   IconsOff IconsOff   off \\$[gt.No]\
 
 *${modname}: Line 	left
-*${modname}: Text 	\Icon size:\
+*${modname}: Text 	\\$[gt.Icon size:]\
 *${modname}: Input 	Size 2 \\
-*${modname}: Text 	\ (in pixels. Default is 24)
+*${modname}: Text 	\\$[gt. (in pixels. Default is 24)]\
 
 *${modname}: Line 	left
-*${modname}: Text 	\Converted Icon directory:  \
+*${modname}: Text 	\\$[gt.Converted Icon directory:  ]\
 *${modname}: Input 	IconDir 25 \~/.fvwm/icons\
-*${modname}: Text 	\ (Directory for converted icons)\
+*${modname}: Text 	\\$[gt. (Directory for converted icons)]\
 
 *${modname}: Line		Left
-*${modname}: Text \Use Titles in Menus?  \
+*${modname}: Text \\$[gt.Use Titles in Menus?  ]\
 *${modname}: SelectionSelItype single
-*${modname}: Choice   TitlesOn  TitlesOnon  \Yes\
-*${modname}: Choice   TitlesOff TitlesOff   off \No\
+*${modname}: Choice   TitlesOn  TitlesOnon  \\$[gt.Yes]\
+*${modname}: Choice   TitlesOff

Re: Patches for fvwm-menu-desktop to support py-xdg 0.19 and localization

[Thomas Funk]

Dominique Michel wrote:
 Portage doesn't give rej file. I used
 patch -p0  fvwm-menu-desktop-config.fpl.gettext.patch
 to get it.
Perhaps Portage isn't up-to-date with CVS?
The reject problem was my fault. See my emailto Dan/fvwm-workers minutes
ago.

 It work know. I removed ~/.fbwm-nightshade. Maybe something get screwed
 when it was not working. The .menu file was existing but was empty.
You had had removing the .menu file only. But anyway removing 
~/.fvwm-nightshade

is also a solution ^^

 BTW, I took a lock at the files in /etc/xdg/menus. They doesn't
 support the freedesktop additional categories. The freedesktop guys are
 amazing, they write a norm and don't respect it. Or I missed something,
 but the result is the generated menus in Fvwm-NightShade only use the
 main categories, which is a mess when you have a lot of apps in one
 category.
Hmmm, sounds strange to me. I will test it on my Xubuntu VM whether this
happens there also. On my Mint I have sub categories in the menus, so ...

Best,
Thomas

Patches for fvwm-menu-desktop to support py-xdg 0.19 and localization

[Thomas Funk]

Hi Dan!

attached are some patches to fix the following:

fvwm-menu-desktop:
- fix problem with python-xdg versions  0.19 (Dominique reported this
  some days ago)
- localization support for gettext - 'Regenerate XDG menu(s)'

fvwm-menu-desktop-config.fpl:
- localization support for gettext
- add query to check if no menus found - message occur

fvwm.pot:
- update to support translations for fvwm-menu-desktop and
  fvwm-menu-desktop-config.fpl

fvwm.de.po:
- update of the German translation

@Dominique:
Would you update the french translation file, please?

@Jesús J. Guerrero Botella:
Is it possible that you would do the translation for the Spanish po?

@all others:
Who has time to update the rest of the pos?
- ar
- ru
- sv_SE
- zh_CN
- zh_TW

Thanks,
Thomas
--- ../cvs/fvwm/po/fvwm.de.po	2012-09-07 23:58:21.019311436 +0200
+++ fvwm.de.po	2013-06-15 20:28:41.297731413 +0200
@@ -1,14 +1,15 @@
 # German translations for fvwm package
-# Copyright (C) 2003 fvwm workers
+# Copyright (C) 2013 fvwm workers
 # This file is distributed under the same license as the fvwm package.
 # Andrei Mitrofanow smile...@web.de, 2003.
+# Thomas Funk t.f...@web.de, 2013
 #
 msgid 
 msgstr 
 Project-Id-Version: fvwm\n
 POT-Creation-Date: 2002-11-28 14:23+0100\n
-PO-Revision-Date: 2002-11-23 06:00+0100\n
-Last-Translator: Andrei Mitrofanow smile...@web.de\n
+PO-Revision-Date: 2013-06-15 20:00+0200\n
+Last-Translator: Thomas Funk t.f...@web.de\n
 Language-Team: German\n
 Language: \n
 MIME-Version: 1.0\n
@@ -318,3 +319,163 @@
 #. ./modules/FvwmForm/FvwmForm-Setup.in: line 55
 msgid Copy Config File(s)
 msgstr Konfigurationsdateien kopieren
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 51
+msgid Fvwm Menu Desktop Config
+msgstr Fvwm Menu Desktop Konfiguration
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 58
+msgid Multiple Menu
+msgstr Mehrfachmenü
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 66
+msgid Menus in
+msgstr Menüs in
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 95
+msgid No menus found! Check why from within a terminal with
+msgstr Keine Menüs gefunden! In einem Terminal checken warum mit
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 107
+msgid General Options
+msgstr Generelle Optionen
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 110
+msgid Use Icons in Menus?   
+msgstr Icons in Menüs?
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 112
+msgid Yes
+msgstr Ja
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 113
+msgid No
+msgstr Nein
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 116
+msgid Icon size:
+msgstr Icongröße: 
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 118
+msgid  (in pixels. Default is 24)
+msgstr  (in Pixel. Default ist 24)
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 121
+msgid Converted Icon directory:  
+msgstr Icon-Verzeichnis:  
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 123
+msgid  (Directory for converted icons)
+msgstr  (für konvertierte Icons)
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 126
+msgid Use Titles in Menus?  
+msgstr Titel in Menüs?
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 132
+msgid Insert Menu(s) in a Menu? 
+msgstr Menü(s) in einem Menü? 
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 136
+msgid Top title name: 
+msgstr Toptitel Name: 
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 140
+msgid Used Icon theme:  
+msgstr Benutzter Icontheme:   
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 142
+msgid  (Theme name for icon selection)
+msgstr  (Themename für Iconauswahl)
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 149
+msgid Single Menu
+msgstr Einzelmenü
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 152
+msgid If you want a single menu only deselect all menus above and fill out
+msgstr Für ein Einzelmenü alle nicht benötigten Menüs deselektieren und die
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 154
+msgid the fields below. But remember, if the menu doesn't exist, nothing happens.
+msgstr Felder unten ausfüllen. Achtung: wenn ein Menü leer ist, passiert nichts.
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 158
+msgid Menu Top Title:
+msgstr Menü Top Titel:
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 147
+msgid  (Eg. FvwmTestMenu)
+msgstr  (z.b. FvwmTestMenu)
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 160
+msgid Install-Prefix:
+msgstr Install-Prefix:
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 165
+msgid  (Eg. /etc/xdg/menus/)
+msgstr  (z.B. /etc/xdg/menus/)
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 168
+msgid Desktop:   
+msgstr Desktop:   
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 170
+msgid  (Eg. gnome, kde, xfce, lxde)
+msgstr  (z.B. gnome, kde, xfce, lxde)
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 173
+msgid Menutype:  
+msgstr Menütyp:   
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 175
+msgid  (Eg. applications, settings)
+msgstr  (z.B. applications

Re: Patches for fvwm-menu-desktop to support py-xdg 0.19 and localization

[Thomas Funk]

Dominique Michel wrote:
 PATCH COMMAND:  patch -p1 -g0 -E --no-backup-if-mismatch  
 
'/var/lib/layman/test/x11-wm/fvwm/files/fvwm-menu-desktop-config.fpl.gettext.patch'


 ==
 checking file bin/fvwm-menu-desktop-config.fpl
 Hunk #2 FAILED at 48.
 Hunk #3 succeeded at 205 (offset 16 lines).
 Hunk #4 FAILED at 225.
 2 out of 4 hunks FAILED

 I included the rej file. It is against the svn of today.
I used your patch command and it worked on my machine with the latest
CVS update. But I copied fvwm-menu-desktop-config.fpl.in together with
the patch into a temp directory:
tf@t61:/media/daten/shared/sourcen/Fvwm/temp$ patch -p1 -g0 -E 
--no-backup-if-mismatch   fvwm-menu-desktop-config.fpl.gettext.patch

can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|--- ../cvs/fvwm/bin/fvwm-menu-desktop-config.fpl.in2012-07-28 
20:20:30.0 +0200

|+++ fvwm-menu-desktop-config.fpl   2013-06-15 17:41:33.654376217 +0200
--
File to patch: ./fvwm-menu-desktop-config.fpl.in
patching file ./fvwm-menu-desktop-config.fpl.in

Also with the simpler command patch -p0:
tf@t61:/media/daten/shared/sourcen/Fvwm/temp$ patch -p0 
fvwm-menu-desktop-config.fpl.in fvwm-menu-desktop-config.fpl.gettext.patch

patching file fvwm-menu-desktop-config.fpl.in

If I diffing my version with the patched one no differences occur on
both patch tries.

 fvwm.pot:
 - update to support translations for fvwm-menu-desktop and
 fvwm-menu-desktop-config.fpl

 fvwm.de.po:
 - update of the German translation

 The other patches are working fine. But I still doesn't get anything
 into Fvwm-Nightshade menu configurator:

 cut: champs et positions sont numérotés à partir de 1
 which mean
 cut: fields and positions are numbered from 1
What does fvwm-menu-desktop -v prints out? Also --version?

I tested the changed fvwm-menu-desktop on Xubuntu 13.04 which
use python-xdg 0.25 and on my Mint LMDE which uses 0.19.

What is your default Python version? Type 'python' in a terminal to
start the interactive python console. It is important that it is 2.x
because fvwm-menu-desktop isn't usable with Python 3.x.

 @Dominique:
 Would you update the french translation file, please?

 It is join.
Thanks :)
Thomas

Re: Patches for fvwm-menu-desktop to support py-xdg 0.19 and localization

[Thomas Funk]

Dominique Michel wrote:
 @Dominique:
 Would you update the french translation file, please?

 It is join.
As it works now can you change your translation to fit the french text
in fvwm-menu-desktop-config.fpl so that is all in the correct places?
Because the spaces behind the text moves the elements like check boxes
and text fields in the correct positions. Perhaps you have to reduce
some text parts a little bit.

For better understanding ... this is the original text:
msgid Use Icons in Menus?   
msgid Icon size:
msgid Converted Icon directory:  
msgid Use Titles in Menus?  
msgid Insert Menu(s) in a Menu? 
msgid Used Icon theme:  

That's your's:
msgstr Utiliser des icônes dans les menus? 
msgstr Taille d'icône :  
msgstr Dossier des icônes:  
msgstr Utiliser des titres dans les menus?  
msgstr Menu(s) dans un menu? 
msgstr Thême d'icônes à utiliser:  

You see that the '' at the end are not in one line. Better
msgstr Utiliser des icônes dans les menus? 
msgstr Taille d'icône :
msgstr Dossier des icônes: 
msgstr Utiliser des titres dans les menus? 
msgstr Menu(s) dans un menu?   
msgstr Thême d'icônes à utiliser:  

Best would be if
msgstr Utiliser des icônes dans les menus? 
msgstr Utiliser des titres dans les menus? 
are smaller to reduce the width of fvwm-menu-desktop-config.fpl

the same is with
msgid Menu Top Title:
msgid Install-Prefix:
msgid Desktop:   
msgid Menutype:  
msgid Output path:   

Thanks,
Thomas

Patches for fvwm-menu-desktop to support py-xdg 0.19 and localization

[Thomas Funk]

Hi Dan!

attached are some patches to fix the following:

fvwm-menu-desktop:
- fix problem with python-xdg versions  0.19 (Dominique reported this
   some days ago)
- localization support for gettext - 'Regenerate XDG menu(s)'

fvwm-menu-desktop-config.fpl:
- localization support for gettext
- add query to check if no menus found - message occur

fvwm.pot:
- update to support translations for fvwm-menu-desktop and
   fvwm-menu-desktop-config.fpl

fvwm.de.po:
- update of the German translation

@Dominique:
Would you update the french translation file, please?

@Jesús J. Guerrero Botella:
Is it possible that you would do the translation for the Spanish po?

@all others:
Who has time to update the rest of the pos?
- ar
- ru
- sv_SE
- zh_CN
- zh_TW

Thanks,
Thomas

--- ../cvs/fvwm/po/fvwm.de.po	2012-09-07 23:58:21.019311436 +0200
+++ fvwm.de.po	2013-06-15 20:28:41.297731413 +0200
@@ -1,14 +1,15 @@
 # German translations for fvwm package
-# Copyright (C) 2003 fvwm workers
+# Copyright (C) 2013 fvwm workers
 # This file is distributed under the same license as the fvwm package.
 # Andrei Mitrofanow smile...@web.de, 2003.
+# Thomas Funk t.f...@web.de, 2013
 #
 msgid 
 msgstr 
 Project-Id-Version: fvwm\n
 POT-Creation-Date: 2002-11-28 14:23+0100\n
-PO-Revision-Date: 2002-11-23 06:00+0100\n
-Last-Translator: Andrei Mitrofanow smile...@web.de\n
+PO-Revision-Date: 2013-06-15 20:00+0200\n
+Last-Translator: Thomas Funk t.f...@web.de\n
 Language-Team: German\n
 Language: \n
 MIME-Version: 1.0\n
@@ -318,3 +319,163 @@
 #. ./modules/FvwmForm/FvwmForm-Setup.in: line 55
 msgid Copy Config File(s)
 msgstr Konfigurationsdateien kopieren
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 51
+msgid Fvwm Menu Desktop Config
+msgstr Fvwm Menu Desktop Konfiguration
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 58
+msgid Multiple Menu
+msgstr Mehrfachmenü
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 66
+msgid Menus in
+msgstr Menüs in
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 95
+msgid No menus found! Check why from within a terminal with
+msgstr Keine Menüs gefunden! In einem Terminal checken warum mit
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 107
+msgid General Options
+msgstr Generelle Optionen
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 110
+msgid Use Icons in Menus?   
+msgstr Icons in Menüs?
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 112
+msgid Yes
+msgstr Ja
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 113
+msgid No
+msgstr Nein
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 116
+msgid Icon size:
+msgstr Icongröße: 
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 118
+msgid  (in pixels. Default is 24)
+msgstr  (in Pixel. Default ist 24)
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 121
+msgid Converted Icon directory:  
+msgstr Icon-Verzeichnis:  
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 123
+msgid  (Directory for converted icons)
+msgstr  (für konvertierte Icons)
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 126
+msgid Use Titles in Menus?  
+msgstr Titel in Menüs?
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 132
+msgid Insert Menu(s) in a Menu? 
+msgstr Menü(s) in einem Menü? 
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 136
+msgid Top title name: 
+msgstr Toptitel Name: 
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 140
+msgid Used Icon theme:  
+msgstr Benutzter Icontheme:   
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 142
+msgid  (Theme name for icon selection)
+msgstr  (Themename für Iconauswahl)
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 149
+msgid Single Menu
+msgstr Einzelmenü
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 152
+msgid If you want a single menu only deselect all menus above and fill out
+msgstr Für ein Einzelmenü alle nicht benötigten Menüs deselektieren und die
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 154
+msgid the fields below. But remember, if the menu doesn't exist, nothing happens.
+msgstr Felder unten ausfüllen. Achtung: wenn ein Menü leer ist, passiert nichts.
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 158
+msgid Menu Top Title:
+msgstr Menü Top Titel:
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 147
+msgid  (Eg. FvwmTestMenu)
+msgstr  (z.b. FvwmTestMenu)
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 160
+msgid Install-Prefix:
+msgstr Install-Prefix:
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 165
+msgid  (Eg. /etc/xdg/menus/)
+msgstr  (z.B. /etc/xdg/menus/)
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 168
+msgid Desktop:   
+msgstr Desktop:   
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 170
+msgid  (Eg. gnome, kde, xfce, lxde)
+msgstr  (z.B. gnome, kde, xfce, lxde)
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 173
+msgid Menutype:  
+msgstr Menütyp:   
+
+#. ./bin/fvwm-menu-desktop-config.fpl.in: line 175
+msgid  (Eg. applications, settings)
+msgstr  (z.B. applications

Re: FVWM: New Fvwm-Nightshade release 0.6.5 is out!

[Thomas Funk]

Hi Dominique,


I think some additional steps are needed in order to make the
applications menu to work.On gentoo, fvwm-menu-desktop is just



installed at the same time than fvwm, but no configuration at all is
made.

It works only with fvwm 2.6.6 and only from CVS. the latest snapshot

is buggy - fvwm-menu-desktop-config.fpl isnt available there. This file 

creates theconfig gui. You can test it within a Fvwm-Console:

Module FvwmPerl -l fvwm-menu-desktop-config.fpl


I think it can be the same issue with most distributions at the
exception of Debian, which have always been talking care of the menu
integration in all wm/dekstops.

I have tested it on several distributions -Fedora, Arch, OpenSuse,

Debian and Ubuntu and on all it works correctly.



If I run fvwm-menu-desktop, it output nothing.
If I run the examples in the man page and try other options, fvwm
tell me they are obsolete.

 fvwm-menu-desktop
 fvwm-menu-desktop --desktop kde-user --enable-mini-icons WARNING:
Argument desktop obsolete. Ignored.
 fvwm-menu-desktop --type gtk WARNING: Argument type obsolete.
Ignored.

Thats right. These are options from the old perl script. Which version is installed?

 fvwm-menu-desktop --version

If it is 2.0 or higher than one thing could be ...

Have a look in /etc/xdg/menus. Are there any .menu files especially applications.menu?

If not than it is clear that no menu appears. These files are mandatory. Without them

nothing happens. Iffvwm-menu-desktop-config.fpl is available and you see no menu

listed at the top of the gui ...



What output comes with this command:

 fvwm-menu-desktop --insert-in-menu menuRoot


Best,

Thomas



--
Two things are infinite: the universe and human stupidity; and Im not sure about the the universe. -- Albert Einstein




Gesendet:Dienstag, 11. Juni 2013 um 14:18 Uhr
Von:Dominique Michel dominique.mic...@vtxnet.ch
An:Thomas Funk t.f...@web.de
Betreff:Re: FVWM: New Fvwm-Nightshade release 0.6.5 is out!

Le Sun, 09 Jun 2013 17:38:02 +0200,
Thomas Funk t.f...@web.de a crit :



Hi,

I try it with the code from the git. I hope it is in sync.

I get the same problem than before with the application menu: it
doesnt exist, all I can do is to launch its configuration script,
which remain desperately empty.

The only error or warning messages I get are:

[FvwmForm-Form][FlocaleGetFontSet]: (9x15bold) Missing font charsets:
ISO8859-2, ISO8859-3, ISO8859-4, ISO8859-5, KOI8-R, ISO8859-7,
ISO8859-9, ISO8859-13, ISO8859-14, ISO8859-15, JISX0208.1983-0,
KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0, ISO10646-1
[FNS-BaseSetup][FlocaleGetFontSet]: (9x15bold) Missing font charsets:
ISO8859-2, ISO8859-3, ISO8859-4, ISO8859-5, KOI8-R, ISO8859-7,
ISO8859-9, ISO8859-13, ISO8859-14, ISO8859-15, JISX0208.1983-0,
KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0, ISO10646-1 ls:
impossible daccder  /home/dom/.fvwm-nightshade/themes/: Aucun
fichier ou dossier de ce type ls: impossible daccder
 /home/dom/.fvwm-nightshade/layouts/: Aucun fichier ou dossier de ce
type

I think some additional steps are needed in order to make the
applications menu to work. On gentoo, fvwm-menu-desktop is just
installed at the same time than fvwm, but no configuration at all is
made.
I think it can be the same issue with most distributions at the
exception of Debian, which have always been talking care of the menu
integration in all wm/dekstops.

If I run fvwm-menu-desktop, it output nothing.
If I run the examples in the man page and try other options, fvwm
tell me they are obsolete.

 fvwm-menu-desktop
 fvwm-menu-desktop --desktop kde-user --enable-mini-icons WARNING:
Argument desktop obsolete. Ignored.
 fvwm-menu-desktop --type gtk WARNING: Argument type obsolete.
Ignored.

Best,
Dominique

--
We have the heroes we deserve.

Re: FVWM: New Fvwm-Nightshade release 0.6.5 is out!

[Thomas Funk]

Dominique Michel wrote:
 $ fvwm-menu-desktop --insert-in-menu menuRoot
 Traceback (most recent call last):
   File /usr/bin/fvwm-menu-desktop, line 556, in module
 main()
   File /usr/bin/fvwm-menu-desktop, line 203, in main
 menulist, desktop_temp = getmenulist(desktop, menu_type)
   File /usr/bin/fvwm-menu-desktop, line 228, in getmenulist
 config_dirs = xdg_config_dirs # xdg_config_dirs is a built-in list
 from python-xdg NameError: global name 'xdg_config_dirs' is not defined
I have guessed it ... you have python-xdg  0.19 installed, right?

I have had the same problem on an Arch test system. There was 0.25
installed. They have changed something but I haven't had the time to
analyze it. I will look over it at the weekend hopefully.

Thanks,
Thomas

FVWM: New Fvwm-Nightshade release 0.6.5 is out!

[Thomas Funk]

This minor release of Fvwm-Nightshade includes the following:

- Localization support for German, French and Spanish
- Tab cycling in both directions with Alt-Tab (forward) and
  Alt-Shift-Tab (backwards)
- Included Python scripts work now with Python 2 and 3
- Many Bugfixes

It's not a big release but it makes 0.6 more stable :-)

It can be downloaded from our website
http://fvwm-nightshade.github.io/Fvwm-Nightshade
or from Box-look.org
http://box-look.org/content/show.php?content=156697

If anyone wants to contribute, we need translations for the following
languages: Russian, Italian and Swedish.

I want to thank all people who helped us. Especially Jesús J. Guerrero
Botella for proofreading of the Spanish translation.

Best,
Thomas Funk
- Fvwm-Nightshade -

Re: FvwmScript, UseGettext and LocalePath

[Thomas Funk]

Dominique Michel wrote:
 Le Sun, 05 May 2013 01:35:32 +0200,
 Thomas Funk t.f...@web.de a écrit :

 It does, but the string in FvwmScript have to be quoted in FvwmScript
 quotes:
 UseGettext
 
{$FVWM_USERDIR/locale;fvwm-crystal:$FVWM_SYSTEMDIR/locale;fvwm-crystal:+}


 Great, that work fine.
You're welcome ^^

 My Font statement was confusing me:

 Fontxft:$[panel_font]:size=16:$[panel_font_style]

 It is  instead of {}. With that, widgets like ItemDraw or CheckBox
 are OK. With all other statements I try, they get shortened and the
 text cam get cut in those widgets.
It is interesting that this works in the header :)

 Another strange font issue is, whatever I try, only the font size is
 applied correctly with that statement, as well with the Font in the
 Init section. But Font changes are applied integrally into in further
 sections.
I accustom oneself to use a temporarily variable for each command I
assigned to GetOutup because then I can see whether the command is correct.
For checking your problem do this:
Set $Cmd = {echo \$[panel_font]}
Do {echo Cmd panel_font: }$Cmd
Set $PanelFont = (GetOutput $Cmd 1 -1)
Set $Cmd = {echo \$[panel_font_size]}
Do {echo Cmd panel_font_size: }$Cmd
Set $PanelFontSize = (GetOutput $Cmd 1 -1)
Set $Cmd = {echo \$[panel_font_style]}
Do {echo Cmd panel_font_style: }$Cmd
Set $PanelFontStyle = (GetOutput $Cmd 1 -1)
Set $SelectorFont = {xft:}$PanelFont{:pixelsize=16:}$PanelFontStyle
Do {echo SelectorFont: }$SelectorFont

So you can see in .xsession-errors if your command looks fine.


 
https://sourceforge.net/p/fvwm-crystal/code/HEAD/tree/fvwm/scripts/FontSelector/FontSelector

A little remark to your script

to reduce code you can use for loops to assign your font to the widgets:
For $Widget=1 To 6 Do
ChangeFont $Widget $SelectorFont
For $Widget=12 To 16 Do
ChangeFont $Widget $SelectorFont
Set $step = 10
Set $Widget = 20
While $step  80 Do
Begin
ChangeFont $Widget $SelectorFont
Set $Widget = (Add $Widget $step)
End
ChangeFont 71 $SelectorFont
ChangeFont 100 $SelectorFont
ChangeFont 101 $SelectorFont
ChangeFont 102 $SelectorFont
ChangeFont 121 $SelectorFont
ChangeFont 122 $SelectorFont

Re: FvwmScript, UseGettext and LocalePath

[Thomas Funk]

Dan Espen wrote:
 Dominique Michel dominique.mic...@vtxnet.ch writes:

 I try to get UseGettext to work with FvwmScript and Fvwm-Crystal.

 From FvwmScript man page:

 UseGettext [locale_path]
 You can reset this catalog or add some catalogs exactly in the same
 way than with the LocalePath fvwm command (see the fvwm manual
 page).

 In Fvwm-Crystal config, one of the first instruction is:

 LocalePath
 
$[FVWM_USERDIR]/locale;fvwm-crystal:$[FVWM_SYSTEMDIR]/locale;fvwm-crystal:+


 If I put exactly the same path in my FvwmScript
 UseGettext
 
$[FVWM_USERDIR]/locale;fvwm-crystal:$[FVWM_SYSTEMDIR]/locale;fvwm-crystal:+


 the script crash with a syntax error at that line:
 UseGettext!
 [/home/dom/.fvwm-crystal/scripts/FontSelector/FontSelector] Line 7:
 syntax error

 The beginning of the script:

 # FvwmScript Font Selector
 # A Font Selector for Fvwm-Crystal
 # Copyright Dominique Michel dominique_li...@users.sourceforge.net
 2013
 # Released under the GNU GPL license v2 or later

 # Header ̣{{{1
 UseGettext
 
$[FVWM_USERDIR]/locale;fvwm-crystal:$[FVWM_SYSTEMDIR]/locale;fvwm-crystal:+

 WindowLocaleTitle {FVWM-Crystal Font Selector}

 Is it something I can do, or is it a bug?

 See my other reply.  I don't think FvwmScript is going to expand
 $[FVWM_SYSTEMDIR].

It does, but the string in FvwmScript have to be quoted in FvwmScript
quotes:
UseGettext 
{$FVWM_USERDIR/locale;fvwm-crystal:$FVWM_SYSTEMDIR/locale;fvwm-crystal:+}


If this doesn't work the problem could be that fvwm-crystal doesn't
export FVWM_USERDIR in the shell, too. It is not enough to set
FVWM_USERDIR in the config. I have had the same problems and fixed it in
the start up script.

For crystal the following should be added in fvwm-crystal startup script:
# Default path
# if a variable 'configfile' is defined in the environment, its value is
# preserved; otherwise, the scripts look for configuration in common places.
configfile=$HOME/fvwm-crystal/$configname
export FVWM_USERDIR=$HOME/fvwm-crystal
export FNS_SYSTEMDIR=`dirname ${0}`/../share/fvwm-crystal

Thomas

Re: FvwmScript, UseGettext and LocalePath

[Thomas Funk]

Ouch! Copy paste typo :S

Thomas Funk wrote:
 It does, but the string in FvwmScript have to be quoted in FvwmScript
 quotes:
 UseGettext 
{$FVWM_USERDIR/locale;fvwm-crystal:$FVWM_SYSTEMDIR/locale;fvwm-crystal:+}

Corrected:
UseGettext 
{$[FVWM_USERDIR]/locale;fvwm-crystal:$[FVWM_SYSTEMDIR]/locale;fvwm-crystal:+}


 If this doesn't work the problem could be that fvwm-crystal doesn't
 export FVWM_USERDIR in the shell, too. It is not enough to set
 FVWM_USERDIR in the config. I have had the same problems and fixed it in
 the start up script.

 For crystal the following should be added in fvwm-crystal startup script:
 # Default path
 # if a variable 'configfile' is defined in the environment, its value is
 # preserved; otherwise, the scripts look for configuration in common 
places.

 configfile=$HOME/fvwm-crystal/$configname
 export FVWM_USERDIR=$HOME/fvwm-crystal
 export FNS_SYSTEMDIR=`dirname ${0}`/../share/fvwm-crystal
And here now that from above:
UseGettext 
{$FVWM_USERDIR/locale;fvwm-crystal:$FVWM_SYSTEMDIR/locale;fvwm-crystal:+}


Sorry,
Thomas

Re: X does not support es_CU.UTF-8 message

[Thomas Funk]

Dominique Michel wrote:
 When I try to open po/fvwm.pot with poedit, it fail with

 09:35:38 AM: /tmp/poeditgUBFPw/0ref.pot:321: duplicate message
 definition... 09:35:38 AM: /tmp/poeditgUBFPw/0ref.pot:36: ...this is
 the location of the first definition 09:35:38 AM: msgmerge: found 1
 fatal error

 gtranslator warm me about this too, but is able to open the file: In
 consequence, I am not sure if the resulting translation file is fully
 usable.
If I open po/fvwm.pot from CVS with poedit directly or via 'New catalog
from Template' no errors occur. My poedit version: 1.4.6

Thomas

Re: FVWM: Anouncement: Fvwm-Nightshade 0.6 released

[Thomas Funk]

Tom Horsley wrote:
 I'll never use it, but I have nothing against it as long as
 you never make me change my own config file.
It never ever change any own config because it has its own folder
~/.fvwm-nightshade ^^
and if you use a graphical login manager you have an own entry for it.
So, you can use it parallel with your existing config :-)

 The most spectacularly useful thing about fvwm is that
 I can copy my own config from one fedora release to another
 and I always see the same interface which I know how to use.
 No learning how the heck to use all the improvements that
 gnome, kde, et. al. always want to foist on me :-).
Yeah, that's right ^^ 5 stars for Fvwm !!!

Re: FVWM: Meaning of the right-hand field of the popup window list

[Thomas Funk]

 Can anybody explain the meaning of the numbers of the last field.

http://www.fvwm.org/doc/unstable/commands/WindowList.html

The format of the geometry part is: desk(layer): x-geometry sticky,
where desk and layer are the corresponding numbers and sticky is empty
or a capital S. The geometry of iconified windows is shown in
parentheses.

Hope this helps.

Regards,
Thomas

Re: FVWM: check for perl in configure

[Thomas Funk]

Dan Espen wrote:
 Sorry.  Try:

 ftp://ftp.fvwm.org/pub/fvwm/devel/snapshots/fvwm-snap-20121011.tar.gz

 Can't say when I'll create a release.  One of these days...

Unfortunately bin/fvwm-menu-desktop-config.fpl is missing in the
snapshot. I stumbled over that yesterday as I tried to installing it.
So, CVS have to be used until it is fixed :(

Thomas F.

Re: FVWM: Where can I find a document that explains the entries in fvwm2rc

[Thomas Funk]

Roger Campbell wrote:
I can figure out mouse buttons and the actions that will take place. What does 
the R and A stand for?

snippet from my config:

+--+
| || || || |
|  |
+--+
# 1  2  3


R = Root Window 
W = Application Window 
F = Frame Corners 
S = Frame Sides 
T = Title Bar 
I = Icon 
Numbers are buttons: 1 3 5 7 9   0 8 6 4 2

rr
rIFSFr
rrS13642Sr
rISwSr
rrSwSr
rIFSFr
rr

Modifiers: (A)ny, (C)ontrol, (S)hift, (M)eta, (N)othing


Structure of a binding line:
Button  Context Modifi  Function
Mouse 1 F   A   FuncFvwmResizeOrRaise

Hope this helps.
Regards,
Thomas

--
Two things are infinite: the universe and human stupidity; and I'm not sure 
about the the universe. -- Albert Einstein

Re: FVWM: Where can I find a document that explains the entries in fvwm2rc

[Thomas Funk]

Dan Espen wrote:

The document that explains all this is the man page.

That's right but it's a very handy and compact overview ;)

--
Two things are infinite: the universe and human stupidity; and I'm not sure 
about the the universe. -- Albert Einstein

Re: FVWM: $[page.nx] etc. not functioning

[Thomas Funk]

msib...@crosswire.com wrote:
 Howdy,

 I have a 3x3 DeskTop

 # .fvwmconfig
 Key F8 A A Exec xmessage $[desk.n] $[page.nx] $[page.ny] $[w.id]

 I hit f8 while focused in a window in the bottom right page

 # xmessage output
 0 0 0 0x142

 I should get:
 0 2 2 -x142

 Am I correct?

On which page you are?

From your xmessage output your window is here
   |
   v
+-+-+-+
| 0/0 | 1/0 | 2/0 |
+-+-+-+
| 0/1 | 1/1 | 2/1 |   desk 0
+-+-+-+
| 0/2 | 1/2 | 2/2 |
+-+-+-+
   ^
   |
What you want is here. Are your window here?


Thomas

Re: FVWM: Does fvwm2 depend on other window managers?

[Thomas Funk]

Roger Campbell wrote:
 I was having trouble with fvwm2 so I rebuilt the system with no
 window manger. I then used yum to install fvwm2.

 Now I am having trouble starting fwmw.

 Do I need kde or some other window manager?

 Thank you for your time.

 Roger

Have you installed a graphical login screen like xdm, gdm, kdm?

If not:
- create a ~/.xinitrc and add 'exec fvwm'
- type in the console 'startx'

If:
- add in /usr/share/xsessions a fvwm.desktop file with the following
  content:
[Desktop Entry]
Encoding=UTF-8
Name=FVWM
Comment=ICCCM-compliant multiple virtual desktop window manager
Exec=fvwm
Terminal=False

See also http://en.gentoo-wiki.com/wiki/FVWM

Other good site:
https://wiki.archlinux.org/index.php/FVWM


Cheers,
Thomas

Re: FVWM: Stepping down from next year.

[Thomas Funk]

Thomas Adam wrote:
 I'd hoped to do more on this, but cannot.  I really now do not have
 sufficient time to devote to this project.

 I will be around if you need me for general questions, etc., a lurker
 if you will, but I cannot guarantee or promise an active role in
 FVWM's development, and I wouldn't want anyone here to rely on that
 possibility.  So until/if that changes, consider me idle.

 As far as 2.6.5's release goes, that too will have to be handled by
 someone else.

 The Wiki and FvwmForums I shall keep ticking over for everyone to enjoy.

 I want to thank everyone for their efforts and help over the years.
 I've enjoyed it.  :)

 Bye bye...

 -- Thomas Adam

It's too bad that you leave the project :( ... at least you're in the
background, so perhaps, in the future, you'll find time to come back ...
would be fine ...

I wish you all the best and ... what can I say more than thank you very
much for all your help and pretty good work over the years ...

Respectfully,

Thomas

Some questions about future developing

[Thomas Funk]

Hi Thomas,

as you leave the project (sadly) as the maintainer and main developer
next to Dan, what happens now with the following points:
- document conversion from groff to asciidoc?
- release 2.6.6?
- switching from cvs to git?

Is there room for hope that you're willing to help to bring this to
a successful end?

Thanks,
Thomas

Re: Patch for fvwm-menu-desktop to fix UnicodeDecodeError

[Thomas Funk]

Dan Espen wrote:
 Sorry this escaped my attention.

 The patch above intercepts a failure in printtext which does this:

 def printtext(text):
 print text.encode(utf-8)

 So if I understand the patch, it intercepts one failure to do utf-8
 encoding and tries using iso-8859-15 instead.

 Why is only that call to printtext subject to this failure?

Because wine applications create desktop files with another codepage
than linux apps do. The best solution was to decode the strings with
iso-8859-15 because this codepage has the most special characters as
all other codepages.


 Don't other calls to printtext using menu names share this problem?

No.


 Just wondering if it makes more sense to put the logic in printtext.

That was my first thought but the error occurs while calling printtext.
printtext expects unicode compliant strings (chars below ascii 127).
Perhaps we could made a decode function which brings the strings in the
correct format before sending to printtext. but only the wrong formated
strings need this function others not. The solution above was the smallest.


 How about just printing the text without encoding it, if encoding fails?

Doesn't work because print wants strings without signs above ascii 127 also.
See 
http://blog.codekills.net/2008/05/01/encoding-and-decoding-text-in-python-%28or---i-didn%27t-ask-you-to-use-the-%27ascii%27-codec!-%29/

again.


Thomas

Re: Patch for fvwm-menu-desktop to fix UnicodeDecodeError

[Thomas Funk]

Hi Dan!

have you got this email below? If so, what do you think?

To state the problem more precisely:

This issue happens if wine is installed on the system and also some
apps. The command entries have often signs over ascii 127 if the
user lives outside England or United States. Therefore I think it
is important to implement this fix ...

Thanks,
Thomas

Thomas Funk wrote:
 Hi Dan,

 sorry, but I have another patch for fvwm-menu-desktop again ...

 On a system with wine the following error occur:
 Traceback (most recent call last):
   File ./fvwm-menu-desktop.in.py, line 536, in module
 main()
   File ./fvwm-menu-desktop.in.py, line 213, in main
 parsemenus(menulist, desktop)
   File ./fvwm-menu-desktop.in.py, line 429, in parsemenus
 parsemenu(xdg.Menu.parse(menu), name, title)
   File ./fvwm-menu-desktop.in.py, line 502, in parsemenu
 parsemenu(entry)
   File ./fvwm-menu-desktop.in.py, line 486, in parsemenu
 printmenu(desktop.getName(), desktop.getIcon(), Exec exec  +  
 + execProgram)

   File ./fvwm-menu-desktop.in.py, line 407, in printmenu
 printtext('+ %s%s %s' % (name, iconfile, command))
 UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 
154: ordinal not in range(128)


 This happens because the text will be decoded to utf-8 but there's a sign
 over ascii 127 like ä,ö,ü ... so it fails.

 The fix is to encode it to unicode and then decode it with iso-8859-15
 to the correct string.

 About this problem see
 
http://blog.codekills.net/2008/05/01/encoding-and-decoding-text-in-python-%28or---i-didn%27t-ask-you-to-use-the-%27ascii%27-codec!-%29/

Patches for fvwm-menu-desktop to support other mini icon directory

[Thomas Funk]

Hi Dan,

attached are 3 patches to enable support for changing the hard coded
icon directory (~/.fvwm/icons).

Patches for:
fvwm-menu-desktop: add option --mini-icon-dir
fvwm-menu-desktop.1: add description for new option in manpage
fvwm-menu-desktop-config.fpl: add possibility to change the directory.
Also 2 new desktops in the weighting list: cinnamon and mate
These 2 desktops have own menus in new LinuxMint and without them in the
list they will added as others to the menu list and get a check mark.

Why the new option --mini-icon-dir:
because fvwm-crystal for example has its own home diretory
(~/.fvwm-crystal). If no ~/.fvwm folder exist fvwm-menu-desktop can't
create the icons. So no icons appear in the menus.

Hope you would apply these patches before release 2.6.6. Would be great.

thanks,
Thomas
--- fvwm-menu-desktop.in.orig	2012-09-01 15:39:01.300694794 +0200
+++ fvwm-menu-desktop.in.py	2012-09-01 15:39:25.284998706 +0200
@@ -98,7 +98,7 @@
 opts, args = getopt.getopt(sys.argv[1:], hs:t:vw,
[help, verbose, enable-mini-icons, with-titles, version,
 desktop=, size=, theme=, install-prefix=, menu-type=,
-title=, get-menus=, set-menus=, insert-in-menu=]+obs_args+equaled_obs_parms)
+title=, get-menus=, set-menus=, insert-in-menu=, mini-icon-dir=]+obs_args+equaled_obs_parms)
 except getopt.GetoptError, err:
 # print help information and exit:
 print str(err) # will print something like option -a not recognized
@@ -106,7 +106,7 @@
 sys.exit(2)
 global verbose, force, size, theme, icon_dir, top, install_prefix, menu_type, menu_list_length 
 global with_titles, menu_entry_count, get_menus, timestamp, set_menus, printmode, insert_in_menu
-version = 2.0
+version = 2.1
 verbose = False
 force = False
 desktop=''
@@ -152,6 +152,8 @@
 sys.exit(1)
 elif o in (-s,--size) :
 size = int(a)
+elif o in (--mini-icon-dir) :
+icon_dir = a
 elif o in (--set-menus) :
 if a[-1] == ' ':
 a = a[:-1]
@@ -267,7 +269,7 @@
 		# first the desktops, then debian (shouldn't appear in others) then others holding
 		# all other non DE menus e.g. tools and at the end the nones without prefixes
 		# If there're other prefixes from other WMs - should be added BEFORE debian
-DEs = ['gnome', 'kde', 'xfce', 'lxde', 'debian', 'others', 'none']
+DEs = ['gnome', 'kde', 'xfce', 'lxde', 'cinnamon', 'mate', 'debian', 'others', 'none']
 else:
 DEs = [desktop]
 for de in DEs:
@@ -522,6 +524,7 @@
 -w, --with-titles generate menus with titles.
 --enable-mini-icons   enable mini-icons in menu
 -s, --size NUMset size of mini-icons in menu. Default is 24.
+--mini-icon-dir   set directory for mini-icons. Default is ~/.fvwm/icons.
 -t, --title NAME  menu title of the top menu used by Popup command.
   Default is FvwmMenu
 --insert-in-menu NAME generates a menu to place it in the root level of the

--- fvwm-menu-desktop.1.in.orig	2012-09-01 15:42:01.515020792 +0200
+++ fvwm-menu-desktop.1	2012-09-01 15:43:49.324455203 +0200
@@ -30,6 +30,7 @@
 [ \fB\-\-with\-titles\fR|\fB\-w\fR ]
 [ \fB\-\-enable\-mini\-icons\fR ]
 [ \fB\-\-size\fR|\fB\-s\fR \fINUM\fR ]
+[ \fB\-\-mini\-icon\-dir\fR|\fB\-t\fR \fIDIR\fR ]
 [ \fB\-\-title\fR|\fB\-t\fR \fINAME\fR ]
 [ \fB\-\-insert\-in\-menu\fR \fINAME\fR ]
 [ \fB\-\-get\-menus\fR \fIall\fR|\fIdesktop\fR ]
@@ -117,8 +118,9 @@
 .IP \fB\-\-enable\-mini\-icons\fR
 This option enables mini\-icons in the menus. If set, 24x24 mini-icons
 are used. If the specified icon isn't that size it will be converted
-if \fBImageMagick\fR is installed and saved in $HOME/.fvwm/icons.
-Otherwise no icon appears in the menu for that entry.
+if \fBImageMagick\fR is installed and saved in $HOME/.fvwm/icons or to
+the folder specified with \-\-mini\-icon\-dir option. Otherwise no icon
+appears in the menu for that entry.
 With most distributions, all the menu entries will have mini-icons
 appropriate to the application.
 
@@ -126,6 +128,9 @@
 If \-\-enable\-mini\-icons is used the \fIsize\fR of the icons can
 changed with this parameter. Default is 24.
 
+.IP \fB\-\-mini\-icon\-dir\fR \fIDIR\fR
+fvwm-menu-desktop converts icons to $HOME/.fvwm/icons. If another target
+is needed use this option.
 
 .SH USAGE
 Without any parameters \fBfvwm-menu-desktop\fR creates a menu named

--- fvwm-menu-desktop-config.fpl.orig	2012-09-01 15:45:03.461458185 +0200
+++ fvwm-menu-desktop-config.fpl	2012-09-01 15:13:17.098547278 +0200
@@ -100,6 +100,11 @@
 *${modname}: Input 	Size 2 \\
 *${modname}: Text 	\ (in pixels. Default is 24)
 
+*${modname}: Line 	left
+*${modname}: Text 	\Used Icon directory:  \

Re: Desktop changes

[Thomas Funk]

2012/7/29 Dan Espen des...@verizon.net:
 I don't think we need a save settings and generate entry.
 I'd like to just click on an okay button, have it save, update,
 and exit the form.
I've split it because if you've more than one menu file (I mean e.g. one
multiple menu and two single menus) than it's annoying if the tool closing
itself every time.

Ok, save settings not needed (It would be only interesting if the Form
can handle different save files but doesn't). Can be combined with the
generate.

 Anyway, thought you guys might get a laugh out of my form default colorsets:
 http://tinypic.com/view.php?pic=21oops1s=6
:D ... looking too long on it get dimly ^^

Re: First try of fvwm-menu-desktop which creates a full menu

[Thomas Funk]

Hi Dan,

attached is a small improvement patch for fvwm-menu-desktop.in. It
changing the top menu entries to better looking titles.
Before:

DestroyMenu FvwmMenu
AddToMenu FvwmMenu FvwmMenu Title
+ Kde4-applications Popup FvwmKde4-applications
+ Preferences Popup FvwmPreferences
+ Settings Popup FvwmSettings
+ Start-here Popup FvwmStart-here
+ System-settings Popup FvwmSystem-settings

after:
DestroyMenu FvwmMenu
AddToMenu FvwmMenu FvwmMenu Title
+ Kde4 Applications Popup FvwmKde4 Applications
+ Preferences Popup FvwmPreferences
+ Settings Popup FvwmSettings
+ Start Here Popup FvwmStart Here
+ System Settings Popup FvwmSystem Settings


Thomas

--- /media/daten/shared/sourcen/cvs/fvwm/bin/fvwm-menu-desktop.in	2012-07-23 18:32:18.108252482 +0200
+++ fvwm-menu-desktop.in.py	2012-07-27 11:10:16.720543498 +0200
@@ -415,8 +415,10 @@
 # create a top title list
 top_titles = []
 for file in menulist:
-name = file.replace('.menu', '').split('/')
-top_titles.append(name[-1][0].upper()+name[-1][1:])
+# extract and split the filename and set first char of each word to capital
+name_parts = file.replace('.menu', '').split('/')[-1].split('-')
+name_parts = [name[0].replace(name[0], name[0].upper())+name[1:] for name in name_parts]
+top_titles.append(' '.join(name_parts))
 
 # create the submenus
 new_toptitles = []

Re: First try of fvwm-menu-desktop which creates a full menu

[Thomas Funk]

2012/7/23 Dan Espen des...@verizon.net:
 I don't understand.
 If you do this:

  + I Test (f  $[FVWM_USERDIR]/.menu) Read $[FVWM_USERDIR]/.menu
  + I TestRC (!Match) PipeRead 'fvwm-menu-desktop --insert-in-menu MenuRoot \\
 $[FVWM_USERDIR]/.menu \\
 +   echo Read $[FVWM_USERDIR]/.menu'

 Then the menu only gets regenerated when the file
 $[FVWM_USERDIR]/.menu goes away.

 I don't see how that helps at all.
This is not the important part. With

AddToMenu MenuRoot Root Menu Title
+ FuncXdgMenusInRoot

you must restart because the root menu and the entry + FuncXdgMenusInRoot
generates a static menu. But if you use a dynamic root menu like this:
AddToMenu MenuRoot DynamicPopupAction FuncMenuRoot

DestroyFunc FuncMenuRoot
AddToFunc FuncMenuRoot
+ I DestroyMenu MenuRoot
+ I AddToMenu MenuRoot DynamicPopupAction FuncMenuRoot
+ I AddToMenu MenuRoot Root Menu Title
+ I Popup XdgMenus

and also a dynamic XdgMenus menu:

AddToMenu XdgMenus DynamicPopupAction FuncXdgMenusInRoot

DestroyFunc FuncXdgMenusInRoot
AddToFunc FuncXdgMenusInRoot
+ I DestroyMenu XdgMenus
+ I AddToMenu XdgMenus DynamicPopupAction FuncXdgMenusInRoot

then you can execute Regenerate menus without a restart. The trick is,
that Regenerate menus does a Read after execution of fvwm-menu-desktop.
so the new generated menu is instantly available if the user pops up the
root menu.

The two Test lines are only to guarantee that a .menu is red and if not
exist generated and red while poping up the root menu.

I gave a thought at night to the patch and discovered that the example with
+ FuncXdgMenusInRoot should be deleted because it shows a way the
user doesn't use anymore if he read the example below. Or should we let
it for the sake of completness?

Thomas

Re: First try of fvwm-menu-desktop which creates a full menu

[Thomas Funk]

Dan Espen des...@verizon.net wrote
Using --insert-in-menu MyMenu, I get this:

AddToMenu MyMenu
+ Kde4-applications Popup FvwmKde4-applications
+ Preferences Popup FvwmPreferences
+ Settings Popup FvwmSettings
+ Start-here Popup FvwmStart-here
+ System-settings Popup FvwmSystem-settings
+  Nop
+ Regenerate XDG Menu(s) Module FvwmPerl -l fvwm-menu-desktop-config.fpl

If I run this twice, MyMenu will have all these entries appended to
MyMenu twice. I'd have to destroy the menu and recreate it to get any
other outcome.
Can you post how you've implemented it in the MyMenu? If you've deleted
+ I DestroyMenu XdgMenus
because of my last email to Thomas then do it back. I have problems on my
VM with creating menus and must check this first. On my Debian system at
home all works fine with the new snippet.

Thomas

Re: First try of fvwm-menu-desktop which creates a full menu

[Thomas Funk]

Dan Espen des...@verizon.net wrote:
 Thomas Funk t.funk...@googlemail.com writes:

 Dan Espen des...@verizon.net wrote
 Using --insert-in-menu MyMenu, I get this:

 AddToMenu MyMenu
 + Kde4-applications Popup FvwmKde4-applications
 + Preferences Popup FvwmPreferences
 + Settings Popup FvwmSettings
 + Start-here Popup FvwmStart-here
 + System-settings Popup FvwmSystem-settings
 +  Nop
 + Regenerate XDG Menu(s) Module FvwmPerl -l 
fvwm-menu-desktop-config.fpl


 If I run this twice, MyMenu will have all these entries appended to
 MyMenu twice. I'd have to destroy the menu and recreate it to get any
 other outcome.
 Can you post how you've implemented it in the MyMenu? If you've deleted
 + I DestroyMenu XdgMenus
 because of my last email to Thomas then do it back. I have problems 
on my

 VM with creating menus and must check this first. On my Debian system at
 home all works fine with the new snippet.
 I typed in the command:

 python fvwm-menu-desktop.in --insert-in-menu MyMenu

 I then searched the output for MyMenu.
 The lines above are the only references to MyMenu.

 If I paste the lines above into FvwmTalk twice
 and then enter PopUp MyMenu
 I see a menu with all it's entries duplicated.

Yes, that's correct cause no DestroyMenu MyMenu exists in the generated
menu. But that has to be. If you have a static/normal menu called
MyMenu then you create it like this in .config:

DestroyMenu MyMenu
AddToMenu   MyMenu
+ A_Title Title
+ Entry1 FuncSomething
+ Entry2 Popup SomeMenu

If you want to add something to MyMenu you do it like
AddToMenu MyMenu
+ Another_Entry1 Popup SomeOtherMenu
+ Another_App Exec exec foo

If you add this part again like you do with FvwmTalk you've duplicated
entries.

But if you use the dynamic example all works fine. I've added the patch
again but without + I DestroyMenu XdgMenus in FuncXdgMenusInRoot as
Thomas pointed out. Thanks Thomas :-)

Also a fixed fvwm-menu-desktop-config.fpl because there were some
missing double quotes (I don't know why they were absent ... shit happens)

Thomas




--- /media/daten/shared/sourcen/cvs/fvwm/bin/fvwm-menu-desktop.1.in	2012-07-22 12:25:57.772773990 +0200
+++ fvwm-menu-desktop.1	2012-07-23 22:31:40.817613594 +0200
@@ -86,9 +86,10 @@
 .IP \fB\-\-insert\-in\-menu\fR \fINAME\fR
 Option to insert generated menu(s) \fBIN\fR a menu \fINAME\fR (its
 top title).  Note that this 0ption does not work correctly with the
-Regnerate Menus menu entry since items insserted into a menu cannot be
-removed (currently).  If you use this option and want to update your menus,
-restart fvwm.
+Regnerate Menus menu entry in a normal built menu since items insserted 
+into such a menu cannot be removed (currently). If you use this option
+there and want to update your menus, you have to restart fvwm. A better
+way is to use dynamic menus (see the example in the USAGE section).
 
 .IP \fB\-\-get\-menus\fR \fIall\fR|\fIdesktop\fR
 Prints a space separated list of full menu paths. \fIall\fR is all menus
@@ -213,7 +214,8 @@
 .EE
 .RE
 
-or if you want to show the menus directly in the Root menu use this:
+or if you want to show the menus directly in a normal Root menu use
+this:
 
 .RS
 .EX
@@ -226,6 +228,32 @@
 + I Test (f  $[FVWM_USERDIR]/.menu) Read $[FVWM_USERDIR]/.menu
 + I TestRC (!Match) PipeRead 'fvwm-menu-desktop --insert-in-menu MenuRoot \\
$[FVWM_USERDIR]/.menu \\
+   echo Read $[FVWM_USERDIR]/.menu'
+.EE
+.RE
+
+The problem here is, that you have to restart fvwm because items insserted 
+into such a menu cannot be removed. For that BOTH menus must be dynamically:
+
+.RS
+.EX
+AddToMenu MenuRoot DynamicPopupAction FuncMenuRoot
+
+DestroyFunc FuncMenuRoot
+AddToFunc FuncMenuRoot
++ I DestroyMenu MenuRoot
++ I AddToMenu MenuRoot DynamicPopupAction FuncMenuRoot
++ I AddToMenu MenuRoot Root Menu Title
++ I Popup XdgMenus
+
+AddToMenu XdgMenus DynamicPopupAction FuncXdgMenusInRoot
+
+DestroyFunc FuncXdgMenusInRoot
+AddToFunc FuncXdgMenusInRoot
++ I AddToMenu XdgMenus DynamicPopupAction FuncXdgMenusInRoot
++ I Test (f  $[FVWM_USERDIR]/.menu) Read $[FVWM_USERDIR]/.menu
++ I TestRC (!Match) PipeRead 'fvwm-menu-desktop --insert-in-menu MenuRoot \\
+   $[FVWM_USERDIR]/.menu \\
echo Read $[FVWM_USERDIR]/.menu'
 .EE
 .RE
# This script generates a FvwmForm similar to the FvwmForm-Desktop by
# Dan Espen but insert the found xdg menus dynamically into the Form
# before processed.
# Author: Thomas Funk t.f...@web.de
# Version: 1.2

package MenuConfig;
use File::Basename;
use strict;
use warnings;

#open(MSG ,[path]/log.txt) || die Error $!;

my $all = `fvwm-menu-desktop --get-menus all`;
my $selected = `fvwm-menu-desktop --get-menus desktop`;

my @all_filelist = split(/ /,$all);
my @selected_filelist = split(/ /,$selected);

my %all_menus = ();
my %selected__menus = ();
my $max_length = 0;
foreach my $path (@selected_filelist) {
my ($filename

Re: First try of fvwm-menu-desktop which creates a full menu

[Thomas Funk]

Dan Espen des...@verizon.net wrote:
 Nice.  Regarding this section:

 \ .SH ERRORS AND WARNINGS
 \ \fBfvwm-menu-desktop\fR prints errors and warnings to STDERR. So these
 \ messages could be redirect to e.g. ~/.xsessions-errors:

 \ .RS
 \ .EX
 \ fvwm-menu-desktop  $FVWM_USERDIR/.menu 2 ~/.xsession-errors
 \ .EE
 \ .RE

 Everything I run under fvwm already redirects to ~/.xsession-errors.
 (I send it somewhere else, but same idea.)

 Point is, isn't all error output, from everything under Fvwm already
 going to an error file?
 I don't think we need that section.
No problem. As I see you've commented this part out already.

Btw. you've wrote in --insert-in-menu NAME:
... Note that this 0ption does not work correctly with the Regnerate
Menus menu entry since items insserted into a menu cannot be removed
(currently). If you use this option and want to update your menus,
restart fvwm.

This applies only for normal menus. If you use for both DynamicPopupAction
fvwm must not restarted. I've wrote the additions for the manpage in the
attached patch.

Thomas

--- /media/daten/shared/sourcen/cvs/fvwm/bin/fvwm-menu-desktop.1.in	2012-07-22 12:25:57.772773990 +0200
+++ fvwm-menu-desktop.1	2012-07-23 00:51:00.611988135 +0200
@@ -86,9 +86,10 @@
 .IP \fB\-\-insert\-in\-menu\fR \fINAME\fR
 Option to insert generated menu(s) \fBIN\fR a menu \fINAME\fR (its
 top title).  Note that this 0ption does not work correctly with the
-Regnerate Menus menu entry since items insserted into a menu cannot be
-removed (currently).  If you use this option and want to update your menus,
-restart fvwm.
+Regnerate Menus menu entry in a normal built menu since items insserted 
+into such a menu cannot be removed (currently). If you use this option
+there and want to update your menus, you have to restart fvwm. The only
+way is to use dynamic menus (see the example in the USAGE section).
 
 .IP \fB\-\-get\-menus\fR \fIall\fR|\fIdesktop\fR
 Prints a space separated list of full menu paths. \fIall\fR is all menus
@@ -213,7 +214,8 @@
 .EE
 .RE
 
-or if you want to show the menus directly in the Root menu use this:
+or if you want to show the menus directly in a normal Root menu use
+this:
 
 .RS
 .EX
@@ -226,6 +228,33 @@
 + I Test (f  $[FVWM_USERDIR]/.menu) Read $[FVWM_USERDIR]/.menu
 + I TestRC (!Match) PipeRead 'fvwm-menu-desktop --insert-in-menu MenuRoot \\
$[FVWM_USERDIR]/.menu \\
+   echo Read $[FVWM_USERDIR]/.menu'
+.EE
+.RE
+
+The problem here is, that you have to restart fvwm because items insserted 
+into such a menu cannot be removed. For that BOTH menus must be dynamically:
+
+.RS
+.EX
+AddToMenu MenuRoot DynamicPopupAction FuncMenuRoot
+
+DestroyFunc FuncMenuRoot
+AddToFunc FuncMenuRoot
++ I DestroyMenu MenuRoot
++ I AddToMenu MenuRoot DynamicPopupAction FuncMenuRoot
++ I AddToMenu MenuRoot Root Menu Title
++ I Popup XdgMenus
+
+AddToMenu XdgMenus DynamicPopupAction FuncXdgMenusInRoot
+
+DestroyFunc FuncXdgMenusInRoot
+AddToFunc FuncXdgMenusInRoot
++ I DestroyMenu XdgMenus
++ I AddToMenu XdgMenus DynamicPopupAction FuncXdgMenusInRoot
++ I Test (f  $[FVWM_USERDIR]/.menu) Read $[FVWM_USERDIR]/.menu
++ I TestRC (!Match) PipeRead 'fvwm-menu-desktop --insert-in-menu MenuRoot \\
+   $[FVWM_USERDIR]/.menu \\
echo Read $[FVWM_USERDIR]/.menu'
 .EE
 .RE

Re: First try of fvwm-menu-desktop which creates a full menu

[Thomas Funk]

Dan Espen des...@verizon.net wrote:
 Haven't you been doing CVS updates?
Sorry, used fvwm-menu-desktop.1 instead of fvwm-menu-desktop.1.in
Correct patch attached.

Thomas
--- /media/daten/shared/sourcen/cvs/fvwm/bin/fvwm-menu-desktop.1.in	2012-07-11 16:45:31.0 +0200
+++ fvwm-menu-desktop.1	2012-07-21 12:18:11.617683854 +0200
@@ -20,88 +20,86 @@
 fvwm-menu-desktop \- Reads XDG menu files and creates Fvwm menus
 
 .SH SYNOPSIS
-
 fvwm-menu-desktop
-[ \fB\-\-help\fR|\fB\-h\fR|\fB\-?\fR ]
-[ \fB\-\-verbose\fR|\fB\-v\fR ]
+[ \fB\-\-help\fR|\fB\-h\fR ]
+[ \fB\-\-version\fR|\fB\-v\fR ]
 [ \fB\-\-install\-prefix\fR \fIDIR\fR ]
 [ \fB\-\-desktop\fR \fINAME\fR ]
-[ \fB\-\-title\fR \fINAME\fR ]
+[ \fB\-\-menu\-type\fR \fINAME\fR ]
+[ \fB\-\-theme\fR \fINAME\fR ]
+[ \fB\-\-with\-titles\fR|\fB\-w\fR ]
 [ \fB\-\-enable\-mini\-icons\fR ]
+[ \fB\-\-size\fR|\fB\-s\fR \fINUM\fR ]
+[ \fB\-\-title\fR|\fB\-t\fR \fINAME\fR ]
+[ \fB\-\-insert\-in\-menu\fR \fINAME\fR ]
+[ \fB\-\-get\-menus\fR \fIall\fR|\fIdesktop\fR ]
+[ \fB\-\-set\-menus\fR \fImenu_paths\fR ]
+[ \fB\-\-verbose\fR ]
+
 
 .SH DESCRIPTION
-This is a python script which parses XDG menus definitions to build
+This is a python script which parses XDG menus definitions to build 
 corresponding fvwm menus.
 
-.SH USAGE
-To add the XDG application menu to the Utilities menu
-add the following to your fvwm config file (.fvwm/config):
-.EX
- ...
-AddToMenu Utilities Application Menu Popup FvwmMenu
-PipeRead 'fvwm-menu-desktop'
-.EE
-
-By default fvwm-menu-desktop
-builds the applications menu
-and the menu is named FvwmMenu.
-
-.EX
-AddToMenu Utilities KDE User Menu Popup kde\-user
-AddToMenu kde\-user
-+ DynamicPopupAction PipeRead 'fvwm-menu-desktop --desktop kde-user --enable-mini-icons [other options]'
-.EE
-
-If you think that fvwm-menu-desktop slows your startup too much do
-not use PipeRead.  Instead run  fvwm-menu-desktop
-and
-redirect the menu to a file and Read that file in
-your .fvwm2rc file.
-Another possibility is to use DynamicPopupAction
-(with fvwm menu), the menu will be built only if
-you pop up the menu. The
-following menu creates a kde\-all menu which contains the user menu
-which is built each time you pop up kde\-all and contains a pop up
-to the system menu which is built only the first time you pop it up.
-.EX
-AddToMenu kde\-all
-+ DynamicPopupAction FuncRecreateKdeAll
-
-AddToMenu kde\-sys
-+ DynamicPopupAction PipeRead 'fvwm-menu-desktop \\
-\-\-desktop kde\-sys [options, but \-\-destroy-type d* or n*]'
-
-AddToFunc FuncRecreateKdeAll \\
-I PipeRead 'fvwm-menu-desktop \\
-\-\-desktop kde\-user \-\-enable\-mini\-icons \-\-name kde\-all \\
-\-\-destroy-type dynamic [options you like]'
-+ I AddToMenu kde\-all  Nop
-+ I AddToMenu kde\-all Kde System%mini/mini\-k.xpm% Popup kde\-sys
-.EE
-
 .SH OPTIONS
 
 .IP Main Options
 
 .IP \fB\-\-help\fR
 Show the help and exit.
-.IP \fB\-\-verbose\fR
-Run verbosely.
+
+.IP \fB\-\-version\fR
+Show the version and exit.
+
 .IP \fB\-\-install-prefix\fR \fIDIR\fR
-Optional parameter to override the default location
-for XDG menu definitions.  The default location is /etc/xdg/menus.
+Optional parameter to override the default locations for XDG menu
+definitions. Related to the xdg specification the default location is
+/etc/xdg/menus and $HOME/.config/menus if exist.
+
 .IP \fB\-\-desktop\fR \fINAME\fR
-The name of the menus you want to generate.
-The default is application.
-.IP \fB\-\-title\fR \fINAME\fR
-Define the menu title of the top menu. Default
-is Gnome System Menu for gnome\-sys, Gnome User Menu for
-gnome\-user, Gnome Red Hat Menu for gnome\-redhat,
-Gnome Mandriva Menu for gnome\-mandriva. For KDE the
-default is given by KDE itself (or are similar to GNOME title).
-.IP \fB\-\-name\fR \fINAME\fR
-Define the menu name of the top menu. Default is the \-\-desktop
-name if you use one above.
+Optional parameter to override the \fINAME\fR of the main desktop
+environment installed on the system. If a system offers multiple
+desktop environments $XDG_MENU_PREFIX is typically set and is
+ignored if \-\-desktop is denoted. Possible names are: \fIgnome\fR,
+\fIkde\fR, \fIxfce\fR, \fIlxde\fR, \fIdebian\fR, etc.
+
+.IP \fB\-\-menu\-type\fR \fINAME\fR
+Defines which type of menus should be found. Possible \fINAME\fR types
+could be: \fIapplications\fR, \fIsettings\fR, \fIpreferences\fR, etc.
+
+Note that if the specified menu type doesn't exist the generated menu
+is empty!
+
+.IP \fB\-\-theme\fR \fINAME\fR
+Defines the used icon theme. Default is \fIgnome\fR but all others
+found in /usr/share/icons could be used except the \fIhicolor\fR theme
+because it's the default fallback theme if no icon is found.
+
+.IP \fB\-\-with\-titles\fR|\fB\-w\fR
+If this option is set menus are generated with titles. Default is no
+titles.
+
+.IP \fB\-\-title\fR|\fB\-t\fR \fINAME\fR 
+Option to define the menu title \fINAME\fR of the top menu used by Fvwms
+\fBPopup\fR command. Default is FvwmMenu.
+
+.IP 

Re: First try of fvwm-menu-desktop which creates a full menu

[Thomas Funk]

Dan Espen des...@verizon.net wrote
 TF:

 All I really need is the words.
 I can add (t)groff/man markup as needed.
Thanks for your accommodation but I've finished it already. Patch
is attached ^^ Please review it for grammar and phrase errors.

 I don't see get-menus in the man page.
added.

 I think you want the option to be:

 --get-menus all | desktop

 with an error for any other value.
Your fix is excellent! And 'desktop' is absolutely suitable :-)

 Rule of thumb, NEVER use the word will in documentation.
eliminated except two.

Thomas
--- /media/daten/shared/sourcen/cvs/fvwm/bin/fvwm-menu-desktop.1	2012-01-02 19:25:49.120033746 +0100
+++ fvwm-menu-desktop.1	2012-07-21 00:16:50.485774334 +0200
@@ -1,5 +1,5 @@
 .\ t
-.\ @(#)fvwm-2.6.4 (not released yet)
+.\ @(#)fvwm-2.6.6 (not released yet)
 .de EX		\Begin example
 .ne 5
 .if n .sp 1
@@ -14,461 +14,257 @@
 .if t .sp .5
 ..
 .ta .3i .6i .9i 1.2i 1.5i 1.8i
-.TH fvwm-menu-desktop 1 (not released yet) (2.6.4) Fvwm Fvwm Modules
+.TH fvwm-menu-desktop 1 (not released yet) (2.6.6) Fvwm Fvwm Modules
 .UC
 .SH NAME
-fvwm-menu-desktop \- builds GNOME and KDE menus and style commands for fvwm
+fvwm-menu-desktop \- Reads XDG menu files and creates Fvwm menus
 
-.SH SYNOPSIS
 
+.SH SYNOPSIS
 fvwm-menu-desktop
-[ \fB\-\-help\fR|\fB\-h\fR|\fB\-?\fR ]
-[ \fB\-\-version\fR|\fB\-v\fR|\fB\-V\fR ]
+[ \fB\-\-help\fR|\fB\-h\fR ]
+[ \fB\-\-version\fR|\fB\-v\fR ]
 [ \fB\-\-install\-prefix\fR \fIDIR\fR ]
 [ \fB\-\-desktop\fR \fINAME\fR ]
-[ \fB\-\-type\fR NAME\fR ]
-[ \fB\-\-fvwmgtk\-alias\fR \fINAME\fR ]
-[ \fB\-\-title\fR \fINAME\fR ]
-[ \fB\-\-name\fR \fINAME\fR ]
-[ \fB\-\-merge-user-menu\fR ]
+[ \fB\-\-menu\-type\fR \fINAME\fR ]
+[ \fB\-\-theme\fR \fINAME\fR ]
+[ \fB\-\-with\-titles\fR|\fB\-w\fR ]
 [ \fB\-\-enable\-mini\-icons\fR ]
-[ \fB\-\-enable\-tran\-mini\-icons\fR ]
-[ \fB\-\-mini\-icons\-path\fR \fIDIR\fR ]
-[ \fB\-\-png\-icons\-path\fR \fIDIR\fR ]
-[ \fB\-\-tran\-mini\-icons\-path\fR \fIDIR\fR ]
-[ \fB\-\-check-mini\-icons\fR \fIPATH\fR ]
-[ \fB\-\-icon\-toptitle\fR
-\fImicon\fR:\fIlaw\fR:\fIplace\fR:\fIside_pic\fR:\fIcolor\fR ]
-[ \fB\-\-icon\-title\fR
-\fImicon\fR:\fIlaw\fR:\fIplace\fR:\fIside_pic\fR:\fIcolor\fR ]
-[ \fB\-\-icon\-folder\fR  \fImicon\fR:\fIlaw\fR:\fIplace\fR ]
-[ \fB\-\-icon\-app\fR \fImicon\fR:\fIlaw\fR:\fIplace\fR ]
-[ \fB\-\-wm\-icons\fR ]
-[ \fB\-\-enable\-style\fR ]
-[ \fB\-\-enable\-tran\-style\fR ]
-[ \fB\-\-icon-style\fR \fImicon\fR:\fIicon\fR:\fIlaw\fR ]
-[ \fB\-\-icons\-path\fR \fIDIR\fR ]
-[ \fB\-\-tran\-icons\-path\fR \fIDIR\fR ]
-[ \fB\-\-check-icons\fR \fIPATH\fR ]
-[ \fB\-\-submenu\-name\-prefix\fR \fIname\fR ]
-[ \fB\-\-dir\fR \fIDIR\fR ]
-[ \fB\-\-destroy\-type\fR \fIFLAG\fR ]
-[ \fB\-\-xterm\fR \fICMD\fR ]
-[ \fB\-\-lang\fR \fINAME\fR ]
-[ \fB\-\-utf8\fR ]
-[ \fB\-\-uniconv\fR \fIcharset\fR ]
-[ \fB\-\-uniconv-exec\fR \fIexec\fR ]
-[ \fB\-\-menu-style\fR \fIname\fR ]
-[ \fB\-\-no\-check\-app\fR ]
-[ \fB\-\-time\-limit\fR \fINUM\fR ]
-[ \fB\-\-kde_config\fR \fIcommand\fR ]
+[ \fB\-\-size\fR|\fB\-s\fR \fINUM\fR ]
+[ \fB\-\-title\fR|\fB\-t\fR \fINAME\fR ]
+[ \fB\-\-insert\-in\-menu\fR \fINAME\fR ]
+[ \fB\-\-get\-menus\fR \fIall\fR|\fIdesktop\fR ]
+[ \fB\-\-set\-menus\fR \fImenu_paths\fR ]
+[ \fB\-\-verbose\fR ]
+
 
 .SH DESCRIPTION
-This is a perl script which parses XDG (GNOME or KDE) menus definitions to build
-corresponding fvwm menus. The script can also
-build icon and mini\-icon style commands for the applications.
+This is a python script which parses XDG menus definitions to build 
+corresponding fvwm menus.
+
+.SH OPTIONS
+
+.IP Main Options
+
+.IP \fB\-\-help\fR
+Show the help and exit.
+
+.IP \fB\-\-version\fR
+Show the version and exit.
+
+.IP \fB\-\-install-prefix\fR \fIDIR\fR
+Optional parameter to override the default locations for XDG menu
+definitions. Related to the xdg specification the default location is
+/etc/xdg/menus and $HOME/.config/menus if exist.
+
+.IP \fB\-\-desktop\fR \fINAME\fR
+Optional parameter to override the \fINAME\fR of the main desktop
+environment installed on the system. If a system offers multiple
+desktop environments $XDG_MENU_PREFIX is typically set and is
+ignored if \-\-desktop is denoted. Possible names are: \fIgnome\fR,
+\fIkde\fR, \fIxfce\fR, \fIlxde\fR, \fIdebian\fR, etc.
+
+.IP \fB\-\-menu\-type\fR \fINAME\fR
+Defines which type of menus should be found. Possible \fINAME\fR types
+could be: \fIapplications\fR, \fIsettings\fR, \fIpreferences\fR, etc.
+
+Note that if the specified menu type doesn't exist the generated menu
+is empty!
+
+.IP \fB\-\-theme\fR \fINAME\fR
+Defines the used icon theme. Default is \fIgnome\fR but all others
+found in /usr/share/icons could be used except the \fIhicolor\fR theme
+because it's the default fallback theme if no icon is found.
+
+.IP \fB\-\-with\-titles\fR|\fB\-w\fR
+If this option is set menus are generated with titles. Default is no
+titles.
+
+.IP \fB\-\-title\fR|\fB\-t\fR \fINAME\fR 
+Option to define the menu title \fINAME\fR of the 

Re: First try of fvwm-menu-desktop which creates a full menu

[Thomas Funk]

Dan Espen des...@verizon.net wrote:
 Thomas Funk t.f...@web.de writes:

 Try the examples in the manpage you requested to get an overview about
 the look and feel of the different display possibilities. The page is
 created with asciidoc but in Groff format so you can look into it with
 man ^^

 The man page is a LOT less readable than I expected it to be.
 Does every period have to be escaped?

 Not real happy with the result.

What do you mean with Does every period have to be escaped ?
Do you mean the man page file itself or if you use
$./man fvwm-menu-desktop.1

I can send you the asciidoc file. It's plain text with some asciidoc
formatings.

I have no clue how to write groff. So I use the easier way via asciidoc.

Thomas

Re: First try of fvwm-menu-desktop which creates a full menu

[Thomas Funk]

Am 19.07.2012 22:38, schrieb Dan Espen:
 Thomas Funk t.f...@web.de writes:

 Hi Dan!

 I've attached the advised patch related to your last CVS version of
 fvwm-menu-desktop. It includes the needed functionality to response to
 the attached configuration tool for fvwm-menu-desktop. Two new options:
 - get-menus [selected, all] to send the found menus to the config gui
 - set-menus [filelist] to tell fvwm-menu-desktop which menus should be
   build
 The usage prompt for get-menus says it prints a comma separated list,
 but I get a space separated list.
Uups, forgot to change to 'space separated list'. Would you change it,
please?

 The usage prompt says selected is an option but it looks like anything
 other than all is what it looks for.  I'm not clear on what the
 selected option is doing.
Yes, right. You can use every word you want but it needs a word because
I sample in parsemenus() for not get_menus == '' (it's for both). As the
user doesn't know it I decided to use 'selected' for the other possibility.

 You're English it pretty good.  No such word as founded though.
Thanks for the compliment :-) I try to reduce the german part of my
english to a bearable level with talking and writing ^^

 Rule of thumb, NEVER use the word will in documentation.
 Always describe features as already there.
Ah, ok. Not known. Thanks for the tip.

Thomas

Re: First try of fvwm-menu-desktop which creates a full menu

[Thomas Funk]

2012/7/17 Dan Espen des...@verizon.net wrote:
 Thomas Adam tho...@fvwm.org writes:

 On Mon, Jul 16, 2012 at 06:23:17PM -0400, Dan Espen wrote:
 Thomas Adam tho...@fvwm.org writes:

  On Mon, Jul 16, 2012 at 11:35:20PM +0200, Thomas Funk wrote:
  Regenerate Menu(s)
 
  Why can this not be an on-disk cache or something instead of requiring the
  user to care to regenerate the menus?

 The purpose of Regenerate Menus is to get a new menu after you've
 installed a new package.   A cache would only make the problem worse.

 Actually, no.  Effectively this is what Debian does with its menuing system
 and it works just fine.  I see no reason why we need an explicit
 regeneration of these menus.

 I'm not following.

 If I install a new package, say Evolution, it won't be in the Fvwm
 menus.  Not until the menu is regenerated.

 How is a user supposed to get a new menu with Evolution in it?
I've looked a little around and the easiest way is to scan the
$XDG_DATA_HOME ($HOME/.local/share) and $XDG_DATA_DIRS (/usr/local/share/,
/usr/share/) periodically if .desktop files are added/removed there.

For that an own module for menu creation/changing/updating will be
beneficial ;-). Due to the fact that I am working on that stuff I would
start with such a module. But could take a little while ;-) ...

In the meantime it would be fine if anybody who's interested in helping
would test fvwm-menu-desktop and report bugs here on the list.

Dan, I will send you a small bugfix patch for the actual CVS version. The
fixes are in the last patch included but as this is a proof of concept
would be better to seperate them.

Thomas

Re: First try of fvwm-menu-desktop which creates a full menu

[Thomas Funk]

 Thomas Funk t.funk...@googlemail.com wrote:
 Dan, I will send you a small bugfix patch for the actual CVS 
version. The

 fixes are in the last patch included but as this is a proof of concept
 would be better to seperate them.
 Okay.  As you've seen I'm a bit slow to look at these things.
 I haven't looked at your latest work yet.
 I will get to it though.
Attached the patch for
- fixing bug, that empty menus were generated
- fix your fixme for Regenerate Applications Menu
- add forgotten --version
- add forgotten -t for title option
- update help

Thomas
--- /media/daten/shared/sourcen/cvs/fvwm/bin/fvwm-menu-desktop.in	2012-07-13 13:14:31.428392223 +0200
+++ fvwm-menu-desktop.in.p4.1.py	2012-07-18 00:20:03.011125095 +0200
@@ -97,7 +97,7 @@
 
 try:
 opts, args = getopt.getopt(sys.argv[1:], hs:t:vw,
-   [help, verbose, enable-mini-icons, with-titles, verbose,
+   [help, verbose, enable-mini-icons, with-titles, verbose, version,
 desktop=, size=, theme=, install-prefix=, menu-type=, title=]+obs_args+equaled_obs_parms)
 except getopt.GetoptError, err:
 # print help information and exit:
@@ -105,6 +105,7 @@
 print usage
 sys.exit(2)
 global verbose, force, size, theme, icon_dir, top, install_prefix, menu_type, with_titles, menu_entry_count
+version = 2.0
 verbose = False
 force = False
 desktop=''
@@ -123,11 +124,14 @@
 elif o in (-h, --help) :
 print usage
 sys.exit()
+elif o in (--version) :
+print fvwm-menu-desktop version  + version
+sys.exit()
 elif o in (--enable-mini-icons) :
 force=True
 elif o in (--desktop) :
 desktop=a
-elif o in (--title) :
+elif o in (-t, --title) :
 top=a
 elif o in (--install-prefix) :
 if a and not os.path.isabs(a):
@@ -364,6 +368,7 @@
 printtext('+ %s%s %s' % (name, iconfile, command))
 
 def parsemenus(menulist, desktop):
+global menu_entry_count
 if len(menulist) == 1:
 # user defines only one special menu
 parsemenu(xdg.Menu.parse(menulist[0]), top)
@@ -385,6 +390,7 @@
 if not menu_entry_count == 0:
 new_toptitles.append(title)
 new_menulist.append(menu)
+menu_entry_count = 0
 else:
 vprint( Menu is empty - won't be used!)
 
@@ -402,8 +408,10 @@
 def parsemenu(menu, name=, title=):
 global menu_entry_count
 m = re.compile('%[A-Z]?', re.I) # Pattern for %A-Z (meant for %U)
+gen_name = ''
 if not name :
 name = menu.getPath()
+gen_name = menu.getPath(True)
 if not title:
 title = name
 printtext('DestroyMenu %s' % name)
@@ -422,15 +430,16 @@
 menu_entry_count += 1
 	else:
 	printtext('# not supported: ' + str(entry))
+
+if gen_name == 'System':
+printmenu(Regenerate XDG Menu(s), system-software-update, FvwmForm FvwmForm-Desktop )
+
 printtext('')
 
 for entry in menu.getEntries():
 	if isinstance(entry, xdg.Menu.Menu):
 	parsemenu(entry)
 
-if (re.search('.*System Tools$',name)) : # fixme, find a better way to do this?
-printmenu(Regenerate Applications Menu, , FvwmForm  FvwmForm-Desktop )
-
 usage=
 A script which parses xdg menu definitions to build
 the corresponding fvwm menus.
@@ -443,13 +452,13 @@
   For the system wide menus use /etc/xdg/menus/
 --desktop NAMEdesktop name to build menus for:
   gnome, kde, xfce, lxde, debian, etc.
---menu-type NAME  applications (default), settings, preferences, etc.
+--menu-type NAME  applications, settings, preferences, etc.
 --theme NAME  gnome (default), oxygen, etc. Don't use hicolor. 
   It's the default fallback theme if no icon will be found.
 -w, --with-titles generate menus with titles.
 --enable-mini-icons   enable mini-icons in menu
--s, --sizeset size of mini-icons in menu. Default is 24.
---title NAME  menu title of the top menu used by Popup command.
+-s, --size NUMset size of mini-icons in menu. Default is 24.
+-t, --title NAME  menu title of the top menu used by Popup command.
   Default is FvwmMenu
 -v, --verbose run and display debug info on STDERR
 

Re: First try of fvwm-menu-desktop which creates a full menu

[Thomas Funk]

2012/7/16 Dan Espen des...@verizon.net wrote:
 The code to generate all menus looks like it needs work.
 I find the same menus repeated in multiple places.
Yes I saw that but the multiple appearances are a result of the xml menus by
themselve. Depending whether they are used for, the menus are generated as
the sources were.

One possibility could be to create the menus and then search for double
entries, eliminate them and if a menu is empty delete it. But the actual
menu built process took on my Dual core system 10-15 seconds (with icon
conversion). With this selection certainly 25-30. For me too long. And for
slower machines far too much.

 I realize the XDG spec isn't helping but would some trimming be in order?
Personally I thought that fvwm-menu-desktop shall provide a possibility
for the user to choose the menus she/he wants. And that's what the tool
does. But we shouldn't strip down the menus.

In the next days I will present a fvwm-menu-desktop config tool based on
FvwmPerl which shows all founded menus on the system and let the user
decide which menu/menus she/he wants to create and how.

Perhaps that would be sufficient enough ...

Thomas

Re: First try of fvwm-menu-desktop which creates a full menu

[Thomas Funk]

Dan Espen des...@verizon.net wrote:
On my Fedora system I have Preferences as a top level menu now.
I also have Settings at the same level. Inside Settings are
Preferences and Administration.

Which Preferences should be removed?
What I could imagine is, to scan the xml menus and build our own Fvwm
xml menu and then generate this with the python process. But which menu
should the main one to extend?

How does the parsing of the files are running? and in which data structure
do we organize it?

No small undertaking ...

Thomas

Re: First try of fvwm-menu-desktop which creates a full menu

[Thomas Funk]

 %s' % name)
+if with_titles:
+# for insert-in-menu AddToMenu doesn't have a title for top menu
+# because this will appear then in the other menu
+if insert_in_menu and name == top and menu_list_length == 1:
+printtext('AddToMenu %s' % name)
+else:
+printtext('AddToMenu %s %s Title' % (name, title))
+else:
+printtext('AddToMenu %s' % name)
 for entry in menu.getEntries():
 	if isinstance(entry, xdg.Menu.Menu):
-printmenu(entry.getName(), entry.getIcon(), 'Popup %s' % entry.getPath())
+if printmode:
+printmenu(entry.getName(), entry.getIcon(), 'Popup %s' % entry.getPath())
 	elif isinstance(entry, xdg.Menu.MenuEntry):
-desktop = DesktopEntry(entry.DesktopEntry.getFileName())
-# eliminate '%U' etc behind execute string
-execProgram = m.sub('', desktop.getExec())
-printmenu(desktop.getName(), desktop.getIcon(), Exec exec  +   + execProgram)
+if printmode:
+desktop = DesktopEntry(entry.DesktopEntry.getFileName())
+# eliminate '%U' etc behind execute string
+execProgram = m.sub('', desktop.getExec())
+printmenu(desktop.getName(), desktop.getIcon(), Exec exec  +   + execProgram)
 menu_entry_count += 1
 	else:
-	printtext('# not supported: ' + str(entry))
-printtext('')
+if printmode:
+printtext('# not supported: ' + str(entry))
+
+# should only appear in a single menu. For more it will insert in parsemenus() when the top menu will built
+if menu_list_length == 1 and not insert_in_menu and name == top:
+printtext('+  Nop')
+printmenu(Regenerate XDG Menu, system-software-update, Module FvwmPerl -l fvwm-menu-desktop-config.fpl )
+
+if printmode:
+printtext('')
 
 for entry in menu.getEntries():
 	if isinstance(entry, xdg.Menu.Menu):
 	parsemenu(entry)
 
-if (re.search('.*System Tools$',name)) : # fixme, find a better way to do this?
-printmenu(Regenerate Applications Menu, , FvwmForm  FvwmForm-Desktop )
-
 usage=
 A script which parses xdg menu definitions to build
 the corresponding fvwm menus.
@@ -443,14 +508,22 @@
   For the system wide menus use /etc/xdg/menus/
 --desktop NAMEdesktop name to build menus for:
   gnome, kde, xfce, lxde, debian, etc.
---menu-type NAME  applications (default), settings, preferences, etc.
+--menu-type NAME  applications, settings, preferences, etc.
 --theme NAME  gnome (default), oxygen, etc. Don't use hicolor. 
   It's the default fallback theme if no icon will be found.
 -w, --with-titles generate menus with titles.
 --enable-mini-icons   enable mini-icons in menu
--s, --sizeset size of mini-icons in menu. Default is 24.
---title NAME  menu title of the top menu used by Popup command.
+-s, --size NUMset size of mini-icons in menu. Default is 24.
+-t, --title NAME  menu title of the top menu used by Popup command.
   Default is FvwmMenu
+--insert-in-menu NAME generates a menu to place it in the root level of the
+  menu NAME
+--get-menus   prints a comma separated list with full menu paths.
+  'selected' prints the desktop related menus. 'all' prints 
+  all founded menus on the system except empty ones. No
+  menu generation will be done.
+--set-menus   expects a space separated list of full menu paths to generate
+  user specified menus
 -v, --verbose run and display debug info on STDERR
 
 if __name__ == __main__:
# This script generates a FvwmForm similar to the FvwmForm-Desktop by
# Dan Espen but insert the found xdg menus dynamically into the Form
# before processed.
# Author: Thomas Funk t.f...@web.de
# Version: 1.0

package Test;
use File::Basename;
use strict;

#open(MSG ,[path]/log.txt) || die Error $!;

my $all = `fvwm-menu-desktop --get-menus all`;
#print MSG $all;

my $selected = `fvwm-menu-desktop --get-menus selected`;
#print MSG $selected;
my @all_filelist = split(/ /,$all);
my @selected_filelist = split(/ /,$selected);

my %all_menus = ();
my %selected__menus = ();
my $max_length = 0;
foreach my $path (@selected_filelist) {
my ($filename, $directories, $suffix) = fileparse($path, qr/\.[^.]*/);
push (@{$selected__menus{$directories}}, $filename);
}

my $i = 1;
foreach my $path (@all_filelist) {
my $name = MEN . $i;
my ($filename, $directories, $suffix) = fileparse($path, qr/\.[^.]*/);
push (@{$all_menus

Deprecated warnings with deb-inplace

[Thomas Funk]

Hi,

I've gotten deprecated warnings for some packages on Xubuntu 12.04
with deb-inplace. It's only for your information because the packages
will be 'soon FTBFS'. But good to know ;-)

Here're the output:
  :
fakeroot dh_installchangelogs -P`cd ..  pwd`/inst-2.6.5
dh_installchangelogs: No compatibility level specified in debian/compat
dh_installchangelogs: This package will soon FTBFS; time to fix it!
dh_installchangelogs: Compatibility levels before 5 are deprecated
(level 1 in use)
fakeroot dh_installdocs -P`cd ..  pwd`/inst-2.6.5
dh_installdocs: No compatibility level specified in debian/compat
dh_installdocs: This package will soon FTBFS; time to fix it!
dh_installdocs: Compatibility levels before 5 are deprecated (level 1 in use)
fakeroot dh_installmenu -P`cd ..  pwd`/inst-2.6.5
dh_installmenu: No compatibility level specified in debian/compat
dh_installmenu: This package will soon FTBFS; time to fix it!
dh_installmenu: Compatibility levels before 5 are deprecated (level 1 in use)
fakeroot dh_link -P`cd ..  pwd`/inst-2.6.5
dh_link: No compatibility level specified in debian/compat
dh_link: This package will soon FTBFS; time to fix it!
dh_link: Compatibility levels before 5 are deprecated (level 1 in use)
fakeroot dh_strip -P`cd ..  pwd`/inst-2.6.5
dh_strip: No compatibility level specified in debian/compat
dh_strip: This package will soon FTBFS; time to fix it!
dh_strip: Compatibility levels before 5 are deprecated (level 1 in use)
fakeroot dh_compress -P`cd ..  pwd`/inst-2.6.5
dh_compress: No compatibility level specified in debian/compat
dh_compress: This package will soon FTBFS; time to fix it!
dh_compress: Compatibility levels before 5 are deprecated (level 1 in use)
fakeroot dh_fixperms -P`cd ..  pwd`/inst-2.6.5
dh_fixperms: No compatibility level specified in debian/compat
dh_fixperms: This package will soon FTBFS; time to fix it!
dh_fixperms: Compatibility levels before 5 are deprecated (level 1 in use)
fakeroot dh_perl -P`cd ..  pwd`/inst-2.6.5
dh_perl: No compatibility level specified in debian/compat
dh_perl: This package will soon FTBFS; time to fix it!
dh_perl: Compatibility levels before 5 are deprecated (level 1 in use)
fakeroot dh_installdeb -P`cd ..  pwd`/inst-2.6.5
dh_installdeb: No compatibility level specified in debian/compat
dh_installdeb: This package will soon FTBFS; time to fix it!
dh_installdeb: Compatibility levels before 5 are deprecated (level 1 in use)
fakeroot dh_shlibdeps -P`cd ..  pwd`/inst-2.6.5
dh_shlibdeps: No compatibility level specified in debian/compat
dh_shlibdeps: This package will soon FTBFS; time to fix it!
dh_shlibdeps: Compatibility levels before 5 are deprecated (level 1 in use)
fakeroot dh_gencontrol -P`cd ..  pwd`/inst-2.6.5
dh_gencontrol: No compatibility level specified in debian/compat
dh_gencontrol: This package will soon FTBFS; time to fix it!
dh_gencontrol: Compatibility levels before 5 are deprecated (level 1 in use)
dpkg-gencontrol: warning: package fvwm: unused substitution variable
${perl:Depends}
fakeroot dh_md5sums -P`cd ..  pwd`/inst-2.6.5
dh_md5sums: No compatibility level specified in debian/compat
dh_md5sums: This package will soon FTBFS; time to fix it!
dh_md5sums: Compatibility levels before 5 are deprecated (level 1 in use)
fakeroot dh_builddeb -P`cd ..  pwd`/inst-2.6.5
dpkg-deb: building package `fvwm' in `../fvwm_2.6.5-0.20120627_i386.deb'.
dh_builddeb: No compatibility level specified in debian/compat
dh_builddeb: This package will soon FTBFS; time to fix it!
dh_builddeb: Compatibility levels before 5 are deprecated (level 1 in use)
dh_builddeb: No compatibility level specified in debian/compat
dh_builddeb: This package will soon FTBFS; time to fix it!
dh_builddeb: Compatibility levels before 5 are deprecated (level 1 in use)
dpkg-genchanges: including full source code in upload
/bin/bash: debsign: command not found
make[1]: [inplace] Error 127 (ignored)
fakeroot dh_clean -P`cd ..  pwd`/inst-2.6.5
dh_clean: No compatibility level specified in debian/compat
dh_clean: This package will soon FTBFS; time to fix it!
dh_clean: Compatibility levels before 5 are deprecated (level 1 in use)
rm -rf `cd ..  pwd`/inst-2.6.5
(cd ..  ls fvwm_2.6.5-0.`date +%Y%m%d`*)
fvwm_2.6.5-0.20120627.dsc   fvwm_2.6.5-0.20120627_i386.deb
fvwm_2.6.5-0.20120627_i386.changes  fvwm_2.6.5-0.20120627.tar.gz
make[1]: Leaving directory `/home/xubuntu/Downloads/fvwm-2.6.5'

Regards,
Thomas

Re: First try of fvwm-menu-desktop which creates a full menu

[Thomas Funk]

Dan Espen des...@verizon.net wrote:
 So maybe you can clean up this version a bit more
 and submit as a patch?
Attached. It's diffed against the latest CVS version of fvwm-menu-desktop.in

This popped out:

This can't be right:

if len(menulist) == 0:

sys.stderr.write(install_prefix+/+desktop+-+menu_type+.menu not 
available on this system. Exiting...\n)


For example:

python fvwm-menu-desktop.in.py --menu-type notfound
/debian-notfound.menu not available on this system. Exiting...
Fixed.

Not sure what this is:

python fvwm-menu-desktop.in.py --menu-type system-settings
Traceback (most recent call last):
  File fvwm-menu-desktop.in.py, line 470, in module
main()
  File fvwm-menu-desktop.in.py, line 170, in main
menulist, desktop = getmenulist(desktop, menu_type)
  File fvwm-menu-desktop.in.py, line 285, in getmenulist
desktop_dict[de_highest].add(menu)
KeyError: 'debian'
This happens because the the 'others' and 'none' were ignored in the
weighting. I did that before I sorted the keys to prevent that in the
first loop 'none' or 'others' are the start menus. And so in your case
debian was the winner but hasn't any menu and therefore no dict entry
exists. Only 'others'. So no key 'debian' - KeyError: 'debian'
Fixed.

1. We have less chance of losing the #!@PYTHON@ line.
In the CVS version #!/usr/bin/python is set instead of #!@PYTHON@
Should changed back?

Meanwhile, the man page is about half done.
Updated the fvwm-menu-desktop help also.

If we go this route,
it would be nice if you included some of the comments
you made.   At least for me, not all of this was obvious.
Done.

Also I fixed some issues I found while testing:
- The not working regex with trailing slash in install-prefix
  interpretation.
- Eliminate '%' behind menu entries if no icon will be found.
- Wrong conditional expression which tests the availability of
  $XDG_MENU_PREFIX.

Thomas




--- fvwm-menu-desktop.orig.py	2012-07-03 22:56:01.316247721 +0200
+++ Old/fvwm-menu-desktop.in.p4.py	2012-07-09 23:55:48.005438739 +0200
@@ -42,6 +42,7 @@
 import os.path
 import os
 from xdg.DesktopEntry import *
+import fnmatch
 
 
 def main ():
@@ -81,7 +82,6 @@
'png-icons-path',
'submenu-name-prefix',
'time-limit',
-   'title',
'tran-icons-path',
'tran-mini-icons-path',
'type',
@@ -97,14 +97,14 @@
 
 try:
 opts, args = getopt.getopt(sys.argv[1:], hs:t:vw,
-   [help, verbose, enable-mini-icons, with-titles,
-desktop=, size=, theme=, install-prefix=, menu-type=]+obs_args+equaled_obs_parms)
+   [help, verbose, enable-mini-icons, with-titles, verbose,
+desktop=, size=, theme=, install-prefix=, menu-type=, title=]+obs_args+equaled_obs_parms)
 except getopt.GetoptError, err:
 # print help information and exit:
 print str(err) # will print something like option -a not recognized
 print usage
 sys.exit(2)
-global verbose, force, size, theme, icon_dir, top, install_prefix, menu_type, with_titles
+global verbose, force, size, theme, icon_dir, top, install_prefix, menu_type, with_titles, menu_entry_count
 verbose = False
 force = False
 desktop=''
@@ -112,9 +112,10 @@
 theme='gnome'
 icon_dir=~/.fvwm/icons
 top='FvwmMenu'
-install_prefix = '/etc/xdg/menus/'
-menu_type = 'applications'
+install_prefix = ''
+menu_type = ''
 with_titles = False
+menu_entry_count = 0
 
 for o, a in opts:
 if o == -v:
@@ -125,14 +126,15 @@
 elif o in (--enable-mini-icons) :
 force=True
 elif o in (--desktop) :
-#?desktop=a + '-'
 desktop=a
+elif o in (--title) :
+top=a
 elif o in (--install-prefix) :
 if a and not os.path.isabs(a):
 assert False, install-prefix must be an absolute path
 # add trailing slash if not there already
-if (not re.search('.*[.]/$',a)) : # no trailing slash
-a=a+'/'
+if not a[-1] == '/' : # trailing slash
+a=a + '/'
 install_prefix = a
 
 elif o in (-s,--size) :
@@ -143,33 +145,177 @@
 menu_type = a
 elif o in (-w,--with-titles) :
 with_titles = True
+elif o in (--verbose) :
+verbose = True
 elif o in (str(dashed_obs_args+dashed_obs_parms)) :
 # Ignore
 sys.stderr.write( Warning: Arg +o+ is obsolete and ignored\n )
 else:
 assert False, unhandled option
+
+xdg_menu_prefix = (os.environ['XDG_MENU_PREFIX'] if os.environ.has_key('XDG_MENU_PREFIX') else '')
 
-check=install_prefix+desktop+menu_type+'.menu'
-menu = checkmenu(check)
+# First check if no user 

Re: First try of fvwm-menu-desktop which creates a full menu

[Thomas Funk]

2012/7/6 Dan Espen des...@verizon.net wrote:
 Your code is pretty ingenious, and it solves the single biggest
 issue I had with the xdg spec.  Ie. if finds all the menus a WM
 might want to make visible to the user.
I'm very pleased to hear that the implementation suits your needs :-)

 If we go this route,
 it would be nice if you included some of the comments
 you made.   At least for me, not all of this was obvious.
Will do that then.

 I was thinking of leaving the choice of menus to generate up to
 the user.  Of course the distros could do the logical thing
 and create a single menu hierarchy or at least set some rules.

Yes, I thought the same. Not known how to do it with FvwmForm or
FvwmScript but I could implement
an option in fvwm-menu-desktop to printout a string with menus found on
the system like
--show-menus=[all, de-selected] and then the user can select/deselect
via checkboxes which menus
she/he wants to display. For that I have to rewrite the --desktop and
--menu-type functionality to handle
lists then.

 You'd want something like fvwm-menu-directory front ending FvwmForm.
With fvwm-menu-desktop it's better because the menus can checked if they're
empty.

 I got a little feedback from the xdg folks:
 ...
 It doesn't sound to me like they are going to address the issue in the
 near term.
Yep, looks so.

 I'd like to implement what's best for Fvwm.
That's also my intend.
 If XDG gets it's act together later we can replace what we've done
 with something simpler.
I don't think they will change it in the future anymore.

 So maybe you can clean up this version a bit more
 and submit as a patch?
I've submitted the patch in another email - Second try ... but
afterwards it was silly to put it in another thread because it
belongs to this one. Sorry about that. Won't be happen anymore.
Would you answer that email in this thread then? Or is this yet
impossible now?

 Thanks for your efforts,
 and I'm getting a few python lessons along the way...
You're welcome ^^

Thomas

Re: [Patch] fvwm-menu-desktop improvements

[Thomas Funk]

Dan Espen des...@verizon.net wrote:
Seems to me, the best way fvwm can interface with this mess
is to just treat the whole name as one thing.

What about this:
we rename
--desktop to --menu-prefix
--menu-type to --menu-name

In the help the following is written:
--menu-prefix PREFIX  Menu prefix following the xdg standard like:
  gnome-, kde4-, xfce-, lxde-, debian-,
etc. Default is empty
--menu-name NAME  applications (default), settings,
preferences, etc.
  For non xdg compliant menus the complete
name should use
  without the trailing '.menu' e.g.
'applications-gnome' or 'gnomecc'

What do you thinking? Could this a compromise?

Thomas

Re: [Patch] fvwm-menu-desktop improvements

[Thomas Funk]

Dan Espen des...@verizon.net wrote:
Still giving the whole issue some thought.
Still seems to me like:

The XDG spec is faulty.  It treats xxx-applications like a special
case, but completely ignores any other root menu.
No, it's not faulty
 Extract from Desktop Menu Specification V1.0
 File locations
 $XDG_CONFIG_DIRS/menus/${XDG_MENU_PREFIX}applications.menu
  :
 Implementations may chose to use .menu files with other names for tasks
 or menus other than the main application menu. Such usage is not covered
 by this specification.

Shouldn't there be a xxx-settings.menu and a
xxx-documentation menu?
If a distro think it should exist one sure. On my Debian system a
gnome-settings.menu and a kde4-information.menu but they are optional.
If a user wants them, no prob - should implement it in her/his config.

We should give the user the ability to get an applications menu.
All others are the users beer. Sure, we should give her/him the possibility
to access these menus and fvwm-menu-desktop do this.

If there were, the menu prefix would make sense.
Maybe no prefix for the distro default, and
xxx- prefixes for each desktop package.
You're right. Normally the ${XDG_MENU_PREFIX} is empty by default. Only if
 Extract from Desktop Menu Specification V1.0
 File locations
 $XDG_CONFIG_DIRS/menus/${XDG_MENU_PREFIX}applications.menu
  :
 Systems that offer multiple desktop environments and that want to use
 distinct menu layouts in the different environments can use differently
 prefixed .menu files. In this case the $XDG_MENU_PREFIX environment
 variable must be set by the system to reflect the .menu file that is
 being used.

I've checked 7 distros (Debian, Redhat, Ubuntu, Mandriva, Fedora,
OpenSuse) with different versions and on all ${XDG_MENU_PREFIX} isn't set.
Therefore fvwm-xdg-menu and fvwm-menu-desktop.in doesn't check it.

I see that Gentoo claims to have a gnome-applications.menu.
On my Debian system there's also a gnome-applications.menu in
$HOME/.config/menus/ Therefore I've implemented in my fvwm-xdg-menu the
mtime check. That works on my system, but on a Xubuntu system from a
friend of mine the xfce-settings.menu was found because this menu was
changed as the last one ... so you see, not really practicable...

Maybe what I'm seeing in Fedora is just a Fedora issue.
Maybe. But I've checked the applications-gnome.menu and applications.menu
under your system (F17 hopefully ^^) and they are 95% identical. So for
me I address the question - why this discussion? We create for 95-98% of the
distros an application menu. Perhaps for 100. If not, the user have to
look deeper in her/his system and the fvwm-menu-desktop help. Then he
must change the command and get the menu she/he wants

@Thomas:
...this has to state that it would override whatever XDG_MENU_PREFIX
might be set to.
This happens if we implement the $XDG_MENU_PREFIX, yes. But at the moment
we must set this manually to get e.g. a gnome-applications.menu. But 
normally

the applications.menu reflects the most applications installed on a system.

Thomas

Re: [Patch] fvwm-menu-desktop improvements

[Thomas Funk]

Dan Espen des...@verizon.net wrote:
I see:
File locations
Files involved in this specification are located according to the
desktop base directory specification.

Here are the files defined by this specification:
$XDG_CONFIG_DIRS/menus/${XDG_MENU_PREFIX}applications.menu

But on my Fedora system, I have
/etc/xdg/menus/applications-gnome.menu

Which is part of the gnome-menus-3.2.0.1-1.fc16.i686
package. Looks like it doesn't care about that rule.

Then there are all the other menus in the xdg/menus area.
They don't end in applications either.

These are optional menus. The main menu is applications.menu

I mean, I see it in the xdg spec and I see what you'd like to do with
accessing applications. But I don't see how this fits with the
other xdg menus we might want to access which don't have rules like this.

fvwm-menu-desktop is absolutely xdg compliant
--desktop fits ${XDG_MENU_PREFIX} like gnome-, kde4-, xfce-, lxde-
--menu-type specifies the type like applications, preferences, settings
              and for non compliant menus all other named stuff ...

And we can map *ALL* menus - compliant and non compliant ones:
applications-gnome.menu
--menu-type=applications-gnome
applications.menu
*standard* (no parameter needs to set)
documentation.menu
--menu-type=documentation
gnomecc.menu
--menu-type=gnomecc
kde4-applications.menu
--desktop=kde4(-)
kde-information.menu
--desktop=kde(-) --menu-type=information
preferences.menu
--menu-type=preferences
server-settings.menu
--desktop=server(-) --menu-type=settings OR
--menu-type=server-settings
settings.menu
--menu-type=settings --title=FvwmSettings
start-here.menu
--desktop=start(-) --menu-type=here OR
--menu-type=start-here
system-settings.menu
--desktop=system(-) --menu-type=settings
applications-gnome.menu
--desktop=applications(-) --menu-type=gnome
kde4-applications.menu
--desktop=kde4(-)

Okay, it's not nice how the parameters are misused but menus like
applications-gnome.menu are poor also. And they doesn't follow the xdg spec.

Not happy with the whole scheme.
Convince me not to dump it.
What we can do is to rename the parameters like
--desktop - --menu-prefix
--menu-type - --menu-postfix

Seems to me, the best way fvwm can interface with this mess
is to just treat the whole name as one thing.

To merge --desktop and --menu-type to e.g --menu-name would anul the
xdg automatism.

All systems that I've analyzed has an applications.menu (except Debian)
and they use mostly a {gnome,kde4,kde,xfce,lxde,...}-applications.menu
for each installed desktop environment. Also for system wide menus like
preferences, settings: no ${XDG_MENU_PREFIX} infront and if there is a desktop
specific one they added the desktop name (kde4-settings). From that
point of view
all is ok with the implementation in fvwm-menu-desktop (except that we not check
the Env var ${XDG_MENU_PREFIX} as is described in the xdg spec).

The only thing what I would do is, if you prefer the complete prefix as an
argument renaming --desktop to --menu-prefix because --desktop associates
to use a desktop name *without* a trailing '-'

Thomas

Btw about renaming ... we should rename the following parameters for better
understanding:
--size - --icon-size or --mini-icon-size
--with-titles - --with-menu-titles

With the last one I am in doubt. It's every time a tightrope walk between
short as possible and a maximum of expressiveness.

Re: [Patch] fvwm-menu-desktop improvements

[Thomas Funk]

Dan Espen des...@verizon.net wrote:
Could you redo patch 3 in light of current CVS.
Attached.

The way checkmenu wipes out it's input,
the value of menu in the abort message is always
None. Gives me a syntax error.
You're right. Changed it from 'check' to 
'install_prefix+desktop+menu_type+.menu ...'
because check could changed to 'debian-menu.menu' and that could 
irritate a user:
--desktop not set and menu-type not set - normally 'applications.menu' 
should appear

and not 'debian-menu.menu' ...


About your comment in fvwm-menu-desktop.in in cvs
#?desktop=a + '-'
The '-' is important because if desktop is not empty and the menu name 
will be built

then the following happens:
check=install_prefix+desktop+menu_type+'.menu'
check='/etc/xdg/menus/'+'gnome'+'applications'+'.menu'
- /etc/xdg/menus/gnomeapplications.menu
if the '-' will be inserted into the check string and desktop is empty 
this will be built:

/etc/xdg/menus/-applications.menu
- no applications.menu will be found anymore

I've added a forgotten check - if user wants explicitly build a debian 
menu (--desktop=debian)

the menu-type must change:
if desktop == 'debian-':
menu_type = 'menu'

Also, if a user wants a preference, settings or what else menu he/she 
must change the
title of the top menu name used by Popup command. I reanimated --title 
which was used

in the past for that. Hope these two adds are ok.

Could you add something to usage for --desktop and --menu-type.
Yep, done ^^

Thomas


--- ../cvs/fvwm/bin/fvwm-menu-desktop.in	2012-06-27 19:41:57.303273477 +0200
+++ fvwm-menu-desktop.in.py	2012-06-27 23:27:55.164621906 +0200
@@ -42,6 +42,7 @@
 import os.path
 import os
 from xdg.DesktopEntry import *
+import fnmatch
 
 
 def main ():
@@ -81,7 +82,6 @@
'png-icons-path',
'submenu-name-prefix',
'time-limit',
-   'title',
'tran-icons-path',
'tran-mini-icons-path',
'type',
@@ -98,7 +98,7 @@
 try:
 opts, args = getopt.getopt(sys.argv[1:], hs:t:vw,
[help, verbose, enable-mini-icons, with-titles,
-desktop=, size=, theme=, install-prefix=, menu-type=]+obs_args+equaled_obs_parms)
+desktop=, size=, theme=, install-prefix=, menu-type=, title=]+obs_args+equaled_obs_parms)
 except getopt.GetoptError, err:
 # print help information and exit:
 print str(err) # will print something like option -a not recognized
@@ -112,7 +112,7 @@
 theme='gnome'
 icon_dir=~/.fvwm/icons
 top='FvwmMenu'
-install_prefix = '/etc/xdg/menus/'
+install_prefix = ''
 menu_type = 'applications'
 with_titles = False
 
@@ -125,8 +125,9 @@
 elif o in (--enable-mini-icons) :
 force=True
 elif o in (--desktop) :
-#?desktop=a + '-'
-desktop=a
+desktop=a + '-'
+elif o in (--title) :
+top=a
 elif o in (--install-prefix) :
 if a and not os.path.isabs(a):
 assert False, install-prefix must be an absolute path
@@ -149,27 +150,41 @@
 else:
 assert False, unhandled option
 
-check=install_prefix+desktop+menu_type+'.menu'
+if desktop == 'debian-':
+menu_type = 'menu'
+
+check=desktop+menu_type+'.menu'
 menu = checkmenu(check)
 
-if menu == None and menu_type == 'applications':
+if menu == None and desktop == '' and menu_type == 'applications':
 # it could be a Debian system
-check = install_prefix + 'debian-menu.menu'
+check = 'debian-menu.menu'
 menu = checkmenu(check)
 
 if menu == None:
-# fixme, no point in trying to print None.
-sys.stderr.write(check+ not available on this system. Exiting...\n)
+sys.stderr.write(install_prefix+desktop+menu_type+.menu not available on this system. Exiting...\n)
 sys.exit()
 else:
 parsemenu(xdg.Menu.parse(menu), top)
  
-def checkmenu(menu):
-if not os.path.exists(menu):
-menu = None
+def checkmenu(menu_name):
+stop = False
+menu = None
+if install_prefix == '':
+for dir in xdg_config_dirs:
+dir = dir + '/menus'
+if os.path.exists(dir):
+dir_list = os.listdir(dir)
+for filename in fnmatch.filter(dir_list, menu_name):
+menu = os.path.join(dir, filename)
+stop = True
+if stop == True:
+break
+else:
+if os.path.exists(install_prefix+menu):
+menu = install_prefix+menu
 return menu
 
-
 def printtext(text):
 print text.encode(utf-8)
 
@@ -191,9 +206,6 @@
 if not os.path.isdir(os.path.expanduser(icon_dir)):
 os.system(mkdir  + os.path.expanduser(icon_dir))
 
-if not 

Re: [Patch] fvwm-menu-desktop improvements

[Thomas Funk]

Dan Espen des...@verizon.net wrote:
I had some testing issues there.
I don't remember what they were but I got something like

--desktop gnome-

to work and left that comment behind.

Is there an xdg rule that makes '-' special?
--desktop with '-' is the $XDG_MENU_PREFIX

Seem to be saying that we should treat the whole name
as one thing.
For the users point of view --desktop=gnome is easier to remember than
--desktop=gnome-
It could happen that the '-' will be forgotten. For that I append it
inside fvwm-menu-desktop.

My personal preference is --desktop=gnome. But the other part is also
ok for me.

Thomas

Btw. If you decide for 'gnome-' don't forget to add the '-' in the help.

Re: [Patch] Fixing bugs and some improvements for fvwm-menu-desktop.in

[Thomas Funk]

2012/6/25 Dan Espen des...@verizon.net:
 - some menu entries doesn't work because of these trailing %U, %f,
 etc. Therefore these parts must be eliminated:
 Fix in parsemenu():
     m = re.compile('%[A-Z]?', re.I)
     :
             execProgram = m.sub('', desktop.getExec())

 Applied but I'm not so sure removing %A-Za-z from all exec commands
 is a good idea. Isn't there a more limited set of these?
I don't know. Must check. But as I compare the menu created by the old
fvwm-menu-desktop the exec commands look the same...

 some icons defined in the desktop files won't be created because they
 are svgs. But convert can't convert to .svg
 Fix in geticonfile() to convert also svgs:
     if not iconpath == None:
         extension = os.path.splitext(iconpath)[1]
     :
     if extension == '.svg':
         iconfile = iconfile.replace('.svg', '.png')

 If the icon called for is svg, why does this code assume
 there will be a .png file?  Not applied yet.
No no ... the iconfile is the destination created from the basename of
the source (iconpath):
  iconfile = os.path.join(os.path.expanduser(options.icon_dir),
  %ix%i- % (size, size) +
  os.path.basename(iconpath))

Convert needs a bitmap extension, otherwise an error occur. It cannot
convert a svg TO .svg but to png
Therefore I changed the extension of the iconfile.

 These fixes let the tool run in eclipse smoothless. But not on the
 command line.
 #!@PYTHON@
 doesn't work there. Switched back to
 #!/usr/bin/python

 Run the whole automake sequence and this should clear up.
Ah, ok. haven't compiled it yet.

Btw. did you have implemented a query for ./configure for python-xdg?
I used this in an sh install script:

module_found=`python -c import xdg 2/dev/null  echo 1`
if [ $module_found ==  ]
then
  echo -e not found
else
  echo -e found
fi  

 Sure appreciate the help.
You're welcome :-)

Thomas

[Patch] fvwm-menu-desktop improvements

[Thomas Funk]

Hi Dan,

I've attached 2 patches again.

fvwm-menu-desktop.in.p2.patch - only improvements. Should be patched 
after the first patch.

- I've added two new options:
  '--menu-type' and changed '--desktop' to it's named behavior.
Before:
  --desktop=applications/gnome-applications [applications]
Now:
  --desktop=gnome/kde/xfce ['']
  --menu-type=applications/preferences/settings [applications]

  '-w' or '--with-titles'
I like menus with titles, so this option enables them :-)

Also, if no applications.menu found it will search for debian-menu.menu. 
If all fails a message will print to stderr.



fvwm-menu-desktop.in.p3.patch - implements the full xdg spec. Should be 
patched after patch 2


- Now fvwm-menu-desktop.in searches in the xdg directories. I've changed 
--install-prefix='/etc/xdg/menus' to --install-prefix='' but if user 
wants to search in a specific path it can be used anyway. Then the xdg 
way will not used.


I know, patches over patches ... but now it works hopefully on all systems.

I haven't changed the help because I don't know what of these changes 
you agree with.


Thomas

--- Old/fvwm-menu-desktop.in.p1.py	2012-06-24 14:36:09.002394717 +0200
+++ Old/fvwm-menu-desktop.in.p2.py	2012-06-24 14:52:46.900522522 +0200
@@ -96,23 +96,25 @@
 dashed_obs_parms.append('--'+a)
 
 try:
-opts, args = getopt.getopt(sys.argv[1:], hs:t:v,
-   [help, verbose, enable-mini-icons,
-desktop=, size=, theme=, install-prefix=]+obs_args+equaled_obs_parms)
+opts, args = getopt.getopt(sys.argv[1:], hs:t:vw,
+   [help, verbose, enable-mini-icons, with-titles,
+desktop=, size=, theme=, install-prefix=, menu-type=]+obs_args+equaled_obs_parms)
 except getopt.GetoptError, err:
 # print help information and exit:
 print str(err) # will print something like option -a not recognized
 print usage
 sys.exit(2)
-global verbose, force, size, theme, icon_dir, top, install_prefix
+global verbose, force, size, theme, icon_dir, top, install_prefix, menu_type, with_titles
 verbose = False
 force = False
-desktop='applications'
+desktop=''
 size=24
 theme='gnome'
 icon_dir=~/.fvwm/icons
 top='FvwmMenu'
 install_prefix = '/etc/xdg/menus/'
+menu_type = 'applications'
+with_titles = False
 
 for o, a in opts:
 if o == -v:
@@ -123,7 +125,7 @@
 elif o in (--enable-mini-icons) :
 force=True
 elif o in (--desktop) :
-desktop=a
+desktop=a + '-'
 elif o in (--install-prefix) :
 if a and not os.path.isabs(a):
 assert False, install-prefix must be an absolute path
@@ -136,25 +138,32 @@
 size = int(a)
 elif o in (--theme) :
 theme = a
+elif o in (--menu-type) :
+menu_type = a
+elif o in (-w,--with-titles) :
+with_titles = True
 elif o in (str(dashed_obs_args+dashed_obs_parms)) :
 # Ignore
 sys.stderr.write( Arg +o+ is obsolete and ignored\n )
 else:
 assert False, unhandled option
 
-# If desktop lacks a trailing .menu, put one there.
-if (not re.search('.*[.]menu$',desktop)) : # no trailing .menu
-  desktop=desktop+'.menu'
-menu=install_prefix+desktop
-# If desktop arg has leading slash, it's a full path
-if (desktop[0] == '/'):
-menu=desktop
+menu = checkmenu(install_prefix+desktop+menu_type+'.menu')
 
-if os.path.exists(menu):
-parsemenu(xdg.Menu.parse(menu), top)
-else:
-print menu +  not available on this system. Exiting...
+if menu == None and menu_type == 'applications':
+# it could be a Debian system
+menu = checkmenu(install_prefix + 'debian-menu.menu')
 
+if menu == None:
+sys.stderr.write( menu +  not available on this system. Exiting...\n )
+sys.exit()
+else:
+parsemenu(xdg.Menu.parse(menu), top)
+ 
+def checkmenu(menu):
+if not os.path.exists(menu):
+menu = None
+return menu
 
 def printtext(text):
 print text.encode(utf-8)
@@ -207,7 +216,10 @@
 if not name:
 name = menu.getPath()
 printtext('DestroyMenu %s' % name)
-printtext('AddToMenu %s' % name)
+if with_titles:
+printtext('AddToMenu %s %s Title' % (name, name))
+else:
+printtext('AddToMenu %s' % name)
 for entry in menu.getEntries():
 	if isinstance(entry, xdg.Menu.Menu):
 	printmenu(entry.getName(), entry.getIcon(),

--- Old/fvwm-menu-desktop.in.p2.py	2012-06-24 14:52:46.900522522 +0200
+++ fvwm-menu-desktop.py	2012-06-24 14:52:59.104693184 +0200
@@ -41,6 +41,7 @@
 import xdg.Locale
 import os.path
 import os
+import fnmatch
 from xdg.DesktopEntry import *
 
 

[Patch] Fixing bugs and some improvements for fvwm-menu-desktop.in

[Thomas Funk]

Hi Dan,

I've analyzed your rewritten fvwm-menu-desktop.in and there are couple 
of things.


- under Debian systems it doesn't work out of the box, because there's 
no applications.menu. Therefore the program ends in some python errors:

pydev debugger: starting
Traceback (most recent call last):
  File 
/opt/eclipse/eclipse/plugins/org.python.pydev.debug_2.5.0.2012040618/pysrc/pydevd.py, 
line 1346, in module

debugger.run(setup['file'], None, None)
  File 
/opt/eclipse/eclipse/plugins/org.python.pydev.debug_2.5.0.2012040618/pysrc/pydevd.py, 
line 1060, in run

pydev_imports.execfile(file, globals, locals) #execute the script
  File 
/media/daten/shared/sourcen/Fvwm-xdg-menu/fvwm-menu-desktop.py, line 
273, in module

main()
  File 
/media/daten/shared/sourcen/Fvwm-xdg-menu/fvwm-menu-desktop.py, line 
153, in main

parsemenu(xdg.Menu.parse(menu), top)
  File /usr/lib/pymodules/python2.7/xdg/Menu.py, line 523, in parse
doc = xml.dom.minidom.parse(filename)
  File /usr/lib/python2.7/xml/dom/minidom.py, line 1920, in parse
return expatbuilder.parse(file)
  File /usr/lib/python2.7/xml/dom/expatbuilder.py, line 922, in parse
fp = open(file, 'rb')
IOError: [Errno 2] No such file or directory: 
'/etc/xdg/menus/applications.menu'


It must be checked if it exist *before* it will be parsed because the 
parse routine in xdg.Menu doesn't do that.

Fix in main():
if os.path.exists(menu):
parsemenu(xdg.Menu.parse(menu), top)
else:
print menu +  not available on this system. Exiting...

- some menu entries doesn't work because of these trailing %U, %f, etc. 
Therefore these parts must be eliminated:

Fix in parsemenu():
m = re.compile('%[A-Z]?', re.I)
:
execProgram = m.sub('', desktop.getExec())
printmenu(desktop.getName(), desktop.getIcon(),
  Exec exec  +   + execProgram)

- if you want to use icons with --enable-mini-icons no icons can be 
saved because no icons dir exist. Therefore it has to be explicit created:

if not os.path.isdir(os.path.expanduser(icon_dir)):
os.system(mkdir  + os.path.expanduser(icon_dir))

some icons defined in the desktop files won't be created because they 
are svgs. But convert can't convert to .svg

Fix in geticonfile() to convert also svgs:
if not iconpath == None:
extension = os.path.splitext(iconpath)[1]
:
if extension == '.svg':
iconfile = iconfile.replace('.svg', '.png')

These fixes let the tool run in eclipse smoothless. But not on the 
command line.

#!@PYTHON@
doesn't work there. Switched back to
#!/usr/bin/python

The
print 'DestroyMenu %s' % name
throws errors
Traceback (most recent call last):
  File ./fvwm-menu-desktop.py, line 289, in module
main()
  File ./fvwm-menu-desktop.py, line 154, in main
parsemenu(xdg.Menu.parse(menu), top)
  File ./fvwm-menu-desktop.py, line 226, in parsemenu
parsemenu(entry)
  File ./fvwm-menu-desktop.py, line 209, in parsemenu
print 'DestroyMenu %s' % name
UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in 
position 14: ordinal not in range(128)


changed it to
printtext('DestroyMenu %s' % name)

Btw about your comment
# themes not working: hicolor is a required theme  I see lots of 
themes but none seem to affect much
- it works, but the icons for popups doesn't exist in the hicolor theme 
because they are hardcoded in getdefaulticonfile(). I will look into it 
later.


Hope these fixes are ok for you.

Thomas

--- ../cvs/fvwm/bin/fvwm-menu-desktop.in	2012-06-22 20:28:55.671420675 +0200
+++ fvwm-menu-desktop.py	2012-06-23 12:41:42.633766537 +0200
@@ -1,4 +1,4 @@
-#!@PYTHON@
+#!/usr/bin/python
  
 # Modification History
 
@@ -107,7 +107,7 @@
 global verbose, force, size, theme, icon_dir, top, install_prefix
 verbose = False
 force = False
-desktop='applications'
+desktop='gnome-applications'
 size=24
 theme='gnome'
 icon_dir=~/.fvwm/icons
@@ -150,8 +150,11 @@
 if (desktop[0] == '/'):
 menu=desktop
 
-parsemenu(xdg.Menu.parse(menu), top)
-
+if os.path.exists(menu):
+parsemenu(xdg.Menu.parse(menu), top)
+else:
+print menu +  not available on this system. Exiting...
+
 
 def printtext(text):
 print text.encode(utf-8)
@@ -159,6 +162,9 @@
 def geticonfile(icon):
 iconpath = xdg.IconTheme.getIconPath(icon, size, theme, [png, xpm])
 
+if not iconpath == None:
+extension = os.path.splitext(iconpath)[1]
+
 if not iconpath:
 return None
 
@@ -168,9 +174,16 @@
 if iconpath.find(%ix%i % (size, size)) = 0: # ugly hack!!!
 return iconpath
 
+if not os.path.isdir(os.path.expanduser(icon_dir)):
+os.system(mkdir  + os.path.expanduser(icon_dir))
+
 iconfile = os.path.join(os.path.expanduser(icon_dir),
 %ix%i- % (size, size) + 
 os.path.basename(iconpath))
+
+if extension == '.svg':

[Patch] for fvwm-menu-desktop

[Thomas Funk]

Hi,

attached is a patch for fvwm-menu-desktop to fix the following:

- removing obsolete entries in help
- fix bug that debian menu wouldn't merged if merge entry in the
parent menu exist (worked in versions  2.6.4)
- complete xdg spec that search will start in $XDG_CONFIG_HOME and
then in $XDG_CONFIG_DIRS
- add two options:
  --system- to start search in $XDG_CONFIG_DIRS only
  --desktop=desktop - for e.g. gnome, kde, lxde, debian ... to
fill $XDG_MENU_PREFIX

tested under Debian and OpenSusE

Regards,
Thomas


fvwm-menu-desktop.patch
Description: Binary data

Re: [Patch] for fvwm-menu-desktop

[Thomas Funk]

sorry, patch with -u attached.

Thomas


2012/6/21 Thomas Adam tho...@fvwm.org:
 On Thu, Jun 21, 2012 at 03:31:58PM +0200, Thomas Funk wrote:
 Hi,

 attached is a patch for fvwm-menu-desktop to fix the following:

 You *must* send this in unified diff format, not context diff, or a mixture
 of the two.  See:  docs/DEVELOPER-CVS.

 -- Thomas Adam


fvwm-menu-desktop.patch
Description: Binary data

Re: [Patch] for fvwm-menu-desktop

[Thomas Funk]

Dan Espen des...@verizon.net wrotes:

As for root-menu vs. xdg-menu,
doesn't make much difference to me.
The tool creates a menu hierarchy.
The argument indicates a starting point.
I won't kick of a useless discussion about a named function. It's equal for me.
Important is, that fvwm-menu-desktop will work. That's all.

Regards,
Thomas

fvwm html pages with asciidoc

[Thomas Funk]

Hi Thomas,

I've played around with the asciidoc manpages to include them into fvwm 
html

pages (interesting for fvwm-web).

Atached is a working example which uses two asciidoc manpages (FvwmForm and
FvwmTheme) inside the actual Fvwm page.

It is based on the asciidoc webpage example. On Debian you'll find it under
/usr/share/doc/asciidoc/examples/website/


Used componnents:
- layout_fvwm.conf to build the manpage inside a fvwm page

- build-website.sh
create the html pages

- manpage.css -
stylesheet for the manpage formating. It is very poor at the
moment, and need some changes to fit the fvwm look. But that's no 
prob, cause

if you create a standalone asciidoc html page with

asciidoc -f manpage manpage.txt

the complete formating will be found at the beginning of the page.

- style.css
the original fvwm style sheet

I've put two links for testing in FvwmForm:
- external link: FvwmTheme - in *FvwmForm: Colorset n
- internal link: DEFAULTS - in *FvwmForm: Back color

These links doesn't occur inside a manpage. See for yourself - create with

create-manpage.sh FvwmForm.txt

a manpage and view it.


I hope this will help to switch completely to asciidoc. It's amazing how 
easy it

is to build different document types with one asciidoc document.

Cheers,
Thomas


asciidoc-html.tgz
Description: application/compressed-tar

Re: Status fvwm-menu-desktop

[Thomas Funk]

Hi Dan,

I've been working on it. I've restructured the menu as Thomas suggested some 
weeks ago. I am now at that point how to merge several menus to one (there are 
often programs listed in the kde but not in gnome or debian menu or vice 
versa). But it's not very simple. Also some other parts which the original 
fvwm-menu-desktop script doesn't bear in mind with other distributions. I've 
sent a customized fvwm-menu-desktop script weeks ago but this script isn't that 
which could be committed anyway.

If anyone can help me to get an idea how I can implement this merging in a good 
an nice way shout.

Thanks,
Thomas

--
What is the exact difference between a 'terminal', a 'shell', a 'tty' and a 
'console'?
A terminal is at the end of an electric wire, a shell is the home of a turtle, 
tty is a strange abbreviation and a console is a kind of cabinet. -- Gilles

-Ursprüngliche Nachricht-
Von: Dan Espen des...@verizon.net
Gesendet: 19.12.2011 22:48:00
An: fvwm-workers@fvwm.org
Betreff: Status fvwm-menu-desktop


We had a recent patch for fvwm-menu-desktop.
I never got around to taking a look.
Did it get committed?

I recently installed Fedora 16 and fvwm-menu-desktop
stopped working. It looks like it never finds
the .desktop files in /usr/share/applications.

I made a quick fix by adding /usr/share/applications
to @legacy_dirs in function get_KDE_legacy_dirs.
I think this directory must have been in previous xdg config
files but isn't there anymore.

--
Dan Espen



___
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

Re: FVWM: Rounded corners patch

[Thomas Funk]

Not officially. ArchLinux might have an updated set though. See their AUR,
perhaps?

Is it possible to put the rounded corner patch into the official fvwm?

It would be a very nice feature ^^

Regards,
Thomas

--
What is the exact difference between a 'terminal', a 'shell', a 'tty' and a 
'console'?
A terminal is at the end of an electric wire, a shell is the home of a turtle, 
tty is a strange abbreviation and a console is a kind of cabinet. -- Gilles


___
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

Re: FVWM: Stepping down from next year.

[Thomas Funk]

Von: des...@verizon.net
Gesendet: 07.11.2011 23:24:00

Having a single maintainer is too much of a burden. I've always been
surprised that anyone would take on that role.

Yes, that's probably true. I think Thomas is at the end of his power.
The permanent attacks against him the last time weren't very cooperative at all 
...

If someone comes to this list with a great new idea and convinces the
few of us that hang around that he's qualified he'll get commit
privileges and Fvwm get new capabilities.

A great new idea ... there are many ideas but for these ideas we need people
who are willing to show them with config examples and accept constructive 
reviews.
We need also a good default config for new users to show what is possible with 
Fvwm.
We started months ago with them. I created a config based on that ideas but it 
must
be tested and need feedback from the community.

It's pretty hard to work up any ambition when Fvwm already does
everything a person wants. (It does for me.)

For me too, but we need more than comments what is bad and should change ...

Hopefully we have the mechanisms in place for this project to carry
on to serve that niche of users that want total control and don't need
GUI's to write configuration files.

Thomas started with his wiki for that but it should extend to get a rich pool 
of information
around of Fvwm.

Thomas

--
What is the exact difference between a 'terminal', a 'shell', a 'tty' and a 
'console'?
A terminal is at the end of an electric wire, a shell is the home of a turtle, 
tty is a strange abbreviation and a console is a kind of cabinet. -- Gilles

___
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192