Re: lyx-1.4.0pre2-qt-cygwin doesn't display characters
In <[EMAIL PROTECTED]>, Luis Rivera <[EMAIL PROTECTED]> typed: > In short, this port of LyX-Qt on Cygwin-X requires the Cygwin native python > interpreter, ImageMagick, ghostscript, and the jpeg and qt3 packages, plus the > Xserver scalable fonts. Apparently, LyX-Qt on Cygwin-X does posix style > searches for the conversion scripts, so it doesn't recognize the paths to > Windows native python, imgck or gs. Just out of curiosity, what happens if you add the appropriate directories to the PATH? Thanks, http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Re: Python script conversion
In <[EMAIL PROTECTED]>, [EMAIL PROTECTED] typed: > > The downside is that you wind up with one copy of Python installed for > > every script. If you've only got one script, this is ok. If you've got > > more than one, you probably want to consider another approach. > It will be the same, using several scripts, too. > > I have tried, I can do the following variant: > - place all the python scripts into the script dir > - create .exe files for the scripts > - create an archive file containing python > > In this case, you will have only one python packaged , but several small > scrits converted to .exe. Unless you're doing something strange, the process of creating the .exe files will put the python dll and copies of all the library files into the .exe. Are you doing something to prevent that? And if so - I'd be interested in knowing what. > A few converted scritps look like this: > PYTHON23 DLL 979 005 05.02.08 16.23 python23.dll > W9XPOPEN EXE16 384 05.02.08 16.24 w9xpopen.exe > LIBRARY ZIP 311 060 05.10.12 19.30 library.zip > LYX2LYX EXE40 960 05.10.12 19.30 lyx2lyx.exe > GENERA~1 EXE28 672 05.10.12 19.30 general_command_wrapper.exe > PIC2AS~1 EXE28 672 05.10.12 19.30 pic2ascii.exe > > So, they can use the same interpreter. This amounts to simply bundling the Python interpreter with LyX. I think that's a great option - in fact, I think someone should bundle up a complete system, with all the dependencies included - but I'm pretty sure that shouldn't be the only binary offering available. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Re: Python script conversion
In <[EMAIL PROTECTED]>, [EMAIL PROTECTED] typed: > Dears, > > I found that I could convert all the python script to .exe. > Thus I can remove Pyhthon dependecy. Are you sure? The only way I know of to convert a python script to .exe is with py2exe, which does it by creating an executable archive, and putting all the scripts that make up the program and the python interpreter in the archive. It doesn't remove the Python dependency so much as hide it. The downside is that you wind up with one copy of Python installed for every script. If you've only got one script, this is ok. If you've got more than one, you probably want to consider another approach. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Re: Bundle everything into lyx windows installer.
In <[EMAIL PROTECTED]>, Bo Peng <[EMAIL PROTECTED]> typed: > I personally do not *want* such a distribution since I am a linux > user. I was trying to tell lyx developers that current windows > installer is not good enough to attract windows users and suggest that > they make the installation process simpler by bundling some tools with > lyx. I think it would be better if someone who specialized in Windows did that, rather than distract the LyX developers with it. > Anyway, it is not possible at this stage to bundle things together. > That can happen only after the dependence on mingw and perl are > removed. I.e., after configure.m4 is replaced by configure.py. Why do you think we have to wait? Aren't all those things GPLed? If so, they can be bundled along with everything else. It just makes the bundlge bigger. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Re: Bundle everything into lyx windows installer.
In <[EMAIL PROTECTED]>, Bo Peng <[EMAIL PROTECTED]> typed: > The last question is that whether or not the developers are required, > or willing, to please these 'ignorant' windows users It doesn't matter whether or not they are willing - they are neither required nor necessary. Most of the tools involved are freely redistributable. So use the Linux model: Let the LyX developers keep doing what they are doing, while third parties bundle LyX with other tools to create a complete bundled application. This works for Linux and for Python; it ought to work for LyX. So, if you want such a distribution, you should feel free to create it. It would be nice if it could be hosted at lyx.org, but even that's not a requirement. If you can't, I'll donate space for it at mired.org. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Re: Bundle everything into lyx windows installer.
In <[EMAIL PROTECTED]>, Angus Leeming <[EMAIL PROTECTED]> typed: > Joachim Krieg wrote: > > I think the idea to make a bundle LyX installer is very interesting > > for people who start working with LyX. I know many people who will > > never try out LyX because installing it is very difficult for them. > > IMHO a bundled version of LyX would make it more easier and popular. > > For people who know enough about computers and software a bundle > > version isn't necessary. > I'm not adverse to the idea of an "intelligent" Windows installer that will > grab the necessary and extra stuff *that I ask it to* from the web. In > other words, a stub installer. However, writing such a thing will involve > quite some work and subsequent maintenance. > > One of the really difficult things in designing such a beast will be to > satisfy people like me and to also satisfy "ignorant users" who, > apparently, don't want to think about what they're putting on their > machine. You don't need to satisfy both sets of users. That's not the Windows way. In particular experienced users are willing to deal with the pain of "Follow the link, find the download site, choose the distribution, download and install it." They aren't in the audience we're trying to attract. We're trying to attract the users used to the huge windows package that includes everything, and lets them choose what they want at install time, and are willing to put up with the disadvantages of that in order to *not* have to deal with multiple products. Giving them that is straightforward (build a directory with everything in it, and preconfigure LyX to find everything in that directory), that's what we should give them. I admit that there's a lot of attraction to the idea of doing it "right". That's probably why ever Unix distros tools to do that. And if you do it, every Windows open source developer in the world would probably thank you. But Windows isn't about doing things right - it's about making the user happy. Unless someone steps up who's willing to do it right. LyX should settle for making the user happy. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Re: OpenDocument format
In <[EMAIL PROTECTED]>, Martin Vermeer <[EMAIL PROTECTED]> typed: > Another question is, whether it is worth the effort to make LyX do this if > good XML-to-XML transformation tools exist (do they yet?) Depends on how you define good. But XSLT is defined, available as a C library - with Python bindings if you want them - and was designed to do that job, among others. On the subject of making LyX use XML as a native format - please don't do that just because XML is the flavor of the month. Only do that if it buys something real. XML is mostly good as a standard for document interchange (it's used for lots of other things that it's not good as), which doesn't seem to be useful to LyX's native format. The other thing it buys you is the ability to use XML tools. Unless there's one that provides functionality that doesn't already exist in LyX, that's not a win either. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Re: Compile .py files to .exe under windows.
In <[EMAIL PROTECTED]>, Bo Peng <[EMAIL PROTECTED]> typed: > May it be a good idea to compile .py files to windows .exe files > under windows? Because you can't reaaly do that? The various .py->.exe tools available for windows just fake it. They bundle the byte-compiled python files and the python runtime up into an archive, and arrange things so that running the archive results in running the bundled python interpreter on the python progam in question. For an application, this is a win on Windows: the user gets to download a single package that includes everything they need to run the application. They get a copy of Python for every python-based application, but the tradeoffs seem acceptable for Windows developers. For a collection of programs, it doesn't work so well. Itj would involve putting one copy of the python interpreter into the distribution for every .py file. That's not really a good idea. It might be possible to create a LyX distribution for Windows that included a Python interpreter to handle the .py files. The Python license certainly allows that. I don't know enough about building distribution for Windows to say whether or not this is possible. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Re: Bugs in 1.4.0CVS for Mac OS X
In <[EMAIL PROTECTED]>, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> typed: > >>>>> "Mike" == Mike Meyer <[EMAIL PROTECTED]> writes: > Mike> "configure --help" says that won't work > What do you mean? "configure --help" gives lists of the subdirectories- "--bindir", "--datadir", etc. - with defaults that break things out in a way that is wrong for a MacIntosh .app directory. They're apparently wrong on the Mac. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Re: Bugs in 1.4.0CVS for Mac OS X
In <[EMAIL PROTECTED]>, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> typed: > Mike> Configure ignores (some of) the --datadir, --bindir and --mandir > Mike> options. I set them all to > Mike> /Users/mwm/Applications/LyX.app/Contents/... to install > Mike> 1.4.0CVSin ~/Applications, and "make intsall" still installed > Mike> things in /Applications. > You should use --prefix=/Users/mwm/Applications/ instead. "configure --help" says that won't work, but it does. Though you actually want "../Applications/LyX.app". The INSTALL.MacOSX (post-rename) needs to be fixed. Thanks, http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Re: Python version of configure script (preview version)
In <[EMAIL PROTECTED]>, Bo Peng <[EMAIL PROTECTED]> typed: > One problem with the rc approach is that re-configuration is required > whenever users change a filetype association. Also, opening a file > with its associated application is quite easy under windows. (There are APIs.) Since Bo Peng didn't provide context, I groveled it out by chasing down the message-id he's replying to. He is replying to a message pointing out how to dig information out of the windows registry. From what he says, I presume said information would be the type->viewer map, and that reconfig should store the appropriate viewer in the LyX preferences file. A reconfig isn't required. Until that's done, LyX will just use the "old" viewer. Who knows - that may even be the one the User wants? I know I don't want LyX to use my default web browser for View>HTML. On OS X, the solution is easy - you look for the "viewer" /usr/bin/open. If you find it, you use it. I've got an "open" for Unix that I've been using in LyX for the last week. I hope to have a version with enough features that it's useful for end users done this weekend. According to Jean-Marc Lasgouttes, you should use "start" on Windows. Is that an external application? If so, then LyX just needs to know how to launch external command line applications, so no changes are needed. configure will need to be taught to check for open/start, and use those for the viewer for everything if it finds them. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Bugs in 1.4.0CVS for Mac OS X
Readme.MacOSX refers to ftp://ftp.lyx.org/pub/lyx/stable/lyx-mac-1.3.5-skeleton.tar.gz. That file doesn't exist - it's actually a .zip file. Configure ignores (some of) the --datadir, --bindir and --mandir options. I set them all to /Users/mwm/Applications/LyX.app/Contents/... to install 1.4.0CVSin ~/Applications, and "make intsall" still installed things in /Applications. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
bugs in CVS build of 1.4.0
I couldn't find references to either of these in bugzilla, and I'm not sure one of them is a bug, so I'll post here. After making the appropriate gyrations with the environment of the configure command (see the thread "Errors building 1.4.0"), I got the CVS version to build. The configure script still has a bug in that it doesn't set LDFLAGS appropriately on my system even when it finds the qt library. First thing that happened when I tried to load a LyX document is that 1.4.0 complains that it can't find lyx2lyx. It's in the distribution. Shouldn't it have been installed? Second thing that I noticed was that clicking off the scroller in the horizontal scroll bar scrolls by one paragraph, not a page. This is *very* disconcerting! I think it's a bug, but it seems possible someone thought it was a good idea... Details on my environment: Configure command: bhuda% CPPFLAGS=-D_THREAD_SAFE LIBS=-pthread ./configure --with-frontend=qt --with-qt-dir=/usr/X11R6 --with-pspell --with-extra-libs=/usr/opt/lib --with-extra-inc=/usr/opt/include --with-pspell-lib=/usr/opt/lib --with-pspell-include=/usr/opt/lib/include buhda% uname -a FreeBSD bhuda.mired.org 5.4-STABLE FreeBSD 5.4-STABLE #9: Thu Aug 11 15:56:04 EDT 2005 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/BHUDA i386 bhuda% gcc --version ~/external-src/lyx-devel gcc (GCC) 3.4.2 [FreeBSD] 20040728 Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The only information I could find about qt is that it's version 3.3.4. It's installed from the FreeBSD ports system. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Re: Fwd: Re: Errors building 1.4.0 (?)
In <[EMAIL PROTECTED]>, Georg Baum <[EMAIL PROTECTED]> typed: > > Subject: Re: Errors building 1.4.0 (?) > > Date: Mittwoch, 14. September 2005 03:41 > > From: Mike Meyer <[EMAIL PROTECTED]> > > To: Georg Baum > > <[EMAIL PROTECTED]> > > CPPFLAGS=-D_THREAD_SAFE LIBS=-pthread ./configure --with-frontend=qt > Is it -pthread or -lpthread? I think the answer is "yes", but for two different platforms. From the gcc man page on FreeBSD: FreeBSD SPECIFIC OPTIONS -pthread Link a user-threaded process against libc_r instead of libc. IIRC, this has been the case since FreeBSD 3.0, and I'm currently running 5.4. It may be different on 6 or 7. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Re: Errors building 1.4.0 (?)
In <[EMAIL PROTECTED]>, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> typed: > > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: > > Georg> Am Dienstag, 13. September 2005 14:30 schrieb John Levon: > >> On Tue, Sep 13, 2005 at 09:24:07AM +0200, Georg Baum wrote: > It > >> looks like configure does not find the qt libary (but it seems to > >> find > the headers). This looks like a configure bug: It should > >> stop with an > error message if the library cannot be found. > >> > >> IIRC Lars changed this. > > Georg> I now remember that, too. I also remember that I added error > Georg> messages for moc and uic, so here comes the logical extension. > > Georg> Mike, could you please test whether configure aborts with this > Georg> patch (and without the other one) if it cannot find the qt > Georg> library? > > The patch looks good. Concerning the bug itself, could it be related > to > http://marc.theaimsgroup.com/?l=lyx-devel&m=112490112909207&w=2 Looks to be the same kind of problem. Both systems require magic flags at compile time to get to the threads versions of libraries, and the configure system isn't providing them. They are different flags, though. Since LyX checks for the non-threaded libraries, maybe the configure script should grow a "--with-thread-flags" option (or family of options), and only try the threads libraries if that (or one of them) is set? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Re: Errors building 1.4.0 (?)
In <[EMAIL PROTECTED]>, Georg Baum <[EMAIL PROTECTED]> typed: > Am Dienstag, 13. September 2005 14:30 schrieb John Levon: > > On Tue, Sep 13, 2005 at 09:24:07AM +0200, Georg Baum wrote: > > > It looks like configure does not find the qt libary (but it seems to find > > > the headers). This looks like a configure bug: It should stop with an > > > error message if the library cannot be found. > > > > IIRC Lars changed this. > > I now remember that, too. I also remember that I added error messages for moc > and uic, so here comes the logical extension. > > Mike, could you please test whether configure aborts with this patch (and > without the other one) if it cannot find the qt library? Ok, I installed just this patch. After doing autogen.sh and configure, it ends with the line "qt library not found." So you've fixed that bug. Now, I'll keep trying to build the thing. Thanks, > Georg > Index: ChangeLog > === > RCS file: /usr/local/lyx/cvsroot/lyx-devel/ChangeLog,v > retrieving revision 1.1023 > diff -u -p -r1.1023 ChangeLog > --- ChangeLog 18 Jul 2005 15:49:56 - 1.1023 > +++ ChangeLog 13 Sep 2005 14:23:16 - > @@ -1,3 +1,8 @@ > +2005-09-13 Georg Baum <[EMAIL PROTECTED]> > + > + * configure.ac: error out if qt frontend is choosen but no qt library > + was found > + > 2005-07-18 Lars Gullik Bjønnes <[EMAIL PROTECTED]> > > * configure.ac: version back to 1.4.0cvs > Index: configure.ac > === > RCS file: /usr/local/lyx/cvsroot/lyx-devel/configure.ac,v > retrieving revision 1.58 > diff -u -p -r1.58 configure.ac > --- configure.ac 18 Jul 2005 15:49:57 - 1.58 > +++ configure.ac 13 Sep 2005 14:23:16 - > @@ -216,6 +219,9 @@ dnl qt build will fail without moc or ui > fi > if test -z "$UIC"; then > LYX_ERROR([uic binary not found !]) > + fi > + if test -z "$QT_LIB"; then > + LYX_ERROR([qt library not found !]) > fi >;; > *) -- Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Re: Errors building 1.4.0 (?)
[Apologies to George, who's seeing this twice.] In <[EMAIL PROTECTED]>, Bennett Helm <[EMAIL PROTECTED]> typed: > On Sep 13, 2005, at 10:03 AM, Mike Meyer wrote: > > the configure script walks your $PATH looking for sgmltools and/or > > db2dvi to decide whether or not to configure docbook support. Fink > > probably put those in /sw/bin. > > If that's the case, you need to add /sw/bin the path used by LyX. On > > tiger (sorry, I'm a Mac newbie and haven't dealt with anything else) > > you edit ~/.MacOSX/environment.plist. There's a GUI plist editor > > available, but the file is just XML text, so you can use your favorite > > text editor on it as well. > Actually, if all you want is to add /sw/bin to the path that LyX > uses, you should do it from within LyX itself: LyX > Preferences > > PATH > PATH Prefix. (For LyX/Mac-1.3.6, the default settings already > have /sw/bin there.) If you add something to the PATH setting in > ~/.MacOSX/environment.plist, that will apply to *every* OS X > application, which is probably overkill and potentially a security risk. Whether or not it's overkill depends on how many applications you have that want to use programs from fink (or, in my case, darwinports). I have a couple, so doing things this way is easier for me. I found this method while trying to figure out why LyX wasn't finding my darwinports software. That I didn't find the LyX > Preferences > PATH > PATH Prefix methods suggests a doc bug. This appears to be a Mac issue - I don't find the PATH entries in preferences in 1.3.5 on my Unix box. Might just be my not having taken time to read the docs properly, though. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Re: Errors building 1.4.0 (?)
In <[EMAIL PROTECTED]>, Georg Baum <[EMAIL PROTECTED]> typed: > Mike Meyer wrote: > > Looking over this, it's a link command - except that I don't see a qt > > library being linked in. Grovelling through config.status finds: > > "s,@QT_LIB@,,;t t", which sure looks like it didn't set the QT library > > properlty. > It looks like configure does not find the qt libary (but it seems to find > the headers). This looks like a configure bug: It should stop with an error > message if the library cannot be found. > Could you please post the lines of config.log where it searches for the qt > library? (around the message "checking for Qt library name"). Sure: configure:24202: checking for Qt library name configure:24247: g++ -o conftest -g -O -I/usr/X11R6//include -L/usr/X11R6//lib -I/usr/opt/include -Wextra -Wall-I/usr/X11R6/include conftest.cc -lSM -lICE -lc -lm -L/usr/X11R6/lib -lX11 -lqt-mt >&5 /usr/X11R6//lib/libqt-mt.so: undefined reference to `pthread_cleanup_pop' /usr/X11R6//lib/libqt-mt.so: undefined reference to `pthread_attr_destroy' /usr/X11R6//lib/libqt-mt.so: undefined reference to `pthread_attr_init' /usr/X11R6//lib/libqt-mt.so: undefined reference to `pthread_exit' /usr/X11R6//lib/libqt-mt.so: undefined reference to `pthread_cancel' /usr/X11R6//lib/libqt-mt.so: undefined reference to `pthread_testcancel' /usr/X11R6//lib/libqt-mt.so: undefined reference to `pthread_cleanup_push' /usr/X11R6//lib/libqt-mt.so: undefined reference to `pthread_attr_getschedpolicy' /usr/X11R6//lib/libqt-mt.so: undefined reference to `pthread_attr_setinheritsched' /usr/X11R6//lib/libqt-mt.so: undefined reference to `pthread_attr_setstacksize' /usr/X11R6//lib/libqt-mt.so: undefined reference to `pthread_attr_setschedparam' /usr/X11R6//lib/libqt-mt.so: undefined reference to `pthread_attr_setdetachstate' /usr/X11R6//lib/libqt-mt.so: undefined reference to `pthread_cond_timedwait' configure:24253: $? = 1 configure: failed program was: [listing of failing program elided] configure:24247: g++ -o conftest -g -O -I/usr/X11R6//include -L/usr/X11R6//lib -I/usr/opt/include -Wextra -Wall-I/usr/X11R6/include conftest.cc -lSM -lICE -lc -lm -L/usr/X11R6/lib -lX11 -lqt-mt3 >&5 /usr/bin/ld: cannot find -lqt-mt3 configure:24253: $? = 1 configure: failed program was: [listing of failed program elded] configure:24247: g++ -o conftest -g -O -I/usr/X11R6//include -L/usr/X11R6//lib -I/usr/opt/include -Wextra -Wall-I/usr/X11R6/include conftest.cc -lSM -lICE -lc -lm -L/usr/X11R6/lib -lX11 -lqt3 >&5 /usr/bin/ld: cannot find -lqt3 configure:24253: $? = 1 configure: failed program was: [listing of failed program elded] configure:24247: g++ -o conftest -g -O -I/usr/X11R6//include -L/usr/X11R6//lib -I/usr/opt/include -Wextra -Wall-I/usr/X11R6/include conftest.cc -lSM -lICE -lc -lm -L/usr/X11R6/lib -lX11 -lqt2 >&5 /usr/bin/ld: cannot find -lqt2 configure:24253: $? = 1 configure: failed program was: [listing of failed program elded] configure:24247: g++ -o conftest -g -O -I/usr/X11R6//include -L/usr/X11R6//lib -I/usr/opt/include -Wextra -Wall-I/usr/X11R6/include conftest.cc -lSM -lICE -lc -lm -L/usr/X11R6/lib -lX11 -lqt >&5 /usr/bin/ld: cannot find -lqt configure:24253: $? = 1 configure: failed program was: configure:24289: result: failed configure:24306: checking whether the Qt library is multi-threaded configure:24345: g++ -o conftest -g -O -I/usr/X11R6//include -L/usr/X11R6//lib -I/usr/opt/include -Wextra -Wall-I/usr/X11R6/include conftest.cc -lSM -lICE -lc -lm -L/usr/X11R6/lib -lX11 >&5 /var/tmp//cc4P8UEz.o(.text+0x118): In function `main': /home/mwm/external-src/lyx-devel/conftest.cc:51: undefined reference to `QApplication::QApplica tion(_XDisplay*, unsigned long, unsigned long)' /var/tmp//cc4P8UEz.o(.text+0x123):/home/mwm/external-src/lyx-devel/conftest.cc:52: undefined re ference to `QApplication::unlock(bool)' /var/tmp//cc4P8UEz.o(.text+0x136):/home/mwm/external-src/lyx-devel/conftest.cc:55: undefined re ference to `QApplication::~QApplication()' /var/tmp//cc4P8UEz.o(.text+0x14c):/home/mwm/external-src/lyx-devel/conftest.cc:55: undefined re ference to `QApplication::~QApplication()' /var/tmp//cc4P8UEz.o(.gnu.linkonce.r._ZTV6QGList+0xc): undefined reference to `QGList::clear()' /var/tmp//cc4P8UEz.o(.gnu.linkonce.r._ZTV6QGList+0x10):/usr/include/c++/3.4/bits/basic_string.h :257: undefined reference to `QGList::~QGList()' /var/tmp//cc4P8UEz.o(.gnu.linkonce.r._ZTV6QGList+0x14):/usr/include/c++/3.4/bits/basic_string.h :532: undefined reference to `QGList::~QGList()' /var/tmp//cc4P8UEz.o(.gnu.linkonce.r._ZTV6QGList+0x18):/usr/include/c++/3.4/bits/stl_algobase.h :151: undefined reference to `QPtrCollection::newItem(void*)' /va
Errors building 1.4.0 (?)
I'm trying to build the CVS version for the first time. I used the page that google had cached from www.devel.lyx.org on getting LyX sources from CVS to get started. That page talks about building "the development module" but doesn't talk about what that is. The difference is that you run the autogen.sh script before doing the configure/make/make install dance. I did that. The build platform is FreeBSD 5.4-STABLE. That uses gcc 3.4.2. The configure args I used were "--with-frontend=qt --with-qt-dir=/usr/X11R6 --with-aspell -with-extra-lib=/usr/opt/lib -with-extra-inc=/usr/opt/include". The FreeBSD ports tree builds version 1.3.5 with no patches. I used the option it had to build with qt and aspell, and it adds the -with-extra-* arguments to configure when it builds 1.3.5. Since I'm using the same qt installation, I figured copying them couldn't hurt. The compile exits with a slew of missig references to Qt objects. The command that generated them and the first of them looks like this: g++ -fno-exceptions -g -O -o lyx-qt main.o Bidi.o BufferView.o BufferView_pimpl.o Bullet.o Bran chList.o Chktex.o CutAndPaste.o DepTable.o FloatList.o Floating.o FontIterator.o FuncStatus.o I nsetList.o LColor.o LaTeX.o LaTeXFeatures.o LyXAction.o MenuBackend.o ParagraphParameters.o Pri nterParams.o Spacing.o Thesaurus.o ToolbarBackend.o author.o boost.o box.o buffer.o buffer_func s.o bufferlist.o bufferparams.o bufferview_funcs.o changes.o chset.o converter.o counters.o coo rdcache.o cursor.o cursor_slice.o debug.o dimension.o dociterator.o encoding.o errorlist.o expo rter.o gettext.o factory.o format.o funcrequest.o graph.o importer.o intl.o insetiterator.o kbm ap.o kbsequence.o language.o lastfiles.o lengthcommon.o lyx_cb.o lyx_main.o lyx_sty.o lyxfont.o lyxfind.o lyxfunc.o lyxgluelength.o lyxlayout.o lyxlength.o lyxlex.o lyxlex_pimpl.o lyxrc.o ly xrow.o lyxrow_funcs.o lyxserver.o lyxsocket.o lyxtextclass.o lyxtextclasslist.o lyxvc.o message s.o metricsinfo.o mover.o output.o outputparams.o output_docbook.o output_latex.o output_linuxd oc.o output_plaintext.o paragraph.o paragraph_funcs.o paragraph_pimpl.o pariterator.o ispell.o SpellBase.o rowpainter.o sgml.o tabular.o tex-accent.o tex-strings.o texrow.o text.o text2.o te xt3.o toc.o trans.o trans_mgr.o undo.o vc-backend.o version.o vspace.o mathed/.libs/libmathed. a insets/.libs/libinsets.a frontends/.libs/libfrontends.a frontends/qt2/.libs/libqt2.a -L/usr/X 11R6//lib frontends/controllers/.libs/libcontrollers.a graphics/.libs/libgraphics.a support/.li bs/libsupport.a ../boost/libs/regex/src/.libs/libboost_regex.a ../boost/libs/signals/src/.libs/ libboost_signals.a ../boost/libs/filesystem/src/.libs/libboost_filesystem.a ../intl/libintl.a - lSM -lICE -lm -L/usr/X11R6/lib -lX11 -lz frontends/qt2/.libs/libqt2.a(Alert_pimpl.o)(.text+0x150): In function `prompt_pimpl(std::string const&, std::string const&, int, int, std::string const&, std::string const&, std::string cons t&)': /usr/X11R6//include/qapplication.h:451: undefined reference to `QApplication::focus_widget' Looking over this, it's a link command - except that I don't see a qt library being linked in. Grovelling through config.status finds: "s,@QT_LIB@,,;t t", which sure looks like it didn't set the QT library properlty. I could probably figure this out myself - except it's 3am, and I've been fighting recalcitrant hardware all night. I'm going to sleep, then to work, and with luck and help from you all, I'll find a solution in my mailbox tomorrow evening. Thanks, http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Re: Change in pdf viewer search order?
In <[EMAIL PROTECTED]>, Georg Baum <[EMAIL PROTECTED]> typed: > Jose' Matos wrote: > > > Better than that we should have some kind of profile configuration, so > > that > > if I choose kde as my preferred desktop environment I get kpdf, if I > > choose gnome I get evince and if I choose plain X I get xpdf, wind users > > get ... > > > > That would allow a coherent set of first choices to the viewers, what we > > have now is a mess. > > I agree, but since this is not 1.4.0 stuff, I filed it in bugzilla: > http://bugzilla.lyx.org/show_bug.cgi?id=2017 If it's not appropriate to talk about non 1.4.0 stuff at this time, I apologize. But I've been thinking about this, and would like to get feedback. Answers off-list if you feel that's required. This is a hard problem in general. How is the data stored, how does the user edit it, what do we do on failure, and so on. It's harder on Unix than on OS X or Windows, because the answer changes depending on whether or not $DISPLAY is set. However, LyX doens't need to worry about any of that. It needs two things. Well, three: 1) A way to get an arbitrary file. 2) A way to find out if files with a given extension can be displayed by this tool. 3) A way to check that it's got the right tool. If we provide a tool that covers those things, we can change it later to make it "right". This seems like a generally useful tool, so I'm going to implement a first cut over the weekend. The command will be called "open". I prefer it to "start", but am open to other suggestions. If you invoke it with a single argument, it uses the extension on the argument to search for an application, and then said application is asked to open the argument. That's point 1. If invoked as "open -q ext", it does the same search, except it exits with success if it knows how to open files with extension ext, and exits with failure if it doesn't. That's point 2. If invoked with "open --open-protocol" it will print a numeric version number followed by a string of single-character options that it understands. This lets applications that are trying to do what lib/configure does verify that they have something that understands the "-q" option as described herein. That's point 3. The changes to lib/configure are to search $PATH for "open", and if it finds one do "open --open-protocol" to see if it understands the "-q" option. If it doesn't, keep searching. If it does, save the full path for future reference. If configure has a path to an open, configure will ask open whether it knows how to deal with file types of the appropriate extension before searching the list of applications for that file type. If open answers yes, then that "open" becomes the application to use for this file type. If the answer is no, configure does what it does now. Comments? Questions? Feedback? Anyone think the proposed changes to configure would be worth making to committing (I'll probably make them as a test of open)? Thanks, http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Re: Change in pdf viewer search order?
In <[EMAIL PROTECTED]>, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> typed:
> > "Jose'" == Jose' Matos <[EMAIL PROTECTED]> writes:
> Jose'> This is precisely the point. We always took a neutral stance
> Jose'> on this although more and more unix is linux. Are we ready to
> Jose'> take the next step?
> Sure we are. But what would be the right solution on a modern unix.
> What is the step?
I think the right solution is awaiting discovery. Let's consider some
things that have been tried in the past.
The historical solution is to check the environment. If we provided a
viewer for ASCII, the correct program would be ${VISUAL:-EDITOR} (if
you could assume it worked in an X environment). Python's webbrowser
module uses $BROWSER.
I believe mailcap is pretty much dead. Most browsers provide their own
tools for setting helper applications, and seem to ignore mailcap. For
our application - where we know the extension on the file - mailcap is
the wrong solution anyway.
Even if you have something like "open", you need to provide an
escape. $BROWSER is *not* the browser I want LyX using to view HTML
(neither is configure's choice of Mozilla). Apple realized this, and
allows you to pass an application to open with "-a". Except that "open
-a application URL" always uses the default browser, a fact I curse a
couple of times week.
If we come up with a good solution as a standalone application, it'd
probably get picked up by other applications that need this
capability.
http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
Change in pdf viewer search order?
The default search list for a pdf previewer (in lib/configure.m4) goes gv ghostview xpdf, or some such - xpdf is definitely last. xpdf is a *much* nicer pdf previewer than ghostview. I'd like to suggest that it be moved in front of the two ghostview entries. Thanks, http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
