Re: fvwm frees invalid pointer
On Sun, Sep 15, 2013 at 10:13:29AM -0400, Dan Espen wrote:
D> Gleb Smirnoff writes:
D>
D> > Configuration Information [Automatically generated, do not change]:
D> > 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
D> > compiler flags: cc -Wall -Wno-implicit-int -g -I/usr/local/include
D> >
D> > FVWM Version: 2.6.5
D> > FVWM_MODULEDIR: /usr/local/libexec/fvwm/2.6.5
D> > FVWM_DATADIR: /usr/local/share/fvwm
D> > FVWM_USERDIR: /home/glebius/.fvwm
D> >
D> > Description:
D> > Fvwm crashes in free() in libc couple of times per day. Crashes
D> > are different, and call path can involve different libraries,
D> > but the problem is always in free().
D> >
D> > Here is an example:
D> >
D> > (gdb) bt
D> > #0 __free (ptr=0x796b6369745321) at arena.h:504
D> > #1 0x000800bc02a7 in XFreeStringList (list=0x804a18c08) at
TextToStr.c:113
D> > #2 0x004de0a3 in FlocaleFreeNameProperty (ptext=0x804a05010)
D> > at Flocale.c:2358
D>
D> Sorry, I've tried just setting LC_TYPE to ru_RU.UTF-8.
D> That doesn't seem to be sufficient to cause the problem.
A crash happens one or two times during working day. Not every windows
close causes crash.
D> Any more hint's would be helpful.
D>
D> If you know how to use gdb, a print of ptext might be helpful.
(gdb) p *ptext
$1 = {
name = 0x804a29500 "Шо�\201�\201е�\200 зимой на оживленной
п�\200иго�\200одной �\202�\200а�\201�\201е - С�\202�\200ани�\206а 26 - Mozilla
Firefox", name_list = 0x804a18c08}
(gdb) p *ptext->name_list
$2 = 0x796b6369745321
(gdb)
Another crash:
(gdb) p *ptext
$1 = {
name = 0x804a2a480 "«�\227де�\201�\214 должн�\213 б�\213ли
по�\201�\202�\200ои�\202�\214 новое об�\211ежи�\202ие �\234�\223У» - Public
forum of MSU united student networks - Mozilla Firefox",
name_list = 0x804a18a50}
(gdb) p *ptext->name_list
$2 = 0x163
It looks like the memory garbaging happens earlier than we encounter assertion,
and actually the trace from core isn't a place where error lives.
Here I have a crash with different trace. Now assertion is hit in malloc(),
not free().
(gdb) bt
#0 arena_run_reg_alloc (run=0x804827000, bin_info=0x803134d90) at bitmap.h:99
#1 0x000802e3d081 in __jemalloc_arena_malloc_small (arena=0x8044000c0,
size=96, zero=false)
at /usr/obj/usr/src/head/lib/libc/jemalloc_arena.c:1435
#2 0x000802e4434f in __malloc (size=Cannot access memory at address 0x1
) at arena.h:918
#3 0x0050b888 in safemalloc (length=88) at safemalloc.c:43
#4 0x004c1451 in make_named_packet (len=0x7fffd1ec,
event_type=2048, name=0x804a3d6e0 "Facebook - Mozilla Firefox", num=3)
at module_interface.c:407
#5 0x004c1567 in BroadcastName (event_type=2048, data1=33554549,
data2=4195027, data3=34437353472,
name=0x804a3d6e0 "Facebook - Mozilla Firefox") at module_interface.c:455
#6 0x004c166c in BroadcastWindowIconNames (fw=0x804a05000, window=0,
icon=1) at module_interface.c:479
#7 0x004d4085 in EWMH_WMIconName (fw=0x804a05000, ev=0x73cb28,
style=0x0, any=0) at ewmh_names.c:190
#8 0x004abd6f in EWMH_ProcessPropertyNotify (exc=0x80482b300)
at ewmh_events.c:1620
#9 0x004468ea in HandlePropertyNotify (ea=0x7fffd488)
at events.c:3628
#10 0x0044777f in dispatch_event (e=0x7fffd4c0) at events.c:4135
#11 0x004481a1 in HandleEvents () at events.c:4179
#12 0x00477293 in main (argc=2, argv=0x7fffdbf0) at fvwm.c:2591
(gdb) fr 3
#3 0x0050b888 in safemalloc (length=88) at safemalloc.c:43
43 ptr = malloc(length);
(gdb) p length
$1 = 88
(gdb)
--
Totus tuus, Glebius.
Re: Window and Icon title behavior inconsistent/incorrect, fvwm repeatable crash
Thomas Adam wrote: On Sun, Sep 15, 2013 at 03:25:15AM -0700, Victor wrote: Style "*" IconTitleFormat %i (%n) Style "*" TitleFormat %n (%i) With the TitleFormat string set as above, the window manager would crash when opening an new window. I'd also tested this in my rc file, which would cause fvwm to core dump upon login. Try the attached patch, please. I can only verify it looks correct. I've not tested it. If it doesn't work, or doesn't provide the same effect as the one you're after, someone else can pick it up and run with it, I'm sure. -- Thomas Adam Thank you Thomas. The patch does prevent the crash, however it also prevents the window from ever updating the %i. Out of curiosity, I changed the test before the break to only: if (fw->icon_name.name == NULL) With this, the behavior of the window and icon titles the same as my initial email, however without the crash, which makes troubleshooting quite a bit easier. FWIW, I also tested a change to call fvwm_msg(WARN) before the break, and I could verify that the message would appear each time a window was created. Thanks, -Victor
Re: Window and Icon title behavior inconsistent/incorrect, fvwm repeatable crash
On 16 September 2013 16:21, Victor wrote: > Thank you Thomas. The patch does prevent the crash, however it also > prevents the window from ever updating the %i. Out of curiosity, I changed > the test before the break to only: > if (fw->icon_name.name == NULL) Right. Does this therefore solve your original problem? -- Thomas Adam
Re: CVS tadam: TitleFormat: Don't crash for NULL icon name
c...@math.uh.edu writes: > CVSROOT: /home/cvs/fvwm > Module name: fvwm > Changes by: tadam 13/09/16 10:56:58 > > Modified files: > . : Tag: branch-2_6 ChangeLog > fvwm : Tag: branch-2_6 add_window.c > > Log message: > TitleFormat: Don't crash for NULL icon name > > When using %i on a window which doesn't have an icon name set, don't try and > dereference that, else FVWM will crash. > > That's it, guys! I am gone from this project. > > I hope everything works out. :) Like the long list of primary contributors before you, I (and we) appreciate your efforts. Hope you've gained something along the way. My efforts slowed down a long time ago since Fvwm does everything I want, but I feel obligated to hang on to pay back guys like you who have contributed so much. May you find fulfillment in your future endeavors. -- Dan Espen
Re: Window and Icon title behavior inconsistent/incorrect, fvwm repeatable crash
No, although it prevents the crash, the window and icon titles are still incorrect as before. -Victor Thomas Adam wrote: On 16 September 2013 16:21, Victor wrote: Thank you Thomas. The patch does prevent the crash, however it also prevents the window from ever updating the %i. Out of curiosity, I changed the test before the break to only: if (fw->icon_name.name == NULL) Right. Does this therefore solve your original problem? -- Thomas Adam
Re: CVS tadam: TitleFormat: Don't crash for NULL icon name
On Mon, Sep 16, 2013 at 12:09:39PM -0400, Dan Espen wrote:
> c...@math.uh.edu writes:
>
> > CVSROOT:/home/cvs/fvwm
> > Module name:fvwm
> > Changes by: tadam 13/09/16 10:56:58
> >
> > Modified files:
> > . : Tag: branch-2_6 ChangeLog
> > fvwm : Tag: branch-2_6 add_window.c
> >
> > Log message:
> > TitleFormat: Don't crash for NULL icon name
> >
> > When using %i on a window which doesn't have an icon name set, don't try and
> > dereference that, else FVWM will crash.
> >
> > That's it, guys! I am gone from this project.
> >
> > I hope everything works out. :)
>
> Like the long list of primary contributors before you,
> I (and we) appreciate your efforts.
>
> Hope you've gained something along the way.
>
> My efforts slowed down a long time ago since Fvwm does everything
> I want, but I feel obligated to hang on to pay back guys like
> you who have contributed so much.
>
> May you find fulfillment in your future endeavors.
Thanks, Dan. I've learnt a lot working on this, that's for sure. I want to
thank you for all your help as well over the years; you've provided some
great insight in to the different areas of FVWM I've worked on. Thank you
for that.
Kindly,
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
CVS tadam: TitleFormat: Don't crash for NULL icon name
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: tadam 13/09/16 10:56:58 Modified files: . : Tag: branch-2_6 ChangeLog fvwm : Tag: branch-2_6 add_window.c Log message: TitleFormat: Don't crash for NULL icon name When using %i on a window which doesn't have an icon name set, don't try and dereference that, else FVWM will crash. That's it, guys! I am gone from this project. I hope everything works out. :)
Re: CVS tadam: TitleFormat: Don't crash for NULL icon name
-- Thomas Adam [2013-09-16 17:21:55 +0100]: > > That's it, guys! I am gone from this project. > Ditto to Dan's sentiment, Thomas. I pass along my earnest thanks for all you've contributed here. Even as a very infrequent visitor to the list, it's clear your technical work and responsiveness have been exemplary. Yes, the occasional friction and a little controversial from time to time too, but all in all you've really been a great help to a great many users. (And hey, what fun would any mailing list be without the occasional argument and controversy now & then. :)) Best to you in whatever calls you, and a sincere thanks for your work! Regards, Glenn P.S. You still owe me a postcard. :))
Re: fvwm-xdg-menu: additonal FreeDesktop categories support
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
fvwm-xdg-menu: additonal FreeDesktop categories support
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] 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? Best, Dominique
Re: FVWM: Forums and Wiki need new maintainers/homes
On 09/15/2013 01:23 PM, Thomas Adam wrote: 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. I talked to Thomas and to keep the data alive I am taking the wiki and will now host it at fvwmforums.org/wiki and since I am already hosting the forums I just need to take control of the domain to get the responsibilities out of Thomas' hands. Thank you Thomas for all you have done for fvwm over the years and passing this data on as so it won't be lost to the community. I will keep an aloof eye and of course backups of the data just in case, but over all I will not be actively moderating the sites. I am able to host these sights for the foreseeable future and if anyone wants to step up and add to them or moderate them more actively, we can deal with this at that time. I expect the transition to happen sometime this week. jaimos
Re: fvwm-xdg-menu: additonal FreeDesktop categories support
On lun. 16/09/13 22:41 , Thomas Funk 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. > 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. > > 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. 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. 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: Other xfce-other.directory 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? Dominique > > Thomas > > > > Best, > > Dominique > > > > Links: > -- > [1] > http://awebmail.vtx.ch/parse.php?redirect=https://github.com/domichel/fvwm- > xdg-menu >
Re: fvwm frees invalid pointer
> 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. My reproduction procedure involves more superstition than science, so it's probably less than helpful. I can't get it to work myself when I move to a different computer, and can't find any identifiable settings that should have an impact: set LC_CTYPE, start the gimp, open a .jpg file, use "save as" to save to a new filename, accept the compression settings, select file-> close, then file->quit. If that doesn't work the first time... save yourself some time and don't try again. If it does work, it seems to repeat almost every time. I haven't figured out what's going on yet, but here are my observations so far: (1) The LC_CTYPE environment variable is causing gimp/firefox/whatever to use names that are localized, which creates a name_list in Flocale.c. This means that the LC_CTYPE variable does NOT need to be set when launching FVWM. (2) Just before the crash, I see two completely different functions causing the same name_list to be freed. a) The first to free is within EWMH_WMName(), when it calls free_window_names(fw, True, False). This ultimately frees fw->name.name_list. b) The second free is within destroy_icon(), when it calls free_window_names(fw, False, True). This ultimately frees fw->icon_name.name_list. 3) For reasons I do not yet understand, in the crash situation fw->icon_name and fw->name of a different window have an identical name_list. When the second free of the list happens, fvwm crashes. I'll keep tinkering with this in my spare time, and I'll see what I can figure out. Jonathan
Re: fvwm frees invalid pointer
"Schaaf, Jonathan P (GE Healthcare)" writes: >> 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. > > My reproduction procedure involves more superstition than science, so > it's probably less than helpful. I can't get it to work myself when I > move to a different computer, and can't find any identifiable settings > that should have an impact: > > set LC_CTYPE, > start the gimp, > open a .jpg file, > use "save as" to save to a new filename, > accept the compression settings, > select file-> close, > then file->quit. > > If that doesn't work the first time... save yourself some time and > don't try again. If it does work, it seems to repeat almost every > time. > > I haven't figured out what's going on yet, but here are my observations so > far: > > (1) The LC_CTYPE environment variable is causing gimp/firefox/whatever > to use names that are localized, which creates a name_list in > Flocale.c. This means that the LC_CTYPE variable does NOT need to be > set when launching FVWM. > (2) Just before the crash, I see two completely different functions causing > the same name_list to be freed. >a) The first to free is within EWMH_WMName(), when it calls > free_window_names(fw, True, False). This ultimately frees > fw->name.name_list. >b) The second free is within destroy_icon(), when it calls > free_window_names(fw, False, True). This ultimately frees > fw->icon_name.name_list. > 3) For reasons I do not yet understand, in the crash situation > fw->icon_name and fw->name of a different window have an identical > name_list. When the second free of the list happens, fvwm crashes. > > I'll keep tinkering with this in my spare time, and I'll see what I can > figure out. There's a bit of a mess in there, but every free should be accompanied by a setting of the pointer to the freed item being set to NULL or in some cases "Untitled". As long as the areas are checked before free, everything should be okay. There's also the case where name and name_list represent the same object. That's why we see this in Flocale.c: if (ptext->name != NULL && ptext->name != *ptext->name_list) XFree(ptext->name); name and name_list represent the same thing so it only wants to free one of them. Like I say, a bit of a mess. But I need to be able to create the problem before making a fix. So far I'm unable to even get into the code, but I'm American and hopeless with foreign languages. I did get Russian in my title bars, but no tracing of the area with the abend. If this is inconsistent, efence might help. It will report problems even when it doesn't crash. -- Dan Espen
Re: fvwm-xdg-menu: additonal FreeDesktop categories support
michel dominique wote: > On lun. 16/09/13 22:41 , Thomas Funk 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 xfce-education.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- 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: > > Other > xfce-other.directory > > > > > > 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
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: fvwm-xdg-menu: additonal FreeDesktop categories support
On mar. 17/09/13 01:41 , Thomas Funk wrote: > michel dominique wote: > > On lun. 16/09/13 22:41 , Thomas Funk 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] [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 > xfce-education.directory It is why I change them to fvwm-*.directory. But I am doing one at a time and test it. XML is so easily confused by typos. > >> 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- directory entries. Use the xdg defaults. Then you have > translation per default. I am on Debian for now, and the only one I have are the xfce* files. I choose xfce at the beginning of the installation. So, I think the best think to do in order to be sure it will work in any cases, is to provide 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. > > > > 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. It is late. I will take a look another day. > > > 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. At that point... > >>> 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. The Tango theme is very popular. Also, in wm-icons, it is some icons that can be used for the extra categories, but they will not mix very well with the gnome or tango themes. I don't think any single theme will provide icons for all the possible additional categories. But I didn't looked at it for now. I think the best would be to provide these icons. Also, it is the Ken's Lester icon themes which are very nice and very popular on the Amiga OS, but GNU/Linux have a very poor support
