Re: Is 257 some sort of magic number?
On Thu, 8 Aug 2002, Tim Phipps wrote:
[SNIP]
I can't help feeling that 257 is the wrong number for all this stuff and
256 is the correct number. It might be better to just leave most of
these things as unsigned shorts or pass XColor's around and convert to
byte size pieces as late as possible.
/257 will take ages on any processor, /256 will take one cycle on most.
257 is the correct scale factor for conversion between 8- and
16-bit colors: 257==0x101, so that e.g. 0xFF becomes 0x if multiplied
by 0x101, not 0x100. Most of XFree86 code uses 0x101 as conversion factor
(see xc/{lib/X11/LRGB.c,programs/xcmsdb/xcmsdb.c}. Of course, when
scaling from 16 down to 8 bits 256 will work almost as good as 257, but
unification-wise 257 is better.
_
Dmitry Yu. Bolkhovityanov
The Budker Institute of Nuclear Physics
Novosibirsk, Russia
--
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: Xft_LIBS in Makefile.am
On Mon, Aug 05, 2002 at 10:50:50PM -0500, Dave Trollope wrote: Hi I've been having problems building 2.5.3 recently (month or two) and tonight decided to figure it out. At some point the $(Xft_LIBS) in LDADD of several Makefile.am files eg fvwm/fvwm. On my system (cygwin) this causes a problem because -lfvwm is now after -lXft. Flocale.c in libfvwm uses Xft. Before submitting a patch for this, I was hoping someone could explain what this change was made for so that I can make sure I don't undo whatever they did! I did this inversion when I add Xft2 support. From the Changeog: * fvwm/Makefile.am: * libs/Makefile.am: Put $(Xft_CFLAGS) before $(X_CFLAGS) to be able to use an independent Xft2 library. Removed FT2 CFLAGS and LIBS So -lfvwm should be before -lXft but -lXft should be before $(X_CFLAGS) ? Patch welcome. Regards, Olivier -- 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 olicha: * Implemented a new color limit method
Hello, Sorry for the delay of the answer. I will try to answer to Dan,
Dimtry and Tim in this mail.
First I have a very basic video card: a neomagic card (I can run the
neomagic and the vesa XFree drivers).
Secondly, as Dimtry says and it is the most important point, any
server which support the render extension pre-allocate some colors
(and I think that the only way to avoid this is at XFree compile time
as render is a builtin extension). At depth 8, XFree-4.2 pre-allocate
244 colors (the 6x6x6 color cube + 28 grey) and a recent cvs version
pre-allocate 85 colors (the 4x4x4 color cube + 21 grey's). BTW it
seems that the grey are not used (by the render ext) in Pseudo Color
mode and the cube is not use in Gray Scale mode (maybe a bug ...).
There are no pbs with XFree-4.2 and gtk, imlib{2} and qt apps because they
all use the 6x6x6 color cube by default. There are problems with gtk-2 apps
(private colormap) and the XFree cvs because gtk want at least a 5x5x5
color cube (qt always use a 6x6x6 color cube plus an allocation in
the color map method if a color in the cube cannot be allocated. So
no pbs with qt but the render effort to do not waste the cmap at start
up is not useful).
I get no problems with all the app I can run by chance (and because
the 6x6x6 cc is a quite regular palette). But when I implement an
allocation in the color map method in fvwm I succeed to produce
problems (e.g., by changing my netscape bg color to a well chosen
one). Dan, please accept my apologies.
Finally, about xstcmap and the associated Xcms* Xlib functions,
I've rapidly read the doc and it seems that these stuff is for
private colormaps. Applications which want to use a private cmap
choose a (red, green, blue or regular) palette defined by xstcmap.
This allows apps to share the same palettes (but not the colors).
I've write down a new color limit method. I will comment more one
this soon.
Olivier
--
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/912
On Thu, Aug 08, 2002 at 11:34:38PM +0200, Matthias Clasen wrote: On Thu, 2002-08-08 at 19:26, Dominik Vogt wrote: When fvwm takes over from metacity, it seems to ignore the _NET_WM_DESKTOP properties left behind by metacity. Worse, windows which are not on the first desk sometimes get completely lost - they don't appear on any desk, but switching back to metacity makes them reappear at the right position. Could you point me to the spec and the specific place that states how the _NET_WM_DESTOP property should be handled? I'd assume the window manager is resposible of deleting this property from the client window and map all windows on all desks when it terminates. How else should the WM find out about windows that are not mapped when it starts and that are never mapped by the application? Yes, the leaving WM is responsible for mapping all windows (actually I think this is automatic as part of save-set handling). The CVS version of the EWMH 1.2 draft (still not available online...) specifies that the _NET_WM_DESKTOP and _NET_WM_STATE properties should be cleared upon withdrawal of a window, but left in place in case of loosing ownership of the manager selection, so that the next wm can pick them up. So, is the windows don't appear on any desk part a bug or not? Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe -- 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: * Discard an unused return code.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/08/09 05:05:08 Modified files: . : ChangeLog fvwm : add_window.c Log message: * Discard an unused return 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]
releasing 2.4.9?
It's time for another maintenance release in the stable branch. I can build that one myself, but it's not well tested yet. Although almost all fixes are identical to the fixes in the development branch, we should take a few days to thes 2.4.9 in real life. Everyone is asked to check out the stable branch and run it for a few days. Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe -- 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: * Updated ANNOUNCE for 2.4.9.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/08/09 05:19:48 Modified files: docs : Tag: branch-2_4 ANNOUNCE Log message: * Updated ANNOUNCE for 2.4.9. -- 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: Is 257 some sort of magic number?
Dmitry Yu. Bolkhovityanov wrote:
On Thu, 8 Aug 2002, Tim Phipps wrote:
/257 will take ages on any processor, /256 will take one cycle on most.
257 is the correct scale factor for conversion between 8- and
16-bit colors: 257==0x101, so that e.g. 0xFF becomes 0x if multiplied
by 0x101, not 0x100. Most of XFree86 code uses 0x101 as conversion factor
(see xc/{lib/X11/LRGB.c,programs/xcmsdb/xcmsdb.c}. Of course, when
scaling from 16 down to 8 bits 256 will work almost as good as 257, but
unification-wise 257 is better.
OK, I see. Multiplying by 257 is OK anyway since the compiler should
spit out a shift-or sequence but the conversion from 16 bit to 8 bit
should be a shift (or /256 which the compiler will change to a shift).
Cheers,
Tim.
--
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: * backported from 2.5.x
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: migo02/08/09 05:38:40 Modified files: . : Tag: branch-2_4 NEWS docs : Tag: branch-2_4 ANNOUNCE utils : Tag: branch-2_4 ChangeLog fvwm-menu-headlines.1 fvwm-menu-headlines.in Log message: * backported from 2.5.x -- 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 a compile error.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/08/09 06:57:55 Modified files: . : ChangeLog fvwm : add_window.c Log message: * Fixed a compile error. -- 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: web page (documentation maintainer wanted)
On Fri, Aug 09, 2002 at 11:10:02AM +0200, Dominik Vogt wrote: Maybe we can find a volunteer to vamp up the fvwm documentation by placing a job opening on our web page. What do you think about that? Yes, good idea. Olivier -- 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]
Notification: incoming/913
FVWM Bug Tracking notification new message incoming/913 Message summary for PR#913 From: [EMAIL PROTECTED] Subject: PRIVATE: an afterimage remains when movin a window Date: Fri, 09 Aug 2002 00:05:07 -0500 0 replies 0 followups ORIGINAL MESSAGE FOLLOWS From [EMAIL PROTECTED] Fri Aug 09 00:05:08 2002 Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 17d1xU-0004t5-00 for [EMAIL PROTECTED]; Fri, 09 Aug 2002 00:05:08 -0500 Received: from malifon.math.uh.edu ([129.7.128.13] ident=mail) by util2.math.uh.edu with esmtp (Exim 4.10) id 17d1xU-0006if-00 for [EMAIL PROTECTED]; Fri, 09 Aug 2002 00:05:08 -0500 Received: from localhost ([127.0.0.1] ident=65534) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 17d1xT-0004t1-00 for [EMAIL PROTECTED]; Fri, 09 Aug 2002 00:05:07 -0500 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: PRIVATE: an afterimage remains when movin a window Message-Id: [EMAIL PROTECTED] Date: Fri, 09 Aug 2002 00:05:07 -0500 Full_Name: Matsui Shuji Version: 2.4.3 CVS_Date: OS: Solaris8 X_Server: CDE Submission from: (NULL) (164.71.1.147) PGX64:in depth 32, an afterimage remains when moving a window(/usr/dt/bin/netscape, /usr/dt/bin/solregis) in fvwm2 or twm. Twm was corrected with 104945-02. Will you schedule the correction in fvwm? -- 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/912
On Fri, Aug 09, 2002 at 04:29:15PM +0200, Matthias Clasen wrote: So, is the windows don't appear on any desk part a bug or not? Yes, I consider that a bug, although I'm not sure if the problem is on Metacitys side or on fvwms. I'll do some more investigation and report back. The current draft of the EWMH is now online, btw. Matthias Where? Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe -- 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/912
On 09 Aug 2002 18:06:59 +0200, Dominik Vogt wrote: On Fri, Aug 09, 2002 at 04:29:15PM +0200, Matthias Clasen wrote: The current draft of the EWMH is now online, btw. Where? http://www.freedesktop.org/standards/wm-spec/ 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]
