Re: Modules and receiving MX_* packets
Thomas Adam writes:
> Hi all,
>
> I thought I understood the nature of registering and receiving MX_* module
> packets, but I don't, so I'm hoping someone here will have the answer I'm
> looking for.
>
> I'm writing a C module for fvwm, and am amalgamating the different packet
> types in a table such as the following:
>
> struct fvwm_event {
> const char *event;
> unsigned longflag;
> } fe[] = {
> {"new_window", M_ADD_WINDOW},
> {"configure_window", M_CONFIGURE_WINDOW},
> {"new_page", M_NEW_PAGE},
> {"new_desk", M_NEW_DESK},
> {"enter_window", MX_ENTER_WINDOW|M_EXTENDED_MSG},
> {"leave_window", MX_LEAVE_WINDOW|M_EXTENDED_MSG},
> };
>
> In matching the events against the table above, I've deliberately added in
> M_EXTENDED_MSG for the MX_* events because this allows me to separate out the
> two distinct calls to SetMessageMask(). Hence:
>
> unsigned long non_mx_events;
> unsigned long mx_events;
>
> non_mx_events |= M_ADD_WINDOW|M_NEW_DESK;
> mx_events |= flag & ~M_EXTENDED_MSG;
>
> SetMessageMask(fvwm_fd, non_mx_events);
> SetMessageMask(fvwm_fd, mx_events);
>
>
> I believe I'm right in saying that fvwm expects to receive two distinct calls
> as above.
>
> This is working except that when receiving the packet from fvwm, I'm finding
> that the MX_* events are also matching non-MX events.
>
> For example, just requesting MX_ENTER_WINDOW means I end up receiving an event
> for M_NEW_DESK as well. This makes some sense, since M_NEW_DESK is defined as
> 1<<1, and MX_ENTER_WINDOW is also defined as 1<<1 | M_EXTENDED_MSG. It's
> almost as if I've made a mistake with M_EXTENDED_MSG somewhere. But it's
> implied when using MX_*.
>
> I've looked at other examples in fvwm such as FvwmAnimate, FvwmAuto, and none
> of them are doing anything different to MX_* packet handling, to what I'm
> trying to do.
>
> If anyone has any thoughts, I'd appreciate it.
I'm the culprit that added module message masks.
My intent that modules could select the messages they want.
I didn't add the MX part, that must have been someone else.
Since the MX flags are in a different word, perhaps modules should be
clearing both words before they set anything.
I'm not sure why this wasn't done with one large bit mask like the style
flags were done.
--
Dan Espen
Re: fvwm and casting from chrome
peter g writes: > Hi Everyone: > > i have a frustrating issue with fvwm and casting from google's chrome, > that maybe somebody has a workaround for. > > Normally, under any other WM i've tried (and also on windows), in the > chrome browser, choosing "Cast", will pop up a small window that asks > the user what device to cast to. Unfortunately in fvwm that little > window with those options does not show up. > > I've tried both with my config, but also with a very fvwm config such as: > key c A CM FvwmConsole > key r A CM Restart > Key u A CM Exec xterm > > If anyone has a work around, that would be much appreciated, as > casting, for better or worse, is very useful to me. I've got chromium, not google-chrome. I click on the 3 dots on the second line, a menu pops up, I select "cast". A dialog box pops up labeled "cast tab". It searches for devices and finds none. That dialog box is internal to the browser, it's not a window manager window. -- Dan Espen
Fvwm fullscreen with SDL2
I happened on a game that uses SDL2 to set the screen to:
640x480
fullscreen
In the past, SDL would change the video card resolution to 640x480.
This would be handled by a modeset in X.
With SDL2 it leaves the resolution alone and instead tells the video
card to magnify everything.
It looks like Fvwm is ignorant of the process, when I run an SDL2 app
Fvwm decorates the full screen window, so I see a titlebar and border.
Just a warning, it's difficult to work with this window, you can wind up
having to reboot.
I ran FvwmIdent from a titlebar button and the window iconified and the
apparent window resolution stayed at 640x480.
Just use caution if you test, I ended up using
a keyboard driven menu that used xrandr to restore my resolution to recover.
So, I'm guessing SDL2 sets some kind of hint that it's in full screen
and should not be decorated. I'm not sure how to find that hint. As
long as the window is full screen I can't run anything else.
Attached is a demo module. It's c++, uses SDL2.
Depending on your distro, you may need some packages, I needed
a few sdl devel packages:
I did:
sudo dnf install SDL2_*-devel
The demo creates a blue window which goes away after a few seconds.
You can see how to increase the time if you like.
A comment in the source code shows how to use FvwmCommand to get rid
of the unwanted border and titlebar which creates a workable 640x480
SDL2 window.
So I'll attempt to include the demo right inline, I tried to keep the
lines short enough, this is wind.cpp:
// Modification History
// Created on 04/09/20 by Dan Espen:
// - Demo fullscreen with SDL2
// - Full screen 640x480 window,
// terminate with escape,
// times out after a few secs.
#include
int main(int argc, char *argv[]) {
SDL_Window* window = NULL;
SDL_Renderer* renderer;
if (SDL_Init(SDL_INIT_VIDEO|SDL_INIT_EVENTS) != 0) {
SDL_Log("Failed to initialize SDL: %s", SDL_GetError());
return 1;
}
// fixme, the WM is adding titlebar and borders,
// To remove decoration, Run:
// FvwmCommand 'Style "mywind" NoTitle, BorderWidth 0, HandleWidth 0'
window = SDL_CreateWindow("mywind",
SDL_WINDOWPOS_UNDEFINED,
SDL_WINDOWPOS_UNDEFINED,
640, 480,
SDL_WINDOW_FULLSCREEN_DESKTOP
|SDL_WINDOW_BORDERLESS);
renderer = SDL_CreateRenderer(window, -1, 0);
SDL_SetRenderDrawColor(renderer,
0x80, 0x80, 0xFF, 0xFF); // RGBA
SDL_RenderClear(renderer);
SDL_RenderPresent(renderer);
bool quitting = false;
int how_long = 0;
while(!quitting) {
SDL_Event event;
while( SDL_PollEvent() ) {
switch (event.type) {
case SDL_QUIT:
quitting = true;
break;
case SDL_KEYDOWN:
switch (event.key.keysym.scancode) {
case SDL_SCANCODE_Q:
case SDL_SCANCODE_ESCAPE:
quitting = true;
printf("quit on key\n");
break;
}
}
}
SDL_Delay(3);
if (how_long++ > 500) {
quitting = true;
printf("quit on count\n");
}
}
SDL_DestroyWindow(window);
SDL_Quit();
exit(0);
}
// Local Variables:
// compile-command: "gcc wind.cpp -lSDL2 -I/usr/include/SDL2 -o wind && ./wind"
// End:
--
Dan Espen
Re: COVID-19: Hope everyone's well
Thomas Adam writes: > Hi everyone. > > Just emailing to check that everyone's OK and not suffering too much at the > moment. I know different countries are largely doing the same things as one > another -- and I'm working from home for the foreseeable. > > I really do hope no one's suffering and feeling unwell. Let's keep in touch, > please. > > Kindly, > Thomas Hi everyone, I've stopped all outside activities since March 9. I miss the gym, pool halls, and weekly visits to friends. I live by myself now so it's no fun to be here by myself. One upside, I keep finding projects around the house so lots of things are getting fixed. I really miss the gym. I was into my second year of really getting into shape. I have a set of weights in the basement but I'm finding it really hard to get motivated to work out at home. Must go do that now... Take care all. -- Dan Espen
Re: Next Steps
Thomas Adam <tho...@xteddy.org> writes: > Hi, > > Now that the copyright issue has been sorted out, and we're largely able to > resume things, I can't remember what we said about what the next steps were > with fvwm. > > I know we had some conversations around the state of fvwm2, with this odd > split between my deprecating a bunch of modules, and fvwm2-stable being a > branch which undoes this, but I recall we've drawn a line under this now. Or > rather, I will no longer personally be touching fvwm2 in any guise. AFAIAC, > I'm done with that. > > So it begs the question what to do next and how to approach doing that work. > There's a list of ideas I'd started either to write or collate from elsewhere, > and I know that Dominik has been kind enough to comment on some of those: > > https://github.com/fvwmorg/fvwm/blob/master/TODO.md > > There's some really good ideas there -- and there's the core of fvwm which > will really lend itself well to trying to improve and modernise things. I'm > keen on that point -- with a 20+ year old project, it's always good to take > the opportunity to weed/prune/modernise what's there when the opportunity > presents itself. It's something I tried to do in part with fvwm2, and failed. > > Thoughts welcome. It would be nice to see Fvwm actually work with RandR. Working would be sensing the change and moving windows into the new screen dimensions. Every once and a while I get the urge to try my 1600x1200 panel as 1200x1600. -- Dan Espen
Re: fvwm.org domain name
Jaimos Skriletz <jaimosskril...@gmail.com> writes: > On Sat, Feb 10, 2018 at 8:38 AM, Dan Espen <dan1es...@gmail.com> wrote: >> >> Hi, >> >> I've renewed the fvwm.org domain name for the next 9 years. (The max >> gandi allows for.) The fvwm.org web site is back up from here. >> >> Hopefully, I'll still be alive in 9 years, but I've got no guarantees. >> I don't think there will be a problem, as I understand it anyone can >> renew. >> > > If needed, and we want to go through the pain of transferring the > domain, I can put the domain with some domains I control, such as > fvwmforums.org, which is setup to auto renew. You must be young. :) 9 years I'll be 81. Not too concerned about 9 years from now. -- Dan Espen
Re: fvwm.org domain name
Hi, I've renewed the fvwm.org domain name for the next 9 years. (The max gandi allows for.) The fvwm.org web site is back up from here. Hopefully, I'll still be alive in 9 years, but I've got no guarantees. I don't think there will be a problem, as I understand it anyone can renew. Thomas Adam <tho...@xteddy.org> writes: > Hi Dan, > > I hope you're well. I was wondering if you were the one with domain > name renewal powers for fvwm.org? I was speaking to Jason Tibbetts who > said that he hasn't renewed it for years. > > Currently, fvwm.org needs renewing -- would you be able to do this? If > not, I'm happy to pick up the costs, and/or have the domain name > transferred to me, etc. > > Kindly, Thomas > -- Dan Espen
Re: Default Configuration File
Thomas Adam <tho...@fvwm.org> writes: > On Sun, Oct 23, 2016 at 12:09:47AM -0600, Jaimos Skriletz wrote: >> Hello, >> >> Thomas has asked me to help with a default configuration file and this is >> what I have come up with. >> >> http://fvwmforums.org/fvwm-default-config.tar.gz >> >> That file extracts to fvwm-default-config/ and to use copy the contents to >> $HOME/.fvwm > > This won't be necessary. I've more-or-less added these files to the FVWM > build, the result of which can be found on the 'default-config' branch on git. > > I've been using it like this: > > % make clean && ./autogen.sh && ./configure --prefix=tmp/fvwn && \ > sudo make install > > Then running fvwm under Xephyr: > > % /tmp/fvwm/bin/fvwm -f /dev/null Hi, So far I sort of like this. I have a few comments, 1) Wall paper changing isn't working. I get the message: [fvwm-root] failed to load image file 'images/background/bg2.png' The files are there: /usr/local/share/fvwm/default-config/images/background: -rw-r--r--. 1 root root 550823 Oct 23 19:54 bg2.png I think maybe "default-config" isn't in the images path? 2) The right panel goes all the way to the bottom of the screen but it's empty. I don't like it wasting space. 3) "refresh" is in the menus. Is that something users will use? 4) Olive Drab? 5) I have windows without mini-icons and they are difficult to see in the pager. 6) There should be a menu to invoke the modules. Especially FvwmAnimate. -- Dan Espen
Re: Future image support
Dominik Vogt <dominik.v...@gmx.de> writes: > During the discussion of mandarory or optional PNG support I've > started wondering if we *really* need a multitude of different > image format support in the core and the modules. > > At the moment, there's a plugin like image loading and maintenance > layer in the library that takes care or reading images into > memory. When this is done, all images are actually the same. > > +---+ +---+ +---+ > | PNG file | | XPM file | | SVG file | > +---+ +---+ +---+ > |___|___| > | > | load > | > +---+ > | | PNG lib | | XPM lib | | SVG lib | | > | +---+ +---+ +---+ | > | |_|_| | > | | | > | +---+ |^ > | | Picture code using Pixmap | || > | +---+ | library code > |-|-| > | | | > |fvwm core or module using Pixmaps | > | | > +---+ > > It would be possible to rip out image loading support from the > library except for a single format and rely on external tools to > provide that format if necessary. Possible approaches: > > * Use e.g. Imagemagick to convert the image file to the target >format. We'd get support for many image formats for free >while linking fvwm with only one image library. > > * Have our own tool similar to fvwm-root to read the image into >memory (on the X server, as shared memory or whatever). Only >that tool would know about image formats, Fvwm and the modules >would simply work with the Pixmaps from memory. As a bonus, >the Pixmaps could be shared between modules and the core. > > The Imagemagick approach is probably too slow and unreliable, but > the second should be doable with well designed inter process > communication (which needs a redesign anyway). Uploading Pixmaps > to the server before they can be used may not be a good idea for > remote servers. > > Thoughts? I don't see XPMs in the XDG libraries, but I do see them still being shipped with Emacs 24.5. I don't think Fvwm would need XPM support in order to allow Emacs to supply it's own icon as it likes to do. At minimum Fvwm needs to support the icons supplied by XDG. -- Dan Espen
Re: FVWM: [Draft] New Configuration Format
Thomas Adam <tho...@fvwm.org> writes: > On Mon, 19 Sep 2016 at 12:57 Ron Tapia <rd...@psu.edu> wrote: >> What are the >> shortcomings of the current configuration format that the new format >> addresses? > > Have another read of that document, Ron. FVWM is completely governed > by how it reads in commands, and hence at the moment, each command is > responsible for parsing its values. There's been twenty years of this > idea; organically growing out of control. Adding or even changing > existing options to commands is a nightmare; there's no state being > kept between commands (which would be good), and hence there's a lot > of the same sorts of information being gathered separately, leading to > a lot of duplication at the code-level. Actually, there is state kept between commands, or the "+" operator and the backslash for continuation would never work. (If that is what you were trying to say.) My comment is that the new commands are unreadable. Also, I do not want to change my existing config file. In the past we never changed the config file unless we could supply a conversion script to make the transition invisible to users. None of the proposed changes show any new functionality. Years and years ago we had a proposal that Fvwm change to using Scheme as it's command language. I can see how that would add functionality. At the time I was against that mainly for bloat concerns. The current Fvwm command structure is designed around readability. The context switches being a necessary exception. We currently do this: Mouse 2 W SM Move 100 0 Key LeftA C Scroll -100 0 We could allow: Mouse 2 Window Shift+Meta Move 100 0 Key LeftAll CtrlScroll -100 0 The concept of a "bind" command is interesting. But it feels like we'd be bringing implementation details into the command language. Not always a good thing. -- Dan Espen
Re: FVWM: Recommend Config for Fluxbox user
Tim Johnson <t...@akwebsoft.com> writes:
> * Thomas Adam <tho...@fvwm.org> [160625 06:41]:
>> On 24 June 2016 at 01:23, lee <l...@yagibdah.de> wrote:
>> > A configuration created with the hopes of being somewhat helpful for
>> > users wanting to learn how to configure fvwm can be obtained like this:
>>
>> Be careful with that intention, not matter how we meaning it is.
> <...>
> I got ("git'ed") git://dawn.adminart.net/fvwm.git for reasons of
> possible edification, however Thomas Funk's recommendation of "Setup
> Form" was just what I needed. It gave me a basic, sane beginning,
> and keywords for searches.
>
> Being a homestead kind of person, having a window manager that I can
> design from the ground up is right up my alley.
>
> Quoting T. Funk: "Up to Fvwm version 2.6.6 you could use the "Setup
> Form" in the Builtin Menu" et. al.
>
> Do I take that to mean that Setup Form has been discarded after
> later versions? If so, replaced at all?
Thomas,
I know the Setup Form has some issues, I said so myself,
but it's better than nothing.
It could use more options, (like choosing a couple of key
configurations, border color, frame thickness, etc.) but
putting it back unchanged is better than nothing.
You expressed unhappiness with the multiple files
it creates. That's dead simple to fix if you don't
like it. Personally, I prefer one file, I just did
it as multiple files because I assumed a user could
undo it.
My opinion.
(Note: this reply sent to -workers on purpose.)
--
Dan Espen
Re: Deprecation: Let's talk once more about removing $STUFF...
Thomas Adam <tho...@fvwm.org> writes:
> On Tue, May 31, 2016 at 08:44:23PM -0400, Dan Espen wrote:
>> If you want to open this can of worms, I think some streamlining might
>> be in order, that's up to you. I think it's a very good thing that Fvwm
>> has at least a minimal way to create a working configuration without
>> resorting to overblown theming engines mentioned above.
>
> Thanks, Dan.
>
> Having done as you suggested, I've come to the conclusion that all of this can
> go, so I have indeed opened up the can of worms. ;) Why? Well, irrespective
> of whether we should link to something external or not, all of the means by
> which I can end up with a config from FVWM is outdated. The files themselves
> haven't been maintained in a long time, and it shows as well.
>
> I like the intent of what the Fvwm{Form,Scripts} were getting at, but they're
> two very different ways of trying to do the same thing. If we want to
> introduce something again, we can do, easily, but we should go back to the
> drawing board about it.
>
> If I have no configuration file (fvwm -f /dev/null) then I'm now presented
> with something very bare-bones indeed. I think that's OK. From what I've
> seen a lot of Linux distros (Debian, RPM) have their own config which they
> ship, so the changes of a user being landed in the land of grey and black is
> slimmer than it was.
>
> So for now, all of it has gone. If we want to pick up from where the old
> FvwmScript/FvwmForm tried to, then we can do, and now we have a clean slate to
> do so.
You started out to eliminate unused modules.
In this case FvwmTaskBar.
This particular module should be eliminated because FvwmButtons+some
other modules is a better choice. Do we have a good example of a
working taskbar built that way? Shouldn't we?
In the case of FvwmForm and the Setup Form, I think you've eliminated
something that I remember at least one poster using. It's not the
best part of Fvwm, but the Setup Form gets a certain class of users
from befuddled to a working start. It's not a big deal for me
but I don't see that removing it gains anything. I don't agree
that it was outdated.
I have no idea what the distros do. I started as a SunOS user
and a sense of loyalty makes me want to continue to serve those
users.
Since you are primary developer, feel free to ignore me on this.
As I said, not a big deal to me.
--
Dan Espen
Re: Deprecation: Let's talk once more about removing $STUFF...
Thomas Adam <tho...@fvwm.org> writes:
> On 31 May 2016 9:31 p.m., "Thomas Funk" <t.f...@web.de> wrote:
>>
>> On 05/31/2016 09:30 PM, Thomas Adam wrote:
>>
>>>
>>> On 19 May 2016 4:18 p.m., "Thomas Adam" <tho...@fvwm.org
> <mailto:tho...@fvwm.org>> 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.
>
> It's already present in the form of FvwmButtons and FvwmIconMan.
> There's nothing to do, other than to point people at relevant
> implementations. Fvwm-{themes,crystal} notwithstanding, and this is
> not a reason to delay such a thing.
>
> No one has been able to assess the impact of this, and hence I'd say,
> the loss of FvwmTaskbar is not going to be missed. Even if were, it's
> still easily mitigated.
Fvwm uses FvwmTaskBar, for example in file:
sample.fvwmrc/system.fvwm2rc-sample-95
Those uses need to be eliminated before the module goes.
--
Dan Espen
Re: Deprecation: Let's talk once more about removing $STUFF...
Thomas Adam <tho...@fvwm.org> writes: > 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. > > As I understand it, FVWM was written with extensibility in mind, and hence > could be extended through the use of modules. Although the core of FVWM is > quite a bit larger now (read: some of the things ther could be modules, but > hey-ho, one for another time), there are at least quite a few modules which > change FVWM's behaviour. > > Long ago when developers were more active, getting the code into FVWM was > easier, and perhaps more importantly, the maintainability was easier, since > the author(s) of the code had a vested interest in keeping it alive. > > But those days have ended, as far as I am concerned. People have lives, and > have moved on, or simply don't use FVWM anymore. That's OK, and that's what > happens with software over time. But the hole it leaves is almost always > *somebody else's* mess. In this case, right now, that mess is mine. > > In looking at FVWM, I'm really trying to tidy up the rough edges. You can see > my progress in Git. Indeed, to make that easier, an easy win is to *reduce* > the amount of things which have to be touched by these cleanups. This means > removing modules. > > And let us be clear here, this isn't anything new. We (as developers) know > there's a lot of old cruft kicking around, but no one has had the balls to > remove it for fear of breaking things for other users. That's cool, but > equally, I want that trade-off to always be about what's maintainable, > long-term. > > So to that end, I've started work to deprecate those modules I really do think > can go, because their functionality is either covered by other FVWM modules, > or could easily be replaced by readily available third-party tools (where that > functionality is a minor part of FVWM). So what am I proposing, and why? > Here's the list, with rationale: > > * FvwmDragWell -- never could get this to work. The XDnD specification is > interesting, but the applications listening to this are also dead. > > * FvwmGTK -- GTK1.x is completely deprecated. Goodbye GTK! > > * FvwmIconBox -- use the IconBox style for similar grouping of icons. > > * FvwmSave / FvwmSaveDesk -- use a session manager. Also, a lot of > applications don't use WM_COMMAND anymore. > > * FvwmTaskBar -- Use FvwmIconMan. > > * FvwmTheme -- it's in the core of FVWM. > > * FvwmWharf -- use FvwmButtons. > > * FvwmWinList -- use FvwmIconMan. > > * FvwmTabs -- use 'tabbed' from suckless. > > * FvwmWindowMenu -- someone's experiment. Look in the samples directory. We configure lots of that stuff. > As you can see, I've spared FvwmCPP and FvwmM4 for now, but I did break out > into a cold sweat as to whether they should be removed. I left them in > because I want to unify them and expand on the idea a little more. I'm using FvwmCpp but I don't need it anymore. At one time I was sharing a configuration between PC and Sun hardware with 8 bit color. Seemed like a valid use. Not sure if our condition testing can do the same thing: #if PLANES > 8 + TitleStyle LeftJustified\ ActiveUp (\ HGradient 128 2 rgb:FF/00/00 70 rgb:88/00/88 30 rgb:00/00/ff)\ Inactive (\ Solid Navy -- flat)\ ActiveDown (\ HGradient 128 2 rgb:FF/00/00 50 rgb:88/00/88 50 rgb:00/00/ff) #else + TitleStyle LeftJustified ActiveUp (Solid Navy -- flat) \ ActiveDown (Solid Navy -- flat) \ Inactive (Solid grey51 -- flat) #endif > > I've also gone and removed these two directories: > > debian/ > rpm/ > > AFAIAC, these shouldn't be part of a window manager, and it is unreasonable to > expect maintainers of a window manager to understand package management to any > degree. All downstream do when they package FVWM is remove these directories > and replace them with their own (newer) versions, since ours are just left to > bitrot. If you want to build packages of your own, do so. But it's > peripheral to FVWM. > > Thoughts, comments, and suggestions, please. I'm keen to get the discussion > moving and come to a consensus. Note that if people really, _really_ want > these modules, then having these maintained externally to FVWM is easy to do, > and actively encouraged. I'm not using anything else you mentioned, so no problem. But I'm unsure what problem some of them cause just hanging around. Back when session management became a feature, someone decided we needed FvwmSave, etc. Never heard a problem reported for it, so I just ignored it. Just had an opportunity to look at Fvwm.Org, it looks pretty nice. I thought we were going to retain the themeing, but I don't see it. Not a real problem. -- Dan Espen
Re: fvwm repeatedly crashing
zli...@ns.sympatico.ca writes: > Configuration Information [Automatically generated, do not change]: > Description: > fvwm occasionally crashes (a few times a day). > > Repeat-By: > Since I've started trying to take note of when it crashes, > every time it was when I was > - switching tabs in firefox, > - opening a new tab in firefox, or > - closing a tab in firefox. > #2 0x00485deb in FlocaleFreeNameProperty > (ptext=ptext@entry=0x25e9710) > at Flocale.c:2358 If you print ptext->name it will probably be "Untitled". It's fixed in the 2_6 branch in CVS. If you can, you might want to read through: http://www.fvwm.org/documentation/dev_cvs.php and get the 2_6 branch like this: cvs -d :pserver:anonym...@cvs.fvwm.org:/home/cvs/fvwm checkout -r branch-2_6 fvwm configure, then make. There's a shell to help. -- Dan Espen
Re: Crash in FVWM (bug report)
Alwin <translati...@ziggo.nl> writes: > Dear List, > > I would like to report a crash in FVWM 2.6.5. According to the logs, > it's a possible buffer overflow. I'm using FVWM-Crystal 3.4.0 SVN rev. > 767, X.Org server 1.16.4 and Gentoo Linux. > > The logs are huge, so it might be a good idea to only copy the relevant > parts in-line from the attached gzipped files: config.log, build.log, > session.log and backtrace.txt. > > The crash happens when the Volume+ or Volume- button is pressed > on the keyboard. These are common Multimedia Keys which generate the > XF86AudioRaiseVolume and XF86AudioLowerVolume KeySyms, and have auto > repeat enabled by default. The KeySyms have key bindings in > FVWM-Crystal: see 'Change-Volume-Down' function in the session.log. It > decreases the volume, and prints the volume level on screen, using a > function called 'FvwmButtons-Tooltip-Volume' in the session.log. > > When these buttons are pressed for about 3 seconds too long, after the > volume reached 0% (or 100%) already, then FVWM is aborted with > this log message: > > *** buffer overflow detected ***: fvwm terminated > > The backtrace leads to the tooltip print function, which might be the > problem here: > > #10 0x00437c89 in sprintf (__fmt=0x4a2898 "%d", > __s=0x7ffc22de1290 "10wmButtons-Tooltip-Volume (99)") at > /usr/include/bits/stdio2.h:33 > > > Please let me know if more information is needed, or to test a patch. Looks to me like this line in add_window.c: char win_name_len[MAX_WINDOW_NAME_NUMBER_DIGITS]; should be: char win_name_len[MAX_WINDOW_NAME_NUMBER_DIGITS+1]; If you can test that, okay. If I don't hear otherwise, I'll commit a change in a day or 3. -- Dan Espen
Re: Fvwm commit problem
Jason L Tibbitts III ti...@math.uh.edu writes: R Sure, I'll look today when I get some time. I had to redo that server a while back (at least a couple of months) but it's possible that I broke it and nobody has committed anything since then. I really would like to get rid of CVS. If you know how to convert the CVS stuff to git, I'm willing to learn to use git. Can you convert and retain the change history? -- Dan Espen
Fvwm commit problem
Hi, I made up a fix for fvwm-menu-desktop but I get errors when I try to commit which I believe are on the CVS server end. I tried yesterday and today. The message I get is: cvs commit: [16:13:51] waiting for nobody's lock in /home/cvs/fvwm/fvwm/bin I believe there is a lock file on the server. Jason, please take a look. -- Dan Espen
Re: Fvwm commit problem
Jason L Tibbitts III ti...@math.uh.edu writes: Can you try now? cvs commit: cannot find pre-commit filter `/usr/bin/commit_prep': No such file or directory cvs commit: Pre-commit check failed cvs commit: cannot find pre-commit filter `/usr/bin/commit_prep': No such file or directory cvs commit: Pre-commit check failed cvs [commit aborted]: correct above errors first! -- Dan Espen
Re: Bug#777685: Resizing of Gnuplot Qt windows sometimes flicker and fail
Vincent Lefevre vinc...@vinc17.net writes:
On 2015-02-25 23:24:46 +, Thomas Adam wrote:
On Wed, Feb 25, 2015 at 03:06:25PM -0800, Vincent W. Chen wrote:
Hi,
Please retain the CC to 777685-forwar...@bugs.debian.org in your
response, so that the Debian BTS has a record.
Running
gnuplot5-qt EOF
plot '-' using 1:2 t '' with line
0 0
10 10
e
pause mouse close
print Done
EOF
creates a window. With ResizeOpaque set, resizing the window causes
the window to flicker rapidly. The window also does not resize
properly, as the size of the window does not correspond to the
Can you reproduce this using the CVS version? I can't reproduce it.
I can reproduce the problem with the branch-2_6 branch.
Now I can too.
It looks like the program realizes it's been resized and then
calculates a size it likes better.
When I drag it to a sufficiently larger size, the window
bounces a bit then settles for a larger size a bit smaller than
where I dragged it.
xprop on the window:
_NET_WM_USER_TIME(CARDINAL) = 498539938
WM_STATE(WM_STATE):
window state: Normal
icon window: 0x0
_WIN_AREA(CARDINAL) = 0, 0
_WIN_WORKSPACE(CARDINAL) = 0
_WIN_LAYER(CARDINAL) = 4
_WIN_STATE(CARDINAL) = 0
_NET_FRAME_EXTENTS(CARDINAL) = 8, 8, 30, 8
_KDE_NET_WM_FRAME_STRUT(CARDINAL) = 8, 8, 30, 8
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CHANGE_DESKTOP,
_NET_WM_ACTION_CLOSE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MAXIMIZE_HORZ,
_NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_MOVE,
_NET_WM_ACTION_RESIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_STICK
_NET_WM_DESKTOP(CARDINAL) = 0
_NET_WM_ICON_VISIBLE_NAME(UTF8_STRING) = Gnuplot window 0
_NET_WM_VISIBLE_NAME(UTF8_STRING) = Gnuplot window 0
_NET_WM_NAME(UTF8_STRING) = Gnuplot window 0
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 50331662
_NET_WM_ICON(CARDINAL) =Icon (32 x 32):
...
XdndAware(ATOM) = BITMAP
_MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0
WM_CLIENT_LEADER(WINDOW): window id # 0x305
_NET_WM_PID(CARDINAL) = 24257
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x3e, 0x7e, 0x0, 0x0
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING,
_NET_WM_SYNC_REQUEST
WM_NAME(STRING) = Gnuplot window 0
WM_LOCALE_NAME(STRING) = en_US.UTF-8
WM_CLASS(STRING) = gnuplot_qt, Gnuplot_qt
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
Initial state is Normal State.
bitmap id # to use for icon: 0x30b
window id # of group leader: 0x305
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified minimum size: 69 by 120
window gravity: NorthWest
WM_CLIENT_MACHINE(STRING) = home-home
WM_COMMAND(STRING) = { gnuplot_qt }
--
Dan Espen
Re: Resizing of Gnuplot Qt windows sometimes flicker and fail
Thomas Adam tho...@fvwm.org writes: On Wed, Feb 25, 2015 at 03:06:25PM -0800, Vincent W. Chen wrote: Hi, Please retain the CC to 777685-forwar...@bugs.debian.org in your response, so that the Debian BTS has a record. Running gnuplot5-qt EOF plot '-' using 1:2 t '' with line 0 0 10 10 e pause mouse close print Done EOF creates a window. With ResizeOpaque set, resizing the window causes the window to flicker rapidly. The window also does not resize properly, as the size of the window does not correspond to the Can you reproduce this using the CVS version? I can't reproduce it. I'm pretty close to current CVS and I can't reproduce it either. I'm FC 20, the binary is named gnuplot-qt, not gnuplot5-qt. -- Dan Espen
Re: Fvwm project
Thomas Adam tho...@fvwm.org writes: On Mon, Oct 13, 2014 at 05:53:06PM -0400, Dan Espen wrote: I don't see the sense in removing xpm, svg, bmp, etc. support. How many lines of code does that save? Hi Dan, It's not about saving lines of code, or even necessarily trying to reduce the amount of memory that's being used, as it is more an effort to standardise on one or two things (at most), thus reducing the overhead as a maintainer/programmer. But I question that there is any savings. There's a tiny amount of XPM code in Fvwm and I can't remember there ever being a problem with it. I know it's a departure from what we have now, because it's a change, but that's something that's a little easier to do. It's not necessarily all about less code either, but having a multitude of different image formats is nice from a users' perspective, but it's little effort to convert them. So you agree it's better for the users. I've set Fvwm in some work areas where the first thing that goes wrong with Fvwm, those users will move to Windows full time. But my real issue is moving the development source to another location and not documenting anything about it. I don't see this as clandestine---although I assume that's not what you're implying. Which parts are undocumented, may I ask? The development model (if I can call it that) is the same as we have now for fvwm---sure, the sources for mvwm are in a different location now (they're in git, they have to be), but I'd happily grant you commit privileges, etc., if you wanted so you could work on mvwm. There are detailed step by step instructions at fvwm.org that explain the entire CVS process: http://fvwm.org/documentation/dev_cvs.php That, and changing the name of fvwm to something else. If you want to fork, say so. There's already a separate thread for this; it's already been discussed---I'm unsure how much of that you've been following? To be fair, there was quite a flurry of emails. Yes, I remember. Yes, I changed the name for (at the time) good reasons. If you remember, I mentioned that I've been running versions of fvwm side by side for years. There is no reason to change a name. You can still take your existing fvwm config, tweak a few things [1] and you ought not to see any difference. That's the point, we're still trying to keep compatibility as much as possible before we diverge things away. Sure, in the case of images, that's already happened a little, but these changes are expected more and more as time progresses. You won't get there by renaming everything. It's evolution, Dan, it's not exactly a fork. Were it so, I'd have been even more brutal in my approach, but that's not what I had in mind _at all_ when I started this. It doesn't look like evolution. Not with a name change. -- Dan Espen
Fvwm project
I don't see the sense in removing xpm, svg, bmp, etc. support. How many lines of code does that save? I can imagine it saves some amount of non-resident memory, but if you don't have xpms, libxpm should not be using any significant real memory. Otherwise, it just causes issues for users. But my real issue is moving the development source to another location and not documenting anything about it. That, and changing the name of fvwm to something else. If you want to fork, say so. -- Dan Espen
Re: [OT]: Using Emacs
Thomas Adam tho...@fvwm.org writes: Hi all, I know this is slightly off-topic, but for various reasons I'm having to use Emacs, and was wondering what others on this list do to make their lives easier with things like: * C development; * GDB; * Make/compilation It's important to do make while inside Emacs, there are benefits to working that way. Bind some keys to invoke the compiler and find errors, I do: (define-key global-map [(f1)] 'compile) (define-key global-map [(f2)] 'next-error) (define-key global-map [(S-f2)] 'previous-error) Anything fvwm-specific as well would be welcomed. In the fvwm source directory I keep a file for Emacs that automatically enforces fvwm project rules. The name of the file is .dir-locals.el and it's contents: ((nil . ((indent-tabs-mode . t) (fill-column . 80))) (c-mode . ((c-basic-offset . 8) (c-indent-level . 8) (indent-tabs-mode . t Emacs reads .dir-locals.el and applies it's rules in all sub-directories. -- Dan Espen
Re: GetNextSimpleOption is broken
Dominik Vogt dominik.v...@gmx.de writes: Just found this comment in CMD_Test: /* * unfortunately, GetNextSimpleOption is * * broken, does not accept quoted empty */ Actually, GetNextSimpleOption() is _not_ broken. The parsing library guarantees never to return empty tokens. This is a feature, albeit a questionable one. The CVS command you are looking for is annotate. 1.107 (migo 13-Aug-05): /* unfortunately, GetNextSimpleOption is Could be that it was broken when the comment was written. -- Dan Espen
Re: GetNextSimpleOption is broken
Dominik Vogt dominik.v...@gmx.de writes: On Tue, Sep 02, 2014 at 05:48:05PM -0400, Dan Espen wrote: Dominik Vogt dominik.v...@gmx.de writes: Just found this comment in CMD_Test: /* * unfortunately, GetNextSimpleOption is * * broken, does not accept quoted empty */ Actually, GetNextSimpleOption() is _not_ broken. The parsing library guarantees never to return empty tokens. This is a feature, albeit a questionable one. The CVS command you are looking for is annotate. 1.107 (migo 13-Aug-05): /* unfortunately, GetNextSimpleOption is Well, I thought it might be worhtwhile to mention it in public while we're working on the parser anyway. Could be that it was broken when the comment was written. No, it has always been this way. This guarantee is used in many places where parsing is done, and when I coded GetNextSimpleOption() this was in there from the start (because it simply uses the same underlying implementation of the tokenisation functions as the rest of the parsing library). By the way, does anybody know what this infostore stuff is about? Thomas does, but just in case he doesn't find his own email... https://www.mail-archive.com/fvwm-workers@fvwm.org/msg02706.html Seems reasonable, but I suggest, from infostore.h: MetaInfo *new_metainfo(void); void insert_metainfo(char *, char *); char *get_metainfo_value(const char *); void print_infostore(void); the new, insert and get functions should all use the word infostore, not metainfo. -- Dan Espen
Re: GetNextSimpleOption is broken
Dominik Vogt dominik.v...@gmx.de writes: On Tue, Sep 02, 2014 at 06:07:44PM -0400, Dan Espen wrote: Dominik Vogt dominik.v...@gmx.de writes: By the way, does anybody know what this infostore stuff is about? Thomas does, but just in case he doesn't find his own email... https://www.mail-archive.com/fvwm-workers@fvwm.org/msg02706.html Seems reasonable, but I suggest, from infostore.h: MetaInfo *new_metainfo(void); void insert_metainfo(char *, char *); char *get_metainfo_value(const char *); void print_infostore(void); the new, insert and get functions should all use the word infostore, not metainfo. Hm, is this in a stable release already? I find the syntax a bit clumsy (the name is not very intuitive, and $[infostore] is so much to type), and if while we're rewriting the parser we might clean that up as well. We have SetEnv. Does SetVar work for you? All of 2.6 is stable. -- Dan Espen
Re: GetNextSimpleOption is broken
Thomas Adam tho...@fvwm.org writes: On Tue, Sep 02, 2014 at 11:11:56PM +0100, Dominik Vogt wrote: On Tue, Sep 02, 2014 at 06:07:44PM -0400, Dan Espen wrote: Dominik Vogt dominik.v...@gmx.de writes: By the way, does anybody know what this infostore stuff is about? Thomas does, but just in case he doesn't find his own email... https://www.mail-archive.com/fvwm-workers@fvwm.org/msg02706.html Seems reasonable, but I suggest, from infostore.h: MetaInfo *new_metainfo(void); void insert_metainfo(char *, char *); char *get_metainfo_value(const char *); void print_infostore(void); the new, insert and get functions should all use the word infostore, not metainfo. Hm, is this in a stable release already? I find the syntax a bit clumsy (the name is not very intuitive, and $[infostore] is so much to type), and if while we're rewriting the parser we might clean that up as well. I don't mind. But I certainly _dislike_ the ridiculous tokens we have now in terms of w.foo, i.foo, etc., etc. I'd much rather we deferred that part until much later on, as I've a few notes regarding expansion versus information coming out of fvwm (and how that's stored in fvwm, etc.) Just kibitzing here, but when I do re-factoring, I like to start with consistent names. I could see how changing names might cause git - cvs issues. -- Dan Espen
Re: Historical Parsing (twm onwards) [WAS: Re: REWRITE: Parsing]
Thomas Adam tho...@fvwm.org writes:
On Tue, Aug 26, 2014 at 07:32:17PM +0100, Dominik Vogt wrote:
Another example are function definitions:
AddToFunc TeddyBear I Echo xteddy
AddToFunc TeddyBear
+ C Exec exec xteddy
+ M Nop
This is actually a terrible piece of the fvwm syntax: Function and
menu definitions are not atomic. If you write a function definition
using FvwmConsole, the meaning of the '+' might change between lines:
For example, if a function is triggered that uses PipeRead to
generate a menu definition on the fly while you type into FvwmConsole,
the next '+' might no longer add to the function but to the menu
instead. And let's not talk about functions that generate functions
that generate functions.
Oh absolutely---I'm amazed we've not encountered bugs with regards to
this---clearly over the years the developers have done something right.
Or maybe it's that, and no one's used this in the weird and wonderful
ways that would break things.
Since we're on this subject, I'm curious about some of fvwm's history.
fvwm (1.x) had what I'd call block level constructs, so for
example:
Function Resize-or-Raise
Resize Motion
Raise Motion
Raise Click
RaiseLower DoubleClick
EndFunction
This is at odds from twm which uses constructs like:
Function move-or-iconify {
f.move f.deltastop f.iconify
}
Although the intent is the same; and from what I can tell of fvwm 1.X's
code having just quickly eye-balled it, nested function definitions
wasn't possible.
I wonder when the + command was introduced into fvwm, and did it
always have a triple-meaning of menu/function/decor? Or did that get
extended over time?
I might take the blame for other mis-designed things, but
as far as I remember, that goes way back. I think the issue was those
pretty long commands AddToFunc, etc. But the + sign is just broken.
On the other hand, I've never seen it cause a real problem.
I think Fvwm just scoops up commands so fast that it's unlikely that
there will be a conflict.
A warning in the man page might be in order.
It would be nice if Fvwm reported where it found an error
(line 40 .fvwm/config) which would make the parser aware
of where commands are coming from and provide a way to fix
this. Of course sometimes it would be FvwmAnimate PID 1234,
20th command.
--
Dan Espen
Re: REWRITE: New parser design
Thomas Adam tho...@fvwm.org writes:
* Tokenisation in the form key/value means that each command can lookup
the data in the same way. For instance:
if (has_token(level)) {
int l = strtonum(get_token(level), 1, INT_MAX, NULL);
if (l 10)
fprintf(stderr, Sorry, break level too high!\n);
}
Comments:
What you show above tells me we have 2 functions has_token and
get_token that as a result of a parser can retrieve parts of the
command just parsed using a token in the command.
Doesn't imply some kind of hash table?
I would expect a table driven parser to have a table representing the
commands arguments.
Maybe:
Animated_Move = {int, x,
int, y,
keyword, WARP, warp_keyword};
Then the logic in the CMD_ANIMATED_MOVE would be
getting at it's parsed values differently:
this_am_x = x;
this_am_y = y;
this_am)_warp = FALSE;
if (warp_keyword) {
this_am_warp = TRUE;
}
--
Dan Espen
Re: REWRITE: Some removed features
Thomas Adam tho...@fvwm.org writes: On Mon, Aug 18, 2014 at 05:23:57PM +0100, Dominik Vogt wrote: I find it really strange to have a configuration input filter implemented as a module. I don't know what to do with it in the long run, but at the moment I find it indispensable. I understand. And xpm images are easy to write as source code. Hm, don't we have some hard coded xpm images somewhere in the sources anyway? We don't have anything in the source, but we do seem to offer these still: http://fvwm.org/download/icons.php Is that what you were thinking of? There are XPM files in the test directory and one XPM file stored with FvwmBanner. -- Dan Espen
Re: names in auto generated menus
Dominique Michel dominique.mic...@vtxnet.ch writes:
Le Fri, 03 Jan 2014 10:34:24 -0500,
Dan Espen des...@verizon.net a écrit :
Dominique Michel dominique.mic...@vtxnet.ch writes:
Le Fri, 3 Jan 2014 15:07:52 +0100,
Dominique Michel dominique.mic...@vtxnet.ch a écrit :
It seam like file and directory names with characters like {} or ()
into their names confuse very easily fvwm. At the beginning, I was
thinking it was fvwm-menu-directory that get confused by them, but
after running the same command into a console, it appear the menu
generated by it is correct in any cases. So the issue is in fvwm
itself.
Sorry, I've read your post twice and still don't understand.
Please send a single fvwm command that doesn't work as you expect.
A resumed fvwm code that fail is:
DestroyFunc FuncFvwmMenuMovieDirectory
AddToFunc FuncFvwmMenuMovieDirectory
+ I PipeRead 'case \$0\ in \
/home/alian/Vídeos*) myexec=fvwm-crystal.mplayer-wrapper file dom;;
I rather not install fvwm-crystal.
--
Dan Espen
Re: To remove a key binding fail with -
Dominik Vogt dominik.v...@gmx.de writes: The attached patch should fix the problems. For some reason my CVS connection hangs forever, so I cannot apply the patch myself. :-/ Works from here. Not sure why you would have a problem. -- Dan Espen
Re: bug in 2.6.5's bin/fvwm-menu-desktop.in
Mathieu sig...@gmail.com writes:
It does not recurse into the applications sub-directories because it
tries to use a _ stat cache incorrectly.
--- fvwm-menu-desktop.in.orig 2012-01-18 05:22:44.0 -0500
+++ fvwm-menu-desktop.in2013-12-09 20:49:37.0 -0500
@@ -477,11 +477,11 @@
{
if ($entry =~ /\.desktop$/)
{
read_desktop_entry($pool, $dir/$entry, $topdir);
}
-elsif (-d _ and $entry !~ /^\.{1,2}$/
+elsif (-d $dir/$entry and $entry !~ /^\.{1,2}$/
and $entry ne '.hidden')
{
scan_AppDir($pool, $dir/$entry, $topdir);
delete $__scanmap{$dir};
}
Sorry, but fvwm-menu-desktop has been completely rewritten in CVS
and patches for the 2.6.5 version don't apply.
Current CVS version 2.6.6 is the only version we're making changes to.
--
Dan Espen
Re: FvwmScript - WriteToFile seems not working
Thomas Funk t.f...@web.de writes:
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'
Good stuff!
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
Hmm, I wonder what flags we need to use to get near that size?
The only thing that not fit in this theory is Dominiques issue because
his code is self compiled, too ...
I should have said fprintf(stderr);
I put a few in and observed expected behavior.
One near the end of CalcArg:
fprintf(stderr,calc arg value of %s\n,TmpStr);
One right at the start of WriteToFile:
fprintf(stderr,number of args %d\n,NbArg);
What you say above sounds like a very possible optimizer/compiler
problem. Probably the distro flags haven't changed so we might
need to know the flags and the specific compiler version.
BTW, I'm FC19 but I always build my own executables.
--
Dan Espen
Re: Bad window background in pager
Dominik Vogt v...@linux.vnet.ibm.com writes: I've seen this a couple of times in 2013: (grey window background in attached .png) Any idea which change may have caused this? A side effect of the multi-line-labels patch maybe? I never use the pager so I haven't noticed anything. I guess you mean this patch? 2012-04-14 Thomas Adam tho...@fvwm.org * modules/FvwmPager/x_pager.c (label_window_wrap): New static function for wrapping window lables. * modules/FvwmPager/x_pager.c (do_label_window): Use wrapped window names in pager by default. -- Dan Espen
Re: FvwmScript - WriteToFile seems not working
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. -- Dan Espen
Re: Bug#698920: fvwm: In FvwmWinList, the list shows the title names instead of the icon names
Vincent W. Chen vin...@gmail.com writes: On Tue, Nov 12, 2013 at 8:19 AM, Dan Espen des...@verizon.net wrote: Arne Wichmann a...@anhrefn.saar.de writes: begin quotation from Dan Espen (in ic61s0x85c@home.home): Arne Wichmann a...@anhrefn.saar.de writes: begin quotation from Schaaf, Jonathan P (GE Healthcare) (in c2dddb22b0ae094db5f3ce04cb9e2f2615a20...@cinurcna02.e2k.ad.ge.com): Ok, doing some tests it seems that the logic of setting window/icon names in fvwm is broken. The behavior depends on the ability of the client to do set UTF8-properties, but it is broken in any case. Tests follow: Just on a hunch, you might want to try this version: ftp://ftp.fvwm.org/pub/fvwm/version-2/fvwm-2.6.3.tar.gz A patch was added in 2.6.4 that seems really suspicious to me. For my own purposes, I've been reverting the patch to event.c that relates to icon names because it's been causing segfaults for me. The problem doesn't seem to appear with this version. I've reverted the patch in the 2.6.6 branch. If you have time I'd like to hear if it helps. If you have an easy way to find and install it I will take a look... Sadly, our snapshot building stopped a few years ago. You can check out from CVS and build, or wait until Debian picks up a recent 2.6.6. Could you attach/send the patch to me? I'd like to backport this into Debian if possible. We got email indicating the patch was applied: From: Schaaf, Jonathan P (GE Healthcare) jonathan.p.sch...@ge.com Subject: Re: CVS dane: * fvwm/events.c (HandlePropertyNotify): Disable prior fix suspected of causing To: @HEALTH CST c...@ge.com Cc: FVWM CVS fvwm-workers@fvwm.org Date: Wed, 20 Nov 2013 21:11:53 + (5 days, 17 hours, 26 minutes ago) Upstream FVWM has reverted the fix that causes the MR gimp crash. Jonathan -Original Message- From: c...@math.uh.edu [mailto:c...@math.uh.edu] Sent: Saturday, November 09, 2013 11:21 AM To: fvwm-workers@fvwm.org Subject: CVS dane: * fvwm/events.c (HandlePropertyNotify): Disable prior fix suspected of causing CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: dane13/11/09 11:20:50 Modified files: . : Tag: branch-2_6 ChangeLog fvwm : Tag: branch-2_6 events.c Log message: * fvwm/events.c (HandlePropertyNotify): Disable prior fix suspected of causing problems. -- Dan Espen
Re: fvwm: In FvwmWinList, the list shows the title names instead of the icon names
Arne Wichmann a...@anhrefn.saar.de writes: begin quotation from Dan Espen (in ic61s0x85c@home.home): Arne Wichmann a...@anhrefn.saar.de writes: begin quotation from Schaaf, Jonathan P (GE Healthcare) (in c2dddb22b0ae094db5f3ce04cb9e2f2615a20...@cinurcna02.e2k.ad.ge.com): Ok, doing some tests it seems that the logic of setting window/icon names in fvwm is broken. The behavior depends on the ability of the client to do set UTF8-properties, but it is broken in any case. Tests follow: Just on a hunch, you might want to try this version: ftp://ftp.fvwm.org/pub/fvwm/version-2/fvwm-2.6.3.tar.gz A patch was added in 2.6.4 that seems really suspicious to me. For my own purposes, I've been reverting the patch to event.c that relates to icon names because it's been causing segfaults for me. The problem doesn't seem to appear with this version. I've reverted the patch in the 2.6.6 branch. If you have time I'd like to hear if it helps. If you have an easy way to find and install it I will take a look... Sadly, our snapshot building stopped a few years ago. You can check out from CVS and build, or wait until Debian picks up a recent 2.6.6. -- Dan Espen
Re: fvwm: In FvwmWinList, the list shows the title names instead of the icon names
Arne Wichmann a...@anhrefn.saar.de writes: begin quotation from Schaaf, Jonathan P (GE Healthcare) (in c2dddb22b0ae094db5f3ce04cb9e2f2615a20...@cinurcna02.e2k.ad.ge.com): Ok, doing some tests it seems that the logic of setting window/icon names in fvwm is broken. The behavior depends on the ability of the client to do set UTF8-properties, but it is broken in any case. Tests follow: Just on a hunch, you might want to try this version: ftp://ftp.fvwm.org/pub/fvwm/version-2/fvwm-2.6.3.tar.gz A patch was added in 2.6.4 that seems really suspicious to me. For my own purposes, I've been reverting the patch to event.c that relates to icon names because it's been causing segfaults for me. The problem doesn't seem to appear with this version. I've reverted the patch in the 2.6.6 branch. If you have time I'd like to hear if it helps. -- Dan Espen
Re: Spelling Error in FvwmPager Manpage
Vincent W. Chen vin...@gmail.com writes: Hi, There is a spelling error in the FvwmPager manpage. Attached is a small patch which should apply cleanly to the 2.6 branch. Thanks, applied. -- Dan Espen
Re: Notes to the future maintainer
Thomas Adam tho...@fvwm.org writes: On Mon, Sep 23, 2013 at 09:57:25PM -0400, Dan Espen wrote: Thomas Adam tho...@fvwm.org writes: * Consider using DBus as the API which is used to communicate to/from FVWM, INCLUDING MODULES; Is it available on all X Windows platforms? Yes. Even compiles for Solaris, AFAIK. Yes, what I read says it compiles but doesn't work. Is it faster than the pipes we use? I haven't profiled it, but it'll be no slower, that's for sure. Slower is no good. -- Dan Espen
Re: Notes to the future maintainer
permissioning scheme in use obsolete, thank God. If we move our source, we would still need Jason for accepting release binaries, and we'd need to update CVS to get our web pages updated. So, I think a Git transition would necessitate moving the entire project, web pages and all. I'm not sure what all the steps are but I've been thinking of buying some web space. Any comments? Note that this isn't anything personal or an attack on past contributors--- I don't see an attack. I think we (as in developers) have long since realised FVWM3 was meant to be a rewrite. It didn't happen. Fair enough, but it's going to quickly turn into a curio if it's not maintained past the point of applying band-aids. The world's moving on with things, and FVWM isn't. I was never in favor of Fvwm3. Too many projects dump old and working forcing their users through a conversion. [1] By all rights it's meant to be written as 'fvwm'. I personally disagree with this, since it's an acronym, but whatever, the style is already completely destroyed. Don't care. -- Dan Espen
Re: fvwm frees invalid pointer
Gleb Smirnoff gleb...@glebius.int.ru writes:
On Tue, Sep 17, 2013 at 10:04:52AM -0400, Dan Espen wrote:
DJust got a very different panic. It may be unrelated
D to the free/malloc problems, but since fvwm was rock stable
D for the last 10 years for me, I'm prone to think that all
D my recent crashes are caused by the same single problem.
D
D (gdb) bt
D #0 0x004daab8 in FlocaleDrawString (dpy=0x804831000,
flf=0x80482f980,
D fws=0x80482aec0, flags=0) at Flocale.c:1983
D ...
D Core saved, I can provide more info.
D
D Starting to look like a memory overlay somewhere.
D In which case valgrind or one of the other memory checkers would be
D more useful.
D
D Do list.
D Print fws, *fws, comb_chars, i.
(gdb) list
1978while(comb_chars[i].c.byte1 != 0
comb_chars[i].c.byte2 != 0)
1979{
1980/* draw composing character on top of
corresponding
1981 real character */
1982FlocaleWinString tmp_fws = *fws;
1983int offset =
pixel_pos[comb_chars[i].position];
1984char *buf2;
1985int out_len;
1986curr_len =
FlocaleChar2bOneCharToUtf8(comb_chars[i].c,
1987 buf);
Current language: auto; currently minimal
(gdb) p fws
$1 = (FlocaleWinString *) 0x80482aec0
(gdb) p *fws
$2 = {str = 0x804a0f230 Shells, e_str = 0x804a37850 Shells, str2b = 0x0,
gc = 0x80482f840, colorset = 0x804a13410, win = 18874669, x = 3, y = 33,
len = 0, clip_region = 0x0, flags = {text_rotation = 0, has_colorset = 1,
has_clip_region = 0}}
(gdb) p comb_chars
$3 = (superimpose_char_t *) 0x804a37850
(gdb) p i
$4 = 0
(gdb)
p pixel_pos
p *comb_chars
p char_len
--
Dan Espen
Re: fvwm frees invalid pointer
Gleb Smirnoff gleb...@glebius.int.ru writes:
On Tue, Sep 17, 2013 at 10:54:22AM -0400, Dan Espen wrote:
D D Do list.
D D Print fws, *fws, comb_chars, i.
D
D (gdb) list
D 1978while(comb_chars[i].c.byte1 != 0
comb_chars[i].c.byte2 != 0)
D 1979{
D 1980/* draw composing character on top of
corresponding
D 1981 real character */
D 1982FlocaleWinString tmp_fws = *fws;
D 1983int offset =
pixel_pos[comb_chars[i].position];
D 1984char *buf2;
D 1985int out_len;
D 1986curr_len =
FlocaleChar2bOneCharToUtf8(comb_chars[i].c,
D 1987
buf);
D Current language: auto; currently minimal
D (gdb) p fws
D $1 = (FlocaleWinString *) 0x80482aec0
D (gdb) p *fws
D $2 = {str = 0x804a0f230 Shells, e_str = 0x804a37850 Shells, str2b =
0x0,
Dgc = 0x80482f840, colorset = 0x804a13410, win = 18874669, x = 3, y =
33,
Dlen = 0, clip_region = 0x0, flags = {text_rotation = 0, has_colorset =
1,
D has_clip_region = 0}}
D (gdb) p comb_chars
D $3 = (superimpose_char_t *) 0x804a37850
D (gdb) p i
D $4 = 0
D (gdb)
D
D p pixel_pos
D p *comb_chars
D p char_len
(gdb) p pixel_pos
$1 = (int *) 0x804a48420
(gdb) p *comb_chars
$2 = {position = 1818585171, c = {byte1 = 108 'l', byte2 = 115 's'}}
(gdb) p char_len
$3 = 6
p *pixel_pos
--
Dan Espen
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: fvwm frees invalid pointer
Schaaf, Jonathan P (GE Healthcare) jonathan.p.sch...@ge.com 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 frees invalid pointer
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
Thomas Funk t.f...@web.de writes: Hi Dan, I've found a bug in fvwm-menu-desktop if only one xdg menu exists: I'd like to nominate Thomas Funk for CVS update access. He meets all the criteria, he's been around a long time and has contributed useful and well written patches. If I don't get any negative feedback by Wednesday I'll notify Jason. -- Dan Espen
Re: Bugfix for fvwm-menu-desktop if only one XDG menu exist
Hmm, now everyone's top-posting. I feel myself weakening. I've been occupied, but I'll get to this. Thomas Funk t.f...@web.de writes: 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 -- Dan Espen
Re: More complex menu schortvuts
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. -- Dan Espen
Re: More complex menu schortvuts
Thomas Adam tho...@fvwm.org writes: On Sun, Jun 30, 2013 at 05:42:51PM +0100, Dominik Vogt wrote: 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. + FvwmConsole (f1) ... AddMenuItemHotKey f1 The hotkey would be merged into the previously defined menu item. I cannot say that either option looks good to me. Can anybody think of a cleaner or more natural way to define hotkeys, possibly recuycling the syntax of the Key command? Another idea might be to simply allow keys when a menu is open to act like a typeahead search; the more keys you press, the closer to match you get, and at each stage, matched items are highlighted in the menu, etc. Aggh. no! Actually lots of my menus are heavily short-cutted. I'd don't think I'd get very far in a search term before one the options would be selected. Even a menu without short cuts accepts vi-keys for cursor movement. -- Dan Espen
Re: CVS dane: Patches from Thomas Funk
Dominique Michel dominique.mic...@vtxnet.ch writes: Le Mon, 17 Jun 2013 20:23:29 -0500, c...@math.uh.edu a écrit : CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: dane13/06/17 20:23:29 Modified files: bin: Tag: branch-2_6 ChangeLog fvwm-menu-desktop-config.fpl fvwm-menu-desktop.in po : Tag: branch-2_6 ChangeLog fvwm.de.po fvwm.pot The compilation didn't update the gmo file with the last translation. From into the po directory: # make po-update make: *** No rule to make target `po-update'. Stop. tuxstudio po # make make: Nothing to be done for `all' To get them, I have to cd into the po dir, and issue # make fvwm.de.gmo rm -f fvwm.de.gmo /usr/bin/gmsgfmt -c --statistics -o fvwm.de.gmo fvwm.de.po 106 translated messages. Maybe I missed something into the configure step, but I didn't see any obvious option for that. You're right. I remembered to do that and promptly forgot about it. There are instructions in the po directory on how to build the gmo file. I'll get to it. -- Dan Espen
Re: FvwmScript, UseGettext and LocalePath
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].
--
Dan Espen
Re: CVS tadam: Fix Echo command displaying messages
c...@math.uh.edu writes: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: tadam 13/04/16 09:53:26 Modified files: fvwm : Tag: branch-2_6 builtins.c misc.c Log message: Fix Echo command displaying messages This fixes Echo when using fvwm_msg() I saw some bad echos during testing, but I think I saw some good ones too. I eventually decided everything was okay since I wasn't messing with the echo code. -- Dan Espen
Re: CVS domivogt: * Fix many unused variable warnings in modules (write only).
Dominik Vogt dominik.v...@gmx.de writes: R On Mon, Apr 15, 2013 at 07:44:10PM +0100, Thomas Adam wrote: On 14 April 2013 09:57, Dominik Vogt dominik.v...@gmx.de wrote: On Sun, Apr 14, 2013 at 03:41:48AM -0500, c...@math.uh.edu wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: domivogt13/04/14 03:41:48 None of these changes seem to be following the fvwm-2_6 branch. Is this intentional? I did spend a while before fixing up a bunch of warnings. Not sure if I've already done so or not with the version of GCC you claim to be using, but I don't think you're looking at the correct branch point in CVS for starters. I'm looking at the main branch. Yes, CVS isn't quite right. I think it was after 2.6 we had a 2.7 branch created but the current plan is to stop with odd numbered releases that never happen and stay with 2.6. If I knew enough about CVS to remove the 2.7 branch I would. I would not be opposed to creating 2.8 if that's what it takes. -- Dan Espen
Re: FvwmIconMan man edit line 713 change - we to is
scootch...@yahoo.com writes: FvwmIconMan man edit line 713 change - we to is: cut diff/patch- --- FvwmIconMan.1 2013-04-02 18:33:29.0 +1100 +++ FvwmIconMan.1.edited 2013-04-02 18:40:06.0 +1100 @@ -708,10 +708,10 @@ This example is the Reader's Digest version of my personal configuration. It has two managers, one for emacs and one for everything else, minus things with -no icon title. Only windows on the current page are displayed. The use of the -\fIdrawicons\fP and \fIshape\fP options requires that fvwm and FvwmIconMan we -compiled with the correct options. Note how the geometry and show options are -specified per manager, and the others are common to all: +no icon title. Only windows on the current page are displayed. The use of +the \fIdrawicons\fP and \fIshape\fP options requires that fvwm and +FvwmIconMan is compiled with the correct options. Note how the geometry and +show options are specified per manager, and the others are common to all: .nf .sp cut diff/patch- Thanks, change committed. I went with we - are. -- Dan Espen
Re: FVWM Patch for Interaction problem with Java 7
John Faucett fauc...@lanl.gov writes: Thomas Adam thomas at fvwm.org writes: Well, that patch isn't correct with respect to the fix I added to CVS. I was able to install branch-2_6 but the problem with Java 7 persists. I should have reported that I tried CVS and saw the problem too. The window initially allows you to type in the window, but after a resize if won't accept focus until you move the pointer out of the window and then back in. I have not had time to investigate any deeper. -- Dan Espen
Re: FVWM Patch for Interaction problem with Java 7
John Faucett fauc...@lanl.gov writes: My problem is a little different. If the application comes up and the mouse is not over the window, then you can type into the field as well as tab around the widgets. But once the mouse enters the window, even without trying to resize or move it, then the ability to focus in a text field goes away and never comes back. Not sure why I have these: Style * DecorateTransient,Lenience Style sun-awt-X11-XWindowPeer HandleWidth 0,NoTitle,Lenience Style sun-awt* NoLenience I can type in the initial window regardless of pointer location. Since the resource is sun-awt-X11-XFramePeer, looks like I'm using NoLenience. Yep, reissuing the first line, makes it so I can't focus the window at all, I can only type there when the window first comes up and the pointer is not in the window. So, using the last line shown above, helps, a little. -- Dan Espen
Re: [contribute] Russian translate
Spoofing ivan.gayevs...@gmail.com writes: Hello from Russia :) Can I suggest a russian translate for FVWM? I will apply this, but it might take some time. Thanks. -- Dan Espen
Re: Closing nedit crashes fvwm
Vladimir Klebanov kleba...@kit.edu writes: On Wed, Jan 23, 2013 at 6:01 PM, Dan Espen des...@verizon.net wrote: Changes committed. Seems like it is no longer crashing, at least not upon quick testing. If crashes come back in everyday use, so will I. Thanks for fixing. Thanks for testing. -- Dan Espen
Re: Closing nedit crashes fvwm
Vladimir Klebanov kleba...@kit.edu writes: fvwm 2.6.4 shipped with openSuSE 12.2 regularly crashes on me. Details below. Any help would be appreciated. Thanks, Vladimir Backtrace: Program received signal SIGABRT, Aborted. 0xb7756424 in __kernel_vsyscall () Missing separate debuginfos, use: zypper install libgcc47-debuginfo-4.7.1_20120723-1.1.1.i586 (gdb) bt #0 0xb7756424 in __kernel_vsyscall () #1 0xb736831f in raise () from /lib/libc.so.6 #2 0xb7369c03 in abort () from /lib/libc.so.6 #3 0xb73a6335 in __libc_message () from /lib/libc.so.6 #4 0xb73acac2 in malloc_printerr () from /lib/libc.so.6 #5 0xb75db87b in XFree () from /usr/lib/libX11.so.6 #6 0x080d0afe in FlocaleFreeNameProperty (ptext=ptext@entry=0xbfb97afc) at Flocale.c:2365 #7 0x08075345 in HandlePropertyNotify (ea=0xbfb97b5c) at events.c:3344 #8 0x08073725 in dispatch_event (e=e@entry=0xbfb97bbc) at events.c:4124 #9 0x080737c8 in HandleEvents () at events.c:4168 #10 0x08050e55 in main (argc=optimized out, argv=0xbfb98454) at fvwm.c:2588 The behavior is not quite deterministic, but the best way to reproduce it for me was the following: start nedit type some text select a portion of it click the close window decoration click no in the save suggestion dialog crash Can you update from CVS and try again? I've committed a change that should fix the problem. -- Dan Espen
distcheck issues
Hopefully I just fixed the issue with fvwm-menu-desktop-config.fpl. Not sure why but the issue went away when I spelled out the name instead of using a variable. I still get an error: make[4]: Entering directory `/home/dane/fvwm-src/build_version-2_6_1/fvwm-2.6.6/_build/doc/fvwm' make[4]: *** No rule to make target `../../../doc/fvwm/fvwm.man.xml', needed by `fvwm.1'. Stop I'm using VPATH, Ie. building outside the package. When it looks for fvwm.man.xml it prepends $(srcdir) which is still in the build tree, not the source tree. Of course fvwm.man.xml is not there. Ah the mysteries of automake... -- Dan Espen
Re: rounded windows using fvwm
Ranjan Maitra stat.mai...@inbox.com writes: Hi Dan, I do wonder however, how something like pekwm handles this. It is pretty fast there (though I have not used it at the same intensity level as fvwm), but of course, does not have the full functionality of fvwm. So, perhaps not a fair comparison. Anyway thinking aloud, nothing more. Based on this screenshot: https://www.pekwm.org/projects/pekwm They cut off 3 pixels from the top window corner producing a barely visible curve that is not really a curve. The bottom of the window just has 1 pixel removed. That's 6 rectangles per window. Haven't looked at the source code to see if that's the only option. -- Dan Espen
Re: rounded windows using fvwm
Dan Espen des...@verizon.net writes: Ranjan Maitra stat.mai...@inbox.com writes: On Sun, 02 Dec 2012 00:14:45 -0500 Dan Espen des...@verizon.net wrote: Ranjan Maitra stat.mai...@inbox.com writes: Hello, I was wondering if it is yet possible to get rounded corners on windows using fvwm. I know that there is an unofficial patch around for this, but I was looking to hopefully avoid going out of the official version. If it is not possible to get rounded corners on windows using fvwm, are there any plans for adding this support? If so, soon? Longer? Why not just adapt the patch? Generally Fvwm only adds frivolous things (like FvwmAnimate), when they don't add bloat to the core of fvwm. I found a file named 09-FluxRoundedCorners.patch It doesn't qualify. OK, I am sorry for this naivete, but I don't know what parts in the patch cause the bloat: can they be worked around? (Of course, by that, I mean easily, since after all, anything can possibly be worked around.) If that's the complete patch, it's lacking documentation and only works with 2 radiuses, would attempt to curve a 1 pixel border. In short, it looks like a hack. Looking again at rounded windows, I notice how they conflict with Fvwm's notion of a border. Fvwm borders come in beveled and flat flavors with variable width. A one or 2 pixel border doesn't lend itself to being rounded. I'm not sure how many pixels are needed before rounding becomes visible, probably around 5. Bevels probably wouldn't work at all. You couldn't just use a shape mask, you'd have to try to make the bevel follow the curve. So far I haven't found a generic method for building the shape mask that would account for the degree of curvature. The patch I looked at, just used 2 different shape masks. I'm not sure how well that approach would work at varying resolutions. Lastly, I found this pretty old Kenton Lee write up: http://www.rahul.net/kenton/perf.html#Shapes Shaped Windows A performance issue related to object shapes is the use of shaped (non-rectangular) windows. Shaped windows are available via the SHAPE X protocol extension. While shaped windows can be useful, they can cause performance problems in many situations. Most importantly, Expose events always return rectangular exposure regions, so if a shaped window is moved or unmapped, the X server must send many Expose events to each exposed window to describe the shaped region. If the client owning the exposed window processes each event, its performance will be significantly affected. In general, you should avoid repeatedly resizing, moving, or unmapping shaped windows owned by your application. Also, if you expect many Expose events caused by shaped windows, you should write your Expose event handlers to compress the events as much as possible. So, I think that pretty much puts the nail in the coffin of shaped windows for me. Rounded windows have visual appeal because the roundness is more visually appealing. But I find fast pretty appealing too. Anyway, comments welcome. -- Dan Espen
Re: rounded windows using fvwm
Ranjan Maitra stat.mai...@inbox.com writes: On Sun, 02 Dec 2012 00:14:45 -0500 Dan Espen des...@verizon.net wrote: Ranjan Maitra stat.mai...@inbox.com writes: Hello, I was wondering if it is yet possible to get rounded corners on windows using fvwm. I know that there is an unofficial patch around for this, but I was looking to hopefully avoid going out of the official version. If it is not possible to get rounded corners on windows using fvwm, are there any plans for adding this support? If so, soon? Longer? Why not just adapt the patch? Generally Fvwm only adds frivolous things (like FvwmAnimate), when they don't add bloat to the core of fvwm. I found a file named 09-FluxRoundedCorners.patch It doesn't qualify. OK, I am sorry for this naivete, but I don't know what parts in the patch cause the bloat: can they be worked around? (Of course, by that, I mean easily, since after all, anything can possibly be worked around.) If that's the complete patch, it's lacking documentation and only works with 2 radiuses, would attempt to curve a 1 pixel border. In short, it looks like a hack. On a somewhat related question: is it possible to have the window title (the bar at the top of the window, right) not go entirely from left to right, but only part on the left. So that it looks like kind of a tab to the window. Would someone know how to do that ? Nope. So, this is not possible? Not that I know of. FvwmTabs does something different. I don't know why I'd want a truncated title leaving an unusable gap. -- Dan Espen
Re: rounded windows using fvwm
Ranjan Maitra stat.mai...@inbox.com writes: Hello, I was wondering if it is yet possible to get rounded corners on windows using fvwm. I know that there is an unofficial patch around for this, but I was looking to hopefully avoid going out of the official version. If it is not possible to get rounded corners on windows using fvwm, are there any plans for adding this support? If so, soon? Longer? Why not just adapt the patch? Generally Fvwm only adds frivolous things (like FvwmAnimate), when they don't add bloat to the core of fvwm. I found a file named 09-FluxRoundedCorners.patch It doesn't qualify. On a somewhat related question: is it possible to have the window title (the bar at the top of the window, right) not go entirely from left to right, but only part on the left. So that it looks like kind of a tab to the window. Would someone know how to do that ? Nope. -- Dan Espen
Re: [50 character or so descriptive subject here (for reference)]
andrew.n.riley anri...@ecsmtp.fm.intel.com writes: Configuration Information [Automatically generated, do not change]: uname: Linux fmci22064 2.6.16.60-0.58.1.3835.0.PTF.638363-smp #1 SMP Wed Dec 2 12:27:56 UTC 2009 x86_64 x86_64 x86_64 GNU/Linux compiler flags: gcc -Wall -Wno-implicit-int -fmessage-length=0 -D_FORTIFY_SOURCE=2 -O2 -Wall -g -fno-strict-aliasing FVWM Version: 2.5.12 FVWM_MODULEDIR: /usr/X11R6/lib/X11/fvwm2 FVWM_DATADIR: /usr/X11R6/share/fvwm FVWM_USERDIR: /nfs/fm/disks/fm_home_a1fs/anriley Description: I cannot get a new vnc session to load fvwm-themes. Its listing a large amount of command not found errors.[Detailed description of the problem, suggestion, or complaint.] Repeat-By: When i start a new vnc, the windows manager will not load.[Describe the sequence of events that causes the problem to occur.] Fix: [Description of how to fix the problem. If you don't know a fix for the problem, don't include this section.] Fvwm-themes is not part of fvwm. I suppose they have a mailing list of their own. Also, Fvwm version 2.5.12 is pretty old. -- Dan Espen
Re: Documentation discrepancy
Philippe Grégoire gregoi...@hotmail.com writes: On 2012-10-20 21:50, Dan Espen wrote: Philippe Grégoiregregoi...@hotmail.com writes: Hi, I am working on a window placement module in perl and \ noticed a discrepancy between the documentation and the \ implementation. Got it now. Wasn't all that familiar with this area of Fvwm. Change committed. Thanks. -- Dan Espen
Re: Documentation discrepancy
Philippe Grégoire gregoi...@hotmail.com writes: Hi, I am working on a window placement module in perl and \ noticed a discrepancy between the documentation and the \ implementation. In 'FVWM::Tracker::GlobalConfig', it is said that the \ observable is value updated. However, the code uses \ value changed. As such, modules that use this tracker \ do not receive updates. Here is a patch for the documen- \ tation: --- fvwm-snap-20121011/perllib/FVWM/Tracker/GlobalConfig.pm 2009-03-17 13:09:15.0 -0400 +++ fvwm-snap-20121011p/perllib/FVWM/Tracker/GlobalConfig.pm 2012-10-18 16:52:54.0 -0400 @@ -100,7 +100,7 @@ __END__ This is a subclass of BFVWM::Tracker that enables to read the global FVWM configuration. -value updated +value changed =head1 SYNOPSYS Changed vs Updated, I'm failing to see the difference. -- Dan Espen
Re: Patch for fvwm-menu-desktop to fix UnicodeDecodeError
Thomas Funk t.f...@web.de writes:
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 [removed] ... 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-pyth
on-%28or---i-didn%27t-ask-you-to-use-the-%27ascii%27-codec!-%29/
Regards,
Thomas
--- ../cvs/fvwm/bin/fvwm-menu-desktop.in 2012-09-07 23:58:20.407275653
+0200
+++ fvwm-menu-desktop.in.py 2012-09-08 00:10:36.551201906 +0200
@@ -409,7 +409,18 @@
iconfile = geticonfile(icon) or getdefaulticonfile(command) or icon
if not iconfile == '':
iconfile = '%'+iconfile+'%'
-printtext('+ %s%s %s' % (name, iconfile, command))
+# fix unicode decode problem like
+# UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position
xyz: ordinal not in range(128)
+try:
+printtext('+ %s%s %s' % (name, iconfile, command))
+except UnicodeDecodeError:
+try:
+unicode_name = name.decode(iso-8859-15)
+unicode_command = command.decode(iso-8859-15)
+text = '+ %s%s %s' % (unicode_name, iconfile, unicode_command)
+print text.encode(iso-8859-15)
+except:
+sys.stderr.write(A menu entry cannot decode! Skipping it ...\n)
def parsemenus(menulist, desktop):
global menu_entry_count
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?
Don't other calls to printtext using menu names share this problem?
Just wondering if it makes more sense to put the logic in printtext.
How about just printing the text without encoding it, if encoding fails?
--
Dan Espen
Re: Patches for fvwm-menu-desktop to support other mini icon directory
Thomas Funk t.f...@web.de writes: 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. They sound like good changes. Might take a few days, a bit late now, and some guests coming over tomorrow. Thanks. -- Dan Espen
Re: Status update
Thomas Adam tho...@fvwm.org writes: Hi all, Can I please have a status update about how close we might be to needing another release? Just so I know when I might need to start creating tarballs. I'm hoping it won't be past the end of next month, as I now cannot devote time to this project. I believe the fvwm-desktop-menu stuff is in working order. I did not look closely at the issue about make rpm-dist not working. It doesn't work for me either but it looked like it wasn't working because the tar.gz wasn't where it was supposed to be. I don't build inside the source tree. I didn't try Tom F's suggested solution. If that fixes it, I wouldn't understand why. The only other pressing issue I'm aware of is snapshots getting built off of 2.7. -- Dan Espen
Re: Status update
Jason L Tibbitts III ti...@math.uh.edu writes: DE == Dan Espen des...@verizon.net writes: DE The only other pressing issue I'm aware of is snapshots getting DE built off of 2.7. I think I have things going again; for whatever reason the script really didn't like building from a fresh checkout. It does actually appear to validly fail to build, however: /usr/bin/msgmerge --update fvwm.ar.po fvwm.pot fvwm.pot:321: duplicate message definition... fvwm.pot:36: ...this is the location of the first definition /usr/bin/msgmerge: found 1 fatal error make[1]: *** [fvwm.ar.po] Error 1 I had to make target update-po to cause the error. I don't think at this point that I'm doing anything wrong I don't think so either. I've committed a change. -- Dan Espen
Re: Snapshots
Jason L Tibbitts III ti...@math.uh.edu writes: I stopped doing the snapshots a while back. I could do them again, I guess, but, really, why not just build yourself if that's what you want? I download from CVS and build myself. I suppose a tgz is easier for users to work with? We do provide them for releases. If no one else thinks we need them, I'll update the web pages to match the current situation. I'll give it a few days. -- Dan Espen
Desktop changes
Hi, I've applied the fpl file. TA: If you still have problems with the PerlLib issue, please clarify. I had problems with it picking up the old form information so I've changed the form name. 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. This might be a good time to think about adding a separator to FvwmForm because those headings don't do it for me. Anyway, thought you guys might get a laugh out of my form default colorsets: http://tinypic.com/view.php?pic=21oops1s=6 -- Dan Espen
Replying on fvwm-workers
Guys, you're driving me nuts. On the fvwm list we never know if the person posting is subscribed so we reply to all. Here on workers, we know each other is subscribed. PLEASE, only reply to fvwm-workers. I don't need 2 copies of every email! -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: I am willing to do the job of rewriting it but I need help. If you could take some of your spare time to give me hints and answer questions fairly would be fine. What I want to say is, that i want an open, honest and constructive discussion about the programming and functionality of the module and not RTFM - I do this every time before I asking. So if you're willing to be a mentor in a sense I am ready to programming it. Looks like I should educate myself too. Back when I'm a bit smarter. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: 2012/7/18 Dan Espen des...@verizon.net: I'm guessing dbus or some other abomination does the job for the desktops... I've checked the internet for finding infos how the Distributions/ Desktops do the automatic menu update process. Here're my results: Debian: When a package that wants to add/remove something to/from the menu tree gets installed/removed, it will run update-menus in its postinst/postrm script. http://www.debian.org/doc/packaging-manuals/menu.html/ch2.html - see chapter 2.1 http://www.debian.org/doc/packaging-manuals/menu.html/ch4.html - See chapter 4.2 KDE: Use kbuildsycoca4 to update the configuration cache in KDE https://bbs.archlinux.org/viewtopic.php?id=64514 Gnome: found nothing about how they do it. I send an email to the LinuxMint developers because they made their own menu (mintmenu) but got no response back yet. Xfce: Before 4.8 they use libxfce4menu. In the sources there're comments that they use filesystem monitoring - down line 171 http://bazaar.launchpad.net/~vcs-imports/libxfce4menu/trunk/view/head:/STATUS Since 4.8 garcon is used. Also with filesystem monitoring - http://wiki.xfce.org/dev/garcon In the Xfce wiki page (http://wiki.xfce.org/howto/customize-menu) they said also that xfdesktop session starts, changes to the menu file are implemented immediately. (for Xfdesktop 4.5 or higher) Or reload xfdesktop Fluxbox and other WMs: Per default no automatic update. User have to do this manually. The thoughts doing this over dbus or other stuff: found nothing about specific messages used by package systems to inform tools to start menu updating. Summary: - Debian do updating Debian specific - not usable - depends on package mgmt. - Some DEs do updating specific too via daemons - too much dependencies - Xfce do filesystem monitoring/scanning - Other WMs don't update automatically - No event messages available to initialize menu updating Looks deflating. 2012/7/23 Dan Espen des...@verizon.net: Over here: http://crunchbanglinux.org/forums/topic/5370/how-to-set-up-a-dynamic-xdg-menu-for-openbox/ http://tinyurl.com/84jdvcy I see they are talking about using inotify to know when menus have been updated. Not something I'd recommend. Manual update still seems preferable (to me). inotify sounds interesting but another dependency again. I still prefer the filesystem scan by ourself if at all. I found the idea in the sources of Marchfluxmenu: They do this with 'ls /usr/share/applications/*.desktop | wc -l'. They remember the count and if it changed a menu update starts. One directory is enough for them because they use the applications menu only. But I am not sure if this is enough for our menus. Must check this first. But if so a scan tooks milliseconds and the load is insignificant. We could do a scan perhaps every minute. This could be enough to rebuild the menus without recognition by the user. Another advantage is no dependency with dbus and other 'abomination' as you said. We need no entries for daemons to register us, no restarts of them and so forth ... Personally I haven't either a problem with manual nor with automatic updating. Both have their own charm ... But for a automatic menus update we need another solution - a module as Thomas suggested. Excellent work. Lots of people expect their system to be able to go to sleep, hence my dislike for polling. Sounds to me like Debian has it right. (Specifically invoking a process after menus change.) I wouldn't be surprised to see a solution being implemented in other distros in due time. In the mean time, I think we're fine as is. Again, personal issues piling up. Forgive me for dragging my feet on patch application. I'll try to get to it ASAP. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: Dan Espen des...@verizon.net wrote: Thomas Funk t.funk...@googlemail.com writes: Dan Espen des...@verizon.net wrote 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) I think it's time for me to commit this fpl file. It comes without Makefile.am consideration or even a place to put it. Which directory do you see it being in? Doesn't it need a man page? Thomas Adam made some comments about using FvwmPerl. Is that resolved? I'm not all that familiar with FvwmPerl myself. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.funk...@googlemail.com writes: 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? 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. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
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. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: Dan Espen des...@verizon.net wrote: 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. 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. Over here: http://crunchbanglinux.org/forums/topic/5370/how-to-set-up-a-dynamic-xdg-menu-for-openbox/ http://tinyurl.com/84jdvcy I see they are talking about using inotify to know when menus have been updated. Not something I'd recommend. Manual update still seems preferable (to me). I don't think insert-in-menu is a problem, in fact it's pretty nice. I just wanted to point out it's limitation. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: 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 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. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: 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. That appears to be a patch against the old version of the man page. Haven't you been doing CVS updates? -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
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. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
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. 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. You're English it pretty good. No such word as founded though. Rule of thumb, NEVER use the word will in documentation. Always describe features as already there. Committing the menu-desktop changes for now. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: 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. I guess I mis-understood. If you are writing the man page as asciidoc, that's what should get checked in. I'm guessing the other fvwm developers are okay with going to asciidoc? -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Adam tho...@fvwm.org writes: On 19 July 2012 22:11, Dan Espen des...@verizon.net wrote: I'm guessing the other fvwm developers are okay with going to asciidoc? No. I have an attempt at this, but it's not finished. We either use groff or nothing, and I don't mean groff backported from some conversion tool. If you don't know groff, start learning. I thought since you were making the attempt, you thought asciidoc would be a good direction to go in. The alternative approach is to put the fvwm-menu-desktop under docbook's control. These are the only two options. Okay with me. TF: All I really need is the words. I can add (t)groff/man markup as needed. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: 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? As you probably know by now, I did. 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. I don't see get-menus in the man page. I think you want the option to be: --get-menus all | desktop with an error for any other value. Rule of thumb, NEVER use the word will in documentation. Always describe features as already there. Ah, ok. Not known. Thanks for the tip. Pet peeve. We tend to write documentation describing new features as this will do X, but when the reader sees it, it does do X. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Adam tho...@fvwm.org writes: On Thu, Jul 19, 2012 at 05:48:25PM -0400, Dan Espen wrote: Thomas Adam tho...@fvwm.org writes: On 19 July 2012 22:11, Dan Espen des...@verizon.net wrote: I'm guessing the other fvwm developers are okay with going to asciidoc? No. I have an attempt at this, but it's not finished. We either use groff or nothing, and I don't mean groff backported from some conversion tool. If you don't know groff, start learning. I thought since you were making the attempt, you thought asciidoc would be a good direction to go in. Yes it will be when it's ready. It's pretty much done, bar some plugging in scripts so it builds. But until I can finish that and then rip out the other docs, having it in Asciidoc means we can't use it, and that's bad. If we add an asciidoc file, I'd expect the Makefile to be modified to produce the man page or html as required. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.funk...@googlemail.com writes: 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. Polling for changes? Nope, I'd rather require specific user action. 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. 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. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: Dan Espen des...@verizon.net wrote: Polling for changes? Nope, I'd rather require specific user action. Suggestion: First step We release fvwm-menu-desktop as is or with my last patch and the reworked FvwmPerl script - user must update manually the menu(s) Second step In the next or ensuing release with the FvwmMenu module which polls e.g. every 5 min /usr/share/applications, /usr/local/share/applications and $HOME/.local/share for changes. This poll takes not much cpu load and time. I've tested this with time find /usr/share/applications -name *.desktop |wc -l 189 real0m0.088s user0m0.000s sys 0m0.004s And if the count in/decrease it starts a silent regenerate. So, user doesn't need updating after installing/removing a new package. But can regenerate manually already. 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. And ... what do you think about this proof of concept apart from that it is a little bit slow (will test Thomas' suggestion with IPC::Run) and not FvwmPerl like? I'm guessing dbus or some other abomination does the job for the desktops... -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Adam tho...@fvwm.org writes: On 16 July 2012 15:37, Thomas Funk t.funk...@googlemail.com wrote: 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. Isn't this in the XDG spec as to which menus appear where, in categories? I'm sure it is. 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 No. That's just admitting to not wanting to fix the problem. :) ? 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. That might be useful longer-term, but I think I'd rather see the basics of this menu generation working first of all. The basics work pretty well. I really think the XDG folks have paid little attention to the concept of a main menu or any organization at that level. 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? Despite the duplication, the current default of generating everything at least gets me at all the menus the other desktops support. I hate hunting for the right GUI configuration tool when I can't figure out the right command line tool. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
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. I'm guessing that there is some way you can get auto-notification of a menu update but I don't know what that is. -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
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? -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.funk...@googlemail.com writes: 2012/7/6 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. For example, with no arguments: AddToMenu FvwmStart-here + Preferences Popup Preferences AddToMenu FvwmSettings + Preferences Popup Preferences I realize the XDG spec isn't helping but would some trimming be in order? -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: Dan Espen des...@verizon.net writes: It' works over file weighting because it's too complicated to check distribution relevant paths for finding the default desktop. Can you explain the weighting in terms a user would understand. I read the code once and still didn't have a clue. 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. 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. 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. I got a little feedback from the xdg folks: DE I just don't get the logic of having a standard for DE just the applications category. I believe the rationale is that only applications.menu is reserved by the spec, and XDG_MENU_PREFIX was a way to handle conflicts between different applications.menu shipped by different desktops. No other menu name is defined in the spec, and so we were instead relying on the fact that desktops would not create conflicts. That being said, I don't think I'd be opposed to using XDG_MENU_PREFIX for all .menu files. We should just make sure that it doesn't create any compatibility issue. It doesn't sound to me like they are going to address the issue in the near term. I'd like to implement what's best for Fvwm. If XDG gets it's act together later we can replace what we've done with something simpler. So maybe you can clean up this version a bit more and submit as a patch? Thanks for your efforts, and I'm getting a few python lessons along the way... -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a full menu
Thomas Funk t.f...@web.de writes: Hi, attached is my first try of a fvwm-menu-desktop which creates a menu with all desktop related menus (if they have entries). Interesting. It' works over file weighting because it's too complicated to check distribution relevant paths for finding the default desktop. Can you explain the weighting in terms a user would understand. I read the code once and still didn't have a clue. It works under OpenSuse, Fedora, Mandriva and Debian fine and creates a menu with a structure like this: Fedora 14 example Root: Documentation Gnome-applications Gnome-screensavers Gnomecc Preferences Server-settings Settings Start-here System-settings 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. 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... ^^^ 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' I've attached the complete file and not a patch because too much changed and it's easier for testing ^^ Not good. Doesn't contain the Usage fixes I recently committed. I'm not sure how you're testing, but there's a hint at the bottom of the file that Emacs reacts to. If you test that way there are 2 benefits: 1. We have less chance of losing the #!@PYTHON@ line. 2. Diffs will work without me having to change the file names. The other functionality with --desktop=whatever_desktop_name, --menu-type=whatever_menu_name or/and --install-prefix=whatever_path should work also. Dan, I don't know if applications-gnome.menu would be created. In my simulation it is listed but there could be problems with the xdg-automatism. See here: http://lists.fedoraproject.org/pipermail/devel/2011-August/155342.html https://bugzilla.redhat.com/show_bug.cgi?id=754845 I see. If it's been declared a bug, and it looks like it, we can just ignore applications-gnome because it will probably go away. And I found a very interesting entry at the end here: http://people.gnome.org/~walters/0001-Ship-applications-gnome.menu.patch which could be explain the change from gnome-applications.menu to applications-gnome.menu: +* Mon Apr 11 2011 Colin Walters walt...@verbum.org - 3.0.0-2 +- Ship applications-gnome.desktop; we don't want GNOME 3 to use redhat-menus. I must be dull. Can't see why they did that. I've subscribed to the xdg mailing list, asked my question. Still waiting for an answer. Meanwhile, the man page is about half done. -- Dan Espen
Re: [Patch] fvwm-menu-desktop improvements
Thomas Funk t.funk...@googlemail.com writes: 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? 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. Shouldn't there be a xxx-settings.menu and a xxx-documentation menu? If there were, the menu prefix would make sense. Maybe no prefix for the distro default, and xxx- prefixes for each desktop package. I see that Gentoo claims to have a gnome-applications.menu. Maybe what I'm seeing in Fedora is just a Fedora issue. Might be time to subscribe to the xdg list. This might take a while... -- Dan Espen
