Thanks for your rapid response
"Matthew D. Fuller" <[email protected]> wrote:
>
> On Thu, Jun 25, 2015 at 05:03:57PM +0100 I heard the voice of
> Aaron Sloman, and lo! it spake thus:
> >
> > For some time I've been unable to use the 'font color' and
> > 'highlighting' menus in libreoffice (LO). Attempts to use them fail
> > the colour menu is not shown: something flashes on the screen,
> > suggesting a failed attempt to create something.
>
> FWIW, they come up for me fine too (LO 4.3.7, ctwm essentially-head).
I should have specified my LO version:
Version: 4.4.3.2
Build ID: 4.4.3.2-6.fc22
At some time in the past the font-colour menu in LO worked fine for me in CTWM.
I don't use it often enough to know when it stopped working!
If/when you upgrade to a newere LO it will be interesting to know if you
also find things stop working in ctwm.
> > This message in the xterm window from which I've invoked LO:
> >
> > (soffice:30121): Gdk-WARNING **: GdkWindow 0x480187f unexpectedly destroyed
> >
> > (soffice:30121): GLib-GObject-WARNING **: invalid unclassed pointer in cast
> > to 'GtkWidget'
>
> Yeah, I don't see how ctwm could have much effect on that... that's
> pretty deep down in gtk, and there isn't that much back-and-forth
> discussion between the app and the window manager, really. I'm not
> sure how we could screw up pointers inside the app...
I have the impression linux developers change too many things without good
reason.
I've just installed Openoffice rpms in this (un-tarred) directory:
Apache_OpenOffice_4.1.1_Linux_x86-64_install-rpm_en-GB.tar.gz
Apart from the stupidity that OO and LO both claim ownership of /usr/bin/soffice
(which meant I had rename the LO one, and use rpm --force to get OO to install)
I now have both working in Fedora 22 with ctwm.
OO allows me to change colours: the colour menu displays as a 2-D grid. But it
cannot save in docx format, so I have to use odt. When sharing files with people
who can't cope with odt I'll then have to read the files into LO and save as
docx, etc. Fortunately, none of this is required frequently. I can live with
this for now.
[AS]
> > I tried to recompile from http://www.ctwm.org/dist/ctwm-3.8.2.tar.xz
> > (May 2014) but I am no longer able to compile that.
> >
> > [axs@vig 3.8.2]# xmkmf
> > imake -DUseInstalled -I/usr/share/X11/config
> > /usr/bin/ld: i386 architecture of input file
> > `/usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../crt1.o' is incompatible
> > with i386:x86-64 output
>
> [...]
>
> > Determining if the C compiler works failed with the following output:
> [...]
> > Building C object
> > CMakeFiles/cmTryCompileExec2251071135.dir/testCCompiler.c.o
> > /usr/bin/cc -o
> > CMakeFiles/cmTryCompileExec2251071135.dir/testCCompiler.c.o -c
> > /usr/local/src/ctwm-test/3.6.5/ctwm/trunk/build/CMakeFiles/CMakeTmp/testCCompiler.c
> > Linking C executable cmTryCompileExec2251071135
> > /usr/bin/cmake -E cmake_link_script
> > CMakeFiles/cmTryCompileExec2251071135.dir/link.txt --verbose=1
> > /usr/bin/cc
> > CMakeFiles/cmTryCompileExec2251071135.dir/testCCompiler.c.o -o
> > cmTryCompileExec2251071135 -rdynamic
> > /usr/bin/ld: i386 architecture of input file
> > `/usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../crt1.o' is incompatible
> > with i386:x86-64 output
> [...]
[MDF]
> Yeah, see, none of that is even ctwm; that's just blowing up trying to
> compile a plain file inside the cmake 'configure'-ish process to
> evaluate the compiler. The imake barf looks similar; xmkmf didn't
> even complete, much less get to any ctwm stuff. That sounds like a
> hardcore b0rked toolchain. Can you even build a Hello World?
Yes, though for a very simple test I had to add -m32 after gcc for compiling on
a 64 bit machine. When I previously managed to build ctwm I may have been
running 32bit linux. Too many things are changing, some unnecessarily I suspect.
When I run that the font colour menu (2D grid of colours) works perfectly
with ctwm.
It looks as if the changes in LO have been made for spurious reasons.
I'll just have to put up with the fact that OO cannot save in docx
formats and use LO for the final conversion back to Microsoft format,
when needed. So I won't have to switch to OpenBox WM.
Later, if/when I have time I may try to probe more deeply.
Thanks for the feedback.
Aaron
