CVS domivogt: * Completely removed the old builtin command interface.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/09/11 04:45:25 Modified files: . : ChangeLog fvwm : add_window.c builtins.c colorset.c conditional.c events.c focus.c functions.c fvwm.h icons.c menucmd.c module_interface.c move_resize.c placement.c schedule.c stack.c update.c virtual.c windowlist.c windowshade.c Log message: * Completely removed the old builtin command interface. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt: * Removed a temporary pre-execcontext function.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/09/11 05:23:58 Modified files: fvwm : move_resize.c libs : FEvent.c FEvent.h Log message: * Removed a temporary pre-execcontext function. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
the new internal command execution interface
First a word of warning: although the sources compile again, the
work is by no means complete. There are definitely a lot of nasty
bugs yet.
Now to the details. I initially started this work to make fvwm
fully functional in the menu loop with the mid term goal of making
tear off menus behave like any other windows. This required to
remove all the global variables that were used to pass vital
information about the execution context around (Event, Fw,
lastTimestamp and others).
The new code consits of three central parts:
* An event handling wrapper library FEvent.[ch] which hides the
X envent handling functions and stores some extra information.
* A new module execcontext.[ch] that provides a structure that
holds all information a builtin command or an event handler
needs to know to do its job.
* The new builtin command and event handler interface (formerly
F_CMD_ARGS and (void)).
Basically, executing anything now works like this:
* An action is triggered (by an X event, a module, the scheduler,
or other sources like startup or garbage_collection).
* Depending on the action's source, either execute_function() or
dispatch_event() is called.
* Both functions assemble an exec_context_t structure with the
relevant execution information. Note that this structure type
is *read only* everywhere. If any members have to be changed,
the function exc_clone_context() must be called to create a
(read only) copy with some values changed.
* The structure (exc) is passed down into any function that needs
to know something about the context of execution. For event
handlers, the structure is wrapped in another structure to
allow extending the event handler interface without much effort
in the future.
* As a side effect, it's no longer possible to pass values up to
the caller. Any new code should try very hard to avoid this.
* Thus, it is no longer possible to change members of the event
structure. To do this, build up a new event structure in local
memory and call fev_fake_event, e.g.
XEvent e = *exc-e.etrigger;
e.xbutton.x = 0;
e.xbutton.y = 0;
few_fake_event(e);
which is equivalent to the old way:
Event.xbutton.x = 0;
Event.xbutton.y = 0;
This is the structure's definition (refined for readability).
typedef struct
{
exec_context_type_t type;
struct
{
XEvent *etrigger;
XEvent *elast;
} x;
struct
{
FvwmWindow *fw;
Window w;
unsigned long wcontext;
} w;
struct
{
int modnum;
} m;
} exec_context_t;
* type: an enum that indicates the original source of the action,
e.g. EXCT_EVENT or EXCT_MODULE. I'm not sure this information
is useful, so I may remove it.
* x.etrigger: a copy of the event that originally triggered the
action.
* x.elast: always points to the latest event received from the
X server. At the beginning of execution, the contents of
*e.last are always identical to the contents of *x.etrigger
(although the pointers are different).
* w.fw, w.w, w.wcontext: the context FvwmWindow, Window, and
context mask.
* m.modnum: the module number that caused the action or -1.
References:
* FEvent.h for an overview of the event handling layer.
* execcontext.h for the available exec_context_t handling
function.
* functions.c (execute_function... functions) for the new
function execution interface including some convenience
functions.
* conditionals.c for some examples.
Notes:
* FEvent.h has an additional iterface that is only exported if
FEVENT_PRIVILEGED_ACCESS is defined when including it. This
must be accessed *only* from execcontext.c.
* DeferExecution is now called centrally in functions.c and
*must not* be called externally.
Hopefully I'll get most functionality running this evening. Until
then, many, many things are broken. If you feel like trying it
out (not recommended unless you're a developer) write down a list
of things that don't work, but please don't bother me with them
yet. I'll announce when I think that public testing makes sense.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt: * Removed debug code.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/09/11 05:50:02 Modified files: fvwm : events.c Log message: * Removed debug code. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt: * Fixed (de)iconify bug introduced with transient stacking bug.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/09/11 12:51:32 Modified files: . : ChangeLog fvwm : icons.c Log message: * Fixed (de)iconify bug introduced with transient stacking bug. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: CVS domivogt: * Event handling fixes. Code is slowly becoming usable again. Known problems:
On Wed, Sep 11, 2002 at 08:00:51PM -0500, fvwm-workers wrote: Log message: * ... Code is slowly becoming usable again... It's stable enough to write or apply patches given that you can live without restart/recapture and tolerate buggy menus and complex functions. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: FVWM crashes when typing Q on Pine
On Sep 8, 2002, 19:55 (-) Mikhael Goikhman wrote: On 08 Sep 2002 21:38:20 +0200, Wolfgang Pfeiffer wrote: On Sep 8, 2002, 18:59 (-) Mikhael Goikhman wrote: On 08 Sep 2002 20:43:02 +0200, Wolfgang Pfeiffer wrote: On Sep 8, 2002, 08:51 (-) Mikhael Goikhman wrote: Can you reproduce the crash with this two line .xinirc: xterm -geometry 92x50+1550+60 -e /usr/bin/pine /usr/bin/fvwm -cmd 'AddToFunc StartFunction I FvwmPager' these 2 lines when starting fvwm or fvwm-themes-start ? The second line already starts fvwm in foreground, don't put any other lines into ~/.xinitrc except for maybe sleep 3 in the middle. The same as with the old .xinitrc: XCrash if I type a 'q' on Pine in an xterm So this happens with no config at all. Fine. Forget fvwm-themes for now. Please recompile 2.5.3 from sources and install it (say into /usr/local). Then run the same 2 line .xinitrc, but with /usr/local/bin/fvwm instead. When you get core, run gdb /usr/local/bin/fvwm core and then where. Send the stack trace (5-20 lines), preferably to [EMAIL PROTECTED] Thank you very much. Regards, Mikhael. OK: I installed FVWM from source to the default directories with: ./configure make make check (not being sure whether this was useful .. :) make install I didn't touch any config.files for the build: just ran the 4 commands from above. Didn't even install fribidi from source (tho there is fribidi installed from an RPM ...) then running: ### $ gdb /usr/local/bin/fvwm core GNU gdb 19991004 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux... Core was generated by `/usr/local/bin/fvwm -cmd AddToFunc StartFunction I FvwmPager'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/X11R6/lib/libXpm.so.4...done. Reading symbols from /usr/lib/libstroke.so.0...done. Reading symbols from /usr/X11R6/lib/libSM.so.6...done. Reading symbols from /usr/X11R6/lib/libICE.so.6...done. Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Reading symbols from /lib/libm.so.6...done. Reading symbols from /usr/lib/libpng.so.2...done. Reading symbols from /usr/lib/libz.so.1...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from /usr/lib/gconv/ISO8859-1.so...done. #0 0x80a590c in FlocaleFreeNameProperty (ptext=0x80effe8) at Flocale.c:1569 ---Type return to continue, or q return to quit--- 1569if (ptext-name != NULL ptext-name != *ptext-name_list) (gdb) where #0 0x80a590c in FlocaleFreeNameProperty (ptext=0x80effe8) at Flocale.c:1569 #1 0x8074355 in free_window_names (fw=0x80effe0, nukename=0, nukeicon=1) at add_window.c:2812 #2 0x8072651 in destroy_icon (fw=0x80effe0) at add_window.c:1255 #3 0x80744bd in destroy_window (fw=0x80effe0) at add_window.c:2915 #4 0x8070141 in HandleUnmapNotify () at events.c:3228 #5 0x80703a1 in DispatchEvent (preserve_Fw=0) at events.c:3358 #6 0x8070432 in HandleEvents () at events.c:3413 #7 0x808398a in main (argc=3, argv=0xba64) at fvwm.c:2251 (gdb) ## Hoping it helps Wolfgang -- Key on: http://home.t-online.de/home/520050060325-0001/ Key fingerprint = 5FFA E2D1 6DB5 C023 0C5F 3FA7 4E08 5F9F 1560 0BA8 Home Page: www.geocities.com/wolfgangpfeiffer/ -- END TRANSMISSION -- -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Addendum to FAQ 4.3
On 11 Sep 2002 09:44:26 +0200, Eric Doenges wrote: first a short disclaimer -- I have no idea if this is the correct mailing list, but there seems to be no other way of contacting the fvwm maintainers. If this mail is inapropriate, I'm sorry. Anyway, I have an addendum to FAQ 4.3 I'm seeing odd things when trying to preprocess files with the FvwmM4/Cpp module I was seeing strange things too. On our setup, the main .fvwm2rc file reads a number of different subfiles, some of which were parsed with FvwmM4. This periodically led to a race condition where FvwmM4 was not finished processing before the M4 output was needed elsewhere in the configuration (in our case, the problem was with FvwmButtons being started before the apps to swallow had been started). The fix detailed in FAQ 4.3 did not help (because we were starting other modules), but the solution was surprisingly simple: I replaced all FvmM4 file commands with PipeRead 'm4 file' and everything seems to work now. Well, this may be useful, but it is not the same, none of the X and FVWM related constants are expanded, usual search paths are not used and so on. The real solution to your synchronization problem is to invoke FvwmM4 with the -lock switch. Regards, Mikhael. -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Addendum to FAQ 4.3
On 11 Sep 2002 15:41:08 +0200, Eric Doenges wrote: Mikhael Goikhman wrote: Well, this may be useful, but it is not the same, none of the X and FVWM related constants are expanded, usual search paths are not used and so on. I found that out the hard way shortly after sending my mail (everything seemed to work for me, but broke for some other users =8^(. Fortunately our configuration only uses HOME and USER, which fvwm can expand itself from $HOME and $USER. The real solution to your synchronization problem is to invoke FvwmM4 with the -lock switch. We currently run fvwm-2.2 and fvwm-2.4 (on different Unix variants), but want to have the same configuration files. If you insist not to use any 2.4.x features, we can't help. The support on this list and the FAQ (not counting some non-updated parts) is for 2.4.x. '-lock' seems to be a feature added in version 2.4. Also, if I use '-lock' to read m4-processed files from a .fvwm2rc File, it doesn't seem to do anything (i.e. FvwmM4 -lock file exhibits the same problems FvwmM4 file does). The manual page says to start the module with 'ModuleSynchronous, but the FvwmM4 module itself isn't started anywhere. Yes, I forgot to mention that for -lock to work you should run: ModuleSynchronous FvwmM4 -lock file Regards, Mikhael. -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
