CVS scott: Apply conditionals patch.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: scott 04/07/11 01:26:55 Modified files: . : AUTHORS ChangeLog fvwm : conditional.c fvwm.1.in fvwm.h Log message: Apply conditionals patch. Committed patch by Norman Yarvin (with a few minor mods) to extend conditionals to handle multiple window names. -- 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]
man pages have wrong date
I just got confused by the FVWM man pages. The very last line of all the
man pages (with the notable exception of fvwm.1) appears to have an arbitary
date (hardcoded from the source man page).
For example, the FvwmButtons man page from the 2.5.10 release has this line:
3rd Berkeley Distribution 23 September 2002FvwmButtons(1)
You can see all the dates with this command:
find . -name '*.1' -exec /bin/grep ^.TH {} \;
What is the correct solution for this?
Create FvwmButtons.1.in, a Makefile entry run it through config.status?
(like the fvwm.1 man page)
Additionally, I think it would be nice to specify the version of FVWM
that each man page applies/belongs to in the actual man page. The fvwm.1
man page has this.
Thoughts?
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: Changes in module interface
On 11 Jul 2004 02:46:50 +0200, Dominik Vogt wrote: 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? How can you know in advance the number of bytes flags occupies? You can know in advance sizeof(long int) on that platform, but not sizeof(flags). Of course, if we only speak about C-modules compiled together with fvwm, this does not matter. But other modules should at least get other fixed-size event arguments correctly. In the similar way, all name arguments in window/icon name events are of the variable size and thus should be last. There is one difference, you can calculate the size of flags in compile time, but you can't calculate the size of window names at compile time. Still for modules in pure perl there is no such difference. 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? No, event argument is a positioned fixed-size (or variable-size if last) field. Here is the terminology I and perllib/FVWM/EventNames.pm use: Event is a synonym of packet from fvwm. Event name: M_ICON_NAME Event type (or rather mask): 111 Event arguments: win_id of type window (it is long int in C) frame_id of type window (it is long int in C) ptr of type number (it is pointer in C) name of type string (variable size) 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. Although I didn't actually use M_OLD_ADD_WINDOW/M_OLD_CONFIGURE_WINDOW, I think I could use them to obtain certain flags. Did you remove them because you need more event slots? There are plenty of MX_*. I think it is a good idea to think about the set of maybe 50 of most useful flags (each of one or two bits) and create such compiler independent two-arguments-of-32-bit compact event, similar to M_OLD_*. And BTW, perllib does not currently support 64 bits platforms, because I have neither LLP64 nor LP64 nor ILP64 platforms to test the fix. See this url for the C type table: http://yarchive.net/comp/longlong.html Regards, Mikhael. -- 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: Changes in module interface
On 11 Jul 2004 10:47:28 +, Mikhael Goikhman wrote: Although I didn't actually use M_OLD_ADD_WINDOW/M_OLD_CONFIGURE_WINDOW, I think I could use them to obtain certain flags. I think it is a good idea to think about the set of maybe 50 of most useful flags (each of one or two bits) and create such compiler independent two-arguments-of-32-bit compact event, similar to M_OLD_*. I should clarify myself. I don't want to restore M_OLD_ADD_WINDOW and M_OLD_CONFIGURE_WINDOW events. I rather want to add two 32-bit arguments flags_bunch_1 and flags_bunch_2 to M_ADD_WINDOW and M_ADD_WINDOW events. Regards, Mikhael. -- 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: man pages have wrong date
On Sun, Jul 11, 2004 at 08:01:02PM +1000, Scott Smedley wrote:
I just got confused by the FVWM man pages. The very last line of all the
man pages (with the notable exception of fvwm.1) appears to have an arbitary
date (hardcoded from the source man page).
For example, the FvwmButtons man page from the 2.5.10 release has this line:
3rd Berkeley Distribution 23 September 2002FvwmButtons(1)
You can see all the dates with this command:
find . -name '*.1' -exec /bin/grep ^.TH {} \;
What is the correct solution for this?
Create FvwmButtons.1.in, a Makefile entry run it through config.status?
(like the fvwm.1 man page)
Yes. I've done all this manually in the past, but only when I
remembered.
Additionally, I think it would be nice to specify the version of FVWM
that each man page applies/belongs to in the actual man page. The fvwm.1
man page has this.
Thoughts?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
pgpW4u4IC5zOU.pgp
Description: PGP signature
Notification: incoming/1346
FVWM Bug Tracking notification new message incoming/1346 Message summary for PR#1346 From: [EMAIL PROTECTED] Subject: Wait windowname with identical windownames failing Date: Sat, 10 Jul 2004 14:30:44 -0500 0 replies 0 followups ORIGINAL MESSAGE FOLLOWS From [EMAIL PROTECTED] Sat Jul 10 14:30:45 2004 Received: from lserv00.math.uh.edu ([129.7.128.99]) by util2.math.uh.edu with esmtp (Exim 4.30) id 1BjNYb-0001YX-DR for [EMAIL PROTECTED]; Sat, 10 Jul 2004 14:30:45 -0500 Received: from localhost (lserv00.math.uh.edu [127.0.0.1]) by lserv00.math.uh.edu (8.11.6/8.11.1) with ESMTP id i6AJUiJ24351 for [EMAIL PROTECTED]; Sat, 10 Jul 2004 14:30:44 -0500 Date: Sat, 10 Jul 2004 14:30:44 -0500 Message-Id: [EMAIL PROTECTED] From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Wait windowname with identical windownames failing Full_Name: Athanasius Version: 2.5.10 (Debian 2.5.10-8) CVS_Date: OS: Debian/testing X_Server: 4.3.0.1 (Debian 4.3.0.dfsg.1-4 20040529113443 Submission from: (NULL) (81.6.228.236) In my Initfunction I have some lines to switch to various Pages in FvwmPager and start applications, using Wait to ensure windows have drawn before moving to the next page so that windows end up on the correct pages. I used to (2.4.6) be able to use: + I GotoPage0 1 + I Exec exec color_xterm -fn 9x15 -geometry 141x24+0+120 -T 'games' -n 'games' + I Wait games + I Exec exec color_xterm -fn 9x15 -geometry 80x24+0-0 -T 'games' -n 'games' + I Wait games And things would work fine. When I updated to Debian/testing and fvwm 2.5.10 this stopped working. The second Wait would seem to not 'run' and the Page would be changed (by following lines) before the window was drawn. Changing the above to: + I GotoPage0 1 + I Exec exec color_xterm -fn 9x15 -geometry 141x24+0+120 -T 'games' -n 'games' + I Wait games + I Exec exec color_xterm -fn 9x15 -geometry 80x24+0-0 -T 'games2' -n 'games2' + I Wait games2 i.e. unique window names has made it work again. -- 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 scott: Apply conditionals patch.
On Sun, Jul 11, 2004 at 01:26:55AM -0500, fvwm-workers wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: scott 04/07/11 01:26:55 Modified files: . : AUTHORS ChangeLog fvwm : conditional.c fvwm.1.in fvwm.h Log message: Apply conditionals patch. Committed patch by Norman Yarvin (with a few minor mods) to extend conditionals to handle multiple window names. Hm, I did not expect this to be committed with the option naming issue unresolved, but so be it. The current syntax is inaccepable because it is now impossible to use $[w.name] in a condition if the window has a '|' in its name. It's already bad enough with '?' and '*', but I see no need to add new problems. Instead, a new option should be added, perhaps Next (foobar Netscape|Mozilla) foo that considers '|' to be special while the old syntax does not. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] pgpWkUHa4TaEy.pgp Description: PGP signature
CVS domivogt: * Added a comment on 128 platforms in vpacket.h
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt04/07/11 10:04:41 Modified files: docs : CONVENTIONS libs : vpacket.h Log message: * Added a comment on 128 platforms in vpacket.h * Corrected some typos in docs/CONVENTIONS. -- 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: Changes in module interface
On Sun, Jul 11, 2004 at 10:47:28AM +, Mikhael Goikhman wrote: On 11 Jul 2004 02:46:50 +0200, Dominik Vogt wrote: 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? How can you know in advance the number of bytes flags occupies? You can know in advance sizeof(long int) on that platform, but not sizeof(flags). Of course, if we only speak about C-modules compiled together with fvwm, this does not matter. But other modules should at least get other fixed-size event arguments correctly. In the similar way, all name arguments in window/icon name events are of the variable size and thus should be last. There is one difference, you can calculate the size of flags in compile time, but you can't calculate the size of window names at compile time. Still for modules in pure perl there is no such difference. 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? No, event argument is a positioned fixed-size (or variable-size if last) field. Here is the terminology I and perllib/FVWM/EventNames.pm use: I see. Testing the modules when the order of fields in ConfigWinPacket changes should not be necessary as all modules have been rewritten to use that structure when it was introduced in 2000. If the perllib does not use it, it's a bug in the perllib. Currently, the only reliable way I see to access the structure from perl is to write a bit of C code that translates it to a format perl can read. [snip] 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. Although I didn't actually use M_OLD_ADD_WINDOW/M_OLD_CONFIGURE_WINDOW, I think I could use them to obtain certain flags. Did you remove them because you need more event slots? There are plenty of MX_*. The M_OLD_..._WINDOW code has been commented out for years. All I did was to remove the dead code. I think it is a good idea to think about the set of maybe 50 of most useful flags (each of one or two bits) and create such compiler independent two-arguments-of-32-bit compact event, similar to M_OLD_*. And BTW, perllib does not currently support 64 bits platforms, because I have neither LLP64 nor LP64 nor ILP64 platforms to test the fix. See this url for the C type table: http://yarchive.net/comp/longlong.html I think the right way to fix this is to define a machine independent representation of the data that is currently sent in ConfigWinPacket structures. I always whought it was a mistake to just blindly export the whole window_flags structure anyway. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] pgp1iCejN61J6.pgp Description: PGP signature
Re: matchVersion() compile problems
Dominik Vogt [EMAIL PROTECTED] writes:
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.
=20
if (1)
{
foo;
}
=20
not
=20
if (1)
foo;
...
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.
So thats why a few things I try to do in Emacs don't work.
The underlying brokenness is in beginning-of-defun which is
widely used, for example, by C-x 4 a.
Emacs often has to go back to the beginning of
the function to figure out what it is looking at.
The default pattern for beginning-of_defun is to just look for
{ in the first column. That can be overridden by setting
defun-prompt-regexp but my few attempts were failures.
I see this is a known issue, and after reading this:
http://w3.pppl.gov/info/ccmode/Performance_Issues.html
I'm pretty much convinced that the curly brace in column 1 for
functions is an Emacs requirement.
--
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]
Re: Notification: incoming/1346
On Sat, Jul 10, 2004 at 02:33:08PM -0500, fvwm-bug wrote: FVWM Bug Tracking notification new message incoming/1346 Subject: Wait windowname with identical windownames failing Full_Name: Athanasius Version: 2.5.10 (Debian 2.5.10-8) CVS_Date: OS: Debian/testing X_Server: 4.3.0.1 (Debian 4.3.0.dfsg.1-4 20040529113443 Submission from: (NULL) (81.6.228.236) In my Initfunction I have some lines to switch to various Pages in FvwmPager and start applications, using Wait to ensure windows have drawn before moving to the next page so that windows end up on the correct pages. I used to (2.4.6) be able to use: + I GotoPage0 1 + I Exec exec color_xterm -fn 9x15 -geometry 141x24+0+120 -T 'games' -n 'games' + I Wait games + I Exec exec color_xterm -fn 9x15 -geometry 80x24+0-0 -T 'games' -n 'games' + I Wait games And things would work fine. When I updated to Debian/testing and fvwm 2.5.10 this stopped working. The second Wait would seem to not 'run' and the Page would be changed (by following lines) before the window was drawn. Changing the above to: + I GotoPage0 1 + I Exec exec color_xterm -fn 9x15 -geometry 141x24+0+120 -T 'games' -n 'games' + I Wait games + I Exec exec color_xterm -fn 9x15 -geometry 80x24+0-0 -T 'games2' -n 'games2' + I Wait games2 i.e. unique window names has made it work again. Fixed in CVS. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] pgpUgA0Dy0kjH.pgp Description: PGP signature
CVS domivogt: * Fixed ConfigWinPacket length.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt04/07/11 11:05:01 Modified files: . : ChangeLog fvwm : builtins.c module_interface.c libs : vpacket.h Log message: * Fixed ConfigWinPacket length. * Fixed Wait (multiple hits for same window). -- 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 Sun, Jul 11, 2004 at 11:19:55AM -0400, Dan Espen wrote:
Dominik Vogt [EMAIL PROTECTED] writes:
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.
=20
if (1)
{
foo;
}
=20
not
=20
if (1)
foo;
...
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.
So thats why a few things I try to do in Emacs don't work.
The underlying brokenness is in beginning-of-defun which is
widely used, for example, by C-x 4 a.
Emacs often has to go back to the beginning of
the function to figure out what it is looking at.
The default pattern for beginning-of_defun is to just look for
{ in the first column. That can be overridden by setting
defun-prompt-regexp but my few attempts were failures.
I see this is a known issue, and after reading this:
http://w3.pppl.gov/info/ccmode/Performance_Issues.html
I'm pretty much convinced that the curly brace in column 1 for
functions is an Emacs requirement.
It's not only emacs, other C tools need it too. I think cscope is
one of them.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
pgpgKJeoap7hU.pgp
Description: PGP signature
Re: Changes in module interface
On 11 Jul 2004 16:54:18 +0200, Dominik Vogt wrote: On Sun, Jul 11, 2004 at 10:47:28AM +, Mikhael Goikhman wrote: 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? No, event argument is a positioned fixed-size (or variable-size if last) field. Here is the terminology I and perllib/FVWM/EventNames.pm use: I see. Testing the modules when the order of fields in ConfigWinPacket changes should not be necessary as all modules have been rewritten to use that structure when it was introduced in 2000. If the perllib does not use it, it's a bug in the perllib. The bug part is questionable. There are currently 32+ events, not just 2. Currently perllib (EventNames.pm specifically) defines the complete event scheme. The C library does not even come close, modules simply parse the events on their own, so there is no really enough info to generate from. One solution would be to write a parser of ConfigWinPacket structure to generate the scheme of these two events only. But given that someone should maintain such parser, and this structure is not changed often (maybe once per year), it is just much *much* easier to manually synchronize EventNames.pm with it. Testing the modules is not really necessary unless arguments are removed. What is not questionable is that perllib should have tests, so any breakage is auto-detected. Currently, the only reliable way I see to access the structure from perl is to write a bit of C code that translates it to a format perl can read. This may be done when the C module library is established and stabilized. But then again, there is currently only problem with flags that are hard to be parsed reliably, and you want to solve this problem anyway. I think it is a good idea to think about the set of maybe 50 of most useful flags (each of one or two bits) and create such compiler independent two-arguments-of-32-bit compact event, similar to M_OLD_*. I think the right way to fix this is to define a machine independent representation of the data that is currently sent in ConfigWinPacket structures. I always whought it was a mistake to just blindly export the whole window_flags structure anyway. This may be a good goal, but it requires more effort and mainainance than the intermediate solution I suggested. But I am all for the complete solution in the long run. Regards, Mikhael. -- 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 scott: Apply conditionals patch.
On 11 Jul 2004 17:03:37 +0200, Dominik Vogt wrote: On Sun, Jul 11, 2004 at 01:26:55AM -0500, fvwm-workers wrote: Log message: Apply conditionals patch. Committed patch by Norman Yarvin (with a few minor mods) to extend conditionals to handle multiple window names. Hm, I did not expect this to be committed with the option naming I didn't expect this to be commited so shortly too, but so be it. issue unresolved, but so be it. The current syntax is inaccepable because it is now impossible to use $[w.name] in a condition if the window has a '|' in its name. It's already bad enough with '?' and '*', but I see no need to add new problems. Instead, a new option should be added, perhaps Next (foobar Netscape|Mozilla) foo that considers '|' to be special while the old syntax does not. This still leaves the problem with '?' and '*'. I think, the new condition option is not necessary. Instead, some filters may be added to variable expansion. I.e.: $[w.name] - expanded to: 'My %^* window' $[w.name:dquote] - expanded to: My %^* window $[w.name:noquote] - expanded to: My %^* window $[w.name:glob]- expanded to: 'My %^\* window' $[w.name:menu]- expanded to: 'My %%^* window' Regards, Mikhael. -- 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-work...@hpc.uh.edu
fvwm-workers@hpc.uh.edu 您好! 我們是從網上認識到你的, 冒昧打攏, 希望我們的來信能為你的工作提供方便 我們在深圳是一家（噴圖印務）生產商, 例如: 各類大小廣告宣傳畫面、海報橫額、挂畫招貼、展板展架、燈片燈箱、展覽展示等。 承印各類產品目錄畫冊、手提袋、膠貼紙、卡片、包裝盒等。 我們需要知道具體的尺寸規格, 顏色, 數量, 用料及工藝要求等才能為你預算成本 或者在不了解的情況下只需告訴我們你的計劃與目的, 我們也可為你建議方案 可派送到香港或海關關口, 最快上午發貨, 當天下午收到, 貨款的交收只需在我廠發貨前交給香港中國銀行我廠指定賬號即可 你的相關資料通過以下地址可直接拷貝到我廠的電腦上(早上九點至晚上十二點) ftp://szcolor.com/ ftp://26220610.dns0755.net/ 請寫清楚你的生產要求,電話,聯絡人等, 發個e-mail通知我們以便及時回復 如在當日後還未答復, 請用電話或傳真跟進 平時要為了能夠與我廠即時取得溝通， 可從以下網址下載工具安裝并依照軟件提示注冊一個ICQ號碼 http://www.icq.com/ 然後再加入我的用戶號：173161456 即可看到我廠是否在線并交流 Dear Hong Kong compatriots: Thank you for your enquiries on our product. We are that an advertisement in Shenzhen make the factory. Hope that the information can bring convenience for you! Speciality of our factory: 1. Making of color poster by spray 2. Making of color page by printing Including all kinds of poster, outdoor and indoor Banner, show tools, etc.. Including all kinds of paper printing, catalogue, bag, card, box, etc.. You can visit our home page www.6220610.com for more information. Welcome your quotation inquiry! Mr. Liu 負責人劉洋 Shen Zhen Advertising Factory http://www.6220610.com/ E-mail: [EMAIL PROTECTED] Tel: +86-0755-2622 0610 Fax: +86-0755-8240 9179 Mobile: 136-9198-4046 ICQ Number: 173161456 Welcome to contact us ! 01:14:04 2004-07-12 -- 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: CVS scott: Apply conditionals patch.
On Sun, Jul 11, 2004 at 04:25:46PM +, Mikhael Goikhman wrote: On 11 Jul 2004 17:03:37 +0200, Dominik Vogt wrote: On Sun, Jul 11, 2004 at 01:26:55AM -0500, fvwm-workers wrote: Log message: Apply conditionals patch. Committed patch by Norman Yarvin (with a few minor mods) to extend conditionals to handle multiple window names. Hm, I did not expect this to be committed with the option naming I didn't expect this to be commited so shortly too, but so be it. In any case, thanks. issue unresolved, but so be it. The current syntax is inaccepable because it is now impossible to use $[w.name] in a condition if the window has a '|' in its name. It's already bad enough with '?' and '*', but I see no need to add new problems. Instead, a new option should be added, perhaps Next (foobar Netscape|Mozilla) foo that considers '|' to be special while the old syntax does not. This still leaves the problem with '?' and '*'. The situation with '|' is worse than with '?' or '*', because both of those match the literal characters; if someone names his window **BIG**ANNOYING**WINDOW**, then the pattern **BIG**ANNOYING**WINDOW** will still match it. Not so with the window name |BIG|ANNOYING|WINDOW|. I think, the new condition option is not necessary. Instead, some filters may be added to variable expansion. I.e.: $[w.name] - expanded to: 'My %^* window' $[w.name:dquote] - expanded to: My %^* window $[w.name:noquote] - expanded to: My %^* window $[w.name:glob]- expanded to: 'My %^\* window' $[w.name:menu]- expanded to: 'My %%^* window' At the moment, the code that interprets '|' doesn't deal with quotes itself, and can't even tell that there once were quotes -- they get stripped off inside GetNextSimpleOption(), or rather inside the general parsing code which it calls. Another thing that happens inside that code is that backslashes disappear. (Double backslashes get converted into single backslashes.) But one thing that can be done without changing or bypassing the general parsing code is to have repeating the '|' character twice, as in ||, match a literal '|'. (The only thing that would impair would be the ability to specify a zero-length string as one of the alternatives to match to; if the user wanted to specify a zero-length string, he'd have to make it the first or last alternative, as in |foo|bar or foo|bar|.) Then one of those filters could expand | into ||. But is using $[w.name] in a condition a useful enough thing to do, that it is worth the trouble? -- 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 scott: Apply conditionals patch.
On 11 Jul 2004 16:56:08 -0400, Norman Yarvin wrote: On Sun, Jul 11, 2004 at 04:25:46PM +, Mikhael Goikhman wrote: On 11 Jul 2004 17:03:37 +0200, Dominik Vogt wrote: On Sun, Jul 11, 2004 at 01:26:55AM -0500, fvwm-workers wrote: Committed patch by Norman Yarvin (with a few minor mods) to extend conditionals to handle multiple window names. The current syntax is inaccepable because it is now impossible to use $[w.name] in a condition if the window has a '|' in its name. It's already bad enough with '?' and '*', but I see no need to add new problems. Instead, a new option should be added, perhaps Next (foobar Netscape|Mozilla) foo that considers '|' to be special while the old syntax does not. This still leaves the problem with '?' and '*'. The situation with '|' is worse than with '?' or '*', because both of those match the literal characters; if someone names his window **BIG**ANNOYING**WINDOW**, then the pattern **BIG**ANNOYING**WINDOW** will still match it. Not so with the window name |BIG|ANNOYING|WINDOW|. I think, the new condition option is not necessary. Instead, some filters may be added to variable expansion. I.e.: $[w.name] - expanded to: 'My %^* window' $[w.name:dquote] - expanded to: My %^* window $[w.name:noquote] - expanded to: My %^* window $[w.name:glob]- expanded to: 'My %^\* window' $[w.name:menu]- expanded to: 'My %%^* window' At the moment, the code that interprets '|' doesn't deal with quotes itself, and can't even tell that there once were quotes -- they get stripped off inside GetNextSimpleOption(), or rather inside the general parsing code which it calls. Another thing that happens inside that code is that backslashes disappear. (Double backslashes get converted into single backslashes.) But one thing that can be done without changing or bypassing the general parsing code is to have repeating the '|' character twice, as in ||, match a literal '|'. (The only thing that would impair would be the ability to specify a zero-length string as one of the alternatives to match to; if the user wanted to specify a zero-length string, he'd have to make it the first or last alternative, as in |foo|bar or foo|bar|.) Then one of those filters could expand | into ||. But is using $[w.name] in a condition a useful enough thing to do, that it is worth the trouble? There is a need for the quoting syntax of '*', '?' and '|' in names. I would not encourage usage of $[w.name] as-is in any place with special characters, so this should not be an issue. The current situation is that there is no way to specify the exact window names like raised, transient, visible, sticky and many others in conditionals. This problem is IMHO even worse than a possible '|' problem. I think the current syntax of non-option names should not be the main one in the long run. How about to solve the whole issue correctly by introducing the following options in conditions: Name pattern, IconName pattern, Class pattern, Resource pattern AnyName pattern All of these will support special pattern characters including |. The non-option names are still supported, but there is a better syntax. And we still need the variable filters like $[var:pattern], and quoting syntax for names in conditions; ||, ** and ?? is ok by me. Regards, Mikhael. -- 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]
A user is getting experiences about: fvwm-work...@fvwm.org
**OPINION SHARING ALERT** Advisory - A user is trying to share experiences and opinions about you via our website. The purpose of this email is to inform you that a posting has been made about you at our website. This is email is not commercial in nature. If this email message was delivered to your spam or bulk email folder please notify your ISP or spam filtering company regarding this mistake on their part. To see what users have posted about you use this link: http://1.sharyx.us/lx.php?a=searchb=5[EMAIL PROTECTED] This website also includes a highly valuable Daily Searching System. This is a simple system in which you can set-up searches that this website will perform for you each and every day. After performing the searches that you have specified, our Daily Searching System will send your search results to you via email. By setting up Daily Searches for all the people and businesses that matter to you, you will be assured to find out right away when a user submits a Experience Request that is interesting to you. IMPORTANT - To add this email address to our Do Not Email List click here: http://8.sharyx.biz/lx.php?a=donotemail[EMAIL PROTECTED] Regards, SYEC Support -- 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 migo: * perllib: support looped args in events; update CONFIGURE_WINDOW format
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: migo04/07/11 21:23:10 Modified files: modules: ChangeLog modules/FvwmDebug: FvwmDebug.in FvwmGtkDebug.in modules/FvwmPerl: FvwmPerl.in perllib: ChangeLog perllib/FVWM : Event.pm EventNames.pm perllib/FVWM/Tracker: WindowList.pm Log message: * perllib: support looped args in events; update CONFIGURE_WINDOW format * perllib: new methods FVWM::Window::dump, FVWM::Event::dump * FvwmPerl: support window context in cmd(); improve documentation * FvwmDebug, FvwmGtkDebug: support looped args in events -- 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 scott: Apply conditionals patch.
Committed patch by Norman Yarvin (with a few minor mods) to extend conditionals to handle multiple window names. Hm, I did not expect this to be committed with the option naming issue unresolved I was not aware of this issue. This is the first post I've seen discussing it. I saw Mikhael's proposal (liked it) audited/tested Norman's subsequent patch to make sure it did what Mikhael suggested. Did I miss other posts on the topic? Either way, I'm sorry to have caused a problem. 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: FVWM: Saving Windows: save stacking order?
On 11 Jul 2004 17:01:16 +, Mikhael Goikhman wrote: On 11 Jul 2004 20:08:06 +1000, Scott Smedley wrote: Currently M_RESTACK is the only event with periodical format, and it is not fully supported by perllib yet. So, you can't get the stacking info yet. But there is nothing inherently difficult to implement such periodical format parsing, I just didn't have a need for this event yet. I'm not sure what you mean by periodical format. Can you please elaborate? I notice there are only 3 fields in an M_RESTACK event: win_id ptr, frame_id I can't find a logical connection b/w those fields a way to calculate the stacking order. These 3 arguments are repeated for all windows participated in restack. So there are actually 3*number_of_windows arguments in M_RESTACK event. You are right, the meaning of the windows is not documented well, just briefly, in http://fvwm.org/documentation/dev_modules.php#M_RESTACK . You should figure out yourself how to use this to get the stacking order. I will either implement the generic support for events with periodical arguments (more likely), or provide the special M_RESTACK interface. Ok, I have implemented the generic looped args support, so M_RESTACK is now fully supported. But I am disappointed now. It seems that M_RESTACK is always sent when some window is lowered and it always has 6 arguments (i.e. 2 windows). This is kind of contradicting the documentation in the link above. Unless of course I have some bug (unlikely). If someone knows whether this strange behaviour of M_RESTACK is intended, please explain. So, I am not sure whether this event is useful to manage the stacking order. M_LOWER_WINDOW and M_RAISE_WINDOW seem to be more useful. I think you should take a look at FvwmPager, it is the only module currently that manages stacking order of windows. Regards, Mikhael. -- 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]
