The attached patch fixes a small bug in the dvi2 format entry
as written to lyxrc.defaults by configure.py in 1.4.x
--
Enrico
Index: lib/configure.py
===
--- lib/configure.py(revision 13943)
+++ lib/configure.py(working copy)
you could disable it by defining BOOST_ALL_NO_LIB, and then
linking against the libs generated by your build process.
Thanks, Peter. lyx now builds and links fine (except for included gettext).
So, Abdel, could you verify the attached patch? You need to
Step 1: install scons-0.96.92
Step 2:
> These installers have been uploaded
to incoming on the LyX FTP server. Can someone move them to a public
location?
We do not have access there! Could you upload to ftp.devel.lyx.org/pub/incoming
?
Thanks,
JMarc
Georg Baum wrote:
Am Samstag, 27. Mai 2006 17:11 schrieb Abdelrazak Younes:
Georg Baum wrote:
+ delete app;
Is this necessary?
I think so. It makes sure that the LQApplication object is destructed at a
defined time. How should the compiler know when to destruct it otherwise?
I was m
Bo Peng wrote:
>> How must I call scons? Could you please post a complete command
>> which I can use (after fixing the paths)?
>> Do I have to add all the qt_* settings to the command?
>> This I have done but then it asks for extra_inc_path1.
>
> Hi, Peter,
>
> Thank you very much for the info. H
Finally, the source code of the new LyX 1.4 installer. Updated Windows
build instructions are also included.
To apply this to a 1.4 tree:
* Remove everything inside development\Win32\packaging\installer
* Remove development\Win32\packaging\build_aspell.sh
* Remove development\Win32\packaging\RE
Attached is then the new version.
Shall we now address the issue of "do we actually want this in LyX"?
;-)
- Martin
Index: src/LaTeXFeatures.C
===
--- src/LaTeXFeatures.C (revision 13930)
+++ src/LaTeXFeatures.C (working copy)
@@
On Sat, May 27, 2006 at 06:06:53PM +0200, Georg Baum wrote:
> Am Samstag, 27. Mai 2006 17:46 schrieb Martin Vermeer:
> > QNoteDialog.C: In constructor
> > 'lyx::frontend::QNoteDialog::QNoteDialog(lyx::frontend::QNote*)':
> > QNoteDialog.C:30: error: no matching function for call to
> > 'lyx::fronte
Am Samstag, 27. Mai 2006 17:46 schrieb Martin Vermeer:
> QNoteDialog.C: In constructor
> 'lyx::frontend::QNoteDialog::QNoteDialog(lyx::frontend::QNote*)':
> QNoteDialog.C:30: error: no matching function for call to
> 'lyx::frontend::QNoteDialog::connect(QRadioButton*&, const char [15],
> lyx::front
How must I call scons? Could you please post a complete command
which I can use (after fixing the paths)?
Do I have to add all the qt_* settings to the command?
This I have done but then it asks for extra_inc_path1.
Hi, Peter,
Thank you very much for the info. Here is what I get right now.
Ste
On Sat, May 27, 2006 at 03:00:14PM +0200, Abdelrazak Younes wrote:
> Martin Vermeer wrote:
> >On Sat, 2006-05-27 at 11:00 +0200, Georg Baum wrote:
> >>Am Freitag, 26. Mai 2006 23:21 schrieb Martin Vermeer:
> >>>But won't the connections disappear again when you recompile? This file
> >>>is generate
Am Samstag, 27. Mai 2006 17:11 schrieb Abdelrazak Younes:
> Georg Baum wrote:
> > + delete app;
>
> Is this necessary?
I think so. It makes sure that the LQApplication object is destructed at a
defined time. How should the compiler know when to destruct it otherwise?
Georg
> I don't think you should run the spellcker when loading a document.
Every text processor does it. If we don't, we will have an inconsistent
representation of wrong/correct words. For example, should you save a
document and re-open it, every underlined mistake will be gone until you move
the c
Georg Baum wrote:
Am Samstag, 27. Mai 2006 15:20 schrieb Abdelrazak Younes:
Another idea... Maybe the QApplication destruction is happening too soon
in the exit process, this patch remove the QLApplication destructor.
This was the right idea. The 'static' LQApplication changed the
destruction
Georg Baum wrote:
Am Samstag, 27. Mai 2006 15:20 schrieb Abdelrazak Younes:
Another idea... Maybe the QApplication destruction is happening too soon
in the exit process, this patch remove the QLApplication destructor.
This was the right idea. The 'static' LQApplication changed the
destruction
The qt4 ui subdirectory does not contain any .C files anymore. Therefore
the command for generating the pch.gch file fails. The attached patch
fixes this problem.
Georg
Log:
* src/frontends/qt4/ui/pch.h: remove
* src/frontends/qt4/ui/Makefile.am: remove unused rules
Index: src/
Am Samstag, 27. Mai 2006 15:20 schrieb Abdelrazak Younes:
> Another idea... Maybe the QApplication destruction is happening too soon
> in the exit process, this patch remove the QLApplication destructor.
This was the right idea. The 'static' LQApplication changed the
destruction order in a way q
Am Samstag, 27. Mai 2006 15:40 schrieb Abdelrazak Younes:
> OK, then this patch use a straight QApplication. QLApplication is used
> only for Mac as far as I see. And use qApp only.
Does not help:
#0 0xb7b94bcc in QPixmapCache::clear () from /usr/lib/libQtGui.so.4
#1 0xb7b4ddb5 in QApplication
Am Samstag, 27. Mai 2006 15:11 schrieb Abdelrazak Younes:
> Juergen Spitzmueller wrote:
> >
> > I'd second that.
>
> Me too but shouldn't be an automatic detection?
Currently I simply implemented an additional frontend name kde. It is like
any other frontend, the only difference is that the sou
Georg Baum wrote:
Am Samstag, 27. Mai 2006 14:57 schrieb Abdelrazak Younes:
I have maybe an idea. Peter Kummel claims the following in his Cmake
patch:
---
and this fixes the crash on exit under windows, maybe
lyx_gui::unregister_
Am Samstag, 27. Mai 2006 15:05 schrieb Juergen Spitzmueller:
> I did that. Two things for a start:
> - it would be good if --with-frontend=kde compiled the qt frontend
> automatically.
Why? It does not need it. Although the sources are shared, the object
files are not.
> - in the kfiledialog, t
Georg Baum wrote:
Am Samstag, 27. Mai 2006 15:20 schrieb Abdelrazak Younes:
Another idea... Maybe the QApplication destruction is happening too soon
in the exit process, this patch remove the QLApplication destructor. I
am not sure this will solve the crash but your backtrace seems to imply
so
Am Samstag, 27. Mai 2006 14:57 schrieb Abdelrazak Younes:
> I have maybe an idea. Peter Kummel claims the following in his Cmake
patch:
>
> ---
> and this fixes the crash on exit under windows, maybe
> lyx_gui::unregister_socket_call
Am Samstag, 27. Mai 2006 15:20 schrieb Abdelrazak Younes:
> Another idea... Maybe the QApplication destruction is happening too soon
> in the exit process, this patch remove the QLApplication destructor. I
> am not sure this will solve the crash but your backtrace seems to imply
> so. If not, I
Georg Baum wrote:
Am Freitag, 26. Mai 2006 11:33 schrieb Helge Hafting:
Abdel, do you have any idea why this happens?
Another idea... Maybe the QApplication destruction is happening too soon
in the exit process, this patch remove the QLApplication destructor. I
am not sure this will solve
Juergen Spitzmueller wrote:
I'd second that.
Me too but shouldn't be an automatic detection?
I did that. Two things for a start:
- it would be good if --with-frontend=kde compiled the qt frontend
automatically.
Yes and at runtime, the binary would switch to Qt only is KDE is not
detected
Martin Vermeer wrote:
On Sat, 2006-05-27 at 11:00 +0200, Georg Baum wrote:
Am Freitag, 26. Mai 2006 23:21 schrieb Martin Vermeer:
But won't the connections disappear again when you recompile? This file
is generated.
Yes, they will. They are the result of the lines in the .ui file! If you
want
Georg Baum wrote:
> I have created an experimental kde branch at
> svn://svn.lyx.org/lyx/lyx-devel/branches/personal/baum/kde. It can be
> configured in parallel to the other frontends. It is pretty lightweight (no
> copied source files, therefore it has some ugly ifdefs). The only
> difference to
Georg Baum wrote:
Am Freitag, 26. Mai 2006 11:33 schrieb Helge Hafting:
When lyx-qt4 ends, I get:
lyx: SIGSEGV signal caught
Sorry, you have found a bug in LyX. Please read the bug-reporting
instructions in Help->Introduction and send us a bug report, if
necessary. Thanks !
Bye.
Avbrutt (SIGA
Lars (or others),
Would you agree to add
boost/boost/type_traits/detail/is_function_ptr_tester.hpp
boost/boost/type_traits/detail/is_mem_fun_pointer_tester.hpp
boost/boost/detail/interlocked.hpp
boost/boost/regex/v4/w32_regex_traits.hpp
for vc2003/2005 support? If you want me to do it, please t
Peter Kümmel wrote:
Abdelrazak Younes wrote:
it could not find user32.lib which is part of the SDK. Have you called
the sdk variable setting file SetEnv.Cmd?
No, was it in your recipe?
No, I thought that one managed this when compiling Qt.
I wonder why you could compile Qt w
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Could it be that your scripts assumes that the SDK is installed in
"D\program\SDK"?
Sure, you have to adjust the path to your Visual C++ and
SDK installation.
But I did that of course.
Abdel.
Martin Vermeer wrote:
On Fri, May 26, 2006 at 10:01:26PM +0200, Abdelrazak Younes wrote:
Martin Vermeer wrote:
I know qt3 ui files does this but if you continue doing that then I (or
others) would have problems to port that to qt4. So I would like that
any future signal-slot conne
Am Freitag, 26. Mai 2006 11:33 schrieb Helge Hafting:
> When lyx-qt4 ends, I get:
> lyx: SIGSEGV signal caught
> Sorry, you have found a bug in LyX. Please read the bug-reporting
> instructions in Help->Introduction and send us a bug report, if
> necessary. Thanks !
> Bye.
> Avbrutt (SIGABRT)
>
On Sat, 2006-05-27 at 11:00 +0200, Georg Baum wrote:
> Am Freitag, 26. Mai 2006 23:21 schrieb Martin Vermeer:
> > But won't the connections disappear again when you recompile? This file
> > is generated.
>
> Yes, they will. They are the result of the lines in the .ui file! If you
> want to please
Abdelrazak Younes wrote:
> I still have the same error:
> ".\cmTryCompileExec.dir\Debug\testCCompiler.obj"
> ".\cmTryCompileExec.dir\Debug\cmTryCompileExec.exe.embed.manifest.res"
> LINK : fatal error LNK1104: cannot open file 'user32.lib'
>
> But user32.lib is here:
Oh, I forgot: I've added the
Am Freitag, 26. Mai 2006 23:21 schrieb Martin Vermeer:
> But won't the connections disappear again when you recompile? This file
> is generated.
Yes, they will. They are the result of the lines in the .ui file! If you
want to please Abdel you could copy them to QNoteDialog.C, then you can
remove
Abdelrazak Younes wrote:
>>
>> it could not find user32.lib which is part of the SDK. Have you called
>> the sdk variable setting file SetEnv.Cmd?
>
> No, was it in your recipe?
>
No, I thought that one managed this when compiling Qt.
I wonder why you could compile Qt without the SDK
in your e
Bo Peng wrote:
> Let us start a new thread.
>
> Right now, I have told scons to build lyx, but it fails at the very
> first command:
How must I call scons? Could you please post a complete command
which I can use (after fixing the paths)?
Do I have to add all the qt_* settings to the command?
Thi
Bo Peng wrote:
> Another problem:
>
> The mingw-libs zconf.h, line 289 assumes the existence of unistd.h.
> This is not true for msvc. I am trying the official zlib1.dll package
> but the lib name will be different (and I can no longer use -lz).
>
> Bo
>
>
There is a ifdef where you could disab
Bo Peng wrote:
>> The option is /TP. As the error message indicates you should use /EHsc to
>> get exception handling (which is turned off for a reason I cannot
>> imagine),
>
> Adding /EHsc does not fix the problem.
> detail/is_function_ptr_tester.hpp is still needed, as well as other
> three boo
Bo Peng wrote:
> Thank you. This option works.
>
> Any idea how to get pid_t? I think it is in sys/types.h under linux,
> but msvc types.h may not have it. This causes problems in
> src/support/forkedcall.h etc.
>
> Bo
>
>
msvc lacks some symbols, you could have a look at
lyx-cmake/config.h.cm
Abdelrazak Younes wrote:
>
> Could it be that your scripts assumes that the SDK is installed in
> "D\program\SDK"?
>
Sure, you have to adjust the path to your Visual C++ and
SDK installation.
I tried executing the following commandon aussie.lyx.org
$ wget http://pmwiki.org/pmwiki/uploads/Cookbook/markup.css
--09:54:21-- http://pmwiki.org/pmwiki/uploads/Cookbook/markup.css
=> `extendmarkup.php'
Resolving pmwiki.org... failed: No such file or
Georg Baum wrote:
> > I already commited the patch, but I can change that, if you like.
>
> That would be nice.
>
> > For all
> > other converters using $$i only, I guess individual tests have to be
> > made.
>
> Yes.
OK, I'm putting the attached in, as a start. There are still quite a lot of
con
> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
>> I told you the patch was bogus :)
Bennett> And I thought "bogus" meant it would be all but useless, and
Bennett> it certainly wasn't that. (The syntax of that LSRolesMask
Bennett> line was new to me, though. Pretty slick.)
I knew th
46 matches
Mail list logo
