Re: fvwm frees invalid pointer

2013-09-15 Thread Dan Espen
Gleb Smirnoff gleb...@glebius.int.ru writes:

 Configuration Information [Automatically generated, do not change]:
 uname: FreeBSD think.nginx.com 10.0-CURRENT FreeBSD 10.0-CURRENT #11 r254323: 
 Wed Aug 14 17:08:51 MSK 2013 
 gleb...@think.nginx.com:/usr/obj/usr/src/head/sys/THINKPAD_X1  amd64
 compiler flags: cc -Wall -Wno-implicit-int -g -I/usr/local/include

 FVWM Version:   2.6.5
 FVWM_MODULEDIR: /usr/local/libexec/fvwm/2.6.5
 FVWM_DATADIR:   /usr/local/share/fvwm
 FVWM_USERDIR:   /home/glebius/.fvwm

 Description:
 Fvwm crashes in free() in libc couple of times per day. Crashes
 are different, and call path can involve different libraries,
 but the problem is always in free().

 Here is an example:

 (gdb) bt
 #0  __free (ptr=0x796b6369745321) at arena.h:504
 #1  0x000800bc02a7 in XFreeStringList (list=0x804a18c08) at 
 TextToStr.c:113
 #2  0x004de0a3 in FlocaleFreeNameProperty (ptext=0x804a05010)
 at Flocale.c:2358

Sorry, I've tried just setting LC_TYPE to ru_RU.UTF-8.
That doesn't seem to be sufficient to cause the problem.

Any more hint's would be helpful.

If you know how to use gdb, a print of ptext might be helpful.

-- 
Dan Espen



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

2013-09-15 Thread 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: Forums and Wiki need new maintainers/homes

2013-09-15 Thread Thomas Adam
On Thu, Sep 05, 2013 at 10:25:52PM +0100, Thomas Adam wrote:
 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.
 
 They're very low traffic sites, and the only real burden will be the PhpBB3
 maintenance.  Whomever wishes to take that on might want to consider
 upgrading that, and/or ditching it for something else entirely.  Note that
 there are still a number of users who use that site.  The wiki, by contrast,
 is less used.  In fact, much of the content therein has come from myself.
 
 One final thing to note, I own the domain name fvwmforums.org and am willing
 to hand that over, and furthermore, if you want to take this on, you'll need
 to consider hosting of the wiki since I won't want to be using my domain for
 this in the future.
 
 Jaimos Skriletz is currently very kindly hosting the forums for me.  I don't
 know if he's willing to continue that given I'm handing this over to someone
 else, so I'd consider hosting that yourself.  He's been exemplary in his
 role as host and has done a great job at ensuring no real downtime as a
 result, so thanks Jaimos!
 
 Any questions, please ask.

This thread seems to have decended in to a different subject altogether, so
I want to bring it back to my original question.  Those of you concerned
about FVWM's continued development can ask in a different thread---I do not
want nor care to discuss it here.

Answers to the question asked above would be good, please, otherwise you'll
lose the data in due course, and it will only be available on request for
those who wish to resurrect it.

Forgive the terseness of this, but I want you all to appreciate the impact
of this.

-- Thomas Adam

-- 
It was the cruelest game I've ever played and it's played inside my head.
-- Hush The Warmth, Gorky's Zygotic Mynci.