Re: matchVersion() compile problems
Hi Dominik, :)
To avoid problems with comiling / reading the fvwm sources, please
* adhere to the ANSI-C 88 standard, not the new one.
Specifically,
- Don't use C++-like comments with //
- Declare variables only at the beginning of a block.
* limit your lines to 79 characters (if possible, do not use 80
characters - I can't get xemacs to start with 80 columns, it
either has 79 or 81 because of the font I use).
Sure. No problem.
* Please put single statements in loops or if clauses in curly
braces, i.e.
if (1)
{
foo;
}
not
if (1)
foo;
What's the rationale behind this? I must confess I'm not particularly fond
of this restriction but I will, of course, follow any FVWM coding standards.
SCoTT. :)
--
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: matchVersion() compile problems
* Please put single statements in loops or if clauses in curly
braces, i.e.
if (1)
{
foo;
}
not
if (1)
foo;
What's the rationale behind this? I must confess I'm not particularly fond
of this restriction but I will, of course, follow any FVWM coding standards.
From docs/CONVENTIONS:
o Always place curly braces on a separate line. In some cases,
placing braces on the same line as other code confuses
(x)emacs.
Wouldn't it be prudent to fix Emacs?
(That's an honest question, not trying to start an xemacs-vs-gvim war.)
SCoTT.
--
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 scott: FvwmButtons eye candy.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: scott 04/07/10 04:13:25 Modified files: . : ChangeLog NEWS modules: ChangeLog modules/FvwmButtons: FvwmButtons.1 FvwmButtons.c FvwmButtons.h button.c draw.c dynamic.c icons.c icons.h parse.c Log message: FvwmButtons eye candy. New FvwmButtons options: HoverColorset, HoverIcon HoverTitle options. Also possible to ChangeButton Icon/Title if originally no icon/title specified. -- 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: matchVersion() compile problems
Scott Smedley [EMAIL PROTECTED] writes:
* Please put single statements in loops or if clauses in curly
braces, i.e.
if (1)
{
foo;
}
not
if (1)
foo;
What's the rationale behind this? I must confess I'm not particularly fond
of this restriction but I will, of course, follow any FVWM coding standards
.
o Always place curly braces on a separate line. In some cases,
placing braces on the same line as other code confuses
(x)emacs.
Wouldn't it be prudent to fix Emacs?
(That's an honest question, not trying to start an xemacs-vs-gvim war.)
I don't think Emacs has anything to do with it.
As far as I can tell, Emacs has no problems with either format.
Certainly someone would submit a bug report if there was a problem.
I think the above choices are personal preference.
Personally, I like curly braces to NOT take an extra line.
There are sound arguments to be made on both sides.
This is what I put in my .emacs to allow Emacs to follow the
fvwm standard for fvwm work, and for me to use my own rules for
everything else:
;set my defaults for c
(defun my-c-mode-hook ()
(if (string-match fvwm buffer-file-name) ;fvwm project settings:
(progn
(setq
c-indent-level 8
c-basic-offset 8
c-brace-offset 0
c-continued-brace-offset 0
c-brace-imaginary-offset 0
c-continued-statement-offset 0
c-label-offset 0
c-argdecl-indent 0
c-auto-newline nil
c-tab-always-indent t
indent-tabs-mode t)
(c-set-offset 'substatement-open 0))
;; Local site default settings
(setq
c-indent-level 2
c-basic-offset 2
c-brace-offset 0
c-continued-brace-offset 0
c-brace-imaginary-offset 0
c-continued-statement-offset 2
c-label-offset -2
c-argdecl-indent 0
c-auto-newline nil
c-tab-always-indent t
indent-tabs-mode nil
comment-column 40)))
(add-hook 'c-mode-hook 'my-c-mode-hook t)
--
Dan Espen E-mail: [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]
CVS scott: More FvwmButtons eye candy.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: scott 04/07/10 12:35:44 Modified files: modules: ChangeLog modules/FvwmButtons: FvwmButtons.1 FvwmButtons.c FvwmButtons.h button.c draw.c icons.c parse.c Log message: More FvwmButtons eye candy. PressColorset, PressIcon PressTitle options. Don't utilise Hover options when button is selected. -- 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: Patch to allow multiple window names in conditions
Mikhael Goikhman [EMAIL PROTECTED] wrote:
Like other posters, I don't quite like that names are sudently work
using logical OR while all other options in conditional commands work
using logical AND. And the nagations of names work using AND again.
Here is the proposal that should solve all these ambiguities, but it is
a bit backward incompatible in that one character is treated specially.
I don't think there is any fvwm user that has a conditional in his config
that will be broken however, so this is mostly the theoretical problem.
1) All condition options always work using logical AND, as usual.
2) Any option is either keyword or window name/resource/class, as usual.
3) Options (with possible argument) are separated by commas, as usual.
4) In the future we will have (Name name1, Class name2) syntax.
5) The leading character ! means logical NOT of that option, as usual.
6) Any name may contain a spacial character | meaning logical OR.
Here are examples:
Next (Netscape|konqueror|Mozilla*) WarpToWindow 99 90 # go to browser
All (CurrentPage, xterm|rvxt, !Iconified) Iconify # iconify terminals
Next (!FvwmPager|FvwmForm*|FvwmButtons) Raise # raise next non-module
Next (!FvwmPager, !FvwmForm*, !FvwmButtons) Raise
The last 2 commands are equivalent. So basically, we don't really need
to support more than one name options like in the last example. I am
not against to add such extended support though.
I think this syntax naturally extends the current syntax and allows most
of the logical expressions a user may want to have. This can't be said
about the original proposed syntax.
Thanks for the proposal. I was contemplating adding full boolean
expressions, but looking at the code, that gets a bit complicated if
backwards compatibility is to be preserved. The code change required by
your proposal is not much bigger than my original patch; and it doesn't
have the user interface weirdness that mine did. So I implemented it.
Here's the patch:
Index: ChangeLog
===
RCS file: /home/cvs/fvwm/fvwm/ChangeLog,v
retrieving revision 1.2518
diff -u -u -r1.2518 ChangeLog
--- ChangeLog 10 Jul 2004 09:13:25 - 1.2518
+++ ChangeLog 10 Jul 2004 17:47:13 -
@@ -1,3 +1,11 @@
+2004-07-10 Norman Yarvin [EMAIL PROTECTED]
+
+ * fvwm/conditional.c:
+ * fvwm/fvwm.h:
+ * fvwm/fvwm.1.in:
+ modified the code for conditions so that multiple window names may
+ be specified in each condition
+
2004-07-09 Dominik Vogt [EMAIL PROTECTED]
* fvwm/module_interface.c (CONFIGARGS):
Index: fvwm/conditional.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/conditional.c,v
retrieving revision 1.95
diff -u -u -r1.95 conditional.c
--- fvwm/conditional.c 8 Jul 2004 10:08:09 - 1.95
+++ fvwm/conditional.c 10 Jul 2004 17:47:14 -
@@ -376,22 +376,31 @@
}
/*
- * The name field of the mask is allocated in CreateConditionMask.
+ * The name_condition field of the mask is allocated in CreateConditionMask.
* It must be freed.
* NOTE - exported via .h
*/
void FreeConditionMask(WindowConditionMask *mask)
{
- if (mask-my_flags.needs_name)
- {
- free(mask-name);
- }
- else if (mask-my_flags.needs_not_name)
+ struct name_condition *pp,*pp2;
+ struct namelist *p,*p2;
+
+ for (pp=mask-name_condition; pp; )
{
- free(mask-name - 1);
+ for (p=pp-namelist; p; )
+ {
+ p2=p-next;
+ if(!p2)
+ {
+ free(p-name - (pp-invert ? 1 : 0));
+ }
+ free(p);
+ p=p2;
+ }
+ pp2=pp-next;
+ free(pp);
+ pp=pp2;
}
-
- return;
}
/* Assign the default values for the window mask
@@ -614,21 +623,36 @@
}
mask-my_flags.needs_same_layer = on;
}
- else if (!mask-my_flags.needs_name
-!mask-my_flags.needs_not_name)
- {
- /* only 1st name to avoid mem leak */
- mask-name = condition;
- condition = NULL;
- if (on == 0)
- {
- mask-my_flags.needs_not_name = 1;
- mask-name++;
- }
- else
- {
- mask-my_flags.needs_name = 1;
+ else
+ {
+ struct name_condition *pp;
+ struct namelist *p;
+ char *condp;
+
+ pp = (struct name_condition *)
+
CVS domivogt: * Reordered ConfigWinPacket members.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt04/07/10 15:03:21 Modified files: . : ChangeLog fvwm : module_interface.c libs : vpacket.h Log message: * Reordered ConfigWinPacket members. -- 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]
ôé÷ðèé ìà úñìç ôùòé ä÷øèì ìãéï !!
http://www.readme.co.il/pikanti/index.html -- 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: matchVersion() compile problems
On Sat, Jul 10, 2004 at 06:42:24PM +1000, Scott Smedley wrote:
* Please put single statements in loops or if clauses in curly
braces, i.e.
if (1)
{
foo;
}
not
if (1)
foo;
What's the rationale behind this? I must confess I'm not particularly fond
of this restriction but I will, of course, follow any FVWM coding standards.
Maintenance. It is easy to forget to add the curly braces when
you add another statement to a branch, at least if your editor
does not automatically indent the code. There's not much else
behind it.
From docs/CONVENTIONS:
o Always place curly braces on a separate line. In some cases,
placing braces on the same line as other code confuses
(x)emacs.
Wouldn't it be prudent to fix Emacs?
The question is: who is going to do it? I don't know how to fix
it. One case in which xemacs misbehaves is when you have such a
function:
void foo(void) {
...
}
If you press C-x 4 a to generate a ChangeLog entry, it does not
find the function's name. That does not affect code inside the
functions. Personally
* I don't like braces on a code line because I have difficulties
to find the matching closing brace if it's not in the same
column.
* I don't care much about code in places I rarely look at, but if
I see such code in the files I maintain most of the time (most
of the fvwm core), I reformat it.
(That's an honest question, not trying to start an xemacs-vs-gvim war.)
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
pgpZ6tDOfHnoh.pgp
Description: PGP signature
Re: Changes in module interface
On Sat, Jul 10, 2004 at 12:42:52AM +, Mikhael Goikhman wrote: At least one change (order of arguments in CONFIGURE_WINDOW) is bad. The flags are of the variable size and thus should be last. I can change that. But why are the flags variable size? If you ever change any event arguments, please update file perllib/FVWM/EventNames.pm (including format, names and types of the event args), or tell me to update. Testing all modules that use that event would be nice too. What's an event argument? Do you mean module messages? BTW, I am really unhappy with the new flags method that is pretty much C-only. Modules that can't embed the .h data structure simply can't use window flags. The old method with positioned word-based properties rather than compiler dependent bit-based flags was more robust. Yes, the compiler dependent structure layout is a bad idea. One should never map C structures to the network. Currently a module should be in C and should be compiled by the same compiler with the same options, otherwise it may not get window flags correctly... I don't have a good solution here. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] pgpC78YqF1M0R.pgp Description: PGP signature
Re: -Meta_L
On Tue, Jul 06, 2004 at 10:58:11PM -0700, Jason Weber wrote: On Tue, Jul 06, 2004 at 11:32:49AM +0200, Dominik Vogt wrote: On Mon, Jul 05, 2004 at 11:43:25AM -0700, Jason Weber wrote: Maybe I need an example. Do you mean to deactivate it or change the command string dynamically? No, I meant to tell FvwmProxy * Which modifier key to watch for Can do. * If FvwmProxy should be aborted when the key is released or if the selected window whould be activated That's what the 'command' does, presumably Hide or Abort. Going back to your original example, to tag it onto Show, I'd also have to tag it onto Next, Prev, ShowToggle, and Circulate. Why? You only need to tell FvwmProxy once when it's initially activated. Well, I suggest we start with the basics: * Add the code to configure the modifier to release via a module config line. * Add the code to watch for the modifier release and take the appropriate action. Once this is done, we can think more about the fvwm/FvwmProxy interface. I assume the picture gets clearer when we have some code to look at. And aside from the repetition, that gets pretty ugly on Circulate because it auto-appends SendToModule FvwmProxy Mark. Key Tab A M SendToModule FvwmProxy Circulate \ ScanForWindow East South (CurrentPage !Sticky) some delimiter? \ OnModifierRelease M SendToModule FvwmProxy Hide If it's not different per each activation method, it seems flexible enough to do *FvwmProxy: Action ModifierRelease M SendToModule FvwmProxy Hide Otherwise, Circulate gets too messy and I would expect we would have to force people to use a bunch of functions AddToFunc CirculateForward + I SendToModule FvwmProxy ScanForWindow East South (CurrentPage !Sticky) \ SendToModule FvwmProxy Mark + I SendToModule FvwmProxy OnModifierRelease M SendToModule FvwmProxy Hide AddToFunc CirculateBackward + I SendToModule FvwmProxy ScanForWindow West North (CurrentPage !Sticky) \ SendToModule FvwmProxy Mark + I SendToModule FvwmProxy OnModifierRelease M SendToModule FvwmProxy Hide AddToFunc MyShowToggle + I SendToModule FvwmProxy ShowToggle + I SendToModule FvwmProxy OnModifierRelease M SendToModule FvwmProxy Hide Key Tab A M CirculateForward Key Tab A SM CirculateBackward Key Escape A M MyShowToggle And make OnModifierRelease a one-shot. And no auto-append. I don't know. [snip] Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] pgpfQluVpDzmy.pgp Description: PGP signature
