Re: Arrival/departure dates for Bromarv?
On Tue, Jul 10, 2007 at 11:25:14PM +0200, [EMAIL PROTECTED] wrote: > On Tue, 10 Jul 2007, Andre Poenitz wrote: ... > I've now booked my flight, I arrive in Helsinki 14:00, you at 14:45 and > Jean-Marc at 14:50. So I'll just have a late lunch while waiting. All on thursday 9th? Then perhaps we should just pick you up by car. I'll talk to the CEO about it ;-) > > Both should be enough to reach the regular bus to/from Bromarv. > Ok. > > > Is there anybody else coming btw? > > I don't think so... Martin? Lars was planning to come by bike. And then Jose and Susana... Jose? > Anything special to bring? We have bedlinen and towels and all... but do bring as many laptops as you can, with ethernet cables / wireless cards, and a spare hub or ADSL modem if you have one. Last Saturday we had the thunderstorm of the century - phone dead, internet dead. Two working days, said Sonera. We'll see. I have some contingency plans for that... A yes, bring swimming clothes. Nice sand beach close by. > Should I bring a laptop? I can take my old Dell (300MHz,256MB) which > probably isn't too useful, or my work laptop (mass=7 kg including PSU). One with a working LyX SVN local tree, and a compiler that doesn't run out of steam ;-) > /C > > It's kind of funny that I take off and land at the same time on the way > back... Hmmm... I once landed 5 min before departure. - Martin
[patch] tiny cosmetics
this is really just to make the paragraph dialog look a little bit more compact, i.e. I reduced the ugly whitespace on the bottom, no other change. OK to commit? Jürgen Index: src/frontends/qt4/ui/ParagraphUi.ui === --- src/frontends/qt4/ui/ParagraphUi.ui (Revision 19033) +++ src/frontends/qt4/ui/ParagraphUi.ui (Arbeitskopie) @@ -9,7 +9,7 @@ 0 0 488 -334 +286 @@ -36,52 +36,6 @@ 6 - - - - Qt::Vertical - - - - 20 - 31 - - - - - - - - 0 - - - 6 - - - - -Indent &Paragraph - - - - - - -Qt::Horizontal - - -QSizePolicy::Expanding - - - - 20 - 20 - - - - - - @@ -151,61 +105,64 @@ - - - - 0 + + + + Qt::Vertical - - 6 + + + 20 + 16 + - - - -L&ine spacing: - - -linespacing - - - - - - - - Default + + + + + + false + + + + 5 + 1 + 0 + 0 + + + + Label Width + + + + 9 + + + 6 + + + + + This text defines the width of the paragraph label - - - - Single + + + + + + This text defines the width of the paragraph label - - - 1.5 + &Longest label - - - - Double + + labelWidth - - - - Custom - - - - - - - -false - - - - + + + + @@ -273,52 +230,95 @@ - - - - false + + + + 0 - - - 5 - 1 - 0 - 0 - + + 6 - - Label Width - - - - 9 - - - 6 - - - - - This text defines the width of the paragraph label + + + +L&ine spacing: + + +linespacing + + + + + + + + Default - - - - - - This text defines the width of the paragraph label + + + + Single + + - &Longest label + 1.5 - - labelWidth + + + + Double - - - - + + + + Custom + + + + + + + +false + + + + + + + + 0 + + + 6 + + + + +Indent &Paragraph + + + + + + +Qt::Horizontal + + +QSizePolicy::Expanding + + + + 20 + 20 + + + + + +
Re: Help in understanding GUI structure
Tommaso Cucinotta wrote: Hi, I'm not managing to figure out where, in the LyX code, it is decided where to put the GuiWorkArea instance into the main window (LyXView) layout. In GuiImplementation::newWorkArea() but this might change in the future to be put directly in LyXView. It doesn't seem to exist a .ui file for that, does it ? No, doesn't need to as there are no controls except for the scrollbar. See the Qt doc for QAbstractScrollArea if you want more detail. Abdel.
Re: r19028 - in /lyx-devel/branches/BRANCH_1_4_X: src/fronten...
Joost Verburg wrote: > Abdelrazak Younes wrote: >> 1) you have a patch ready using LoadLibrary/GetProcAddress before >> tomorrow: 1.5.0 will support Win9X! > > Here is the patch. I tested it and it works for me. > > Win9x support for 1.5 will be delayed anyway because it often crashes > when going into math mode. I won't be able to fix that before tomorrow. > > Joost What about using my patch and to replace the QLibrary code with your native calls? Peter
Re: \propto displayed as \mu
On Tue, 2007-07-10 at 19:57 +0100, José Matos wrote: > On Tuesday 10 July 2007 19:48:44 Michael Gerz wrote: > > > > On Win XP, LyX 1.5.0svn, \propto looks identical in LyX and in DVI > > output (similar to a greek alpha symbol) > > And so it does on Linux (Fedora 7). I think the main point that Darren > points are the missing fonts in his installation. I find it odd though that in all other cases I get red text, but here I get the wrong symbol instead. Surely this isn't right? Have fun, Darren
INSTALL.cmake
Could we rename README.cmake into INSTALL.cmake and move it to top level trunk? It would be great if someone could also have a look at the content, layout, English, formating, ... Thanks, Peter
Re: Status of LyX 1.5.0?
Enrico Forestieri wrote: > On Tue, Jul 10, 2007 at 09:40:38PM +0200, Peter Kümmel wrote: >> Here an updated patch which only calls the Ex functions >> if they are available. >> >> And what was the status? It doesn't work on Vista? >> And also needs some chmod changes on cygwin? > > The patch works on Vista. However, for some inexplicable reason the > font files must have the executable flag set. I only found > this explanation: http://cygwin.com/ml/cygwin/2005-11/msg00100.html > hinting that "the executable flag means more than just execution" > in Windows. This is not cygwin related, though. I incurred in this > "bug" only because the cygwin svn did not set the executable flag > on the files in lib/fonts. When the fonts are installed through the > NSIS or cygwin installation tools, everything is fine, seemingly. > Isn't this stuff for the installer? But we could also set the flags in os_win32/os_cgwin, but I can't do it before this evening. Therefore, if LyX is really released today and we use my patch, then someone should just commit it. Maybe we should move the common code into a new file, os_win.cpp, and include this one in the other two files. -- Peter Kümmel
Re: r19028 - in /lyx-devel/branches/BRANCH_1_4_X: src/fronten...
On Wed, Jul 11, 2007 at 12:14:29AM +0200, Joost Verburg wrote: > Abdelrazak Younes wrote: > > 1) you have a patch ready using LoadLibrary/GetProcAddress before > > tomorrow: 1.5.0 will support Win9X! > > Here is the patch. I tested it and it works for me. Hmm. Seems that you and Peter are treading on each other's toes. The patch by Peter seems to be more comprehensive, though... -- Enrico
Re: Status of LyX 1.5.0?
On Tue, Jul 10, 2007 at 09:40:38PM +0200, Peter Kümmel wrote: > Here an updated patch which only calls the Ex functions > if they are available. > > And what was the status? It doesn't work on Vista? > And also needs some chmod changes on cygwin? The patch works on Vista. However, for some inexplicable reason the font files must have the executable flag set. I only found this explanation: http://cygwin.com/ml/cygwin/2005-11/msg00100.html hinting that "the executable flag means more than just execution" in Windows. This is not cygwin related, though. I incurred in this "bug" only because the cygwin svn did not set the executable flag on the files in lib/fonts. When the fonts are installed through the NSIS or cygwin installation tools, everything is fine, seemingly. -- Enrico
Help in understanding GUI structure
Hi, I'm not managing to figure out where, in the LyX code, it is decided where to put the GuiWorkArea instance into the main window (LyXView) layout. It doesn't seem to exist a .ui file for that, does it ? Thanx, bye, T. -- Tommaso Cucinotta, Computer Engineering PhD, Researcher ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy Tel +39 050 882 024, Fax +39 050 882 003 http://feanor.sssup.it/~tommaso
Re: r19028 - in /lyx-devel/branches/BRANCH_1_4_X: src/fronten...
Abdelrazak Younes wrote:
1) you have a patch ready using LoadLibrary/GetProcAddress before
tomorrow: 1.5.0 will support Win9X!
Here is the patch. I tested it and it works for me.
Win9x support for 1.5 will be delayed anyway because it often crashes
when going into math mode. I won't be able to fix that before tomorrow.
Joost
Index: support/os_win32.cpp
===
--- support/os_win32.cpp(revision 19016)
+++ support/os_win32.cpp(working copy)
@@ -74,6 +74,11 @@
using lyx::support::addPath;
using lyx::support::package;
+// API definition for manually calling font functions on Windows 2000 and later
+typedef int (WINAPI *FONTAPI)(LPCSTR, DWORD, PVOID);
+#define FR_PRIVATE 0x10
+
+// Names of TrueType fonts to load
string const win_fonts_truetype[] = {"cmex10", "cmmi10", "cmr10", "cmsy10",
"eufm10", "msam10", "msbm10", "wasy10", "esint10"};
const int num_fonts_truetype = sizeof(win_fonts_truetype) /
sizeof(*win_fonts_truetype);
@@ -408,11 +413,22 @@
// Windows only: Add BaKoMa TrueType font resources
string const fonts_dir =
addPath(package().system_support().absFilename(), "fonts");
+ HMODULE hDLL = LoadLibrary("gdi32");
+ FONTAPI pAddFontResourceEx = (FONTAPI) GetProcAddress(hDLL,
"AddFontResourceExA");
+
for (int i = 0 ; i < num_fonts_truetype ; ++i) {
string const font_current =
addName(fonts_dir, win_fonts_truetype[i] + ".ttf");
-
AddFontResource(to_local8bit(from_utf8(external_path(font_current))).c_str());
+ if (pAddFontResourceEx) {
+ // Windows 2000 and later: Use AddFontResourceEx for
private font
+
pAddFontResourceEx(to_local8bit(from_utf8(external_path(font_current))).c_str(),
FR_PRIVATE, 0);
+ } else {
+ // Older Windows versions: Use AddFontResource
+
AddFontResource(to_local8bit(from_utf8(external_path(font_current))).c_str());
+ }
}
+
+ FreeLibrary(hDLL);
}
@@ -421,11 +437,22 @@
// Windows only: Remove BaKoMa TrueType font resources
string const fonts_dir =
addPath(package().system_support().absFilename(), "fonts");
+ HMODULE hDLL = LoadLibrary("gdi32");
+ FONTAPI pRemoveFontResourceEx = (FONTAPI) GetProcAddress(hDLL,
"RemoveFontResourceExA");
+
for(int i = 0 ; i < num_fonts_truetype ; ++i) {
string const font_current =
addName(fonts_dir, win_fonts_truetype[i] + ".ttf");
-
RemoveFontResource(to_local8bit(from_utf8(external_path(font_current))).c_str());
+ if (pRemoveFontResourceEx) {
+ // Windows 2000 and later: Use RemoveFontResourceEx for
private font
+
pRemoveFontResourceEx(to_local8bit(from_utf8(external_path(font_current))).c_str(),
FR_PRIVATE, 0);
+ } else {
+ // Older Windows versions: Use RemoveFontResource
+
RemoveFontResource(to_local8bit(from_utf8(external_path(font_current))).c_str());
+ }
}
+
+ FreeLibrary(hDLL);
}
} // namespace os
Re: Need for better dialogs
Le 9 juil. 07 à 17:33, Richard Heck a écrit : I checked that if you modify isBufferDependent() for LaTeX logs (hence into ControlLog.h) so that it returns true when belonging to a LaTeX log dialog, then it is no more hidden when switching buffer (but this isn't sufficient because there are update issues to deal with...). Yes, this is all related to the update issue. The call to ControlLog::initialiseParams() is supposed to pass (a) the name of the logfile type and (b) the name of the logfile. We're supposed to return false if there's some error in the parsing of this information. The call you mention passes no data at all, so the parsing fails, and we return false. To do a proper update, you'd have to have that information lying around somewhere. I'm curious to know how one should specify that a buffer dependent dialog has to hide/keep displayed when switching to another buffer. At present, there is no way to do this. Perhaps a new hideOnSwitch () virtual method is needed. I agree. A more general solution, perhaps, would be to add a new onSwitch() virtual method, which would allow the dialog to do whatever it wished when the buffer was switched. Perhaps it would hide itself; perhaps it would clear itself; perhaps it would try to update itself. This could be called before the update(). Yes, this solution would be better. As for the graphics dialog, a question: If you click away from the graphics inset to which the dialog is attached, what happens? The dialog remains as is if you stay into the same buffer. It is emptied if you switch to another buffer. But in the latter case I think we have a bug: despite the dialog is emptied, if you modify some parameters and click the "Apply" button, then parameters are always linked (and so applied) to the graphics inset. IMO, this is really unadapted! Yes, that would be a bug. This should probably return true for hideOnSwitch(), or do something sensible in onSwitch(). Should I file a bug for this particular behavior? What should happen? In my vision, this shouldn't be possible for dialogs such as graphics (modal dialogs). You'd have to close the dialog before. This would avoid undesired effects (e.g. modify some graphic parameters whereas the preview is no more visible due to scrolling, or buffer switching...). The addition of a hideOnSwitch() method would deal with this problem, while allowing you to do this: change the graphics parameters for one inset; then (in the same document), click another graphics dialog and make changes there, without having to close and re-open the dialog. Ok. For my usage, it's not annoying to close and reopen because most of time, I make settings just after inserting graphics. But there are issues about update that led to the paragraph settings dialog becoming modal. Abdel is working on this. The intention is for it to become non-modal again, once he's got it sorted out. Well I can't see why. If you want to apply the same settings to several paragraphs, you could select them all, and then apply settings, no? The idea was that maybe you are making different changes in different paragraphs, and it slows you down to have to close and open the dialog every time. Ok, now I understand why some people like it. But personally, I'd prefer modal dialogs. What about a preference option? It would concern only this kind of dialogs (I don't know, maybe we could refer to them as "Inset dialogs"). Mael.
Re: [patch] bug 1820 --- footnotes in different language
Dov Feldstern wrote:
Dov Feldstern wrote:
So, to sum up: the patch attached at
http://permalink.gmane.org/gmane.editors.lyx.devel/89376 together with
the patch attached here solve bug 1820 completely.
Index: src/insets/InsetFootlike.h
===
--- src/insets/InsetFootlike.h (revision 19014)
+++ src/insets/InsetFootlike.h (working copy)
@@ -37,7 +37,7 @@
/** returns true if, when outputing LaTeX, font changes should
be closed before generating this inset. This is needed for
insets that may contain several paragraphs */
- bool noFontChange() const { return true; }
+ bool noFontChange() const { return false; }
};
Georg wrote about this (in bugzilla) as follows:
"This second part is probably a file format change (is it really needed
for all footlike insets?)."
My response:
Regarding whether or not this is necessary for all footlike insets: I
don't know. I've run into it for footnotes, but I think it should be
fixed for all footlike insets; I'm not sure if it's ever right, for that
matter. Do you know why this whole font-change mechanism was originally
added?
Would changing the patch to deal only with footnote and not footlike
change the question of this being a format change?
Regarding the format change: why is this a format change? I mean, yes,
in some cases the output of a given LyX file will change --- but I
*want* that to happen, because currently the output is wrong. If the
output before the patch is correct, then I think that with the patch
perhaps the generated latex may be slightly different, but the output
will remain the same. But the best thing would be if we could find
examples where this does actually cause a change in the output, then
we'll be able to deal with it. I've tried this on various files I have,
some of them with pretty complex font/language transitions, and they all
seem to be okay with these patches (i.e., the output is no different).
Dov
Re: FuncRequest/dispatch goals
Jean-Marc Lasgouttes ha scritto: Except if this serialization can be merged with the writing of the xml parameters once we switch to that. In this case, the thing would make more sense (and allow to define bindings to tune individual parameters). Is it possible to have brief description of what is this "writing of XML params" (or just a pointer to archived mail or wiki page, if any) ? Thanks, bye, T.
Re: Status of LyX 1.5.0?
Here an updated patch which only calls the Ex functions
if they are available.
And what was the status? It doesn't work on Vista?
And also needs some chmod changes on cygwin?
Peter
Index: src/support/os_cygwin.cpp
===
--- src/support/os_cygwin.cpp (revision 19031)
+++ src/support/os_cygwin.cpp (working copy)
@@ -19,7 +19,12 @@
#include "debug.h"
+// compile with Windows > Win98 API, but load those functions dynamically
+// only needed for AddFontResourceEx
+#define _WIN32_WINNT 0x0500
+#define WIN32_LEAN_AND_MEAN
#include
+
#include
#include
#include
@@ -27,6 +32,8 @@
#include
+#include
+
using std::endl;
using std::string;
@@ -324,6 +331,40 @@
}
+// same as in os_win32.cpp
+static
+void fontResources(const std::string& name, LPCTSTR font_file_name)
+{
+ // first try to get the Ex version
+ typedef int (WINAPI* FontFunc)(LPCTSTR);
+ typedef int (WINAPI* FontExFunc)(LPCTSTR, DWORD, PVOID);
+ static FontFunc func = 0;
+ static FontExFunc func_ex = 0;
+ static std::string resolved_name;
+ if (resolved_name != name) {
+ QLibrary win_lib("gdi32");
+ win_lib.load();
+ std::string name_exa = name + "ExA";
+ func_ex = (FontExFunc) win_lib.resolve(name_exa.c_str());
+ if (!func_ex) {
+ std::string name_a = name + "A";
+ func = (FontFunc) win_lib.resolve(name_a.c_str());
+ }
+ resolved_name = name;
+ }
+ if (func_ex) {
+ func_ex(font_file_name, FR_PRIVATE, 0);
+ LYXERR(Debug::FONT) << "fontResources function: " <<
name.c_str() << "Ex" << endl;
+ } else if (func) {
+ func(font_file_name);
+ LYXERR(Debug::FONT) << "fontResources function: " <<
name.c_str() << endl;
+ } else {
+ // could never happen
+ LYXERR(Debug::FONT) << "fontResources - fatal error" << endl;
+ }
+}
+
+
void addFontResources()
{
#ifdef X_DISPLAY_MISSING
@@ -334,7 +375,7 @@
string const font_current = to_local8bit(from_utf8(convert_path(
addName(fonts_dir, win_fonts_truetype[i] + ".ttf"),
PathStyle(windows;
- AddFontResource(font_current.c_str());
+ fontResources("AddFontResource", font_current.c_str());
}
#endif
}
@@ -350,7 +391,7 @@
string const font_current = to_local8bit(from_utf8(convert_path(
addName(fonts_dir, win_fonts_truetype[i] + ".ttf"),
PathStyle(windows;
- RemoveFontResource(font_current.c_str());
+ fontResources("RemoveFontResource", font_current.c_str());
}
#endif
}
Index: src/support/os_win32.h
===
--- src/support/os_win32.h (revision 19031)
+++ src/support/os_win32.h (working copy)
@@ -42,6 +42,10 @@
# define _WIN32_IE 0x0500
#endif
+// compile with Windows > Win98 API, but load those functions dynamically
+// only needed for AddFontResourceEx
+#define _WIN32_WINNT 0x0500
+#define WIN32_LEAN_AND_MEAN
#include
Index: src/support/os_win32.cpp
===
--- src/support/os_win32.cpp(revision 19031)
+++ src/support/os_win32.cpp(working copy)
@@ -30,6 +30,8 @@
#include
#include
+#include
+
/* The GetLongPathName macro may be defined on the compiling machine,
* but we must use a bit of trickery if the resulting executable is
* to run on a Win95 machine.
@@ -403,6 +405,39 @@
}
+static
+void fontResources(const std::string& name, LPCTSTR font_file_name)
+{
+ // first try to get the Ex version
+ typedef int (WINAPI* FontFunc)(LPCTSTR);
+ typedef int (WINAPI* FontExFunc)(LPCTSTR, DWORD, PVOID);
+ static FontFunc func = 0;
+ static FontExFunc func_ex = 0;
+ static std::string resolved_name;
+ if (resolved_name != name) {
+ QLibrary win_lib("gdi32");
+ win_lib.load();
+ std::string name_exa = name + "ExA";
+ func_ex = (FontExFunc) win_lib.resolve(name_exa.c_str());
+ if (!func_ex) {
+ std::string name_a = name + "A";
+ func = (FontFunc) win_lib.resolve(name_a.c_str());
+ }
+ resolved_name = name;
+ }
+ if (func_ex) {
+ func_ex(font_file_name, FR_PRIVATE, 0);
+ LYXERR(Debug::FONT) << "fontResources function: " <<
name.c_str() << "Ex" << endl;
+ } else if (func) {
+ func(font_file_name);
+ LYXERR(Debug::FONT) << "fontResources function: " <<
name.c_str() << endl;
+ } else {
+ // could never happen
+
Re: \propto displayed as \mu
On Tuesday 10 July 2007 19:48:44 Michael Gerz wrote: > > On Win XP, LyX 1.5.0svn, \propto looks identical in LyX and in DVI > output (similar to a greek alpha symbol) And so it does on Linux (Fedora 7). I think the main point that Darren points are the missing fonts in his installation. > Michael -- José Abílio
Re: \propto displayed as \mu
Darren Freeman schrieb: Hi all, I just inserted a \propto to find that it is displayed in LyX as a Greek mu, but correctly in the LaTeX output. On Win XP, LyX 1.5.0svn, \propto looks identical in LyX and in DVI output (similar to a greek alpha symbol) Michael
Re: Deadline of translations?
There is a file, called po/LINGUAS, that is used by Makefile. If you remove some language entries from it, the build process should still work. It sounds like we need a LINGUAS_dist file that will be used by make dist. :-) Bo
Re: Deadline of translations?
José Matos schrieb: On Tuesday 10 July 2007 16:13:50 Bo Peng wrote: We can exclude them from source tar.gz and hope our build systems will not choke. The only way to check the latter is to build lyx/rc2 from its tarball with some po files removed. Michael and Jean-Marc are the wizards for this area. :-) I will let this task in their capable hands. ;-) There is a file, called po/LINGUAS, that is used by Makefile. If you remove some language entries from it, the build process should still work. Michael
Re: FuncRequest/dispatch goals
On Tue, Jul 10, 2007 at 06:39:30PM +0200, Abdelrazak Younes wrote: > Jean-Marc Lasgouttes wrote: > >>"Tommaso" == Tommaso Cucinotta <[EMAIL PROTECTED]> writes: > > > >Tommaso> While this could be useful to allow activation of the > >Tommaso> functionality from the action buffer or a script, why don't > >Tommaso> just call the method, instead, from the GUI classes ? > > > >This was part of the Model/View/Controller separation of the code. The > >idea was that the controllers should only use lfuns instead of direct > >code. I am not very sure myself that this is useful. > > I personally think the use of LFUN to request a change is fine and > useful; useful because it forces us to think about how to design the > LFUN in a GUI independent way (when it applies). It could be a plain library interface nevertheless. The string based interface is useful for the LyX server, but that's not in active widesprecd use. > What I personally dislike (I should probably say "hate" ;-)) and what I > intent to change in 1.6 is the serialization used in order to retrieve > information from the core (the initParam() and such). That's plain stupid indeed. Andre'
Re: [Patch] allow unicode in layout style name
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> FYI Jean-Pierre provided me with a layout file converted Abdelrazak> to utf8 and a 1.4 LyX file using this layout. With my Abdelrazak> patch, I had no problem opening the LyX file and the Abdelrazak> conversion to UTF-8 of the style names was done Abdelrazak> automatically. Fine. JMarc
Re: [Patch] allow unicode in layout style name
José Matos wrote: On Tuesday 10 July 2007 13:15:58 Jean-Marc Lasgouttes wrote: But the rest of the file is converted separately by lyx2lyx. I thought that this translation was more subtle than just running iconv. JMarc OK, now I see what you mean. :-) My problem was with the .layout file and you refered the .lyx file. For .layout files the convertion should be as described. For .lyx files I would expect that the only problem would appear if the paragraph style name uses a different encoding from the lyx file. Are there any such cases? I am not sure if this would have worked before... That is as long as the .lyx and the .layout use the same enconding everything should just work. Or am I missing any case? FYI Jean-Pierre provided me with a layout file converted to utf8 and a 1.4 LyX file using this layout. With my patch, I had no problem opening the LyX file and the conversion to UTF-8 of the style names was done automatically. Abdel.
Re: FuncRequest/dispatch goals
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> We don't need XML to sanitize a the format of the passed Abdelrazak> string, we could do that now using Abdelrazak> requests. I mean that we will do XML in any case, and this could be merged with the serialization stuff. Abdelrazak> But I object that this is needed at all, we have a fine Abdelrazak> in-memory Buffer structure and we should use that. This Abdelrazak> serialization is the number one reason why the LyX dialogs Abdelrazak> are so hard to modify for beginners. I agree with that. JMarc
Re: FuncRequest/dispatch goals
Jean-Marc Lasgouttes wrote: "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> What I personally dislike (I should probably say "hate" Abdelrazak> ;-)) and what I intent to change in 1.6 is the Abdelrazak> serialization used in order to retrieve information from Abdelrazak> the core (the initParam() and such). For retrieving Abdelrazak> information we should use direct calls like what is done Abdelrazak> in the Outline dialog, the Tabular dialog etc. Except if this serialization can be merged with the writing of the xml parameters once we switch to that. In this case, the thing would make more sense (and allow to define bindings to tune individual parameters). We don't need XML to sanitize a the format of the passed string, we could do that now using requests. But I object that this is needed at all, we have a fine in-memory Buffer structure and we should use that. This serialization is the number one reason why the LyX dialogs are so hard to modify for beginners. I've programmed a lot in property based languages (MATLAB GUIDE) and I much prefer the Qt C++ way. Abdel.
Re: FuncRequest/dispatch goals
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> What I personally dislike (I should probably say "hate" Abdelrazak> ;-)) and what I intent to change in 1.6 is the Abdelrazak> serialization used in order to retrieve information from Abdelrazak> the core (the initParam() and such). For retrieving Abdelrazak> information we should use direct calls like what is done Abdelrazak> in the Outline dialog, the Tabular dialog etc. Except if this serialization can be merged with the writing of the xml parameters once we switch to that. In this case, the thing would make more sense (and allow to define bindings to tune individual parameters). JMarc
Re: FuncRequest/dispatch goals
Jean-Marc Lasgouttes wrote: "Tommaso" == Tommaso Cucinotta <[EMAIL PROTECTED]> writes: Tommaso> While this could be useful to allow activation of the Tommaso> functionality from the action buffer or a script, why don't Tommaso> just call the method, instead, from the GUI classes ? This was part of the Model/View/Controller separation of the code. The idea was that the controllers should only use lfuns instead of direct code. I am not very sure myself that this is useful. I personally think the use of LFUN to request a change is fine and useful; useful because it forces us to think about how to design the LFUN in a GUI independent way (when it applies). What I personally dislike (I should probably say "hate" ;-)) and what I intent to change in 1.6 is the serialization used in order to retrieve information from the core (the initParam() and such). For retrieving information we should use direct calls like what is done in the Outline dialog, the Tabular dialog etc. Abdel.
Re: FuncRequest/dispatch goals
> "Tommaso" == Tommaso Cucinotta <[EMAIL PROTECTED]> writes: Tommaso> While this could be useful to allow activation of the Tommaso> functionality from the action buffer or a script, why don't Tommaso> just call the method, instead, from the GUI classes ? This was part of the Model/View/Controller separation of the code. The idea was that the controllers should only use lfuns instead of direct code. I am not very sure myself that this is useful. JMarc
Re: [PATCH] Fix crash exporting a multi-part document at the command-line
> "Richard" == Richard Heck <[EMAIL PROTECTED]> writes: Richard> And there's a similar question about the citation-insert code Richard> that precedes. It'd be quite easy at this point to do the Richard> enhancement mentioned there, but there's a question about the Richard> format of the command. We should try to come up with some kind of syntax for these lfuns. I am confident this will eventually happen :) JMarc
Re: FuncRequest/dispatch goals
On 7/10/07, Tommaso Cucinotta <[EMAIL PROTECTED]> wrote: Hi, as a newbie of the LyX code, I'm just curious about the purpose of the FuncRequest/dispatch mechanism. Specifically, it is not clear to me why from the GUI some functions produce a formatted text string that is dispatched through a FuncRequest object, for being parsed later somewhere else in the code, and finally result into a method call (e.g. LFUN_WORD_FIND, in files ControlSearch.cpp, LyxAction.cpp, LyXFunc.cpp, lyxfind.cpp). While this could be useful to allow activation of the functionality from the action buffer or a script, why don't just call the method, instead, from the GUI classes ? insets, text, gui may handle the same LFUN in different ways under different situations. If you trace a LFUN, you can sometimes see 'get a message, if a condition is met, process and mark this lfun as dispatched, otherwise, pass this lfun untouched to someone else'. Cheers, Bo
Re: [PATCH] Fix crash exporting a multi-part document at the command-line
Jean-Marc Lasgouttes wrote: Hey, that's not fair! I was busy preparing a garden party for 80 people! To be fair, some of the messages in the thread are familiar to me... Richard> Indeed, how to define the optional argument was one of the Richard> major issues. (The other option was a new LFUN.) And while Richard> I'm prepared to believe that this is "not how we define Richard> arguments", "|" is used as a delimiter for an optional Richard> argument in the code just preceding this: Richard, it looks like my tone felt a bit rude to you. Sorry about that. No, I didn't take offense. Actually I would prefer a syntax like buffer-child-insert "file-name-in-optional quotes" or buffer-child-insert "file-name-in-optional quotes" true Anyway, as Abdel rightfully pointed out this is work for later. And there's a similar question about the citation-insert code that precedes. It'd be quite easy at this point to do the enhancement mentioned there, but there's a question about the format of the command. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Deadline of translations?
Here is what the current table looks like: http://www-rocq.inria.fr/~lasgoutt/lyx/www-user/devel/i18n-15x.php Nice table. (BTW, Bo, did I get the language names right for chinese?) Yes. I propose to keep: - all the green and orange entries This would mean to remove the following: da fi ru sk sl nl pt wa sv plus zh_CN.po Bo
Re: [PATCH] Fix crash exporting a multi-part document at the command-line
> "Richard" == Richard Heck <[EMAIL PROTECTED]> writes: Richard> I'm pretty sure he did: Richard> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg120884.html. >[PATCH] Child TOC Crash, Again >Richard Heck >Sat, 16 Jun 2007 10:14:39 -0700 Hey, that's not fair! I was busy preparing a garden party for 80 people! To be fair, some of the messages in the thread are familiar to me... Richard> Indeed, how to define the optional argument was one of the Richard> major issues. (The other option was a new LFUN.) And while Richard> I'm prepared to believe that this is "not how we define Richard> arguments", "|" is used as a delimiter for an optional Richard> argument in the code just preceding this: Richard, it looks like my tone felt a bit rude to you. Sorry about that. Actually I would prefer a syntax like buffer-child-insert "file-name-in-optional quotes" or buffer-child-insert "file-name-in-optional quotes" true Anyway, as Abdel rightfully pointed out this is work for later. JMarc
Re: Deadline of translations?
> "José" == José Matos <[EMAIL PROTECTED]> writes: José> Michael and Jean-Marc are the wizards for this area. :-) I José> will let this task in their capable hands. ;-) Here is what the current table looks like: http://www-rocq.inria.fr/~lasgoutt/lyx/www-user/devel/i18n-15x.php (BTW, Bo, did I get the language names right for chinese?) I propose to keep: - all the green and orange entries - more generally, all the entries that have been updated more or less recently (example: Korean, for which we may expect more work from cghan) This would mean to remove the following: da fi ru sk sl nl pt wa sv JMarc
Re: [PATCH] Fix crash exporting a multi-part document at the command-line
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Note that Richard asked for comment at the time.
Sure, but he did not point to this particular "feature" :)
I'm pretty sure he did:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg120884.html.
Indeed, how to define the optional argument was one of the major issues.
(The other option was a new LFUN.) And while I'm prepared to believe
that this is "not how we define arguments", "|" is used as a delimiter
for an optional argument in the code just preceding this:
case LFUN_CITATION_INSERT: {
BOOST_ASSERT(lyx_view_);
if (!argument.empty()) {
// we can have one optional argument, delimited by '|'
// citation-insert |
// this should be enhanced to also support text_after
// and citation style
string arg = argument;
string opt1;
if (contains(argument, "|")) {
arg = token(argument, '|', 0);
opt1 = token(argument, '|', 1);
}
InsetCommandParams icp("cite");
icp["key"] = from_utf8(arg);
if (!opt1.empty())
icp["before"] = from_utf8(opt1);
string icstr = InsetCommandMailer::params2string("citation",
icp);
FuncRequest fr(LFUN_INSET_INSERT, icstr);
dispatch(fr);
} else
dispatch(FuncRequest(LFUN_DIALOG_SHOW_NEW_INSET, "citation"));
break;
}
That's where I got the idea.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Windows 98 / Me support?
Joost Verburg wrote: Andre Poenitz wrote: No... rather an obvious replacement that's e.g. known to work with Chinese Windows or such... FILE_SHARE_DELETE is a sharing mode supported by Windows 2000 and later. This boost library uses it in the part of the code that is supposed to work on older Windows versions. That's why it needs to be removed. You won't notice the difference anyway because the file handles are closed immediately. I guess Andre' was talking about replacing boost::filesystem altogether with Qt equivalent functionality; nothing related to your patch. As for your patch, it is OK for me. Abdel.
Re: Deadline of translations?
> The only way to check the latter is to build lyx/rc2 from > its tarball with some po files removed. I just checked that scons can install without problem because it globs po/*.po . windows installers may still fail to compile though. Bo
Re: Deadline of translations?
On Tuesday 10 July 2007 16:13:50 Bo Peng wrote: > We can exclude them from source tar.gz and hope our build systems will > not choke. The only way to check the latter is to build lyx/rc2 from > its tarball with some po files removed. Michael and Jean-Marc are the wizards for this area. :-) I will let this task in their capable hands. ;-) > Bo -- José Abílio
Re: Deadline of translations?
How do we disable the interface? By not including it in the distribution? Actually I think we need to do it for other languages as well (for the same reason). We can exclude them from source tar.gz and hope our build systems will not choke. The only way to check the latter is to build lyx/rc2 from its tarball with some po files removed. Bo
Re: [PATCH] Fix crash exporting a multi-part document at the command-line
Jean-Marc Lasgouttes wrote: Abdelrazak> Note that Richard asked for comment at the time. Sure, but he did not point to this particular "feature" :) IIRC he asked what was the correct syntax for argument but nobody (including me) answered him. Abdelrazak> I agree and I already started to take care of this in mvc Abdelrazak> branch which will be merged either in 1.5.1 or in 1.6svn. I am not sure Juergen will be willing to merge something big in 1.5.1 (or later). I plan the open the debate as soon as 1.5.0 is out ;-) Abdel.
Re: [Patch] allow unicode in layout style name
José Matos wrote: > I will look into them. Thanks! Seems you are the only one available now with the necessary skills. Jürgen
FuncRequest/dispatch goals
Hi, as a newbie of the LyX code, I'm just curious about the purpose of the FuncRequest/dispatch mechanism. Specifically, it is not clear to me why from the GUI some functions produce a formatted text string that is dispatched through a FuncRequest object, for being parsed later somewhere else in the code, and finally result into a method call (e.g. LFUN_WORD_FIND, in files ControlSearch.cpp, LyxAction.cpp, LyXFunc.cpp, lyxfind.cpp). While this could be useful to allow activation of the functionality from the action buffer or a script, why don't just call the method, instead, from the GUI classes ? Thanks, bye, T.
Re: [PATCH] Fix crash exporting a multi-part document at the command-line
José Matos wrote: On Tuesday 10 July 2007 15:56:04 Jean-Marc Lasgouttes wrote: Abdelrazak> But for the time being, let's please get 1.5.0 out. Sure. In this respect, your patch is OK. +1 Done, thanks.
Re: [PATCH] Fix crash exporting a multi-part document at the command-line
On Tuesday 10 July 2007 15:56:04 Jean-Marc Lasgouttes wrote: > Abdelrazak> But for the time being, let's please get 1.5.0 out. > > Sure. In this respect, your patch is OK. +1 -- José Abílio
Re: [Patch] allow unicode in layout style name
On Tuesday 10 July 2007 15:05:52 Jürgen Spitzmüller wrote: > Shouldn't the remaining major issues with lyx2lyx be addressed first (bug > 3313, 3404, 3958, 3976, 3985)? > > Jürgen I will look into them. -- José Abílio
Re: [Patch] allow unicode in layout style name (was Re: Upgrade from 1.4 to 1.5)
On Tuesday 10 July 2007 15:16:56 [EMAIL PROTECTED] wrote: > > What's the risk of embarrassing[*] bugs? (As this is just before the > release of 1.5.0). There is no RC3 planned, right? Do you want a formula with deltas and epsilons? ;-) No there is not any RC3 planned. Do you think we need one? Regarding this subject I think that this course of action is sound so I don't expect any major surprises. (Famous last words). > /Christian > > [*] I think the bugs will be easy to fix, it may just be somewhat > embarrasing to do a 1.5.1 release very quickly after 1.5.0. That is always a possibility. :-) -- José Abílio
Re: [PATCH] Fix crash exporting a multi-part document at the command-line
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: >> Why is the lyx_view_ needed? Abdelrazak> LFUN_BUFFER_CHILD_OPEN uses LyXView::loadLyXFile() because Abdelrazak> of outline, tabbar, etc. OK. Abdelrazak> Note that Richard asked for comment at the time. Sure, but he did not point to this particular "feature" :) Abdelrazak> I agree and I already started to take care of this in mvc Abdelrazak> branch which will be merged either in 1.5.1 or in 1.6svn. I am not sure Juergen will be willing to merge something big in 1.5.1 (or later). But cleanup is much welcome. Abdelrazak> But for the time being, let's please get 1.5.0 out. Sure. In this respect, your patch is OK.
Re: Deadline of translations?
On Tuesday 10 July 2007 15:33:31 Bo Peng wrote: > I suggest that we disable it for 1.5.0 because it is better to give > Chinese users a pure-English interface than a half-translated, or > empty one. > > Cheers, > Bo How do we disable the interface? By not including it in the distribution? Actually I think we need to do it for other languages as well (for the same reason). -- José Abílio
Re: [PATCH] Fix crash exporting a multi-part document at the command-line
Jean-Marc Lasgouttes wrote: "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> This patch revert part of the code changed in revision Abdelrazak> 18825. This is needed because there is no lyx_view_ when Abdelrazak> exporting at the command-line. Why is the lyx_view_ needed? LFUN_BUFFER_CHILD_OPEN uses LyXView::loadLyXFile() because of outline, tabbar, etc. Also, I know it does not come from your patch, I really do not like this weird "|true" syntax below: + lyx::dispatch(FuncRequest(LFUN_BUFFER_CHILD_OPEN, + included_file.absFilename() + "|true")); Note that Richard asked for comment at the time. But I agree with you it's not very nice. This is definitely not how we define arguments. We should really refrain from making our ``API'' even worse than it currently is. I agree and I already started to take care of this in mvc branch which will be merged either in 1.5.1 or in 1.6svn. But for the time being, let's please get 1.5.0 out. Abdel.
Re: [PATCH] Fix crash exporting a multi-part document at the command-line
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> This patch revert part of the code changed in revision Abdelrazak> 18825. This is needed because there is no lyx_view_ when Abdelrazak> exporting at the command-line. Why is the lyx_view_ needed? Also, I know it does not come from your patch, I really do not like this weird "|true" syntax below: + lyx::dispatch(FuncRequest(LFUN_BUFFER_CHILD_OPEN, + included_file.absFilename() + "|true")); This is definitely not how we define arguments. We should really refrain from making our ``API'' even worse than it currently is. JMarc
Re: Deadline of translations?
I would like to release before Thursday (that is with Wednesday as the deadline). How much time do you need? The simplified Chinese translation will not be ready by Thursday (almost half-done). Even if the translation is complete, Lyx can not display Chinese under linux (bug 3971, the reason why the translation can not be done sooner). I suggest that we disable it for 1.5.0 because it is better to give Chinese users a pure-English interface than a half-translated, or empty one. Cheers, Bo
[PATCH] Fix crash exporting a multi-part document at the command-line
This patch revert part of the code changed in revision 18825. This is
needed because there is no lyx_view_ when exporting at the command-line.
OK?
Abdel.
Index: InsetInclude.cpp
===
--- InsetInclude.cpp(revision 19003)
+++ InsetInclude.cpp(working copy)
@@ -404,9 +404,19 @@
// the readonly flag can/will be wrong, not anymore I think.
if (!fs::exists(included_file.toFilesystemEncoding()))
return false;
- lyx::dispatch(FuncRequest(LFUN_BUFFER_CHILD_OPEN,
- included_file.absFilename() + "|true"));
- buf = theBufferList().getBuffer(included_file.absFilename());
+ if (use_gui) {
+ lyx::dispatch(FuncRequest(LFUN_BUFFER_CHILD_OPEN,
+ included_file.absFilename() + "|true"));
+ buf =
theBufferList().getBuffer(included_file.absFilename());
+ }
+ else {
+ buf =
theBufferList().newBuffer(included_file.absFilename());
+ if (!loadLyXFile(buf, included_file)) {
+ //close the buffer we just opened
+ theBufferList().close(buf, false);
+ return false;
+ }
+ }
return buf;
}
buf->setParentName(parentFilename(buffer));
Re: [Patch] allow unicode in layout style name (was Re: Upgrade from 1.4 to 1.5)
On Tue, 10 Jul 2007, José Matos wrote: The plan for this change is then: * to convert our layout files to utf8; * apply your patch; * add a comment to the release notes. I propose to do this tomorrow to give some time for feedback. If by tomorrow there are no voices against we will implement this plan. OK? What's the risk of embarrassing[*] bugs? (As this is just before the release of 1.5.0). There is no RC3 planned, right? /Christian [*] I think the bugs will be easy to fix, it may just be somewhat embarrasing to do a 1.5.1 release very quickly after 1.5.0. -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: r19028 - in /lyx-devel/branches/BRANCH_1_4_X: src/fronten...
Joost Verburg wrote: Abdelrazak Younes wrote: [EMAIL PROTECTED] wrote: Author: lasgouttes Date: Tue Jul 10 15:37:10 2007 New Revision: 19028 URL: http://www.lyx.org/trac/changeset/19028 Log: 2007-07-10 Enrico Forestieri <[EMAIL PROTECTED]> * qfont_loader.C (initFontPath, ): use AddFontResourceEx to mark our fonts as private (bug 3962) (~FontLoader): ditto with RemoveFontResourceEx. What about trunk? Abdel. LyX 1.4 requires Windows 2000 or later (because of Q../Free), so using this API won't cause any troubles. LyX 1.5 now works on Windows 98/Me (with the patch I posted yesterday). This means that the API function should be loaded dynamically on run-time when running on Windows 2000 or later. This should be possible using LoadLibrary/GetProcAddress. So we have two solutions IMHO: 1) you have a patch ready using LoadLibrary/GetProcAddress before tomorrow: 1.5.0 will support Win9X! 2) you don't: we apply the above patch for now and re-target Win9X support to 1.5.1. Abdel.
Re: LyX-1.4.4 fails to build against boost-1.34
Mikhail T. wrote: Jean-Marc Lasgouttes wrote: This is exactly why we bundle boost with LyX :) No, such bundling is wrong... Ensuring compatibility with two (or even three) most recent versions of Boost would, probably, be still easier for you, and would do The Right Thing (TM), instead of inflating your own tarball and causing porters on various platforms extra problems. We all agree that it'd be better to not bundle boost but this is a compromise between easing developers' work and easing porters' work. Up to version 1.34.0, all version of boost needed to be patched. Maybe we should stop the bundling when 1.34.1 is out. You (LyX) are pretty good, actually. Bundling boost is a minor offense. The OpenOffice folks, for example, would've bundled the entire Qt4 with their distribution. Just in case... You mean the Qt4 source? that's bad indeed. Abdel.
Re: [Patch] allow unicode in layout style name
Jean-Marc Lasgouttes wrote: > So you can also update lyx2lyx in 1.4.5svn, right? I will be away > starting on next Friday, so I'd like to release on thursday (or > tomorrow?). Shouldn't the remaining major issues with lyx2lyx be addressed first (bug 3313, 3404, 3958, 3976, 3985)? Jürgen
Re: LyX-1.4.4 fails to build against boost-1.34
> "Mikhail" == Mikhail T <[EMAIL PROTECTED]> writes: Mikhail> No, such bundling is wrong... Ensuring compatibility with two Mikhail> (or even three) most recent versions of Boost would, Mikhail> probably, be still easier for you, and would do The Right Mikhail> Thing (TM), instead of inflating your own tarball and causing Mikhail> porters on various platforms extra problems. Things are a bit better now, but in the past we had to apply minor patches to our boost copy. But when/if boost really stabilizes, we'll unbundle it. JMarc
Re: r19028 - in /lyx-devel/branches/BRANCH_1_4_X: src/fronten...
Abdelrazak Younes wrote: [EMAIL PROTECTED] wrote: Author: lasgouttes Date: Tue Jul 10 15:37:10 2007 New Revision: 19028 URL: http://www.lyx.org/trac/changeset/19028 Log: 2007-07-10 Enrico Forestieri <[EMAIL PROTECTED]> * qfont_loader.C (initFontPath, ): use AddFontResourceEx to mark our fonts as private (bug 3962) (~FontLoader): ditto with RemoveFontResourceEx. What about trunk? Abdel. LyX 1.4 requires Windows 2000 or later (because of Q../Free), so using this API won't cause any troubles. LyX 1.5 now works on Windows 98/Me (with the patch I posted yesterday). This means that the API function should be loaded dynamically on run-time when running on Windows 2000 or later. This should be possible using LoadLibrary/GetProcAddress. Joost
Re: [Patch] allow unicode in layout style name
> "José" == José Matos <[EMAIL PROTECTED]> writes: José> On Tuesday 10 July 2007 13:25:04 Abdelrazak Younes wrote: >> What about the documentation? It is probably time to convert them, >> isn't it? José> As far as I remember there are no patches holding that change José> the file format. If so then yes it is time to start updating the José> documentation to the latest format. So you can also update lyx2lyx in 1.4.5svn, right? I will be away starting on next Friday, so I'd like to release on thursday (or tomorrow?). JMarc
Re: LyX-1.4.4 fails to build against boost-1.34
Jean-Marc Lasgouttes wrote: "Mikhail" == Mikhail Teterin <[EMAIL PROTECTED]> writes: Mikhail> Hello! Boost-1.34 is not only released now, it is also Mikhail> _required_ for the upcoming LyX-1.5.0. Unfortunately, the Mikhail> current release of LyX (1.4.4) fails to build against it. Mikhail> I'm attaching the patch I plan to add to FreeBSD's print/lyx Mikhail> port to make the source compatible with both Boost-1.33.1 and Mikhail> 1.34. I will apply this patch to 1.4.5svn if some other developer tells me it is OK. Mikhail> P.S. Boost people should really be ashamed of themselves for Mikhail> introducing API incompatibilities like this -- especially, in Mikhail> a _minor_ number release... This is exactly why we bundle boost with LyX :) No, such bundling is wrong... Ensuring compatibility with two (or even three) most recent versions of Boost would, probably, be still easier for you, and would do The Right Thing (TM), instead of inflating your own tarball and causing porters on various platforms extra problems. You (LyX) are pretty good, actually. Bundling boost is a minor offense. The OpenOffice folks, for example, would've bundled the entire Qt4 with their distribution. Just in case... -mi
Re: r19028 - in /lyx-devel/branches/BRANCH_1_4_X: src/fronten...
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> [EMAIL PROTECTED] wrote: >> Author: lasgouttes Date: Tue Jul 10 15:37:10 2007 New Revision: >> 19028 >> >> URL: http://www.lyx.org/trac/changeset/19028 Log: 2007-07-10 Enrico >> Forestieri <[EMAIL PROTECTED]> >> >> * qfont_loader.C (initFontPath, ): use AddFontResourceEx to mark >> our fonts as private (bug 3962) (~FontLoader): ditto with >> RemoveFontResourceEx. Abdelrazak> What about trunk? >From what I understand, we need a solution that works with win9x too. JMarc
Re: Fwd: Re: About LyX (Net|Open)BSD and wchar_t
On Tuesday 10 July 2007 13:44:59 Jean-Marc Lasgouttes wrote: > But it uses the one found by configure, right? Since we did not had any reports saying otherwise I suppose you are right. :-) > JMarc -- José Abílio
Re: r19028 - in /lyx-devel/branches/BRANCH_1_4_X: src/fronten...
[EMAIL PROTECTED] wrote: Author: lasgouttes Date: Tue Jul 10 15:37:10 2007 New Revision: 19028 URL: http://www.lyx.org/trac/changeset/19028 Log: 2007-07-10 Enrico Forestieri <[EMAIL PROTECTED]> * qfont_loader.C (initFontPath, ): use AddFontResourceEx to mark our fonts as private (bug 3962) (~FontLoader): ditto with RemoveFontResourceEx. What about trunk? Abdel.
Re: [Patch] allow unicode in layout style name (was Re: Upgrade from 1.4 to 1.5)
On Tuesday 10 July 2007 13:25:04 Abdelrazak Younes wrote: > What about the documentation? It is probably time to convert them, isn't > it? As far as I remember there are no patches holding that change the file format. If so then yes it is time to start updating the documentation to the latest format. > > Abel. -- José Abílio
Re: Towards LyX 1.4.5 [status update #1]
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: >> I'll apply it tomorrow (is there a bug number?) Enrico> Bug 3962. Thanks. The patch is applied now. JMarc
Re: LyX-1.4.4 fails to build against boost-1.34
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> IIUC, this patch is to make LyX compile with external Abdelrazak> boost 1.34.0 which known to be deficient. Are you sure Abdelrazak> that this patch will work with our bundled boost? OK, I agree that it would be better to avoid caring about that. Mikhail, you will have to keep this patch in your port (or use the bundled boost). JMarc
Re: [Patch] allow unicode in layout style name
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > > > "José" == José Matos <[EMAIL PROTECTED]> writes: > > José> On Tuesday 10 July 2007 11:47:36 Jean-Marc Lasgouttes wrote: > >> It would be even better to provide explicit commands or some kind > >> of script to update .lyx file. I suspect it is not trivial. > >> > >> JMarc > > José> Using iconv? > > José> Something like this for bash > > José> cd /path/to/layouts for l in * do cp $l tmp.txt iconv -f latin1 > José> -t utf8 tmp.txt -o $l done > > You do not want to translate the whole file, only the > \begin_layout NameWithAccent > lines. But lyx2lyx *does* convert, e.g. \begin_layout Liste_à_puces as \begin_layout Liste à puces (sorry, my Solaris does not display Unicode). lyx-1.5.0rc2 has an assertion if I open the file in the LyX window, but exports perfectly this as itemize if I run the export as batch with lyx-1.5.0rc2 -e latex unicode_test_1.5.lyx So nothing has to be done on the lyx docs side. About layout conversion: layout2layout.py updates the format, iconv turns them in utf8 (needed for non-ascii characters in the style bodies). There are two ways to solve the assertion problem: - forbid non ascii characters in styles names and use gettext to translate: needs manual renaming of style names with non-ascii characters (bugfree with lyx up to 1.4) to ascii names and update of gmo files); - allow non ascii characters: Abdel's patch should solve the assertion problem. Do you need an example ? -- Jean-Pierre
Re: [Updated PATCH] accept utf8 in layout files
Jean-Pierre Chrétien wrote: Abdelrazak Younes <[EMAIL PROTECTED]> writes: Jean-Pierre Chrétien wrote: The problems comes from the fact that with both layout and lyx files in Unicode, [...] I know and my patch solves this, did you try it? I do not have access to svn from here, and I guess it won't work with 1.5.0rc2 ? I guess not but you could try. I can send you a snapshot of trunk if you want. Abdel.
Re: LyX-1.4.4 fails to build against boost-1.34
Jean-Marc Lasgouttes wrote: "Mikhail" == Mikhail Teterin <[EMAIL PROTECTED]> writes: Mikhail> Hello! Boost-1.34 is not only released now, it is also Mikhail> _required_ for the upcoming LyX-1.5.0. Unfortunately, the Mikhail> current release of LyX (1.4.4) fails to build against it. Mikhail> I'm attaching the patch I plan to add to FreeBSD's print/lyx Mikhail> port to make the source compatible with both Boost-1.33.1 and Mikhail> 1.34. I will apply this patch to 1.4.5svn if some other developer tells me it is OK. Mikhail> P.S. Boost people should really be ashamed of themselves for Mikhail> introducing API incompatibilities like this -- especially, in Mikhail> a _minor_ number release... This is exactly why we bundle boost with LyX :) IIUC, this patch is to make LyX compile with external boost 1.34.0 which known to be deficient. Are you sure that this patch will work with our bundled boost? Abdel.
Re: [Updated PATCH] accept utf8 in layout files
Abdelrazak Younes <[EMAIL PROTECTED]> writes: > > Jean-Pierre Chrétien wrote: > > The problems comes from the fact that with both layout > >and lyx files in Unicode, [...] > > I know and my patch solves this, did you try it? I do not have access to svn from here, and I guess it won't work with 1.5.0rc2 ? -- Jean-Pierre
Re: LyX-1.4.4 fails to build against boost-1.34
> "Mikhail" == Mikhail Teterin <[EMAIL PROTECTED]> writes: Mikhail> Hello! Boost-1.34 is not only released now, it is also Mikhail> _required_ for the upcoming LyX-1.5.0. Unfortunately, the Mikhail> current release of LyX (1.4.4) fails to build against it. Mikhail> I'm attaching the patch I plan to add to FreeBSD's print/lyx Mikhail> port to make the source compatible with both Boost-1.33.1 and Mikhail> 1.34. I will apply this patch to 1.4.5svn if some other developer tells me it is OK. Mikhail> P.S. Boost people should really be ashamed of themselves for Mikhail> introducing API incompatibilities like this -- especially, in Mikhail> a _minor_ number release... This is exactly why we bundle boost with LyX :) JMarc
Re: [Updated PATCH] 3877:Highlighting text slows down LyX extremely
> "José" == José Matos <[EMAIL PROTECTED]> writes: José> On Monday 09 July 2007 18:12:48 Bo Peng wrote: >> Jose, if you can not decide, just toss a coin. IMO, both approaches >> are good enough. :-) José> OK then, let us go Jean-Marc's way, and proceed for other more José> pressing issues. I committed a slightly updated patch. JMarc
Re: [Patch] allow unicode in layout style name
> "José" == José Matos <[EMAIL PROTECTED]> writes: José> That is as long as the .lyx and the .layout use the same José> enconding everything should just work. Or am I missing any case? Just do it and you will see if people complain :) JMarc
Re: Fwd: Re: About LyX (Net|Open)BSD and wchar_t
> "José" == José Matos <[EMAIL PROTECTED]> writes: >> Or add a lyxrc entry for it and let configure.py fill the value in. >> Or just let port maintainers set the right value in lyxrc.dist. José> The problem is that by then is already too late because José> configure.py needs the location of the python version used. :-) But it uses the one found by configure, right? JMarc
Re: [Patch] allow unicode in layout style name (was Re: Upgrade from 1.4 to 1.5)
José Matos wrote: On Tuesday 10 July 2007 10:50:28 Abdelrazak Younes wrote: Right. Does anyone has any objection to this change? The purpose of this release is the support of unicode, we are using utf8 for the saved files so it makes all sense to follow the same route for layout files. In the special cases where layout files are in the ascii subset the no change is need because that is already valid utf-8. Abdel. The plan for this change is then: * to convert our layout files to utf8; What about the documentation? It is probably time to convert them, isn't it? * apply your patch; * add a comment to the release notes. I propose to do this tomorrow to give some time for feedback. If by tomorrow there are no voices against we will implement this plan. OK? Fine with me. Abel.
Re: Fwd: Re: About LyX (Net|Open)BSD and wchar_t
On Tuesday 10 July 2007 13:15:00 Jean-Marc Lasgouttes wrote: > José> The call for python is made over src/support/os.cpp so all > José> further configurations should be done there. We need to change > José> configure.ac and companions and the use config.h to configure > José> os.cpp to use the choose python. > > Or add a lyxrc entry for it and let configure.py fill the value in. Or > just let port maintainers set the right value in lyxrc.dist. The problem is that by then is already too late because configure.py needs the location of the python version used. :-) > JMarc -- José Abílio
Re: [Patch] allow unicode in layout style name
On Tuesday 10 July 2007 13:15:58 Jean-Marc Lasgouttes wrote: > But the rest of the file is converted separately by lyx2lyx. I thought > that this translation was more subtle than just running iconv. > > JMarc OK, now I see what you mean. :-) My problem was with the .layout file and you refered the .lyx file. For .layout files the convertion should be as described. For .lyx files I would expect that the only problem would appear if the paragraph style name uses a different encoding from the lyx file. Are there any such cases? I am not sure if this would have worked before... That is as long as the .lyx and the .layout use the same enconding everything should just work. Or am I missing any case? -- José Abílio
Re: [Patch] allow unicode in layout style name
Jean-Marc Lasgouttes wrote: "José" == José Matos <[EMAIL PROTECTED]> writes: José> On Tuesday 10 July 2007 12:53:56 Jean-Marc Lasgouttes wrote: You do not want to translate the whole file, only the \begin_layout NameWithAccent lines. JMarc José> Why not? It is easier to use has a file with coherent encoding José> that one that uses a mixed encoding. But the rest of the file is converted separately by lyx2lyx. I thought that this translation was more subtle than just running iconv. If we are to believe Jean-Pierre Chrétien, there's nothing to be done for LyX files: "So from the user point of view, nothing else to do with lyx files than loading in 1.5, manual format/unicode conversion of user layouts required." Abdel.
Re: [Patch] allow unicode in layout style name
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: >> Why not? It is easier to use has a file with coherent encoding that >> one that uses a mixed encoding. Abdelrazak> I agree with Jose. I cannot see a reason why mixed Abdelrazak> encoding would be preferred. I am not sure we are discussing the same thing. Assume one has a file in 1.4 file format with contents in latin1 and some layout names in latin1 too. What do you propose to do? I see two solutions. 1/ first convert the latin1 file to utf8 in one sweep and hope that lyx2lyx will not butcher it when translating to 1.5 file format 2/ first convert to 1.5 file format. Then only the layout names should be converted in a second step. I do not think that iconv would appreciate to see UTF8 characters in a file which is supposed to be latin1. JMarc
Re: [Patch] allow unicode in layout style name
José Matos wrote: On Tuesday 10 July 2007 12:53:56 Jean-Marc Lasgouttes wrote: You do not want to translate the whole file, only the \begin_layout NameWithAccent lines. JMarc Why not? It is easier to use has a file with coherent encoding that one that uses a mixed encoding. I agree with Jose. I cannot see a reason why mixed encoding would be preferred. Abdel.
Re: [Patch] allow unicode in layout style name
> "José" == José Matos <[EMAIL PROTECTED]> writes: José> On Tuesday 10 July 2007 12:53:56 Jean-Marc Lasgouttes wrote: >> You do not want to translate the whole file, only the \begin_layout >> NameWithAccent lines. >> >> JMarc José> Why not? It is easier to use has a file with coherent encoding José> that one that uses a mixed encoding. But the rest of the file is converted separately by lyx2lyx. I thought that this translation was more subtle than just running iconv. JMarc
Re: Fwd: Re: About LyX (Net|Open)BSD and wchar_t
> "José" == José Matos <[EMAIL PROTECTED]> writes: José> I am not sure if it is worth it. José> First LyX does not care about python file headers, we always José> call python directly. Those headers are only useful for José> developer who don't need to call python directly each time. OK. José> The call for python is made over src/support/os.cpp so all José> further configurations should be done there. We need to change José> configure.ac and companions and the use config.h to configure José> os.cpp to use the choose python. Or add a lyxrc entry for it and let configure.py fill the value in. Or just let port maintainers set the right value in lyxrc.dist. JMarc
Re: [Patch] allow unicode in layout style name
On Tuesday 10 July 2007 12:53:56 Jean-Marc Lasgouttes wrote: > You do not want to translate the whole file, only the > \begin_layout NameWithAccent > lines. > > JMarc Why not? It is easier to use has a file with coherent encoding that one that uses a mixed encoding. -- José Abílio
Re: Fwd: Re: About LyX (Net|Open)BSD and wchar_t
On Friday 06 July 2007 23:21:24 Jean-Marc Lasgouttes wrote: > I received this from the NetBSD and OpenBSD maintainers. José, is there > something we can do about python? I am not sure if it is worth it. First LyX does not care about python file headers, we always call python directly. Those headers are only useful for developer who don't need to call python directly each time. It is the reason of placing #!/bin/sh as the first line of a shell script, make it executable and then call: ./my-script.sh instead of sh my-script.sh The call for python is made over src/support/os.cpp so all further configurations should be done there. We need to change configure.ac and companions and the use config.h to configure os.cpp to use the choose python. > JMarc -- José Abílio
Re: [Patch] allow unicode in layout style name
> "José" == José Matos <[EMAIL PROTECTED]> writes: José> On Tuesday 10 July 2007 11:47:36 Jean-Marc Lasgouttes wrote: >> It would be even better to provide explicit commands or some kind >> of script to update .lyx file. I suspect it is not trivial. >> >> JMarc José> Using iconv? José> Something like this for bash José> cd /path/to/layouts for l in * do cp $l tmp.txt iconv -f latin1 José> -t utf8 tmp.txt -o $l done You do not want to translate the whole file, only the \begin_layout NameWithAccent lines. JMarc
Re: [Patch] allow unicode in layout style name
On Tuesday 10 July 2007 11:47:36 Jean-Marc Lasgouttes wrote: > It would be even better to provide explicit commands or some kind of > script to update .lyx file. I suspect it is not trivial. > > JMarc Using iconv? Something like this for bash cd /path/to/layouts for l in * do cp $l tmp.txt iconv -f latin1 -t utf8 tmp.txt -o $l done -- José Abílio
\propto displayed as \mu
Hi all, I just inserted a \propto to find that it is displayed in LyX as a Greek mu, but correctly in the LaTeX output. I have missing fonts because the relations aren't displayed at all (such as \gtrsim), but this is the first time I saw one show up as the wrong thing. So maybe it's a genuine bug. Have fun, Darren
Re: [Patch] allow unicode in layout style name
> "José" == José Matos <[EMAIL PROTECTED]> writes: José> The plan for this change is then: José> * to convert our layout files to utf8; * apply your patch; * add José> a comment to the release notes. It would be even better to provide explicit commands or some kind of script to update .lyx file. I suspect it is not trivial. JMarc
Re: [Patch] allow unicode in layout style name (was Re: Upgrade from 1.4 to 1.5)
On Tuesday 10 July 2007 10:50:28 Abdelrazak Younes wrote: > Right. Does anyone has any objection to this change? The purpose of this release is the support of unicode, we are using utf8 for the saved files so it makes all sense to follow the same route for layout files. In the special cases where layout files are in the ascii subset the no change is need because that is already valid utf-8. > Abdel. The plan for this change is then: * to convert our layout files to utf8; * apply your patch; * add a comment to the release notes. I propose to do this tomorrow to give some time for feedback. If by tomorrow there are no voices against we will implement this plan. OK? -- José Abílio
Re: [Patch] allow unicode in layout style name (was Re: Upgrade from 1.4 to 1.5)
José Matos wrote: On Tuesday 10 July 2007 10:23:02 Abdelrazak Younes wrote: So? This patch fixes a crash and a regression against 1.4. Unless you want to implement the layout2layout support and do the GUIName addition before 1.5.0, this patch should go in now. It's just a string -> docstring conversion and it fixes a number of "FIXME UNICODE". It also allows unicode style names for non-english speaking people which I think is very important. This should also be clearly stated in the RELEASE NOTES, all layout files should be converted to utf8. That is the idea, right? Right. Abdel.
Re: [Patch] allow unicode in layout style name (was Re: Upgrade from 1.4 to 1.5)
On Tuesday 10 July 2007 10:23:02 Abdelrazak Younes wrote: > So? > > This patch fixes a crash and a regression against 1.4. Unless you want > to implement the layout2layout support and do the GUIName addition > before 1.5.0, this patch should go in now. > > It's just a string -> docstring conversion and it fixes a number of > "FIXME UNICODE". It also allows unicode style names for non-english > speaking people which I think is very important. This should also be clearly stated in the RELEASE NOTES, all layout files should be converted to utf8. That is the idea, right? > Abdel. -- José Abílio
Re: [Patch] allow unicode in layout style name (was Re: Upgrade from 1.4 to 1.5)
Abdelrazak Younes wrote: Jean-Pierre Chrétien wrote: Abdelrazak Younes <[EMAIL PROTECTED]> writes: 1) provide a python script that converts the layout as good as possible: Théorème -> Theoreme Liste_à_puce -> Liste_a_puce The problem is that it could be done easily for French but maybe not for other languages. Second problem is that I am not sure we have a lyx2lyx equivalent for layoouts, do we? 2) Accept the layout field as is and do not try to translate them. Given the burden of gettext management, this would clearly be better, I've implemented that already, see attached patch. I agree this is better to the end-user who doesn't care if his styles are not translated. Especially if these styles are not meant to be distributed outside his classroom for example. So? This patch fixes a crash and a regression against 1.4. Unless you want to implement the layout2layout support and do the GUIName addition before 1.5.0, this patch should go in now. It's just a string -> docstring conversion and it fixes a number of "FIXME UNICODE". It also allows unicode style names for non-english speaking people which I think is very important. Abdel.
Re: [patch] bug 3819: LyX fails to export with an XFig insert w/ Image Cache enabled
Jean-Marc Lasgouttes wrote: > I guess we have to apply it, since it is a regression. You should add > a pointer to the bug, along with the fixme. Done. Jürgen
Re: [Updated PATCH] 3877:Highlighting text slows down LyX extremely
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: >> OK then, let us go Jean-Marc's way, and proceed for other more >> pressing issues. Abdelrazak> I could have bet you would say this. Yes, I secretly promised him an all-you-can-eat smorgasbord of beer and cucumber for the next time we meet :) JMarc
Re: [patch] bug 3819: LyX fails to export with an XFig insert w/ Image Cache enabled
On Tuesday 10 July 2007 09:33:17 Jürgen Spitzmüller wrote: > So what shall we do with this patch? OK. > Jürgen -- José Abílio
Re: [patch] bug 3819: LyX fails to export with an XFig insert w/ Image Cache enabled
> "Jürgen" == Jürgen Spitzmüller <[EMAIL PROTECTED]> writes: Jürgen> Jürgen Spitzmüller wrote: >> http://bugzilla.lyx.org/show_bug.cgi?id=3819 >> >> This is a patch from Georg. I tested it and it seems to work for me >> (there is an issue with an assert directly after applying the patch >> if the file in question is already in the cache which can only be >> solved by emptying the cache, see bugzilla). Jürgen> So what shall we do with this patch? I guess we have to apply it, since it is a regression. You should add a pointer to the bug, along with the fixme. JMarc
Re: [Updated PATCH] 3877:Highlighting text slows down LyX extremely
José Matos wrote: On Monday 09 July 2007 18:12:48 Bo Peng wrote: Jose, if you can not decide, just toss a coin. IMO, both approaches are good enough. :-) OK then, let us go Jean-Marc's way, and proceed for other more pressing issues. I could have bet you would say this. Abdel.
Re: [Updated PATCH] accept utf8 in layout files
Jean-Pierre Chrétien wrote: The problems comes from the fact that with both layout and lyx files in Unicode, lyx crashes on this: Assertion triggered in const lyx::docstring lyx::from_ascii(const char*) by failing check "static_cast(*c) < 0x80" in file docstring.cpp:32 Abort I know and my patch solves this, did you try it? This would not happen with the gettext translation mechanism (name the styles in ascii, translate in the .po file), but it seems agreed that this is too complicated for user layouts. Not yet agreed. Abdel.
Re: [Updated PATCH] 3877:Highlighting text slows down LyX extremely
On Monday 09 July 2007 18:12:48 Bo Peng wrote: > Jose, if you can not decide, just toss a coin. IMO, both approaches > are good enough. :-) OK then, let us go Jean-Marc's way, and proceed for other more pressing issues. > Bo In this issue I feel like Golan Trevize: http://en.wikipedia.org/wiki/Golan_Trevize ;-) -- José Abílio
Re: [patch] bug 3819: LyX fails to export with an XFig insert w/ Image Cache enabled
Jürgen Spitzmüller wrote: > http://bugzilla.lyx.org/show_bug.cgi?id=3819 > > This is a patch from Georg. I tested it and it seems to work for me (there > is an issue with an assert directly after applying the patch if the file in > question is already in the cache which can only be solved by emptying the > cache, see bugzilla). So what shall we do with this patch? Jürgen
Re: [Updated PATCH] accept utf8 in layout files
Abdelrazak Younes <[EMAIL PROTECTED]> writes: > > Jean-Marc Lasgouttes wrote: > >> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: > > > > Abdelrazak> Why should we? I am probably missing something but... > > Abdelrazak> isn't it enough to tell to the users that their layout > > Abdelrazak> needs to be converted to utf8? Of course we should say it > > Abdelrazak> big and loud but I reckon that users that are able to > > Abdelrazak> change a layout are also able to change the encoding of > > Abdelrazak> their layout. Especially so if the big goal of 1.5 is > > Abdelrazak> unicode. > > > > And then, what about their old .lyx files that contain layouts with latin1 > > names? Or am I missing something? > > As for the layouts, they should also convert their LyX file to utf8. If > they can convert their layouts, they can also convert their LyX files. > They should do that in any case. > For any users (especially users not using latin-1 encoding), I reckon > there should be a strong recommendation to convert all their old LyX > file to UTF-8. If it is not the announcement, it should be. >From the user point of view, it's different for lyx files and for layouts: - for lyx files, you can do it manually with lyx2lyx, or by loading the old file format thet you should be able to use right out of the box. You can even keep the lyx file in the old format if you do not edit it, but it will be Unicoded all right if you save it (including style names); - for layouts, the python script layout2layout.py does format conversion between layouts (and again, old format layouts are converted on the fly), but layout2layout.py knows nothing about Unicode, so you have to convert it manually with iconv (see the older thread about 1.4 to 1.5 upgrade). This is required anyway for isolatin characters spreading around in local layouts. So the user HAS to convert his own layouts to Unicode. So from the user point of view, nothing else to do with lyx files than loading in 1.5, manual format/unicode conversion of user layouts required. The problems comes from the fact that with both layout and lyx files in Unicode, lyx crashes on this: Assertion triggered in const lyx::docstring lyx::from_ascii(const char*) by failing check "static_cast(*c) < 0x80" in file docstring.cpp:32 Abort This would not happen with the gettext translation mechanism (name the styles in ascii, translate in the .po file), but it seems agreed that this is too complicated for user layouts. -- Jean-Pierre
