Re: Can't get Aspell working in LyX 1.4.3/WinXP
Joost Verburg wrote: Paul A. Rubin wrote: I ran aspelldata-0.60.4-root.exe after the 1.4.3 installation, I thought I was reinstalling what I already had from the 1.4.1 days (in the forlorn hope that it would refresh a registry entry or something). It will indeed setup the old things LyX 1.3.7 and 1.4.1 in C:\Aspell. That won't work with more recent versions. If you like to keep everything in C:\Aspell, copy everything inside C:\Aspell\lib\aspell-0.60 to C:\Aspell\Dictionaries. Thanks! That turned the trick. /Paul
Re: Can't get Aspell working in LyX 1.4.3/WinXP
Paul A. Rubin wrote: I ran aspelldata-0.60.4-root.exe after the 1.4.3 installation, I thought I was reinstalling what I already had from the 1.4.1 days (in the forlorn hope that it would refresh a registry entry or something). It will indeed setup the old things LyX 1.3.7 and 1.4.1 in C:\Aspell. That won't work with more recent versions. If you like to keep everything in C:\Aspell, copy everything inside C:\Aspell\lib\aspell-0.60 to C:\Aspell\Dictionaries. Joost
Re: Can't get Aspell working in LyX 1.4.3/WinXP
Joost Verburg wrote: Paul A. Rubin wrote: Uninstalling and reinstalling Aspell (in C:\Aspell) and reconfiguring LyX did no good. The US dictionaries are installed (in C:\Aspell\lib\aspell-0.60\). Any ideas why LyX thinks they're not present? aspelldata-0.60.4-root.exe is not intended to be used with LyX 1.4.2/1.4.3. You should not install it. The Windows installer will setup everything automatically, including Aspell. For LyX 1.3.7 and 1.4.1, keep your old Aspell installation in C:\Aspell. Joost, 1.4.1 required adding some Aspell 0.60 files to the Aspell 0.50 installation that 1.3.7 was using. I think those files are what is in aspelldata-0.60.4-root.exe, although I can't swear to this. At any rate, when I installed 1.4.2 in parallel to 1.4.1 (without making any changes to my C:\Aspell setup), the spell checker did not work in 1.4.2 (and does not work in 1.4.3), so apparently the installer either failed to set something up or ran into a conflict with what I already had. When I ran aspelldata-0.60.4-root.exe after the 1.4.3 installation, I thought I was reinstalling what I already had from the 1.4.1 days (in the forlorn hope that it would refresh a registry entry or something). What all does the 1.4.2/1.4.3 install (and where) to enable Aspell support? Thanks, Paul
[1.5svn] [BUG] redefinition of 'class Point'
g++-4 -DHAVE_CONFIG_H -I. -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -Winvalid-pch --include=./pch.h -I../../../src -I../../../src/frontends -I../../../images -I/usr/local/Trolltech/Qt-4.2.0/include -I/usr/local/Trolltech/Qt-4.2.0/include/QtCore -I/usr/local/Trolltech/Qt-4.2.0/include/QtGui -I../../../boost -I../../../src/frontends/controllers -Wextra -Wall -I/sw/include -g -Os -MT GuiApplication.lo -MD -MP -MF .deps/GuiApplication.Tpo -c GuiApplication.C -o GuiApplication.o ../../../src/coordcache.h:30: error: redefinition of 'class Point' /System/Library/Frameworks/CoreServices.framework/Headers/../Frameworks/CarbonCore.framework/Headers/MacTypes.h:485: error: previous definition of 'class Point'make[7]: *** [GuiApplication.lo] Error 1 make[6]: *** [all-recursive] Error 1 make[5]: *** [all] Error 2 make[4]: *** [all-recursive] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 make: *** [all-recursive] Error 1
Re: Compiling with MSVC - and request for general status
Joost Verburg wrote: Asger Ottar Alstrup wrote: Could someone please update those with instructions on what to get and install to compile the Qt4 frontend using MSVC? The INSTALL.Win32 in the 1.4 branch provides detailed instructions for building with Q../Free and MSVC. You can follow this method and compile Qt4 yourself. Instructions for 1.5 including pre-compiled dependency packages will be available soon. OK, so this is what I did so far: - Buy & install MSVC2005 (alternative is to use free edition) - Install TortoiseSVN - Check out lyx-devel using this - Download & install Python 2.5 - Download & install scons - Download & extract qt-4.2 free edition for windows - Download & extract & apply q../win free patch for qt-4.2 - Compile patched 4.2 using \vcvars32 (to get MSVC tools into path) cd c:\lyx\qt-4.2 qconfigure msvc2005 (answer questions) nmake (wait a long time) I also downloaded the LyX development package you uploaded to contrib. I'm going to bed now - hope Qt will be compiled when I wake up, so I can proceed to next step. Regards, Asger
Re: [Cvslog] r15302 - in /lyx-devel/trunk/src: BufferView.C BufferView...
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | This is something I already wondered about. Do we have a clear | description of what is a same change by one author? Same day? Less | that 10 minutes? Same editing session? Ha. Another user for my uuid thingie. We could use that to create unique session ids. Then as long as you are in the same session, then it is the same change. | We should think about that and define a clear notion of 'same change'. | A good first step would be to define some method (or maybe a | Change::operator==) to compare changes and use it all over. Then we | can decide what we put in this method. 'raps. But I agree defining "same change" is important. (And should make a nice paragraph in the documentation.) -- Lgb
Re: r15306 - in /lyx-devel/trunk: development/scons/scons_man...
Abdelrazak Younes <[EMAIL PROTECTED]> writes: | > Can you please use a proper include to | > get to the declaration instead? | | If you want but this is interim code. Please. -- Lgb
Re: [PATCH] Introduce ConsoleFontMetrics and ConsoleFontLoader
Abdelrazak Younes <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: | > Abdelrazak Younes <[EMAIL PROTECTED]> writes: | > | Hello, | > | | This patch saves the need to check for lyx::use_gui in a number | > of | > | place. I will commit tomorrow if there's no objection. | > | | * lyx_main.h: define "extern bool lyx::use_gui" here. | > | | * ConsoleFontMetrics.h: new class for command-line LyX | > | | * ConsoleFontLoader.h: new class for command-line LyX | > HOw hard would it be to have the "Application" type be selectable on | > startup? | > What i mean is (in principle) "lyx --gui=qt" or "lyx --gui=gtk", and | > si this specific case, and perhaps more easily achivable "lyx | > --gui=none" and have that use the gui/frontend found in | > frontends/console. | | Very easy right now. We are ready for that and we can compile qt3, qt4 | and gtk in the same executable if we want to. Looks like my clean up | work have some nice side effect :-) Yeah... but I guess that even if possible we would like to that with an exec wrapper: lyx --gui=qt starts lyx-qt lyx --gui=gtk starts lyx-gtk Without dragging in both libs all the time. (of course there is dlopen and dynamic linking... but that would be overkill) | > Would selecting a frontend in such a way make the code elsewhere | > simpler eaiser? Perhaps no need for the statics of this patch? | | Yes, I wanted to create a Command-line application instead of this | static trick. But then the Clipboard and Selection access doesn't make | sense for the command-line so I opted for the simpler static trick. ? Clipboard and selection? does nogui/cli need that? | > (Years ago, Asger and I had a dream of a curses based frontend... | > never had any time to pursue anything in that direction...) | | You just to implement the virtual interface define in | frontends/Application and you're done. Should be very easy. No. :-) That is the hard part. -- Lgb
Re: mail-archive
[EMAIL PROTECTED] writes: | Hi there, | could you please delete the following two entries: | www.mail-archive.com/lyx-devel@lists.lyx.org/msg29149.html | www.mail-archive.com/lyx-devel@lists.lyx.org/msg29027.html | because they are very old and contain personal data I don't want to | distribute. We are not running any of the archives ourselves (and I am sure that there are archives that we don't even know about.) and have no control over them (or very little, no direct control at least.) So you really should take this up the archive maintainers. -- Lgb
Re: [PATCH] Introduce ConsoleFontMetrics and ConsoleFontLoader
Lars Gullik Bjønnes wrote: [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | Abdelrazak Younes <[EMAIL PROTECTED]> writes: | | | Hello, | | | | This patch saves the need to check for lyx::use_gui in a number of | | place. I will commit tomorrow if there's no objection. | | | | * lyx_main.h: define "extern bool lyx::use_gui" here. | | | | * ConsoleFontMetrics.h: new class for command-line LyX | | | | * ConsoleFontLoader.h: new class for command-line LyX | | HOw hard would it be to have the "Application" type be selectable on | startup? | | What i mean is (in principle) "lyx --gui=qt" or "lyx --gui=gtk", and | si this specific case, and perhaps more easily achivable "lyx | --gui=none" and have that use the gui/frontend found in | frontends/console. | | Would selecting a frontend in such a way make the code elsewhere | simpler eaiser? Perhaps no need for the statics of this patch? | | (Years ago, Asger and I had a dream of a curses based frontend... | never had any time to pursue anything in that direction...) Btw. I think what you call the "console" frontend, really is no frontend at all. Let's reserve the console name for when some crazy person really creates a console frontend for LyX. You are right. But what to cal it then? "nogui"? Commandline? Abdel.
Re: [PATCH] Introduce ConsoleFontMetrics and ConsoleFontLoader
Lars Gullik Bjønnes wrote: Abdelrazak Younes <[EMAIL PROTECTED]> writes: | Hello, | | This patch saves the need to check for lyx::use_gui in a number of | place. I will commit tomorrow if there's no objection. | | * lyx_main.h: define "extern bool lyx::use_gui" here. | | * ConsoleFontMetrics.h: new class for command-line LyX | | * ConsoleFontLoader.h: new class for command-line LyX HOw hard would it be to have the "Application" type be selectable on startup? What i mean is (in principle) "lyx --gui=qt" or "lyx --gui=gtk", and si this specific case, and perhaps more easily achivable "lyx --gui=none" and have that use the gui/frontend found in frontends/console. Very easy right now. We are ready for that and we can compile qt3, qt4 and gtk in the same executable if we want to. Looks like my clean up work have some nice side effect :-) Would selecting a frontend in such a way make the code elsewhere simpler eaiser? Perhaps no need for the statics of this patch? Yes, I wanted to create a Command-line application instead of this static trick. But then the Clipboard and Selection access doesn't make sense for the command-line so I opted for the simpler static trick. (Years ago, Asger and I had a dream of a curses based frontend... never had any time to pursue anything in that direction...) You just to implement the virtual interface define in frontends/Application and you're done. Should be very easy. Abdel.
Re: [PATCH] Introduce ConsoleFontMetrics and ConsoleFontLoader
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | Abdelrazak Younes <[EMAIL PROTECTED]> writes: | | | Hello, | | | | This patch saves the need to check for lyx::use_gui in a number of | | place. I will commit tomorrow if there's no objection. | | | | * lyx_main.h: define "extern bool lyx::use_gui" here. | | | | * ConsoleFontMetrics.h: new class for command-line LyX | | | | * ConsoleFontLoader.h: new class for command-line LyX | | HOw hard would it be to have the "Application" type be selectable on | startup? | | What i mean is (in principle) "lyx --gui=qt" or "lyx --gui=gtk", and | si this specific case, and perhaps more easily achivable "lyx | --gui=none" and have that use the gui/frontend found in | frontends/console. | | Would selecting a frontend in such a way make the code elsewhere | simpler eaiser? Perhaps no need for the statics of this patch? | | (Years ago, Asger and I had a dream of a curses based frontend... | never had any time to pursue anything in that direction...) Btw. I think what you call the "console" frontend, really is no frontend at all. Let's reserve the console name for when some crazy person really creates a console frontend for LyX. But what to cal it then? "nogui"? -- Lgb
Re: [PATCH] Introduce ConsoleFontMetrics and ConsoleFontLoader
Abdelrazak Younes <[EMAIL PROTECTED]> writes: | Hello, | | This patch saves the need to check for lyx::use_gui in a number of | place. I will commit tomorrow if there's no objection. | | * lyx_main.h: define "extern bool lyx::use_gui" here. | | * ConsoleFontMetrics.h: new class for command-line LyX | | * ConsoleFontLoader.h: new class for command-line LyX HOw hard would it be to have the "Application" type be selectable on startup? What i mean is (in principle) "lyx --gui=qt" or "lyx --gui=gtk", and si this specific case, and perhaps more easily achivable "lyx --gui=none" and have that use the gui/frontend found in frontends/console. Would selecting a frontend in such a way make the code elsewhere simpler eaiser? Perhaps no need for the statics of this patch? (Years ago, Asger and I had a dream of a curses based frontend... never had any time to pursue anything in that direction...) -- Lgb
Re: Please include LyXWinInstaller's toolbar in the official LyX Windows installer
Lars Gullik Bjønnes wrote: The solution is not necessarily to follow Uwe. Of course there is a reason why this modification of Uwe is not official, it's because many people find it annoying. Why do we have auto toolbars at all? It looks like nobody likes them. If someone can create a patch that makes LyX remember whether the toolbars were on or off, we already have a good solution. I agree with keeping the auto toolbars outside of the GUI until we have something better. Joost
Re: [PATCH] CT revision (this time for real)
Abdelrazak Younes <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: | > Michael Gerz <[EMAIL PROTECTED]> writes: | > | Lars Gullik Bjønnes wrote: | > | | >I think you can continue as you have outlined. Please try to | > not make | > | >anything (except CT) more unusable than it already is. If not it might | > | >create difficulties for us, when we go into "hard working mode" during | > | >the Denmark thing. | > | > | > | Thank you for your trust. | > | | BTW: I think there is slow progress regarding unicode. Do you | > have any | > | idea how to overcome the current situation? It seems some people are | > | waiting for a sign :-) | > Yeah... you would at least have expected frontend people to work on | > getting their frontends really ready for unicode. | | Well I think most of the remaining work is completely outside the | frontend space. At least the most important one... All IM stuff resides in the frontends. (Input Methods) Also the core is easily handled (unless we go completely overboard and decide to support all of Unicode right away.) (We might have a problem with bi-dir...) I think the most crucial part as of now is output, especially output to latex and how to handle that. Will it mean Omega/Lambda, some utf8 packages for LaTeX? How to solve this with (La)TeX is pretty open. -- Lgb
Re: Please include LyXWinInstaller's toolbar in the official LyX Windows installer
Lars Gullik Bjønnes wrote: Have you tried working with autotoolbars? You really think this is a nifty idea? Personally I like to have the toolbars on at all times. Currently there is no way for a user to turn on these toolbars by default other than hacking ui files. I would already be very happy if it just remembered the state of my toolbars, without any auto stuff at all. Joost
Re: Please include LyXWinInstaller's toolbar in the official LyX Windows installer
Georg Baum <[EMAIL PROTECTED]> writes: | I doubt that it will be quicker than using C-S-m followed by M-m n, but it | might nevertheless be good for new users. LyX has never tried to be particularly nice to new users, and I don't think we should be now. Of course when a solution is good both for advanced (read: users that has used lyx for a while) and new users then we should use such a solution. But selecting a solution to a problem or feature just because it is good to new users does not seem to be the way to go. IMHO therein you find bloat and feature mangolomia. (So. "good for new users" triggers a knee-jerk reaction from me..., and remember that a new user is only new the very first seconds.) -- Lgb
Re: Please include LyXWinInstaller's toolbar in the official LyX Windows installer
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Joost" == Joost Verburg <[EMAIL PROTECTED]> writes: | | Joost> Jean-Marc Lasgouttes wrote: | >> What about shipping a default-autotoolbars.ui file which make auto | >> toolbars active? | | Joost> That still requires users to manually set a different UI file, | Joost> which is not a very obvious thing to do when you want to have | Joost> the toolbars visible. | | Joost> Why not put the auto toolbars in default and create a | Joost> default-noautotoolbars? | | Because I think there will be as many people annoyed by auto toolbars | then people who like them. Personally, having toolbars which flash in | and out when I do pageup/down annoys me. ditto. -- Lgb
[PATCH] Introduce ConsoleFontMetrics and ConsoleFontLoader
Hello,
This patch saves the need to check for lyx::use_gui in a number of
place. I will commit tomorrow if there's no objection.
* lyx_main.h: define "extern bool lyx::use_gui" here.
* ConsoleFontMetrics.h: new class for command-line LyX
* ConsoleFontLoader.h: new class for command-line LyX
Index: development/scons/scons_manifest.py
===
--- development/scons/scons_manifest.py (revision 15322)
+++ development/scons/scons_manifest.py (working copy)
@@ -431,7 +431,9 @@
Alert.h
Alert_pimpl.h
Application.h
-Clipboard.h
+Clipboard.h
+ConsoleFontLoader.h
+ConsoleFontMetrics.h
Dialogs.h
FileDialog.h
FontLoader.h
Index: src/frontends/Alert.C
===
--- src/frontends/Alert.C (revision 15322)
+++ src/frontends/Alert.C (working copy)
@@ -14,6 +14,7 @@
#include "Alert_pimpl.h"
#include "debug.h"
+#include "lyx_main.h" // for lyx::use_gui
using lyx::docstring;
@@ -25,8 +26,6 @@
namespace lyx {
-extern bool use_gui;
-
namespace frontend {
int Alert::prompt(docstring const & title, docstring const & question,
Index: src/frontends/Application.C
===
--- src/frontends/Application.C (revision 15330)
+++ src/frontends/Application.C (working copy)
@@ -12,6 +12,8 @@
#include "frontends/Application.h"
+#include "frontends/ConsoleFontLoader.h"
+#include "frontends/ConsoleFontMetrics.h"
#include "frontends/FontLoader.h"
#include "frontends/FontMetrics.h"
#include "frontends/Gui.h"
@@ -21,6 +23,7 @@
#include "bufferlist.h"
#include "funcrequest.h"
#include "FuncStatus.h"
+#include "lyx_main.h"
#include "LyXAction.h"
#include "lyxfont.h"
#include "lyxfunc.h"
@@ -167,6 +170,11 @@
lyx::frontend::FontLoader & theFontLoader()
{
+ static lyx::frontend::ConsoleFontLoader console_font_loader;
+
+ if (!lyx::use_gui)
+ return console_font_loader;
+
BOOST_ASSERT(theApp);
return theApp->fontLoader();
}
@@ -174,6 +182,11 @@
lyx::frontend::FontMetrics const & theFontMetrics(LyXFont const & f)
{
+ static lyx::frontend::ConsoleFontMetrics console_font_metrics;
+
+ if (!lyx::use_gui)
+ return console_font_metrics;
+
BOOST_ASSERT(theApp);
return theApp->fontLoader().metrics(f);
}
Index: src/frontends/ConsoleFontLoader.h
===
--- src/frontends/ConsoleFontLoader.h (revision 0)
+++ src/frontends/ConsoleFontLoader.h (revision 0)
@@ -0,0 +1,48 @@
+// -*- C++ -*-
+/**
+ * \file ConsoleFontLoader.h
+ * This file is part of LyX, the document processor.
+ * Licence details can be found in the file COPYING.
+ *
+ * \author Abdelrazak Younes
+ *
+ * Full author contact details are available in file CREDITS.
+ */
+
+#ifndef LYX_CONSOLE_FONTLOADER_H
+#define LYX_CONSOLE_FONTLOADER_H
+
+#include "frontends/FontLoader.h"
+
+#include "frontends/ConsoleFontMetrics.h"
+
+namespace lyx {
+namespace frontend {
+
+/// Dummy FontLoader for command-line output.
+class ConsoleFontLoader: public FontLoader
+{
+public:
+ ///
+ ConsoleFontLoader() {}
+ ///
+ virtual ~ConsoleFontLoader() {}
+
+ /// Update fonts after zoom, dpi, font names, or norm change
+ virtual void update() {};
+
+ /// Is the given font available ?
+ virtual bool available(LyXFont const & f) { return false; };
+
+ /// Get the Font metrics for this LyXFont
+ virtual FontMetrics const & metrics(LyXFont const & f) { return
metrics_; }
+
+private:
+ ///
+ ConsoleFontMetrics metrics_;
+};
+
+} // namespace frontend
+} // namespace lyx
+
+#endif // LYX_CONSOLE_FONTLOADER_H
Property changes on: src\frontends\ConsoleFontLoader.h
___
Name: svn:eol-style
+ native
Index: src/frontends/ConsoleFontMetrics.h
===
--- src/frontends/ConsoleFontMetrics.h (revision 0)
+++ src/frontends/ConsoleFontMetrics.h (revision 0)
@@ -0,0 +1,66 @@
+// -*- C++ -*-
+/**
+ * \file ConsoleFontMetrics.h
+ * This file is part of LyX, the document processor.
+ * Licence details can be found in the file COPYING.
+ *
+ * \author Abdelrazak Younes
+ *
+ * Full author contact details are available in file CREDITS.
+ */
+
+#ifndef CONSOLE_FONT_METRICS_H
+#define CONSOLE_FONT_METRICS_H
+
+#include "frontends/FontMetrics.h"
+
+#include "support/docstring.h"
+
+namespace lyx {
+namespace frontend {
+
+class ConsoleFontMetrics: public FontMetrics
+{
+public:
+
+ ConsoleFontMetrics() {}
+
+ virtual ~ConsoleFontMetrics() {}
+
+ virtual int maxAscent() const { return 1; }
+
+ virtual int maxDescent() const { return 1; }
+
+ virtual int ascent(lyx::char_type c) const { return 1
Re: Please include LyXWinInstaller's toolbar in the official LyX Windows installer
Angus Leeming <[EMAIL PROTECTED]> writes: | Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > Joost> Microsoft Office 2007 will have a very nice user interface with | > Joost> a context-sensitive ribbon: | > Joost> http://blogs.msdn.com/photos/jensenh/images/547376/original.aspx | > Joost> This way you won't have a separate menu and toolbar anymore but | > Joost> an integrated way to access all features. | | > Time will tell whether it is a nice interface in normal use... | | I've been "dogfooding" Office12 now for 9 months. My experience is that the UI | works very well once you've invested time in learning the unfamiliar interface. | | Of course, it's just a funky way to get more functions into the toolbar, so | the problem of finding the buttons still exists, just as it does now in LyX | when you have an overcrowded toolbar. The difference is that buttons are | grouped logically so you have some chance of finding 'em. So just like how menus are supposed to work then... -- Lgb
Re: [PATCH] fix bugs 2877 and 1720
On Sat, Oct 14, 2006 at 05:46:03PM +0200, Jean-Marc Lasgouttes wrote: > > This patch (against 1.4) should > > 1/ reimplement the OSX feature that greys-out unavailable actions when > a dialog is active > > 2/ fix the bug that save is not reactivated when changing document > settings. > > Please test both behaviours, and in general weird toolbar things. I don't know if 1) is supposed to only work on OSX, but (at least on Windows) the toolbar buttons remain active when a dialog is opened. However, 2) seems to be fixed and I didn't notice anything weird. -- Enrico
Re: Please include LyXWinInstaller's toolbar in the official LyX Windows installer
Joost Verburg <[EMAIL PROTECTED]> writes: | Jean-Marc Lasgouttes wrote: | > Because I think there will be as many people annoyed by auto toolbars | > then people who like them. Personally, having toolbars which flash in | > and out when I do pageup/down annoys me. | | Not having auto toolbars makes them very difficult to use, because | you'll have to reopen them again every time you start LyX (unless you | know how to hack the ui files, you can't expect that from a normal | Windows user). The auto toolbars are also already in 1.5. Create a sidebar thing, completely outside the current lyx "window". Perhaps that might be a better solution than the on-top-toolbar. (Then I can just not show the sidebar and be done with it.) | I still have not managed to convince Uwe to create one official | Windows installer. This is one of the things why he wants to keep his | modified unofficial version. We really need a solution here. The solution is not necessarily to follow Uwe. Or even to have a single official windows installer. -- Lgb
Re: Please include LyXWinInstaller's toolbar in the official LyX Windows installer
Joost Verburg <[EMAIL PROTECTED]> writes: | Jean-Marc Lasgouttes wrote: | > What about shipping a default-autotoolbars.ui file which make auto | > toolbars active? | | That still requires users to manually set a different UI file, which | is not a very obvious thing to do when you want to have the toolbars | visible. | | Why not put the auto toolbars in default and create a | default-noautotoolbars? Have you tried working with autotoolbars? You really think this is a nifty idea? -- Lgb
Re: [Bug 2882] not possible to delete row in ERT inset
Georg Baum <[EMAIL PROTECTED]> writes: | Juergen Spitzmueller wrote: | | > Andre Poenitz wrote: | >> Have a function 'Inset***::backspaceShouldDeleteEmptyLines()' and be | >> done. | > | > I don't understand. Backspace should _always_ delete empty lines AFAICS. | > The problem is that backspace is lazy and passes the job to dEPM, which | > doesn't have a clue whether an empty par is there because of backspace or | > because of something else (in the latter case, it should not delete the | > lines for free spacing stuff like ERT). | | Exactly. I am wondering whether it would not be better to base InsetERT on | something else than InsetText, since we have so many special cases. We need a editor inset (kindo). I belive I have stated this before... -- Lgb
Re: [SVN updated patch] Introduce frontends/FontMetrics virtual interface
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
| > On Fri, Oct 06, 2006 at 10:52:31PM +0200, Abdelrazak Younes wrote:
| >> If you prefer I can add this as a helper function in some
| >> theFontLoader.h header:
| >>
| >> #include "frontends/Application.h"
| >> #include "frontends/FontLoader.h"
| >>
| >> FontLoader & theFontLoader()
| >> {
| >> return theApp->fontLoader();
| >> }
| > Hm, why not directly in FontLoader.h:
| > FontLoader & theFontLoader();
| > and in FontLoader.C (or even, *gosh*, in Application.C):
| > FontLoader & theFontLoader()
| > {
| > return theApp->fontLoader();
| > }
| > This way I'd get my 'theFontLoader' without an extra include or extra
| > file and you' get al the singletons bundled in theApp.
|
| Hum... indeed this looks sane and doesn't seem to conflict with the
| minimal dependency goal that Lars asked for. But I am not sure it
| won't conflict with the Application_pimpl. I'll try, thanks for the
| idea.
|
| Abdel.
When the declaration is in X.h and the definition is in Y.C then a
comment is warrantet. I belive this is missing now?
I'll add the comments.
Abdel.
Re: r15306 - in /lyx-devel/trunk: development/scons/scons_man...
Lars Gullik Bjønnes wrote: [EMAIL PROTECTED] writes: | Author: younes | Date: Thu Oct 12 16:10:13 2006 | New Revision: 15306 | | URL: http://www.lyx.org/trac/changeset/15306 | Log: | This commit is purely mechanical and get rid of lyx_gui.[Ch]. | | Only qt4 is guaranted to compile and work. I did not remove gtk and qt3 lyx_gui.C because they might be needed for reference to complete the header declarations in "GuiApplication.C". | | - lyx_gui::use_gui transfered to lyx::use_gui in lyx_main.C I see that use use "extern bool use_gui" to get access to that bool in a couple of places. Generally externs are a maintenance nightmare. My goal is to get rid of that altogether and make that bool private to the LyX class. All other sources should not know whether use_gui is true or false. Can you please use a proper include to get to the declaration instead? If you want but this is interim code. Abdel.
Re: [PATCH] Multiple view support
Abdelrazak Younes <[EMAIL PROTECTED]> writes: | > If you want to get some nice crashes add some | > BOOST_ASSERT(cell.bv_owner) | > (or similar, from memory) in insettabular. | | Year, this tabular thing is the root of evil... You should have seen it before it was cleaned up... -- Lgb
Re: [SVN updated patch] Introduce frontends/FontMetrics virtual interface
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
| > On Fri, Oct 06, 2006 at 10:52:31PM +0200, Abdelrazak Younes wrote:
| >> If you prefer I can add this as a helper function in some
| >> theFontLoader.h header:
| >>
| >> #include "frontends/Application.h"
| >> #include "frontends/FontLoader.h"
| >>
| >> FontLoader & theFontLoader()
| >> {
| >>return theApp->fontLoader();
| >> }
| > Hm, why not directly in FontLoader.h:
| > FontLoader & theFontLoader();
| > and in FontLoader.C (or even, *gosh*, in Application.C):
| > FontLoader & theFontLoader()
| > {
| > return theApp->fontLoader();
| > }
| > This way I'd get my 'theFontLoader' without an extra include or extra
| > file and you' get al the singletons bundled in theApp.
|
| Hum... indeed this looks sane and doesn't seem to conflict with the
| minimal dependency goal that Lars asked for. But I am not sure it
| won't conflict with the Application_pimpl. I'll try, thanks for the
| idea.
|
| Abdel.
When the declaration is in X.h and the definition is in Y.C then a
comment is warrantet. I belive this is missing now?
--
Lgb
Re: r15306 - in /lyx-devel/trunk: development/scons/scons_man...
[EMAIL PROTECTED] writes: | Author: younes | Date: Thu Oct 12 16:10:13 2006 | New Revision: 15306 | | URL: http://www.lyx.org/trac/changeset/15306 | Log: | This commit is purely mechanical and get rid of lyx_gui.[Ch]. | | Only qt4 is guaranted to compile and work. I did not remove gtk and qt3 lyx_gui.C because they might be needed for reference to complete the header declarations in "GuiApplication.C". | | - lyx_gui::use_gui transfered to lyx::use_gui in lyx_main.C I see that use use "extern bool use_gui" to get access to that bool in a couple of places. Generally externs are a maintenance nightmare. Can you please use a proper include to get to the declaration instead? -- Lgb
Re: LyX slow in Windows XP
Enrico Forestieri wrote:
On Sat, Oct 14, 2006 at 05:56:24PM +0200, Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
"kmailuk" == kmailuk <[EMAIL PROTECTED]> writes:
kmailuk> Hey! With "instant preview" turned ON there is a noticeable
kmailuk> performance improvement (i.e. speed is not a problem any
kmailuk> more). Why would that make things run faster? (I prefer the
kmailuk> way LyX looked with instant preview off but I can't
kmailuk> complain).
It seems that math equation display is really slow for some reason,
but I cannot guess why.
I am guessing that this has to do with the scrolling code in BufferView.
I know this is difficult to do right but this thing is slowing scrolling
enormously especially when there is math. I think I would prefer a bad
scrollbar position and good performance.
I heartily second this.
But in this case, it's not only that. The attachment in the bugzilla
entry is still slow when I disable the scrollbar update in bufferview
with the attached patch. So this is more complicated than a simple
scrollbar issue as I initially thought.
Asger, if you have already finished with my task list you could ask
Andre how we could optimize the editing of the attached document.
Abdel.
Index: BufferView.C
===
--- BufferView.C(revision 15324)
+++ BufferView.C(working copy)
@@ -394,6 +394,9 @@
return;
}
+ scrollbarParameters_.reset();
+ return;
+
LyXText & t = buffer_->text();
int const parsize = int(t.paragraphs().size() - 1);
if (anchor_ref_ > parsize) {
attachment.lyx
Description: application/lyx
Re: LyX slow in Windows XP
On Sat, Oct 14, 2006 at 05:56:24PM +0200, Abdelrazak Younes wrote: > Jean-Marc Lasgouttes wrote: > >> "kmailuk" == kmailuk <[EMAIL PROTECTED]> writes: > > > > kmailuk> Hey! With "instant preview" turned ON there is a noticeable > > kmailuk> performance improvement (i.e. speed is not a problem any > > kmailuk> more). Why would that make things run faster? (I prefer the > > kmailuk> way LyX looked with instant preview off but I can't > > kmailuk> complain). > > > > It seems that math equation display is really slow for some reason, > > but I cannot guess why. > > I am guessing that this has to do with the scrolling code in BufferView. > I know this is difficult to do right but this thing is slowing scrolling > enormously especially when there is math. I think I would prefer a bad > scrollbar position and good performance. I heartily second this. -- Enrico
Re: LyX slow in Windows XP
Jean-Marc Lasgouttes wrote: "kmailuk" == kmailuk <[EMAIL PROTECTED]> writes: kmailuk> Hey! With "instant preview" turned ON there is a noticeable kmailuk> performance improvement (i.e. speed is not a problem any kmailuk> more). Why would that make things run faster? (I prefer the kmailuk> way LyX looked with instant preview off but I can't kmailuk> complain). It seems that math equation display is really slow for some reason, but I cannot guess why. I am guessing that this has to do with the scrolling code in BufferView. I know this is difficult to do right but this thing is slowing scrolling enormously especially when there is math. I think I would prefer a bad scrollbar position and good performance. Abdel.
[PATCH] fix bugs 2877 and 1720
This patch (against 1.4) should
1/ reimplement the OSX feature that greys-out unavailable actions when
a dialog is active
2/ fix the bug that save is not reactivated when changing document
settings.
Please test both behaviours, and in general weird toolbar things.
JMarc
Index: src/lyxfunc.C
===
--- src/lyxfunc.C (revision 15327)
+++ src/lyxfunc.C (working copy)
@@ -345,7 +345,7 @@ FuncStatus LyXFunc::getStatus(FuncReques
http://bugzilla.lyx.org/show_bug.cgi?id=1941#c4
*/
Buffer * buf;
- if (cmd.origin == FuncRequest::UI && !owner->hasFocus())
+ if (cmd.origin == FuncRequest::MENU && !owner->hasFocus())
buf = 0;
else
buf = owner->buffer();
@@ -1609,23 +1609,16 @@ void LyXFunc::dispatch(FuncRequest const
view()->owner()->updateLayoutChoice();
}
}
+ owner->updateMenubar();
+ owner->updateToolbars();
sendDispatchMessage(_(getMessage()), cmd);
}
void LyXFunc::sendDispatchMessage(string const & msg, FuncRequest const & cmd)
{
- /* When an action did not originate from the UI/kbd, it makes
- * sense to avoid updating the GUI. It turns out that this
- * fixes bug 1941, for reasons that are described here:
- * http://bugzilla.lyx.org/show_bug.cgi?id=1941#c4
- */
- if (cmd.origin != FuncRequest::INTERNAL) {
- owner->updateMenubar();
- owner->updateToolbars();
- }
-
- const bool verbose = (cmd.origin == FuncRequest::UI
+ const bool verbose = (cmd.origin == FuncRequest::MENU
+ || cmd.origin == FuncRequest::TOOLBAR
|| cmd.origin == FuncRequest::COMMANDBUFFER);
if (cmd.action == LFUN_SELFINSERT || !verbose) {
Index: src/frontends/Toolbars.C
===
--- src/frontends/Toolbars.C (revision 15327)
+++ src/frontends/Toolbars.C (working copy)
@@ -168,7 +168,7 @@ void layoutSelected(LyXView & lv, string
// Yes, the _() is correct
if (_(itname) == name) {
FuncRequest const func(LFUN_LAYOUT, itname,
- FuncRequest::UI);
+ FuncRequest::TOOLBAR);
lv.getLyXFunc().dispatch(func);
return;
}
Index: src/funcrequest.h
===
--- src/funcrequest.h (revision 15327)
+++ src/funcrequest.h (working copy)
@@ -28,7 +28,8 @@ public:
/// Where the request came from
enum Origin {
INTERNAL,
- UI, // The menu or the toolbar
+ MENU, // A menu entry
+ TOOLBAR, // A toolbar icon
KEYBOARD, // a keyboard binding
COMMANDBUFFER
};
Index: src/MenuBackend.C
===
--- src/MenuBackend.C (revision 15327)
+++ src/MenuBackend.C (working copy)
@@ -106,7 +106,7 @@ MenuItem::MenuItem(Kind kind, string con
FuncRequest const & func, bool optional)
: kind_(kind), label_(label), func_(func), optional_(optional)
{
- func_.origin = FuncRequest::UI;
+ func_.origin = FuncRequest::MENU;
}
Index: src/ToolbarBackend.C
===
--- src/ToolbarBackend.C (revision 15327)
+++ src/ToolbarBackend.C (working copy)
@@ -207,7 +207,7 @@ void ToolbarBackend::add(Toolbar & tb,
FuncRequest const & func, string const & tooltip)
{
tb.items.push_back(make_pair(func, tooltip));
- tb.items.back().first.origin = FuncRequest::UI;
+ tb.items.back().first.origin = FuncRequest::TOOLBAR;
}
Index: src/frontends/qt2/QtView.C
===
--- src/frontends/qt2/QtView.C (revision 15327)
+++ src/frontends/qt2/QtView.C (working copy)
@@ -149,11 +149,7 @@ void QtView::activated(FuncRequest const
bool QtView::hasFocus() const
{
-#if 0
return qApp->activeWindow() == this;
-#else
- return true;
-#endif
}
Re: Compiling with MSVC - and request for general status
Asger Ottar Alstrup wrote: Hi, I wanted to compile LyX on my machine to prepare for the meeting, but the README.win32 and INSTALL.win32 in trunk seem a little obsolete and not really relevant for MSVC. Could someone please update those with instructions on what to get and install to compile the Qt4 frontend using MSVC? For Qt4 and MSVC you have two solutions: 1) scons: mostly complete. Will compile and install and gives you the same level of customisation as autotools. I reckon the documentation in trunk/development/scons is enough. 2) CMake: lacks the polish of scons but is very good for development as it generates a true MSVC solution. Also, I guess it would be nice to have a high-level summary of the current status of trunk. What is stopping LyX from being usable now? I understand Unicode is the thing these days, so what needs to be done here to make things work again? I guess the main thing is to fix the LateX export WRT unicode. Once we have that, things would be pretty usable again. Other things I have in mind: - tabular is a mess: the metrics are not properly updated thus causing crashes. This needs a big cleanup IMHO - typing anything in mathed just put the cursor out of the math inset. - mouse selection does not work inside math inset (qt4 only). - bug in Qt4 math toolbar positioning. - a toolbar configuration dialog would be nice. Abdel.
Re: [PATCH] Fix command-line LateX export
Georg Baum wrote: Am Samstag, 14. Oktober 2006 16:45 schrieb Abdelrazak Younes: OK, I'll try do that changes for the GUI mode. But what do you mean by output font? If it is PS or PDF, I reckon this has nothing to do with screen fonts. Exactly. Yes, I mean PS or PDF (or DVI) font. It is very important that the result of this function is the same both with and without GUI. But that was never the case as font_metrics::width() used to return the string length when use_gui was false. It is wrong nevertheless :-( For now I guess you should remove the fontmetrics completely, use the width and add a big FIXME. Although using the width is more likely to find the wrong label this is better IMHO because the difference between GUI and noGUI export is then gone. Oups.. too late. I'll revert the change then... Maybe using something like ghostscript? I think it is easier to use preview latex, because that machinery is already in place. Good idea. These hardcoding could very well fit into the Console frontend I am preparing (attached the two first files). I don't think so. This has nothing to do with any frontend, but with the output, therefore it should not be handled in any frontend (GUI or not). You're right but then I was thinking in terms of the first patch where GUI and noGUI were different. Abdel.
Re: [PATCH] Fix command-line LateX export
Am Samstag, 14. Oktober 2006 16:45 schrieb Abdelrazak Younes: > OK, I'll try do that changes for the GUI mode. But what do you mean by > output font? If it is PS or PDF, I reckon this has nothing to do with > screen fonts. Exactly. Yes, I mean PS or PDF (or DVI) font. > > It is very important that the result of this function is the same both with > > and without GUI. > > But that was never the case as font_metrics::width() used to return the > string length when use_gui was false. It is wrong nevertheless :-( For now I guess you should remove the fontmetrics completely, use the width and add a big FIXME. Although using the width is more likely to find the wrong label this is better IMHO because the difference between GUI and noGUI export is then gone. > Maybe using something like ghostscript? I think it is easier to use preview latex, because that machinery is already in place. > These hardcoding could very well > fit into the Console frontend I am preparing (attached the two first files). I don't think so. This has nothing to do with any frontend, but with the output, therefore it should not be handled in any frontend (GUI or not). Georg
Re: Compiling with MSVC - and request for general status
Asger Ottar Alstrup wrote: I wanted to compile LyX on my machine to prepare for the meeting, but the README.win32 and INSTALL.win32 in trunk seem a little obsolete and not really relevant for MSVC. Could someone please update those with instructions on what to get and install to compile the Qt4 frontend using MSVC? The INSTALL.Win32 in the 1.4 branch provides detailed instructions for building with Q../Free and MSVC. You can follow this method and compile Qt4 yourself. Instructions for 1.5 including pre-compiled dependency packages will be available soon. Joost
Re: Tooltips toggle
On Sat, Oct 14, 2006 at 04:36:20PM +0200, Abdelrazak Younes wrote:
> Enrico Forestieri wrote:
> > On Sat, Oct 14, 2006 at 04:05:38PM +0200, Michael Gerz wrote:
> >
> >> Georg Baum schrieb:
> >>> That is a lame excuse ;-) It is very simple: If you remove an lfun, look
> >>> up
> >>> the name in src/LyXAction.C, and remove all occurrences of it in lib/ui
> >>> and lib/bind.
> >>>
> >> Even better, run
> >>
> >>find . -name ".svn" -prune -o -type f -exec grep -i
> >> "somethingobsolete" {} \; -print
> >
> > But he is on Windows and not using cygwin, AFAIK.
>
> Well I use cygwin sometimes... ;-)
Doh! Then can I mail you an archive with the cygwin/qt3 native GUI lib?
This way you could build a cygwin lyx-qt3 and surely find that damn'd bug
causing a crash ;-) (just joking, no need to reply, Abdel)
--
Enrico
Re: [PATCH] Fix command-line LateX export
Abdelrazak Younes wrote:
Georg Baum wrote:
Am Samstag, 14. Oktober 2006 15:33 schrieb Abdelrazak Younes:
That being, I really don't know why the fontMetrics is useful here
because we use a default font that we don't even know the shape.
Maybe the attached patch is good enough?
The first one is better IMO. In case you don't know what
bibitemWidest() does: It is supposed to find the bibitem with the
widest label in the output, because that is needed as an argument of
the bibliography environment to dtermine the correct indentation. To
be 100% correct we would need the metrics of the font that is used in
the output, but usually we don't have access to these.
In practice, any proportional font is probably good enough, since we
don't need to know the final with, we only need to know the which
label is the widest.
OK, thanks for the explanation.
Unless there is an easy way to get the metrics of the output font I
suggest to use a hardcoded font like "Times" or so.
OK, I'll try do that changes for the GUI mode. But what do you mean by
output font? If it is PS or PDF, I reckon this has nothing to do with
screen fonts.
It is very important that the result of this function is the same both
with and without GUI.
But that was never the case as font_metrics::width() used to return the
string length when use_gui was false.
After thinking about this it is clear that no LyXFont metrics should
be used here, since these come from the gui. If we can't easily get
the LaTeX font metrics we should make our own poor mans front metrics
replacement, e.g. by hardcoding the metrics of the standard TeX font.
Maybe using something like ghostscript? These hardcoding could very well
fit into the Console frontend I am preparing (attached the two first
files).
Abdel.
// -*- C++ -*-
/**
* \file ConsoleFontMetrics.h
* This file is part of LyX, the document processor.
* Licence details can be found in the file COPYING.
*
* \author Abdelrazak Younes
*
* Full author contact details are available in file CREDITS.
*/
#ifndef CONSOLE_FONT_METRICS_H
#define CONSOLE_FONT_METRICS_H
#include "frontends/FontMetrics.h"
#include "support/docstring.h"
namespace lyx {
namespace frontend {
class ConsoleFontMetrics: public FontMetrics
{
public:
ConsoleFontMetrics() {}
virtual ~ConsoleFontMetrics() {}
virtual int maxAscent() const { return 1; }
virtual int maxDescent() const { return 1; }
virtual int ascent(lyx::char_type c) const { return 1; }
int descent(lyx::char_type c) const { return 1; }
virtual int lbearing(lyx::char_type c) const { return 1; }
virtual int rbearing(lyx::char_type c) const { return 1; }
virtual int width(lyx::char_type const * s, size_t n) const { return n;
}
virtual int signedWidth(lyx::docstring const & s) const
{
if (s[0] == '-')
return -FontMetrics::width(s.substr(1, s.length() - 1));
else
return FontMetrics::width(s);
}
virtual void rectText(lyx::docstring const & str,
int & width,
int & ascent,
int & descent) const {};
virtual void buttonText(lyx::docstring const & str,
int & width,
int & ascent,
int & descent) {};
};
} // namespace frontend
} // namespace lyx
#endif // QT4_FONT_METRICS_H
// -*- C++ -*-
/**
* \file ConsoleFontLoader.h
* This file is part of LyX, the document processor.
* Licence details can be found in the file COPYING.
*
* \author Abdelrazak Younes
*
* Full author contact details are available in file CREDITS.
*/
#ifndef LYX_CONSOLE_FONTLOADER_H
#define LYX_CONSOLE_FONTLOADER_H
#include "ConsoleFontMetrics.h"
namespace lyx {
namespace frontend {
/// Dummy FontLoader for command-line output.
class ConsoleFontLoader: public FontLoader;
{
public:
///
ConsoleFontLoader() {}
///
virtual ~ConsoleFontLoader() {}
/// Update fonts after zoom, dpi, font names, or norm change
virtual void update() {};
/// Is the given font available ?
virtual bool available(LyXFont const & f) { return false; };
/// Get the Font metrics for this LyXFont
virtual FontMetrics const & metrics(LyXFont const & f) { return
metrics_; }
private:
///
ConsoleFontMetrics metrics_;
};
} // namespace frontend
} // namespace lyx
#endif // LYX_CONSOLE_FONTLOADER_H
Re: [PATCH] Fix command-line LateX export
Georg Baum wrote: Am Samstag, 14. Oktober 2006 15:33 schrieb Abdelrazak Younes: That being, I really don't know why the fontMetrics is useful here because we use a default font that we don't even know the shape. Maybe the attached patch is good enough? The first one is better IMO. In case you don't know what bibitemWidest() does: It is supposed to find the bibitem with the widest label in the output, because that is needed as an argument of the bibliography environment to dtermine the correct indentation. To be 100% correct we would need the metrics of the font that is used in the output, but usually we don't have access to these. In practice, any proportional font is probably good enough, since we don't need to know the final with, we only need to know the which label is the widest. OK, thanks for the explanation. Unless there is an easy way to get the metrics of the output font I suggest to use a hardcoded font like "Times" or so. OK, I'll try do that changes for the GUI mode. But what do you mean by output font? If it is PS or PDF, I reckon this has nothing to do with screen fonts. It is very important that the result of this function is the same both with and without GUI. But that was never the case as font_metrics::width() used to return the string length when use_gui was false. After thinking about this it is clear that no LyXFont metrics should be used here, since these come from the gui. If we can't easily get the LaTeX font metrics we should make our own poor mans front metrics replacement, e.g. by hardcoding the metrics of the standard TeX font. Maybe using something like ghostscript? These hardcoding could very well fit into the Console frontend I am preparing (attached the two first files). Abdel.
Compiling with MSVC - and request for general status
Hi, I wanted to compile LyX on my machine to prepare for the meeting, but the README.win32 and INSTALL.win32 in trunk seem a little obsolete and not really relevant for MSVC. Could someone please update those with instructions on what to get and install to compile the Qt4 frontend using MSVC? Also, I guess it would be nice to have a high-level summary of the current status of trunk. What is stopping LyX from being usable now? I understand Unicode is the thing these days, so what needs to be done here to make things work again? Thanks, Asger
Re: Tooltips toggle
Enrico Forestieri wrote:
On Sat, Oct 14, 2006 at 04:05:38PM +0200, Michael Gerz wrote:
Georg Baum schrieb:
That is a lame excuse ;-) It is very simple: If you remove an lfun, look up
the name in src/LyXAction.C, and remove all occurrences of it in lib/ui
and lib/bind.
Even better, run
find . -name ".svn" -prune -o -type f -exec grep -i
"somethingobsolete" {} \; -print
But he is on Windows and not using cygwin, AFAIK.
Well I use cygwin sometimes... ;-)
Abdel.
Re: Tooltips toggle
On Sat, Oct 14, 2006 at 04:05:38PM +0200, Michael Gerz wrote:
> Georg Baum schrieb:
> > That is a lame excuse ;-) It is very simple: If you remove an lfun, look up
> > the name in src/LyXAction.C, and remove all occurrences of it in lib/ui
> > and lib/bind.
> >
> Even better, run
>
>find . -name ".svn" -prune -o -type f -exec grep -i
> "somethingobsolete" {} \; -print
But he is on Windows and not using cygwin, AFAIK. Btw, -print could be
omitted and on cygwin you get faster searches using "+" in place of "\;"
as the terminator for -exec.
--
Enrico
Re: [PATCH] Fix command-line LateX export
Am Samstag, 14. Oktober 2006 15:33 schrieb Abdelrazak Younes: > That being, I really don't know why the fontMetrics is useful here > because we use a default font that we don't even know the shape. Maybe > the attached patch is good enough? The first one is better IMO. In case you don't know what bibitemWidest() does: It is supposed to find the bibitem with the widest label in the output, because that is needed as an argument of the bibliography environment to dtermine the correct indentation. To be 100% correct we would need the metrics of the font that is used in the output, but usually we don't have access to these. In practice, any proportional font is probably good enough, since we don't need to know the final with, we only need to know the which label is the widest. Unless there is an easy way to get the metrics of the output font I suggest to use a hardcoded font like "Times" or so. It is very important that the result of this function is the same both with and without GUI. After thinking about this it is clear that no LyXFont metrics should be used here, since these come from the gui. If we can't easily get the LaTeX font metrics we should make our own poor mans front metrics replacement, e.g. by hardcoding the metrics of the standard TeX font. Georg
Re: Link error
Am Samstag, 14. Oktober 2006 16:02 schrieb Michael Gerz: > Well, link fails indeed :-( With million of warnings, it is impossible > to determine what went wrong. make >o.log 2>e.log and looking at the first lines in e.log/o.log works for me in such cases. > Did you really succeed on SuSE 9.3? Yes. But it could be a boost issue, since I use a centrally installed boost. > I compile with scons. Maybe I have > to rebuild everything from scratch... I use autotools. Georg
Re: Tooltips toggle
Georg Baum schrieb:
That is a lame excuse ;-) It is very simple: If you remove an lfun, look up
the name in src/LyXAction.C, and remove all occurrences of it in lib/ui
and lib/bind.
Even better, run
find . -name ".svn" -prune -o -type f -exec grep -i
"somethingobsolete" {} \; -print
Michael
Re: Tooltips toggle
Am Samstag, 14. Oktober 2006 14:38 schrieb Abdelrazak Younes: > Michael Gerz wrote: > > Abdel, > > > > you forgot to remove tooltips-toggle from the UI files. > > That's because I don't know much about UI files :-/ That is a lame excuse ;-) It is very simple: If you remove an lfun, look up the name in src/LyXAction.C, and remove all occurrences of it in lib/ui and lib/bind. Georg
Re: Link error
Georg Baum schrieb: Does the link fail not? If it does not fail ignore this. I get similar messages on my SuSE 9.3 box, the reason is a gcc/binutils compatibility problem that is solved in newer versions. As long as the link succeeeds I have never seen any problems resulting from this. Well, link fails indeed :-( With million of warnings, it is impossible to determine what went wrong. Did you really succeed on SuSE 9.3? I compile with scons. Maybe I have to rebuild everything from scratch... Michael
Re: Link error
Am Samstag, 14. Oktober 2006 14:31 schrieb Michael Gerz: > Hi, > > since about 2 days I cannot link any more (SuSE Linux 9.3). I get > millions of uncomprehensible console messages: > > /usr/lib/gcc-lib/i586-suse-linux/3.3.5/../../../../i586-suse-linux/bin/ld: > `.gnu.linkonce.t._ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_12regex_traitsIcNS_16cpp_regex_traitsIcE15match_startmarkEv' > referenced in section `.rodata' of > debug/libs/liblyxbase_pre.a(vc-backend.o): defined in discarded section > `.gnu.linkonce.t._ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_12regex_traitsIcNS_16cpp_regex_traitsIcE15match_startmarkEv' > of debug/libs/liblyxbase_pre.a(vc-backend.o) > > Does anybody know what is going on? Does the link fail not? If it does not fail ignore this. I get similar messages on my SuSE 9.3 box, the reason is a gcc/binutils compatibility problem that is solved in newer versions. As long as the link succeeeds I have never seen any problems resulting from this. Georg
Re: [Patch] math_font_available() returns true when lyx::use_gui is false (was Re: [Cvslog] r15327 - in /lyx-devel/trunk/src: lyx_main.C mathed/MathF...)
Georg Baum wrote: Am Samstag, 14. Oktober 2006 14:04 schrieb Abdelrazak Younes: Georg Baum wrote: Am Samstag, 14. Oktober 2006 13:46 schrieb Abdelrazak Younes: Georg Baum wrote: It was used for requirements like ams. The second part of the patch is definitely right, the first one is wrong, since the fonts are only used for drawing and metrics. I don't understand. That's exactly what the first part of the patch is doing: avoid the font searching in case when lyx::use_gui=false. So one part cannot go with the other. The problem is that it also lies: It says that the fonts are available, but they are not. If you simply want to skip the searching, return false, But if I do that, won't this affect the proper export of the math formulas? No. As I wrote, the result of this check is only used in draw() and metrics(). Therefore you will not notice any difference if you return false. Nevertheless false is the correct value to use, because the result might be used differently in the future. I understand, thanks. Will commit soon then. Abdel.
Re: [Patch] math_font_available() returns true when lyx::use_gui is false (was Re: [Cvslog] r15327 - in /lyx-devel/trunk/src: lyx_main.C mathed/MathF...)
Am Samstag, 14. Oktober 2006 14:04 schrieb Abdelrazak Younes: > Georg Baum wrote: > > Am Samstag, 14. Oktober 2006 13:46 schrieb Abdelrazak Younes: > >> Georg Baum wrote: > >>> It was used for requirements like ams. The second part of the patch is > >>> definitely right, the first one is wrong, since the fonts are only used > >>> for drawing and metrics. > >> I don't understand. That's exactly what the first part of the patch is > >> doing: avoid the font searching in case when lyx::use_gui=false. So one > >> part cannot go with the other. > > > > The problem is that it also lies: It says that the fonts are available, but > > they are not. If you simply want to skip the searching, return false, > > But if I do that, won't this affect the proper export of the math formulas? No. As I wrote, the result of this check is only used in draw() and metrics(). Therefore you will not notice any difference if you return false. Nevertheless false is the correct value to use, because the result might be used differently in the future. Georg
Re: [PATCH] Fix command-line LateX export
Abdelrazak Younes wrote:
Hello,
This patch fixes a crash when doing latex export. This is because
theFontMetrics() is accessed while in non GUI mode (lyx::use_gui =
false). This is due to my code reorganisation, theApp is null when
use_gui = false. I promise to get rid of all those use_gui checking once
I have completed the Console frontend.
That being, I really don't know why the fontMetrics is useful here
because we use a default font that we don't even know the shape. Maybe
the attached patch is good enough?
Abdel.
Index: insetbibitem.C
===
--- insetbibitem.C (revision 15322)
+++ insetbibitem.C (working copy)
@@ -21,8 +21,6 @@
#include "paragraph.h"
#include "ParagraphList.h"
-#include "frontends/FontMetrics.h"
-
#include "support/lstrings.h"
#include "support/std_ostream.h"
#include "support/convert.h"
@@ -145,9 +143,6 @@
// Does look like a hack? It is! (but will change at 0.13)
InsetBibitem const * bitem = 0;
- // FIXME font is used unitialized, is that correct?
- LyXFont font;
- lyx::frontend::FontMetrics const & fm = theFontMetrics(font);
ParagraphList::const_iterator it = buffer.paragraphs().begin();
ParagraphList::const_iterator end = buffer.paragraphs().end();
@@ -156,8 +151,7 @@
if (it->bibitem()) {
docstring const label = it->bibitem()->getBibLabel();
- int const wx =
- fm.width(label);
+ int const wx = label.size();
if (wx > w) {
w = wx;
bitem = it->bibitem();
[PATCH] Fix command-line LateX export
Hello,
This patch fixes a crash when doing latex export. This is because
theFontMetrics() is accessed while in non GUI mode (lyx::use_gui =
false). This is due to my code reorganisation, theApp is null when
use_gui = false. I promise to get rid of all those use_gui checking once
I have completed the Console frontend.
Abdel.
Index: insets/insetbibitem.C
===
--- insets/insetbibitem.C (revision 15322)
+++ insets/insetbibitem.C (working copy)
@@ -38,6 +38,9 @@
int InsetBibitem::key_counter = 0;
string const key_prefix = "key-";
+namespace lyx {
+extern bool use_gui;
+}
InsetBibitem::InsetBibitem(InsetCommandParams const & p)
: InsetCommand(p, "bibitem"), counter(1)
@@ -147,7 +150,6 @@
InsetBibitem const * bitem = 0;
// FIXME font is used unitialized, is that correct?
LyXFont font;
- lyx::frontend::FontMetrics const & fm = theFontMetrics(font);
ParagraphList::const_iterator it = buffer.paragraphs().begin();
ParagraphList::const_iterator end = buffer.paragraphs().end();
@@ -156,8 +158,8 @@
if (it->bibitem()) {
docstring const label = it->bibitem()->getBibLabel();
- int const wx =
- fm.width(label);
+ int const wx = lyx::use_gui?
+ theFontMetrics(font).width(label): label.size();
if (wx > w) {
w = wx;
bitem = it->bibitem();
Re: [patch] wide streams - last version
On Sat, Oct 14, 2006 at 10:45:52AM +0200, Georg Baum wrote:
> Am Freitag, 13. Oktober 2006 19:33 schrieb Enrico Forestieri:
>
> > Sorry, Georg, I forgot to mention that I don't think it is related
> > to this patch, too, but if I revert it the final link stage fails.
>
> Why? I don't understand.
Because I get undefined references.
> But you can do a binary search for revisions that
> work and that don't in order to find out which patch is the culprit.
Yes, I will experiment with "svn up -r x".
> > What I could do is compiling LyX using my patched STLPort library, after
> > hacking config.h by changing the SIZEOF_WCHAR_T define to 4.
>
> I would not do that. How could that help?
I tried compiling LyX on linux and there I get a lot of EILSEQ warnings
("EILSEQ An invalid multibyte sequence has been encountered...") exactly
where I get crashes on cygwin. As the way I patched STLPort a wchar_t is
4 bytes (so I actually don't need your workarounds), if it doesn't crash
but gives the same warnings, I would have a little clue, I think.
> > A full recompile takes almost 2 hours here, though.
>
> Get ccache.
Already tried that long ago, but on Windows it may even slow further down
the compiles. Scons is a bit faster than autotools, but frankly I find
that autotools are a bit more easily customizable when you want to do
non-standards builds (and my cygwin/qt3/4 libs are quite non-standard).
--
Enrico
Re: Tooltips toggle
Michael Gerz wrote: Abdel, you forgot to remove tooltips-toggle from the UI files. That's because I don't know much about UI files :-/ I will fix the files in a minute... Thanks, Abdel.
Tooltips toggle
Abdel, you forgot to remove tooltips-toggle from the UI files. I will fix the files in a minute... Michael Index: bind/aqua.bind === --- bind/aqua.bind (Revision 15327) +++ bind/aqua.bind (Arbeitskopie) @@ -139,7 +139,6 @@ \bind "M-~S-n b 4" "bookmark-goto 4" \bind "M-~S-n b 5" "bookmark-goto 5" -\bind "M-~S-h o" "tooltips-toggle" \bind "M-~S-h i" "help-open Intro" \bind "M-~S-h t" "help-open Tutorial" \bind "M-~S-h u" "help-open UserGuide" Index: ui/classic.ui === --- ui/classic.ui (Revision 15327) +++ ui/classic.ui (Arbeitskopie) @@ -401,8 +401,6 @@ # HELP MENU # Menu "help" - Item "Tooltips|o" "tooltips-toggle" - Separator Item "Introduction|I" "help-open Intro" Item "Tutorial|T" "help-open Tutorial" Item "User's Guide|U" "help-open UserGuide" Index: ui/stdmenus.ui === --- ui/stdmenus.ui (Revision 15327) +++ ui/stdmenus.ui (Arbeitskopie) @@ -258,8 +258,6 @@ Item "Open All Insets|O" "all-insets-toggle open" Item "Close All Insets|C" "all-insets-toggle close" Separator - Item "Display Tooltips|i" "tooltips-toggle" - Separator Item "View source|s" "dialog-show view-source" Submenu "Update|U" "view_update" ViewFormats
Link error
Hi, since about 2 days I cannot link any more (SuSE Linux 9.3). I get millions of uncomprehensible console messages: /usr/lib/gcc-lib/i586-suse-linux/3.3.5/../../../../i586-suse-linux/bin/ld: `.gnu.linkonce.t._ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_12regex_traitsIcNS_16cpp_regex_traitsIcE15match_startmarkEv' referenced in section `.rodata' of debug/libs/liblyxbase_pre.a(vc-backend.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_12regex_traitsIcNS_16cpp_regex_traitsIcE15match_startmarkEv' of debug/libs/liblyxbase_pre.a(vc-backend.o) Does anybody know what is going on? Michael
Re: [patch] wide streams - last version
Georg Baum wrote: Am Samstag, 14. Oktober 2006 13:20 schrieb Abdelrazak Younes: Georg Baum wrote: What I do not understand is why it works on windows this way but did not with the old approach. My explanation yesterday did not satisfy you? It did, but I do not understand what is different now. I think the main point is this snippet from your message: "The problem is that QApplication::exit() was called somewhere during LyX::ref().exec2() which caused the QApplication instance to disappear. The static trick enabled us to make this instance persistent across functions." We still call QApplication::exit() in LyX::exec2() if something goes wrong. The destruction of the Application object does still happen after calling LyX::exec2(), so why are the problems gone? The exit() call stops the event processing. There is no QTimer available any more. Some QObjects were still not killed at this time (socket_callbacks contains QObjects) and where trying to access the main QTimer which was already dead. This is not happening any more. I think this is due to my reorganisation work and the elimination of global variables. Every QObject used is now created within the Application context. My understanding is that this ensure that it is properly shut down. BTW, you should now merge LyX::exec2 with LyX::pricv_exec(). exec2 was only created to be able to use the Application object as an autonatic variable and is not needed anymore. Indeed. Abdel.
Re: [Patch] math_font_available() returns true when lyx::use_gui is false (was Re: [Cvslog] r15327 - in /lyx-devel/trunk/src: lyx_main.C mathed/MathF...)
Georg Baum wrote: Am Samstag, 14. Oktober 2006 13:46 schrieb Abdelrazak Younes: Georg Baum wrote: It was used for requirements like ams. The second part of the patch is definitely right, the first one is wrong, since the fonts are only used for drawing and metrics. I don't understand. That's exactly what the first part of the patch is doing: avoid the font searching in case when lyx::use_gui=false. So one part cannot go with the other. The problem is that it also lies: It says that the fonts are available, but they are not. If you simply want to skip the searching, return false, But if I do that, won't this affect the proper export of the math formulas? but I think this is the wrong place to check for use_gui, this should rather be done in the font loader. I agree but now FontLoader is an Application member. This is the very reason why I wanted to create this console frontend. Once we have that, all lyx::use_gui test can go (except in lyx_main and lyx_cb that is). Abdel.
Re: [Patch] math_font_available() returns true when lyx::use_gui is false (was Re: [Cvslog] r15327 - in /lyx-devel/trunk/src: lyx_main.C mathed/MathF...)
Am Samstag, 14. Oktober 2006 13:46 schrieb Abdelrazak Younes: > Georg Baum wrote: > > It was used for requirements like ams. The second part of the patch is > > definitely right, the first one is wrong, since the fonts are only used > > for drawing and metrics. > > I don't understand. That's exactly what the first part of the patch is > doing: avoid the font searching in case when lyx::use_gui=false. So one > part cannot go with the other. The problem is that it also lies: It says that the fonts are available, but they are not. If you simply want to skip the searching, return false, but I think this is the wrong place to check for use_gui, this should rather be done in the font loader. Georg
Re: [1.5.0svn] issues with coordcache.h
Georg Baum wrote: Am Samstag, 14. Oktober 2006 12:48 schrieb Abdelrazak Younes: Georg Baum wrote: Am Samstag, 14. Oktober 2006 02:35 schrieb Timothy Reaves: Does this patch fix it? Why not just "#undef check"? I did not think of that, but it is better because it prevents this problem coming up at other places, too. OK, I'll commit it then. Abdel.
Re: [patch] wide streams - last version
Am Samstag, 14. Oktober 2006 13:20 schrieb Abdelrazak Younes: > Georg Baum wrote: > > What I do not understand is why it works on windows this way but did not > > with the old approach. > > My explanation yesterday did not satisfy you? It did, but I do not understand what is different now. I think the main point is this snippet from your message: "The problem is that QApplication::exit() was called somewhere during LyX::ref().exec2() which caused the QApplication instance to disappear. The static trick enabled us to make this instance persistent across functions." We still call QApplication::exit() in LyX::exec2() if something goes wrong. The destruction of the Application object does still happen after calling LyX::exec2(), so why are the problems gone? BTW, you should now merge LyX::exec2 with LyX::pricv_exec(). exec2 was only created to be able to use the Application object as an autonatic variable and is not needed anymore. Georg
Re: [Patch] math_font_available() returns true when lyx::use_gui is false (was Re: [Cvslog] r15327 - in /lyx-devel/trunk/src: lyx_main.C mathed/MathF...)
Georg Baum wrote: Am Samstag, 14. Oktober 2006 12:42 schrieb Abdelrazak Younes: Georg Baum wrote: Am Freitag, 13. Oktober 2006 23:27 schrieb [EMAIL PROTECTED]: Author: younes Date: Fri Oct 13 23:27:55 2006 New Revision: 15327 URL: http://www.lyx.org/trac/changeset/15327 Log: enable buffer-export without loading the GUI. * lyx_main.C: - parse_export(): set lyx::use_gui to false. * MathFactory.C: - initMath(): initSymbols() only if lyx::use_gui is true. Both is wrong, please revert. initSymbols() loads information about math commands that is needed to parse math stuff correctly, so this is also needed without gui. Unfortunately it also requires some font information, so lyx::use_gui was set to true on purpose. There is a closed bug about this somewhere in bugzilla. I found the bug: http://bugzilla.lyx.org/show_bug.cgi?id=1665 I understand. But is the font imformation really required? After reading the bug I am not sure anymore. It looks like it is not required anymore. Won't the attached patch solves the problem. If not, why do we need these font information if we don't display anything on screen? It was used for requirements like ams. The second part of the patch is definitely right, the first one is wrong, since the fonts are only used for drawing and metrics. I don't understand. That's exactly what the first part of the patch is doing: avoid the font searching in case when lyx::use_gui=false. So one part cannot go with the other. I believe that the math part would then be fixed. The change of lyx::use_gui really looked suspicious to me, since it matched so well the old problem. I did some search in svn and found out that you set lyx::use_gui to true in revision 15306 (probably a copy/paste error), so this fix was ok. Yes, and that was the reason why I reverted it to false but then, because of the FontMetrics access which were not available anymore it crashed. What you can see from this conversation is that it really helps to send patches in advance to the list, together with a short explanation. That would have saved me some time. I know that I also committed several changes directly lately, but they were purely mechanical. Yes, sorry but I thought this one was purely mechanical also. On the plus side, we can now use the export feature without loading the GUI now. At least for text. I will test the other formats. Abdel.
Re: [Patch] math_font_available() returns true when lyx::use_gui is false (was Re: [Cvslog] r15327 - in /lyx-devel/trunk/src: lyx_main.C mathed/MathF...)
Am Samstag, 14. Oktober 2006 12:42 schrieb Abdelrazak Younes: > Georg Baum wrote: > > Am Freitag, 13. Oktober 2006 23:27 schrieb [EMAIL PROTECTED]: > >> Author: younes > >> Date: Fri Oct 13 23:27:55 2006 > >> New Revision: 15327 > >> > >> URL: http://www.lyx.org/trac/changeset/15327 > >> Log: > >> enable buffer-export without loading the GUI. > >> > >> * lyx_main.C: > >> - parse_export(): set lyx::use_gui to false. > >> > >> * MathFactory.C: > >> - initMath(): initSymbols() only if lyx::use_gui is true. > > > > Both is wrong, please revert. > > > > initSymbols() loads information about math commands that is needed to parse > > math stuff correctly, so this is also needed without gui. Unfortunately it > > also requires some font information, so lyx::use_gui was set to true on > > purpose. There is a closed bug about this somewhere in bugzilla. I found the bug: http://bugzilla.lyx.org/show_bug.cgi?id=1665 > I understand. But is the font imformation really required? After reading the bug I am not sure anymore. It looks like it is not required anymore. > Won't the > attached patch solves the problem. If not, why do we need these font > information if we don't display anything on screen? It was used for requirements like ams. The second part of the patch is definitely right, the first one is wrong, since the fonts are only used for drawing and metrics. I believe that the math part would then be fixed. The change of lyx::use_gui really looked suspicious to me, since it matched so well the old problem. I did some search in svn and found out that you set lyx::use_gui to true in revision 15306 (probably a copy/paste error), so this fix was ok. What you can see from this conversation is that it really helps to send patches in advance to the list, together with a short explanation. That would have saved me some time. I know that I also committed several changes directly lately, but they were purely mechanical. Georg
Re: [patch] wide streams - last version
Georg Baum wrote: Am Freitag, 13. Oktober 2006 18:49 schrieb Abdelrazak Younes: I have committed this one as this seems to be the direct culprit of your crash and it is safe anyway. It looks like it solved the crash both in qt3 and qt4. Disclaimer: This is on a different machine with different qt versions, so the crash could still happen on the other one, but experience tells that this is unlikely. Thanks for the fix! You're welcome. I always keep my promise ;-) What I do not understand is why it works on windows this way but did not with the old approach. My explanation yesterday did not satisfy you? I've come to understand that by debug stepping through Qt. I recommend everyone to do this to understand the LyX and Qt structure. Abdel.
Re: [patch] wide streams - last version
Am Freitag, 13. Oktober 2006 18:49 schrieb Abdelrazak Younes: > I have committed this one as this seems to be the direct culprit of your > crash and it is safe anyway. It looks like it solved the crash both in qt3 and qt4. Disclaimer: This is on a different machine with different qt versions, so the crash could still happen on the other one, but experience tells that this is unlikely. Thanks for the fix! What I do not understand is why it works on windows this way but did not with the old approach. Georg
Re: [1.5.0svn] issues with coordcache.h
Am Samstag, 14. Oktober 2006 12:48 schrieb Abdelrazak Younes: > Georg Baum wrote: > > Am Samstag, 14. Oktober 2006 02:35 schrieb Timothy Reaves: > > > > Does this patch fix it? > > Why not just "#undef check"? I did not think of that, but it is better because it prevents this problem coming up at other places, too. Georg
Re: [1.5.0svn] issues with coordcache.h
Georg Baum wrote: Am Samstag, 14. Oktober 2006 02:35 schrieb Timothy Reaves: Does this patch fix it? Why not just "#undef check"? You should complain to apple that they define a check() macro, that is calling for problems. Yep. BTW the Point class in coordcache.h should be in a lyx namespace. Yep, CoordCacheBase and CoordCache also. Abdel. Index: coordcache.h === --- coordcache.h(revision 15324) +++ coordcache.h(working copy) @@ -11,6 +11,9 @@ #ifndef COORDCACHE_H #define COORDCACHE_H +// It seems that MacOSX define the check macro. +#undef check + class InsetBase; class LyXText; class MathArray;
[Patch] math_font_available() returns true when lyx::use_gui is false (was Re: [Cvslog] r15327 - in /lyx-devel/trunk/src: lyx_main.C mathed/MathF...)
Georg Baum wrote:
Am Freitag, 13. Oktober 2006 23:27 schrieb [EMAIL PROTECTED]:
Author: younes
Date: Fri Oct 13 23:27:55 2006
New Revision: 15327
URL: http://www.lyx.org/trac/changeset/15327
Log:
enable buffer-export without loading the GUI.
* lyx_main.C:
- parse_export(): set lyx::use_gui to false.
* MathFactory.C:
- initMath(): initSymbols() only if lyx::use_gui is true.
Both is wrong, please revert.
initSymbols() loads information about math commands that is needed to parse
math stuff correctly, so this is also needed without gui. Unfortunately it
also requires some font information, so lyx::use_gui was set to true on
purpose. There is a closed bug about this somewhere in bugzilla.
I understand. But is the font imformation really required? Won't the
attached patch solves the problem. If not, why do we need these font
information if we don't display anything on screen?
Abdel.
Index: mathed/MathFactory.C
===
--- mathed/MathFactory.C(revision 15327)
+++ mathed/MathFactory.C(working copy)
@@ -87,6 +87,9 @@
bool math_font_available(string & name)
{
+ if (!lyx::use_gui)
+ return true;
+
LyXFont f;
augmentFont(f, name);
@@ -230,8 +233,7 @@
if (!initialized) {
initialized = true;
initParser();
- if (lyx::use_gui)
- initSymbols();
+ initSymbols();
}
}
Re: [1.5.0svn] issues with coordcache.h
Am Samstag, 14. Oktober 2006 02:35 schrieb Timothy Reaves: > g++-4 -DHAVE_CONFIG_H -I. -I. -I../../../src -DQT_CLEAN_NAMESPACE > -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -Winvalid-pch > --include=./pch.h -I../../../src -I../../../src/frontends > -I../../../images -I/usr/local/Trolltech/Qt-4.2.0/include > -I/usr/local/Trolltech/Qt-4.2.0/include/QtCore > -I/usr/local/Trolltech/Qt-4.2.0/include/QtGui -I../../../boost > -I../../../src/frontends/controllers -Wextra -Wall -I/sw/include -g -Os > -MT GuiApplication.lo -MD -MP -MF .deps/GuiApplication.Tpo -c > GuiApplication.C -o GuiApplication.o > In file included from ../../../src/BufferView.h:18, > from GuiApplication.C:27: > ../../../src/coordcache.h:59:19: error: macro "check" passed 2 > arguments, but takes just 1 > ../../../src/coordcache.h:65:19: error: macro "check" passed 2 > arguments, but takes just 1 > ../../../src/coordcache.h:71:20: error: macro "check" passed 2 > arguments, but takes just 1 > ../../../src/coordcache.h:89:47: error: macro "check" passed 2 > arguments, but takes just 1 > ../../../src/coordcache.h:27: error: redefinition of 'class Point' > /System/Library/Frameworks/CoreServices.framework/Headers/../Frameworks/CarbonCore.framework/Headers/MacTypes.h:485: > Does this patch fix it? You should complain to apple that they define a check() macro, that is calling for problems. BTW the Point class in coordcache.h should be in a lyx namespace. Georg Index: src/frontends/qt4/GuiApplication.C === --- src/frontends/qt4/GuiApplication.C (Revision 15327) +++ src/frontends/qt4/GuiApplication.C (Arbeitskopie) @@ -14,6 +14,10 @@ #include "GuiApplication.h" +// This must be included before all qt stuff, since on OS X some qt header +// pulls in a macro check(), and we have a check() method in coordcache.h. +#include "BufferView.h" + #include "qt_helpers.h" #include "QLImage.h" #include "socket_callback.h" @@ -24,7 +28,6 @@ #include "support/os.h" #include "support/package.h" -#include "BufferView.h" #include "Color.h" #include "debug.h" #include "lyx_main.h"
Re: [Cvslog] r15327 - in /lyx-devel/trunk/src: lyx_main.C mathed/MathF...
Am Freitag, 13. Oktober 2006 23:27 schrieb [EMAIL PROTECTED]: > Author: younes > Date: Fri Oct 13 23:27:55 2006 > New Revision: 15327 > > URL: http://www.lyx.org/trac/changeset/15327 > Log: > enable buffer-export without loading the GUI. > > * lyx_main.C: > - parse_export(): set lyx::use_gui to false. > > * MathFactory.C: > - initMath(): initSymbols() only if lyx::use_gui is true. Both is wrong, please revert. initSymbols() loads information about math commands that is needed to parse math stuff correctly, so this is also needed without gui. Unfortunately it also requires some font information, so lyx::use_gui was set to true on purpose. There is a closed bug about this somewhere in bugzilla. Georg
Re: [patch] wide streams - last version
Am Freitag, 13. Oktober 2006 19:33 schrieb Enrico Forestieri: > Sorry, Georg, I forgot to mention that I don't think it is related > to this patch, too, but if I revert it the final link stage fails. Why? I don't understand. But you can do a binary search for revisions that work and that don't in order to find out which patch is the culprit. > What I could do is compiling LyX using my patched STLPort library, after > hacking config.h by changing the SIZEOF_WCHAR_T define to 4. I would not do that. How could that help? > A full recompile takes almost 2 hours here, though. Get ccache. Georg
