As described in the links below, the architecture board voted to bump the major version number of the libXaw library. http://freedesktop.org/pipermail/release-wranglers/2004-August/000970.html http://freedesktop.org/pipermail/release-wranglers/2004-September/000982.html
Created attachment 810 [details] [review] Xaw patch This patch bumps the major version number of libXaw and creates a frozen libXaw7 version as described on the architecture call (30 Aug 2004).
Actually assigning to myself this time.
Two questions: 1. The following change looks strage: -- snip -- --- programs/xdpyinfo/Imakefile 16 Aug 2004 16:36:15 -0000 1.5 +++ programs/xdpyinfo/Imakefile 2 Sep 2004 01:05:17 -0000 @@ -62,7 +62,7 @@ DMXLIBS = $(DMXLIB) #endif -#if BuildXprintLib +#if BuildXprintLib && BuildXprintClients XPRINTDEFINES = -DXPRINT XPRINTLIBS = $(XPLIB) #endif -- snip -- Both "xdpyinfo" and "xset" are more or less "generic" control applications and I am not sure whether the extra dependicy on |BuildXprintClients| is needed here... or is it ? 2. The changes to "xedit" and "xman" seem to be lost - should I fix that ?
(In reply to comment #3) > Two questions: > Both "xdpyinfo" and "xset" are more or less "generic" control applications and I > am not sure whether the extra dependicy on |BuildXprintClients| is needed > here... or is it ? It is needed for vendors who choose build clients that do not depend on Xprint. This is very important. > 2. The changes to "xedit" and "xman" seem to be lost - should I fix that ? I haven't gotten to those yet. I'm just going through all of the other bugs first. I already added the xlogo changes back in. I was going to start on adding the xedit and xman changes back in next. If you would like to do that, then that would be great. Otherwise, I'll take care of it in a little while.
Kevin E. Martin wrote: > (In reply to comment #3) > > Two questions: > > Both "xdpyinfo" and "xset" are more or less "generic" control applications > > and I > > am not sure whether the extra dependicy on |BuildXprintClients| is needed > > here... or is it ? > > It is needed for vendors who choose build clients that do not depend on > Xprint. > This is very important. Ah, OK... > > 2. The changes to "xedit" and "xman" seem to be lost - should I fix that ? > > I haven't gotten to those yet. I'm just going through all of the other bugs > first. I already added the xlogo changes back in. I was going to start on > adding the xedit and xman changes back in next. If you would like to do that, > then that would be great. I can do that... it will need around ~~75mins from now...
OK, I am done... I have one final nit: The code test for the CPP symbol |XPRINT| (better would be something like |BUILD_PRINTSUPPORT| (two words - just to avoid the xx@@!!-namespace cliff)) - which shouldn't be done since that symbol is already "in use" by the Xprint server side (and both sides shouldn't use the same CPP symbols - at least applications like Xnest will suffer from that) - can I fix that, too (I already avoided that for the xedit/xman code, but I see the same uglyness in the glxgears, xdpyinfo, xset, etc. code ;-(( ) ?
That's fine. Changing the defines from XPRINT to something else is easy to do. I'll do that when I check in your patch.
Okay, I've changed all of the #ifdef XPRINT to #ifdef INCLUDE_XPRINT_SUPPORT I'm also fixing some build problems with BuildServersOnly. I'll check these in after I finish the testing.
Created attachment 814 [details] [review] Restore original xedit, xman, etc. functionality (patch for 2004-09-02-trunk)
Comment on attachment 814 [details] [review] Restore original xedit, xman, etc. functionality (patch for 2004-09-02-trunk) Can I commit this patch, please ?
I am working on finishing up my patch, and then I will commit yours.
Okay, I've checked your patch in. It looked fine. I made a few minor changes to make xman and xedit use #ifdef INCLUDE_XPRINT_SUPPORT (for consistency) and to expose the print button (xedit) and the print menu option (xman) only when building with Xprint support.
Kevin: Can we close this bug or is there anything ToDo ?
Yes, this can be closed since the code has been checked in. Closing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.