Simulate button press in FvwmButtons, try 2
Looks like Mikhael committed cleaned up version of FvwmButtons so I'm
resubmitting my patch for button press simulation. I cleaned the code up as
requested.
--
George 'Nephrite' Potapov
Index: AUTHORS
===
RCS file: /home/cvs/fvwm/fvwm/AUTHORS,v
retrieving revision 1.112
diff -u -r1.112 AUTHORS
--- AUTHORS 9 Feb 2006 11:49:32 - 1.112
+++ AUTHORS 10 Feb 2006 08:35:19 -
@@ -35,6 +35,7 @@
George Potapov:
ShowOnlyFocused option for FvwmIconMan.
+PressButton command in FvwmButtons
Jim C. Brown:
MailDir option in FvwmTaskBar.
Index: ChangeLog
===
RCS file: /home/cvs/fvwm/fvwm/ChangeLog,v
retrieving revision 1.2669
diff -u -r1.2669 ChangeLog
--- ChangeLog 9 Feb 2006 16:01:26 - 1.2669
+++ ChangeLog 10 Feb 2006 08:35:22 -
@@ -1,3 +1,11 @@
+2006-02-10 George Potapov [EMAIL PROTECTED]
+
+ * modules/FvwmButtons/FvwmButtons.1.in
+ * modules/FvwmButtons/FvwmButtons.c
+ * modules/FvwmButtons/FvwmButtons.h
+ * modules/FvwmButtons/dynamic.c
+ Added command PressButton to module FvwmButtons
+
2006-02-09 Dominik Vogt dominik(dot)vogt(at)gmx(dot)de
* fvwm/menus.c (size_menu_horizontally):
Index: NEWS
===
RCS file: /home/cvs/fvwm/fvwm/NEWS,v
retrieving revision 1.596
diff -u -r1.596 NEWS
--- NEWS9 Feb 2006 11:49:32 - 1.596
+++ NEWS10 Feb 2006 08:35:22 -
@@ -9,6 +9,8 @@
- New MenuStyle options TitleFont, TitleColorset and
HilightTitleBack.
+ - New command PressButton in module FvwmButtons for being able to emulate
+ button press via other means
* Bug Fixes:
Index: modules/FvwmButtons/FvwmButtons.1.in
===
RCS file: /home/cvs/fvwm/fvwm/modules/FvwmButtons/FvwmButtons.1.in,v
retrieving revision 1.2
diff -u -r1.2 FvwmButtons.1.in
--- modules/FvwmButtons/FvwmButtons.1.in27 Feb 2005 07:47:25 -
1.2
+++ modules/FvwmButtons/FvwmButtons.1.in10 Feb 2006 08:35:22 -
@@ -1015,6 +1015,19 @@
above. Command may be any fvwm command with variables $var that
are expanded if supported.
+.IP PressButton \fIbutton_id\fP [\fImouse_button\fP]
+where
+.I button_id
+is the id of the button to press as specified using the
+.B Id
+button option and
+.I mouse_button
+is the number of mouse button used to click on the button e.g 1 for left
+mouse button etc. Quotes around the number is not needed. If
+.I mouse_button
+option is omitted 1 assumed. This command behaves exactly like if
+the button in question was pressed using the mouse.
+
.IP Silent
This prefix may be specified before other actions. It disables
all possible error and warning messages.
Index: modules/FvwmButtons/FvwmButtons.c
===
RCS file: /home/cvs/fvwm/fvwm/modules/FvwmButtons/FvwmButtons.c,v
retrieving revision 1.200
diff -u -r1.200 FvwmButtons.c
--- modules/FvwmButtons/FvwmButtons.c 9 Feb 2006 23:17:05 - 1.200
+++ modules/FvwmButtons/FvwmButtons.c 10 Feb 2006 08:35:23 -
@@ -944,6 +944,114 @@
return b;
}
+void ButtonPressProcess (b, act)
+ button_info *b;
+ char **act;
+{
+ FlocaleNameString tmp;
+ int i,i2;
+
+memset(tmp, 0, sizeof(tmp));
+ if (b !*act b-flags.b_Panel)
+ {
+ ActiveButton = b;
+ HandlePanelPress(b);
+ if (b-newflags.panel_mapped == 0)
+ {
+ if (is_transient)
+ {
+ /* terminate if transient and panel has been
unmapped */
+ exit(0);
+ }
+ else if (is_transient_panel)
+ {
+ XWithdrawWindow(Dpy, MyWindow, screen);
+ }
+ }
+ } /* panel */
+ else
+ {
+ if (!*act)
+ *act=GetButtonAction(b,0);
+ if (b b == CurrentButton *act)
+ {
+ if (strncasecmp(*act,Exec,4) == 0
+ isspace((*act)[4]))
+ {
+
+ /* Look for Exec identifier, in which case
the button
+ stays down until window identifier
materializes */
+ i = 4;
+ while(isspace((unsigned char)(*act)[i]))
+ i++;
+ if((*act)[i] == '')
+ {
+ i2=i+1;
+ while((*act)[i2]!=0 (*act)[i2]!='')
+
Re: Simulate button press in FvwmButtons, try 2
On Fri, Feb 10, 2006 at 11:37:29AM +0300, George 'Nephrite' Potapov wrote:
Looks like Mikhael committed cleaned up version of FvwmButtons so I'm
resubmitting my patch for button press simulation. I cleaned the code up as
requested.
I have committed the patch. Some random comments, but nothing
really important.
* The patch to the Loop() function did not apply to current CVS,
but it was easy to fix.
* You changed the wrong ChangeLog. There is a modules/ChangeLog
file too.
* The mousebutton variable was used uninitialized if
GetQuotedString returned NULL.
* The text length in the NEWS file is limited to 66 characters
(Just stop before the text exceeds the length of the dashed
lines).
* It would be nice to include the funtion names in ChangeLog
entries too. That helps a lot to find out when some bug
appeared. It was pretty easy to do manually with yout patch.
+ rest = GetQuotedString(rest, buttonn, , NULL, NULL, NULL);
+ if (buttonn)
+ {
+ mousebutton = atoi(buttonn);
+ free(buttonn);
+ }
else
{
mousebutton = 1;
}
+ if (mousebutton= 0 ||
+ mousebutton NUMBER_OF_EXTENDED_MOUSE_BUTTONS)
+ mousebutton = 1;
...
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
CVS domivogt: * Applied ButtonPress patch.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt06/02/10 06:33:22 Modified files: . : AUTHORS ChangeLog NEWS fvwm : module_interface.c libs : PictureBase.c modules: ChangeLog modules/FvwmButtons: FvwmButtons.1.in FvwmButtons.c FvwmButtons.h dynamic.c modules/FvwmSave: FvwmSave.1.in Log message: * Applied ButtonPress patch.
CVS domivogt: * Removed accidentally committed FVWM_MODULE_ALIAS patch.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt06/02/10 06:35:24 Modified files: . : ChangeLog fvwm : module_interface.c Log message: * Removed accidentally committed FVWM_MODULE_ALIAS patch.
Re: Simulate button press in FvwmButtons, try 2
On Fri, Feb 10, 2006 at 01:29:18PM +0100, Dominik Vogt wrote: * The patch to the Loop() function did not apply to current CVS, but it was easy to fix. Oops, I just forgot to update from CVS first. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
FVWM in the session screen
Hi, I'm running RedHat3 WS U6 on my desktop. How do I configure the session in the Login screen to be able to choose FVWM also ( now the user can choose KDE and GNOME only ). I build the fvwm-2.4.19-1.src.rpm. Best Regards, Mati
Re: Module.h bug and sugestion
Dominik Vogt [EMAIL PROTECTED] writes: The -audio option and invoking it as FvwmAudio is the result or merging the old FvwmAudio module back into FvwmEvent. It was once split from FvwmEvent (I think) and shared most of the code. Probably FvwmAudio did not support module aliases, so there is no mode to have both. FvwmAudio was written long before FvwmEvent. Like some of other modules, it never needed aliases. -- Dan Espen E-mail: [EMAIL PROTECTED]
Re: Module.h bug and sugestion
On 22:24 Thu 09 Feb , Dominik Vogt wrote: On Thu, Feb 09, 2006 at 04:08:00PM +, seventh guardian wrote: On 2/9/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Thu, Feb 09, 2006 at 03:32:44PM +, seventh guardian wrote: On 2/9/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Wed, Feb 08, 2006 at 02:05:14PM +, seventh guardian wrote: I've committed the patch to CVS (and removed the FARGS macro from FvwmConsole). For further patches, please always add a list of modified functions to the ChangeLog after the name of the .c file. This simplifies maintenance enormously. Here goes a second patch. I've added the list of modified functions after the file name, except for the main function. I followed the style of some of your entries in the changelogs, hope I've done it ok. Actually, its not my personal style but what xemacs (and emacs?) generate when you move the cursor into a function and the press ctrl-x 4 a. (Unfortunately more recent versions of xemacs changed the style of the function list which makes it more difficult to grep through it. As you said once, the command line syntax isn't going to change that much, even for 3.0. But even so, some coding styles make it difficult to use properly the ParseModuleArgs (or functions alike) regarding the module aliases. I wonder if there could be fixed a standard for aliases. I mean a true standard that modules using aliases should follow. The argv[6] rule would be ok, but it would break some config files. Obviosly some kind of wrapper could be used to avoid those breakings, like in FvwmRearrange. I wonder what you think about this. The one problem with that approach is that such a change would break all third-party modules. Hum, you're right. What about making the change only for official modules, those using Module.h? Hm, what about passing the module alias as an environment variable? It's ugly, but we're already doing it with FVWM_VISUALID and FVWM_COLORMAP. An FVWM_MODULE_ALIAS wouldn't do further harm. However, this doesn't solve the syntax issue on the fvwm side. What can we do about invocations like FvwmButtons ColourTable (right from my config file)? Okay, let's see how big the mess is: 1) Modules that currently support the syntax modulename [alias] without further command line args: Animate, CommandS, Form, Gtk, IconBox, TaskBar 2) Modules which do not accept any command line options, icluding aliases: Backer, DragWell, Ident, Proxy, Save, SaveDesk, Scroll, Theme, Wharf 3) Modules which do not have any config lines: Auto, Save, SaveDesk 4) Modules which only accept command line options beginning with '-': Console, Debug, GtkDebug, Rearrange, Tabs 5) Modules which accept a list of '-' options followed by a single argument that does not begin with '-' (and is not an alias): Cpp, M4 6) Modules that accept a single non-alias argument: Banner, Script 7) Weird cases: * Buttons Possible arguments are ['-'options] [alias] [cfgfile] Iterates over its arguments. For each argument it checks if it's an option with '-' first. If not (or the same option was encountered earlier), it's taken as the alias. If the alias is already define, it's taken as the cfgfile. If the cfgfile is already defined, it's ignored. YUCK! * OldDebug Can be invoked as one of OldDebug OldDebug alias OldDebug -v OldDebug -v alias OldDebug alias -v YUCK! * Event Can be invoked as one of Event Event -audio Event alias * IconMan Can be invoked as IconMan IconMan alias IconMan transient IconMan -transient IconMan transient alias IconMan -transient alias * Pager Same as IconMan, but may be followed by one or two desk numbers or asterisks. * Perl Can be invoked as Perl ['-'options] [alias] * WindowMenu Takes options without a '-' prefix but no alias. * WindowList Same as IconMan. Classes (2) and (3) are no problem at all while (1), (4) and (5) are relatively easy to cope with. Class (6) modules are broken at the moment, i.e. it's not possible to kill them with KillModule Modulename because their argument is interpreted as an alias name. WindowMenu, Tabs and Perl are new in 2.5.x, so we can change their interface without worrying about incompatibilities. Event and Perl have the alias name at the end of their option Any ideas for a clean interface that breaks only configs that are really weird? How about factoring the alias mechanism away from the module alias? You could have a command: AliasModule module-name alias [ alias ... ] This
Re: FVWM in the session screen
On 2/10/06, Giladi Mati-R57914 [EMAIL PROTECTED] wrote: Hi, I'm running RedHat3 WS U6 on my desktop. How do I configure the session in the Login screen to be able to choose FVWM also ( now the user can choose KDE and GNOME only ). I build the fvwm-2.4.19-1.src.rpm. Best Regards, Mati Please don't space your text that much. Also, this is _not_ the list to ask that. You should have tried the fvwm list first, (not the workers list), but in any case this has _nothing_ to do with fvwm. It's the entire responsability of your distro. Anyway, you could put #!/bin/bash /usr/bin/fwm2 in the file /etc/X11/Sessions/fvwm2 and make it executable. I have no idea if this applies to kdm though.. Please consult KDE's documentation. And please use google _before_ posting this kind of things in any mailing list. Cheers Renato Caldas
Re: Module.h bug and sugestion
On 10 Feb 2006 08:35:04 +0100, Dominik Vogt wrote: On Fri, Feb 10, 2006 at 01:19:26AM +, seventh guardian wrote: Then we have two options: - Modules don't pass a matching string to fvwm and fvwm is entirely responsible of the module's aliases. - Modules continue to pass the matching string and fvwm translates it if an alias is defined in the core. Hm, would that break the old way FvwmIconMan requested its config liens? I mean *FvwmIconMan*1*foobar ... Instead of the new *FvwmIconMan: 1 foobar ... Or is that completely transparent to the modules? Mikhael? The second line is unfortunately (for backward compatibility with all other modules parsing their config) is sent as: *FvwmIconMan1 foobar ... FvwmIconMan simply supports 2 formats, old with *, and without *. Similarly, FvwmButtons config that looks like: *MyButtons: Frame 5 *MyButtons: (Container) is sent (again, for backward compatibility) as: *MyButtonsFrame 5 *MyButtons(Container) At least DestroyModuleConfig MyButtons: Width and DestroyModuleConfig MyButtons: * do the right thing, i.e. do not affect lines of another alias *MyButtonsFrame: Title my-frame. Of corse, the correct thing is to introduce MX_MODULE_CONFIG packet and new rules (a module may request from the core a config related to the module name, say FvwmScript, or related to its alias, say FvwmButtons, or both, say FvwmForm) and to send the config lines without any prefix. This requires rewrite of all modules and the core. Not before 2.6. Regards, Mikhael.
Re: Module.h bug and sugestion
On 10 Feb 2006 08:25:41 +, Nick Fortune wrote: How about factoring the alias mechanism away from the module alias? You could have a command: AliasModule module-name alias [ alias ... ] This way instead of writing DestroyModuleConfig MonitorPanel: * *MonitorPanel: (1x1, Swallow 'asclock' 'Exec exec asclock') # ... AddToFunc StartFunction + I Module FvwmButtons MonitorPanel You'd write AliasModule FvwmButtons MonitorPanel DestroyModuleConfig MonitorPanel *MonitorPanel: (1x1, Swallow 'asclock' 'Exec exec asclock') # ... AddToFunc StartFunction + I Module MonitorPanel Which seems a little clearer. That way we get to remove the alias from the module arguments, we can deprecate the old usage, and third party modules don't have to use it. For the module side of the operation, I'd pass it in the environment as already suggested. We get a migration path to a cleaner syntax, and we don't have to break anything. This is an option to consider, before redesigning the module interface. However, this syntax will require 2 lines for launching every module, AliasModule and Module, instead of just Module. And we also need UnaliasModule. I.e. now the user should predeclare all module instances he wants to use. I should rething this idea first before agreeing or disagreeing with it. Regards, Mikhael.
Re: Module.h bug and sugestion
On 2/10/06, Mikhael Goikhman [EMAIL PROTECTED] wrote: On 10 Feb 2006 08:35:04 +0100, Dominik Vogt wrote: On Fri, Feb 10, 2006 at 01:19:26AM +, seventh guardian wrote: Then we have two options: - Modules don't pass a matching string to fvwm and fvwm is entirely responsible of the module's aliases. - Modules continue to pass the matching string and fvwm translates it if an alias is defined in the core. Hm, would that break the old way FvwmIconMan requested its config liens? I mean *FvwmIconMan*1*foobar ... Instead of the new *FvwmIconMan: 1 foobar ... Or is that completely transparent to the modules? Mikhael? The second line is unfortunately (for backward compatibility with all other modules parsing their config) is sent as: *FvwmIconMan1 foobar ... FvwmIconMan simply supports 2 formats, old with *, and without *. Similarly, FvwmButtons config that looks like: *MyButtons: Frame 5 *MyButtons: (Container) is sent (again, for backward compatibility) as: *MyButtonsFrame 5 *MyButtons(Container) At least DestroyModuleConfig MyButtons: Width and DestroyModuleConfig MyButtons: * do the right thing, i.e. do not affect lines of another alias *MyButtonsFrame: Title my-frame. Of corse, the correct thing is to introduce MX_MODULE_CONFIG packet and new rules (a module may request from the core a config related to the module name, say FvwmScript, or related to its alias, say FvwmButtons, or both, say FvwmForm) and to send the config lines without any prefix. This requires rewrite of all modules and the core. Not before 2.6. I'm forced to agree, but when will 2.6 come out? I happende to step on this when I was trying the wiki: DV What about the future? Well, the work for the next stable series DV (2.6.x) is proceeding very well. Fvwm will go into feature freeze DV again near the end of the year so that 2.6 is ready before fvwm's DV tenth birthday on 1st of June, 2003. I have vague plans for a DV big event on that day to remind people that fvwm is still there DV and that it can easily compete with any other window manager. DV After that there are plans for a version 3.0 that would change a DV lot of the syntax and introduce fantastic new features, but that's DV too far from now. It has been a long time, and there are no major bugs now. Can we proceed to the next level? Cheers Renato Caldas
Re: Module.h bug and sugestion
On Fri, Feb 10, 2006 at 05:03:09PM +, seventh guardian wrote: I happende to step on this when I was trying the wiki: DV What about the future? Well, the work for the next stable series DV (2.6.x) is proceeding very well. Fvwm will go into feature freeze DV again near the end of the year so that 2.6 is ready before fvwm's DV tenth birthday on 1st of June, 2003. I have vague plans for a DV big event on that day to remind people that fvwm is still there DV and that it can easily compete with any other window manager. DV After that there are plans for a version 3.0 that would change a DV lot of the syntax and introduce fantastic new features, but that's DV too far from now. It has been a long time, and there are no major bugs now. Can we proceed to the next level? It's just a matter of doing the tedious work, and it looks like nobody has the time to do it right now. We have a todo-2.6 that lists all the open issues, but that is several years old and needs updating. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
todo-2.6: E6 - rename FvwmProxy
Hi. After giving a look at the todo-2.6 list I got curious about what FvwmProxy actually does, and the name is a bit misleading. It's so nice I've just binded SendToModule FvwmProxy ShowToggle to the Super_L key. Anyway, on that list there's the entry E6, saying FvwmProxy should be renamed. I agree, and suggest FvwmWinTag. PS: I'm trying to give a kick-start to the 2.6 process. Cheers, Renato Caldas
Re: todo-2.6: E6 - rename FvwmProxy
On Fri, Feb 10, 2006 at 05:45:21PM +, seventh guardian wrote: Anyway, on that list there's the entry E6, saying FvwmProxy should be renamed. I agree, and suggest FvwmWinTag. I'm indifferent. Proxy makes sense to me in this case -- they're proxy windows that are bound to the current windows on the screen. -- Thomas Adam -- I've been too honest with myself, I should have lied like everybody else.
Re: todo-2.6: E6 - rename FvwmProxy
On 2/10/06, Thomas Adam [EMAIL PROTECTED] wrote: On Fri, Feb 10, 2006 at 05:45:21PM +, seventh guardian wrote: Anyway, on that list there's the entry E6, saying FvwmProxy should be renamed. I agree, and suggest FvwmWinTag. I'm indifferent. Proxy makes sense to me in this case -- they're proxy windows that are bound to the current windows on the screen. In any case, we either decide to change it or remove the entry from the todo-2.6 file. I've given my suggestion, but it's not my call. Let's start cleaning up the todo list :) Cheers, Renato Caldas
Re: todo-2.6: E6 - rename FvwmProxy
On 10 Feb 2006 18:06:55 +, Thomas Adam wrote: On Fri, Feb 10, 2006 at 05:45:21PM +, seventh guardian wrote: Anyway, on that list there's the entry E6, saying FvwmProxy should be renamed. I agree, and suggest FvwmWinTag. I'm indifferent. Proxy makes sense to me in this case -- they're proxy windows that are bound to the current windows on the screen. A name like FvwmWindowLabels or FvwmProxyWindows makes even more sense. Please everyone who cares vote: http://fvwm.lair.be/viewtopic.php?t=1202 Regards, Mikhael.
CVS migo: * spell check the man page and FAQ
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: migo06/02/10 16:12:57 Modified files: . : ChangeLog docs : COMMANDS ChangeLog FAQ fvwm : fvwm.1.in perllib: ChangeLog perllib/FVWM : Commands.pm Log message: * spell check the man page and FAQ * regenerate the list of fvwm commands (one new command in 2.5 years)
Adding a Shift command
Seeing that there has only been one new command in the last 2.5 years I think it was time to add another. ;) I think that a parameter shifting command for use in functions could be useful. It could be used for small recursive (yes I know, that would not be very efficient) function calls: AddToFunc Inline + I $0 + I Shift + I Inline $* A sample call of the above would be Function Inline WindowStyle !Title, !Borders, !Handles UpdateStyles \ Maximize 100 100 Break Appart from that it would also provide meanns to get direct access to positional paramiters after $9. Thoughts? Is this something that anyone but me would use? /Viktor
Re: Adding a Shift command
On 10 Feb 2006 23:34:15 +0100, Viktor Griph wrote: Seeing that there has only been one new command in the last 2.5 years I think it was time to add another. ;) No, it means it is a time to spend all energy on releasing 2.6. :) Then any number of new commands and new features may be added. I think that a parameter shifting command for use in functions could be useful. It could be used for small recursive (yes I know, that would not be very efficient) function calls: AddToFunc Inline + I $0 + I Shift + I Inline $* A sample call of the above would be Function Inline WindowStyle !Title, !Borders, !Handles UpdateStyles \ Maximize 100 100 Break Appart from that it would also provide meanns to get direct access to positional paramiters after $9. Thoughts? Is this something that anyone but me would use? There is a problem with variables looking like $X on the command line. I don't know whether we should absolete $0 .. $9 and $. plus $*. Maybe not. But at least, as the first step we may start to support $[0], $[12]. As well as $[2-5] (four arguments starting from the third, space separated). This, together with the filter/quoting suggestion for all variables http://www.mail-archive.com/fvwm-workers@hpc.uh.edu/msg05721.html should make your Shift command redundant. Regards, Mikhael.
Re: todo-2.6: E6 - rename FvwmProxy
On Fri, Feb 10, 2006 at 08:10:33PM +, Mikhael Goikhman wrote: On 10 Feb 2006 18:06:55 +, Thomas Adam wrote: On Fri, Feb 10, 2006 at 05:45:21PM +, seventh guardian wrote: Anyway, on that list there's the entry E6, saying FvwmProxy should be renamed. I agree, and suggest FvwmWinTag. I'm indifferent. Proxy makes sense to me in this case -- they're proxy windows that are bound to the current windows on the screen. A name like FvwmWindowLabels or FvwmProxyWindows makes even more sense. Please everyone who cares vote: http://fvwm.lair.be/viewtopic.php?t=1202 Although I don't want any more modules that begine with FvwmWin, FvwmWindowLabels is a good name. I'd even vote if the confirmation email for registering on the forum ever arrives (probably never). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Module.h bug and sugestion
On 2/10/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Fri, Feb 10, 2006 at 05:03:09PM +, seventh guardian wrote: I happende to step on this when I was trying the wiki: DV What about the future? Well, the work for the next stable series DV (2.6.x) is proceeding very well. Fvwm will go into feature freeze DV again near the end of the year so that 2.6 is ready before fvwm's DV tenth birthday on 1st of June, 2003. I have vague plans for a DV big event on that day to remind people that fvwm is still there DV and that it can easily compete with any other window manager. DV After that there are plans for a version 3.0 that would change a DV lot of the syntax and introduce fantastic new features, but that's DV too far from now. It has been a long time, and there are no major bugs now. Can we proceed to the next level? It's just a matter of doing the tedious work, and it looks like nobody has the time to do it right now. We have a todo-2.6 that lists all the open issues, but that is several years old and needs updating. Here goes the 3rd patch (maybe the last), for the work I've done until yesterday. I will put this project on hold now, and see if I can help bringing 2.6 to life. Cheers, Renato Caldas patch3.patch Description: Binary data
EdgeScroll and pixel steps
Currently EdgeScroll divides pixel steps1000 by 1000 and enables wrap. I belive this to be a bug (and is reportd as sush (#3162)). However, it is useful to allow for warps when using pixel steps as well, so just removing that ability is no good solution. One possible solution would be to add another way of specifying wraps to the syntax, and make it the required method for pixel sizes (or change the check with pixels so that the size has to be larger than the screen width, and an even multiplicand of 1000, in order for division to take place (for compability with configs using for example EdgeScroll 1024000p 768000p)). I can think of several possible syntaxes, and can't decide on which one is best. One can either add a prefix (or another suffix) option 'w' to the individual coordinates. (w1024p or (1024pw or 1024wp)), or one can add optional keywords to the EdgeScroll syntax after the step parameters. (i.e. EdgeScroll 1024p 768p wrap|wrapx|wrapy) /Viktor
Re: EdgeScroll and pixel steps
On 11 Feb 2006 00:50:13 +0100, Viktor Griph wrote: Currently EdgeScroll divides pixel steps1000 by 1000 and enables wrap. I belive this to be a bug (and is reportd as sush (#3162)). However, it is useful to allow for warps when using pixel steps as well, so just removing that ability is no good solution. One possible solution would be to add another way of specifying wraps to the syntax, and make it the required method for pixel sizes (or change the check with pixels so that the size has to be larger than the screen width, and an even multiplicand of 1000, in order for division to take place (for compability with configs using for example EdgeScroll 1024000p 768000p)). I think the intention was to only divide the percentage values by 1000 (the ones without p suffix). This is also what the man page says. So, EdgeScroll 1024p 768p should be fixed not to wrap. I can think of several possible syntaxes, and can't decide on which one is best. One can either add a prefix (or another suffix) option 'w' to the individual coordinates. (w1024p or (1024pw or 1024wp)), or one can add optional keywords to the EdgeScroll syntax after the step parameters. (i.e. EdgeScroll 1024p 768p wrap|wrapx|wrapy) The last option seems better to me, although I don't think this is really needed, anyone may achieve this now if he specifies 100% or 50%. Regards, Mikhael.
CVS migo: add specification of fvwm variables
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: migo06/02/10 19:08:23 Modified files: docs : ChangeLog Added files: docs : todo-vars Log message: add specification of fvwm variables
On module names and aliases
On 10 Feb 2006 16:48:49 +, Mikhael Goikhman wrote: On 10 Feb 2006 08:25:41 +, Nick Fortune wrote: You'd write AliasModule FvwmButtons MonitorPanel DestroyModuleConfig MonitorPanel *MonitorPanel: (1x1, Swallow 'asclock' 'Exec exec asclock') # ... AddToFunc StartFunction + I Module MonitorPanel This is an option to consider, before redesigning the module interface. However, this syntax will require 2 lines for launching every module, AliasModule and Module, instead of just Module. And we also need UnaliasModule. I.e. now the user should predeclare all module instances he wants to use. I should rething this idea first before agreeing or disagreeing with it. Another serious problem with this suggestion is that now we start to manipulate with strings like ColourTable or MonitorPanel and have no any idea whether they are actually FvwmButtons, FvwmForm, FvwmScript, FvwmGtk or maybe even FvwmEvent. And these are very different modules with different configuration syntaxes and command line options. Several years ago I had and still have the following idea in mind, that seems to solve all problems. However it applies a restriction on the module alias name. And this is its only drawback. The alias name (or more correctly the module id) is anything that is modulename-subname. I.e. FvwmScript-ClockMonitor or FvwmForm-Talk. Now, a module should receive subname and not alias as we know it. Then this module id is used everywhere straightforwardly: Module FvwmButtons-Monitor -g 240x360 KillModule FvwmButtons-Monitor SendToModule FvwmButtons-Monitor PressButton 2 *FvwmButtons-Monitor: Colorset 1 I think, this syntax is pretty clean and self-descriptive. If a module does not accept multiple instances, then it may still be accessible as FvwmBanner (with no subname needed). The FvwmForm and FvwmScript configurations shipped with fvwm already follow this naming scheme. As well as all modules in fvwm-themes. I currently don't see a better solution for module ids. Regards, Mikhael.
Re: On module names and aliases
On 2/11/06, Mikhael Goikhman [EMAIL PROTECTED] wrote: On 10 Feb 2006 16:48:49 +, Mikhael Goikhman wrote: On 10 Feb 2006 08:25:41 +, Nick Fortune wrote: You'd write AliasModule FvwmButtons MonitorPanel DestroyModuleConfig MonitorPanel *MonitorPanel: (1x1, Swallow 'asclock' 'Exec exec asclock') # ... AddToFunc StartFunction + I Module MonitorPanel This is an option to consider, before redesigning the module interface. However, this syntax will require 2 lines for launching every module, AliasModule and Module, instead of just Module. And we also need UnaliasModule. I.e. now the user should predeclare all module instances he wants to use. I should rething this idea first before agreeing or disagreeing with it. Another serious problem with this suggestion is that now we start to manipulate with strings like ColourTable or MonitorPanel and have no any idea whether they are actually FvwmButtons, FvwmForm, FvwmScript, FvwmGtk or maybe even FvwmEvent. And these are very different modules with different configuration syntaxes and command line options. Several years ago I had and still have the following idea in mind, that seems to solve all problems. However it applies a restriction on the module alias name. And this is its only drawback. The alias name (or more correctly the module id) is anything that is modulename-subname. I.e. FvwmScript-ClockMonitor or FvwmForm-Talk. Now, a module should receive subname and not alias as we know it. Then this module id is used everywhere straightforwardly: Module FvwmButtons-Monitor -g 240x360 KillModule FvwmButtons-Monitor SendToModule FvwmButtons-Monitor PressButton 2 *FvwmButtons-Monitor: Colorset 1 I think, this syntax is pretty clean and self-descriptive. If a module does not accept multiple instances, then it may still be accessible as FvwmBanner (with no subname needed). The FvwmForm and FvwmScript configurations shipped with fvwm already follow this naming scheme. As well as all modules in fvwm-themes. I currently don't see a better solution for module ids. I like the idea, and it's definitely as clean as it can be. Also, aliases are exclusive to the configuration, and not visible in daily use. So there's really no drawback. I have one question though: how is this meant to be aplied? Is it pre- or post-2.6?
