Re: Tracking flag changes from modules
Dominik Vogt wrote: On Tue, Aug 08, 2006 at 04:31:00PM +0100, Thomas Adam wrote: On Tue, 8 Aug 2006 16:18:41 +0100 seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: As a way to provide backward compatibility and minimizing the effects of the above VISIBLE changes there could be provided a command that the modules could use to request an alias. This way the module would parse the command line alias options and request the attribution of an alias. So old configs would still work properly!! :) Strange thing now looking through module_interface.c: there is already a string array called pipeAlias!! Is it possible that the infrastructure is already there?? YES! Strangely enough, the infrastructure is there!! You can actually send commands to specific aliased modules! Just use the module alias instead of the name, and voila! Except pipeAlias is never properly written. It seems that someone started the job but didn't get to finish it. The code is as good as it could be at the time Mikhael wrote it. It's not much more than a hack that tries to guess whether the first argument of a module was intended to be an alias (i.e. not an option etc.). It fails in a number of cases, but we can not do much better without rewriting the interface of some modules. So what could be the solution to the initial problem without any kind of rewrite? There isn't, I'm afraid. I can perfectly understand and see the logic behind why the flags should be sent in the packet information -- however in order for there to be a solution to what you're proposing, it is going to mean a rewrite most likely. This was discussed here on this list a few months ago. If you like I will dig through the on-line archives for you. But there is a soulution. Extend the config win packet with a flag that indicated whether a window can be moved by the user, i.e. the return code of the function that determines whether the window can be moved or not. As a possibility for 3.0, could the module interface be reworked perhaps more extensively? I had an idea for an ICE-based module interface that would, if well done, be more flexible and extensible than the current system. (It's biggest change would be that modules would no longer need to be children of the fvwm process.) It could solve this problem by defining a query-flag operation, with an upward-compatible way of specifying flags. FVWM already links libICE (session management uses it), so this wouldn't add much to the size of the running process. Is the time right to start discussing major changes for 3.0, or should I hold this a while longer?
Re: Tracking flag changes from modules
seventh guardian wrote: On 8/23/06, Jacob Bachmeyer [EMAIL PROTECTED] wrote: As a possibility for 3.0, could the module interface be reworked perhaps more extensively? I had an idea for an ICE-based module interface that would, if well done, be more flexible and extensible than the current system. (It's biggest change would be that modules would no longer need to be children of the fvwm process.) It could solve this problem by defining a query-flag operation, with an upward-compatible way of specifying flags. FVWM already links libICE (session management uses it), so this wouldn't add much to the size of the running process. Is the time right to start discussing major changes for 3.0, or should I hold this a while longer? This may not be the right time to start the final discussion, but I guess no one will complain about us spaming the fvwm mailing list :P As for this discussion, IMHO the best thing to do first is to abstract ourselves from the actual communication method. We first define an interface over a generic bidirectional stream, then we can implement it over any kind of mechanisms. Being it pipes, ICE, DBUS, dynamic loaded libraries, TCP/IP. If we manage to work out a good abstract interface, it wouldn't be hard to implement it using ICE.. I was thinking of using the ICE opcodes in a meaningful manner. A packet-oriented interface, rather than a pure stream, in other words. Since ICE should be available on any system where fvwm is in use, why worry about other mechanisms? (Or am I wrong here?) ICE can use TCP/IP as its transport, so using ICE would give us network transparency if we want it. Dynamic linking into fvwm would mean that a poorly written module could crash fvwm, but it shouldn't be too hard to construct a dynamic shell module that loads an .so and then uses the ICE interface to communicate with fvwm. (Why anyone would want this is another matter.) A similar shell could provide backwards compatibility for older modules. A DBUS interface could be implemented in a similar manner, if a reasonable way to represent fvwm's state to DBUS is devised. This could actually be used in an even more general manner--interface modules could be written for KDE's DCOP and whatever GNOME uses as well. Using ICE would allow us to have one interface in fvwm proper and then have other interfaces atop that one in modules that can be started by the programs that need them. Also, ICE is intended for use underneath an app-layer library. This could help with maintaining the module interface code if we put it in such a library. ICE's protocol is similar to X's, which might also help maintainability. To sum up, ICE presents a (almost) ready-made command-response interface--all we do is define the opcodes and implement the ends. And, if session-management is compiled in, libICE is already in use for that, so we can remove the module interface's transport from fvwm's code and use libICE. Is there something so wrong with ICE that working from scratch rather than using it to abstract the transport is a good idea?
Re: Man page changes - negation method
seventh guardian wrote: On 7/23/06, Jacob Bachmeyer [EMAIL PROTECTED] wrote: seventh guardian wrote: Ok, what about this: Some options are now deactivated by prefixing ! to the option. This will eventually be the default, and the old negative options are now deprecated. This is a list of MenuStyle deprecated negative options: AutomaticHotkeysOff, HilightBackOff, TitleWarpOff It's a bit more conservative, yet should still be useful :) Cheers Renato the default in that could be confusing to new users, how about the preferred form? (default could be taken as all options will be default off.) You're right. But it will not be the preferred method, it will be the only method (hence the other methods being deprecated). Can you find me a word for the only method that fits here? :) Cheers Renato This would be: Some options are now deactivated by prefixing ! to the option. This will eventually be the preferred form, and the old negative forms are now deprecated. Ok, how about: Some options are now deactivated by prefixing ! to the option. This will soon be the preferred form for all such options. Any negatable option for which ! does not work should be reported as a bug. The other negative forms are now deprecated and will be removed in FVWM X.Y.
Re: Man page changes - negation method
seventh guardian wrote: Ok, what about this: Some options are now deactivated by prefixing ! to the option. This will eventually be the default, and the old negative options are now deprecated. This is a list of MenuStyle deprecated negative options: AutomaticHotkeysOff, HilightBackOff, TitleWarpOff It's a bit more conservative, yet should still be useful :) Cheers Renato the default in that could be confusing to new users, how about the preferred form? (default could be taken as all options will be default off.) This would be: Some options are now deactivated by prefixing ! to the option. This will eventually be the preferred form, and the old negative forms are now deprecated.
Re: FVWM: How to use StippledTitleOff
seventh guardian wrote: Lol.. Yes, but how do you specify if its an and or an or? What about the words and and or? The symbols '' and '|' could be supported as well.
Re: CVS griph: fix tempfile vulnerabilities in FvwmCommand (bug
Dominik Vogt wrote:
On Wed, Jul 12, 2006 at 01:28:45AM +0200, Viktor Griph wrote:
but if one are really paranoid one could
add checks of the opened files in FvwmCommand.c to verify that they are
fifos with correect permissions.
Ah, but it's too late if the file is open already.
Is there some reason that fstat({2,P}) isn't usable? It takes an open
file descriptor.
Re: ModuleListenOnly command
Dominik Vogt wrote: On Sun, Jun 25, 2006 at 07:18:30PM +1000, Scott Smedley wrote: Having just looked into how Schedule execute_complex_function() work, I'm not prepared to blame Schedule just yet. In my opinion, I don't think FVWM should grab the X server everytime it executes a complex function. I realise it's necessary when the function references the Motion/Click/Hold/Double modifiers but in the majority of cases, most user functions will just use Immediate. [3] Why must the entire server be grabbed to track mouse movement? Why not grab only the mouse? Also, I use modifiers to have mouse clicks and mouse drags on window frames do different things. (Drag to resize/move, click to raise/lower) Is this why other windows freeze when resizing a window? This makes me think it would have been nice to separate AddToFunc into 2 separate commands - AddToMouseFunc AddToFunc. Where AddToMouseFunc would permit modifiers, AddToFunc would _always_ assume an Immediate modifier. As a hack/compromise, maybe we could modify AddToFunc to keep track of whether or not it uses a mouse modifier only then grab the X server, in execute_complex_function(). We discussed this a couple of years ago, and Olivier(?) suggested to allow functions without grabbing. The problem is that it is generally unpredictable which functions need to grab and which do not, and you can't do it on the fly because its too late then. Is it not possible to determine whether a function must grab as it is defined? Couldn't adding a line with a modifier that needs a grab set a this function might need a grab flag?
