CVS migo: * New conditional command This.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: migo02/02/22 05:48:27 Modified files: . : ChangeLog NEWS fvwm : commands.h conditional.c functions.c functions.h fvwm2.1 Log message: * New conditional command This. -- 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]
test, please ignore :-P
Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Adding Bidi to Fvwm ?
On Thu, 21 Feb 2002 23:02:33 +
Mikhael Goikhman migo homemail com wrote:
On 21 Feb 2002 12:08:45 -0800, Nadim Shaikli wrote:
With the recent work on multibyte support in Fvwm2 - has any thought
been given to those languages that are right-to-left oriented (Arabic,
Farsi, Hebrew, etc...) ? In other words, have any considerations been
given to the addition of Bidi (Bi-directionality) ?
http://www.unicode.org/unicode/reports/tr9/
May I suggest a compile-time option of including Fribidi (open source
Bidi library),
http://fribidi.sourceforge.net
I don't know whether I will add bidi support, but I may try to start it.
At least I understand what this means. It is not trivial to immediately
understand why this is needed and even less trivial to understand that
it's all heuristics, there may be possible conflicts in any algorithms.
My understanding is, the inclusion of Bidi (even if it were enabled at
all times) should not adversely affect latin only characters that are
left-to-right (ie. the status quo).
% echo hi 1-2 (english) is SHALOM 1-2 (IVRIT). | fribidi -C CapRTL
hi 1-2 (english) is IVRIT) 2-1 MOLAHS).
# the second example seems like a bug in my fribidi, but maybe not
I'd agree that your second example should be something the fribidi
people should be informed of on their mailing list. In passing there
are other Bidi implementations out there,
http://crl.nmsu.edu/~mleisher/ucdata.html
The point was/is to consider Bidi's inclusion, the various minor issues
within ought to be taken care of in other forums.
Actually, bidi is orthogonal to unicode and to aligment, i.e. it may be
applied to a normal 256-symbol charset, and, I think, we may assume it
only affects an order of symbols inside the string, not its alignment.
So, what I may do is to add --with-fribidi-{library,includes}, and try to
figure out where this bidi filter should be added. But I am not sure yet
what exact parameters should be used in all cases (MULTIBYTE or not) and
what are the conditions when bidi should be applied at all.
As noted above, I'd contend that Bidi's inclusion should not and will not
affect all current external display calls. In other words, passing in
latin (left-to-right) characters at all times will result in NO change
(ie. output = input).
- Nadim
__
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
--
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/854
On Tue, Feb 12, 2002 at 03:21:14AM -0600, fvwm-bug wrote: FVWM Bug Tracking notification new message incoming/854 Full_Name: Sven Knauer Version: 2.4.3 CVS_Date: OS: Mandrake 8.1 X_Server: Submission from: (NULL) (212.222.82.66) If you want to login to fvwm with KDE Login Manager (kdm) it doesn't work. Always started the failsafe Session. Edit /etc/X11/wmsession.d/fvwm-2.4 Change the Name from FVWM 2.4 to FVWM2.4 (without blank) And now it works Please report this to the KDE or Mandrake people or whoever wrote the setup for kdm. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: perl module library
On Sun, Feb 10, 2002 at 08:22:25PM +, Mikhael Goikhman wrote:
I've committed an initial perl module library so that it may be tested.
This new perl library is based on the old X11::Fvwm module, but I redid it
and simplified. Hopefully it is more clean now. It should also support
extended module messages, but this is not really tested.
What impact does this have on future module interface changes?
Here is a simple auto-raise module in perl:
use FVWM::Module;
my $module = new FVWM::Module;
$module-mask(M_FOCUS_CHANGE);
$module-addHandler(M_FOCUS_CHANGE, sub { $_[0]-sendInfo($_[2], Raise)
});
$module-eventLoop();
The things that I will like to do sometimes soon:
* implement missing module config methods
* implement some alias handling (?)
* finalize API
* write documentation
* think about an optional Perl/GTK and Perl/Tk support
There are 2 simple test modules in tests/perl directory, just run them
in FvwmConsole using their full path, after make; make install.
A testing is needed. If someone searches for a challenging toy to program,
implement a one page pager in text mode inside xterm. No ncurses is needed
(unless you want to implement window dragging too), just standard terminal
escape sequenses and maybe pseudo-graphics. It should be not hard in perl.
Gee.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: CVS domivogt: * FvwmBUttons: Added a new way to specify the button that title or icon is to
On Mon, Feb 11, 2002 at 12:48:37PM +, Tim Phipps wrote: On 09 Feb 2002 08:00:53 -0600, FVWM CVS wrote: SendToModule FvwmButtons Title row column ... This is causing me problems when I try to set a button title to a number. I have three buttons in a container to display the day, date and time. This new syntax doesn't work with containers so I have to use the old style. Unfortunaltely the date and time are interpreted as numbers and so the new syntax is used. Could we have +row+column for the new method? Done. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: configure and gnomeConf.sh
On Thu, Feb 07, 2002 at 11:11:00AM +0100, fvwm-workers wrote: On Thu, Feb 07, 2002 at 03:42:56PM +0600, Dmitry Yu. Bolkhovityanov wrote: Hi! I've just downloaded fvwm-snap-20020206 and tried to compile it with installdir ~/usr/ . The commandline was ./configure --prefix=$HOME/usr There was a line in configure output: checking for gnomeConf.sh file in /export/ring1/bolkhov/usr/lib... not found (my $HOME is /export/ring1/bolkhov) and finally a With GNOME support in FvwmGtk? no: Can't find working gnome-config There is /usr/lib/gnomeConf.sh, so I modified the command line to ./configure --prefix=$HOME/usr --with-gnome-libs=/usr/lib/ but that had no effect -- configure still looks in ~/usr/lib/. I've skimmed through the script itself, and there's a code to set $gnome_prefix to the argument of --with-gnome-libs, but later there's some alchemy with --with-gnome, which probably overrides the value of $gnome_prefix. Not that I care about Gnome, but just for correctness... Am I missing something, or is there really a mistake in configure script? Probably a bug in the configure script. According to the documentation --prefix sets only the install path. You can get Gnome support running with --with-gnome-libs and --with-gnome-includes (I hope). Hm, who added that check to configure originally? Could someone who knows how all this GNOME stuff works take a look at it? Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: bug w/ ewmh window state transitions
On Sat, Feb 09, 2002 at 02:39:48PM +0100, Olivier Chapuis wrote: On Wed, Feb 06, 2002 at 11:49:54PM +0100, Dominik Vogt wrote: There is a bug with the ewmh code that forces windows that temporarily withdraw their windows into iconic state when they map again. There is a similar problem for shaded windows and possibly other states too. It's easy to reproduce: 1) Fire up an FvwmButtons that has a panel. 2) Open the panel. 3) Iconify/Shade/... the panel 4) Open the panel again by pressing on the panel button. Now, the panels should be mapped again, but instead the icon is unmapped and then mapped again. I tracked that down into the EWMH_GetStyle function. What FvwmButtons does is this: - XWithdrawWindow() - set wm hints to start the window in normal state - XMapWindow() But the code in EWMH_GetStyle() sets the do_start_iconic flag of the style structure. I think there should be some EWMH_... call to set the EWMH state hint around line 1502 in events.c: SetMapStateProp (Tmp_win, WithdrawnState); (or probably outside the enclosing if-clause). I will take a look on this soon. Seems you have fixed this one. Just out of curiosity, what did you actually do to fix it? Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt: * Fixed mouse bindings on root window w/ xfishtank.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/02/22 16:07:48 Modified files: . : Tag: branch-2_4 ChangeLog NEWS fvwm : Tag: branch-2_4 events.c windowlist.c Log message: * Fixed mouse bindings on root window w/ xfishtank. * Fixed Xinerama placement of WindowList. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt: * Fixed mouse bindings on root window w/ xfishtank.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/02/22 16:09:00 Modified files: . : ChangeLog fvwm : events.c icons.c windowlist.c libs : Parse.c modules: ChangeLog modules/FvwmButtons: FvwmButtons.c Log message: * Fixed mouse bindings on root window w/ xfishtank. * Fixed Xinerama placement of WindowList. * Applied (de)iconify / is_map_pending patch by Markus Schwarzenberg. * Changed syntax of FvwmButtons title/icon changing code. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Need to redesign hints code
With GNOME and EWMH we now have a flood of different methods to specify style and state of a window that compete against each other. Since there already are a lot of problems, I think we need to redesign how hints/styles/states are applied to a window. Right now we have: GNOME hints set by the application GNOME hints set by fvwm EWMH hints set by the application EWMH hints set by fvwm Hints set by the application Fvwm's styles Fvwm's window states For some styles/states it's already almost impossible to keep track of the proper hint to use. The latest example is the GNOME layer hint: when fvwm creates a window, it sets that hint. Later, if you recapture the window or restart fvwm, fvwm finds the layer property on the window and overrides the style, even if it changed. Note that this happens for windows that never set any GNOME hints themselves. I propose the following solution for the external hints (GNOME, EWMH and possibly others in the future): Every window property that is defined externally is duplicated with an FVWM prefix. E.g. NET_WM_FOOBAR -- FVWM_NET_WM_FOOBAR When application provides a hint, e.g. the layer hint, that new property is deleted from its window. If fvwm sets a hint it sets the original property and the FVWM_ property to the according value. Now, whenever fvwm checks for a hint (recapture, restart, etc.) it prefers to use its own styles over any GNOME/EWMH hints that were set by itself (or another fvwm). So, the normal order of preference would be: EWMH hints (by application) GNOME hints (by application) Styles Application hints EWMH hints (by fvwm) GNOME hints (by fvwm) I feel positive that I could do that with the GNOME code, but I don't understand the EWMH code enough to make the proper changes. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: xinerama windowlist patch
On Thu, Feb 21, 2002 at 12:20:28PM +, Darren Marshall wrote: Attached is a patch to fix a problem where clicking the mouse button to popup the windowlist on the secondary screen of an xinerama setup always pops up on the primary screen. I'll apply the patch shortly. Thanks for your help. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: facing problem in fvwm2.4.4
On Wed, Feb 13, 2002 at 03:43:14PM +0530, Srivathsa Rao U wrote: hi, I switched my WM from 2.0 to 2.4.4. Now every thing working fine i got the settings how I want. But Iam facing problem with nedit. Iam working in Unix using solaris system (sun7). Iam using nedit as text editer everywhere. But after i started using new fvwm2.4.4 the size of this nedit is not fixed . For some file which have more memory like 700k the size ( geometry) is very big . But it is maintaing the height only the width is increasing (may be arround some 5 time of screen width) . It is crossing window size also. why it is like that. ? How can i correct this? This problem was not there in fvwm 2.0 my default geometry for nedit is 80X40. This is not only my problem . here whoever using 2.4.4 they are also facing this. pls give the solution . nedit version - 5.1 I didnt downloaded nedit at the time of fvwm. It was there. In my .Xdefault file i setted nedit geometry as - nedit*geometry: 85X40 Attached is the gtar file contains following. file - junk -- a file with big memory. if I open this file in nedit i am getting problem. file - .fvwm2rc - my fvwm settings. file - .nedit- my nedit settings. But size is changing only for the file conating big memory. why it is like that ? With the files you posted I can reproduce the problem. Actually it does not depend on the .fvwm2rc, but I need your .nedit file as well as the data file (using nedit-5.1.1). What happens is this: 1) Start nedit 2) nedit opens its main window with a width of 803 pixels and requests a character width (width_inc in the size hints) of 9 pixels (for me). All is fine for now. 3) From the file dialog, load the data file you sent. 4) nedit provides new size hints. It again requests a width of 803 pixels, but a width_inc if 1. Now this is where the problem starts: according to the ICCCM2, the new requested width is ignored (honoured only when the window is mapped), but the width_inc is honoured. So, the window shrinks to a width of 154 pixels. 5) nedit resizes its window to 803 pixels width. Actually, it seems to believe it still has this size. Keep in mind that the character width is still 1. 6) Again, nedit provides new size hints, with a width of 803 and a width_inc of 9. Fvwm ignores the width as it should and honours the width . Thus, the width of the interior of the window is multiplied by 9 which results in a window that is about 5500 pixels wide :-P This is clearly a bug in nedit. There is no reason to change the width_inc to 1. Also, it seems the author misunderstood the way the size hints work. For other files, nedit neither resizes its window nor does it provide new size hints. The reason why you don't see this with earlier versions and probably not with any other window manager is that fvwm-2.2 and above is the only window manager I know of that properly implements changing the width_inc and height_inc hints. Please report this to the nedit developers. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/853
On Mon, Feb 11, 2002 at 09:53:51AM +0100, Markus Schwarzenberg wrote: On Feb 8, 17:55, Dominik Vogt wrote: Subject: Re: Notification: incoming/853 On Thu, Feb 07, 2002 at 07:38:36AM -0600, fvwm-bug wrote: FVWM Bug Tracking notification new message incoming/853 Full_Name: Markus Schwarzenberg Version: 2.4.5. CVS_Date: OS: sunos 5.7 X_Server: Submission from: (NULL) (153.96.96.2) after fvwm2 -restart the FvwmWindow.flags.is_map_pending bit sometimes seems not to be set properly. This causes the function Iconify(in icons.c) to return in: [ snip ] Can you please make a patch with the 'diff' command? $ diff -u icons.c.orig icons.c Shure (attached). BTW, in the meantime I added the workaround also to the function DeIconify (In very rare circumstances it could be necessary there too). I've applied that patch. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: perl module library
On 22 Feb 2002 21:08:53 +0100, Dominik Vogt wrote: On Sun, Feb 10, 2002 at 08:22:25PM +, Mikhael Goikhman wrote: I've committed an initial perl module library so that it may be tested. This new perl library is based on the old X11::Fvwm module, but I redid it and simplified. Hopefully it is more clean now. It should also support extended module messages, but this is not really tested. What impact does this have on future module interface changes? Nothing special. I will try to keep a synchronization between C and perl libraries. If and when incompatible changes will be introduced, I will increase the library version. I.e. future scripts containing the line: use FVWM::Module 2.1; # at least version 2.1 is needed will fail with the current library (version 1.1). In the future we may use the same version number in both libraries, making it a part of the module protocol if you think this is needed. But the perl module library is not more special than the C one, except that most of perl constants are autogenerated from C ones. 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]
CVS domivogt: * Fixed moving window over the edge of the scrren with the keyboard.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/02/22 17:46:14 Modified files: . : ChangeLog fvwm : move_resize.c Log message: * Fixed moving window over the edge of the scrren with the keyboard. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt: * Fixed moving window over the edge of the scrren with the keyboard.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/02/22 17:46:42 Modified files: . : Tag: branch-2_4 ChangeLog NEWS fvwm : Tag: branch-2_4 move_resize.c Log message: * Fixed moving window over the edge of the scrren with the keyboard. -- 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:
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: migo02/02/22 19:24:22 fvwm/perllib/FVWM/Module Update of /home/cvs/fvwm/fvwm/perllib/FVWM/Module In directory malifon.math.uh.edu:/tmp/cvs-serv11017/perllib/FVWM/Module Log Message: Directory /home/cvs/fvwm/fvwm/perllib/FVWM/Module added to the repository -- 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: * new perl module subclass for writting Perl/Tk modules
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: migo02/02/22 20:33:55 Modified files: . : configure.in ChangeLog perllib/FVWM : Makefile.am Module.pm.in tests/perl : README tests : ChangeLog perllib: ChangeLog Added files: tests/perl : module-tkdesker perllib/FVWM/Module: .cvsignore Makefile.am Tk.pm Log message: * new perl module subclass for writting Perl/Tk modules * several improvements -- 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: * removed debug fprintf
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: migo02/02/22 20:35:17 Modified files: . : INSTALL.fvwm fvwm : decorations.c Log message: * removed debug fprintf -- 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]
