Re: Pegasus Mail
On Sat, Aug 04, 2001 at 01:31:56PM +, Mikhael Goikhman wrote: Dmitry, you use Pegasus Mail. I don't know whether you noticed, but this mailer is the only one (there is also /bin/mail) that does not support threads. When you get dozens of emails daily, threads are essential. Most mailers (I can list 20) support In-reply-to: header (used to show threads), some also support References: header (this is used by mail archives to add links to related messages, usually to all parents). Take a look at http://www.hpc.uh.edu/fvwm/archive/0107/threads.html . You always start a new thread although most of messages are Re: ones. Perhaps you should consider using mutt. It can even identify the correct thread without one of those headers (I guess it's using the subject). Although it's not perfect (such mails are always shown as a reply to the first mail in the thread), at least you get the mails sorted into threads: Jul-29 To fvwm-workers What to do for next release? Jul-30 To fvwm-workers |- Aug-02 To fvwm-workers | `- Aug-04 To fvwm-workers | `- Aug-04 To fvwm-workers `* The last line shows a reply without thread information (indicated by the asterisk). 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: A pair of questions regarding FVWM setup
On Sat, Aug 04, 2001 at 11:35:27AM +, Mikhael Goikhman wrote:
On 04 Aug 2001 16:15:37 +0700, Dmitry Yu. Bolkhovityanov wrote:
First, is it possible to do a Windows-3.1-like windows and menus? The
problem with borders is that in case of BorderStyle -- flat handles are
invisible even without HiddenHandles. The accompanying problem with menus
is that there's only BorderWidth flag, without an ability to switch
3D-ness off (with Nops too). Both seems to be caused by lack of
BorderColor concept. Am I missing something?
Windows have BorderColor concept. Style * [Hilight]BorderColorset.
Menus have BorderColor concept (kind of) using MenuStyle MenuColorset
and ActiveColorset; you may specify sh and hi colors in these colorsets.
I don't remember how should look windows-3.1 windows and menus, so I can't
say whether something is missing to fully or partially emulate the look.
It is hard to believe someone is interesting in microsoft solutions. :)
It simply has 2D borders. It looks a bit like a wire frame around
the windows. You can get the same effect if you choose sh/hi
colours on the border appropriately, e.g.
bg = black
sh = white
hi = white
Second, is it possible to create an if-then-else construct in a
function? I tried to emulate the behaviour of Win9x's TaskBar, which can be
described as:
if (Iconic || !Raised)
{
Iconify Off
Raise
Focus
}
else
{
Iconify On
}
(i.e. deiconify if iconified, otherwise raise of not raised, otherwise
iconify).
We discussed adding shell abilities to fvwmrc two years ago and the
decission was not to do this, since preprocessors and PipeRead can do it.
How about this enhancement to conditional commands:
Next (conditions) { false-action } true-action
This would allow an else case in all conditional commands
without the need to store a return code of these commands. For
example:
AddToFunc ToggleWindow
+ I Next ($0) { Exec $0 } Close
AddToFunc Deiconify-Raise-Focus
+ I Iconify Off
+ I Raise
+ I Focus
AddToFunc Deiconify-or-Raise-or-Iconify
+ I Current (Iconic) Deiconify-Raise-Focus
+ I Current (!Raised) Raise
+ I Current (Raised, !Iconic) Iconify On
AddToFunc Deiconify-Raise-Focus
+ I Iconify Off
+ I Raise
+ I Focus
AddToFunc Deiconify-or-Raise-or-Iconify
+ I Current (Raised, !Iconic) { Deiconify-Raise-Focus } Iconify on
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: Forcing focus
On Fri, Aug 03, 2001 at 10:18:20PM -0400, Dan Espen wrote: Mikhael Goikhman [EMAIL PROTECTED] writes: Next Focus should normaly circulate around all matching windows. But if some window does not accept focus, it may break circulation, because Next Focus makes the problematic window current and tries to give it the focus, this fails and the previous window stays focused forever while you execute Next Focus. Receiving the focus may fail becuase either a program sets Focus Policy to No input or a user explicitely gives a window NeverFocus style. There are 2 solutions to solve breaking circulation. The first is: Style * Lenience This instructs all (or some) windows to accept focus regardless of what the program requests. The second solution is to find a problematic window and make it CirculateSkip, for example: Style XClock CirculateSkip Style FvwmPager CirculateSkip, WindowListSkip Isn't something in fvwm broken? I wouldn't call it broken. It depends on what you want to do with the window. If you want to give the window the focus the windows should be skipped, but not if the action is Raise. How about: Next (AcceptsFocus) Focus Looks good. I'll see what I can do. Next (*) Focus Force I don't think this is necessary or even useful. 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/753
On Fri, Aug 03, 2001 at 05:19:06PM -0500, fvwm-bug wrote: FVWM Bug Tracking notification new message incoming/753 Message summary for PR#753 From: [EMAIL PROTECTED] Subject: SloppyFocus sometimes won't refocus properly Date: Fri, 03 Aug 2001 17:19:05 -0500 0 replies 0 followups Full_Name: Pete Gelbman Version: 2.4.0 CVS_Date: OS: Solaris 2.6 X_Server: ? Submission from: (NULL) (199.74.167.132) I've used SloppyFocus as my default window focus for a long time. Since our sys-admin upgrading to 2.4 recently (and after migrating my .fvwm2rc of course) I notice that after changing desktops, when moving my mouse quickly back into the window that last had the focus before I switched desktops, focus does not aquire properly. I have to move my mouse out of the window and back in again so make it work. I'm now using MouseFocus as my default window focus style and it work fine that way. Could you try to give me detailed instructions on how to reproduce this? The problem seems to be timing related and I don't know exactly what I have to do (please include your config file and also describe where the used windows are). 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/750
On Mon, Jul 30, 2001 at 05:38:53AM -0500, fvwm-bug wrote: FVWM Bug Tracking notification new message incoming/750 Message summary for PR#750 From: [EMAIL PROTECTED] Subject: FvwmButtons button update Date: Mon, 30 Jul 2001 05:38:52 -0500 0 replies 0 followups Hi. In my FvwmButtons I have four buttons that display the led status. These buttons contain the titles mse, num, cap and cze and swallow xkbvleds windows. The problem is that when FvwmButtons start, the titles are drawn in the vertical center, and when the swallowed windows appear, the title is repositioned without clearing the previous. Fixed. 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: What to do for next release?
On Sat, Aug 04, 2001 at 08:36:27PM +0700, Dmitry Yu. Bolkhovityanov wrote: BTW, would it be possible to make --enable-multibyte a default in 2.4.1? As I understand, most of the people are lucky with 8859-1, but that's not the case for us, koi8-r'ers. In most of the modern apps (Netscape is most popular) russian titles are displayed as raw 2022 strings, i.e. the titles are interweaved with koi8-r strings and 2022 escapes. (Sure, my students now better understand how i18n works in X, but I'd prefer them to use their time for other work.) Is there something critical and untested in multibyte code? The whole multibyte support is basically untested :-) I can't remember the minute details, but there are several places where internationalised strings are not yet handled. Then there was this font problem you reported a while ago. Finally, it's implemented using dozens of ifdefs all over the code. This can not be the final solution. A library like implementation like the Xinerama library is needed. This includes a font/fontlist management module that hides the details from the caller. 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: * New condition AcceptsFocus.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/08/05 07:12:24 Modified files: . : ChangeLog NEWS docs : ChangeLog FAQ fvwm : conditional.c fvwm.h fvwm2.1 modules: ChangeLog modules/FvwmButtons: FvwmButtons.c modules/FvwmPager: FvwmPager.c sample.fvwmrc : new-features system.fvwm2rc system.fvwm2rc-sample-1 system.fvwm2rc-sample-2 system.fvwm2rc-sample-95 Log message: * New condition AcceptsFocus. * Fixed redrawind of button titles w/ swallowed windows (bug #750). * Fixed Parsing of Font and SmallFont options in FvwmPager (bug #754). -- 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: xfm and moxfm: Once more unto the breach...
Bob Woodside wrote: Dominik Vogt wrote: Anyway, if you send me your sample program I'll have a look at the problem. Erm...it was attached to the last email. However, ignore it. I'll send you a revised version, if you like, that reveals more information. Here's what it shows. The Leave/Enter events are semi-spurious. They occur (in that order) between every Btn1Down and Btn1Up, and they have mode = NotifyGrab and mode = NotifyUngrab, respectively. This happens when the pointer gets grabbed away from the window it's currently in. It looks like we're grabbing way too often - or possibly even doing the whole focus thing too often - on every single click. This should happen only on the first click needed to transfer focus to the window, not on subsequent clicks when the window already has the focus. It confuses the Xt lib routines that handle double click detection. On further investigation, I can't see any extra grabs occurring. But upon looking at the changes in events.c (HandleEnterNotify and HandleLeaveNotify), I see you've been wrestling with this general problem already, a few months ago. It looks as though we may have some more fine-tuning to do in that area. I'm attaching the revised version of the test program - it's really little more than a textbook example that *should* work as is. Cheers, Bob dblclktst2.tar.gz Description: GNU Zip compressed data
Re: [Fwd: (Review ID: 128437) multi-byte chars ((B) sent to title bar of windows]
To date, this bug has 2 votes. I don't think Sun is getting the message that Java users want Java to work with Fvwm. It only takes a few minutes to register and vote. While you are there, you might consider voting for 4401846 also. This one has 10 votes, but a few more won't hurt. Keith Spainhour [EMAIL PROTECTED] writes: Hi fvwm developers, Here is the bug info sun has returned to me inregards to the multi-byte chars appearing in the title string. Vote for it on sun web page once it shows up. Maybe they'll fix it. Keith Spainhour -- Date: Thu, 19 Jul 2001 11:03:11 -0700 (PDT) From: Paul [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: (Review ID: 128437) multi-byte chars ((B) sent to title bar of windows Hi Keith Spainhour, The bug report you submitted has been determined to be a new bug. It has been entered into our internal bug tracking system with the assigned Bug Id: 4481877. The state of the bug can be monitored via the The Java Developer Connection Bug Parade at: http://developer.java.sun.com/developer/bugParade/index.jshtml It may take a day or two before your bug shows up in this external database. The Java Developer Connection is a free channel that is maintained by staff here at Sun. Access this web page to join: http://developer.java.sun.com/servlet/RegistrationServlet The home page for the Java Developer Connection is: http://java.sun.com/jdc Regards, Paul -- Dan Espen 444 Hoes Lane Room RRC 1C-214 E-mail: [EMAIL PROTECTED] Piscataway, NJ 08854 Phone: (732) 699-5570 -- 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: Pegasus Mail
Open you fvwm folder, and choose sort by threads. You can also ctrl-click on the subject header, and it will sort by threads. Mike On 5 Aug 2001, at 13:48, Dominik Vogt wrote: On Sat, Aug 04, 2001 at 01:31:56PM +, Mikhael Goikhman wrote: Dmitry, you use Pegasus Mail. I don't know whether you noticed, but this mailer is the only one (there is also /bin/mail) that does not support threads. When you get dozens of emails daily, threads are essential. Most mailers (I can list 20) support In-reply-to: header (used to show threads), some also support References: header (this is used by mail archives to add links to related messages, usually to all parents). Take a look at http://www.hpc.uh.edu/fvwm/archive/0107/threads.html . You always start a new thread although most of messages are Re: ones. Perhaps you should consider using mutt. It can even identify the correct thread without one of those headers (I guess it's using the subject). Although it's not perfect (such mails are always shown as a reply to the first mail in the thread), at least you get the mails sorted into threads: Jul-29 To fvwm-workers What to do for next release? Jul-30 To fvwm-workers |- Aug-02 To fvwm-workers | `- Aug-04 To fvwm-workers | `- Aug-04 To fvwm-workers `* The last line shows a reply without thread information (indicated by the asterisk). 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] --- [EMAIL PROTECTED] To obtain my PGP public key, mail SEND PUB KEY in the subject 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: Pegasus Mail
On 05 Aug 2001 13:48:04 +0200, Dominik Vogt wrote: On Sat, Aug 04, 2001 at 01:31:56PM +, Mikhael Goikhman wrote: Dmitry, you use Pegasus Mail. I don't know whether you noticed, but this mailer is the only one (there is also /bin/mail) that does not support threads. When you get dozens of emails daily, threads are essential. Most mailers (I can list 20) support In-reply-to: header (used to show threads), some also support References: header (this is used by mail archives to add links to related messages, usually to all parents). Take a look at http://www.hpc.uh.edu/fvwm/archive/0107/threads.html . You always start a new thread although most of messages are Re: ones. Perhaps you should consider using mutt. It can even identify the If you press 'h' in your mutt, you will see that I am using mutt. correct thread without one of those headers (I guess it's using the subject). Although it's not perfect (such mails are always shown as a reply to the first mail in the thread), at least you get the mails sorted into threads: Jul-29 To fvwm-workers What to do for next release? Jul-30 To fvwm-workers |- Aug-02 To fvwm-workers | `- Aug-04 To fvwm-workers | `- Aug-04 To fvwm-workers `* The last line shows a reply without thread information (indicated by the asterisk). I know that mutt guesses that a message belong to a thread by its subject and adds it to the end of thread. But this does not help for comunication. Consider a not very complex tree: 1350 Jul-22 Dominik Vogt(2.9K) Some subject 1351 Jul-22 Mikhael Goikhman(3.7K) |- 1352 Jul-22 Dan Espen (2.7K) | |- 1353 Jul-22 Mikhael Goikhman(1.3K) | | `- 1354 Jul-22 Dominik Vogt(6.7K) | `- 1355 Jul-22 Dmitry Yu. Bolkhovi (7.5K) `* 1356 Jul-22 Dominik Vogt(4.9K) `- There is no any chance to know whether 1355 is a reply to Dominik, Dan or me (and if to me, to which message) if a mailer does not supply this info. It is unfortunate that someone uses closed non-standard mailer, that breaks a thread into 2 threads exponentially every time a message is sent. I would just patch it and not whine. Now I can only suggest to switch. 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: Pegasus Mail
On 4 Aug 2001, at 13:31, Mikhael Goikhman wrote: Dmitry, you use Pegasus Mail. I don't know whether you noticed, but this mailer is the only one (there is also /bin/mail) that does not support threads. When you get dozens of emails daily, threads are essential. Most mailers (I can list 20) support In-reply-to: header (used to show threads), some also support References: header (this is used by mail archives to add links to related messages, usually to all parents). Take a look at http://www.hpc.uh.edu/fvwm/archive/0107/threads.html . You always start a new thread although most of messages are Re: ones. Is it an option to change your mailer to a more standard-compliant one? I can suggest pine for DOS, but there are more (I didn't use any though). I know it may be a pain. But it was your decision (a bad decision :) ) to use a non free software, patching a free program to set In-reply-to: header in replies should not take more than an hour. P.S. I remember pmail in 1993, a nice colorfull pseudographics text toy. As a member of the Pegasus Mail tech support team, I do take exception to that remark. Pegasus Mail is live well, and works just fine. You will find it supports In-reply-to headers. It is considered the most RFC compliant mail-tool on the market. Most of its problems have to do with non-compliant messages from outlook. (basically forcing non-compliance so that other mail tools are not compatable). (And its free!!) Pause...While I go scan headers Eee Gads. Dmitry. You are using Pegasus Mail 3.50 for Dos??? Alas, that version is no longer supported. The lastest version is 3.12c for windows. Version 4.0 is due out within the next several weeks (that is the version I am using now). You should seriously consider upgrading (www.pmail.com). But, if DOS is the requirement 3.50 should work just fine for you. I'll check to see if 3.50 supports reply- to. Mike --- [EMAIL PROTECTED] To obtain my PGP public key, mail SEND PUB KEY in the subject 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]
Proposing a new if-else syntax
On 05 Aug 2001 13:34:02 +0200, Dominik Vogt wrote:
How about this enhancement to conditional commands:
Next (conditions) { false-action } true-action
This would allow an else case in all conditional commands
without the need to store a return code of these commands. For
example:
AddToFunc ToggleWindow
+ I Next ($0) { Exec $0 } Close
This may work, but is this the best possible solution? This syntax is not
very readable and having else-command before then-command does not make it
better. As before there is still a limit to one command in both branches,
so you are forced to create small functions without a real need. It also
adds a problem of escaping curly brackets in else-command when needed.
What about parsing of nested conditional commands, braces in braces? :)
It seems that an idea of 2 commands on the same line is not very good.
Here is my revised proposal that solves all problems described above.
There are 2 constructs, one is long and one is short, both may be mixed:
if Next (conditions) {
then-commands, one per line
}
else {
else-commands, one per line
}
if Next (conditions) then-command
else else-command
Other one-or-zero-window commands may be used instead of Next as well:
Prev, Current and None. The default if not specified is Current.
The rules are similar to C, else belongs to the last if, braces may
be used to change this. else part is optional. Indentation is optional.
The { may only appear in if or else line, } should be on its own.
The syntax seems to be unambiguous, but a more formal proof is needed.
Here is a long example demostrating the syntax that may be used with
FvwmEvent add_window:
# when a new window appears do the following with it
if (Netscape: *) {
# this Certification logic is from my real config
if (Netscape: Certificate Authority Is Expired) {
WarpToWindow 310p 330p
FakeClick depth 0 wait 200 press 1 wait 100 release 1
}
# warp to Question, so Find dialog does not lose focus
if (Netscape: Question) WarpToWindow 20p 70p
elsif (Netscape: Find) {
if Next (Netscape: my page) {
Next (Netscape: Find) AnimatedMove 40 40
}
}
}
elsif (Terminal) {
AnimatedMove +100 -0 # gnome-terminal lacks position
WarpToWindow 50 10p
}
elsif (Annoying Window) {
Delete # try to delete it nicely first
if Next (Annoying Window) Destroy
}
elsif (Unimportant Window) Lower
elsif WindowId $w (!AllowsFocus) {
if WindowId $w (XClock) {
# force only one xclock, close all previous ones
WindowId $w Layer +1
All (XClock, Layer) Close
WindowId $w Layer -1
}
# individual window Style implementation is only in plans
Style (Id $w) CirculateSkip
}
For a comparision, try to implement the same logic using the suggested
Next (conditions) { else-command } then-command syntax, and count how
many functions you should create. Which one is more readable?
There are 5 new commands if, else, elsif, { and } in this
proposal. No existing command syntax is changed, which is an advantage.
The problem here is psychological, we all know that to add a command, some
prefix like + should be used. We got used to a limiting syntax. :)
Other news is that now a command may be ignored if it's in false branch.
Here are some problems to think about, some are easily solvable, some not.
If someone forgets to close a brace he gets an error at the end of file.
FvwmConsole may handle and show the level of if in the prompt.
What happens if modules try to send command groups concurently. They
will be mixed, just like now if modules try to define menus and functions
concurently bad things happens. So this is not really a new problem.
It should be thought more of course. But implementing this is not hard.
The commands { and } used to group other commands may be used in other
places too if we accept this idea.
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: Notification: incoming/754
On Sat, Aug 04, 2001 at 11:24:37AM -0500, fvwm-bug wrote: FVWM Bug Tracking notification new message incoming/754 Message summary for PR#754 From: [EMAIL PROTECTED] Subject: FvwmPager font name quoting Date: Sat, 04 Aug 2001 11:24:36 -0500 0 replies 0 followups Full_Name: Mark Hanson Version: 2.4.0 CVS_Date: OS: RedHat 6.2 X_Server: XFree86 4.0.3 Submission from: (NULL) (24.8.175.229) *FvwmPager: SmallFont -*-comic sans ms-medium-r-*-*-14-*-*-*-*-*-*-* doesn't work with the quotes included, but it does without the quotes. This worked fine with the quotes in 2.2.5. DefaultFont requires quotes around this font string, so it seems that *FvwmPager: SmallFont should at least allow them. Oops! It seems that we forgot to rewrite the SmallFont option when we reworked the syntax of the Font option. I will commit a fix soon. It will become available with 2.4.1 or tomorrow's snapshot. 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: * Replaced XineRamaEnable/Disable commands with plain Xinerama.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/08/05 19:20:36 Modified files: . : ChangeLog NEWS todo-xinerama fvwm : commands.h functions.c functions.h fvwm2.1 move_resize.c move_resize.h virtual.c libs : Makefile.am WinMagic.c XineramaSupport.c XineramaSupport.h fvwmlib.h modules: ChangeLog modules/FvwmButtons: FvwmButtons.c modules/FvwmDragWell: fvwmDragWell.c modules/FvwmForm: FvwmForm.c modules/FvwmIconBox: FvwmIconBox.c modules/FvwmIconMan: fvwm.c readconfig.c modules/FvwmPager: FvwmPager.c FvwmPager.h modules/FvwmTaskBar: FvwmTaskBar.1 FvwmTaskBar.c Goodies.c List.c List.h modules/FvwmWharf: FvwmWharf.c Log message: * Replaced XineRamaEnable/Disable commands with plain Xinerama. * New commands MoveToScreen. * NewFvwmTaskBar options PageOnly and ScreenOnly. * Full Xinerama support in TaskBar, Pager, IconBox, Wharf. * Xinerama placement in FvwmIconMan. * Fixed Xinerama placement w/ negative geometries. * Fixed button grabbing in FvwmTaskBar. * Fixed negative geometries in FvwmWharf. -- 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/751
On Wed, Aug 01, 2001 at 03:50:43AM -0500, fvwm-bug wrote: FVWM Bug Tracking notification new message incoming/751 Message summary for PR#751 From: [EMAIL PROTECTED] Subject: FvwmIconBox dies on starting acroread/netscape Date: Wed, 01 Aug 2001 03:50:42 -0500 0 replies 0 followups FvwmIconBox dies on starting either acroread or netscape (versions: acroread 4.05, netscape 4.77). I couldn't find any other program causes the the same result (up to now). Everything else works fine. The following error message is given in the log when FvwmIconBox dies: FvwmIconBox: Cause of next X Error. Error: 2 (BadValue) Major opcode of failed request: 53 (CreatePixmap) Minor opcode of failed request: 0 Resource id of failed request: 0x0 Leaving a core dump now Fvwm V2.3.31 comes from SuSE 7.2, the other two versions (2.3.33 and 2.4.0) were compiled by myself. A drawback might be that the .fvwm2rc file has a long history and might contain entries which causes the probelem. But I couldn't find anything in the docs. The complete .fvwm2rc is attached at the end. Thank you a lot for you efforts, To the list: Is that the same problem that was fixed a while ago? 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]
