Summary: | app-text/xpdf doesn't work correctly with openmotif, only lesstif works | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michael Siebert <michi2k> |
Component: | Current packages | Assignee: | Printing Team <printing> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
a screenshot of the original bug
xpdf.png |
Description
Michael Siebert
2006-12-26 09:08:22 UTC
Created attachment 104757 [details]
a screenshot of the original bug
In my experience, and that of many other users, xpdf works even better with openmotif than lesstif, in fact I'm using that combination right now. The real cause for a lot of motif related problems is that motif-config is fundamentally broken. (The previous maintainer is well aware of these problems, but refused to acknowledge them before he left. Just do a bugzilla search from early 2005 till now on this subject.) Currently, the only reliable way is to unmerge all providers of the virtual/motif virtual, unmerge all packages depending on it and start over with exacactly 1 (one) motif library installed. (that would defeat the whole purpose of motif-config, but there you go.) The minute a second provider of virtual/motif is installed, everything is possible, including, but not limited to, cross-linkage between different motif libraries, compiling against headers of current motif-config selection but linking to random other (incompatible) motif library due to libtool being confused, pulling in one motif library directly and another one indirectly, etc., etc., etc. There is a nice analysis somewhere here, again please try and search bugzilla for more information. (In reply to comment #2) Confirmed, I have seen the exact same ComboBox behaviour some time ago, in Xpdf, and in other programs as well. The important thing is, you have to emerge Openmotif and Lesstif in a specific order and repeat from scratch if said order is disturbed during an update. DISCLAIMER: The following is not supposed to be an advertisement, just saying that neither Lesstif, Openmotif, nor Xpdf are at fault. If you're in France, Germany or Switzerland, there's a shop that offers commercial Motif support on Gentoo. Maybe a little pricey for home use, but they're offering a portage overlay with Openmotif, Lesstif, and all Motif apps that used to be, are, and will be in the future, in Gentoo, incl. security backports and guaranteed availability for 1, 2, 5, or more years. From what I've seen they're using a USE flag based Motif selection similar to what used to be in regular portage some years ago plus some advanced portage technology for better interoperability with non-gentoo binary-only stuff. Seeing that the above method works so well here, perhaps Gentoo should do the same? I have unmerged openmotif, lesstif and even motif-config. Then, I emerged openmotif and xpdf again (I didn't unmerge xpdf before, that's right, but I don't think it matters). The bug is there again! Can't be the solution. Created attachment 105118 [details]
xpdf.png
For comparison, here's a shot of what it's supposed to look like with
unbroken openmotif. Looks identical both with stock xpdf-3.01 and
Gentoo's 3.01-r8 (which for some reason reports itself as 3.0 and seems
to contain lots of ubuntuisms).
Is your DPI for X server sane? $ xdpyinfo |grep resolution I cannot confirm this bug with openmotif-2.2.3-r9 and xpdf-3.01-r8. All menus work as expected. What versions are you using? xdpyinfo |grep resolution delivers resolution: 81x86 dots per inch xpdf version: 3.01-r9 openmotif version: 2.2.3-r9:2.2 motif-config version: 0.9 (not the latest one, but stable) you should have my emerge --info As I said, I performed an emerge --unmerge openmotif lesstif motif-config xpdf emerge xpdf And the bug came again, since I used xpdf with lesstif Nothing to do with DPI. The problem is, due to mismatches between header version, compile time library version and runtime library version caused by this whole motif-config mess, when xpdf tries to set some unrelated resource, it really sets the visible item count on the combobox widget to some random value. (which, btw, gentoo's motif maintainer is fully aware of, but his reasoning for closing any bug reports is "there haven't been any complaints". Next time it's reported, "nobody else complained about it" ==> "everything is A-OK" ==> "FIXED", and so on..ad nauseam) And that is only one of many things that can (and will) go wrong. Trust me on this. We've been through this problem so many times on various client sites, I'm very surprised that this is the first time somebody reported this particular symptom. If you really need motif and lesstif at the same time (a lot of people do), currently the best way is to grab ebuilds from the mid-2004 era and add any later patches (minus the bogus ones) yourself, but be sure to select one that is not affected by bug #91951. That's what we do here. I didn't want to use anything in parallel, I just wanted to use xpdf with openmotif, so that it works correctly; nothing more. But I already switched to kpdf. It's not as obsolute as that xpdf motif-frontend, has a much better memory management and things look good and work correctly, so I am perfectly happy. Working with old and obsolete software is like taking care for old, senile people and I'm really fed up with it. (In reply to comment #2) > The real cause for a lot of motif related problems is that motif-config > is fundamentally broken. Right on spot... *** This bug has been marked as a duplicate of bug 147067 *** |