Re: Modules and receiving MX_* packets
Thomas Adam writes: > Hi Dan, > > Hope everyone's well. Here in the UK, we're officially allowed out to a pub > and other places. But I'm staying clear of all of those for now -- we're > likely days away from either a local lockdown or a second national wave of > Covid-19. I don't want to be undoing the hardwork I've put in to remaining > healthy! Hi, As well as can be. I'm living by myself so it's maybe tougher than for some others. It helps to be an introvert. At least one pool hall is opening here in NJ next week. I'd really like to get in some practice but even though our numbers in NJ are pretty good, I don't think so, at least for a few more weeks. So, since I'm retired pool, gym, and swimming are my big activities. None of them a good idea right now. I'm spending most of my time fixing things in the house. As you must know, the virus is out of control here. NJ is okay but I don't know how long that is going to last. -- Dan Espen
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(&event) ) {
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 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 writes: > On Sat, Feb 10, 2018 at 8:38 AM, Dan Espen 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 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 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 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 writes: > On Mon, 19 Sep 2016 at 12:57 Ron Tapia 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 writes:
> * Thomas Adam [160625 06:41]:
>> On 24 June 2016 at 01:23, lee 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...Setup Form
Thomas Adam writes: > On Thu, Jun 02, 2016 at 03:07:27PM -0400, Dan Espen wrote: >> 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. > > It is outdated for two reasons alone: > > 1. The syntax alone is arcane by FVWM's standards. For instance: > > Next [*] ... > > versus: > > Next (...) Simple enough to fix. > 2. The list of applications (via menus or Style lines) are from the arc, and > no longer reflect the de facto set of programs typically installed along > with most distributions. The only outliers I can think of here might be a > few of the major BSDs. Well, "*lock" was meant to handle all known clock programs. Still works for me. XTerm/rxvt still works for me too, but "*term" might be a good addition. I use xmag as opposed to all the other magnifiers. But when I put those apps in there, all anyone could expect is that they were the apps I was familiar with. More could be added, but I suspect EWMH hints covers some of those bases now. > Both the above tell me that FVWM has rested on its laurels for far too long. > Those people who do decide to use the mechanism of what the Setup forms > provide, clearly can't be relying on much. So what do they gain by using > these configs? Maybe it's the FvwmButtons configuration? I can't say, but > I'd guess that over anything else. What they gain, and what it was meant for, is new users curious about Fvwm. Without a config, the casual user will get no where and most likely look somewhere else. The WM came up and you couldn't even create a window. Previous to the Setup Form, we would tell a new user to copy/rename the provided sample to get going. With your changes, we don't even provide a sample. >> 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. > > That's rather cute, but SunOS died a long time ago, especially since Solaris > pretty much took over that market even by the time I poked around such > machines. I just can't justify supporting that kind of idea any more. Solaris is SunOS (5). But I admit I've been using Fvwm from even before the Solaris branding. >> Since you are primary developer, feel free to ignore me on this. >> As I said, not a big deal to me. > > That's humbling that you'd see me as such, but I am by no means ignoring you, > rather I'm trying to open your eyes to what most of the other players are > doing, and hence how the applications that typically came with > SunOS/Solaris/BSD are in the minority, as are the number of users of those > systems/applications as well. > > It always comes back down to what's realistically maintainable, and what > *should* be maintainable by those developers who choose to work on FVWM. Part > of that is about setting expectations on the remit of FVWM as a window > manager, and the environment it is typically deployed in. For that, we have > to look towards the common set of Linux distributions, more than anything else > [0]. Agree. > This entire set of work did indeed start with deprecating modules, and that's > fine. What this has proven to me (with your helpful guidance) is that we can > go further in the efforts I've started, because of certain modules being > deprecated. As far as the internal configuration goes, and having FVWM > provide its own set of values to the user in the case where they have no > config, should be a clean slate for those people(s) who wish to work on such a > thing. This is what I see as a good provision, and although that might be > seen as heavy-handed, the impact in the long-term will be beneficial. > > So given all of that, I'm inclined to proceed---but I am not personally > interested in providing a new configuration myself, but I am willing to offer > mentoring and help to people who want to work on this, as I have a better idea > on how to do that which isn't as invasive as it has been in the past in terms > of spreading out over multiple files. Should anyone want to chat about this, > I'm all ears. Not clear what you mean here. Are the multiple files the sample and the Form in the modules directory or do you mean the potentially multiple files created by the setup form? Pretty easy to fix the later. > Dan, does this help explain things? If it does, I&#
Re: Deprecation: Let's talk once more about removing $STUFF...
Thomas Adam 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 writes:
> On Tue, May 31, 2016 at 04:58:57PM -0400, Dan Espen wrote:
>> Fvwm uses FvwmTaskBar, for example in file:
>>
>> sample.fvwmrc/system.fvwm2rc-sample-95
>>
>> Those uses need to be eliminated before the module goes.
>
> Thanks. Removed the whole lot, in favour of out-of-tree configurations via
> fvwm-{themes,crystal}, etc.
I think you missed the part where Fvwm's built in menu creates an Fvwm95
type configuration. (It uses the files you just removed.)
Take a look at:
fvwm/modules/FvwmScript/Scripts/FvwmScript-Setup95
Look further and you'll find the other files in sample.fvwmrc
are used too.
Let me make some comments here.
Long ago I created the FvwmSetup Form.
When Win95 came out, everyone wanted to go there.
When FvwmScript-Setup95 was created, I was less than happy
because the Script and Form went in 2 different directions.
Sadly, I had other things on my mind and didn't do much about it.
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.
I suggest a recursive grep to find out where those files are used
or perhaps mentioned in the documentation.
--
Dan Espen
Re: Deprecation: Let's talk once more about removing $STUFF...
Thomas Adam writes:
> On 31 May 2016 9:31 p.m., "Thomas Funk" wrote:
>>
>> On 05/31/2016 09:30 PM, Thomas Adam wrote:
>>
>>>
>>> On 19 May 2016 4:18 p.m., "Thomas Adam" <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 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 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
Thomas Adam writes: > On Thu, Jun 18, 2015 at 12:17:02PM -0500, Jason L Tibbitts III wrote: >> >>>>> "DE" == Dan Espen writes: >> >> DE> Can you convert and retain the change history? >> >> Certainly. I converted my Majordomo2 repository to git and dumped it on >> github so that I'd have one less thing on that CVS server. Took only a >> few minutes. You do need access to the raw repository files for the >> best conversion, but of course I have those. >> >> I think that folks here don't like github, so I'll see if I can put >> together a git server locally. Might take me a bit as I'm buried. > > See: > > http://thread.gmane.org/gmane.comp.window-managers.fvwm.devel/4839 > > Which was the last discussion about this. I'm more than happy to help > with this, but it cannot be rushed as there's always a few things to > work out first. > > On Github, I've been mirroring and using fvwm and fvwm-web for years. I know. That discussion starts with the assumption that the git repository would be somewhere else. (It mentions removing a burden for Jason.) I welcome opinions, but if I have my choice, I'd like our source repository to remain at fvwm.org. -- Dan Espen
Re: Fvwm commit problem
Jason L Tibbitts III 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: Fvwm commit problem
Jason L Tibbitts III 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: Bug#777685: Resizing of Gnuplot Qt windows sometimes flicker and fail
Vincent Lefevre 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 <> > 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 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 <> 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 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: CVS dane: new file ChangeLog-pre-2.6.6
Dominik Vogt writes: > On Mon, Sep 15, 2014 at 02:08:44PM -0400, Dan Espen wrote: >> Not sure I want to work in the mvwm tree. >> Not fond of the name, > > Neither me, but more because the "M" gets in the way with tab > completion in the subsirs (also matches Makefile*). I want to avoid the impression of a fork, and F=Feline is fine with me. But our poor Angel died and I'm too old for another cat. >> and don't want to see FvwmCPP go away. > > But the module is already back. :-) > > I think at the moment it should also be possible to add the fvwm > modules to the module path and use them with the new core. If not, > I'm interested in finding out what has to be done to make them > compatible. Fvwm probably has some compatibility check that might > prevent it. Not sure what you mean with the last paragraph. The built in module path should deal with running multiple versions of modules. I usually install fvwm to something like: ~/fvwm/2.6.6/ <-- version number, but could be anything. -- Dan Espen
Re: [OT]: Using Emacs
Thomas Adam 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"
Thomas Adam 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 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., i., 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: "GetNextSimpleOption" "is broken"
Dominik Vogt writes: > On Tue, Sep 02, 2014 at 06:07:44PM -0400, Dan Espen wrote: >> Dominik Vogt 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"
Dominik Vogt writes: > On Tue, Sep 02, 2014 at 05:48:05PM -0400, Dan Espen wrote: >> Dominik Vogt 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 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: REWRITE: New parser design
Thomas Adam 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: Historical Parsing (twm onwards) [WAS: Re: REWRITE: Parsing]
Thomas Adam 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: Some removed features
Thomas Adam 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: REWRITE: Some removed features
Thomas Adam writes: > On Mon, Aug 18, 2014 at 03:18:13PM +0100, Dominik Vogt wrote: >> Some features that have been removed in mvwm that I'm not sure >> about: >> >> 1. FvwmCpp and FvwmM4 > > Heh. In my mind, it came back to maintainability, and from time-to-time we > often see problems with people trying to use these modules. but with nonone > in the development team really "owning" them, so most of the problems end up > either being ignored or worked around at some higher level. (Some of the > problems may be surrounding the whole approach of ModuleSynchronous, etc., > but that's tangential to my point.) Since I added ModuleSynchronous, I'll defend it. If I recall correctly, it made sense for FvwmAnimate and I'm not aware of it causing any problems. I also use CPP, a very nice feature. I'm not really in favor of pulling features without having a good backup plan. -- Dan Espen
Re: names in auto generated menus
Dominique Michel writes:
> Le Fri, 03 Jan 2014 10:34:24 -0500,
> Dan Espen a écrit :
>
>> Dominique Michel writes:
>>
>> > Le Fri, 3 Jan 2014 15:07:52 +0100,
>> > Dominique Michel 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: names in auto generated menus
Dominique Michel writes:
> Le Fri, 3 Jan 2014 15:07:52 +0100,
> Dominique Michel 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.
For my own music, I run a script that "fixes" the file names.
--
Dan Espen
Re: To remove a key binding fail with -
Dominik Vogt 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: To remove a key binding fail with -
Dominique Michel writes: > Le Wed, 18 Dec 2013 12:52:59 +0100, > Dominique Michel a écrit : > >> Hi, >> >> In fvwm man page: >> >> 31.6.5. Key >> >> Key [(window)] Keyname Context Modifiers Function >> >> Binds a keyboard key to a specified fvwm command, or removes the >> binding if Function is '-'. >> >> If I have ardour running, its class is Ardour, I get the following >> into the fvwm console: >> >> Key (Ardour) B W M ToggleFail > > Maybe I was not clear enough. When ardour have the focus and I press > Alt+B, I get the following: >> [fvwm][__execute_function]: <> No such command 'ToggleFail' > That imply the binding work fine. > >> # The ToggleFail function doesn't exist >> >> Key (Ardour) B W M - > Idem, that imply the binding was not removed: >> [fvwm][__execute_function]: <> No such command 'ToggleFail' It's pretty clear to me Fvwm doesn't work as expected when you try to remove a binding with '-'. During the removal process it should NOT be validating the command in the binding. I can't commit to a time frame to fix right now. Patches are always appreciated. >> # To remove the binding fail, but the following work: >> Key (Ardour) B W M >> >> More strange is the following sequence: >> Key (Ardour) B W M ToggleFail > The binding work: >> [fvwm][__execute_function]: <> No such command 'ToggleFail' >> Key (Ardour) B W M ToggleWork > The new binding work: >> [fvwm][__execute_function]: <> No such command 'ToggleWork' >> Key (Ardour) B W M - > The binding was not removed, but put back to its preceding state: >> [fvwm][__execute_function]: <> No such command 'ToggleFail' > The way to remove a binding as stated into the man page doesn't work: >> Key (Ardour) B W M - >> [fvwm][__execute_function]: <> No such command 'ToggleFail' > The only way to remove a binding: >> Key (Ardour) B W M >> # work I don't think that actually works (haven't looked yet). It might be setting the binding to an empty command. Empty commands are skipped so they appear not to be there. -- Dan Espen
Re: bug in 2.6.5's bin/fvwm-menu-desktop.in
Mathieu 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 writes:
> Dan Espen wrote:
>> Thomas Funk 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 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 * 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 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" writes: > On Tue, Nov 12, 2013 at 8:19 AM, Dan Espen wrote: >> Arne Wichmann writes: >> >>> begin quotation from Dan Espen (in ): >>>> Arne Wichmann writes: >>>> >>>> > begin quotation from Schaaf, Jonathan P (GE Healthcare) (in >>>> > ): >>>> >> > 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)" Subject: Re: CVS dane: * fvwm/events.c (HandlePropertyNotify): Disable prior fix suspected of causing To: "@HEALTH CST" Cc: FVWM CVS 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 writes: > begin quotation from Dan Espen (in ): >> Arne Wichmann writes: >> >> > begin quotation from Schaaf, Jonathan P (GE Healthcare) (in >> > ): >> >> > 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 writes: > begin quotation from Schaaf, Jonathan P (GE Healthcare) (in > ): >> > 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: fvwm: In FvwmWinList, the list shows the title names instead of the icon names
"Schaaf, Jonathan P (GE Healthcare)" writes: >> 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. Yes, please let us know how that works out. I'll revert the patch in 2.6.6 if it turns out to be the culprit. -- Dan Espen
Re: Spelling Error in FvwmPager Manpage
"Vincent W. Chen" 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: Manpage for fvwm-menu-desktop GUI
Thomas Funk writes: > Hi Dan, > > I have attached the new manpage for fvwm-menu-desktop-config. > Would you be so kind to review it for spelling and grammar errors, > please? Some changes, some comments: fvwm-menu-desktop.config.1 Description: revised plus comments -- Dan Espen
Re: Restructured fvwm-menu-desktop-config and xdg menu question
Thomas Funk writes:
> Hi Dan,
>
> I have implemented two new options in fvwm-menu-desktop:
> --app-icon NAME set default application icon if no others found.
> Default is gnome-applications.
> --dir-icon NAME set default directory icon if no others found.
> Default is gnome-fs-directory.
>
> because gnome-applications' and 'gnome-fs-directory' not available in
> all icon themes.
>
> Therefore I have restructured fvwm-menu-desktop-config to reduce the
> window size to place the new options.
>
> Would you check my new placements please if it is understandable? I
> have removed some descriptions to hold the layout compactly. If all
> suits I will write a manpage for fvwm-menu-desktop-config.
I see you've hard coded fonts for the FvwmForm:
*${modname}: Font 7x13bold
*${modname}: InputFont 7x13bold
*${modname}: ButtonFont 7x13bold
I don't think that's a good idea.
I'm using much bigger fonts due to my high resolution monitor.
Since we have a GUI for setting FvwmForm defaults, I don't think we
should be overriding those fonts in one of our tools.
Everything else looks okay.
"Usage" is misspelled on the first comment line in the .fpl file.
> Attached is fvwm-menu-desktop-config.fpl and the new fvwm-menu-desktop
> for testing.
Had me confused there, I didn't think you had commit access set up yet.
> Another point is the thing with a xdg menu for Fvwm. Should we ship
> such menu with Fvwm generally? If so the question is what should we do:
> install it under /etc/xdg/menus/ or ship it as an example file and the
> user can decide by her/himself?
>
> I have created a common one with the needed directory files and it
> works fine on most systems. In some parts it could be changed but that
> is another point ;-)
Not sure what you mean, I think you're talking about .desktop files with
Fvwm options in it, like start/restart Fvwm, etc? So that when someone
installs Fvwm they get menu options to start Fvwm.
If so, definitely yes, it's something I wanted to do but never got to it.
--
Dan Espen
Re: Notes to the future maintainer
Thomas Adam writes: > On Mon, Sep 23, 2013 at 09:57:25PM -0400, Dan Espen wrote: >> Thomas Adam 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
er-project hosted sites are > not going to cut it in 2013, chaps and chapettes. Really. Get yourselves > noticed, and go hang with the cool kids. Sure, you could make git.fvwm.org > authoritative, but at least have an official mirror on something like > GitHub. It's where projects are noticed nowadays. You can create > organisations therein and list members; might make the CVS 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 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,
> D> > gc = 0x80482f840, colorset = 0x804a13410, win = 18874669, x = 3, y =
> 33,
> D> > len = 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: fvwm frees invalid pointer
Gleb Smirnoff writes:
> On Tue, Sep 17, 2013 at 10:04:52AM -0400, Dan Espen wrote:
> D> > Just 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 writes: > Hi! > > Just got a very different panic. It may be unrelated > to the free/malloc problems, but since fvwm was rock stable > for the last 10 years for me, I'm prone to think that all > my recent crashes are caused by the same single problem. > > (gdb) bt > #0 0x004daab8 in FlocaleDrawString (dpy=0x804831000, > flf=0x80482f980, > fws=0x80482aec0, flags=0) at Flocale.c:1983 ... > Core saved, I can provide more info. Starting to look like a memory overlay somewhere. In which case valgrind or one of the other memory checkers would be more useful. Do "list". Print fws, *fws, comb_chars, i. -- Dan Espen
Re: fvwm frees invalid pointer
"Schaaf, Jonathan P (GE Healthcare)" writes: >> Sorry, I've tried just setting LC_TYPE to ru_RU.UTF-8. >> That doesn't seem to be sufficient to cause the problem. >> Any more hint's would be helpful. > > My reproduction procedure involves more superstition than science, so > it's probably less than helpful. I can't get it to work myself when I > move to a different computer, and can't find any identifiable settings > that should have an impact: > > set LC_CTYPE, > start the gimp, > open a .jpg file, > use "save as" to save to a new filename, > accept the compression settings, > select file-> close, > then file->quit. > > If that doesn't work the first time... save yourself some time and > don't try again. If it does work, it seems to repeat almost every > time. > > I haven't figured out what's going on yet, but here are my observations so > far: > > (1) The LC_CTYPE environment variable is causing gimp/firefox/whatever > to use names that are localized, which creates a name_list in > Flocale.c. This means that the LC_CTYPE variable does NOT need to be > set when launching FVWM. > (2) Just before the crash, I see two completely different functions causing > the same name_list to be freed. >a) The first to free is within EWMH_WMName(), when it calls > free_window_names(fw, True, False). This ultimately frees > fw->name.name_list. >b) The second free is within destroy_icon(), when it calls > free_window_names(fw, False, True). This ultimately frees > fw->icon_name.name_list. > 3) For reasons I do not yet understand, in the crash situation > fw->icon_name and fw->name of a different window have an identical > name_list. When the second free of the list happens, fvwm crashes. > > I'll keep tinkering with this in my spare time, and I'll see what I can > figure out. There's a bit of a mess in there, but every free should be accompanied by a setting of the pointer to the freed item being set to NULL or in some cases "Untitled". As long as the areas are checked before free, everything should be okay. There's also the case where name and name_list represent the same object. That's why we see this in Flocale.c: if (ptext->name != NULL && ptext->name != *ptext->name_list) XFree(ptext->name); name and name_list represent the same thing so it only wants to free one of them. Like I say, a bit of a mess. But I need to be able to create the problem before making a fix. So far I'm unable to even get into the code, but I'm American and hopeless with foreign languages. I did get Russian in my title bars, but no tracing of the area with the abend. If this is inconsistent, efence might help. It will report problems even when it doesn't crash. -- Dan Espen
Re: 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
Gleb Smirnoff 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: fvwm frees invalid pointer
"Schaaf, Jonathan P (GE Healthcare)" writes: >> Repeat-By: >>I am not sure, but the problem seems to appear after I have >>switched my locale from ru_RU.KOI8-R to ru_RU.UTF-8. > > I can reproduce this problem using GIMP (which also changes the > titlebar content after you save the file). I agree that the locale > seems to have something to do with the issue -- I wasn't able to > reproduce the issue until I set the LC_CTYPE variable. In addition to > Russian, using ja_JP.UTF-8 also causes the issue. I'm guessing you set LC_TYPE before you started Fvwm? Setting it before I start GIMP doesn't seem to cause a problem. -- Dan Espen
Re: Bugfix for fvwm-menu-desktop if only one XDG menu exist
Thomas Funk 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 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: FVWM: Forums and Wiki need new maintainers/homes
Thomas Adam writes: > Hi all, > > Given my diminishing work on FVWM, I need to think about handing over the > FVWM Forums [1] and the FVWM Wiki [2]. I cannot devote the time needed for > their maintenance, nor do I want to act as a point of contact for them > anymore. >From my point of view, I'd have no problem with closing them down. If you could direct users to the mailing lists, that would be a good thing. -- Dan Espen
Language patch?
If I remember right, there was an fvwm language patch posted for French? that I never applied. Please repost or provide a link. I'll try to apply it this time. -- Dan Espen
Re: More complex menu schortvuts
Thomas Adam 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: More complex menu schortvuts
Dominik Vogt 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: CVS dane: Patches from Thomas Funk
Dominique Michel 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 writes: > Le Sun, 5 May 2013 18:24:39 +0200, > Dominique Michel a écrit : > >> Le Sun, 05 May 2013 14:56:53 +0200, >> Thomas Funk a écrit : >> >> > Dominique Michel wrote: > >> > > >> > https://sourceforge.net/p/fvwm-crystal/code/HEAD/tree/fvwm/scripts/FontSelector/FontSelector >> > A little remark to your script >> > >> > to reduce code you can use for loops to assign your font to the >> > widgets: For $Widget=1 To 6 Do > > It look like my script have another and much bigger problem. It was > working fine yesterday, but it just crash at startup today. It I move > the ChangeTitle and ShowWidget stuffs from Init to the Periodic > section, I cannot reproduce this bug, even after restarting the machine. > > That also seam to imply that Fvwm must have some kind of internal cache > that keep stuff from a previous run of this script. How can I be sure > this cache is cleaned without to restart the machine? I don't think there is any cache. If you have a crash, you need to examine the core file. -- Dan Espen
Re: FvwmScript, UseGettext and LocalePath
Dominique Michel 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
> 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: Reproductible crash
Dominique Michel writes: > Le Tue, 23 Apr 2013 14:16:56 +0100, > Thomas Adam a écrit : > >> On 23 April 2013 14:13, Dominique Michel >> wrote: >> > Le Tue, 23 Apr 2013 12:57:38 +0100, >> > Thomas Adam a écrit : >> > >> >> On 23 April 2013 12:21, Dominique Michel >> >> wrote: >> >> So how is FVWM taken out by this? FVWM isn't crashing from the >> corefile you're showing here. > > The whole backtrace for fvwm is as follow: > > Thread 1 (LWP 32646): > #0 0x7f2db920caeb in ?? () > No symbol table info available. > #1 0x in ?? () > No symbol table info available Nothing in there to indicate that the core file is from Fvwm. Since Fvwm doesn't use threads, it looks like that's NOT Fvwm. Not sure why you would have a stripped Fvwm. If you do, you might need to recompile to get a meaningful stack dump. -- 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 writes: R> On Mon, Apr 15, 2013 at 07:44:10PM +0100, Thomas Adam wrote: >> On 14 April 2013 09:57, Dominik Vogt 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: infostore and Test condition
Dominique Michel writes: > Hi, > > I try to convert as much environment variables as possible to infostore > in fvwm-crystal. > > But I didn't find any way to use the infostore variables in a Test > command with fvwm-2.6.5. > > Test (EnvMatch myvariable value) command > > work, but > > Test (EnvMatch infostore.myvariable value) command > > did not work. > > In order to make the infostore fully useful, it would be great if an > InfoStoreMatch condition could be added to the Test command. Or > something like that. Hi, Looks like EnvMatch only supports Environment Variables. I'll see what I can do. -- 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 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: FVWM Patch for Interaction problem with Java 7
John Faucett writes: > Thomas Adam 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: [contribute] Russian translate
Spoofing 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 writes: > On Wed, Jan 23, 2013 at 6:01 PM, Dan Espen 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 writes: > Hi Dan, > > On Mon, Jan 21, 2013 at 1:13 AM, Dan Espen wrote: >> Can you update from CVS and try again? >> I've committed a change that should fix the problem. > > Did you mean "Untitled" instead of "Unknown" in that patch? Yes I did. Changes committed. -- Dan Espen
Re: Closing nedit crashes fvwm
Vladimir Klebanov 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=, 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 > Can you update from CVS and try again? I've committed a change that should fix the problem. -- Dan Espen
Re: Manpage and Spelling Errors with Patch
"Vincent W. Chen" writes:
> Hi,
>
> While trying to package FVWM 2.6.5 on Debian, I got some Lintian
> errors/warnings.
>
> manpage-error.patch:
> http://lintian.debian.org/tags/manpage-has-errors-from-man.html
> Manpage macro errors, due to lines starting with apostrophe (') or period (.).
>
> spelling-error-binary.patch:
> http://lintian.debian.org/tags/spelling-error-in-binary.html
> Misspellings in binary.
>
> spelling-error-manpage.patch
> http://lintian.debian.org/tags/spelling-error-in-manpage.html
> Misspellings in manpages. For some reason when it comes to FvwmDebug,
> FvwmPerl, and FvwmTabs, I had to modify *.1 files (FvwmDebug.1, etc.)
> rather than *.in files (FvwmDebug.in, etc.). I thought calling
> autoreconf would regenerate *.1 from the *.in files when compiling
>
> AFAIK, these bugs are also present in CVS. Attached are the patches named
> above.
Thank you. The patches have just been applied.
--
Dan Espen
Re: distcheck issues
Dan Espen writes: > 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 Error on my part. make distcheck wont work with external build directories. Works now. -- 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 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 writes: > Ranjan Maitra writes: > >> On Sun, 02 Dec 2012 00:14:45 -0500 Dan Espen wrote: >> >>> Ranjan Maitra 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 writes: > On Sun, 02 Dec 2012 00:14:45 -0500 Dan Espen wrote: > >> Ranjan Maitra 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 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" 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 writes: > On 2012-10-20 21:50, Dan Espen wrote: >> Philippe Grégoire 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 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 B 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 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
>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 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
"Jason L Tibbitts III" writes: >>>>>> "DE" == Dan Espen 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: Status update
Thomas Adam writes: > On Thu, Aug 23, 2012 at 04:53:37PM -0400, Dan Espen wrote: >> Thomas Adam 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. > > Cool. > >> I did not look closely at the issue about make rpm-dist not working. > > Oh, I don't care about that, or the debian stuff. In my opinion, both of > those should go in liey of package maintainers downstream having the correct > set of build files. > > The sooner we at FVWM realise this, the better. > >> The only other pressing issue I'm aware of is snapshots getting built >> off of 2.7. > > I've asked about this, but as of yet have had no response. If I do get > one, I'll fix it. My guess was that if we remove the 2.7 tags then the problem would fix itself. To get Jason's attention it helps to send mail directly to him. -- Dan Espen
Re: Status update
Thomas Adam 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: Snapshots
"Jason L Tibbitts III" 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
Snapshots
Just took a look at ftp://ftp.fvwm.org/pub/fvwm/devel/snapshots/ fvwm.org -> download -> snapshots They seem to run from 2003 up to 2012-01-24. Not good! Way too many old snapshots and nothing current. -- 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=21oops1&s=6 -- Dan Espen
Re: First try of fvwm-menu-desktop which creates a "full" menu
Thomas Adam writes: > On 25 July 2012 18:38, Thomas Funk wrote: >>> Dan Espen wrote: >>> Thomas Adam made some comments about using FvwmPerl. Is that resolved? > > No -- and as such, until it starts to use perllib and/or FvwmPerl, > it's not ready. There is *no* reason why we wouldn't dog-food our own > implementation of interfacing to FVWM, other than the individual > developer concerned didn't understand it. We _have_ a framework to do > all of the functionality the code currently uses; it's high-time we > use it. > >> I've fixed all what Thomas suggested except the part to do the complete >> stuff with the perllib framework. That needs a little bit more time. > > But that's the entirety of this file, as far as I am concerned. A > pretty important part, too. > >> I hope it is ok for Thomas that you want to commit it because it's only >> an interim solution. > > Until this is fixed, I would rather this wasn't put in CVS at all. As > I've mentioned my time is limited, but if I have to roll up my sleeves > and take responsibility for this, I don't mind. I'd rather not > though, but either way, someone should let me know if I have to. Okay having read the FvwmPerl man page I see that "TF" has followed the usage pattern in the tests/perl/xmessage.fpl example. It looks like the only interaction this module needs with Fvwm is to send the completed FvwmForm to Fvwm for execution. The module does this using the FvwmPerl "::command" interface. What's wrong with that? It looks like it could have been written as a script in /bin and been invoked with Piperead to get the same effect. -- Dan Espen
