Re: Changing from module arrays to module structure
On Sat, Dec 30, 2006 at 01:44:40AM +, seventh guardian wrote:
On 12/30/06, seventh guardian [EMAIL PROTECTED] wrote:
On 12/29/06, seventh guardian [EMAIL PROTECTED] wrote:
[snip]
So now comes the coding part.
I'll avoid going directly to the big beast, module_interface.c.
Instead, supposing it is working correctly, here go the changes to the
files using its functions: events.c, modconf.c and stack.c
There's a bug with this files. While iterating through them I was
working with the dummy head (bad) and forgetting about the tail (bad)!
It seems now that using a dummy head record isn't worth it, so maybe
in a future cleanup it will be replaced by a mere pointer.
The corrected patches to the above three c files goes on annex.
I'm happy to announce that the linked list is working now without any
quirks so far :)
There were some changes to the above patch, also adding a fourth
changed file (functions.c).
The new version goes on annex.
events.c:
-
** First an old bug i noticed by looking at your patch:
- if (i == npipes || writePipes[i+1] == 0)
Testing writePipes[...] == 0 is incorrect. 0 is a valid file
descriptor, and a module may actually get it under very rare
circumstances. So please remember to inizialize the fds in the
new module struct with -1, not 0.
** Pleade write comments on a line of their own. That's easier
for me to read:
+ if (module == NULL || module-next == NULL) /* last module */
** Also, in the line above, module is already guaranteed to be
!= NULL (in the third block of the patch).
** I think it would be good to remove the hide the implementation
of the list from the user with a function:
fmodule *module_get_next(fmodule *module)
{
if (module == NULL)
{
return module_list.next;
}
else
{
return module-next;
}
}
This way we can get rid of the global variable.
** -if (readPipes[i]=0)
+/* should we really do this test? */
+if (module-readPipe=0)
Yes, we should really do this. This would allow to write modules
that just take input from fvwm but never send any reply.
** -if ((readPipes[i] = 0)
-FD_ISSET(readPipes[i], in_fdset))
+if (FD_ISSET(module-readPipe, in_fdset))
Don't forget to check for readPipe = 0.
** -if ((writePipes[i] = 0)
-FD_ISSET(writePipes[i], out_fdset))
+if (FD_ISSET(module-writePipe, out_fdset))
Dito. Actually, it is really necessary to do the check for the
write pipes because modules created with ModuleListenOnly rely on
it!
functions.c:
Okay.
modconf.c:
--
Okay.
stack.c:
** -PositiveWrite(i, body, length*sizeof(unsigned
long));
+PositiveWrite(module, body,
+ length*sizeof(unsigned long));
Please reindent like this:
+PositiveWrite(
+module, body, length*sizeof(unsigned long));
So the only thing missing now is module_interface.c :) It needs a bit
of cleanup, and as soon as its clean I'll send it.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: Changing from module arrays to module structure
On Sat, Dec 30, 2006 at 12:57:20PM +0100, Dominik Vogt wrote: On Sat, Dec 30, 2006 at 02:13:29AM +, seventh guardian wrote: [snip] Ok, here goes the patch module_interface.c. The first goal of having a functional system is hopefully done. I'm going to create a branch in cvs where we can apply, test and modify the patches. Don't bother to to the changes I posted earlier; I'll do it myself. The branch name will be fvwm-module-struct-branch. To pull it from cvs into a directory modstruct-branch, issue $ cvs co -Pd modstruct-branch -r fvwm-module-struct-branch fvwm I'm done proof-reading and cleaning up the code. Casting the module pointer to int did not even work on 32-bit machines because there is a limit to the numbers that can be used in an fdset (it's a limited size bit field). Instead, I added a member slot to the module struct that has no specific meaning other that that the number is unique and is between 0 and MAX_NUM_MODULES-1 (=256, from libs/defaults.h). It's a bit expensive to maintain the highest slot used when a module is destroyed, but for now it will do. I hope thig ugly bit of code goes away soon. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Changing from module arrays to module structure
On Sat, Dec 30, 2006 at 03:01:22PM +0100, Dominik Vogt wrote: On Sat, Dec 30, 2006 at 12:57:20PM +0100, Dominik Vogt wrote: On Sat, Dec 30, 2006 at 02:13:29AM +, seventh guardian wrote: [snip] Ok, here goes the patch module_interface.c. The first goal of having a functional system is hopefully done. I'm going to create a branch in cvs where we can apply, test and modify the patches. Don't bother to to the changes I posted earlier; I'll do it myself. The branch name will be fvwm-module-struct-branch. To pull it from cvs into a directory modstruct-branch, issue $ cvs co -Pd modstruct-branch -r fvwm-module-struct-branch fvwm I'm done proof-reading and cleaning up the code. See attachment for the complete module-struct patch. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] fvwm-module-struct-branch.patch.gz Description: Binary data signature.asc Description: Digital signature
Re: Changing from module arrays to module structure
On Sat, Dec 30, 2006 at 02:37:15PM +, seventh guardian wrote: On 12/30/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Sat, Dec 30, 2006 at 03:01:22PM +0100, Dominik Vogt wrote: On Sat, Dec 30, 2006 at 12:57:20PM +0100, Dominik Vogt wrote: On Sat, Dec 30, 2006 at 02:13:29AM +, seventh guardian wrote: [snip] Ok, here goes the patch module_interface.c. The first goal of having a functional system is hopefully done. I'm going to create a branch in cvs where we can apply, test and modify the patches. Don't bother to to the changes I posted earlier; I'll do it myself. The branch name will be fvwm-module-struct-branch. To pull it from cvs into a directory modstruct-branch, issue $ cvs co -Pd modstruct-branch -r fvwm-module-struct-branch fvwm I'm done proof-reading and cleaning up the code. Great! Thanks! See attachment for the complete module-struct patch. This doesn't seem to include the slot changes above.. Anyway, I'll work now on the module-struct branch. I don't have the time now, but there is one important bug left: My InitFunction is not executed because it is not defined yet at the moment it is called (StartupStuff() in fvwm.c). I'm starting fvwm like this: fvwm -d :0 -cmd /home/users/bin/FvwmCpp $HOME/.fvwm/.fvwm2rc Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Changing from module arrays to module structure
On Sat, Dec 30, 2006 at 04:12:16PM +0100, Dominik Vogt wrote: On Sat, Dec 30, 2006 at 02:37:15PM +, seventh guardian wrote: On 12/30/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Sat, Dec 30, 2006 at 03:01:22PM +0100, Dominik Vogt wrote: On Sat, Dec 30, 2006 at 12:57:20PM +0100, Dominik Vogt wrote: On Sat, Dec 30, 2006 at 02:13:29AM +, seventh guardian wrote: [snip] Ok, here goes the patch module_interface.c. The first goal of having a functional system is hopefully done. I'm going to create a branch in cvs where we can apply, test and modify the patches. Don't bother to to the changes I posted earlier; I'll do it myself. The branch name will be fvwm-module-struct-branch. To pull it from cvs into a directory modstruct-branch, issue $ cvs co -Pd modstruct-branch -r fvwm-module-struct-branch fvwm I'm done proof-reading and cleaning up the code. Great! Thanks! See attachment for the complete module-struct patch. This doesn't seem to include the slot changes above.. Anyway, I'll work now on the module-struct branch. I don't have the time now, but there is one important bug left: My InitFunction is not executed because it is not defined yet at the moment it is called (StartupStuff() in fvwm.c). I'm starting fvwm like this: fvwm -d :0 -cmd /home/users/bin/FvwmCpp $HOME/.fvwm/.fvwm2rc It was caused by that weird check || writePipes[i+1] == 0 in events.c. I've no idea what it was supposed to do. I have removed that check, but I don't know if that is correct. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: DeadPipe signal handler
On Sat, Dec 30, 2006 at 11:35:21PM +, seventh guardian wrote: The DeadPipe signal handling is actually done by an empty function. Is there any future use for it? Or is it just a relic and may be removed from the code? It may or may not be a relic of older code, but one basic idea of the signal handler rewrite back in '98 or '99 was to have the same signal handling code for fvwm and all modules. So, one reason to keep it is just that some of the modules use it. Update: The DeadPipe handler has been empty at least since the sighandler rewrite (fvwm-2.2 or earlier). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: DeadPipe signal handler
On Sun, Dec 31, 2006 at 12:48:08AM +, seventh guardian wrote: On 12/31/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Sat, Dec 30, 2006 at 11:35:21PM +, seventh guardian wrote: The DeadPipe signal handling is actually done by an empty function. Is there any future use for it? Or is it just a relic and may be removed from the code? It may or may not be a relic of older code, but one basic idea of the signal handler rewrite back in '98 or '99 was to have the same signal handling code for fvwm and all modules. So, one reason to keep it is just that some of the modules use it. Isn't the code for the modules independent from the fvwm code? The DeadPipe I'm talking about is in module_interface.c/h and in fvwm.c.. Yes, the code is independent, but it was created by copy-and-paste. Update: The DeadPipe handler has been empty at least since the sighandler rewrite (fvwm-2.2 or earlier). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: module_interface old vs new functions
On Sun, Dec 31, 2006 at 12:27:09AM +, seventh guardian wrote: On 12/31/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Sat, Dec 30, 2006 at 05:47:51PM +, seventh guardian wrote: Hello. Inside module_interface there are lots of duplicated functions, some old and some new. It would be expected that the new functions were used instead of the old ones, but strangely they are both used in different places. It seems that the migration never finished.. Oh, it's just a pile of functions that appeared without any plan. So are the new functions preferred over the old ones? I need to know in order to clean the dup code lying around module_interface.c.. I don't even know which functions you consider to be new or old. Can you list them? The new functions have new added to the name :) make_vpacket vs. make_new_vpacket SendPacket vs. SendNewPacket BroadcastPacket vs. BroadcastNewPacket Oh, I see. This is an effect of the GSFR (Great Style Flag Rewrite). In the older days, there were only 32 flags that could be communicated to the modules in an int. The GSFR alleviated this restriction. It was necessary to change the SendConfig() and BroadcastConfig() functions to allow sending the enhanced packet format: SendPacket sends a NULL-terminated array of longs. SendNewPacket takes an array of size/value pairs. Maybe it's just that the names are confusing. The new functions are more general, but also slower and take more memory to communicate the arguments. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: DeadPipe signal handler
On Sun, Dec 31, 2006 at 01:13:26AM +, seventh guardian wrote: On 12/31/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Sun, Dec 31, 2006 at 12:48:08AM +, seventh guardian wrote: On 12/31/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Sat, Dec 30, 2006 at 11:35:21PM +, seventh guardian wrote: The DeadPipe signal handling is actually done by an empty function. Is there any future use for it? Or is it just a relic and may be removed from the code? It may or may not be a relic of older code, but one basic idea of the signal handler rewrite back in '98 or '99 was to have the same signal handling code for fvwm and all modules. So, one reason to keep it is just that some of the modules use it. Isn't the code for the modules independent from the fvwm code? The DeadPipe I'm talking about is in module_interface.c/h and in fvwm.c.. Yes, the code is independent, but it was created by copy-and-paste. Should it remain the same on the two spots? IMHO the code would be better to maintain if there were no copy-paste links.. they are not obvious, and tend to be forgotten.. I'd rather say the code should go into some library to remove the code duplication. Update: The DeadPipe handler has been empty at least since the sighandler rewrite (fvwm-2.2 or earlier). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: macros and inline functions in module_interface.h
On Sun, Dec 31, 2006 at 11:15:51AM -0500, Dan Espen wrote: seventh guardian [EMAIL PROTECTED] writes: On 12/31/06, seventh guardian [EMAIL PROTECTED] wrote: On 12/31/06, seventh guardian [EMAIL PROTECTED] wrote: On 12/31/06, Dan Espen [EMAIL PROTECTED] wrote: seventh guardian [EMAIL PROTECTED] writes: Hello If I understand correctly, inline functions weren't allowed some time ago, right? I say this because macros were used instead of small (not inlined) functions. ... Now that the use of inline functions seems more allowed, I wonder i f this macro could be replaced by an inline function. I don't think inline is allowed for most compilers. You'd need a configure test to enable it. I see.. But in those cases, aren't optimizations supposed to be done at the compiler? :) Now seriously, most fvwm user base is using gcc, or some form of C99 compliant compiler, right? In the cases where this is not true, IMHO either the compiler does some form of optimization or it is a bad compiler.. To support my previous words, the current code has variables declared in the middle of functions. This is not allowed by 1990 ANSI, but is allowed by C99. Ops forget this last message.. Ansi C allows the declaration also in the beginning of compound statements.. Over the years we've seen users running Fvwm on many different platforms using all kinds of compilers. I just tried inline using Sun's compiler on Solaris. It didn't work. I'm not sure which standard covers inline but it doesn't look like it's widely supported. Some comments: ** inline is no standard feature of the language. We have a configure test for it. On compilers that don't have inline, it's redefined to an empty string. ** Therefore we can use the inline keyword *only* inside .c files. We *can not* have inline interface functions in header files. Anyway, I'm strongly opposed to code in header files. ** In any case, inlined functions should be used sparsely because they make debugging very hard. It's okay to move part of a function to another inlined function if the latter is called only in one place. Even this should be done only if there is a very good reaseon, e.g. in a loop with potentially lots of iterations. ** There are some macros in the sources that contain real code. Personally I think it's a bad idea. ** There are lots of macros that allow access sto structure members in the header files. These can not be replaced by inline functions. I'm no big fan of that, but it's much better than exposing the details of a structure to the caller. ** C99 is irrelevant to fvwm code. Fvwm has to compile on C89 compilers. This forbids, for example, declarations in the body of a block (my compiler refuses to compile this) or c++-style comments: // bla bla. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: macros and inline functions in module_interface.h
On Mon, Jan 01, 2007 at 04:51:39AM +, seventh guardian wrote: On 12/31/06, Dan Espen [EMAIL PROTECTED] wrote: seventh guardian [EMAIL PROTECTED] writes: situation.. Dan can you test your program with -Os to see if it gets inlined? That didn't do it. I tried -xinline=sub which seemed to work. The assembler is a little odd, it shows the sub calling printf but it also shows the main calling printf instead of calling sub. I'm not sure why. That's right, the same with gcc.. The function appears to be in fact inlined and even optimized for the place it is used, but a more general function remains, maybe to be used as an exportable symbol or something like that (?). I wonder if it is kept in the final executable.. I've searched the gcc man page and found that there's a flag that activates the heuristics-based inlining, and that is -finline-functions. As all -O options happen to be predefined sets of more specific compiler flags, it also happens that -finline-functions is activated by both -Os and -O3, but not by -O(1) or -O2. So just using -O -finline-functions with gcc would suffice for this function to be inlined. Another specially interesting gcc flag is -finline-functions-called-once, which does what the name suggests. I've searched the web for the sun's compiler man page, but to no good.. There should be some kind of flag like this, but compiler flags are definitely non-standard.. I really hoped autoconf would provide some kind of standard mechanism, but for this I've found nothing.. The perfect scenario would be that all the compilers provided some kind of auto-inlining flag, and we wouldn't need to optimize this sort of thing in the code. We really don't need to do a lot of optimization. It's helpful only in very few cases, namely in loops with lots of iterations. Then the use of macros for inline optimization wouldn't be required nor advised. Macros are *not* used for optimization in the fvwm code base (because I'm strongly opposed to macros that actually contain coes). Macros are solely used for information hiding. Before we had the macros, structure members were referenced directly in thousands of places. It was extremely tedious to change member names or structure layout. I wonder if this scenario could be reached somehow.. Even if this conversation eventually leads to nowhere, I'm really learning a lot about compilers! Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Changing from module arrays to module structure
On Sat, Dec 30, 2006 at 02:47:37PM +, seventh guardian wrote: On 12/30/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Sat, Dec 30, 2006 at 03:01:22PM +0100, Dominik Vogt wrote: On Sat, Dec 30, 2006 at 12:57:20PM +0100, Dominik Vogt wrote: On Sat, Dec 30, 2006 at 02:13:29AM +, seventh guardian wrote: [snip] Ok, here goes the patch module_interface.c. The first goal of having a functional system is hopefully done. I'm going to create a branch in cvs where we can apply, test and modify the patches. Don't bother to to the changes I posted earlier; I'll do it myself. The branch name will be fvwm-module-struct-branch. To pull it from cvs into a directory modstruct-branch, issue $ cvs co -Pd modstruct-branch -r fvwm-module-struct-branch fvwm I'm done proof-reading and cleaning up the code. See attachment for the complete module-struct patch. Hum it seems to be a problem with do_execute_module now. If for some reason executing the module doesn't go correctly, the function exits with a broken module still the list. I don't know if we should rely on it being removed at some other place.. Maybe we should do it at the spot. I've already coded this a couple of days ago. Or do you see another leak? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: latest changes to module_interface.[ch]
On Wed, Jan 03, 2007 at 12:02:34PM +0100, Dominik Vogt wrote: With the introduction of the of the module_add_to_fdsets() function the code is now moving into a very unfortunate direction. When fvwm is busy, that function might be called thousands of times per second, with three superfluous function calls. Furthermore, it is completely unnecessary to check the fds *every time* they are added to a set. The size of the fdset struct does not ever change, so the checks can be done once when the fds are created. And finally, the implementation details of the module structure can be hidden with access macros. See my latest patches. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: latest changes to module_interface.[ch]
On Wed, Jan 03, 2007 at 02:18:31PM +, seventh guardian wrote: On 1/3/07, Dominik Vogt [EMAIL PROTECTED] wrote: On Wed, Jan 03, 2007 at 12:02:34PM +0100, Dominik Vogt wrote: With the introduction of the of the module_add_to_fdsets() function the code is now moving into a very unfortunate direction. When fvwm is busy, that function might be called thousands of times per second, with three superfluous function calls. Furthermore, it is completely unnecessary to check the fds *every time* they are added to a set. The size of the fdset struct does not ever change, so the checks can be done once when the fds are created. And finally, the implementation details of the module structure can be hidden with access macros. See my latest patches. Now everything seems cleaner. Great! I guess we can now separate the module handling from the module communication, since we only talk about fds now, not pipes. A module_list.h/c seems logic for handling the module list, and keeping module_interface for the packet sending functions. module_list.h functions: void module_init_list(); - current initModules() void module_kill(); - current KillModule() void module_kill_all(); - current ClosePipes() fmodule *module_execute(); - current executeModuleDesperate() ? fmodule *module_get_next(); int module_count(); - current countModules() void module_write(); - current PositiveWrite() void module_read(); - current HandleModuleInput() I'm not quite happy with this two names. They suggest that they are similar to read() or write(), but they are in fact quite different. (etc) as for module_interface.h/c, keeping every packet sending/receiving function, like Send* and Broadcast*. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Hello, where did fw-frame_g go?
On Wed, Jan 03, 2007 at 09:51:11PM +, seventh guardian wrote: On 1/3/07, seventh guardian [EMAIL PROTECTED] wrote: On 1/3/07, Jesús Guerrero [EMAIL PROTECTED] wrote: Hello, I am new to the list and my first question is this. I am not new to C but I am new to the fvwm sources, so I am a bit loss. In the rounded corners patch someone used fw-frame_g.width and fw-frame_g.height to access I-dont-know-what-info. Can someone tell me what those were and where did they go? From the cvs log you get this: revision 1.249 date: 2006/12/22 09:37:59; author: domivogt; state: Exp; lines: +16 -14 branches: 1.249.2; * New type 'struct window_g' for easier copying. revision 1.248 date: 2006/12/22 09:35:41; author: domivogt; state: Exp; lines: +14 -11 * Moved geometry related members of FvwmWindow into new struct 'g'. Dominik, the description of these changes is missing from the corresponding ChangeLog entry. Can you provide one? Sone. Also, 'g' is a rather vague name, no? It's rarely used alone, so if you come across g.frame that's no worse or better than frame_g. In the sources, g usually stands for geometry. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FvwmIconBox: IconColorset bg color bug
On Wed, Jan 03, 2007 at 11:33:19PM +0300, Serge (gentoosiast) Koksharov wrote: This patch fixes bug in the FvwmIconBox module. Changes of the IconColorset bg color aren't applied immediately. It easily reproducable by typing this in the FvwmConsole: Colorset 42 bg red *FvwmIconBox: IconColorset 42 Module FvwmIconBox Colorset 42 bg green Oops! The background of inactive icon labels stays red, but must be green. Applied. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: focus when between pages
On Thu, Jan 04, 2007 at 08:34:25PM +0100, Viktor Griph wrote: On Thu, 4 Jan 2007, Thomas Adam wrote: On Thu, Jan 04, 2007 at 08:02:06PM +0100, Viktor Griph wrote: Result: The viewport will change to 0 1, and the previously fully visible FvwmCommand will now have 25 pixles to the right of the viewport, and thus be less visible than before the focus command. I don't actually consider this a problem. After all, it is doing exactly what you asked of it. :) I would find it more annoying that decisions such as that were made on the user's behalf, when it could conceivably be not what the user wanted in the first place. Well, there is nothing in the manpage that say that focusing without NoWarp must bring the viewport to a true page. Otherwise it also moves the viewport or window as needed to make the selected window visible. But if the window already is fully visible no such move should be needed. This is undesirable, agreed. I'm for changing the logic that the viewport is only moved: ** If (the ceneter of?) the window is not already visible. OR ** The VP is not at a page position and switching would make the window completely visible. The most annoying thing is ofcource applicartions that trigger this behaviour by gaining focus in other ways. Anything that has UrgencyHint in it, for instance, yes. And other ways too. But again, that's doing what is asked of it too. Do you by any chance know what java AWT transient windows do to gain focus when displayed? I want an ExplainFocus BugOpts option... Phew, difficult. That is because when a window gains focus, you don't know what triggered the event anymore. I'm not playing devil's advocate here -- I just don't see what it is changing the way it currently works accomplishes. Windows shouldn't impose themselves entirely on an exact bounds of the viewport anyway -- if the user so wishes that a window is placed between two pages, then so be it. The fact that viewport could be inbetween pages at a time when focus was given to an application (and hence warped) then sobeit, although one could accomplish switching pages fully with something like: DestroyFunc MyFunc AddToFunc MyFunc + I Current (Visible) GotoPage $[page.nx] $[page.ny] (Crude at best, but you get the idea.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: focus when between pages
On Fri, Jan 05, 2007 at 10:07:39AM +0100, Dominik Vogt wrote: On Thu, Jan 04, 2007 at 08:34:25PM +0100, Viktor Griph wrote: On Thu, 4 Jan 2007, Thomas Adam wrote: On Thu, Jan 04, 2007 at 08:02:06PM +0100, Viktor Griph wrote: Result: The viewport will change to 0 1, and the previously fully visible FvwmCommand will now have 25 pixles to the right of the viewport, and thus be less visible than before the focus command. I don't actually consider this a problem. After all, it is doing exactly what you asked of it. :) I would find it more annoying that decisions such as that were made on the user's behalf, when it could conceivably be not what the user wanted in the first place. Well, there is nothing in the manpage that say that focusing without NoWarp must bring the viewport to a true page. Otherwise it also moves the viewport or window as needed to make the selected window visible. But if the window already is fully visible no such move should be needed. I disabled warping if it's unnecessary. The implementation of the code that moved the window was buggy: ** It confused window width and height in one place. ** It compared the signed window position with the unsigned screen width. The position is implicitly cast to unsigned: x = Screen.Width? with x = -10, Scr.MyDisplayWidth=1024 results in (unsigned int)-10 = 1024? 2^32-10 = 1024? == true :-P Fixed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FvwmConsole under urxvtc
On Sat, Jan 06, 2007 at 11:52:07PM +0300, Serge (gentoosiast) Koksharov wrote: On Sat, Jan 06, 2007 at 12:56:41PM +0100, Dominik Vogt wrote: or removing this SIGCHLD signal handler completely. Hm, I don't know. Why does FvwmConsole get a SIGCHLD anyway? And why does it need to exit when it gets one? If I understood your question correctly, FvwmConsole.c forks child process which then execvp's terminal emulator. When user closes this terminal window, parent process of FvwmConsole receives SIGCHLD, removes socket file which used for communication with FvwmConsoleC part of this module and exits. But as I written in my first letter, I verified and if we don't install SIGCHLD signal handler in FvwmConsole.c the `if' body from my previous message will still do its work and module exits gracefully. So I suppose its safe to remove this handler. Hm, I don't know how to do this properly with the current design of FvwmConsole: When started, FvwmConsole opens a socket, forks and execvp()s the terminal with the option -e /usr/X11R6/bin/xterm or similar and accepts connections to the socket. Later, the client (FvwmConsoleC) connects to the socket and sends user command from there. One incarnation of FvwmConsole consists of four processes: FvwmConsole (communicates with fvwm and the client) terminal FvwmConsoleC server (reads from child and sends to FvwmConsole) FvwmConsole client (reads from termimal and sends to parent) FvwmConsole exits, when ** a connection between FvwmConsole and the FvwmConsoleC server dies, OR ** it gets a SIGCHLD (the terminal dies). Now, if we disable SIGCHLD handling and FvwmConsoleC does not open a connection to FvwmConsole and dies instead, whe FvwmConsole process would never exit. Furthermore, if I disable SIGCHLD handling and use urxvtc and kill it by pressing Ctrl-D, I end up with the FvwmConsoleC server still hanging around while the other three processes have died (looks like a bug). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FvwmConsole under urxvtc
On Sun, Jan 07, 2007 at 11:56:32PM +0300, Serge (gentoosiast) Koksharov wrote: Nice solution with timeout, Dominik, now it works fine with urxvtc. But why you have removed #ifdef HAVE_READLINE around code which uses readline library in FvwmConsole/getline.c? Now FvwmConsole not compiles at all if you pass --without-readline-library option to configure script. Because I did not think before committing. Will be fixed in a minute. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS domivogt: * Reindented and cleaned up FvwmConsole code.
On Sun, Jan 07, 2007 at 09:39:59PM +, seventh guardian wrote: On 1/7/07, FVWM CVS fvwm-workers@fvwm.org wrote: CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt07/01/07 07:34:05 Modified files: . : ChangeLog libs : Makefile.am modules: ChangeLog modules/FvwmConsole: FvwmConsole.c FvwmConsoleC.c getline.c Log message: * Reindented and cleaned up FvwmConsole code. * Added library files fio.c and fio.h to provide wrappers for the io functions that filter EINTR for the caller. Can fvwm_send and fvwm_recv used to provide a socket for terminals to connect, ala todo-3.0 entry 5? It seems interesting. Ah, not really. All I did is put a wrapper that catches EINTR and restarts the call if necessary. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Apparently duplicated function in module_interface.c
Original-Nachricht
Datum: Mon, 8 Jan 2007 02:24:12 +
Von: seventh guardian [EMAIL PROTECTED]
An: FVWM Workers fvwm-workers@fvwm.org
Betreff: Apparently duplicated function in module_interface.c
I've came across two very similar functions in module_interface.c, one
of which was introduced recently during the module struct change. They
are:
static void set_message_mask(msg_masks_t *mask, unsigned long msg)
{
if (msg M_EXTENDED_MSG)
{
mask-m2 = (msg ~M_EXTENDED_MSG);
}
else
{
mask-m1 = msg;
}
return;
}
and
static inline void msg_mask_set(
msg_masks_t *msg_mask, unsigned long m1, unsigned long m2)
{
msg_mask-m1 = m1;
msg_mask-m2 = m2;
return;
}
Is there a place for the two? Or should there be just one?
The latter is really just used for initialization of the module
struct to hide the internal layout of the module mask. Maybe
we should remove its arguments and call it init_msg_mask().
Ciao
Dominik ^_^ ^_^
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Commit in FScreen.c
I'd prefer to leave the blank lines before return statements in place because they are there on purpose. @@ -1245,7 +1247,7 @@ } } } - + } return rc; } Whenever I touch a function that does not have the newline, I add one. Code blocks I write always have this structure: 1. Declarations (no initializatios to allow gcc to warn about uninitialized variables) 2. BLANK LINE 3. Body of the block (usually without *any* blank lines) 4. BLANK LINE 5. Return statement Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS griph: * don't warp on popdown if triggered by motion
CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: griph 07/01/09 16:18:10 Modified files: fvwm : menus.c . : ChangeLog Log message: * don't warp on popdown if triggered by motion Can you describe the problem please? (Note: The menu code is my baby, so I'll always ask about changes and bugfixes). -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Re: moving headers to fvwm_INCLUDE in Makefile.am
On Wed, Jan 10, 2007 at 04:28:14PM +, seventh guardian wrote: Hello. In the process of adding the module_list.c file to Makefile.am I've reorganized the c files by size (things change..). I've noticed that the headers are put in fvwm_SOURCES, while now they should go on fvwm_INCLUDES. Is there any issue with older supported versions of automake preventing this? I don't know, we never tried this. Does automake-1.4 (which is the required version) support this? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS domivogt foo: Imported sources
On Thu, Jan 11, 2007 at 08:44:24AM -0600, fvwm-workers wrote: CVSROOT: /home/cvs/fvwm Module name: foo Changes by: domivogt07/01/11 08:44:24 Ingonre this commit, I had the wrog cvsroot set. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Bug in FvwmIdent's Geometry string.
There appears to be a discrepency between how FvwmIdent calculates the geometry of the specified window, in relation to, say, how xwininfo calculates it. In both cases, xwininfo's report of the geometry of a window is correct. You just have to use a test case of: xterm -g some_geometry_string for the numbers from xwininfo and FvwmIdent to see what's happening. I don't have time to look into why at the moment, I wish I did. Fixed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS domivogt: * Use int instead of unsinged int in many places.
On Sat, Jan 13, 2007 at 09:11:51PM +0100, Viktor Griph wrote: On Sat, 13 Jan 2007, Dominik Vogt wrote: On Sat, Jan 13, 2007 at 05:41:43PM +0100, Viktor Griph wrote: On Sat, 13 Jan 2007, FVWM CVS wrote: * Use int instead of unsinged int in many places. but gcc4.1 complains on passing wrongly signed types to function taking pointers as arguments: Graphics.c:849: warning: pointer targets in passing argument 5 of XQueryBestTile differ in signedness Does it also bug out with -Werror? In any case, it's okay to cast ints to unsigned ints before passing them to X functions, but I don't want any more unsingned arithmetics in the fvwm code. Well, as I don't have a gcc version that throws errors, I can't fix the warnings. I've found that it's possible to add -Wno-pointer-sign to surpress the specific warning. I still don't like it. I'd rather have the arithmetic fixed. But seeing the trouble it introduced I undertand it isn't easy to do at the current stage. Maybe we can do it after 2.6 and take it slowly to not introduce any bugs. Well, using options to suppress warnings selected by -Wall that cause an error with -Werror is no option. But since I don't get the warnings I can't fix them. So feel free to either post the compiler output or fix the warnings yourself (by casting the function arguments to the appropriate types). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Bug in FvwmIdent's Geometry string.
On Sat, Jan 13, 2007 at 09:12:00PM +, Thomas Adam wrote: On Sat, Jan 13, 2007 at 04:34:17PM +0100, Dominik Vogt wrote: There appears to be a discrepency between how FvwmIdent calculates the geometry of the specified window, in relation to, say, how xwininfo calculates it. In both cases, xwininfo's report of the geometry of a window is correct. You just have to use a test case of: xterm -g some_geometry_string for the numbers from xwininfo and FvwmIdent to see what's happening. I don't have time to look into why at the moment, I wish I did. Fixed. Are you sure? There is a difference in the numbers between the FvwmIdent module shipped with 2.5.19 and the updated on in CVS, but they're still reporting erroneous numbers in the geometry string that I can tell. Um, yes I'm quite sure (apart from the new bug I introduced with the fix. Here's an example: xterm -g 80x24+0+0 Places xterm in the top-left corner of the current page. If you run FvwmIdent (from 2.5.19, say) on that window, you'll get a reported geometry of: 484x316+0+0 That's the geometry in pixels. Of course, it _should_ be 80x24+0+0. If you were to then issue a command of: xterm -g 484x316+0+0 That is going to obviously give you one huge XTerm. :) You're looking at the wrong lines of the output. The numbers you are looking for are in the Geometry:-line near the bottom of the window. You get much the same result from the FvwmIdent module in CVS as over an hour ago. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS domivogt: * Use int instead of unsinged int in many places.
On Sat, Jan 13, 2007 at 09:11:51PM +0100, Viktor Griph wrote: I'd rather have the arithmetic fixed. The problem is that it's almost impossible to do. Simple calculations like x = y / z Can have very surprising results if y is signed and z is unsigned. One really shouldn't ever use unsigned arithmetics in C. But seeing the trouble it introduced I undertand it isn't easy to do at the current stage. Maybe we can do it after 2.6 and take it slowly to not introduce any bugs. Overall, I think the number of bugs is cut down significantly by using signed arithmetics, not vice versa. Of course there is a chance that new bugs are introduced in a few places. I'm thinking about using typedefs for the few operations that really need unsigned (mostly flags, masks and interface types). Another option is to replace the X-calls that use unsigned int with wrappers that take signed and do the casting there. I've not decided yet. Anyway, I didn't do that for the kicks but because I needed to make the rectangle structure using signed only in order to code some enhancements to the placement code. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Bug in FvwmIdent's Geometry string.
On Sun, Jan 14, 2007 at 12:27:35AM +, Thomas Adam wrote: On Sun, Jan 14, 2007 at 12:50:57AM +0100, Dominik Vogt wrote: On Sat, Jan 13, 2007 at 09:12:00PM +, Thomas Adam wrote: On Sat, Jan 13, 2007 at 04:34:17PM +0100, Dominik Vogt wrote: There appears to be a discrepency between how FvwmIdent calculates the geometry of the specified window, in relation to, say, how xwininfo calculates it. In both cases, xwininfo's report of the geometry of a window is correct. You just have to use a test case of: xterm -g some_geometry_string for the numbers from xwininfo and FvwmIdent to see what's happening. I don't have time to look into why at the moment, I wish I did. Fixed. Are you sure? There is a difference in the numbers between the FvwmIdent module shipped with 2.5.19 and the updated on in CVS, but they're still reporting erroneous numbers in the geometry string that I can tell. Um, yes I'm quite sure (apart from the new bug I introduced with the fix. Here's an example: xterm -g 80x24+0+0 Places xterm in the top-left corner of the current page. If you run FvwmIdent (from 2.5.19, say) on that window, you'll get a reported geometry of: 484x316+0+0 That's the geometry in pixels. I'm obviously missing something fundamental here. :) That's what I thought -- but this wouldn't really help a client such as XTerm would it? (which largely depends on resize increments to determine geometry unless one has ResizeHintOverride set, for instance). To my eyes, when I use FvwmIdent to ascertain information about a window, such as its geometry, I'd like to think that when I do: my_app -geometry 100x34+0+0 That it opens up in that location. But it doesn't -- not, if you say, compare it to the output from xwininfo, which, when using its geometry string, does open up the application in the position I would have expected it to. Ideally, shouldn't both xwininfo and FvwmIdent's geometry reporting match? I don't understand what your problem is. When I start xterm like this: $ xterm -g 80x24+0+0 I get an 80x24 xterm at +0+0. FvwmIdent says: X: 0 (frame x position) Y: 0 (frame y position) Width: 587 (frame width) Height: 342 (frame height) Geometry: 80x24+0+0 So FvwmIdent gives me the frame's size and position and the width/height/position of the client as if the wm had not decorated it (80x24+0+0). Without any options, xwininfo reports the client window's absolute position (+4+22) and the size in pixels (579x316). It can also report the frame's geometry if called with the -frame option (587x342, +0+0). So, what *is* the problem with that? Of course, it _should_ be 80x24+0+0. If you were to then issue a command of: xterm -g 484x316+0+0 That is going to obviously give you one huge XTerm. :) You're looking at the wrong lines of the output. The numbers you are looking for are in the Geometry:-line near the bottom of the window. Aye -- and using those numbers still produce an erroneous size. Huh? For me it says 80x24+0+0, and that's exactly the string I passed to xterm in the first place. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS griph: * silence compiler warnings
On Sun, Jan 14, 2007 at 03:52:03AM -0600, fvwm-workers wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: griph 07/01/14 03:52:03 Modified files: . : ChangeLog bin: ChangeLog fvwm-root.c fvwm : add_window.c builtins.c conditional.c events.c externs.h focus.c frame.c fvwm.c fvwm.h geometry.c icons.c menugeometry.c menus.c move_resize.c placement.c session.c style.c libs : FScreen.c FScreen.h Graphics.c PictureImageLoader.c PictureUtils.c PictureUtils.h modules: ChangeLog modules/FvwmBanner: FvwmBanner.c modules/FvwmIconBox: FvwmIconBox.h icons.c modules/FvwmIdent: FvwmIdent.c modules/FvwmRearrange: FvwmRearrange.c modules/FvwmScript: types.h modules/FvwmTaskBar: ButtonArray.c ButtonArray.h modules/FvwmWharf: FvwmWharf.c Wharf.h Log message: * silence compiler warnings Cool, thanks! Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS domivogt: * Icon loop fix.
On Sun, Jan 14, 2007 at 06:26:47PM +0100, Viktor Griph wrote: On Sun, 14 Jan 2007, FVWM CVS wrote: Log message: * Icon loop fix. What's the difference. ofw isn't used outside the loop anyway. Ah, you're right. I didn't understand your patch correctly. The effect is the same, but the new version is a bit easier to understand (I hope). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Bug in FvwmIdent's Geometry string.
On Sun, Jan 14, 2007 at 03:54:23PM +, Thomas Adam wrote: On Sun, Jan 14, 2007 at 04:33:56PM +0100, Dominik Vogt wrote: With that, FvwmIdent prints the relevant information to the console. Can you post the output and the (relevant) output of xwininfo please? Sure. I should just point out that I have tried this with FVWM having no config file to load up at all (just in case there was something in my own config file which might cause it). Here's the output from the debug info from FvwmIdent and (selected) xwininfo output: FvwmIdent output: frame 492x340, bw 8, title 16(dir 0), client 484x316 client 484x316, base 0x0, inc 1x1 ^^^ So fvwm thinks the character size is 1x1 (see below). -- units 484x316 xwininfo output: xwininfo: Window id: 0x3cf xterm Absolute upper-left X: 4 Absolute upper-left Y: 20 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 484 Height: 316 Corners: +4+20 -792+20 -792-688 +4-688 -geometry 80x24+0+0 Please note that I don't have ResizeHintOverride set anywhere, although this *does* indeed throw the numbers out, since it reports itself in pixels when I have turned it on. Having spoken to a few people on IRC, they can confirm that FvwmIdent works fine for them, until they set ResizeHintOverride, at which point, the geometry string as reported by FvwmIdent is in pixels. (I consider this to be a bug in itself, but that's a different issue as to why this still isn't working here for me). The reason is that fvwm thinks the character size is 1x1. This happens explicitly with the ResizeHintOverride style (I've committed a patch for that). There are three possible reasons: 1) The user set ResizeHintOverride == Try to set style * !ResizeHintOverride explicitly Note: This style does *not* work if the window is already mapped! 2) The application did not set a character size (or any size hints at all). As xwininfo reports the proper size, this is not the case. 3) The application set an invalid character size (= 0) == look for a message The application window ... has broken size hints (..._inc) on the console. Thanks for your continual assistance on this, Dominik. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: deiconify may loop forever
On Sun, Jan 14, 2007 at 07:01:06PM +0100, Viktor Griph wrote:
On Sun, 14 Jan 2007, Dominik Vogt wrote:
On Sun, Jan 14, 2007 at 04:42:23PM +0100, Viktor Griph wrote:
This loop is on line 2288 in icons.c:
for (ofw = NULL; fw != ofw IS_ICONIFIED_BY_PARENT(fw); )
{
t = get_transientfor_fvwmwindow(fw);
if (t != NULL)
{
ofw = fw;
fw = t;
}
}
I'm not sure exactly what it is supposed to do, but if a non-transient
window is iconified by IconifyWindowGroups it will loop forever.
This loop looks for the top window of the transient tree.
Actually, your fix broke that logic because it climbs only one
level up the tree. The right fix is to break the loop if
get_transientfor_fvwmwindow returns NULL. The comparison
(ofw == fw) is there to catch windows that are their own
transients.
My fix did still climb the tree. What it did was to always assign ofw=fw,
and as long as t wasn't null assign fw = t. Which mean that only if t was
the same as fw or t was NULL would ofw == fw, and the loop would end.
It changed the value of ofw after the loop, but it wasn't used anyway.
Ack.
However I'm still not convinced that this is the right fix. That code was
written without the IconifyWindowGroups option in mind, shouldn't it
really try to climb to the head of the windowgroup as well? Maybe it is
ennoug to use the mark_transient_subtree result. That function doesn't
care about if it's called with the head of a tree or not.
According to the man page, the window group should be iconified
when the group leader is iconified, but *not* if another window of
the group is. So it would be wrong to deiconify the whole group
if just a single window is deiconified.
I don't know if this feature is *usefull* at all, but I don't know
any application that makes use of the window group feature.
The only effect the loop has is that deiconifying raises, not the window
selected for deiconify, but the root of the transient tree. Isn't it
better to raise the window selected, and let the
styles StackTransientParent and RaisTransient control which windows
actually are raised.
I don't know.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: CVS domivogt: * Use resize_inc hint even with ResizeHintOverride style.
On Sun, Jan 14, 2007 at 06:29:01PM +, Tavis Ormandy wrote: On Sun, Jan 14, 2007 at 07:19:07PM +0100, Viktor Griph wrote: On Sun, 14 Jan 2007, FVWM CVS wrote: Log message: * Use resize_inc hint even with ResizeHintOverride style. This faq question will have to be updated: http://www.fvwm.org/documentation/faq/#5.16 So this bug has been exploited for years? Ouch. I'll change the man page and revive overriding the resize_inc. Thanks for the hint. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Question regarding ModuleSynchronous man page entry
On Sun, Jan 14, 2007 at 08:06:09PM +, seventh guardian wrote: Hello. Here's the dubious part of the man page entry: This command is intended for use with the (currently hypothetical) module that should be in place before other modules are started. What is this hypothetical module? The former FvwmTheme module (that is now part of the core). I still start it as a module with ModuleSynchronous. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS griph fvwm-web: * update for 2.5.20 release
[snip] Log message: * update for 2.5.20 release When you're done, don't forget to send mail to tibbs+++fvwm###org (+++ = @, ### = .) not just fvwm-owner to get the tarballs up fast. Ciao Dominik ^_^ ^_^ -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Re: StackTransientParent race condition
On Thu, Jan 11, 2007 at 03:59:58PM +0100, Viktor Griph wrote: If an application itself tries to implement some kind of similar feature, and does it in a simple (and bad) way it may result in a race condition between fvwm and that app. I believe this is what Apple Shake is doing based on some guesses, the face that IgnoreRestack solved it, and reading the code. (Plus I've been able to make my own ill-behaved app to prove it can happen.) The following are the requirements for the race coondition to happen: * the application is on the topmost used layer * Style AllowRestack, StackTransientParent applies to the transient window subject to the race condition. How it (doesn't) work: The app want's to keep it's transients above itself, so whenever it notice a stacking change on it's main window it will raise the transients. (A real app would probably first make sure that the stacking change really is an increas in stack level, but for the sake of this bug that doesn't matter.) Fvwm will then see the raise of the transient and issue a raise of the main window as a consequence. If this raise isn't to the topmost layer events will be sent to the application about stacking change, even if no change really occured. The application will then again raise it's transients. The solution as I see it would be to not make any changes if there would be none. That is to make sure that no restacking takes place if the transient already is at top, and all other transients are bellow it, directly followed by the main window. I'm not quite sure how the restacking code in fvwm works, and I don't have time right now to dwell into it further. Hm, I tried to proof read the patch you made, but it's too big to understand by looking at it for five minutes. Can you explain how it is meant to work and point out the pieces of code you are unsure about, please? It's not that I don't trust your code quality, but the stacking code is very difficult to understand and very easy to break. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS griph: * add interactive scrolling
On Fri, Jan 19, 2007 at 10:47:07AM +0100, Viktor Griph wrote: On Fri, 19 Jan 2007, FVWM CVS wrote: * add interactive scrolling This is based on the code for interactive move, but the window is replaced by the viewport. Try it out with my personal favorite (have been using it all week): Mouse 1 A CM Scroll reverse $ make CFLAGS=-g -O2 -Wall -Wpointer-arith -fno-strict-aliasing -Werror ... virtual.c: In function `__drag_viewport': virtual.c:190: error: `XK_Escape' undeclared (first use in this function) You should always compile with the above CFLAGS to catch these errors (however, if make needs to run the autotools, you have to call them either manually or run make without any options once). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: SVG image loader
On Wed, Jan 24, 2007 at 12:41:34AM +0100, Simon Griph wrote: On Sun, Jan 21, 2007 at 09:55:36AM +0100, Simon Griph wrote: A cvs diff is attatched. Could you please make a single diff file, not one per file. In the current state the patches are extremely tedious to read and to apply. If you have checked out fvwm from CVS it is very easy to do: $ cd fvwm-patched $ cvs diff -u patchfile Sorry about the inconvenience. I did in fact do cvs diff -u, but I had trouble with the new file libs/Fsvg.h. So I hand edited the diff to include this file. I guess I just should have attached it separately. Ah, I just noticed it was all my fault. I looked at the patch with mc without unpacking it first, and mc showed me individual files. But it's actually just one diff file. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: SVG image loader
On Wed, Jan 24, 2007 at 12:47:15AM +0100, Simon Griph wrote: On Mon, 22 Jan 2007, Viktor Griph wrote: * sscanf may or may not include %n in the count returned depending on compiler. The man page says Probably it is wise not to make any assumptions on the effect of %n conversions on the return value. so all comparitions with the return value of sscanf should be changed from equal to greater or equal. True. But will that work with the sscanf format string %dx%n%d%n ? You can't do that. To work reliably, you can have only a single %n at the end of the format string. %n before anoter Format variable may not be portable. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS griph: * redraw sidepics only if parts of them are exposed
On Fri, Jan 26, 2007 at 05:38:00PM -0600, fvwm-workers wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: griph 07/01/26 17:38:00 Modified files: . : ChangeLog fvwm : menus.c Log message: * redraw sidepics only if parts of them are exposed There was a small bug in the patch. To test wether the expose area and the sidepic no not overlap, this is correct: (x = offset + width) not (x offset + width) ^^^ (Fixed). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: SVG image loader
On Wed, Jan 24, 2007 at 12:47:15AM +0100, Simon Griph wrote: On Mon, 22 Jan 2007, Viktor Griph wrote: * Should rsvg_init() and rsvg_term() be called each time an SVG image is loaded? It soulds as function that should be called only once in a program's life time. It is probably enough to call them once, but I'm not sure where else to put them. With my latest patches, you can just put the call in flib_init_graphics() (libs/fvwmlib.c). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS domivogt: * Use flib_init_graphics().
On Sat, Jan 27, 2007 at 01:11:32PM +0100, Viktor Griph wrote: On Sat, 27 Jan 2007, FVWM CVS wrote: Log message: * Use flib_init_graphics(). You only use it in the modules subdirectory. Did you miss to commit in bin and fvwm? It just wraps the typical module init stuff. It seems the core and fvwm-root do it in a different way. THey have to call the svg init function on their own. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FvwmIconMan cleanup patch
On Sun, Jan 28, 2007 at 02:29:22PM +0300, Serge (gentoosiast) Koksharov wrote:
Hello, Renato,
On Sat, Jan 27, 2007 at 10:23:28PM +, seventh guardian wrote:
On 1/27/07, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote:
Hello,
Please see attached patch's ChangeLog.
Some of the #endif comments you added are not a good thing:
*These comments are only useful if there are other compiler directives
in the middle which may confuse the reader, or in the termination of
include guards. Other than that, they serve no purpose.
Please see
http://www.gnu.org/prep/standards/standards.html.gz#index-g_t_0040code_007b_0023endif_007d_002c-commenting-65
Either I misinterpreted this document
or we don't rely on GNU coding standards?
My personal opinion, that comments at the end of the `#endif'
directives help understand to which `if' this `endif' belongs without
pressing `%' key in Vim. Some if/else/endif constructs are several
screens long.
I know it isn't applicable here becuase your patch only changes
existing ifdefs, but:
My opinion is that #ifdefs must not be used at all (except to
configure the system). Reason: They are a maintenance nightmare.
Example:
This code:
fvwmfoo.c:
#ifdef HAVE_LIBFOO
...
foo_something();
...
#endif
Can be writteni:
fvwmfoo.h:
#ifdef HAVE_LIBFOO
# define USE_LIBFOO 1
#else
# define USE_LIBFOO 0
/* dummies for libfoo interface */
# define foo_something() do { } while (0)
#endif
fvwmfoo.c:
if (USE_LIBFOO)
{
...
foo_something();
...
}
Whis way the code is compiled every time (but optimized away if
USEFOO is 0). Much easier to maintain, and the ifdefs are only in
the header file.
An in this special case, since the debug code in FvwmIconMan has
not been used since at least 1998, we might as well remove it.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: SVG patch revision one
On Sun, Jan 28, 2007 at 01:28:21AM +0100, Simon Griph wrote: * fixed sscanf portability issues * simplified Separate rendering options from path * moved Frsvg_init() calls to fvwm/fvwm.c, bin/fvwm-root.c, lib/fvwmlib.c * added Fsvg.h to libfvwm_a_SOURCES * added librsvg2-dev to Build-Depends (debain/control.in) * removed unnecessary tests I have applied your patch with some small changes (most notably: rename SvgSupport with USE_SVG and define it in Fsvg.h). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: more issues with shaded resize
Shaded resize works well with interactive operation. However there are multiple issues with resizing a shaded window by arguments. * The code assumes that any shaded window is shaded in N or S direction. (it allows for change of the width of the window, but not the height.) Resizing a E or W shaded window gives a very bad result. * The code bases relative resizing on frame.g and not the unshaded (or normal) gemoetry (Which should it be?). Do you have a patch? If so, I can take a look now. Otherwise I can take care of it on friday. Ciao Dominik ^_^ ^_^ -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
Re: CVS griph: * initial fix for resizing shaded windows by parameters (Se comments
On Wed, Jan 31, 2007 at 04:49:59PM -0600, fvwm-workers wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: griph 07/01/31 16:49:59 Modified files: . : ChangeLog fvwm : move_resize.c Log message: * initial fix for resizing shaded windows by parameters (Se comments starting with ??? in move_resize.c) So far, the patch is fine. Using g.normal would be wrong as we want to use g.max if the window is maximized and shaded at the same time. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS griph: * initial fix for resizing shaded windows by parameters (Se comments
On Thu, Feb 01, 2007 at 12:09:31AM +0100, Dominik Vogt wrote: On Wed, Jan 31, 2007 at 04:49:59PM -0600, fvwm-workers wrote: CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 07/01/31 16:49:59 Modified files: . : ChangeLog fvwm : move_resize.c Log message: * initial fix for resizing shaded windows by parameters (Se comments starting with ??? in move_resize.c) So far, the patch is fine. Using g.normal would be wrong as we want to use g.max if the window is maximized and shaded at the same time. Okay, I made some more fixes in the old and the new code. What you want to do is: * Get the current geometry of the window if it were unshaded. (get_unshaded_geometry()). * Switch off maximized state (as we always do when resizing a maximized window). (gravity_resize()). * Resize this rectangle honouring gravity, i.e. if gravity is SE, move the top left corner of the window to match its new size. The resulting rectangle is the window's new f.normal. (fw-g.normal = new_g). * Calculate the new shaded geometry from the normal geometry, the title direction and the window's gravity. (get_shaded_geometry()). * Setup the frame accordingly. (frame_setup_window()). The code for unshaded windows always kept them at the same x/y position (by using g.frame.x/y in frame_setup_window). This was wrong - it should have used the new_g.x/y position (fixed). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CursorStyle bugfix
On Sun, Feb 04, 2007 at 10:23:23PM +0100, Simon Griph wrote: A bugfix to make the CursorStyle command behave as described in the man page. The POSITION context haven't worked at all for several years. I have committed a different patch based on your changes. Although your patch looks safe, I prefer not to removed grabbing from the __move_loop() function. The new code passes the desired cursor to the functions (and just grabs the cursor twice). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: SetEnv: disallowing fullstop in envvar name.
On Tue, Feb 27, 2007 at 01:31:22AM +, Thomas Adam wrote:
Currently (thanks to someone asking a question on IRC) I realised that
FVWM was allowing environment variable names with fullstops ('.') in
them. I don't believe FVWM should allow this.
I see no problem. Unix allows almost any character, and just
because shells don't should we really limit the character set?
Contrarily, isn't it very handy to have a character that is not
used by any other application? (SetEnv fvwm.foobar ...).
Currently it's not a problem if one is onlt ever intending for a
variable to be used via SetEnv solely within FVWM; FVWM of course just
exports and reads from its own environment space without ever parsing
via the shell.
Of course, when one tries to do:
SetEnv FOO.VAR hello
... and then:
echo $FOO.VAR
Via a subsequently spawned xterm or whatever, then it will obviously
fail. The patch attached with this email, patches flib_putenv() in
libs/envvar.c using strstr() to see if the env var name contains a '.'
or not (I have no idea just how portable strstr() is but it's a tad
faster than having to iterate over a character array).
I haven't bothered updating the fvwm.1.in in lieu of this, given that
the description doesn't mention this in the first place. By all means
do so if it's felt necessary.
-- Thomas Adam
--
Wanting to feel; to know what is real. Living is a lie. -- Purpoise
Song, by The Monkees.
Index: ./libs/envvar.c
===
RCS file: /home/cvs/fvwm/fvwm/libs/envvar.c,v
retrieving revision 1.18
diff -u -r1.18 envvar.c
--- ./libs/envvar.c 26 Nov 2005 21:55:12 - 1.18
+++ ./libs/envvar.c 27 Feb 2007 01:20:44 -
@@ -453,6 +453,13 @@
void flib_putenv(char *var, char *env)
{
char *s;
+ char *dotchar = .;
+
+ if( strstr(var, dotchar) )
+ {
+fprintf(stderr,Cmd_SetEnv Illegal character '.' in
variable name.\n);
+return;
+ }
s = safestrdup(var);
var = s;
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: XML doc
On Sun, Mar 11, 2007 at 09:57:58AM +1100, Scott Smedley wrote: Hi Dominik, If you do not want to produce this documentation please use: ./configure --disable-htmldoc As the process take four times longer than building the executables, may I suggest that a) the html pages are not built unless you specifically ask for them, Ok. I will change this soon. b) the new man page stuff is disabled by default. Sorry, I don't understand what you mean. There are still the normal man pages which are fine. The current state of the XML documentation prevents me from writing any documentation. As almost everything I do has to be documented, it prevents me to do almost anything. For developers, the XML source files supersede the old fvwm man page. Please make any documentation changes here NOT in the fvwm/fvwm.1.in file. Well, I'd be willing to try that, but I am *not* going to search through *400* files for the contents I want to edit (and all cross references). There *must* be a way to have just one file per man page. I'd like to be able to accomodate, but by having everything in one file we'd lose the ability to have separate HTML pages for each command. IMO, that's probably the most useful feature. See: http://members.optusnet.com.au/~scott.fvwm/allCommands.html It's natural to split up the documentation into smaller files. As an analogy, consider the FVWM source code - we don't have a single fvwm.c source file to make searching easier, but lots of separate source files with grouped functionality. We're not talking about source but documentation. In my eyes having split pages is the one feature in html docs that makes it completely unusable: you can not browse or search it in a sensible way. And it's hell to read. A single page with intra- document links is much more usable. In any case, we're talking about Unix, not windoze. It can't be *this* hard to make a script that extracts the individual files with the command documentation from one big master source file to generate the html docs. I agree though, splitting up the documentation into multiple files has made searching a little harder. But, as Dan indicates, a few simple 'grep' commands should suffice. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [patch] Code-Cleanup: () - (void), kr
On Sun, May 27, 2007 at 07:28:36PM +0200, Stefan Huehner wrote: attached patch converts some function declarations from () to (void) and changes one kr-style function declaration to ansi C. Thanks, I've committed the patches. Please include entries for the ChangeLog file in future patches (I've written one myself for this one). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: CVS griph: * do raise hacks even when the internal stack is intact, unless on a
On Sun, Jun 03, 2007 at 08:28:06AM -0500, fvwm-workers wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: griph 07/06/03 08:28:06 Modified files: . : ChangeLog fvwm : events.c focus.c icons.c stack.c stack.h Log message: * do raise hacks even when the internal stack is intact, unless on a client request Can you elaborate on why this is necessary, please? I'd just like to understand the code. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: [bugfix] Condition separation
On Sat, Jul 07, 2007 at 09:05:41PM +0200, Simon Griph wrote: Currently; All (State 1,Sticky) Lower will lower all state 1 windows, regardless of stickiness. A patch fixing this problem is attached. Good patch. Committed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: [patches] CursorStyle: ARGB mouse cursors
On Fri, Jun 22, 2007 at 12:52:58PM +0200, Simon Griph wrote: I've split up my previous patch into six smaller ones, making it more logical to follow. The patches applies one after another. (cat fvwm-xcursor_p?.diff | patch -p0) or (tar -xzOf fvwm-xcursor-patches.tar.gz | patch -p0) Is that the ARGB patch that was posted to the list about a year ago? (I really can't remember). I can remember though that I did not apply said patch because it contained some magic information to detect ARGB visuals. I tried to confirm that magic with some third party but never found out anything. It it's not that patch, can someone find the patch I'm talking about in the mailing list archives? * fvwm-xcursor_p1.diff Without this patch, every call to PImageCreatePixmapFromArgbData is made from almost identical blocks of about 20 lines of code. Two or three pixmaps are created before the function call, and then destroyed afterwards if they weren't needed. This patch removes that duplicate code. Pixmaps aren't created until there is an image to put, making the XFreePixmap calls unnecessary. The actual XCreatePixmap call is moved to the new local function PImageCreatePixmapFromFImage, which is called up to three times from within PImageCreatePixmapFromArgbData. * fvwm-xcursor_p2.diff This patch revises the logic of PImageCreatePixmapFromArgbData. Most notably; the mask pixmap is no longer created for fully opaque (all alpha == 0xff) or translucent (0 any alpha 0xff) images. * fvwm-xcursor_p3.diff This patch removes duplicate code; modifing PImageLoadXpm to make use of PImageCreatePixmapFromArgbData. * fvwm-xcursor_p4.diff This patch moves the PImageCreatePixmapFromArgbData call from the image loaders into PImageLoadPixmapFromFile. The entire bitmap loader is moved there as well and PImageLoadBitmap is removed. Most of the old PImageLoadPixmapFromFile is made into the new local function PImageLoadArgbDataFromFile. * fvwm-xcursor_p5.diff With this patch, the xpm specific PImageLoadCursorPixmapFromFile is replaced by the general PImageLoadCursorFromFile, which uses PImageLoadArgbDataFromFile and PImageCreatePixmapFromArgbData. New hot-spot arguments are added to the CursorStyle command, allowing PNG and SVG images to be loaded as mouse cursors. * fvwm-xcursor_p6.diff This is the actual Xcursor patch, adding libXcursor calls to PImageLoadCursorFromFile, making it possible to load ARGB and animated mouse cursors. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: function oddity
On Thu, Jul 12, 2007 at 03:41:38PM +1000, Scott Smedley wrote: I need confirmation I'm not crazy. This works ok (substitute rxvt for xterm if appropriate): AddToFunc fn I Exec exec rxvt $* fn -e sleep 4 this is ok too: AddToFunc fn3 I Test (x rxvt) Exec exec rxvt $* fn3 -e sleep 4 but this isn't: AddToFunc fn2 Test (x rxvt) + I Exec exec rxvt $* fn2 -e sleep 4 The Test command expands the $* when it is executed. Try Test (x rxvt) + I Exec exec rxvt $$* (it starts up an interactive shell, instead of sleeping exiting) Am I missing something? or am I going to have to use the source? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Documentation for new command?
I've just committed the new command EchoFuncDefinition which prints a function definition to the console (useful for debugging functions). But I've no idea what I have to do to write the documentation (I daid that I would be unable to write documentation if it's scattered over several files, didn't I?). Here it is in man page format: EchoFuncDefinition function The .B EchoFuncDefinition is similar to the .B Echo command but prints the definition fo the given .I function to .IR stderr . It is useful to find out how fvwm handles quoting and for debugging functions. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: function oddity
On Thu, Jul 12, 2007 at 10:16:32AM +0200, Viktor Griph wrote: On Thu, 12 Jul 2007, Dominik Vogt wrote: On Thu, Jul 12, 2007 at 03:41:38PM +1000, Scott Smedley wrote: I need confirmation I'm not crazy. This works ok (substitute rxvt for xterm if appropriate): AddToFunc fn I Exec exec rxvt $* fn -e sleep 4 this is ok too: AddToFunc fn3 I Test (x rxvt) Exec exec rxvt $* fn3 -e sleep 4 but this isn't: AddToFunc fn2 Test (x rxvt) + I Exec exec rxvt $* fn2 -e sleep 4 The Test command expands the $* when it is executed. Try Test (x rxvt) + I Exec exec rxvt $$* It is also possible to use - Test (x xterm) + I Exec exec xterm $* ^^^ By the way, with my latest commit you can say EchoFuncDefinition fn2 -- [FVWM][EchoFuncDefinition]: definition of function 'fn2': [FVWM][EchoFuncDefinition]: i exec exec rxvt You can immediately see what has happened. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: [patches] CursorStyle: ARGB mouse cursors
On Fri, Jun 22, 2007 at 12:52:58PM +0200, Simon Griph wrote: * fvwm-xcursor_p4.diff This patch moves the PImageCreatePixmapFromArgbData call from the image loaders into PImageLoadPixmapFromFile. The entire bitmap loader is moved there as well and PImageLoadBitmap is removed. Why? What's wrong with bmp images? Most of the old PImageLoadPixmapFromFile is made into the new local function PImageLoadArgbDataFromFile. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: [patches] CursorStyle: ARGB mouse cursors
On Fri, Jun 22, 2007 at 12:52:58PM +0200, Simon Griph wrote: * fvwm-xcursor_p6.diff This is the actual Xcursor patch, adding libXcursor calls to PImageLoadCursorFromFile, making it possible to load ARGB and animated mouse cursors. Now that we have such funky eye candy, do you have an example to try out the new features? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: [patches] CursorStyle: ARGB mouse cursors
On Fri, Jun 22, 2007 at 12:52:58PM +0200, Simon Griph wrote: I've split up my previous patch into six smaller ones, making it more logical to follow. The patches applies one after another. (cat fvwm-xcursor_p?.diff | patch -p0) or (tar -xzOf fvwm-xcursor-patches.tar.gz | patch -p0) [snip] Committed. By the way,, I liked the patches. Very clean and easy to read. Thank you! Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: DestroyFunc not working
On Sun, Jul 15, 2007 at 11:17:51PM +0300, Juhani Pelli wrote: I've just built the current cvs version without any extra patches. It seems that DestroyFunc command is not working correctly. It just does nothing. No errors either. Fixed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: CVS broken (Was: PictureImageLoader stuff ...)
On Mon, Jul 16, 2007 at 12:54:09PM +0200, Dominik Vogt wrote: Probably some of the latest changes is breaking this. The attached patch fixes these errors and some more warnings. Can someone please commit it? This patch does not apply cleanly against CVS. :-P I don't have CVS access at work. [EMAIL PROTECTED]:~/fvwm/cvs.2/fvwm patch -p1 /tmp/3287-001.bin patching file ChangeLog Hunk #1 succeeded at 7 with fuzz 1 (offset 6 lines). patching file libs/Fxpm.h Hunk #4 FAILED at 96. 1 out of 4 hunks FAILED -- saving rejects to file libs/Fxpm.h.rej patching file libs/PictureImageLoader.c Hunk #14 FAILED at 881. 1 out of 16 hunks FAILED -- saving rejects to file libs/PictureImageLoader.c.rej That doesn't look too serious. Can you fix that manually? Without it, I'm getting a bunch of errors different to what was reported: Never mind, there's a semicolon missing in Fxpm.h, so you'll get tons of errors with --without-xpm-lib. Ciao Dominil ^_^ ^_^ -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
Re: CVS broken (Was: PictureImageLoader stuff ...)
On Tue, Jul 17, 2007 at 12:27:15AM +1000, Scott Smedley wrote: But I'm still getting lots of errors in libs/FRender.c. The fix requires that I link with -lXrender. But which makefile to edit? The build/make system is too complicated for me. :( What does the configure summary say? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: CursorStyle triggers a segmentation fault
On Mon, Jul 16, 2007 at 05:03:59PM +0100, seventh guardian wrote: Oh my... this is bad.. In current cvs, this causes a segmentation fault: Open FvwmConsole Type cursorstyle ROOT 10 (repeat the style if necessary) Close the FvwmConsole Boom, segmentation fault. Any ideas? I don't get any crashes. Do you have a stack trace and an minimal config file? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: CVS broken
On Tue, Jul 17, 2007 at 11:42:06PM +1000, Scott Smedley wrote: On Mon, Jul 16, 2007 at 10:04:26PM +0200, Dominik Vogt wrote: On Tue, Jul 17, 2007 at 12:27:15AM +1000, Scott Smedley wrote: But I'm still getting lots of errors in libs/FRender.c. The fix requires that I link with -lXrender. But which makefile to edit? The build/make system is too complicated for me. :( What does the configure summary say? Ah! With Xcursor support? no: Your libXrender version is too old This is on a SUSE 10.1 system. (doesn't seem that old?) So, configure isn't correctly disabling Xcursor support? Maybe. Does it still compile or link with libxcursor? Can you put the following output in a bzip2 archive and post it to the list: * The config.log file * The configure summary * The complete output of make (run it twice and just put the output of the second run in the archive). And what are the version numbers of your Xrender and Xcursor libraries? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: CVS broken
On Thu, Jul 19, 2007 at 06:35:26AM +1000, Scott Smedley wrote: Hi Dominik, So, configure isn't correctly disabling Xcursor support? Maybe. Does it still compile or link with libxcursor? Yep: (I copied the make output appended -lXcursor) [EMAIL PROTECTED]:~ cd fvwm/cvs.0/build.2/bin [EMAIL PROTECTED]:~/fvwm/cvs.0/build.2/bin gcc -Wall -Wno-implicit-int -g -O2 -o fvwm-root fvwm-root.o -L../libs -L/usr/X11R6/lib -lfvwm -lXpm -lSM -lICE -lXext -lX11 -lm -lpng -lz -lXcursor [EMAIL PROTECTED]:~/fvwm/cvs.0/build.2/bin But that does not show up in the make.out you sent? I've fixed the problem that shows up in that file. Does it still happen with current cvs if you build from scratch? Can you put the following output in a bzip2 archive and post it to the list: Find attached. And what are the version numbers of your Xrender and Xcursor libraries? [EMAIL PROTECTED]:~ locate Xrender.so /usr/lib/NX/lib/libXrender.so.1 /usr/lib/NX/lib/libXrender.so.1.2 /usr/X11R6/lib/libXrender.so /usr/X11R6/lib/libXrender.so.1 /usr/X11R6/lib/libXrender.so.1.2.2 [EMAIL PROTECTED]:~ locate Xcursor.so /usr/X11R6/lib/libXcursor.so /usr/X11R6/lib/libXcursor.so.1 /usr/X11R6/lib/libXcursor.so.1.0.2 Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
html-doc; make distcheck fails
... make[1]: Entering directory `/home/luthien/src/fvwm/doc' cp: `./header.html' and `header.html' are the same file make[1]: *** [header.html] Error 1 make[1]: Leaving directory `/home/luthien/src/fvwm/doc' make: *** [distdir] Error 1 This line from doc/Makefile.am is responsible: %.html: $(srcdir)/$@ @cp $(srcdir)/$@ $@ In a normal build environment, the top_builddir and the srcdir are the same, do the cp fails. I'm not sure how this is all meant, but if the file comes from CVS it is not built and should not be copied to the top_builddir. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: html-doc; make distcheck fails
On Thu, Jul 19, 2007 at 05:16:05PM +1000, Scott Smedley wrote: Hi Dominik, On Thu, Jul 19, 2007 at 12:15:33AM +0200, Dominik Vogt wrote: ... make[1]: Entering directory `/home/luthien/src/fvwm/doc' cp: `./header.html' and `header.html' are the same file make[1]: *** [header.html] Error 1 make[1]: Leaving directory `/home/luthien/src/fvwm/doc' make: *** [distdir] Error 1 This line from doc/Makefile.am is responsible: %.html: $(srcdir)/$@ @cp $(srcdir)/$@ $@ In a normal build environment, the top_builddir and the srcdir are the same, do the cp fails. I'm not sure how this is all meant, but if the file comes from CVS it is not built and should not be copied to the top_builddir. When top_builddir == srcdir, I don't want make to do anything. When top_builddir != srcdir, I want to 'cp' to top_builddir so that I can point my browser at the built documentation see that everything is ok. See the Problems building snap-20070713 thread. I notice you made a change to doc/Makefile.am. Did that fix your problem? I'm surprised if it did. No, I just reformatted it slightly: * Break long lines * Set variables like this foo = bar instead of this foo=bar (this is the way it's done in makefiles). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: html-doc; make distcheck fails
On Thu, Jul 19, 2007 at 11:32:26PM +1000, Scott Smedley wrote: Hi Dominik, I notice you made a change to doc/Makefile.am. Did that fix your problem? I'm surprised if it did. No, I just reformatted it slightly: I was referring to this change: - @ cp $(srcdir)/$@ $@ + @cp $(srcdir)/$@ $(top_builddir)/doc/$@ I notice you've changed it to: %.html: $(srcdir)/$@ test x$(top_srcdir) = x$(top_builddir) || \ cp $(srcdir)/$@ $(top_builddir)/doc/$@ Does this fix your problem? Yup. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: [bugfix] FvwmButtons: ActiveColorset without ActiveIcon/ActiveTitle
On Sun, Jul 22, 2007 at 06:49:39PM +0200, Simon Griph wrote: With ... *FvwmButtons: (ActiveColorset 1) ... the button isn't redrawn on EnterNotify. Hm, but that patch does not fix all the problems. I have Key F1 A M GotoPage 0 0 Key F2 A M GotoPage 1 0 Style FvwmButtons sticky *FvwmButtons: ActiveColorset 2 *FvwmButtons(11x5, Swallow FvwmPagerB 'FvwmPager FvwmPagerB * *') Now I do the following: 1) Pess Alt-F1 to go to page 1 0 2) Open some window and move it so that it partially covers the pager in the button bar. 3) Press Alt-F1 to go back to page 0 0. 4) Move the mouse over the pager. FvwmButtons draws a lit border around the pager button. 5) Move the pointer so that it is over the area that is covered by the window on page 1 0. 6) Press Alt-F2 to switch to page 1 0. == Although the pointer is not over the pager button, its border is still lit. Looks like FvwmButtons is ignoring more LeaveNotify events than it should. Se attached patch for a fix. Committed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: [bugfix] FvwmButtons: bitmap icons are drawn with incorrect colors
On Mon, Jul 23, 2007 at 04:13:03PM +0200, Simon Griph wrote: Without a button Title text, monochrome bitmap icons are drawn with a foreground color identical to the specified background color. The background color from a container specific colorset is on the other hand completely ignored. Colorset 1 bg yellow Colorset 2 fg red, bg blue *FvwmButtons: Colorset 1 *FvwmButtons: (Colorset 2, Icon bitmap.xbm) == blue foreground, yellow background A fix is attached. Committed, but (see below) Index: modules/FvwmButtons/draw.h === RCS file: /home/cvs/fvwm/fvwm/modules/FvwmButtons/draw.h,v retrieving revision 1.13 diff -u -r1.13 draw.h --- modules/FvwmButtons/draw.h9 Feb 2006 23:17:05 - 1.13 +++ modules/FvwmButtons/draw.h23 Jul 2007 14:00:55 - @@ -22,6 +22,5 @@ void RelieveButton(Window, int, int, int, int, int, Pixel, Pixel, int); void MakeButton(button_info *); void RedrawButton(button_info *, int draw, XEvent *pev); -void DrawTitle( - button_info *b, Window win, GC gc, XEvent *pev, Bool do_not_modify_fg); +void DrawTitle(button_info *b, Window win, GC gc, XEvent *pev); ^ There are too few context lines after the +void I can't decide whether the patch is complete. Did you manually remove any trailing newlines from the patch? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: FLCXOMCharset again
On Sat, Jul 28, 2007 at 03:41:18AM +0200, Jesús Guerrero wrote: Hello, Some of you (those not using iso8859-1/15) might know that vanilla Fvwm is not capable of showing accents and such things on the menus. This has come a number of times on forums.gentoo.org and fvwm.lair.be. Probably, in many more places. http://fvwm.lair.be/viewtopic.php?f=6t=1402hilit= http://forums.gentoo.org/viewtopic-p-4047950-highlight-.html?sid=3025a66762f485e4d916bb8c3ae08e66 Just to put a couple of examples, though I am sure I have seen this question much more times, and answered it a lot of times via IM or whatever. I found a bug that someone reported some time ago as well: http://www.fvwm.org/cgi-bin/fvwm-bug/incoming?id=1647;page=4;user=guest Which basically, uses the same patch I do, and that is attached to this mail. I haven't been able to find any reason why this patch has not been merged, I am not completely sure, since I have an utf8'ized system, and can't try, but I have some reports of this working on iso8859 systems as well. The patch seems to work ok, and it is the only way I can correctly spell my native language on FVWM. If there is something obvious that I am missing, just let me know. See below. --- libs/FlocaleCharset.c 2006-12-09 19:43:39.0 +0100 +++ libs/FlocaleCharset.c 2006-12-09 19:46:38.0 +0100 @@ -522,7 +522,7 @@ } if (FLCXOMCharsetList_num 0 FLCXOMCharsetList[0]) - FLCXOMCharset = FLCXOMCharsetList[0]; + FLCXOMCharset = FLCXOMCharsetList[FLCXOMCharsetList_num - 1]; #endif } What is special about the last entry in the charset list? Or are we just picking some random entry and hope that it works? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: Possible error in fvwm(1) manpage
On Tue, Jul 31, 2007 at 04:45:30AM -0300, Gustavo Rondina wrote: into your config, but it is not recommended; do this only if you know what you are doing. It is usually critical to start applications or modules *after* the entire config is read, because it contains styles or module configurations which can affect window appearance and functionality. The standard way to start applications or modules on fvwm's start up is to add them to an initialization function (usually StartFunction or InitFunction). This way they are only started *after* fvwm finishes to read and execute config file. Shouldn't that first after be replaced by before? These two paragraphs seems to be opposing each other. The first says that it is critical (i.e., dangerous, error prone) to start apps or modules after the config file is entirely read and processed. The second, on the other hand, states that apps and modules which must be launched on start up should be placed within an initialization function, so they would only be started after the config file was read and executed. The latter assertion seems to go against the former. I think the man page is correct, but the wording is confusing. It is ... critical to ... Means it is very important to ... but can be read as it is very bad to I'll change it in CVS. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: Issue with the new (=2007-02-04) move parsing code
On Tue, Jul 31, 2007 at 02:25:37PM +0200, Simon Griph wrote: I've lost a lot of small windows recently when I try to move them. Move w-5 w-0 This used to move the window 5% to the left, but with CVS code, the window is moved far to the right, and if the window is small, it's moved completely out of sight! First I thought that it must be a bug. But then I saw that an example in the man page had been changed from Move 40p w-10p to Move 40p w+-10p So the new w- behavior is intentional? But when is it useful? It's part of a larger patch: Move 0 0 Move +0 +0 Move top-left corner of window to top-left corner of screen. Move -0 -0 Move bottom-right corner of window to b-r corner of screen. Move +1p +1p Move top-left corner of window to +1/+1 Move +-1p +-1p Move top-left corner of window to -1/-1 Move -1p -1p Move bottom-right corner of window to scrrenwidth-1/screenheight-1. Move -1p -1p Move bottom-right corner of window to scrrenwidth-1/screenheight-1. Move w+1p w+1p Move top-left corner of window to its own position +1/+1. Move w+-1p w+-1p Move top-left corner of window to its own position -1/-1. Move w-1p w-1p Move bottom-right corner of window to its own position -1/-1. Hm, does not work. I'll fix it in a minute. It sure can case a lot of confusion for users with an old config when their windows unintentionally are moved of screen. A patch restoring the old w- behavior is attached. I found the GetOnePositionArgument code unnecessary complex, so I simplified it a bit, and also changed a few variable names to make them more descriptive. ;-) I know that the code can be written much shorter. But experience taught ma that I won't be able to understand it later if I put too many arithmetics in one line. Anyway, the fix is simply to put is_first_shift = 0 right at the beginning of the w case in the first switch. One more question. Why return 1 when the parsing fails? This will move the window to the top left corner on syntax error, instead of reverting to an interactive move as it used to do. Did it? I don't know, but I think just using some default is better that falling back to interactiove motion because the command might be caused by a module action or some other non-user input. I changed it to return 0 if the first shift fails to parse, but return 1 on subsequent parsing failures, so that Move syntax error will case an interactive move, but Move 50syntax 50error will move the window to 50 50. Can you redo that particular patch against the CVS code? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: Issue with the new (=2007-02-04) move parsing code
On Tue, Jul 31, 2007 at 06:39:38PM +0200, Simon Griph wrote: Move w+-1p w+-1p Move top-left corner of window to its own position -1/-1. Move w-1p w-1p Move bottom-right corner of window to its own position -1/-1. Those two cases are equivalent. Or am I missing something here? No, they are not! They result in the same position of the window because the size of the window and the size of the reference rectangle are identical. Without the leading w, they would result in completely different window positions, i.e. -1/-1 in the first case and screen_width - window_width -1 / screen_height - window_height -1 in the second case. A patch restoring the old w- behavior is attached. I found the GetOnePositionArgument code unnecessary complex, so I simplified it a bit, and also changed a few variable names to make them more descriptive. ;-) I know that the code can be written much shorter. But experience taught ma that I won't be able to understand it later if I put too many arithmetics in one line. It wasn't about making the code shorter. I only tried to increase readability. I think it's confusing that you special treat the '-' prefix in the first iteration of the loop, when all you really are doing is to use the (screen_width - window_width) starting position. That's what all the prefixes do, isn't it? They specify which starting position to use. Why not handle '-' at the same place as the other prefixes? Why should '-' be special? It isn't special. The first case handles the cases -1, -+1 and --1 while the second case handles 1, +1, ++1 and +-1. You see, it's much more complex than just 1, +1 and -1. The pattern is that if the offset begins with -, the bottom or right side of the window is moved relative to the bottom or right side of the reference rectangle (screen, window or pointer position). And if the prefix is absent or + the top/left side of the window is moved relative to the reference rectangle. That may sound confusing, but it's exactly how geometry specs work in X. The code reflects this pattern. First we choose a starting position depending on the prefix; 'w', 'm', '-', or ''. Then we enter the loop, adding to that position each successive iteration. Do you really think that such a change in the code will make it more difficult to understand? I can add a descriptive comment to the code if that will make you happy. :-) Anyway, the fix is simply to put is_first_shift = 0 right at the beginning of the w case in the first switch. I don't think that's the best way to fix this. I don't know ehether it's the nicest way, but it's definitely the right fix given the current state of the code. This is how the code was meant to work. It wasn't good in the 'm' case either. I really think it's confusing that the first iteration of the loop don't always has is_first_shift == 1. Well, maybe it's just difficult to understand why it's there. If the prefix w or m is present, we know the starting position to which the shifts are applied. Without the prefix, the first numeric argument determines the starting position and the further arguments the shifts. A clean way to handle this would be to parse the starting position right in the default case of the first switch. The is_first_shift flag would then be unnecessary. Furthermore, the shift arguments don't need the ++, --, +- or -+ prefix. I've committed something to CVS. The first switch now determines the starting position and the loop does the shifting. Do you think that's better? One more question. Why return 1 when the parsing fails? This will move the window to the top left corner on syntax error, instead of reverting to an interactive move as it used to do. Did it? I don't know, but I think just using some default is better that falling back to interactiove motion because the command might be caused by a module action or some other non-user input. Why move it to some default location? If backward compatibility is no concern, then my opinion is that the window should not be moved at all on syntax error. However, I still think that the return value really should indicate if the parsing was successful or not. Hm. I changed it to return 0 if the first shift fails to parse, but return 1 on subsequent parsing failures, so that Move syntax error will case an interactive move, but Move 50syntax 50error will move the window to 50 50. Can you redo that particular patch against the CVS code? Since I can't use is_first_shift for that anymore, I would have to use a new variable to indicate if it's the first iteration of the parsing loop or not, which would make the code more confusing in my opinion. But that is what I will do if you won't accept my other patch. ;-) I'm just trying to understand my own code. :-) Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description
Re: Issue with the new (=2007-02-04) move parsing code
difficult to understand why it's there. If the prefix w or m is present, we know the starting position to which the shifts are applied. Without the prefix, the first numeric argument determines the starting position and the further arguments the shifts. I never thought about it that way. Your code makes a lot more sense to me now. In my mind, it goes like this: * All the numeric arguments determine shifts to a reference point. * If the first numeric argument begins with a -, then the reference point is the (bottom) right corner of the reference rectangle minus the window width (or height). Otherwise the reference point is the (top) left corner of the reference rectangle. I think we should only do this if there is no prefix w or m. If a prefix is present, all numeric arguments shoulb simply be treated as shifts (that's what the code does at the moment). * If we have a w or a m prefix , the reference rectangle is the window or the pointer respectively. Otherwise the reference rectangle is the screen. A clean way to handle this would be to parse the starting position right in the default case of the first switch. The is_first_shift flag would then be unnecessary. Furthermore, the shift arguments don't need the ++, --, +- or -+ prefix. I've committed something to CVS. The first switch now determines the starting position and the loop does the shifting. Do you think that's better? Yes, I do. :-) You insist on looking at the entire first numeric argument (instead of just checking if that argument begins with a -) to determine the starting position, which means that you include the first offset from the reference point into the starting point. This time, it's clear to me that you have done it like that, so I'm OK with it. But for the sake of clarity, I still would have preferred if no offsets were added to the starting position before entering the shifting loop. Now we just have to make your code follow that *pattern* a little better. :-) First of all, we have the issue with the pointer (m) prefix: Move m-5 m-5 currently works exactly the same way as Move m+-5 m+-5 despite the fact that this violates the *pattern*. If it should work like that, then I really need an explanation so I can understand why. I think the second form is useless. The +- thing only makes sense for a numeric position specifier, not for m or w. The other issue, is the fact that you only include the screen_offset in the reference point if the first numeric argument doesn't have any suffix. Why should Move screen 2 -5p -5p move a window to screen 0 when Move screen 2 -5 -5 moves the window to screen 2? This seams strange to me, and not at all in line with the *pattern*. That's a bug. I remember thinking about it in a hurry. I also still think that the return value somehow should indicate if the parsing failed or not. If we don't want an interactive move on syntax error, I think it's better to handle that in the __move_window function instead. Probably. Make a suggestion based on my latest commit. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
htmldoc in-place installation
I'll remove the in-place installation of the html docs that caused problems recently. To test the html docs, just run make install in the future. Pleae remember to *always* run make distcheck when changing installation procedures. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: New 2.5.22 release?
On Mon, Aug 06, 2007 at 02:02:35PM +0100, seventh guardian wrote: The NEWS file is getting long, so I believe a new release would be good. Yes. Should we wait a couple of days for testing the recent changes to the module code? Is there any other issue that may prevent the release? The documentation: * There are several FIXME comments in the generated documentation. Try this: $ cd doc $ find . -type f | xargs grep -I FIXME * GNU make is needed to build it. I'm working on the second problem Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: FVWM: [PATCH] buffer overflow in utf-8 conversion
On Mon, Aug 06, 2007 at 07:45:03PM +0200, Jindrich Makovicka wrote: Hi, There is a typo in FlocaleChar2bOneCharToUtf8 causing a buffer overflow in FlocaleDrawString. On my machine it resulted in a crash when opening a Wikipedia main page in Thai. Trivial fix attached. Committed to CVS. Thank you. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: New 2.5.22 release?
On Tue, Aug 07, 2007 at 11:49:18AM +1000, Scott Smedley wrote: 1 month has elapsed since DV expressed a desire to relicence FVWM with GPLv3. I think we can go ahead with this now. Let's do that later. It's a lot of work and many many files have to be touched. The documentation issue is big enough for now. The documentation: * There are several FIXME comments in the generated documentation. Try this: $ cd doc $ find . -type f | xargs grep -I FIXME All the FIXME stuff in the docbook-xsl/ subdirectory can be safely ignored. Allright. A better check: $ cd doc $ find . -name '*.xml' | xargs grep -i FIXME There are only 2 matches. Both minor not a reason to preclude a 2.5.22 release. I'm not going to release fvwm with a big fat FIXME and a broken paragraph in the man page. * GNU make is needed to build it. I'm so glad someone is helping on this - I find the build system complicated. Done. * There is a Perl script to generate some part of the documentation (doc/util/genAllCommands.pl). Fvwm does not require Perl to be built and I have no intention to change that. That perl script is used to create the alphabetically-sorted table on this page: http://www.fvwm.org/doc/unstable/allCommands.html It is run manually (usually be me) anytime a new command is documented. So, no need to worry about Perl dependencies. 1) I think this is not acceptable. It's too difficult to add new commands right now. I'm working on a solution to have just functable.c as a source for the commands list and to eliminate all other tables. The script must be run automatically when I'm done (and there is no real reason to require running it manually). 2) With a package conforming to the GNU standards, it should be possible to build a new tarbarr from the tarball. The script would be a regular part of the build process and can not be written in Perl. On a separate issue: I am keen to implement Viktor's suggestion to build the documentation on 'make dist'. See: http://thread.gmane.org/gmane.comp.window-managers.fvwm.devel/3173 (It doesn't have to happen before 2.5.22) I think this is a very good idea. Among other things, it would alleviate some of DV's concerns about slow build times. DV: As you have a much better grasp of the build system than I, is this something you might like to tackle? If not, some implementation advice would be very helpful. Yes, I'm planning to do this, but it's not necessary for this release. Let's not do too many things at the same time. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: New 2.5.22 release?
On Tue, Aug 07, 2007 at 11:49:18AM +1000, Scott Smedley wrote: * GNU make is needed to build it. I'm so glad someone is helping on this - I find the build system complicated. It *is* complicated. As a rule of thumb, always run $ make distcheck when you work on the installation process. By eliminating the errors you can learn a lot about how automake works. And don't hesitate to ask if you don't understand something. The distcheck target does the following: * Generate the tarball. * Unpack the tarball. * Build and install the tarball with separate source, build and install directories. It write protects the directories during build steps when they are not allowed to be written. * Deinstall and check that everything is removed. Common errors are that the Makefile tried to create a file in the source directory and that files are left in the install directory after make uninstall. It's difficult to understand from the error messages though. The autoconf/automake documentation is also very good: http://www.gnu.org/software/autoconf/manual/ http://www.gnu.org/software/automake/manual/ And there used to be the autobook, but it's no longer available as postscript, only as a paper copy and html files. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: New 2.5.22 release?
On Tue, Aug 07, 2007 at 03:17:02PM +0100, Thomas Adam wrote: On 07/08/07, Scott Smedley [EMAIL PROTECTED] wrote: write fvwm in lower case Why? Agreed. FVWM is an acronym; it should be written as such, which means in upper case. And why should acronyms be written in capitals? Fvwm is a name, and it's written fvwm almost everywhere. I unified the spelling years ago, and I see no reason to change it again. fvwm works just fine. The remaining occurences of FVWM are there just because I hesitated to change them. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: FVWM: spelling of fvwm vs. Fvwm vs. FVWM
On Thu, Aug 09, 2007 at 01:07:12PM +0100, Thomas Adam wrote: On 09/08/07, Dominik Vogt [EMAIL PROTECTED] wrote: I think opinions have been exchanged by now. So, who of the people who promote FVWM as fvwm's name is willing to do the following: * Rename *all* occurences in *all* files in the fvwm and fvwm-web repositories from fvwm or Fvwm to FVWM, Excluding symbolic names in the source files. I am more than happy to. * This includes - The name of the CVS repositories (FVWM and FVWM-web). - The names of the mailing lists (FVWM, FVWM-workers, etc.) - File names (fvwm.c - FVWM.c, fio.c - Fio.c, fsm.h - Fsm.h etc.) You're stretching the point a little far here -- you can keep the filenames as-is. I think you have no idea of the extend of my efforts to keep naming consistent in the source tree. - The names of the executables (fvwm - FVWM, make_fvwmdist.sh Again, you can keep that as-is. * Take the responsibility to explain to the users why this was done and why their config files are broken. I am happy to update the documentation to reflect s/fvwm/FVWM/g in *context* -- nothing else needs to change. And I'm happy if you *don't* do it just in context. I've spent many hours to have consistent spelling all over the place. You're angry -- so I will let some of your points go without rising to the challenge. I'm serous about every single pont. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: New 2.5.22 release?
On Mon, Aug 13, 2007 at 10:58:09PM +0200, Viktor Griph wrote:
On Mon, 13 Aug 2007, Dominik Vogt wrote:
On Mon, Aug 13, 2007 at 11:08:57AM +0100, seventh guardian wrote:
On 8/6/07, Dominik Vogt [EMAIL PROTECTED] wrote:
On Mon, Aug 06, 2007 at 02:02:35PM +0100, seventh guardian wrote:
The NEWS file is getting long, so I believe a new release would be
good.
Yes.
Ok, so where do we stand now?
* The new module code should be safe [done]
* Is everything related to the manpage fixed?
No, not at all. The only thing fixed is that building the docs
does not require GNU make anymore. All other points on the list
remain.
The fixmes are gone. Perl isn't needed for building but it's unconvinient
to add commands, but that can be fixed after release. Were there any other
points?
Most important: the generated man page is still broken. For
example:
allbox tab(:); lB lB lB. T{ T}:T{ depth 8 (256 colors) T}:T{
depth 4 (16 colors) T} l l l l l l l l l. T{ PseudoColor T}:T{ 68
(4 cc + 4 grey) T}:T{ 10 (2 cc + 2 grey) T} T{ GrayScale T}:T{ 64
regular grey T}:T{ 8 regular grey T} T{ DirectColor T}:T{ 32 (3 cc
+ 5 grey) T}:T{ 10 (2 cc + 2 grey) T}
There are three other places with similar broken formatting in fvwm.1.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, dominik.vogt (at) gmx.de
signature.asc
Description: Digital signature
Re: ListenOnly modules really needed?
On Thu, Aug 16, 2007 at 11:14:58AM +0200, Dominik Vogt wrote:
On Tue, Aug 14, 2007 at 06:58:46PM +0100, seventh guardian wrote:
On 8/14/07, Dominik Vogt [EMAIL PROTECTED] wrote:
On Tue, Aug 14, 2007 at 09:15:21AM -0400, Dan Espen wrote:
seventh guardian [EMAIL PROTECTED] writes:
I must confess I'm not very fond of listen only modules. I believe it
is more of a hack than a long term solution to the shell script
module problem. And I would really like it removed, and for that the
sooner the better.
So I was messing around to see if it was really needed, and it's not.
The pro
of:
run Module FvwmCommandS
create a simple bash script like this:
#!/bin/bash
echo 'Module FvwmBanner' /var/tmp/FvwmCommand-${HOSTNAME}${DISPLAY}C
Now a nice FvwmBanner will appear. You can build complicated scripts
in any language that allows you to write to a file, zsh included, no
overhead whatsoever.
And if you want to listen to fvwm it's a matter of listening to the
'M' counterpart: /var/tmp/FvwmCommand-${HOSTNAME}${DISPLAY}M
The only issue I can see here is the possible variation of the fifo
names, which is not that severe.
Any reasons to keep the ListenOnly module mechanism?
Compatibility?
I just coded it a while ago for my own purposes, so that's no
problem.
Running FvwmCommandS is a security exposure.
Some users might be reluctant to use it.
I don't use FvwmCommand because it's too slow. I wanted a solution
for displaying a clock and the process using the most cpu with as
little overhead as possible. I do not want to start an executable
every n seconds because it has a negative influence on my system,
(namely the graphics performance of Kobo-Deluxe). I didn't do it
for the fun of it but to solve a real problem.
You missed my point, I'm not using FvwmCommand, but only FvwmCommandS.
FvwmCommandS creates two fifos that can be used to send and receive
text to/from fvwm. So instead of calling FvwmCommand, you can directly
write commands to the command fifo. So really NO overhead at all.
(attached my fvwm_periodic script for reference)
I see. But this has several important issues:
* The module never notices that fvwm has gone away. Every time
I restart I get another module. At the moment it catches the
PIPE signal and terminates, just like every other module.
* It would have to guess the pipe's name. Note that I ofthen run
multiple fvwms on separate displays, so it would not do to hard
code /var/tmp/FvwmCommand-zitrone.obstwiese:0.0M (or 0.0C?).
As for the security issues, they can easily be circumvented by putting
the fifo in the user home dir.
The -f option of FvwmCommandS currently does not allow to add the
display name in the path, so it is difficult to have multiple
modules on different displays at the same time.
By the way, I really don't understand why anybody considers
ListenOnlyModules a hack. Isn't it perfectly acceptable to write
a module that does not want to take any input? Why is it bad if
fvwm deos not send messages to certain modules?
Of course, writing such a module as an architecture dependent zsh
script *is* a hack, but that's the user's problem (i.e. mine), not
fvwm's.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, dominik.vogt (at) gmx.de
signature.asc
Description: Digital signature
Re: New 2.5.22 release?
On Thu, Aug 16, 2007 at 07:42:36PM +0200, Viktor Griph wrote:
On Thu, 16 Aug 2007, Dominik Vogt wrote:
On Mon, Aug 13, 2007 at 10:58:09PM +0200, Viktor Griph wrote:
On Mon, 13 Aug 2007, Dominik Vogt wrote:
On Mon, Aug 13, 2007 at 11:08:57AM +0100, seventh guardian wrote:
On 8/6/07, Dominik Vogt [EMAIL PROTECTED] wrote:
On Mon, Aug 06, 2007 at 02:02:35PM +0100, seventh guardian wrote:
The NEWS file is getting long, so I believe a new release would be
good.
Yes.
Ok, so where do we stand now?
* The new module code should be safe [done]
* Is everything related to the manpage fixed?
No, not at all. The only thing fixed is that building the docs
does not require GNU make anymore. All other points on the list
remain.
The fixmes are gone. Perl isn't needed for building but it's unconvinient
to add commands, but that can be fixed after release. Were there any other
points?
Most important: the generated man page is still broken. For
example:
allbox tab(:); lB lB lB. T{ T}:T{ depth 8 (256 colors) T}:T{
depth 4 (16 colors) T} l l l l l l l l l. T{ PseudoColor T}:T{ 68
(4 cc + 4 grey) T}:T{ 10 (2 cc + 2 grey) T} T{ GrayScale T}:T{ 64
regular grey T}:T{ 8 regular grey T} T{ DirectColor T}:T{ 32 (3 cc
+ 5 grey) T}:T{ 10 (2 cc + 2 grey) T}
There are three other places with similar broken formatting in fvwm.1.
I'll look into it if you can give me some hint on how to fix automake for
the doc directory on my macbook.
What's the problem?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, dominik.vogt (at) gmx.de
signature.asc
Description: Digital signature
Re: New 2.5.22 release?
On Thu, Aug 16, 2007 at 09:08:51PM +0200, Viktor Griph wrote:
yOn Thu, 16 Aug 2007, Viktor Griph wrote:
On Thu, 16 Aug 2007, Dominik Vogt wrote:
On Thu, Aug 16, 2007 at 07:42:36PM +0200, Viktor Griph wrote:
I'll look into it if you can give me some hint on how to fix automake for
the doc directory on my macbook.
What's the problem?
doc/fvwm/Makefile.am:14: BUILD_FILES was already defined in condition
TRUE, which implies condition FVWM_BUILD_HTMLDOC_TRUE
BUILD_FILES (User, where = doc/fvwm/Makefile.am:14) +=
{
TRUE =
}
doc/fvwm/Makefile.am:14: BUILD_FILES was already defined in condition
TRUE, which implies condition FVWM_BUILD_MANDOC_TRUE
BUILD_FILES (User, where = doc/fvwm/Makefile.am:14) +=
{
FVWM_BUILD_HTMLDOC_TRUE = $(HTML_FILES)
TRUE =
}
+ exit 3
This is with automake 1.6.3 and autoconf 2.59.
I tried to fix it without understanding the problem. Does it work
now?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, dominik.vogt (at) gmx.de
signature.asc
Description: Digital signature
Re: ListenOnly modules really needed?
On Thu, Aug 16, 2007 at 07:06:13PM +0100, seventh guardian wrote: On 8/16/07, Dominik Vogt [EMAIL PROTECTED] wrote: On Thu, Aug 16, 2007 at 11:14:58AM +0200, Dominik Vogt wrote: By the way, I really don't understand why anybody considers ListenOnlyModules a hack. Isn't it perfectly acceptable to write a module that does not want to take any input? Why is it bad if fvwm deos not send messages to certain modules? A couple of reasons for it to be within my definition of hack: 1. Modules are supposed to work following a set of rules, and ListenOnly modules break that set of rules. It may also prevent some future beneficial changes to the module communication because ListenOnly modules wouldn't work anymore. I really can't think of an interface change that breaks external ListenOnlyModules but keeps external input/output moudles intact. 2. It is a particular scratch for a particular itch: it is only useful for zsh. Perl modules work with the perl fvwm lib, C modules should work with the (hypothetical) C fvwm lib. Other shell's can't work with this mechanism, so some other mechanism must be devised for them. That is simply not true. There's nothing zsh-specific about the module mechanism. I used zsh because it has a lot of features that helped implementing the module (i.e. built in datetime and select functions). The module communication works with any shell that has a decent printf command or any other scripting or programming language that is capable of writing binary output to a given file descriptor. So what I propose is kind of a universal scratch for that same itch, applied to all shells. It isn't working as supposed yet, but once it is it makes no sense to support the two scratches. Well, if there's a different way to have a light weight, output only module without starting another process that's fine. If it does not involve writing the code to receive messages, even better. However, that functionality is already written in a clean and simple way. The only difference between a normal and a ListenOnlyModule is that fvwm does not expect the module to take any input. This could have been done as options to the module command too, but that's only a matter of syntax. Note that the module interface never prevented anybody from writing a module in any scripting language. It's easy to do and I actually did it years ago when I learend about the module interface. It's just easier to do with ListenOnlöyModules. Of course, writing such a module as an architecture dependent zsh script *is* a hack, but that's the user's problem (i.e. mine), not fvwm's. It is if the users complain that they want the same facility for bash :) I believe we can't have yet a third mechanism :P By the way, there's another problem with the supposed solution using FvwmCommandS: You need a dedicated pipe for every module, because the pipe mechanism isn't safe. If multiple modules write to the pipe at the same time, the commands may mix (the atomic write size guaranteed by POSIX is either 256 or 512 bytes). So if the user calls FvwmCommand while the module sends commands to fvwm, the result may be undefined. FvwmConsole actually has this problem when pasting many large commands into the FvwmConsole window. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: New 2.5.22 release?
On Fri, Aug 17, 2007 at 12:42:50AM +0200, Viktor Griph wrote:
On Fri, 17 Aug 2007, Dominik Vogt wrote:
On Thu, Aug 16, 2007 at 10:13:19PM +0200, Viktor Griph wrote:
On Thu, 16 Aug 2007, Viktor Griph wrote:
On Thu, 16 Aug 2007, Dominik Vogt wrote:
Most important: the generated man page is still broken. For
example:
allbox tab(:); lB lB lB. T{ T}:T{ depth 8 (256 colors) T}:T{
depth 4 (16 colors) T} l l l l l l l l l. T{ PseudoColor T}:T{ 68
(4 cc + 4 grey) T}:T{ 10 (2 cc + 2 grey) T} T{ GrayScale T}:T{ 64
regular grey T}:T{ 8 regular grey T} T{ DirectColor T}:T{ 32 (3 cc
+ 5 grey) T}:T{ 10 (2 cc + 2 grey) T}
There are three other places with similar broken formatting in fvwm.1.
I'll look into it if you can give me some hint on how to fix automake for
the doc directory on my macbook.
Does that formatting show up in your processed output?
Yes, that's from the formatted man page.
It is formatting
for tbl(1), which seems to be used by docbook for tables. Is it feasable
to require tbl for building fvwm.1? I think it has been around for a long
time, but I don't know for how long. GNU roff runs preprocessors
automatic, but for compatibility it has to be done at build time.
I really don't know what you are talking about, but gnu tbl is
installed on my machine. Are you saying that tbl is required for
generating the man page or for viewing it? And when I run
tbl was required for viewing it until my latest commt. Now it should only
be required for generating it. I'm not sure exactly why your version of
man doesn't process tbl input, but it didn't work on a solaris 9 machine I
have access to either, so I igured it has to be done at build stage for
compatibility.
$ nroff fvwm.1 | col -bx
manually, I still have that markup in the output.
Does it work with the latest Makefile?
Yes. I'm now looking at the issues brought up by requiring sed,
perl and tbl for building the docs.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, dominik.vogt (at) gmx.de
signature.asc
Description: Digital signature
Re: New 2.5.22 release?
On Fri, Aug 17, 2007 at 05:26:30PM +0200, Viktor Griph wrote: On Fri, 17 Aug 2007, Dominik Vogt wrote: Yes. I'm now looking at the issues brought up by requiring sed, perl and tbl for building the docs. So, is everything ready for release? And is it really helpful to have tables in the man page? What's the benefit of +--++ | Formatting Directive| Description| +--++ |%l, %c %r | Insert the next item | | | label. Up to three labels | | | can be used. The item | | | column is left-aligned | | | (%l), centered (%c) or | | | right-aligned (%r).| +--++ |%i| Inserts the mini icon. | over %l, %c, %r Insert the next item label. Up to three labels can be used. The item column is left-aligned (%l), centered (%c) or right-aligned (%r). %i Inserts the mini icon. I find the table harder to read, but t's easier to find an entry you are looking for. It is also very uncommon to have man pages with ASCII tables. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: New 2.5.22 release?
On Fri, Aug 17, 2007 at 06:13:49PM +0200, Viktor Griph wrote: On Fri, 17 Aug 2007, Dominik Vogt wrote: On Fri, Aug 17, 2007 at 05:26:30PM +0200, Viktor Griph wrote: On Fri, 17 Aug 2007, Dominik Vogt wrote: Yes. I'm now looking at the issues brought up by requiring sed, perl and tbl for building the docs. So, is everything ready for release? And is it really helpful to have tables in the man page? What's the benefit of Other than the table with visuals and depth info I don't really see any use for them. I've been changing informaltable to variablelist in several places already. +--++ | Formatting Directive| Description| +--++ |%l, %c %r | Insert the next item | | | label. Up to three labels | | | can be used. The item | | | column is left-aligned | | | (%l), centered (%c) or | | | right-aligned (%r).| +--++ |%i| Inserts the mini icon. | over %l, %c, %r Insert the next item label. Up to three labels can be used. The item column is left-aligned (%l), centered (%c) or right-aligned (%r). %i Inserts the mini icon. I find the table harder to read, but t's easier to find an entry you are looking for. It is also very uncommon to have man pages with ASCII tables. I also find the variablelist better than tables for describing meaning of certain directives. They use the space more efficient and they don't have an ugly frame. Can you eliminate the use of tables then? I think we just have a couple of them. Speaking of the depth/visual table: Sholud it really read Note that if you use a private color map (i.e., fvwm is started with the -C or the -I options), then others defaults are used. ^^^ ? I'm not a master of Engish grammar, but that s looks bad to me. That's a typo. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: New 2.5.22 release?
On Sat, Aug 18, 2007 at 10:09:46PM +0200, Viktor Griph wrote: On 8/18/07, Dominik Vogt [EMAIL PROTECTED] wrote: Can you eliminate the use of tables then? I think we just have a couple of them. The only remaining table it the one in the description of the color-limit option. That is a legimate table. I'm not sure exactly how to eliminate it. (Thst'd the only tsble that existed in the old man page.) Hm, it could be written like this: XFree-4.3 or better pre-allocate only 85 colors. If no pre- allocated palette is auto detected the defaults are as follow: Display depth 8 (256 colors) PseudoColor: 68 (4x4x4 color cube + 4 grey) GrayScale: 64 regular grey DirectColor: 32 (3x3x3 color cube + 5 grey) Display depth 4 (16 colors) PseudoColor: 10 (2x2x2 color cube + 2 grey) GrayScale:8 regular grey DirectColor: 10 (2x2x2 color cube + 2 grey) Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: New 2.5.22 release?
On Sun, Aug 19, 2007 at 12:42:15AM +0200, Dominik Vogt wrote: On Sat, Aug 18, 2007 at 10:09:46PM +0200, Viktor Griph wrote: On 8/18/07, Dominik Vogt [EMAIL PROTECTED] wrote: Can you eliminate the use of tables then? I think we just have a couple of them. Allright, with your latest commit there is one table left in doc/commands/Menu.xml and four more tables in doc/modules/FvwmTabs.xml. Also, some acronyms use arconym ... /acronym and some use emphasis remap='SM' ... /emphasis. The old man page had two uses of .SM: Acronyms and key names. But cleaning this up is not necessary before the release. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: New 2.5.22 release?
On Sun, Aug 19, 2007 at 11:52:09PM +0200, Viktor Griph wrote: On 8/19/07, Dominik Vogt [EMAIL PROTECTED] wrote: On Sun, Aug 19, 2007 at 12:42:15AM +0200, Dominik Vogt wrote: On Sat, Aug 18, 2007 at 10:09:46PM +0200, Viktor Griph wrote: On 8/18/07, Dominik Vogt [EMAIL PROTECTED] wrote: Can you eliminate the use of tables then? I think we just have a couple of them. Allright, with your latest commit there is one table left in doc/commands/Menu.xml and four more tables in doc/modules/FvwmTabs.xml. The one in Menu.ml is now replaced, as is the keybindings in FvwmTabs.xml. The other three tables inFvwmTabs.xml are slightly more complicated. Also FvwmTabs.1 is not set to be installed (or even built) from the xml source. The old FvwmTabs.1 man page will be installed with the current setup. The man page is not built and istalled, but the HTML documentation is (see doc/commands/Makefile.am). By the way, there's another issue with the build process: * The documentation has a build error when building on a multi core machine with -j 2. I think there are some dependencies missing. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
ModuleSynchronous hangs with current CVS
With this minimal .fvwm2rc fvwm hangs in startup for many seconds. --- BEGIN .fvwm2rc --- ModuleSynchronous Timeout 5 FvwmTheme END .fvwm2rc I think something is broken in the module code. Since it waits longer when more commands are added, fvwm may run into the module timeout repeatedly (but maybe not). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: ModuleSynchronous hangs with current CVS
On Tue, Aug 21, 2007 at 01:57:40PM +0200, Dominik Vogt wrote:
With this minimal .fvwm2rc fvwm hangs in startup for many seconds.
--- BEGIN .fvwm2rc ---
ModuleSynchronous Timeout 5 FvwmTheme
END .fvwm2rc
I think something is broken in the module code. Since it waits
longer when more commands are added, fvwm may run into the module
timeout repeatedly (but maybe not).
The attached patch is responsible for the bug. It was committed
between 2007-08-05 23:00:00 and 2007-08-05 23:30:00.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, dominik.vogt (at) gmx.de
Index: ChangeLog
===
RCS file: /home/cvs/fvwm/fvwm/ChangeLog,v
retrieving revision 1.2963
retrieving revision 1.2964
diff -u -u -r1.2963 -r1.2964
--- ChangeLog 5 Aug 2007 20:49:10 - 1.2963
+++ ChangeLog 5 Aug 2007 21:17:28 - 1.2964
@@ -30,6 +30,12 @@
(module_list_len):
renamed as list handling functions
+ * fvwm/events.c (My_XNextEvent):
+ * fvwm/module_list.h:
+ * fvwm/module_list.c (module_alloc):
+ (do_execute_module):
+ removed useless is_cmdline_module stuff
+
2007-08-05 Dominik Vogt dominik(dot)vogt(at)gmx(dot)de
* configure.ac:
Index: fvwm/events.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/events.c,v
retrieving revision 1.544
retrieving revision 1.545
diff -u -u -r1.544 -r1.545
--- fvwm/events.c 5 Aug 2007 20:49:10 - 1.544
+++ fvwm/events.c 5 Aug 2007 21:17:28 - 1.545
@@ -4039,13 +4039,6 @@
if (fFvwmInStartup)
{
modstore = module_get_next(NULL);
- for (; modstore != NULL; modstore = module_get_next(modstore))
- {
- if (MOD_IS_CMDLINE(modstore-module) == 1)
- {
- break;
- }
- }
if (modstore == NULL)
{
/* last module */
Index: fvwm/module_list.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/module_list.c,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -u -r1.14 -r1.15
--- fvwm/module_list.c 5 Aug 2007 20:49:10 - 1.14
+++ fvwm/module_list.c 5 Aug 2007 21:17:28 - 1.15
@@ -129,7 +129,6 @@
fmodule *module;
module = (fmodule *)safemalloc(sizeof(fmodule));
- MOD_SET_CMDLINE(module, 0);
MOD_SET_REMOVED(module, 0);
MOD_READFD(module) = -1;
MOD_WRITEFD(module) = -1;
@@ -423,7 +422,6 @@
{
/* add to the list of command line modules */
DBUG(executeModule, starting commandline module\n);
- MOD_SET_CMDLINE(module, 1);
}
/* make the PositiveWrite pipe non-blocking. Don't want to jam
Index: fvwm/module_list.h
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/module_list.h,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -u -r1.10 -r1.11
--- fvwm/module_list.h 5 Aug 2007 20:49:10 - 1.10
+++ fvwm/module_list.h 5 Aug 2007 21:17:28 - 1.11
@@ -24,7 +24,6 @@
{
struct
{
- unsigned is_cmdline_module : 1;
unsigned is_removed : 1;
} xflags;
int xreadPipe;
@@ -44,8 +43,6 @@
} fmodule_store;
-#define MOD_IS_CMDLINE(m) ((m)-xflags.is_cmdline_module)
-#define MOD_SET_CMDLINE(m,on) ((m)-xflags.is_cmdline_module = !!(on))
#define MOD_IS_REMOVED(m) ((m)-xflags.is_removed)
#define MOD_SET_REMOVED(m,on) ((m)-xflags.is_removed = !!(on))
#define MOD_READFD(m) ((m)-xreadPipe)
signature.asc
Description: Digital signature
Re: New 2.5.22 release?
On Tue, Aug 21, 2007 at 11:34:55AM +0200, Dominik Vogt wrote: By the way, there's another issue with the build process: * The documentation has a build error when building on a multi core machine with -j 2. I think there are some dependencies missing. Fixed. Multiple targets were using the same temporary files. I think we can release 2.5.22 now. Any volunteers? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
