Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...
On Wed, Sep 06, 2006 at 05:40:23PM +0200, Peter Kümmel wrote: Peter Kümmel wrote: care about it. I just wanna see if it's possible to get Dlls without huge changes. Maybe the design of lyx is s bad that it is not possible. ;) It is indeed so bad. But that's not new knowledge... Andre'
Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...
On Wed, Sep 06, 2006 at 05:06:08PM +0200, Lars Gullik Bjønnes wrote: Isn't it possible to use export lists instead of doing the (imho braindead) annotation on all functions? It is possible. The problem then is to enumerate all the _mangled_ names in the .def file. That's even worse. Maybe there's a tool for generating a list. mingw32 used to have a 'dlltool' IIRC, but yjis probably won't work in a MSVC environment. And no, I don't like the EXPORT macro stuff either. Andre' --
Re: Active table and math toolbar
Michael Gerz wrote: BTW: bottom is ignored in 1.5.0svn/qt4. The tool bar is always displayed at the top. Should I add a bugzilla report? Yes, I am aware of it an I plaid guilty. Right now the toolbars are hard-coded to be at the top because I didn't have the time to fix it properly last christmas. Abdel.
Re: Let's do the same for dialogs! (was Re: [Patch] use enum instead of strings for type of math 'hull' inset)
Andre Poenitz wrote: On Tue, Sep 05, 2006 at 03:33:36PM +0200, Abdelrazak Younes wrote: char const * const dialognames[] = { aboutlyx, bibitem, bibtex, box, branch, changes,... For this I'd actually prefer a factory that's initialized by static singleton or such. Could you elaborate a bit please? The different dialogs are accessed with a string key. The key could as well be an int without any difference in behaviour, that's what I mean. The enum requires a place where all dialogs are known (at least conceptionally) so that we can define an enum { dialogFoo, dialogBar } With a factory (in an ideal world...) we could (in theory...) have a core completely ignorant of concrete dialogs. 'lfun-insert-inset foo' would just ask the factory to create a dialog by a generator registered under the name 'foo'. I agree that the core should not know about concrete dialog. But I would like to be sure that the dialog IDs are exactly the same for all frontends. For this I need the enum to be placed in src/frontend/. Then each frontend could choose to implement or not a dialog. The code in src/frontend/ is an abstraction of the frontend and does not really belong to the core. Abdel.
Re: Shared Libraries
Peter Kümmel wrote: Andre Poenitz wrote: On Tue, Sep 05, 2006 at 11:16:14AM +0200, Peter Kümmel wrote: I have started with frontend/qt4/ but give up because qt4 needs several functions from the other libs. We must start at the bottom not at the top, and qt4 is at the top. Exactly. The problem with the current architecture is, of, course, that drawing is 'pushed' by the kernel, not 'pulled' by the frontend (containing th painter) Andre' Yes, building insets is completely hopeless. And this artifact was nicely hidden by the gcc. Why has lyx not a mvc design where the model nothing knows about the view but its base class? For inset drawing, it will be difficult to achieve easily but that's the goal yes. OTOH, dialogs can and should be converted to a model/view separation. Please have a look at the TOC implementation in qt4/. Abdel.
Re: Shared Libraries
Andre Poenitz wrote: On Tue, Sep 05, 2006 at 11:16:14AM +0200, Peter Kümmel wrote: I have started with frontend/qt4/ but give up because qt4 needs several functions from the other libs. We must start at the bottom not at the top, and qt4 is at the top. Exactly. The problem with the current architecture is, of, course, that drawing is 'pushed' by the kernel, not 'pulled' by the frontend (containing th painter) The plan is of course to change that. Abdel.
Re: Shared Libraries
Andre Poenitz wrote: On Tue, Sep 05, 2006 at 10:37:27AM +0200, Abdelrazak Younes wrote: That's exactly the problem indeed. My earlier cleanup work is heading toward the frontend use the kernel as a library design. Once this is achieved, splitting out the toolkit specific frontend should be easy. So clearly the first candidate for a new dll is the code in frontend/qt4/. Doesn't that contradict each other? Shouldn't there be a lyxkernel.dll and the frontend using this? The frontend virtual interface yes. The qt4 frontend will just be an implementation of this interface and could entirely be in a single dll. This way the lyx-executable would not even have to link to Qt4, only the qt4 frontend dll. The controller will need some cleanup before it could be split up. I still think merging the controller into the frontend specific code would make things a grest deal simpler, more flexible _and_ smaller, even when using two frontends... I agree this should be done on a case by case basis. Each dialog controller should be reviewed for correctness. A controller should not open a dialog for example. The spellchecher controller is an example of such bad design. Abdel.
Re: Shared Libraries
Andre Poenitz wrote: On Tue, Sep 05, 2006 at 10:59:41AM +0200, Abdelrazak Younes wrote: Peter Kümmel wrote: At the current stage the code is full of dependencies, and some circular could only be solved by moving functions into a other library. I think you should forget about the controller for now and concentrated on the frontend. Mathed seems also to be a good candidate. Mathed depends on the core _and_ on the painert stuff, so how could that be a good candidate to start with? This was just a guess as the mathed code seems pretty isolated from the rest of the LyX code. As you said in an earlier mail, the painter stuff needs to be rethought. Abdel.
Re: [PATCH] Re-introduce layout menu
Michael == Michael Gerz [EMAIL PROTECTED] writes: Michael Nevertheless, at some point in time, we should ask the LyX Michael users (not the developers) what they would like to see as the Michael default. Personally, I think that the traditional Michael Windows/Word/OOo user prefers the classic look feel but Michael that is left to be proven. Does anybody read the lyx users Michael mailing list regularly? What did the old guys say about the Michael new 1.4 menu structure? All I can say is that there have been less resistance wrt the menu structure than I expected. But I cannot tell what this means :) JMarc
Re: Towards LyX 1.4.3 [status update #1]
Jean-Marc Lasgouttes wrote: 2698 add buttons for \intop and \ointop to math panel Georg, did you have time to look at the icons? Otherwise, we shall postpone. Now I looked at it. This patch adds the icons from Uwe. OK to go in? Georg Log: Fix bug 2698 (new images from Uwe Stöhr) * src/frontends/controllers/ControlMath.C (latex_misc): Add intop and ointop * lib/images/math/intop.xpm: New * lib/images/math/ointop.xpm: Ditto * lib/images/math/int.xpm: Add box to make the difference to intop clear * lib/images/math/oint.xpm: ditto * lib/Makefile.am: add new filesIndex: src/frontends/controllers/ControlMath.C === --- src/frontends/controllers/ControlMath.C (Revision 14921) +++ src/frontends/controllers/ControlMath.C (Arbeitskopie) @@ -188,7 +188,7 @@ char const * latex_misc[] = { int const nr_latex_misc = sizeof(latex_misc) / sizeof(char const *); char const * latex_varsz[] = { - sum, int, oint, + sum, int, intop, oint, ointop, prod, coprod, bigsqcup, bigotimes, bigodot, bigoplus, bigcap, bigcup, biguplus, Index: status.14x === --- status.14x (Revision 14921) +++ status.14x (Arbeitskopie) @@ -30,6 +30,8 @@ What's new - Updated Czech (Tutorial, new splash) and German (UserGuide, Extended) documentation. +- Add buttons for \intop and \ointop to the math panel (bug 2698) + ** Bug fixes: * Document Input/Output Index: lib/images/math/intop.xpm === --- lib/images/math/intop.xpm (Revision 14921) +++ lib/images/math/intop.xpm (Arbeitskopie) @@ -0,0 +1,41 @@ +/* XPM */ +static char *a[] = { +/* columns rows colors chars-per-pixel */ +15 32 3 1, + c #00, +. c #00, +X c None, +/* pixels */ +XX...XX, +X.X, +..XXX.X, +..XX..X, +..X, +XXX..XX, +XXX..XX, +XXX..XX, +XXX..XX, +XXX..XX, +XXX..XX, +XXX..XX, +XXX..XX, +XX..XXX, +XX..XXX, +XX..XXX, +XX..XXX, +XX..XXX, +XX..XXX, +XX..XXX, +XX..XXX, +X.., +X..XX.., +X.XXX.., +X.X, +XX...XX, +XXX, +.X.X.X., +XXX, +.X., +XXX, +.X.X.X., +}; Index: lib/images/math/oint.xpm === --- lib/images/math/oint.xpm (Revision 14921) +++ lib/images/math/oint.xpm (Arbeitskopie) @@ -1,35 +1,35 @@ /* XPM */ static char *a[] = { /* columns rows colors chars-per-pixel */ -13 26 3 1, +15 26 3 1, c #00, . c #00, X c None, /* pixels */ -X...X, -., -XXX..XXX., -XXX..XX.., -XXX.., -XX..X, -XX..X, -XX..X, -XX..X, -., -XX...XXXX, -X..XXX..XX.XX, -X..XXX..XX.XX, -X..XX..XXX.XX, -X...X..XXX.XX, -XX.X..XXX, -X, -X..XX, -X..XX, -X..XX, -X..XX, -..XXX, -..XX..XXX, -.XXX..XXX, -., -X...X +X...XXX, +.XX, +XXX..XXX.XX, +XXX..XX..XX, +XXX..XX, +XX..XXX, +XX..XXX, +XX..XXX, +XX..XXX, +.XX, +XX...XX, +X..XXX..XX., +X..XXX..XX., +X..XX..XXX., +X...X..XXX., +XX.X..X, +XXX, +X.., +X.., +X.., +X.., +..XX.X.X.X., +..XX..X, +.XXX..XX.X., +.XX, +X....X.X.X. }; Index: lib/images/math/int.xpm === --- lib/images/math/int.xpm (Revision 14921) +++ lib/images/math/int.xpm (Arbeitskopie) @@ -1,48 +1,35 @@ /* XPM */ -static char const * const int_xpm[] = { -/* width height ncolors chars_per_pixel */ -18 25 16 1, -/* colors */ -O c None, +static char *a[] = { +/* columns rows colors chars-per-pixel */ +17 26 3 1, c #00, -. c #939393, -X c #676767, -o c #3B3B3B, -+ c #CECECE, -@ c #0F0F0F, -# c #B0B0B0, -$ c #A2A2A2, -% c #848484, - c #767676, -* c #585858, -= c #4A4A4A, -- c #2C2C2C, -; c #1E1E1E, -: c #BFBFBF, +. c #00, +X c None, /* pixels */ -OO, -OO, -[EMAIL PROTECTED], -OOO=+O, -OO#XOO, -OO%OO, -OO=:OO, -[EMAIL PROTECTED], -O#oOOO, -OXOOO, -O*OOO, -O;$OOO, -+ +OOO, -$;, -X=, -*X, --$, - O, -OOO#-O, -OOO.XO, -OOOX.O, -OOOo+O, -OO+-OO, -O-X%OO, -O=oOOO +XX..., +X.XXX, +..XXX.XXX, +..XX..XXX,
Re: USE_CYGWIN_PACKAGING
On Wed, Sep 06, 2006 at 09:29:21PM -0500, Bo Peng wrote: I plan to refine and apply the attached patch to 1.4.x. This patch lets 'scons install' generate the right kind of cygwin binary package (with /usr/doc/ ..., strip etc). To better reflect the uniqueness of cygwin, I have added USE_CYGWIN_PACKAGING to src/support/package.C, which basically says that cygwin has $HOME, and .exe suffix. JMarc, what do you think about this macro? It is nice to have but it is not absolutely needed since I can walk around it in SConstruct. Some autotools changes may be needed. IMO, USE_CYGWIN_PACKAGING is neither needed nor useful. You don't have to care about the .exe suffix, cygwin takes care of that and in a well thought manner. Every POSIX program that checks for its own name works when compiled on cygwin. No need to fiddle with .exe suffix. Please ;-) Cygwin is POSIX. -- Enrico
Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...
Lars Gullik Bjønnes wrote: Peter Kümmel [EMAIL PROTECTED] writes: | Peter Kümmel wrote: | care about it. I just wanna see if it's possible to get Dlls without | huge changes. | | Maybe the design of lyx is s bad that it is not possible. ;) Works without change on linux... Building a dll on windows is like linking with --no-undefined under linux. Try to link with this option then you will see how wired the dependencies are. -- Peter Kümmel
Re: generating project files with cmake
Georg Baum wrote: Joost Verburg wrote: Abdelrazak Younes wrote: Are there any tools available to locate it? I've heard good things about valgrind. But it's linux only AFAIK. Does anyone know of such a tool for Windows? I once worked with purify, but that is some time ago. See http://www-306.ibm.com/software/awdtools/purifyplus/ This was very nice: http://www.glowcode.com/ If we are going to switch, we should go for Enchant. This is a library that makes it is possible to support Aspell/Pspell, Ispell, HunSpell, MySpell, Uspell, Hspell and Mac OS X Applespell. That has been suggested already long time ago. I don't think that it would be too difficult to add enchant as an additional spell checker, and if everything works drop the other ones. Georg -- Peter Kümmel
[PATCH] Inset dissolve cleanup
The following pair of patch implement inset-dissolve in what I believe to be a clean way. There is no code in insets directory (the disabling for tabular insets is done by testing inset.nargs() == 1 instead). Please test. JMarc Index: src/insets/insettabular.C === --- src/insets/insettabular.C (revision 14921) +++ src/insets/insettabular.C (working copy) @@ -1045,28 +1045,6 @@ bool InsetTabular::getStatus(LCursor c return true; } - case LFUN_INSET_DISSOLVE: { - status.enabled(false); - return true; - } - - // because of the dissolve handling in insettext: - case LFUN_CHAR_DELETE_FORWARD: - if (!cur.selection() cur.depth() 1 - cur.pit() == cur.lastpit() - cur.pos() == cur.lastpos()) { - status.enabled(false); - return true; - } - // Fall through - - case LFUN_CHAR_DELETE_BACKWARD: - if (cur.depth() 1 cur.pit() == 0 cur.pos() == 0) { - status.enabled(false); - return true; - } - // Fall through - case LFUN_INSET_MODIFY: if (translate(cmd.getArg(0)) == TABULAR_CODE) { status.enabled(true); Index: src/insets/insettext.C === --- src/insets/insettext.C (revision 14921) +++ src/insets/insettext.C (working copy) @@ -268,47 +268,14 @@ void InsetText::doDispatch(LCursor cur [ cmd.action = cmd.action ']' endl; setViewCache(cur.bv()); - - switch (cmd.action) { - - case LFUN_CHAR_DELETE_FORWARD: { - if (!cur.selection() cur.depth() 1 - cur.pit() == cur.lastpit() - cur.pos() == cur.lastpos()) - // Merge inset with owner - cmd = FuncRequest(LFUN_INSET_DISSOLVE); - text_.dispatch(cur, cmd); - break; - } - - case LFUN_CHAR_DELETE_BACKWARD: { - if (cur.depth() 1 cur.pit() == 0 cur.pos() == 0) - // Merge inset with owner - cmd = FuncRequest(LFUN_INSET_DISSOLVE); - text_.dispatch(cur, cmd); - break; - } - - default: - text_.dispatch(cur, cmd); - break; - } + text_.dispatch(cur, cmd); } bool InsetText::getStatus(LCursor cur, FuncRequest const cmd, FuncStatus status) const { - switch (cmd.action) { - - case LFUN_CHAR_DELETE_FORWARD: - case LFUN_CHAR_DELETE_BACKWARD: - status.enabled(true); - return true; - - default: - return text_.getStatus(cur, cmd, status); - } + return text_.getStatus(cur, cmd, status); } Index: src/lyxtext.h === --- src/lyxtext.h (revision 14921) +++ src/lyxtext.h (working copy) @@ -232,6 +232,8 @@ public: bool backspacePos0(LCursor cur); /// Delete character before cursor. Honour CT bool backspace(LCursor cur); + // Dissolve the inset under cursor + bool dissolveInset(LCursor cur); /// bool selectWordWhenUnderCursor(LCursor cur, lyx::word_location); /// Index: src/text3.C === --- src/text3.C (revision 14921) +++ src/text3.C (working copy) @@ -79,7 +79,6 @@ using lyx::pos_type; using lyx::cap::copySelection; using lyx::cap::cutSelection; -using lyx::cap::pasteParagraphList; using lyx::cap::pasteSelection; using lyx::cap::replaceSelection; @@ -709,34 +708,9 @@ void LyXText::dispatch(LCursor cur, Fu break; } - case LFUN_INSET_DISSOLVE: { - recordUndoInset(cur); - cur.selHandle(false); - // save position - lyx::pos_type spos = cur.pos(); - lyx::pit_type spit = cur.pit(); - ParagraphList plist; - if (cur.lastpit() != 0 || cur.lastpos() != 0) - plist = paragraphs(); - cur.popLeft(); - // store cursor offset - if (spit == 0) - spos += cur.pos(); - spit += cur.pit(); - cur.paragraph().erase(cur.pos()); - if (!plist.empty()) { - Buffer * b = bv-buffer(); - pasteParagraphList(cur, plist, b-params().textclass, - b-errorList(Paste)); - // restore position - cur.pit() = std::min(cur.lastpit(), spit); - cur.pos() = std::min(cur.lastpos(), spos); - } - cur.clearSelection(); - cur.resetAnchor(); - needsUpdate = true; + case LFUN_INSET_DISSOLVE: + needsUpdate = dissolveInset(cur); break; - } case LFUN_INSET_SETTINGS: cur.inset().showInsetDialog(bv); @@ -1720,20 +1694,17 @@ bool LyXText::getStatus(LCursor cur, F enable = lyx::cap::numberOfSelections() 0; break; - case LFUN_PARAGRAPH_MOVE_UP: { + case LFUN_PARAGRAPH_MOVE_UP: enable = cur.pit() 0 !cur.selection(); break; - } - case LFUN_PARAGRAPH_MOVE_DOWN: { + case LFUN_PARAGRAPH_MOVE_DOWN: enable = cur.pit() cur.lastpit() !cur.selection(); break; - } - case LFUN_INSET_DISSOLVE: { - enable = !isMainText() cur.inTexted(); + case LFUN_INSET_DISSOLVE: + enable = !isMainText() cur.inset().nargs() == 1; break; - } case LFUN_WORD_DELETE_FORWARD: case LFUN_WORD_DELETE_BACKWARD: Index: src/text.C === --- src/text.C (revision 14921) +++ src/text.C (working copy) @@ -88,6 +88,7 @@ using lyx::support::split; using
Re: Towards LyX 1.4.3 [status update #1]
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg Jean-Marc Lasgouttes wrote: 2698 add buttons for \intop and \ointop to math panel Georg, did you have time to look at the icons? Otherwise, we shall postpone. Georg Now I looked at it. This patch adds the icons from Uwe. OK to Georg go in? Sure. JMarc
Re: Active table and math toolbar
John == John Levon [EMAIL PROTECTED] writes: John On Wed, Sep 06, 2006 at 11:01:41PM +0200, Michael Gerz wrote: I think this patch (or a similar one) has been discussed already. Should I commit it? John This is a really difficult one to decide. I can see this being John enormously irritating default behaviour for some people, and we John don't yet have a View-Toolbars that can easily turn it off. On John the other hand, these toolbars are extremely useful. What about a new 'Allow automatic toolbars' lyxrc entry? Then we could set the default to 'true'. Or to 'false' :) JMarc
[PATCH] bug 2600: Change tracking and tables hangs or asserts
The following patches fix a crash: http://bugzilla.lyx.org/show_bug.cgi?id=2600 The problem was the assumption that the LyXText of the cursor is the same as the LyXText of cursor.selBegin. I think there are still problems with CT and tables, but I propose to apply at least this one. I think that the rest of the problem would be fixed by a proper fix to bug 2510. JMarc Index: src/BufferView_pimpl.C === --- src/BufferView_pimpl.C (revision 14926) +++ src/BufferView_pimpl.C (working copy) @@ -749,17 +749,11 @@ bool BufferView::Pimpl::available() cons Change const BufferView::Pimpl::getCurrentChange() { - if (!buffer_-params().tracking_changes) + if (!buffer_-params().tracking_changes || !cursor_.selection()) return Change(Change::UNCHANGED); - LyXText * text = bv_-getLyXText(); - LCursor cur = cursor_; - - if (!cur.selection()) - return Change(Change::UNCHANGED); - - return text-getPar(cur.selBegin().pit()). - lookupChangeFull(cur.selBegin().pos()); + DocIterator dit = cursor_.selectionBegin(); + return dit.paragraph().lookupChangeFull(dit.pos()); } Index: src/BufferView_pimpl.C === --- src/BufferView_pimpl.C (revision 14924) +++ src/BufferView_pimpl.C (working copy) @@ -586,17 +586,11 @@ bool BufferView::Pimpl::available() cons Change const BufferView::Pimpl::getCurrentChange() { - if (!buffer_-params().tracking_changes) + if (!buffer_-params().tracking_changes || !cursor_.selection()) return Change(Change::UNCHANGED); - LyXText * text = bv_-getLyXText(); - LCursor cur = cursor_; - - if (!cur.selection()) - return Change(Change::UNCHANGED); - - return text-getPar(cur.selBegin().pit()). - lookupChange(cur.selBegin().pos()); + DocIterator dit = cursor_.selectionBegin(); + return dit.paragraph().lookupChange(dit.pos()); }
Re: Towards LyX 1.4.3 [status update #1]
On Fri, Aug 25, 2006 at 05:05:04PM +0200, Jean-Marc Lasgouttes wrote: We have come a long way towards 1.4.3, so now is the time to think about a release. I will be in vacation again next week, so the date should be some time at the beginning of September. Please JMarc, could the attached patch be applied to 1.4.x? It is about small fixes for the cygwin target: - Cygwin does not have locale support, so the warning about Locale xx_XX could not be set is bogus. - Some unnecessary path conversions are avoided. - When the fronted is Qt3/X11, it is not necessary that external_path and external_path_list return a windows style path. Thanks in advance. -- Enrico Index: src/ChangeLog === --- src/ChangeLog (revision 14926) +++ src/ChangeLog (working copy) @@ -1,3 +1,8 @@ +1006-09-07 Enrico Forestieri [EMAIL PROTECTED] + + * messages.C (Messages::get): don't warn about locale on cygwin + as it is not supported. + 2006-08-19 Jean-Marc Lasgouttes [EMAIL PROTECTED] * BufferView_pimpl.C (focusChange): new method; updates the Index: src/support/ChangeLog === --- src/support/ChangeLog (revision 14926) +++ src/support/ChangeLog (working copy) @@ -1,3 +1,11 @@ +2006-09-07 Enrico Forestieri [EMAIL PROTECTED] + * os_cygwin.C (is_windows_path): avoid unnecessary conversion + when path is relative + (convert_path_list): avoid unnecessary conversion when path + list is empty + (external_path, external_path_list): for an X11 build it is not + necessary that the output path style is windows + 2006-06-27 Enrico Forestieri [EMAIL PROTECTED] * os.h: rename cygwin_path_fix as windows_style_tex_paths. Index: src/support/os_cygwin.C === --- src/support/os_cygwin.C (revision 14926) +++ src/support/os_cygwin.C (working copy) @@ -55,8 +55,7 @@ bool is_posix_path(string const p) bool is_windows_path(string const p) { - return p.empty() || - (!contains(p, '\\') (p.length() = 1 || p[1] == ':')); + return p.empty() || (!contains(p, '\\') p[0] != '/'); } @@ -87,6 +86,9 @@ string convert_path(string const p, Pa string convert_path_list(string const p, PathStyle const target) { + if (p.empty()) + return p; + char const * const pc = p.c_str(); PathStyle const actual = cygwin_posix_path_list_p(pc) ? posix : windows; @@ -186,7 +188,11 @@ string::size_type common_path(string con string external_path(string const p) { +#ifdef X_DISPLAY_MISSING return convert_path(p, PathStyle(windows)); +#else + return convert_path(p, PathStyle(posix)); +#endif } @@ -198,7 +204,11 @@ string internal_path(string const p) string external_path_list(string const p) { +#ifdef X_DISPLAY_MISSING return convert_path_list(p, PathStyle(windows)); +#else + return convert_path_list(p, PathStyle(posix)); +#endif } Index: src/messages.C === --- src/messages.C (revision 14926) +++ src/messages.C (working copy) @@ -126,10 +126,10 @@ public: #endif // setlocale fails (returns NULL) if the corresponding locale // is not installed. - // On windows (mingw) it always returns NULL. + // On windows (mingw and cygwin) it always returns NULL. // Since this method gets called for every translatable // buffer string like e.g. Figure: we warn only once. -#ifndef _WIN32 +#if !defined(_WIN32) !defined(__CYGWIN__) static bool warned = false; if (!warned !lc_msgs) { warned = true;
Re: inset-dissolve
Michael Gerz wrote: Hi Jürgen, inset-dissolve is still broken: If you open a new document, the function is enabled (which wrong) as you can see in the menu. If you want to dissolve the non-existent inset nevertheless, LyX crashes. But this is correct behaviour! You dissolve the empty document - lyx indeed goes away! ;-) Helge Hafting
Re: Towards LyX 1.4.3 [status update #1]
On Mon, 2006-09-04 at 11:08 +0200, Juergen Spitzmueller wrote: Jean-Marc Lasgouttes wrote: My question now is whether to put this in 1.4.3 or 1.4.4. I tend to think it will be 1.4.4, but I am not fixed on that. I tend to think so, too, for testing reasons. Let's put the patch in soon after 1.4.3 is released, so that people who use 1.4svn for daily work (like me) can text it under real life conditions before releasing. Jürgen I second that. Thanks for the offer :-) - Martin signature.asc Description: This is a digitally signed message part
fs_extras compile fails (errno not declared in this scope)
if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./.. -I../../boost -Wextra -Wall-I/usr/X11R6/include -O2 -MT fs_extras.lo -MD -MP -MF .deps/fs_extras.Tpo -c -o fs_extras.lo fs_extras.C; \ then mv -f .deps/fs_extras.Tpo .deps/fs_extras.Plo; else rm -f .deps/fs_extras.Tpo; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./.. -I../../boost -Wextra -Wall -I/usr/X11R6/include -O2 -MT fs_extras.lo -MD -MP -MF .deps/fs_extras.Tpo -c fs_extras.C -o fs_extras.o fs_extras.C: In function 'void boost::filesystem::copy_file(const boost::filesystem::path, const boost::filesystem::path, bool)': fs_extras.C:101: error: 'errno' was not declared in this scope fs_extras.C:107: error: 'errno' was not declared in this scope fs_extras.C:120: error: 'errno' was not declared in this scope fs_extras.C:148: error: 'errno' was not declared in this scope make[6]: *** [fs_extras.lo] Error 1 make[6]: Leaving directory `/home/kayvan/rpmbuild/BUILD/lyx-1.5.0svn/src/support' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/home/kayvan/rpmbuild/BUILD/lyx-1.5.0svn/src/support' make[4]: *** [all] Error 2 make[4]: Leaving directory `/home/kayvan/rpmbuild/BUILD/lyx-1.5.0svn/src/support' -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan, | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | my beautiful Queen.| Robin Gregory (2/28/92) pgpmq69amdoxc.pgp Description: PGP signature
Re: Towards LyX 1.4.3 [status update #1]
Jean-Marc Lasgouttes wrote: 2660 patch german userguide broken What remains to be done is copy the icons and update Makefile.am. Please, someone... I just did that (and found two more invalid image paths). We need some lint for .lyx files. Georg
Re: fs_extras compile fails (errno not declared in this scope)
Kayvan A. Sylvan wrote: fs_extras.C:101: error: 'errno' was not declared in this scope fs_extras.C:107: error: 'errno' was not declared in this scope fs_extras.C:120: error: 'errno' was not declared in this scope fs_extras.C:148: error: 'errno' was not declared in this scope make[6]: This is fixed now. errno.h was not included. Georg
Re: fs_extras compile fails (errno not declared in this scope)
Georg Baum [EMAIL PROTECTED] writes: | Kayvan A. Sylvan wrote: | | fs_extras.C:101: error: 'errno' was not declared in this scope | fs_extras.C:107: error: 'errno' was not declared in this scope | fs_extras.C:120: error: 'errno' was not declared in this scope | fs_extras.C:148: error: 'errno' was not declared in this scope make[6]: | | This is fixed now. errno.h was not included. and should not be included ... we want cerrno -- Lgb
Re: USE_CYGWIN_PACKAGING
IMO, USE_CYGWIN_PACKAGING is neither needed nor useful. You don't have In the patch, I use packaging_method == 'cygwin' to install files as instructed by cygwin-packaging standard. I can use platform == 'cygwin' but the former seems to be more logical. Also, it might not be at all useful, but the packaging option (both autotools and scons) allows us to make packages cross-platformly. Bo
Re: Towards LyX 1.4.3 [status update #1]
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg Jean-Marc Lasgouttes wrote: 2660 patch german userguide broken What remains to be done is copy the icons and update Makefile.am. Please, someone... Georg I just did that (and found two more invalid image paths). We Georg need some lint for .lyx files. Thanks a lot! JMarc
Re: fs_extras compile fails (errno not declared in this scope)
Lars Gullik Bjønnes wrote: and should not be included ... we want cerrno Why? I don't know any advantage, only a disadvantage: Some compilers do not have it. Georg
Re: please complete short Questionnaire for Developers (part of a user interface study)
Daryl Hepting wrote: Lyx Developer Questionnaire This questionnaire will be used by students of the CS305 course at the University of Regina to inform their semester’s work. Results of this work will be contributed back to the lyx project. All replies sent to me directly ([EMAIL PROTECTED]) will have all identifying information removed before anyone else sees them. This course project study has been approved by the Research Ethics Board at the University of Regina ([EMAIL PROTECTED]). If any publication follows the semester’s work, your replies will not be directly quoted and your responses will not be identifiable. [If you would like to be identified and associated with your comments, please indicate that to me in your reply.] Your completion (and return) of this questionnaire implies your consent for the uses stated above. Why did you choose to become involved with the lyx project? I wanted to learn Qt and contribute something to LyX. Porting LyX from Qt3 to Qt4 seemed to be an easy enough task. I didn't know at the time how much time this project will suck in my life... How would you describe the vision for the lyx project, and why? The best portable document writing tool ever. For whom is lyx intended? Hopefully to anybody willing to spend half a day reading the Tutorial. It's the optimal tool for Scientists and I've heard for Linguists too. Are there any comments you’d like to share about your experience with the lyx project? Come on-board, plenty of things to do here! Abdel.
Re: Towards LyX 1.4.3 [status update #1]
On Thursday 07 September 2006 13:50, Georg Baum wrote: I just did that (and found two more invalid image paths). We need some lint for .lyx files. It is on my todo list, FWIW. :-) Georg -- José Abílio
Re: please complete short Questionnaire for Developers (part of a user interface study)
Why did you choose to become involved with the lyx project? I like lyx, I was between jobs, and I find that it is easier to contribute than arguing in the mailing list and waiting for months (years?) for a feature to be implemented. How would you describe the vision for the lyx project, and why? The best tool for tech writing. For whom is lyx intended? People who have higher standard for the look of their article (book etc), need to write lots of formula, willing to learn a bit latex and read some tutorials about lyx. Bo
Re: fs_extras compile fails (errno not declared in this scope)
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg Lars Gullik Bjønnes wrote: and should not be included ... we want cerrno Georg Why? I don't know any advantage, only a disadvantage: Some Georg compilers do not have it. I think all compilers have it now. JMarc
Re: fs_extras compile fails (errno not declared in this scope)
Jean-Marc Lasgouttes wrote: Georg == Georg Baum [EMAIL PROTECTED] writes: Georg Lars Gullik Bjønnes wrote: and should not be included ... we want cerrno Georg Why? I don't know any advantage, only a disadvantage: Some Georg compilers do not have it. I think all compilers have it now. OK I changed it, but I am still curious to hear why cerrno is better. Georg
Re: Shared Libraries
On Thu, Sep 07, 2006 at 09:39:13AM +0200, Abdelrazak Younes wrote: Shouldn't there be a lyxkernel.dll and the frontend using this? The frontend virtual interface yes. The qt4 frontend will just be an implementation of this interface and could entirely be in a single dll. This way the lyx-executable would not even have to link to Qt4, only the qt4 frontend dll. I am not sure there needs to be a virtual frontend interface at all. In theory, ther kernel could be completely ignorant of any frontend and just signal internal changes. A frontend would directly call into the kernel to make things happen and adjust afterwards by listening to the signals. IMO a common frontend base is a design mistake that puts things downside up: The kernel tells the frontend to draw and listen to events from the frontend. No good. Andre'
Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...
On Thu, Sep 07, 2006 at 11:29:05AM +0200, Peter Kümmel wrote: Lars Gullik Bjønnes wrote: Peter Kümmel [EMAIL PROTECTED] writes: | Peter Kümmel wrote: | care about it. I just wanna see if it's possible to get Dlls without | huge changes. | | Maybe the design of lyx is s bad that it is not possible. ;) Works without change on linux... Building a dll on windows is like linking with --no-undefined under linux. --no-undefined plus -Bsymbolic plus explicit symbol export plus separate heaps plus some 'minor' details. Andre'
Re: Shared Libraries
On Thu, Sep 07, 2006 at 09:41:55AM +0200, Abdelrazak Younes wrote: Mathed depends on the core _and_ on the painert stuff, so how could that be a good candidate to start with? This was just a guess as the mathed code seems pretty isolated from the rest of the LyX code. As you said in an earlier mail, the painter stuff needs to be rethought. Mathed is indeed pretty isolated in the sense that even largish internal changes do not affect the rest much. However, it is not easily separable into a self-contained library. Andre'
Re: Shared Libraries
On Wed, Sep 06, 2006 at 08:49:35PM +0200, Peter Kümmel wrote: The problem with the current architecture is, of, course, that drawing is 'pushed' by the kernel, not 'pulled' by the frontend (containing th painter) Yes, building insets is completely hopeless. And this artifact was nicely hidden by the gcc. Why has lyx not a mvc design where the model nothing knows about the view but its base class? Because LyX architecture is ten years old and mvc wasn't exactly hyped at this time? Andre'
Re: Shared Libraries
On Thu, Sep 07, 2006 at 09:30:18AM +0200, Abdelrazak Younes wrote: Andre Poenitz wrote: On Tue, Sep 05, 2006 at 11:16:14AM +0200, Peter Kümmel wrote: I have started with frontend/qt4/ but give up because qt4 needs several functions from the other libs. We must start at the bottom not at the top, and qt4 is at the top. Exactly. The problem with the current architecture is, of, course, that drawing is 'pushed' by the kernel, not 'pulled' by the frontend (containing th painter) The plan is of course to change that. Of course. Last time I tried it I got stuck somewhere between updateInsetInInset and tabulators in MathParInset... Andre'
Re: Active table and math toolbar
Jean-Marc Lasgouttes schrieb: John This is a really difficult one to decide. I can see this being John enormously irritating default behaviour for some people, and we John don't yet have a View-Toolbars that can easily turn it off. On John the other hand, these toolbars are extremely useful. What about a new 'Allow automatic toolbars' lyxrc entry? Then we could set the default to 'true'. Or to 'false' :) In that case, the current UI file design does not make sense any longer. Anyway, there are at least three people among us who would like to see a short-term solution. See http://bugzilla.lyx.org/show_bug.cgi?id=2813 Why don't we activate the toolbars for now (and for 1.4.3)? The activation is not a showstopper in case someone wants to optimize the look feel later. Michael
Re: [PATCH] Re-introduce layout menu
John Levon schrieb: What would be REALLY cool is some actual UI testing in a proper lab infrastructure. But slightly cool would be something that collected real-life data on menu use, and allowed us to collect it (modulo privacy concerns etc.) Asking a self-selecting population is notoriously tricky for getting meaningful answers. How about my recent Character Style patch? Is this something in the spirit of your GUI design (most important things first etc.)? Michael
Re: [PATCH] Inset dissolve cleanup
Jean-Marc Lasgouttes schrieb: The following pair of patch implement inset-dissolve in what I believe to be a clean way. There is no code in insets directory (the disabling for tabular insets is done by testing inset.nargs() == 1 instead). Please test. inset-dissolve works for 1.5.0, even with nested insets! (I am not able to test 1.4.X right now) Just one cosmetic issue: If you want to undo inset-dissolve, you have to press CTRL-Z twice. This might be a bit disturbing for some users. Michael
Re: [PATCH] Re-introduce layout menu
On Wed, Sep 06, 2006 at 11:29:58PM +0200, Michael Gerz wrote: John, JMarc, what do you think about the patch below? The idea is to have a submenu for character styles that combines layout-specific char styles, bold/emphasize/noun style, and the font dialog. The layout-specific char styles have been moved from menu Insert. Although the styles are actually implemented as insets, the user does not think in terms of inserting something. Bold/emphasize/noun style - whether you like it or not - are frequently requested features. There is at least one bugzilla report for re-adding bold to the menu. The font dialog is listed at the end (Other...) because users should not be encouraged to use it often. Regarding the word-* functions: We might move them to the submenu as well to shorten the Edit menu (as done in the patch). However, after testing word-capitalize, I really doubt that this particular functions is very useful (why do we have it at all?). Any comments? Michael This looks very nice to me. - Martin Index: stdmenus.ui === --- stdmenus.ui(revision 14919) +++ stdmenus.ui(working copy) @@ -89,14 +89,10 @@ Separator Item Find Replace...|F dialog-show findreplace Separator -Item Word in Small Capitals word-capitalize -Item Word in Uppercase word-upcase -Item Word in Lowercase word-lowcase -Separator Item Move Paragraph Up|o paragraph-move-up Item Move Paragraph Down|v paragraph-move-down Separator -Item Text Style...|S dialog-show character +Submenu Character Style...|C insert_charstyles Item Paragraph Settings...|P layout-paragraph Separator # Mathed b0rkage means these don't work properly @@ -136,6 +132,19 @@ PasteRecent End +Menu insert_charstyles +CharStyles +Separator +Item Emphasize Style|E font-emph +Item Noun Style|N font-noun +Item Bold Style|B font-bold +Separator +Item Other...|O dialog-show character +Separator +Item Uppercase word-upcase +Item Lowercase word-lowcase +End + # not much we can do to help here Menu edit_tabular Item Multicolumn|M tabular-feature multicolumn @@ -253,7 +262,6 @@ # YUCK Submenu Note|N insert_note OptSubmenu Branch|B insert_branches -OptSubmenu Character Style|y insert_charstyles Submenu File|e insert_file Item Box box-insert Frameless Separator @@ -377,10 +385,6 @@ Branches End -Menu insert_charstyles -CharStyles -End - # # DOCUMENT MENU # pgpH4y6x618o6.pgp Description: PGP signature
Re: USE_CYGWIN_PACKAGING
On 9/7/06, Bo Peng [EMAIL PROTECTED] wrote: IMO, USE_CYGWIN_PACKAGING is neither needed nor useful. You don't have Hi, Enrico, Could you please apply the attached patch, install scons-local, run python scons.py -f development/scons/SConstruct DESTDIR=cygwin_test mode=release install and check if the files are correctly installed as described in http://cygwin.com/setup.html ? I have also attached the required setup.hint. Bo Index: development/scons/SConstruct === --- development/scons/SConstruct (revision 14932) +++ development/scons/SConstruct (working copy) @@ -54,6 +54,7 @@ # some global settings # package_version = '1.4.3svn' +package_cygwin_version = '1.4.3svn-1' boost_version = '1_32' devel_version = True @@ -397,14 +398,14 @@ share_dir = 'Resources' man_dir = 'Resources/man/man1' locale_dir = 'Resources/locale' -default_prefix = 'c:/program files/lyx' else: share_dir = 'share/lyx' -man_dir = 'man/man1' locale_dir = 'share/locale' -default_prefix = '/usr/local/' +if platform_name == 'cygwin': +man_dir = 'share/man/man1' +else: +man_dir = 'man/man1' -# install to default_prefix by default # program suffix: can be yes, or a string if env.has_key('version_suffix'): if env['version_suffix'] in true_strings: @@ -792,6 +793,14 @@ else: env['MSGFMT'] = env_cache['MSGFMT'] +# cygwin packaging requires the binaries to be stripped +if platform_name == 'cygwin': +if not fast_start: +env['STRIP'] = conf.CheckCommand('strip') +env_cache['STRIP'] = env['STRIP'] +else: +env['STRIP'] = env_cache['STRIP'] + # check uic and moc commands for qt frontends if not fast_start: if frontend[:2] == 'qt' and (conf.CheckCommand('uic') == None \ @@ -1331,7 +1340,7 @@ # for details # if platform_name == 'cygwin': -ld_script_path = '/usr/lib/qt3/mkspecs/cygwin-g++' +ld_script_path = '/tmp' ld_script = utils.installCygwinLDScript(ld_script_path) env.AppendUnique(LINKFLAGS = ['-Wl,--enable-runtime-pseudo-reloc', '-Wl,--script,%s' % ld_script, '-Wl,-s']) @@ -2008,23 +2017,21 @@ else: version_suffix = '' # -# install lyx -target_name = os.path.split(str(lyx[0]))[1].replace('lyx', 'lyx%s' % version_suffix) -target = os.path.join(bin_dest_dir, target_name) -env.InstallAs(target, lyx) -Alias('install', target) -# -# install tex2lyx -target_name = os.path.split(str(tex2lyx[0]))[1].replace('tex2lyx', 'tex2lyx%s' % version_suffix) -target = os.path.join(bin_dest_dir, target_name) -env.InstallAs(target, tex2lyx) -Alias('install', target) -# -# install lyxclient, may not exist -if client != None: -target_name = os.path.split(str(client[0]))[1].replace('client', 'client%s' % version_suffix) +# install lyx, if in release mode, try to strip the binary +if env.has_key('STRIP') and env['STRIP'] is not None and mode != 'debug': +# create a builder to strip and install +env['BUILDERS']['StripInstallAs'] = Builder(action='$STRIP $SOURCE -o $TARGET') + +# install executables +for (name, obj) in (('lyx', lyx), ('tex2lyx', tex2lyx), ('client', client)): +if obj is None: +continue +target_name = os.path.split(str(obj[0]))[1].replace(name, '%s%s' % (name, version_suffix)) target = os.path.join(bin_dest_dir, target_name) -env.InstallAs(target, client) +if env['BUILDERS'].has_key('StripInstallAs'): +env.StripInstallAs(target, obj) +else: +env.InstallAs(target, obj) Alias('install', target) # # share/lyx @@ -2046,14 +2053,27 @@ ('lyx2lyx', lib_lyx2lyx_files)]: dirs.append(env.Install(os.path.join(share_dest_dir, dir), [env.subst('$TOP_SRCDIR/lib/%s/%s' % (dir, file)) for file in files])) +Alias('install', dirs) +if platform_name == 'cygwin': +# cygwin packaging requires a file /usr/share/doc/Cygwin/foot-vendor-suffix.README +Cygwin_README = os.path.join(dest_prefix_dir, 'doc', 'Cygwin', +'%s%s.README' % (package, package_cygwin_version)) +env.InstallAs(Cygwin_README, +os.path.join(env.subst('$TOP_SRCDIR'), 'README.cygwin')) +Alias('install', Cygwin_README) +# also a directory /usr/share/doc/lyx for README etc +Cygwin_Doc = os.path.join(dest_prefix_dir, 'doc', package) +env.Install(Cygwin_Doc, [os.path.join(env.subst('$TOP_SRCDIR'), x) for x in \ +['INSTALL', 'README', 'README.Cygwin', 'RELEASE-NOTES', 'COPYING', 'ANNOUNCE']]) +Alias('install', Cygwin_Doc) + # lyx1.4.x does not have lyx2lyx_version.py.in if os.path.isfile(env.subst('$TOP_SRCDIR/lib/lyx2lyx/lyx2lyx_version.py.in')): # subst and install this file env.substFile(share_dest_dir +
Re: [PATCH] Inset dissolve cleanup
Michael == Michael Gerz [EMAIL PROTECTED] writes: Michael Just one cosmetic issue: If you want to undo inset-dissolve, Michael you have to press CTRL-Z twice. This might be a bit Michael disturbing for some users. I know that, but I have not been able to avoid it. It is because we use the cut and paste machinery, which does its own undo. I really think it should not, if this is possible. Thanks for testing. JMarc
Re: Shared Libraries
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre Because LyX architecture is ten years old and mvc wasn't Andre exactly hyped at this time? Well, LyX is not older than smalltalk... JMarc
Re: [PATCH] Re-introduce layout menu
On Thu, Sep 07, 2006 at 09:07:17PM +0200, Michael Gerz wrote: John Levon schrieb: What would be REALLY cool is some actual UI testing in a proper lab infrastructure. But slightly cool would be something that collected real-life data on menu use, and allowed us to collect it (modulo privacy concerns etc.) Asking a self-selecting population is notoriously tricky for getting meaningful answers. How about my recent Character Style patch? Is this something in the spirit of your GUI design (most important things first etc.)? I'm at a conference right now, I'll try and look tonight? john
Re: Active table and math toolbar
On Thu, Sep 07, 2006 at 08:54:38PM +0200, Michael Gerz wrote: Why don't we activate the toolbars for now (and for 1.4.3)? The activation is not a showstopper in case someone wants to optimize the look feel later. Let's activate it for 1.5.0svn and see what happens, but not 1.4... regards john
Re: USE_CYGWIN_PACKAGING
On Thu, Sep 07, 2006 at 03:02:59PM -0500, Bo Peng wrote: On 9/7/06, Bo Peng [EMAIL PROTECTED] wrote: IMO, USE_CYGWIN_PACKAGING is neither needed nor useful. You don't have Hi, Enrico, Could you please apply the attached patch, install scons-local, run python scons.py -f development/scons/SConstruct DESTDIR=cygwin_test mode=release install I had already installed scons, so I ran scons -f ..., instead. I have not installed the boost libraries, so included boost was used. Scons detected that I have Aiksaurus and compilation went smooth till the final link stage which however failed as follows: g++ -o release/qt2/lyx.exe -Wl,--enable-runtime-pseudo-reloc -Wl,--script,/tmp/i386pe.x-no-rdata -Wl,-s release/common/main.o -Lrelease/libs -L/usr/lib/qt3/lib -L/usr/X11R6/lib -llyxbase_pre -lmathed -linsets -lfrontends -lqt2 -lcontrollers -lgraphics -lsupport -llyxbase_post -lincluded_boost_signals -lincluded_boost_regex -lincluded_boost_filesystem -lqt-mt -lintl -lshlwapi -lstdc++ -lz -liconv -lgdi32 -lAiksaurus -laspell /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lAiksaurus collect2: ld returned 1 exit status scons: *** [release/qt2/lyx.exe] Error 1 scons: building terminated because of errors. After I added extra_lib_path=/usr/local/lib to the scons command line (libAiksaurus.dll.a is there) everything went fine till the end. and check if the files are correctly installed as described in http://cygwin.com/setup.html ? It seems ok to me. However, don't be afraid, they (cygwin-apps) will tell you if something needs to be tuned. Index: README.Cygwin === --- README.Cygwin (revision 14932) +++ README.Cygwin (working copy) @@ -1,32 +1,44 @@ LyX/Cygwin +== + Ruurd Reitsma [EMAIL PROTECTED] +Bo Peng ben.bob#gmail.com -There are two ways to run LyX on Windows: -* as a native Windows application, using the Qt/Win Free clone of - Trolltech's cross-platform Qt toolkit. -* as a POSIX application running under the Cygwin environment. This README describes what is needed for the latter of these two options. Please refer to README.Win32 if you'd like to run LyX as a native Windows application. Maybe the previous last three lines should be deleted, too? + +Hide the cygwin console +=== + If you want to run LyX with no console windows open, there's a small program in development/Win32 that will set the proper environment vars and start LyX. I am afraid both lyxwin32.c and lyxprofile are not in development/Win32 anymore... I am attaching here a small script which will help you spotting dependencies. Launching it with a directory name as an argument (chkdep dir), it will scan that directory for executables and libraries and tells you the names of the packages containing the needed dynamic libraries. I also suggest that you apply this patch for the cygwin distribution: http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg100129.html (in case JMarc does not agree to apply it to 1.4.x) as you are allowed to apply local patches to the upstream sources. -- Enrico #!/bin/sh find $1 -name '*.exe' -o -name '*.dll' -o -name '*.bin' | \xargs cygcheck | \ sed -e '/\.exe/d' -e 's,\\,/,g' | sort -bu | \ xargs -n1 cygpath -u | xargs cygcheck -f | uniq
Re: USE_CYGWIN_PACKAGING
I have not installed the boost libraries, so included boost was used. Even if you have installed boost, the included boost will be used after a version check. Scons detected that I have Aiksaurus and compilation went smooth till the final link stage which however failed as follows: After I added extra_lib_path=/usr/local/lib to the scons command line (libAiksaurus.dll.a is there) everything went fine till the end. This is something need to be fixed. I will have a look. scan that directory for executables and libraries and tells you the names of the packages containing the needed dynamic libraries. I will do this within SConstruct. I also suggest that you apply this patch for the cygwin distribution: This patch should be applied. I have seen it twice but JMarc somehow missed them. Thanks. Bo
Hebrew Translation
hi, I would like to help with the hebrew translation of the LyX documentation. I contacted Tzafrir Cohen (which is listed as the contact for hebrew) but he told me that he doesn't activly maintain the hebrew translation. As there is no active contact for hebrew translation i don't know how can i help with the translation. I would thank you if you could explain to me how can i send new translation for the documentation and if I can be the hebrew tranlation contact man. Best Regards, Guy Rutenberg
Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...
On Wed, Sep 06, 2006 at 05:40:23PM +0200, Peter Kümmel wrote: > Peter Kümmel wrote: > > care about it. I just wanna see if it's possible to get Dlls without > > huge changes. > > Maybe the design of lyx is s bad that it is not possible. ;) It is indeed so bad. But that's not new knowledge... Andre'
Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...
On Wed, Sep 06, 2006 at 05:06:08PM +0200, Lars Gullik Bjønnes wrote: > Isn't it possible to use export lists instead of doing the (imho > braindead) annotation on all functions? It is possible. The problem then is to enumerate all the _mangled_ names in the .def file. That's even worse. Maybe there's a tool for generating a list. mingw32 used to have a 'dlltool' IIRC, but yjis probably won't work in a MSVC environment. And no, I don't like the EXPORT macro stuff either. Andre' --
Re: Active table and math toolbar
Michael Gerz wrote: BTW: "bottom" is ignored in 1.5.0svn/qt4. The tool bar is always displayed at the top. Should I add a bugzilla report? Yes, I am aware of it an I plaid guilty. Right now the toolbars are hard-coded to be at the top because I didn't have the time to fix it properly last christmas. Abdel.
Re: Let's do the same for dialogs! (was Re: [Patch] use enum instead of strings for type of math 'hull' inset)
Andre Poenitz wrote: On Tue, Sep 05, 2006 at 03:33:36PM +0200, Abdelrazak Younes wrote: char const * const dialognames[] = { "aboutlyx", "bibitem", "bibtex", "box", "branch", "changes",... For this I'd actually prefer a factory that's initialized by static singleton or such. Could you elaborate a bit please? The different dialogs are accessed with a string key. The key could as well be an int without any difference in behaviour, that's what I mean. The enum requires a place where all dialogs are known (at least conceptionally) so that we can define an enum { dialogFoo, dialogBar } With a factory (in an ideal world...) we could (in theory...) have a core completely ignorant of concrete dialogs. 'lfun-insert-inset foo' would just ask the factory to create a dialog by a generator registered under the name 'foo'. I agree that the core should not know about concrete dialog. But I would like to be sure that the dialog IDs are exactly the same for all frontends. For this I need the enum to be placed in src/frontend/. Then each frontend could choose to implement or not a dialog. The code in src/frontend/ is an abstraction of the frontend and does not really belong to the core. Abdel.
Re: Shared Libraries
Peter Kümmel wrote: Andre Poenitz wrote: On Tue, Sep 05, 2006 at 11:16:14AM +0200, Peter Kümmel wrote: I have started with frontend/qt4/ but give up because qt4 needs several functions from the other libs. We must start at the bottom not at the top, and qt4 is at the top. Exactly. The problem with the current architecture is, of, course, that drawing is 'pushed' by the kernel, not 'pulled' by the frontend (containing th painter) Andre' Yes, building insets is completely hopeless. And this artifact was nicely hidden by the gcc. Why has lyx not a mvc design where the model nothing knows about the view but its base class? For inset drawing, it will be difficult to achieve easily but that's the goal yes. OTOH, dialogs can and should be converted to a model/view separation. Please have a look at the TOC implementation in qt4/. Abdel.
Re: Shared Libraries
Andre Poenitz wrote: On Tue, Sep 05, 2006 at 11:16:14AM +0200, Peter Kümmel wrote: I have started with frontend/qt4/ but give up because qt4 needs several functions from the other libs. We must start at the bottom not at the top, and qt4 is at the top. Exactly. The problem with the current architecture is, of, course, that drawing is 'pushed' by the kernel, not 'pulled' by the frontend (containing th painter) The plan is of course to change that. Abdel.
Re: Shared Libraries
Andre Poenitz wrote: On Tue, Sep 05, 2006 at 10:37:27AM +0200, Abdelrazak Younes wrote: That's exactly the problem indeed. My earlier cleanup work is heading toward "the frontend use the kernel as a library" design. Once this is achieved, splitting out the toolkit specific frontend should be easy. So clearly the first candidate for a new dll is the code in frontend/qt4/. Doesn't that contradict each other? Shouldn't there be a lyxkernel.dll and the frontend using this? The frontend virtual interface yes. The qt4 frontend will just be an implementation of this interface and could entirely be in a single dll. This way the lyx-executable would not even have to link to Qt4, only the qt4 frontend dll. The controller will need some cleanup before it could be split up. I still think merging the controller into the frontend specific code would make things a grest deal simpler, more flexible _and_ smaller, even when using two frontends... I agree this should be done on a case by case basis. Each dialog controller should be reviewed for correctness. A controller should not open a dialog for example. The spellchecher controller is an example of such bad design. Abdel.
Re: Shared Libraries
Andre Poenitz wrote: On Tue, Sep 05, 2006 at 10:59:41AM +0200, Abdelrazak Younes wrote: Peter Kümmel wrote: At the current stage the code is full of dependencies, and some circular could only be solved by moving functions into a other library. I think you should forget about the controller for now and concentrated on the frontend. Mathed seems also to be a good candidate. Mathed depends on the core _and_ on the painert stuff, so how could that be a good candidate to start with? This was just a guess as the mathed code seems pretty isolated from the rest of the LyX code. As you said in an earlier mail, the painter stuff needs to be rethought. Abdel.
Re: [PATCH] Re-introduce layout menu
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes: Michael> Nevertheless, at some point in time, we should ask the LyX Michael> users (not the developers) what they would like to see as the Michael> default. Personally, I think that the traditional Michael> Windows/Word/OOo user prefers the classic look & feel but Michael> that is left to be proven. Does anybody read the lyx users Michael> mailing list regularly? What did the old guys say about the Michael> new 1.4 menu structure? All I can say is that there have been less resistance wrt the menu structure than I expected. But I cannot tell what this means :) JMarc
Re: Towards LyX 1.4.3 [status update #1]
Jean-Marc Lasgouttes wrote: > 2698 add buttons for \intop and \ointop to math panel > > Georg, did you have time to look at the icons? Otherwise, we shall > postpone. Now I looked at it. This patch adds the icons from Uwe. OK to go in? Georg Log: Fix bug 2698 (new images from Uwe Stöhr) * src/frontends/controllers/ControlMath.C (latex_misc): Add intop and ointop * lib/images/math/intop.xpm: New * lib/images/math/ointop.xpm: Ditto * lib/images/math/int.xpm: Add box to make the difference to intop clear * lib/images/math/oint.xpm: ditto * lib/Makefile.am: add new filesIndex: src/frontends/controllers/ControlMath.C === --- src/frontends/controllers/ControlMath.C (Revision 14921) +++ src/frontends/controllers/ControlMath.C (Arbeitskopie) @@ -188,7 +188,7 @@ char const * latex_misc[] = { int const nr_latex_misc = sizeof(latex_misc) / sizeof(char const *); char const * latex_varsz[] = { - "sum", "int", "oint", + "sum", "int", "intop", "oint", "ointop", "prod", "coprod", "bigsqcup", "bigotimes", "bigodot", "bigoplus", "bigcap", "bigcup", "biguplus", Index: status.14x === --- status.14x (Revision 14921) +++ status.14x (Arbeitskopie) @@ -30,6 +30,8 @@ What's new - Updated Czech (Tutorial, new splash) and German (UserGuide, Extended) documentation. +- Add buttons for \intop and \ointop to the math panel (bug 2698) + ** Bug fixes: * Document Input/Output Index: lib/images/math/intop.xpm === --- lib/images/math/intop.xpm (Revision 14921) +++ lib/images/math/intop.xpm (Arbeitskopie) @@ -0,0 +1,41 @@ +/* XPM */ +static char *a[] = { +/* columns rows colors chars-per-pixel */ +"15 32 3 1", +" c #00", +". c #00", +"X c None", +/* pixels */ +"XX...XX", +"X.X", +"..XXX.X", +"..XX..X", +"..X", +"XXX..XX", +"XXX..XX", +"XXX..XX", +"XXX..XX", +"XXX..XX", +"XXX..XX", +"XXX..XX", +"XXX..XX", +"XX..XXX", +"XX..XXX", +"XX..XXX", +"XX..XXX", +"XX..XXX", +"XX..XXX", +"XX..XXX", +"XX..XXX", +"X..", +"X..XX..", +"X.XXX..", +"X.X", +"XX...XX", +"XXX", +".X.X.X.", +"XXX", +".X.", +"XXX", +".X.X.X.", +}; Index: lib/images/math/oint.xpm === --- lib/images/math/oint.xpm (Revision 14921) +++ lib/images/math/oint.xpm (Arbeitskopie) @@ -1,35 +1,35 @@ /* XPM */ static char *a[] = { /* columns rows colors chars-per-pixel */ -"13 26 3 1", +"15 26 3 1", " c #00", ". c #00", "X c None", /* pixels */ -"X...X", -".", -"XXX..XXX.", -"XXX..XX..", -"XXX..", -"XX..X", -"XX..X", -"XX..X", -"XX..X", -".", -"XX...XXXX", -"X..XXX..XX.XX", -"X..XXX..XX.XX", -"X..XX..XXX.XX", -"X...X..XXX.XX", -"XX.X..XXX", -"X", -"X..XX", -"X..XX", -"X..XX", -"X..XX", -"..XXX", -"..XX..XXX", -".XXX..XXX", -".", -"X...X" +"X...XXX", +".XX", +"XXX..XXX.XX", +"XXX..XX..XX", +"XXX..XX", +"XX..XXX", +"XX..XXX", +"XX..XXX", +"XX..XXX", +".XX", +"XX...XX", +"X..XXX..XX.", +"X..XXX..XX.", +"X..XX..XXX.", +"X...X..XXX.", +"XX.X..X", +"XXX", +"X..", +"X..", +"X..", +"X..", +"..XX.X.X.X.", +"..XX..X", +".XXX..XX.X.", +".XX", +"X....X.X.X." }; Index: lib/images/math/int.xpm === --- lib/images/math/int.xpm (Revision 14921) +++ lib/images/math/int.xpm (Arbeitskopie) @@ -1,48 +1,35 @@ /* XPM */ -static char const * const int_xpm[] = { -/* width height ncolors chars_per_pixel */ -"18 25 16 1", -/* colors */ -"O c None", +static char *a[] = { +/* columns rows colors chars-per-pixel */ +"17 26 3 1", " c #00", -". c #939393", -"X c #676767", -"o c #3B3B3B", -"+ c #CECECE", -"@ c #0F0F0F", -"# c #B0B0B0", -"$ c #A2A2A2", -"% c #848484", -"& c #767676", -"* c #585858", -"= c #4A4A4A", -"- c #2C2C2C", -"; c #1E1E1E", -": c #BFBFBF", +". c #00", +"X c None", /* pixels */ -"OO", -"OO", -"[EMAIL PROTECTED]", -"OOO=+O", -"OO#XOO", -"OO&%OO", -"OO=:OO", -"[EMAIL PROTECTED]", -"O#oOOO", -"O", -"O*", -"O;$OOO", -"+ +OOO", -"$;", -"X=",
Re: USE_CYGWIN_PACKAGING
On Wed, Sep 06, 2006 at 09:29:21PM -0500, Bo Peng wrote: > I plan to refine and apply the attached patch to 1.4.x. This patch > lets 'scons install' generate the right kind of cygwin binary package > (with /usr/doc/ ..., strip etc). To better reflect the uniqueness of > cygwin, I have added USE_CYGWIN_PACKAGING to src/support/package.C, > which basically says that cygwin has $HOME, and .exe suffix. > > JMarc, what do you think about this macro? It is nice to have but it > is not absolutely needed since I can walk around it in SConstruct. > Some autotools changes may be needed. IMO, USE_CYGWIN_PACKAGING is neither needed nor useful. You don't have to care about the .exe suffix, cygwin takes care of that and in a well thought manner. Every POSIX program that checks for its own name works when compiled on cygwin. No need to fiddle with .exe suffix. Please ;-) Cygwin is POSIX. -- Enrico
Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...
Lars Gullik Bjønnes wrote: > Peter Kümmel <[EMAIL PROTECTED]> writes: > > | Peter Kümmel wrote: > | > care about it. I just wanna see if it's possible to get Dlls without > | > huge changes. > | > | Maybe the design of lyx is s bad that it is not possible. ;) > > Works without change on linux... > Building a dll on windows is like linking with --no-undefined under linux. Try to link with this option then you will see how wired the dependencies are. -- Peter Kümmel
Re: generating project files with cmake
Georg Baum wrote: > Joost Verburg wrote: > >> Abdelrazak Younes wrote: Are there any tools available to locate it? >>> I've heard good things about valgrind. But it's linux only AFAIK. >> Does anyone know of such a tool for Windows? > > I once worked with purify, but that is some time ago. See > http://www-306.ibm.com/software/awdtools/purifyplus/ > This was very nice: http://www.glowcode.com/ > >> If we are going to switch, we should go for Enchant. This is a library >> that makes it is possible to support Aspell/Pspell, Ispell, HunSpell, >> MySpell, Uspell, Hspell and Mac OS X Applespell. > > That has been suggested already long time ago. I don't think that it would > be too difficult to add enchant as an additional spell checker, and if > everything works drop the other ones. > > > Georg > > -- Peter Kümmel
[PATCH] Inset dissolve cleanup
The following pair of patch implement inset-dissolve in what I believe to be a clean way. There is no code in insets directory (the disabling for tabular insets is done by testing "inset.nargs() == 1" instead). Please test. JMarc Index: src/insets/insettabular.C === --- src/insets/insettabular.C (revision 14921) +++ src/insets/insettabular.C (working copy) @@ -1045,28 +1045,6 @@ bool InsetTabular::getStatus(LCursor & c return true; } - case LFUN_INSET_DISSOLVE: { - status.enabled(false); - return true; - } - - // because of the dissolve handling in insettext: - case LFUN_CHAR_DELETE_FORWARD: - if (!cur.selection() && cur.depth() > 1 - && cur.pit() == cur.lastpit() - && cur.pos() == cur.lastpos()) { - status.enabled(false); - return true; - } - // Fall through - - case LFUN_CHAR_DELETE_BACKWARD: - if (cur.depth() > 1 && cur.pit() == 0 && cur.pos() == 0) { - status.enabled(false); - return true; - } - // Fall through - case LFUN_INSET_MODIFY: if (translate(cmd.getArg(0)) == TABULAR_CODE) { status.enabled(true); Index: src/insets/insettext.C === --- src/insets/insettext.C (revision 14921) +++ src/insets/insettext.C (working copy) @@ -268,47 +268,14 @@ void InsetText::doDispatch(LCursor & cur << " [ cmd.action = " << cmd.action << ']' << endl; setViewCache(()); - - switch (cmd.action) { - - case LFUN_CHAR_DELETE_FORWARD: { - if (!cur.selection() && cur.depth() > 1 - && cur.pit() == cur.lastpit() - && cur.pos() == cur.lastpos()) - // Merge inset with owner - cmd = FuncRequest(LFUN_INSET_DISSOLVE); - text_.dispatch(cur, cmd); - break; - } - - case LFUN_CHAR_DELETE_BACKWARD: { - if (cur.depth() > 1 && cur.pit() == 0 && cur.pos() == 0) - // Merge inset with owner - cmd = FuncRequest(LFUN_INSET_DISSOLVE); - text_.dispatch(cur, cmd); - break; - } - - default: - text_.dispatch(cur, cmd); - break; - } + text_.dispatch(cur, cmd); } bool InsetText::getStatus(LCursor & cur, FuncRequest const & cmd, FuncStatus & status) const { - switch (cmd.action) { - - case LFUN_CHAR_DELETE_FORWARD: - case LFUN_CHAR_DELETE_BACKWARD: - status.enabled(true); - return true; - - default: - return text_.getStatus(cur, cmd, status); - } + return text_.getStatus(cur, cmd, status); } Index: src/lyxtext.h === --- src/lyxtext.h (revision 14921) +++ src/lyxtext.h (working copy) @@ -232,6 +232,8 @@ public: bool backspacePos0(LCursor & cur); /// Delete character before cursor. Honour CT bool backspace(LCursor & cur); + // Dissolve the inset under cursor + bool dissolveInset(LCursor & cur); /// bool selectWordWhenUnderCursor(LCursor & cur, lyx::word_location); /// Index: src/text3.C === --- src/text3.C (revision 14921) +++ src/text3.C (working copy) @@ -79,7 +79,6 @@ using lyx::pos_type; using lyx::cap::copySelection; using lyx::cap::cutSelection; -using lyx::cap::pasteParagraphList; using lyx::cap::pasteSelection; using lyx::cap::replaceSelection; @@ -709,34 +708,9 @@ void LyXText::dispatch(LCursor & cur, Fu break; } - case LFUN_INSET_DISSOLVE: { - recordUndoInset(cur); - cur.selHandle(false); - // save position - lyx::pos_type spos = cur.pos(); - lyx::pit_type spit = cur.pit(); - ParagraphList plist; - if (cur.lastpit() != 0 || cur.lastpos() != 0) - plist = paragraphs(); - cur.popLeft(); - // store cursor offset - if (spit == 0) - spos += cur.pos(); - spit += cur.pit(); - cur.paragraph().erase(cur.pos()); - if (!plist.empty()) { - Buffer * b = bv->buffer(); - pasteParagraphList(cur, plist, b->params().textclass, - b->errorList("Paste")); - // restore position - cur.pit() = std::min(cur.lastpit(), spit); - cur.pos() = std::min(cur.lastpos(), spos); - } - cur.clearSelection(); - cur.resetAnchor(); - needsUpdate = true; + case LFUN_INSET_DISSOLVE: + needsUpdate = dissolveInset(cur); break; - } case LFUN_INSET_SETTINGS: cur.inset().showInsetDialog(bv); @@ -1720,20 +1694,17 @@ bool LyXText::getStatus(LCursor & cur, F enable = lyx::cap::numberOfSelections() > 0; break; - case LFUN_PARAGRAPH_MOVE_UP: { + case LFUN_PARAGRAPH_MOVE_UP: enable = cur.pit() > 0 && !cur.selection(); break; - } - case LFUN_PARAGRAPH_MOVE_DOWN: { + case LFUN_PARAGRAPH_MOVE_DOWN: enable = cur.pit() < cur.lastpit() && !cur.selection(); break; - } - case LFUN_INSET_DISSOLVE: { - enable = !isMainText() && cur.inTexted(); + case LFUN_INSET_DISSOLVE: + enable = !isMainText() && cur.inset().nargs() == 1; break; - } case LFUN_WORD_DELETE_FORWARD: case LFUN_WORD_DELETE_BACKWARD: Index: src/text.C === --- src/text.C (revision 14921) +++ src/text.C (working
Re: Towards LyX 1.4.3 [status update #1]
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> Jean-Marc Lasgouttes wrote: >> 2698 add buttons for \intop and \ointop to math panel >> >> Georg, did you have time to look at the icons? Otherwise, we shall >> postpone. Georg> Now I looked at it. This patch adds the icons from Uwe. OK to Georg> go in? Sure. JMarc
Re: Active table and math toolbar
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> On Wed, Sep 06, 2006 at 11:01:41PM +0200, Michael Gerz wrote: >> I think this patch (or a similar one) has been discussed already. >> Should I commit it? John> This is a really difficult one to decide. I can see this being John> enormously irritating default behaviour for some people, and we John> don't yet have a View->Toolbars that can easily turn it off. On John> the other hand, these toolbars are extremely useful. What about a new 'Allow automatic toolbars' lyxrc entry? Then we could set the default to 'true'. Or to 'false' :) JMarc
[PATCH] bug 2600: Change tracking and tables hangs or asserts
The following patches fix a crash: http://bugzilla.lyx.org/show_bug.cgi?id=2600 The problem was the assumption that the LyXText of the cursor is the same as the LyXText of cursor.selBegin. I think there are still problems with CT and tables, but I propose to apply at least this one. I think that the rest of the problem would be fixed by a proper fix to bug 2510. JMarc Index: src/BufferView_pimpl.C === --- src/BufferView_pimpl.C (revision 14926) +++ src/BufferView_pimpl.C (working copy) @@ -749,17 +749,11 @@ bool BufferView::Pimpl::available() cons Change const BufferView::Pimpl::getCurrentChange() { - if (!buffer_->params().tracking_changes) + if (!buffer_->params().tracking_changes || !cursor_.selection()) return Change(Change::UNCHANGED); - LyXText * text = bv_->getLyXText(); - LCursor & cur = cursor_; - - if (!cur.selection()) - return Change(Change::UNCHANGED); - - return text->getPar(cur.selBegin().pit()). - lookupChangeFull(cur.selBegin().pos()); + DocIterator dit = cursor_.selectionBegin(); + return dit.paragraph().lookupChangeFull(dit.pos()); } Index: src/BufferView_pimpl.C === --- src/BufferView_pimpl.C (revision 14924) +++ src/BufferView_pimpl.C (working copy) @@ -586,17 +586,11 @@ bool BufferView::Pimpl::available() cons Change const BufferView::Pimpl::getCurrentChange() { - if (!buffer_->params().tracking_changes) + if (!buffer_->params().tracking_changes || !cursor_.selection()) return Change(Change::UNCHANGED); - LyXText * text = bv_->getLyXText(); - LCursor & cur = cursor_; - - if (!cur.selection()) - return Change(Change::UNCHANGED); - - return text->getPar(cur.selBegin().pit()). - lookupChange(cur.selBegin().pos()); + DocIterator dit = cursor_.selectionBegin(); + return dit.paragraph().lookupChange(dit.pos()); }
Re: Towards LyX 1.4.3 [status update #1]
On Fri, Aug 25, 2006 at 05:05:04PM +0200, Jean-Marc Lasgouttes wrote: > > We have come a long way towards 1.4.3, so now is the time to think > about a release. I will be in vacation again next week, so the date > should be some time at the beginning of September. Please JMarc, could the attached patch be applied to 1.4.x? It is about small fixes for the cygwin target: - Cygwin does not have locale support, so the warning about "Locale xx_XX could not be set" is bogus. - Some unnecessary path conversions are avoided. - When the fronted is Qt3/X11, it is not necessary that external_path and external_path_list return a windows style path. Thanks in advance. -- Enrico Index: src/ChangeLog === --- src/ChangeLog (revision 14926) +++ src/ChangeLog (working copy) @@ -1,3 +1,8 @@ +1006-09-07 Enrico Forestieri <[EMAIL PROTECTED]> + + * messages.C (Messages::get): don't warn about locale on cygwin + as it is not supported. + 2006-08-19 Jean-Marc Lasgouttes <[EMAIL PROTECTED]> * BufferView_pimpl.C (focusChange): new method; updates the Index: src/support/ChangeLog === --- src/support/ChangeLog (revision 14926) +++ src/support/ChangeLog (working copy) @@ -1,3 +1,11 @@ +2006-09-07 Enrico Forestieri <[EMAIL PROTECTED]> + * os_cygwin.C (is_windows_path): avoid unnecessary conversion + when path is relative + (convert_path_list): avoid unnecessary conversion when path + list is empty + (external_path, external_path_list): for an X11 build it is not + necessary that the output path style is windows + 2006-06-27 Enrico Forestieri <[EMAIL PROTECTED]> * os.h: rename cygwin_path_fix as windows_style_tex_paths. Index: src/support/os_cygwin.C === --- src/support/os_cygwin.C (revision 14926) +++ src/support/os_cygwin.C (working copy) @@ -55,8 +55,7 @@ bool is_posix_path(string const & p) bool is_windows_path(string const & p) { - return p.empty() || - (!contains(p, '\\') && (p.length() <= 1 || p[1] == ':')); + return p.empty() || (!contains(p, '\\') && p[0] != '/'); } @@ -87,6 +86,9 @@ string convert_path(string const & p, Pa string convert_path_list(string const & p, PathStyle const & target) { + if (p.empty()) + return p; + char const * const pc = p.c_str(); PathStyle const actual = cygwin_posix_path_list_p(pc) ? posix : windows; @@ -186,7 +188,11 @@ string::size_type common_path(string con string external_path(string const & p) { +#ifdef X_DISPLAY_MISSING return convert_path(p, PathStyle(windows)); +#else + return convert_path(p, PathStyle(posix)); +#endif } @@ -198,7 +204,11 @@ string internal_path(string const & p) string external_path_list(string const & p) { +#ifdef X_DISPLAY_MISSING return convert_path_list(p, PathStyle(windows)); +#else + return convert_path_list(p, PathStyle(posix)); +#endif } Index: src/messages.C === --- src/messages.C (revision 14926) +++ src/messages.C (working copy) @@ -126,10 +126,10 @@ public: #endif // setlocale fails (returns NULL) if the corresponding locale // is not installed. - // On windows (mingw) it always returns NULL. + // On windows (mingw and cygwin) it always returns NULL. // Since this method gets called for every translatable // buffer string like e.g. "Figure:" we warn only once. -#ifndef _WIN32 +#if !defined(_WIN32) && !defined(__CYGWIN__) static bool warned = false; if (!warned && !lc_msgs) { warned = true;
Re: inset-dissolve
Michael Gerz wrote: Hi Jürgen, inset-dissolve is still broken: If you open a new document, the function is enabled (which wrong) as you can see in the menu. If you want to dissolve the non-existent inset nevertheless, LyX crashes. But this is correct behaviour! You dissolve the empty document - lyx indeed goes away! ;-) Helge Hafting
Re: Towards LyX 1.4.3 [status update #1]
On Mon, 2006-09-04 at 11:08 +0200, Juergen Spitzmueller wrote: > Jean-Marc Lasgouttes wrote: > > My question now is whether to put this in 1.4.3 or 1.4.4. I tend to think > > it will be 1.4.4, but I am not fixed on that. > > I tend to think so, too, for testing reasons. Let's put the patch in soon > after 1.4.3 is released, so that people who use 1.4svn for daily work (like > me) can text it under real life conditions before releasing. > > Jürgen I second that. Thanks for the offer :-) - Martin signature.asc Description: This is a digitally signed message part
fs_extras compile fails (errno not declared in this scope)
if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./.. -I../../boost -Wextra -Wall-I/usr/X11R6/include -O2 -MT fs_extras.lo -MD -MP -MF ".deps/fs_extras.Tpo" -c -o fs_extras.lo fs_extras.C; \ then mv -f ".deps/fs_extras.Tpo" ".deps/fs_extras.Plo"; else rm -f ".deps/fs_extras.Tpo"; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./.. -I../../boost -Wextra -Wall -I/usr/X11R6/include -O2 -MT fs_extras.lo -MD -MP -MF .deps/fs_extras.Tpo -c fs_extras.C -o fs_extras.o fs_extras.C: In function 'void boost::filesystem::copy_file(const boost::filesystem::path&, const boost::filesystem::path&, bool)': fs_extras.C:101: error: 'errno' was not declared in this scope fs_extras.C:107: error: 'errno' was not declared in this scope fs_extras.C:120: error: 'errno' was not declared in this scope fs_extras.C:148: error: 'errno' was not declared in this scope make[6]: *** [fs_extras.lo] Error 1 make[6]: Leaving directory `/home/kayvan/rpmbuild/BUILD/lyx-1.5.0svn/src/support' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/home/kayvan/rpmbuild/BUILD/lyx-1.5.0svn/src/support' make[4]: *** [all] Error 2 make[4]: Leaving directory `/home/kayvan/rpmbuild/BUILD/lyx-1.5.0svn/src/support' -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan, | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | my beautiful Queen.| Robin Gregory (2/28/92) pgpmq69amdoxc.pgp Description: PGP signature
Re: Towards LyX 1.4.3 [status update #1]
Jean-Marc Lasgouttes wrote: > 2660 patch german userguide broken > > What remains to be done is copy the icons and update Makefile.am. > Please, someone... I just did that (and found two more invalid image paths). We need some lint for .lyx files. Georg
Re: fs_extras compile fails (errno not declared in this scope)
Kayvan A. Sylvan wrote: > fs_extras.C:101: error: 'errno' was not declared in this scope > fs_extras.C:107: error: 'errno' was not declared in this scope > fs_extras.C:120: error: 'errno' was not declared in this scope > fs_extras.C:148: error: 'errno' was not declared in this scope make[6]: This is fixed now. errno.h was not included. Georg
Re: fs_extras compile fails (errno not declared in this scope)
Georg Baum <[EMAIL PROTECTED]> writes: | Kayvan A. Sylvan wrote: | | > fs_extras.C:101: error: 'errno' was not declared in this scope | > fs_extras.C:107: error: 'errno' was not declared in this scope | > fs_extras.C:120: error: 'errno' was not declared in this scope | > fs_extras.C:148: error: 'errno' was not declared in this scope make[6]: | | This is fixed now. errno.h was not included. and should not be included ... we want -- Lgb
Re: USE_CYGWIN_PACKAGING
IMO, USE_CYGWIN_PACKAGING is neither needed nor useful. You don't have In the patch, I use packaging_method == 'cygwin' to install files as instructed by cygwin-packaging standard. I can use platform == 'cygwin' but the former seems to be more logical. Also, it might not be at all useful, but the packaging option (both autotools and scons) allows us to make packages cross-platformly. Bo
Re: Towards LyX 1.4.3 [status update #1]
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> Jean-Marc Lasgouttes wrote: >> 2660 patch german userguide broken >> >> What remains to be done is copy the icons and update Makefile.am. >> Please, someone... Georg> I just did that (and found two more invalid image paths). We Georg> need some lint for .lyx files. Thanks a lot! JMarc
Re: fs_extras compile fails (errno not declared in this scope)
Lars Gullik Bjønnes wrote: > and should not be included ... we want Why? I don't know any advantage, only a disadvantage: Some compilers do not have it. Georg
Re: please complete short "Questionnaire for Developers" (part of a user interface study)
Daryl Hepting wrote: Lyx Developer Questionnaire This questionnaire will be used by students of the CS305 course at the University of Regina to inform their semester’s work. Results of this work will be contributed back to the lyx project. All replies sent to me directly ([EMAIL PROTECTED]) will have all identifying information removed before anyone else sees them. This course project study has been approved by the Research Ethics Board at the University of Regina ([EMAIL PROTECTED]). If any publication follows the semester’s work, your replies will not be directly quoted and your responses will not be identifiable. [If you would like to be identified and associated with your comments, please indicate that to me in your reply.] Your completion (and return) of this questionnaire implies your consent for the uses stated above. Why did you choose to become involved with the lyx project? I wanted to learn Qt and contribute something to LyX. Porting LyX from Qt3 to Qt4 seemed to be an easy enough task. I didn't know at the time how much time this project will suck in my life... How would you describe the vision for the lyx project, and why? The best portable document writing tool ever. For whom is lyx intended? Hopefully to anybody willing to spend half a day reading the Tutorial. It's the optimal tool for Scientists and I've heard for Linguists too. Are there any comments you’d like to share about your experience with the lyx project? Come on-board, plenty of things to do here! Abdel.
Re: Towards LyX 1.4.3 [status update #1]
On Thursday 07 September 2006 13:50, Georg Baum wrote: > I just did that (and found two more invalid image paths). We need some lint > for .lyx files. It is on my todo list, FWIW. :-) > Georg -- José Abílio
Re: please complete short "Questionnaire for Developers" (part of a user interface study)
Why did you choose to become involved with the lyx project? I like lyx, I was between jobs, and I find that it is easier to contribute than arguing in the mailing list and waiting for months (years?) for a feature to be implemented. How would you describe the vision for the lyx project, and why? The best tool for tech writing. For whom is lyx intended? People who have higher standard for the look of their article (book etc), need to write lots of formula, willing to learn a bit latex and read some tutorials about lyx. Bo
Re: fs_extras compile fails (errno not declared in this scope)
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> Lars Gullik Bjønnes wrote: >> and should not be included ... we want Georg> Why? I don't know any advantage, only a disadvantage: Some Georg> compilers do not have it. I think all compilers have it now. JMarc
Re: fs_extras compile fails (errno not declared in this scope)
Jean-Marc Lasgouttes wrote: >> "Georg" == Georg Baum >> <[EMAIL PROTECTED]> >> writes: > > Georg> Lars Gullik Bjønnes wrote: >>> and should not be included ... we want > > Georg> Why? I don't know any advantage, only a disadvantage: Some > Georg> compilers do not have it. > > I think all compilers have it now. OK I changed it, but I am still curious to hear why cerrno is better. Georg
Re: Shared Libraries
On Thu, Sep 07, 2006 at 09:39:13AM +0200, Abdelrazak Younes wrote: > >Shouldn't there be a lyxkernel.dll and the frontend using this? > > The frontend virtual interface yes. The qt4 frontend will just be an > implementation of this interface and could entirely be in a single dll. > This way the lyx-executable would not even have to link to Qt4, only the > qt4 frontend dll. I am not sure there needs to be a virtual frontend interface at all. In theory, ther kernel could be completely ignorant of any frontend and just signal internal changes. A frontend would directly call into the kernel to make things happen and adjust afterwards by listening to the signals. IMO a common frontend base is a design mistake that puts things downside up: The kernel tells the frontend to draw and listen to events from the frontend. No good. Andre'
Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...
On Thu, Sep 07, 2006 at 11:29:05AM +0200, Peter Kümmel wrote: > Lars Gullik Bjønnes wrote: > > Peter Kümmel <[EMAIL PROTECTED]> writes: > > > > | Peter Kümmel wrote: > > | > care about it. I just wanna see if it's possible to get Dlls without > > | > huge changes. > > | > > | Maybe the design of lyx is s bad that it is not possible. ;) > > > > Works without change on linux... > > > > Building a dll on windows is like linking > with --no-undefined under linux. --no-undefined plus -Bsymbolic plus explicit symbol export plus separate heaps plus some 'minor' details. Andre'
Re: Shared Libraries
On Thu, Sep 07, 2006 at 09:41:55AM +0200, Abdelrazak Younes wrote: > >Mathed depends on the core _and_ on the painert stuff, so how could that > >be a good candidate to start with? > > This was just a guess as the mathed code seems pretty isolated from the > rest of the LyX code. As you said in an earlier mail, the painter stuff > needs to be rethought. Mathed is indeed pretty isolated in the sense that even largish internal changes do not affect the rest much. However, it is not easily separable into a self-contained library. Andre'
Re: Shared Libraries
On Wed, Sep 06, 2006 at 08:49:35PM +0200, Peter Kümmel wrote: > > The problem with the current architecture is, of, course, that drawing > > is 'pushed' by the kernel, not 'pulled' by the frontend (containing th > > painter) > > Yes, building insets is completely hopeless. And this artifact was > nicely hidden by the gcc. > Why has lyx not a mvc design where the model nothing knows about > the view but its base class? Because LyX architecture is ten years old and mvc wasn't exactly hyped at this time? Andre'
Re: Shared Libraries
On Thu, Sep 07, 2006 at 09:30:18AM +0200, Abdelrazak Younes wrote: > Andre Poenitz wrote: > >On Tue, Sep 05, 2006 at 11:16:14AM +0200, Peter Kümmel wrote: > >>I have started with frontend/qt4/ but give up because qt4 needs several > >>functions from the other libs. > >>We must start at the bottom not at the top, and qt4 is at the top. > > > >Exactly. > > > >The problem with the current architecture is, of, course, that drawing > >is 'pushed' by the kernel, not 'pulled' by the frontend (containing th > >painter) > > The plan is of course to change that. Of course. Last time I tried it I got stuck somewhere between updateInsetInInset and tabulators in MathParInset... Andre'
Re: Active table and math toolbar
Jean-Marc Lasgouttes schrieb: John> This is a really difficult one to decide. I can see this being John> enormously irritating default behaviour for some people, and we John> don't yet have a View->Toolbars that can easily turn it off. On John> the other hand, these toolbars are extremely useful. What about a new 'Allow automatic toolbars' lyxrc entry? Then we could set the default to 'true'. Or to 'false' :) In that case, the current UI file design does not make sense any longer. Anyway, there are at least three people among us who would like to see a short-term solution. See http://bugzilla.lyx.org/show_bug.cgi?id=2813 Why don't we activate the toolbars for now (and for 1.4.3)? The activation is not a showstopper in case someone wants to optimize the look & feel later. Michael
Re: [PATCH] Re-introduce layout menu
John Levon schrieb: What would be REALLY cool is some actual UI testing in a proper lab infrastructure. But slightly cool would be something that collected real-life data on menu use, and allowed us to collect it (modulo privacy concerns etc.) Asking a self-selecting population is notoriously tricky for getting meaningful answers. How about my recent Character Style patch? Is this something in the spirit of your GUI design (most important things first etc.)? Michael
Re: [PATCH] Inset dissolve cleanup
Jean-Marc Lasgouttes schrieb: The following pair of patch implement inset-dissolve in what I believe to be a clean way. There is no code in insets directory (the disabling for tabular insets is done by testing "inset.nargs() == 1" instead). Please test. inset-dissolve works for 1.5.0, even with nested insets! (I am not able to test 1.4.X right now) Just one cosmetic issue: If you want to undo inset-dissolve, you have to press CTRL-Z twice. This might be a bit disturbing for some users. Michael
Re: [PATCH] Re-introduce layout menu
On Wed, Sep 06, 2006 at 11:29:58PM +0200, Michael Gerz wrote: > John, JMarc, > > what do you think about the patch below? The idea is to have a submenu > for character styles that combines layout-specific char styles, > bold/emphasize/noun style, and the font dialog. The layout-specific char > styles have been moved from menu "Insert". Although the styles are > actually implemented as insets, the user does not think in terms of > "inserting" something. Bold/emphasize/noun style - whether you like it > or not - are frequently requested features. There is at least one > bugzilla report for re-adding "bold" to the menu. The font dialog is > listed at the end ("Other...") because users should not be encouraged to > use it often. Regarding the word-* functions: We might move them to the > submenu as well to shorten the "Edit" menu (as done in the patch). > However, after testing "word-capitalize", I really doubt that this > particular functions is very useful (why do we have it at all?). > > Any comments? > > Michael This looks very nice to me. - Martin > Index: stdmenus.ui > === > --- stdmenus.ui(revision 14919) > +++ stdmenus.ui(working copy) > @@ -89,14 +89,10 @@ > Separator > Item "Find & Replace...|F" "dialog-show findreplace" > Separator > -Item "Word in Small Capitals" "word-capitalize" > -Item "Word in Uppercase" "word-upcase" > -Item "Word in Lowercase" "word-lowcase" > -Separator > Item "Move Paragraph Up|o" "paragraph-move-up" > Item "Move Paragraph Down|v" "paragraph-move-down" > Separator > -Item "Text Style...|S" "dialog-show character" > +Submenu "Character Style...|C" "insert_charstyles" > Item "Paragraph Settings...|P" "layout-paragraph" > Separator > # Mathed b0rkage means these don't work properly > @@ -136,6 +132,19 @@ > PasteRecent > End > > +Menu "insert_charstyles" > +CharStyles > +Separator > +Item "Emphasize Style|E" "font-emph" > +Item "Noun Style|N" "font-noun" > +Item "Bold Style|B" "font-bold" > +Separator > +Item "Other...|O" "dialog-show character" > +Separator > +Item "Uppercase" "word-upcase" > +Item "Lowercase" "word-lowcase" > +End > + > # not much we can do to help here > Menu "edit_tabular" > Item "Multicolumn|M" "tabular-feature multicolumn" > @@ -253,7 +262,6 @@ > # YUCK > Submenu "Note|N" "insert_note" > OptSubmenu "Branch|B" "insert_branches" > -OptSubmenu "Character Style|y" "insert_charstyles" > Submenu "File|e" "insert_file" > Item "Box" "box-insert Frameless" > Separator > @@ -377,10 +385,6 @@ > Branches > End > > -Menu "insert_charstyles" > -CharStyles > -End > - > # > # DOCUMENT MENU > # > pgpH4y6x618o6.pgp Description: PGP signature
Re: USE_CYGWIN_PACKAGING
On 9/7/06, Bo Peng <[EMAIL PROTECTED]> wrote: > IMO, USE_CYGWIN_PACKAGING is neither needed nor useful. You don't have Hi, Enrico, Could you please apply the attached patch, install scons-local, run python scons.py -f development/scons/SConstruct DESTDIR=cygwin_test mode=release install and check if the files are correctly installed as described in http://cygwin.com/setup.html ? I have also attached the required setup.hint. Bo Index: development/scons/SConstruct === --- development/scons/SConstruct (revision 14932) +++ development/scons/SConstruct (working copy) @@ -54,6 +54,7 @@ # some global settings # package_version = '1.4.3svn' +package_cygwin_version = '1.4.3svn-1' boost_version = '1_32' devel_version = True @@ -397,14 +398,14 @@ share_dir = 'Resources' man_dir = 'Resources/man/man1' locale_dir = 'Resources/locale' -default_prefix = 'c:/program files/lyx' else: share_dir = 'share/lyx' -man_dir = 'man/man1' locale_dir = 'share/locale' -default_prefix = '/usr/local/' +if platform_name == 'cygwin': +man_dir = 'share/man/man1' +else: +man_dir = 'man/man1' -# install to default_prefix by default # program suffix: can be yes, or a string if env.has_key('version_suffix'): if env['version_suffix'] in true_strings: @@ -792,6 +793,14 @@ else: env['MSGFMT'] = env_cache['MSGFMT'] +# cygwin packaging requires the binaries to be stripped +if platform_name == 'cygwin': +if not fast_start: +env['STRIP'] = conf.CheckCommand('strip') +env_cache['STRIP'] = env['STRIP'] +else: +env['STRIP'] = env_cache['STRIP'] + # check uic and moc commands for qt frontends if not fast_start: if frontend[:2] == 'qt' and (conf.CheckCommand('uic') == None \ @@ -1331,7 +1340,7 @@ # for details # if platform_name == 'cygwin': -ld_script_path = '/usr/lib/qt3/mkspecs/cygwin-g++' +ld_script_path = '/tmp' ld_script = utils.installCygwinLDScript(ld_script_path) env.AppendUnique(LINKFLAGS = ['-Wl,--enable-runtime-pseudo-reloc', '-Wl,--script,%s' % ld_script, '-Wl,-s']) @@ -2008,23 +2017,21 @@ else: version_suffix = '' # -# install lyx -target_name = os.path.split(str(lyx[0]))[1].replace('lyx', 'lyx%s' % version_suffix) -target = os.path.join(bin_dest_dir, target_name) -env.InstallAs(target, lyx) -Alias('install', target) -# -# install tex2lyx -target_name = os.path.split(str(tex2lyx[0]))[1].replace('tex2lyx', 'tex2lyx%s' % version_suffix) -target = os.path.join(bin_dest_dir, target_name) -env.InstallAs(target, tex2lyx) -Alias('install', target) -# -# install lyxclient, may not exist -if client != None: -target_name = os.path.split(str(client[0]))[1].replace('client', 'client%s' % version_suffix) +# install lyx, if in release mode, try to strip the binary +if env.has_key('STRIP') and env['STRIP'] is not None and mode != 'debug': +# create a builder to strip and install +env['BUILDERS']['StripInstallAs'] = Builder(action='$STRIP $SOURCE -o $TARGET') + +# install executables +for (name, obj) in (('lyx', lyx), ('tex2lyx', tex2lyx), ('client', client)): +if obj is None: +continue +target_name = os.path.split(str(obj[0]))[1].replace(name, '%s%s' % (name, version_suffix)) target = os.path.join(bin_dest_dir, target_name) -env.InstallAs(target, client) +if env['BUILDERS'].has_key('StripInstallAs'): +env.StripInstallAs(target, obj) +else: +env.InstallAs(target, obj) Alias('install', target) # # share/lyx @@ -2046,14 +2053,27 @@ ('lyx2lyx', lib_lyx2lyx_files)]: dirs.append(env.Install(os.path.join(share_dest_dir, dir), [env.subst('$TOP_SRCDIR/lib/%s/%s' % (dir, file)) for file in files])) +Alias('install', dirs) +if platform_name == 'cygwin': +# cygwin packaging requires a file /usr/share/doc/Cygwin/foot-vendor-suffix.README +Cygwin_README = os.path.join(dest_prefix_dir, 'doc', 'Cygwin', +'%s%s.README' % (package, package_cygwin_version)) +env.InstallAs(Cygwin_README, +os.path.join(env.subst('$TOP_SRCDIR'), 'README.cygwin')) +Alias('install', Cygwin_README) +# also a directory /usr/share/doc/lyx for README etc +Cygwin_Doc = os.path.join(dest_prefix_dir, 'doc', package) +env.Install(Cygwin_Doc, [os.path.join(env.subst('$TOP_SRCDIR'), x) for x in \ +['INSTALL', 'README', 'README.Cygwin', 'RELEASE-NOTES', 'COPYING', 'ANNOUNCE']]) +Alias('install', Cygwin_Doc) + # lyx1.4.x does not have lyx2lyx_version.py.in if os.path.isfile(env.subst('$TOP_SRCDIR/lib/lyx2lyx/lyx2lyx_version.py.in')): # subst and install this file env.substFile(share_dest_dir +
Re: [PATCH] Inset dissolve cleanup
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes: Michael> Just one cosmetic issue: If you want to undo inset-dissolve, Michael> you have to press CTRL-Z twice. This might be a bit Michael> disturbing for some users. I know that, but I have not been able to avoid it. It is because we use the cut and paste machinery, which does its own undo. I really think it should not, if this is possible. Thanks for testing. JMarc
Re: Shared Libraries
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> Because LyX architecture is ten years old and mvc wasn't Andre> exactly hyped at this time? Well, LyX is not older than smalltalk... JMarc
Re: [PATCH] Re-introduce layout menu
On Thu, Sep 07, 2006 at 09:07:17PM +0200, Michael Gerz wrote: > John Levon schrieb: > >What would be REALLY cool is some actual UI testing in a proper lab > >infrastructure. But slightly cool would be something that collected > >real-life data on menu use, and allowed us to collect it (modulo privacy > >concerns etc.) > > > >Asking a self-selecting population is notoriously tricky for getting > >meaningful answers. > > > How about my recent Character Style patch? Is this something in the > spirit of your GUI design (most important things first etc.)? I'm at a conference right now, I'll try and look tonight? john
Re: Active table and math toolbar
On Thu, Sep 07, 2006 at 08:54:38PM +0200, Michael Gerz wrote: > Why don't we activate the toolbars for now (and for 1.4.3)? The > activation is not a showstopper in case someone wants to optimize the > look & feel later. Let's activate it for 1.5.0svn and see what happens, but not 1.4... regards john
Re: USE_CYGWIN_PACKAGING
On Thu, Sep 07, 2006 at 03:02:59PM -0500, Bo Peng wrote: > On 9/7/06, Bo Peng <[EMAIL PROTECTED]> wrote: > >> IMO, USE_CYGWIN_PACKAGING is neither needed nor useful. You don't have > > Hi, Enrico, > > Could you please apply the attached patch, install scons-local, run > > python scons.py -f development/scons/SConstruct DESTDIR=cygwin_test > mode=release install I had already installed scons, so I ran "scons -f ...", instead. I have not installed the boost libraries, so included boost was used. Scons detected that I have Aiksaurus and compilation went smooth till the final link stage which however failed as follows: g++ -o release/qt2/lyx.exe -Wl,--enable-runtime-pseudo-reloc -Wl,--script,/tmp/i386pe.x-no-rdata -Wl,-s release/common/main.o -Lrelease/libs -L/usr/lib/qt3/lib -L/usr/X11R6/lib -llyxbase_pre -lmathed -linsets -lfrontends -lqt2 -lcontrollers -lgraphics -lsupport -llyxbase_post -lincluded_boost_signals -lincluded_boost_regex -lincluded_boost_filesystem -lqt-mt -lintl -lshlwapi -lstdc++ -lz -liconv -lgdi32 -lAiksaurus -laspell /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lAiksaurus collect2: ld returned 1 exit status scons: *** [release/qt2/lyx.exe] Error 1 scons: building terminated because of errors. After I added "extra_lib_path=/usr/local/lib" to the scons command line (libAiksaurus.dll.a is there) everything went fine till the end. > and check if the files are correctly installed as described in > http://cygwin.com/setup.html ? It seems ok to me. However, don't be afraid, they (cygwin-apps) will tell you if something needs to be tuned. > Index: README.Cygwin > === > --- README.Cygwin (revision 14932) > +++ README.Cygwin (working copy) > @@ -1,32 +1,44 @@ > LyX/Cygwin > +== > + > Ruurd Reitsma <[EMAIL PROTECTED]> > +Bo Peng> > -There are two ways to run LyX on Windows: > -* as a native Windows application, using the Qt/Win Free clone of > - Trolltech's cross-platform Qt toolkit. > -* as a POSIX application running under the Cygwin environment. > > This README describes what is needed for the latter of these two > options. Please refer to README.Win32 if you'd like to run LyX > as a native Windows application. Maybe the previous last three lines should be deleted, too? > + > +Hide the cygwin console > +=== > + > If you want to run LyX with no console windows open, there's a small > program in development/Win32 that will set the proper environment vars > and start LyX. I am afraid both lyxwin32.c and lyxprofile are not in development/Win32 anymore... I am attaching here a small script which will help you spotting dependencies. Launching it with a directory name as an argument (chkdep dir), it will scan that directory for executables and libraries and tells you the names of the packages containing the needed dynamic libraries. I also suggest that you apply this patch for the cygwin distribution: http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg100129.html (in case JMarc does not agree to apply it to 1.4.x) as you are allowed to apply local patches to the upstream sources. -- Enrico #!/bin/sh find $1 -name '*.exe' -o -name '*.dll' -o -name '*.bin' | \xargs cygcheck | \ sed -e '/\.exe/d' -e 's,\\,/,g' | sort -bu | \ xargs -n1 cygpath -u | xargs cygcheck -f | uniq
Re: USE_CYGWIN_PACKAGING
I have not installed the boost libraries, so included boost was used. Even if you have installed boost, the included boost will be used after a version check. Scons detected that I have Aiksaurus and compilation went smooth till the final link stage which however failed as follows: After I added "extra_lib_path=/usr/local/lib" to the scons command line (libAiksaurus.dll.a is there) everything went fine till the end. This is something need to be fixed. I will have a look. scan that directory for executables and libraries and tells you the names of the packages containing the needed dynamic libraries. I will do this within SConstruct. I also suggest that you apply this patch for the cygwin distribution: This patch should be applied. I have seen it twice but JMarc somehow missed them. Thanks. Bo
Hebrew Translation
hi, I would like to help with the hebrew translation of the LyX documentation. I contacted Tzafrir Cohen (which is listed as the contact for hebrew) but he told me that he doesn't activly maintain the hebrew translation. As there is no active contact for hebrew translation i don't know how can i help with the translation. I would thank you if you could explain to me how can i send new translation for the documentation and if I can be the hebrew tranlation contact man. Best Regards, Guy Rutenberg