Re: MSVC/CMAke: Cannot build BRANCH_1_5_X
Peter Kümmel wrote: Abdelrazak Younes wrote: I get this with -Dnls=0 or 1, -Dmerge=0 or 1: intl.lib(dcigettext.obj) : error LNK2019: unresolved external symbol __nl_language_preferences_default referenced in function _guess_category_value D:\devel\lyx\BRANCH_1_5_X\development\cmake\bin\Debug\lyx-qt4.exe : fatal error LNK1120: 1 unresolved externals Any idea Peter? Abdel. Still ideas needed? If you haven't change anything, yes. The included intl is compiled in by default right? Maybe I have to update some of my GunWin32 libraries... Abdel.
Re: Opinion on the embedding of zip/unzip in lyx using zlib/contrib/minizip.
Bo Peng wrote: I am not quite sure if this is a good idea so any comment is welcome. A library based solution is probably more robust than one based on external programs. I agree. It is not easy to adapt minizip but this makes distributing lyx a lot easier, compared to the gunzip solution. What is the problem with th zlib solution? Abdel.
Re: r19666 - in /lyx-devel/branches/BRANCH_1_5_X: src/insets/...
Bo Peng wrote: URL: http://www.lyx.org/trac/changeset/19666 Log: Fix crash when a user removes a formula when its preview is being generated. (Another signal/destructor/gcc3 bug) This is another signal/destructor/gcc3 bug: when a formula is created, and is removed before its preview is generated, the imageReady signal will crash lyx when the preview is generated because it can not reach the removed inset. You still don't think my systematic strategy is not worth it? I am 100% sure that you or any other user will see more of these in *released* version. ;-P Abdel.
Re: [patch] simplify setinsetfont
Alfredo Braunstein wrote: Better using CursorSlices when possible. Makes sense. Abdel.
Re: [Updated PATCH] BufferView/WorkArea/LyXView reorg a.k.a Multiple WorkAreas
Abdelrazak Younes wrote: Abdelrazak Younes wrote: Abdelrazak Younes wrote: Here is my most recent patch. What is not working yet: - the close tab button: it is implemented but does not show up. - the splash screen: it is implemented but does not show up. I solved the splash screen bug Here is a patch with this fix against latest trunk. Updated and committed. Abdel.
Re: merged cells handling in tabular code
any thoughs on this one? Edwin Leuven wrote: at the moment we store line attributes in the cell *and* in the column and row info. i am tempted to remove them from the column and row info because i do not see what extra info they give on top of the cell attributes am i overseeing something?
Re: Opinion on the embedding of zip/unzip in lyx using zlib/contrib/minizip.
Bo Peng wrote: Dear list, Because I get no objection to the design of the embedding feature of lyx, I plan to add it to the trunk in the next few weeks. There is, however, a big question on how to zip and unzip files. There is a unzipFile function in src/support/filetools.cpp which calls 'gunzip -c'. I am not sure how lyx distributes gunzip and I doubt if it works under windows. gzip is the standard on unix - any machine capable of running LyX is extremely likely to have gzip/gunzip/zlib already. (And if not, getting gzip is easier than installing LyX anyway.) Any distro that package LyX can simply add a dependency in their package management system. I believe zip is more common on windows, but you can't depend on it being present there. A unix machine doesn't necessarily have zip. If a minimal amount of stuff to distribute is a goal, then gzip/zlib seems the way to go: It is likely there on unix, and on windows you have to distribute software no matter what compression you choose. Supporting both is also an option - depending on what compression sw the user have. Of course we don't need more than one compression scheme for LyX own sake. So this would be for those who find it useful to occationally unpack a compressed LyX file manually. Helge Hafting
Re: Opinion on the embedding of zip/unzip in lyx using zlib/contrib/minizip.
Bo Peng wrote: Dear list, Because I get no objection to the design of the embedding feature of lyx, I plan to add it to the trunk in the next few weeks. There is, however, a big question on how to zip and unzip files. There is a unzipFile function in src/support/filetools.cpp which calls 'gunzip -c'. I am not sure how lyx distributes gunzip and I doubt if it works under windows. but gzip/gunzip doesn't do archiving, just deflates single files, doesn't it? IUC you need archiving also. But maybe I don't understand the problem well ;-) A/
Re: [Patch - 1.5] fix bug 4123: crash when closing LyX window with document tabs
Abdelrazak Younes wrote: http://bugzilla.lyx.org/show_bug.cgi?id=4123 This fix is already in trunk. This is the patch for 1.5. Who decides now that Juergen and JMarc are off? As there's apparently nobody, I took the liberty to commit it. Abdel.
Re: [PATCH - 1.5] Fix bug 4117: Crash when using down cursor in an empty math subscript
Abdelrazak Younes wrote: http://bugzilla.lyx.org/show_bug.cgi?id=4117 I took the liberty to commit that one too. Abdel.
Re: Further inset configurability
Richard Heck wrote: Martin Vermeer wrote: On Sat, Aug 18, 2007 at 02:40:27PM -0400, Richard Heck wrote: This looks reasonable to me, though I haven't tested it. (I'm still obsessing over BibTeX stuff.) One suggestion: I think CharStyles should by default have an unobtrusive presentation, NOT with the label showing. OK, I did that. Even better would be a layout parameter specifying the default, as I remember you had. In XML, we use charstyles as 'short elements' and then we do want to see the labels by default. Yes, that would be even better. The default presentation now (or previously?) gets particularly ugly if you try to nest them. Making them nest nicely is critical, it seems to me, to any attempt to replace the Text Settings dialog with CharStyles, which we are pretty much on the verge of doing now. (I think it's really just the menu that needs sorting out for that, as we'd need too many CharStyles to just list them all.) I would already be happy to replace Noun and Emph. But apparently you are also thinking of replacing all font attributes? I would be unhappy with that. There was a huge discussion on the list sone years ago when I introduced the charstyle inset. You see, in the LyX philosophy you want to support lgical character styles, not visual editing (finger painting). This means that all charstyles should represent some meaning -- the name of a person, emphasising, 'strong' (like in HTML). Perhaps this topic should be re-opened. There was some discussion about it just a few weeks back, and my sense was that Jurgen had been intending to do something along these lines. The discussion began because I made the same suggestion independently. The motivation, in my case, anyway, is that the Text Settings dialog is so broken that I don't know it can be fixed. (See the many bugs collected under 3893.) The truth is that, whatever LyX's own philosophy, people do use that dialog. So I suggested that it should be demolished. That said, one wouldn't have to have the finger painting styles appear with the logic character styles on the menu. They could appear elsewhere, perhaps with a stern warning that they are not to be used. ;-) I see nothing wrong in replacing other text settings with charstyles, as long as: * Existing much-used styles, such as emphasize and foreign language are preserved. They must be as easy to use as before. (i.e. emphasize may very well become a generic charstyle defined in a stdcharstyle.inc , but there should still be that userfriendly emphasize button on the toolbar. * Styles that have a visual representation (emphasize, colors, bold, underline, font change, . . . should still be rendered as well as they are today - i.e. use italics for emph, colors for colors, and so on instead of framed insets. Extraneous frames really break up the text. * Today I can mark and emphasize the first 3/4 of a sentence, then mark and color red the last 3/4 - and the middle 1/2 will then be both red and emph. This way of working should work in the future too - even if partial overlap don't fit a nesting model. One solution is to create two red insets behind the scenes. As for loosing the Text settings with their finger-painting opportunities, here is an idea: Get rid of it. The user now have nowhere to go to set Huge text or similiar. All that remains is the few charstyles developers decide is important enough to be distributed with LyX. Emph would be one such style, and perhaps a few more. I'd like languages (and the no-spellcheck language) to be available too. To avoid murder by users who want Huge etc., there must be a way of defining new charstyles. Document-specific or user-specific. (A user-specific style will be saved in the document just like a document-specific style, so that the documents can be exchanged. But it is also saved in the preferences so it is always available for the user.) When creating a new charstyle, you give it a name and pick all attributes to go with it. It might set visual stuff like color font, and/or language. It might even apply a latex command or environment, for the experts. Now the user can create a ReallyEmphasize style using Huge if he wants to. Latex import and old documents containing Text settings can be handled by auto-creating document-specific styles with the same name as the markup used. So users who really want to can still fingerpaint, but since they now have to create a style anyway, they might as well do it properly as that is no more work than just applying font settings. Helge Hafting
[patch for [Bug 1656] command gnome-session-save kills lyx!]
Hi Richard,
you moved the target milestone of bug 1656 to 1.5.x. Now I had the time
and energy to check my proposal to fix the bug again. I modified the
code to fit the new 1.5.x code base. My tests with OpenSuSE 10.2 and Qt
4.1.2 went well. The program isn't exiting prematurely anymore and in
case of unsaved changes the user is asked for proper action just like on
quit of LyX.
The idea was: the default session save action of Qt is to send an close
event to all windows (in method commitData()). I replaced it by an call
to theBufferList().quitWriteAll(). This didn't work with older Qt
versions apparently. Now I have no problem with my current Qt 4.1.2 anymore.
The resulting patch is attached and in bugzilla too.
Regards,
Stephan
Original-Nachricht
Betreff: [Bug 1656] command gnome-session-save kills lyx!
Datum: Mon, 20 Aug 2007 13:38:44 +0200
Von: [EMAIL PROTECTED]
An: [EMAIL PROTECTED]
http://bugzilla.lyx.org/show_bug.cgi?id=1656
[EMAIL PROTECTED] changed:
What|Removed |Added
Attachment #728 is|0 |1
obsolete||
--- Additional Comments From [EMAIL PROTECTED] 2007-08-20
13:38 ---
Created an attachment (id=2110)
-- (http://bugzilla.lyx.org/attachment.cgi?id=2110action=view)
Updated patch for bad exit on gnome-session-save
I've updated my patch for 1.5.X and tested it with activated (comments
removed)
code.
The patch works with OpenSuSE 10.2 and Qt 4.1.2. Cannot test others
environments.
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
Index: src/frontends/qt4/GuiApplication.cpp
===
--- src/frontends/qt4/GuiApplication.cpp (Revision 19655)
+++ src/frontends/qt4/GuiApplication.cpp (Arbeitskopie)
@@ -28,6 +28,7 @@
#include support/Package.h
#include BufferView.h
+#include BufferList.h
#include Color.h
#include debug.h
#include FuncRequest.h
@@ -316,6 +317,22 @@
// X11 specific stuff goes here...
#ifdef Q_WS_X11
+
+void GuiApplication::commitData(QSessionManager sm)
+{
+ /// The implementation is required to avoid an application exit
+ /// when session state save is triggered by session manager.
+ /// The default implementation sends a close event to all
+ /// visible top level widgets when session managment allows
+ /// interaction.
+ /// We are changeing that to write all unsaved buffers...
+ if ( sm.allowsInteraction() ) {
+ if ( !theBufferList().quitWriteAll() ) {
+ sm.cancel();
+ }
+ }
+}
+
bool GuiApplication::x11EventFilter(XEvent * xev)
{
if (!currentView())
Index: src/frontends/qt4/GuiApplication.h
===
--- src/frontends/qt4/GuiApplication.h (Revision 19655)
+++ src/frontends/qt4/GuiApplication.h (Arbeitskopie)
@@ -25,6 +25,7 @@
#include QApplication
#include QTranslator
+#include QSessionManager
namespace lyx {
@@ -106,6 +107,7 @@
std::mapint, boost::shared_ptrsocket_callback socket_callbacks_;
#ifdef Q_WS_X11
+ void commitData(QSessionManager sm);
public:
bool x11EventFilter (XEvent * ev);
#endif
Re: Further inset configurability
On Tue, 21 Aug 2007 10:22:44 +0200 Helge Hafting [EMAIL PROTECTED] wrote: Richard Heck wrote: Martin Vermeer wrote: On Sat, Aug 18, 2007 at 02:40:27PM -0400, Richard Heck wrote: This looks reasonable to me, though I haven't tested it. (I'm still obsessing over BibTeX stuff.) One suggestion: I think CharStyles should by default have an unobtrusive presentation, NOT with the label showing. OK, I did that. Even better would be a layout parameter specifying the default, as I remember you had. In XML, we use charstyles as 'short elements' and then we do want to see the labels by default. Yes, that would be even better. The default presentation now (or previously?) gets particularly ugly if you try to nest them. Making them nest nicely is critical, it seems to me, to any attempt to replace the Text Settings dialog with CharStyles, which we are pretty much on the verge of doing now. (I think it's really just the menu that needs sorting out for that, as we'd need too many CharStyles to just list them all.) I would already be happy to replace Noun and Emph. But apparently you are also thinking of replacing all font attributes? I would be unhappy with that. There was a huge discussion on the list sone years ago when I introduced the charstyle inset. You see, in the LyX philosophy you want to support lgical character styles, not visual editing (finger painting). This means that all charstyles should represent some meaning -- the name of a person, emphasising, 'strong' (like in HTML). Perhaps this topic should be re-opened. There was some discussion about it just a few weeks back, and my sense was that Jurgen had been intending to do something along these lines. The discussion began because I made the same suggestion independently. The motivation, in my case, anyway, is that the Text Settings dialog is so broken that I don't know it can be fixed. (See the many bugs collected under 3893.) The truth is that, whatever LyX's own philosophy, people do use that dialog. So I suggested that it should be demolished. That said, one wouldn't have to have the finger painting styles appear with the logic character styles on the menu. They could appear elsewhere, perhaps with a stern warning that they are not to be used. ;-) I see nothing wrong in replacing other text settings with charstyles, as long as: * Existing much-used styles, such as emphasize and foreign language are preserved. They must be as easy to use as before. (i.e. emphasize may very well become a generic charstyle defined in a stdcharstyle.inc , but there should still be that userfriendly emphasize button on the toolbar. * Styles that have a visual representation (emphasize, colors, bold, underline, font change, . . . should still be rendered as well as they are today - i.e. use italics for emph, colors for colors, and so on instead of framed insets. Extraneous frames really break up the text. Yes... we need the three-box model. * Today I can mark and emphasize the first 3/4 of a sentence, then mark and color red the last 3/4 - and the middle 1/2 will then be both red and emph. This way of working should work in the future too - even if partial overlap don't fit a nesting model. One solution is to create two red insets behind the scenes. But this is fingerpainting... aka why the * would you want to do that? Remember semantics: a charstyle should _mean_ something. How often do you want to make two overlapping pieces of text stand out in two different ways? As for loosing the Text settings with their finger-painting opportunities, here is an idea: Get rid of it. The user now have nowhere to go to set Huge text or similiar. All that remains is the few charstyles developers decide is important enough to be distributed with LyX. Emph would be one such style, and perhaps a few more. I'd like languages (and the no-spellcheck language) to be available too. To avoid murder by users who want Huge etc., there must be a way of defining new charstyles. Document-specific or user-specific. (A user-specific style will be saved in the document just like a document-specific style, so that the documents can be exchanged. But it is also saved in the preferences so it is always available for the user.) When creating a new charstyle, you give it a name and pick all attributes to go with it. It might set visual stuff like color font, and/or language. It might even apply a latex command or environment, for the experts. Now the user can create a ReallyEmphasize style using Huge if he wants to. Latex import and old documents containing Text settings can be handled by auto-creating document-specific styles with the same name as the markup used. So users who really want to can still fingerpaint, but since they now have to create a style anyway, they might as well do it properly as that is
Re: merged cells handling in tabular code
Leuven, E. wrote: any thoughs on this one? Edwin Leuven wrote: at the moment we store line attributes in the cell *and* in the column and row info. i am tempted to remove them from the column and row info because i do not see what extra info they give on top of the cell attributes am i overseeing something? What happends when you insert a new row, does its cells inherit column/row attributes? This would make sense. OTOH, just copying the row above would make also sense. ;-) A/
RE: Re: merged cells handling in tabular code
Alfredo wrote: What happends when you insert a new row, does its cells inherit column/row attributes? inherit from ...? This would make sense. OTOH, just copying the row above would make also sense. ;-) personally i don't see why i would like a copy of a previous line or the line the cursor is in when i am inserting a row. but all this depends on what we decide and is orthogonal to the question whether we need separate row attributes for lines...
RE: Re: merged cells handling in tabular code
On 8/21/07, Leuven, E. [EMAIL PROTECTED] wrote: Alfredo wrote: What happends when you insert a new row, does its cells inherit column/row attributes? inherit from ...? From global (i.e. non-cell specific) column/row line attributes, what else. This would make sense. OTOH, just copying the row above would make also sense. ;-) personally i don't see why i would like a copy of a previous line or the line the cursor is in when i am inserting a row. I meant just to copy line attributes but all this depends on what we decide and is orthogonal to the question whether we need separate row attributes for lines... Not really, IIUC. But probably I didn't UC ;-) A/
Re: merged cells handling in tabular code
Edwin Leuven wrote: at the moment we store line attributes in the cell *and* in the column and row info. i am tempted to remove them from the column and row info because i do not see what extra info they give on top of the cell attributes am i overseeing something? I don't think so. In general the tabular code is far too close to LaTeX IMHO, and this is just one case where it shows. Another one is the single cell multicolumn problem: The fact that you need \multicolumn if you want to change the alignment or border of just one cell is a LaTeX implementation issue, and the user should not need to know that. LyX should create multicolumn cells automatically if needed. I believe that you can simplify the tabular code a lot if you go away from the LaTeX-centric view and implement a more general table model. All the special LaTeX stuff would then be concentrated in the LaTeX export methods. Of course it should still be possible to easily set/unset borders of whole rows/columns, but that is orthogonal to the way how the lines are stored. Georg
RE: Re: merged cells handling in tabular code
Georg Baum wrote: I don't think so. In general the tabular code is far too close to LaTeX IMHO, and this is just one case where it shows. i am glad you say so, it is exactly the feeling i have after staring at the code for some time now... Another one is the single cell multicolumn problem: The fact that you need \multicolumn if you want to change the alignment or border of just one cell is a LaTeX implementation issue, and the user should not need to know that. LyX should create multicolumn cells automatically if needed. and what about tricks like setting multicolumn on single cells to circumvene decimal alignment by dcolumn? I believe that you can simplify the tabular code a lot if you go away from the LaTeX-centric view and implement a more general table model. All the special LaTeX stuff would then be concentrated in the LaTeX export methods. ok (but perhaps some latex tricks are then no longer feasible?) Of course it should still be possible to easily set/unset borders of whole rows/columns, but that is orthogonal to the way how the lines are stored. yes, we should make it easy to select complete rows/columns after whcih we can apply our methods on the cell range...
RE: Re: merged cells handling in tabular code
Leuven, E. wrote: Georg Baum wrote: Another one is the single cell multicolumn problem: The fact that you need \multicolumn if you want to change the alignment or border of just one cell is a LaTeX implementation issue, and the user should not need to know that. LyX should create multicolumn cells automatically if needed. and what about tricks like setting multicolumn on single cells to circumvene decimal alignment by dcolumn? It should of course be possible to set a 1-cell multicolumn explicitly if that is needed, because you can never imagine all the tricks that users might need. But this is expert usage, normally you should not need to think about it. I believe that you can simplify the tabular code a lot if you go away from the LaTeX-centric view and implement a more general table model. All the special LaTeX stuff would then be concentrated in the LaTeX export methods. ok (but perhaps some latex tricks are then no longer feasible?) What do you have in mind? This should of course be avoided, but I don't see how a more general table model in LyX would create problems with LaTeX tricks. Of course it should still be possible to easily set/unset borders of whole rows/columns, but that is orthogonal to the way how the lines are stored. yes, we should make it easy to select complete rows/columns after whcih we can apply our methods on the cell range... Exactly. This works partially already. Georg
Re: merged cells handling in tabular code
Leuven, E. wrote: Georg Baum wrote: I don't think so. In general the tabular code is far too close to LaTeX IMHO, and this is just one case where it shows. i am glad you say so, it is exactly the feeling i have after staring at the code for some time now... Also, I think there's a lot of code sharing that can be done between math tables and tabular. See our discussion about cell access methods to Inset earlier last week (with JMarc and Alfredo). Abdel.
Re: Opinion on the embedding of zip/unzip in lyx using zlib/contrib/minizip.
I agree. It is not easy to adapt minizip but this makes distributing lyx a lot easier, compared to the gunzip solution. What is the problem with th zlib solution? I am using zlib. minizip uses zlib to implement a minizip, minunz commands. Bo
Re: Opinion on the embedding of zip/unzip in lyx using zlib/contrib/minizip.
gzip is easier than installing LyX anyway.) Any distro that package LyX can simply add a dependency in their package management system. Then we also need tar. I believe zip is more common on windows, but you can't depend on it being present there. A unix machine doesn't necessarily have zip. You are right. If a minimal amount of stuff to distribute is a goal, then gzip/zlib seems the way to go: It is likely there on unix, and on windows you have to distribute software no matter what compression you choose. lyx already requires zlib, what I am adding is an implementation of zip/unzip capacity using zlib. Supporting both is also an option - depending on what compression sw the user have. Of course we don't need more than one compression scheme for LyX own sake. So this would be for those who find it useful to occationally unpack a compressed LyX file manually. That is too complicated, because handling tar is really troublesome under windows. Bo
Re: merged cells handling in tabular code
Leuven, E. wrote: Georg Baum wrote: I don't think so. In general the tabular code is far too close to LaTeX IMHO, and this is just one case where it shows. i am glad you say so, it is exactly the feeling i have after staring at the code for some time now... Another idea would be to encapsulate QTableView for our needs. Each cell would then contain a InsetText encapsulated in a QVariant. Each cell would use a GuiWorkArea in order to show itself. Should be straight forward to implement IMHO, QTableView has everything you need I think. Abdel.
Re: Opinion on the embedding of zip/unzip in lyx using zlib/contrib/minizip.
but gzip/gunzip doesn't do archiving, just deflates single files, doesn't it? IUC you need archiving also. But maybe I don't understand the problem well ;-) I need file structure inside the zip file to store all embedded files. gzip can not be used because I do not want to handle tar. Because we already requires zlib, the zip format is easier to use. Cheers, Bo
Re: Opinion on the embedding of zip/unzip in lyx using zlib/contrib/minizip.
Bo Peng wrote: I agree. It is not easy to adapt minizip but this makes distributing lyx a lot easier, compared to the gunzip solution. What is the problem with th zlib solution? I am using zlib. minizip uses zlib to implement a minizip, minunz commands. Ah, good. I thought you were borrowing source code from zlib. Abdel.
RE: Re: merged cells handling in tabular code
Also, I think there's a lot of code sharing that can be done between math tables and tabular. See our discussion about cell access methods to Inset earlier last week (with JMarc and Alfredo). let' s worry about that later (when the tabular code is cleaner)
Re: [PATCH] Embedding feature patch 1: add zipFiles and unzipToDir to support.
I am also wondering if we can add zip/contrib/minizip (four source files) to lyx/svn to make our life a bit easier. How about adding these four minizip files to src/support/minizip? Bo
Re: [PATCH] Embedding feature patch 1: add zipFiles and unzipToDir to support.
Bo Peng wrote: I am also wondering if we can add zip/contrib/minizip (four source files) to lyx/svn to make our life a bit easier. How about adding these four minizip files to src/support/minizip? That seems the logical thing to do. Abdel.
Re: Opinion on the embedding of zip/unzip in lyx using zlib/contrib/minizip.
Bo Peng wrote: gzip is easier than installing LyX anyway.) Any distro that package LyX can simply add a dependency in their package management system. Then we also need tar. I believe zip is more common on windows, but you can't depend on it being present there. A unix machine doesn't necessarily have zip. You are right. If a minimal amount of stuff to distribute is a goal, then gzip/zlib seems the way to go: It is likely there on unix, and on windows you have to distribute software no matter what compression you choose. lyx already requires zlib, what I am adding is an implementation of zip/unzip capacity using zlib. Supporting both is also an option - depending on what compression sw the user have. Of course we don't need more than one compression scheme for LyX own sake. So this would be for those who find it useful to occationally unpack a compressed LyX file manually. That is too complicated, because handling tar is really troublesome under windows. Seems like zlib definitely is the way to go then - nothing extra to distribute. :-) Those wishing to unpack manually can always get zip. Helge Hafting
Re: Re: merged cells handling in tabular code
On Tue, 21 Aug 2007 15:21:13 +0200 Leuven, E. [EMAIL PROTECTED] wrote: Also, I think there's a lot of code sharing that can be done between math tables and tabular. See our discussion about cell access methods to Inset earlier last week (with JMarc and Alfredo). let' s worry about that later (when the tabular code is cleaner) Sure, but keep it in mind to avoid double work. - Martin
Re: Further inset configurability
Martin Vermeer wrote: On Tue, 21 Aug 2007 10:22:44 +0200 Helge Hafting [EMAIL PROTECTED] wrote: Richard Heck wrote: Martin Vermeer wrote: On Sat, Aug 18, 2007 at 02:40:27PM -0400, Richard Heck wrote: This looks reasonable to me, though I haven't tested it. (I'm still obsessing over BibTeX stuff.) One suggestion: I think CharStyles should by default have an unobtrusive presentation, NOT with the label showing. OK, I did that. Even better would be a layout parameter specifying the default, as I remember you had. In XML, we use charstyles as 'short elements' and then we do want to see the labels by default. Yes, that would be even better. The default presentation now (or previously?) gets particularly ugly if you try to nest them. Making them nest nicely is critical, it seems to me, to any attempt to replace the Text Settings dialog with CharStyles, which we are pretty much on the verge of doing now. (I think it's really just the menu that needs sorting out for that, as we'd need too many CharStyles to just list them all.) I would already be happy to replace Noun and Emph. But apparently you are also thinking of replacing all font attributes? I would be unhappy with that. There was a huge discussion on the list sone years ago when I introduced the charstyle inset. You see, in the LyX philosophy you want to support lgical character styles, not visual editing (finger painting). This means that all charstyles should represent some meaning -- the name of a person, emphasising, 'strong' (like in HTML). Perhaps this topic should be re-opened. There was some discussion about it just a few weeks back, and my sense was that Jurgen had been intending to do something along these lines. The discussion began because I made the same suggestion independently. The motivation, in my case, anyway, is that the Text Settings dialog is so broken that I don't know it can be fixed. (See the many bugs collected under 3893.) The truth is that, whatever LyX's own philosophy, people do use that dialog. So I suggested that it should be demolished. That said, one wouldn't have to have the finger painting styles appear with the logic character styles on the menu. They could appear elsewhere, perhaps with a stern warning that they are not to be used. ;-) I see nothing wrong in replacing other text settings with charstyles, as long as: * Existing much-used styles, such as emphasize and foreign language are preserved. They must be as easy to use as before. (i.e. emphasize may very well become a generic charstyle defined in a stdcharstyle.inc , but there should still be that userfriendly emphasize button on the toolbar. * Styles that have a visual representation (emphasize, colors, bold, underline, font change, . . . should still be rendered as well as they are today - i.e. use italics for emph, colors for colors, and so on instead of framed insets. Extraneous frames really break up the text. Yes... we need the three-box model. Being early in development I don't really see a problem with a charstyle transition before 3-box drawing. I was actually thinking more about the problem of having lots of boxes on the screen. Not having a box for every emph is necessary, even if the line breaking still suffer some. * Today I can mark and emphasize the first 3/4 of a sentence, then mark and color red the last 3/4 - and the middle 1/2 will then be both red and emph. This way of working should work in the future too - even if partial overlap don't fit a nesting model. One solution is to create two red insets behind the scenes. But this is fingerpainting... aka why the * would you want to do that? Remember semantics: a charstyle should _mean_ something. How often do you want to make two overlapping pieces of text stand out in two different ways? Two levels of emphasizing happens sometimes, just as two levels of quotation. I can definitely see this happening if language becomes an inset too. But this issue wasn't much of a problem, applying a style on top of partially overlapping stuff is easily solved by breaking the last style up into several insets in the code. The user won't have to know. Please don't create an artifical limitation out of this. Some styles of writing are more colorful than a scientific article. :-) Perhaps my example was dumb, I just wanted to give an example. I think this can happen with styles that mean something too. Helge Hafting
RE: Re: merged cells handling in tabular code
Martin wrote: Sure, but keep it in mind to avoid double work. cleaning up of the tabular code has to be done anyway and i have troubles enough to wrap my head around this tabular stuff crashing on me sigh
Re: [PATCH] Embedding feature patch 1: add zipFiles and unzipToDir to support.
That seems the logical thing to do. Done. Bo
Minizip is added to src/support/minizip, please add the files to autotools/cmake.
Adding src/support/minizip Adding src/support/minizip/crypt.h Adding src/support/minizip/ioapi.c Adding src/support/minizip/ioapi.h Adding src/support/minizip/iowin32.c Adding src/support/minizip/iowin32.h Adding src/support/minizip/unzip.c Adding src/support/minizip/unzip.h Adding src/support/minizip/zip.c Adding src/support/minizip/zip.h src/support/minizip/*.c is needed to build src/support now (iowin32.c is only needed for win32). Please adjust autotools and cmake accordingly. I am testing scons under windows. Cheers, Bo
Re: r19666 - in /lyx-devel/branches/BRANCH_1_5_X: src/insets/...
You still don't think my systematic strategy is not worth it? I am 100% sure that you or any other user will see more of these in *released* version. I knew what you would say about this patch. :-) I am using lyx-1.5svn every day so I will catch such bugs and fix them trivially. I am too lazy to do a systematic survey of this issue. Cheers, Bo
Re: r19659 - /lyx-devel/trunk/src/frontends/qt4/ui/CitationUi.ui
On Tue, Aug 21, 2007 at 07:37:25AM +0200, Peter Kümmel wrote: Enrico Forestieri wrote: On Mon, Aug 20, 2007 at 07:44:32PM +0200, Peter Kümmel wrote: LyX 1.5 is released now, why not drop the requirement Qt = 4.1? This is becoming tedious. Any bells and whistles may be added through conditional compilation without the need for bumping the requirements. So, if you like candies, you can use the latest versions, and if you like efficiency, you are not forced to use them simply for the flashing lights. Then, you cannot pretend that anyone should install a new version because of an unessential feature. I just wanna see who objects first ;) Please, be serious. Qt 4.1.5 was released no more than ten months ago. -- Enrico
Slow down and speed up after copy and paste.
Just to report, as far as I remember, a known problem. Moving with arrow keys (also typing) can suddently become very slow. However, if I select, copy and paste, lyx will speed up a lot. Interesting. Bo
Re: r19659 - /lyx-devel/trunk/src/frontends/qt4/ui/CitationUi.ui
Enrico Forestieri wrote: On Tue, Aug 21, 2007 at 07:37:25AM +0200, Peter Kümmel wrote: Enrico Forestieri wrote: On Mon, Aug 20, 2007 at 07:44:32PM +0200, Peter Kümmel wrote: LyX 1.5 is released now, why not drop the requirement Qt = 4.1? This is becoming tedious. Any bells and whistles may be added through conditional compilation without the need for bumping the requirements. So, if you like candies, you can use the latest versions, and if you like efficiency, you are not forced to use them simply for the flashing lights. Then, you cannot pretend that anyone should install a new version because of an unessential feature. I just wanna see who objects first ;) Please, be serious. Qt 4.1.5 was released no more than ten months ago. Still, I'd be curious to see how many people on X11 use Qt4.1... I bet not a lot. All the predicted integration problem did not really happened AFAICS. FWIW, I don't really care about the bells and whistles, there are enough of them to use even in Qt 4.0. But I do care about conditional compilations to avoid bugs in Qt 4.1. I also do care about code simplification that would results in a switch to 4.2 (I'm thinking about Edwin's toolbar widget for example). Abdel. PS: Qt 4.1.5 was released October 20, 2006. But Qt 3.3.8 was released February, 14 2007. Yet we don't use it ;-)
Re: Slow down and speed up after copy and paste.
Bo Peng wrote: Just to report, as far as I remember, a known problem. I believe there's a bugzilla item from Darren Freeman. He was the only one with these symptoms AFAIK, up until now. Moving with arrow keys (also typing) can suddently How sudden? Can't you derive a test case from it? become very slow. However, if I select, copy and paste, lyx will speed up a lot. Does window resizing help the same? Abdel.
Re: Slow down and speed up after copy and paste.
Moving with arrow keys (also typing) can suddently How sudden? Can't you derive a test case from it? I can not reproduce it reliably. I am still trying. become very slow. However, if I select, copy and paste, lyx will speed up a lot. Does window resizing help the same? I will try when I see this next time. Bo
Re: [Updated PATCH] BufferView/WorkArea/LyXView reorg a.k.a Multiple WorkAreas
On Tue, Aug 21, 2007 at 09:36:35AM +0200, Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Here is my most recent patch. What is not working yet:
- the close tab button: it is implemented but does not show up.
- the splash screen: it is implemented but does not show up.
I solved the splash screen bug
Here is a patch with this fix against latest trunk.
Updated and committed.
Nuisance:
- Even with only one file opened, a toolbar with a tab appears.
Problems:
- The main window bar does not show the filename of a loaded file.
However, after opening another file, the name shows up.
- The list of recently opened files is not updated.
Crash:
When loading the attached file, the cursor is not visible and the text
is out of view. No scrollbar is present, but if you click in the window,
the view is adjusted (and the scrollbar appears). However, if you don't
click in the window and instead try to roll the mouse wheel in an attempt
to scroll the view, lyx crashes:
$ ./src/lyx.exe
stack widget!
Assertion triggered in int lyx::Text::leftMargin(const lyx::Buffer, int,
lyx::pit_type, lyx::pos_type) const by failing check pit = 0 in file
../../src/Text.cpp:375
Abort (core dumped)
--
Enrico
#LyX 1.4.4 created this file. For more info see http://www.lyx.org/
\lyxformat 245
\begin_document
\begin_header
\textclass article
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\papersize default
\use_geometry false
\use_amsmath 1
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\end_header
\begin_body
\begin_layout Standard
\begin_inset Formula $A\overset{S_{1}}{\underset{S_{2}}{\gtrless}}B$
\end_inset
\end_layout
\end_body
\end_document
Re: r19659 - /lyx-devel/trunk/src/frontends/qt4/ui/CitationUi.ui
On Tue, Aug 21, 2007 at 03:18:15AM +0200, Enrico Forestieri wrote: On Tue, Aug 21, 2007 at 02:29:00AM +0200, Andre Poenitz wrote: On Tue, Aug 21, 2007 at 01:10:29AM +0200, Enrico Forestieri wrote: Note that it is much simpler and faster building Qt4 from sources than it is building LyX. I have 4.1.5, 4.2.3, and 4.3.1 installed and I configure LyX for each version through a script without any hassle. And that's with more than one million lines in Qt *.cpp, and just 148000 in LyX. It is really a shame. Yes, it is quite strange, but with LyX I simply do configure; make; make install whereas with Qt I have to write down qmake.conf and qplatformdefs.h (and I should know what to put there) if my platform is not directly supported. That's a one-time effort, requires you to copy two files with 250 lines and adjust maybe 10 of them. The price for not doing that is n-times increased compile and link times for _everybody_ for _every_ build. PS: Wonder why? autotools? You can't eat your cake and have it ;-) That's not about pure compilation. This is about having unnecessary abstraction layers _and_ choosing regularily the most expensive method of abstraction. Andre'
Re: r19659 - /lyx-devel/trunk/src/frontends/qt4/ui/CitationUi.ui
On Tue, Aug 21, 2007 at 06:31:33PM +0200, Abdelrazak Younes wrote: Enrico Forestieri wrote: On Tue, Aug 21, 2007 at 07:37:25AM +0200, Peter Kümmel wrote: Enrico Forestieri wrote: On Mon, Aug 20, 2007 at 07:44:32PM +0200, Peter Kümmel wrote: LyX 1.5 is released now, why not drop the requirement Qt = 4.1? This is becoming tedious. Any bells and whistles may be added through conditional compilation without the need for bumping the requirements. So, if you like candies, you can use the latest versions, and if you like efficiency, you are not forced to use them simply for the flashing lights. Then, you cannot pretend that anyone should install a new version because of an unessential feature. I just wanna see who objects first ;) Please, be serious. Qt 4.1.5 was released no more than ten months ago. Still, I'd be curious to see how many people on X11 use Qt4.1... I bet not a lot. All the predicted integration problem did not really happened AFAICS. There have been already complaints for the dismission of the Qt3 frontend by the FreeBSD people. There are other systems in the world other than Windows and Linux. FWIW, I don't really care about the bells and whistles, there are enough of them to use even in Qt 4.0. But I do care about conditional compilations to avoid bugs in Qt 4.1. I also do care about code simplification that would results in a switch to 4.2 (I'm thinking about Edwin's toolbar widget for example). Then go ahead and require a Qt snapshot such that you can have more fun and less problems. PS: Qt 4.1.5 was released October 20, 2006. But Qt 3.3.8 was released February, 14 2007. Yet we don't use it ;-) And that is a real shame. -- Enrico
Re: merged cells handling in tabular code
On Tue, Aug 21, 2007 at 09:40:49AM +0200, Leuven, E. wrote: any thoughs on this one? Edwin Leuven wrote: at the moment we store line attributes in the cell *and* in the column and row info. i am tempted to remove them from the column and row info because i do not see what extra info they give on top of the cell attributes am i overseeing something? Well, it's modeled after what LaTeX does. There might be lines spanning the whole row, and there might be small lines on certain cells. Of course, implementation does not follow this model internally as long as such output is accepted, output and round-trip safe to the degree it currently is. Andre'
Re: [patch for [Bug 1656] command gnome-session-save kills lyx!]
On Tue, Aug 21, 2007 at 10:31:57AM +0200, Stephan Witt wrote:
// X11 specific stuff goes here...
#ifdef Q_WS_X11
+
+void GuiApplication::commitData(QSessionManager sm)
+{
+ /// The implementation is required to avoid an application exit
+ /// when session state save is triggered by session manager.
+ /// The default implementation sends a close event to all
+ /// visible top level widgets when session managment allows
+ /// interaction.
+ /// We are changeing that to write all unsaved buffers...
+ if ( sm.allowsInteraction() ) {
+ if ( !theBufferList().quitWriteAll() ) {
Spacing.
Andre'
Re: [Cvslog] r19687 - /lyx-devel/trunk/po/fi.po
[EMAIL PROTECTED] schrieb: Author: vermeer Date: Tue Aug 21 09:57:11 2007 New Revision: 19687 URL: http://www.lyx.org/trac/changeset/19687 Log: some work on fi.po Is this also relevant for the stable branch? I think it doesn't make sense to work on the trunk at this point in time. In the past, we copied the po files from the stable branch to the trunk once the branch has stabilized. Michael
Re: [PATCH] Embedding feature patch 1: add zipFiles and unzipToDir to support.
On Tue, Aug 21, 2007 at 08:27:39AM -0500, Bo Peng wrote: I am also wondering if we can add zip/contrib/minizip (four source files) to lyx/svn to make our life a bit easier. How about adding these four minizip files to src/support/minizip? Do that. But also adjust code style. Andre'
Re: [Cvslog] r19687 - /lyx-devel/trunk/po/fi.po
On Tue, Aug 21, 2007 at 08:09:10PM +0200, Michael Gerz wrote: [EMAIL PROTECTED] schrieb: Author: vermeer Date: Tue Aug 21 09:57:11 2007 New Revision: 19687 URL: http://www.lyx.org/trac/changeset/19687 Log: some work on fi.po Is this also relevant for the stable branch? I think it doesn't make sense to work on the trunk at this point in time. In the past, we copied the po files from the stable branch to the trunk once the branch has stabilized. Michael I'm not sure. By the time I am finished with this at this rate, trunk will be the stable branch ;-( - Martin
Re: r19659 - /lyx-devel/trunk/src/frontends/qt4/ui/CitationUi.ui
On Tue, Aug 21, 2007 at 07:56:36PM +0200, Andre Poenitz wrote: On Tue, Aug 21, 2007 at 03:18:15AM +0200, Enrico Forestieri wrote: On Tue, Aug 21, 2007 at 02:29:00AM +0200, Andre Poenitz wrote: On Tue, Aug 21, 2007 at 01:10:29AM +0200, Enrico Forestieri wrote: Note that it is much simpler and faster building Qt4 from sources than it is building LyX. I have 4.1.5, 4.2.3, and 4.3.1 installed and I configure LyX for each version through a script without any hassle. And that's with more than one million lines in Qt *.cpp, and just 148000 in LyX. It is really a shame. Yes, it is quite strange, but with LyX I simply do configure; make; make install whereas with Qt I have to write down qmake.conf and qplatformdefs.h (and I should know what to put there) if my platform is not directly supported. That's a one-time effort, requires you to copy two files with 250 lines and adjust maybe 10 of them. I was also forgetting that you may need to patch *.pri files. Then the Qt build system doesn't let you perform out of tree builds (shadow builds in Qt parliance), even if Qt 4.3 is a big step forward in this respect. With a few patches in tools/configure and *.pri files, I was even able to perform a shadow mingw build. The price for not doing that is n-times increased compile and link times for _everybody_ for _every_ build. PS: Wonder why? autotools? You can't eat your cake and have it ;-) That's not about pure compilation. This is about having unnecessary abstraction layers _and_ choosing regularily the most expensive method of abstraction. There must be something wrong in the way we use autotools. I build many other programs using autotools but do not experience the same slowness as with lyx. But I would like to say that this is with non Linux platforms, as in that case I don't see a real problem. I really don't care when compilation takes 10 minutes instead of 12, but I am concerned when with scons I can compile in almost half the time. -- Enrico
Re: [Cvslog] r19687 - /lyx-devel/trunk/po/fi.po
On Tue, Aug 21, 2007 at 09:22:01PM +0300, Martin Vermeer wrote: On Tue, Aug 21, 2007 at 08:09:10PM +0200, Michael Gerz wrote: [EMAIL PROTECTED] schrieb: Author: vermeer Date: Tue Aug 21 09:57:11 2007 New Revision: 19687 URL: http://www.lyx.org/trac/changeset/19687 Log: some work on fi.po Is this also relevant for the stable branch? I think it doesn't make sense to work on the trunk at this point in time. In the past, we copied the po files from the stable branch to the trunk once the branch has stabilized. Michael I'm not sure. By the time I am finished with this at this rate, trunk will be the stable branch ;-( - Martin OK, seems that all the changes up till now go cleanly into branch. I'll just commit as I seem to be the only one working on this. - Martin
Re: r19659 - /lyx-devel/trunk/src/frontends/qt4/ui/CitationUi.ui
On Tue, Aug 21, 2007 at 05:59:33PM +0200, Enrico Forestieri wrote: On Tue, Aug 21, 2007 at 07:37:25AM +0200, Peter Kümmel wrote: Enrico Forestieri wrote: On Mon, Aug 20, 2007 at 07:44:32PM +0200, Peter Kümmel wrote: LyX 1.5 is released now, why not drop the requirement Qt = 4.1? This is becoming tedious. Any bells and whistles may be added through conditional compilation without the need for bumping the requirements. So, if you like candies, you can use the latest versions, and if you like efficiency, you are not forced to use them simply for the flashing lights. Then, you cannot pretend that anyone should install a new version because of an unessential feature. I just wanna see who objects first ;) Please, be serious. Qt 4.1.5 was released no more than ten months ago. And 3.3.8 was released six months ago. What are you trying to say here? The fact that older versions are maintained does not imply that using them for new development is a good idea. Not even remotely. What really makes me sick here is the application of double standards. For boost we require the newest and shiniest and to be reasonably able to use this we even include it in our sources! And if this results in brown-paper-bag releases as 1.5.0 was it's just considered 'business as usual'. On the other hand, for Qt we are not even allowed to use the _penultimate_ _released_ version. What crap is that? Andre'
Re: r19659 - /lyx-devel/trunk/src/frontends/qt4/ui/CitationUi.ui
On Tue, Aug 21, 2007 at 07:59:36PM +0200, Enrico Forestieri wrote: There have been already complaints for the dismission of the Qt3 frontend by the FreeBSD people. There are other systems in the world other than Windows and Linux. So they should f*** spend _their_ time on a Qt3 frontend but not mine. Being queer is surely nice and acceptable, but being queer _and blaming others for being less so_ is not. This, btw, holds true for Cygwin users, too. FWIW, I don't really care about the bells and whistles, there are enough of them to use even in Qt 4.0. But I do care about conditional compilations to avoid bugs in Qt 4.1. I also do care about code simplification that would results in a switch to 4.2 (I'm thinking about Edwin's toolbar widget for example). Then go ahead and require a Qt snapshot such that you can have more fun and less problems. PS: Qt 4.1.5 was released October 20, 2006. But Qt 3.3.8 was released February, 14 2007. Yet we don't use it ;-) And that is a real shame. This is ridiculous. Andre'
Re: r19659 - /lyx-devel/trunk/src/frontends/qt4/ui/CitationUi.ui
On Tue, Aug 21, 2007 at 08:26:47PM +0200, Andre Poenitz wrote: On Tue, Aug 21, 2007 at 05:59:33PM +0200, Enrico Forestieri wrote: On Tue, Aug 21, 2007 at 07:37:25AM +0200, Peter Kümmel wrote: Enrico Forestieri wrote: On Mon, Aug 20, 2007 at 07:44:32PM +0200, Peter Kümmel wrote: LyX 1.5 is released now, why not drop the requirement Qt = 4.1? This is becoming tedious. Any bells and whistles may be added through conditional compilation without the need for bumping the requirements. So, if you like candies, you can use the latest versions, and if you like efficiency, you are not forced to use them simply for the flashing lights. Then, you cannot pretend that anyone should install a new version because of an unessential feature. I just wanna see who objects first ;) Please, be serious. Qt 4.1.5 was released no more than ten months ago. And 3.3.8 was released six months ago. What are you trying to say here? The fact that older versions are maintained does not imply that using them for new development is a good idea. Not even remotely. This is you opinion, of course. What I can say is that Qt4 does not work well with solaris 10, for example. I don't get antialiased fonts and it is a real pain for reading. It is even worse than with the old Xforms frontend. On the contrary, Qt3 works perfectly well and I don't plan switching to lyx 1.5 on solaris until some OS upgrade brings me antialiased fonts back. I don't know what is the problem here, but I can't get antialiasing with Qt4 even after tampering with fontconfig. What really makes me sick here is the application of double standards. For boost we require the newest and shiniest and to be reasonably able to use this we even include it in our sources! And if this results in brown-paper-bag releases as 1.5.0 was it's just considered 'business as usual'. I don't want to argue with you here, because I more or less share your opinion, but at least boost is included and automatically used. On the other hand, for Qt we are not even allowed to use the _penultimate_ _released_ version. What crap is that? If a Qt3 frontend was provided, I will be using LyX 1.5 on solaris, as that is not the case, I will be still sticking with 1.4 for the time being. With that attitude you may scare away users of alternative systems, which often can't even have the third last released version. -- Enrico
Re: r19659 - /lyx-devel/trunk/src/frontends/qt4/ui/CitationUi.ui
On Tue, Aug 21, 2007 at 08:37:25PM +0200, Andre Poenitz wrote: On Tue, Aug 21, 2007 at 07:59:36PM +0200, Enrico Forestieri wrote: There have been already complaints for the dismission of the Qt3 frontend by the FreeBSD people. There are other systems in the world other than Windows and Linux. So they should f*** spend _their_ time on a Qt3 frontend but not mine. Being queer is surely nice and acceptable, but being queer _and blaming others for being less so_ is not. The Qt3 frontend was dismissed even if there were people willing to maintain it. This, btw, holds true for Cygwin users, too. I am a cygwin user, and for having the possibility of using a cygwin version of lyx, I had to make up myself as a developer. I simply don't have the time and the skill to maintain a Qt3 frontend, too. FWIW, I don't really care about the bells and whistles, there are enough of them to use even in Qt 4.0. But I do care about conditional compilations to avoid bugs in Qt 4.1. I also do care about code simplification that would results in a switch to 4.2 (I'm thinking about Edwin's toolbar widget for example). Then go ahead and require a Qt snapshot such that you can have more fun and less problems. PS: Qt 4.1.5 was released October 20, 2006. But Qt 3.3.8 was released February, 14 2007. Yet we don't use it ;-) And that is a real shame. This is ridiculous. Ipse dixit. -- Enrico
Compilation broken on Mac (current svn)
Attempting to compile on Mac gives me the following error. Any
suggestions?
Thanks.
Bennett
/bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -
I. -I../../src -I./.. -I../../boost -DQT_CLEAN_NAMESPACE -
DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -I/Users/bennett/lyx/
qt-4.3-install/include -I/Users/bennett/lyx/qt-4.3-install/include/
QtCore -Wextra -Wall -I/System/Library/Frameworks/
CoreFoundation.framework/Headers -g -Os -MT filetools.lo -MD -MP -
MF .deps/filetools.Tpo -c -o filetools.lo filetools.cpp
g++ -DHAVE_CONFIG_H -I. -I../../src -I./.. -I../../boost -
DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -I/
Users/bennett/lyx/qt-4.3-install/include -I/Users/bennett/lyx/qt-4.3-
install/include/QtCore -Wextra -Wall -I/System/Library/Frameworks/
CoreFoundation.framework/Headers -g -Os -MT filetools.lo -MD -MP -
MF .deps/filetools.Tpo -c filetools.cpp -o filetools.o
filetools.cpp:59:21: error: direct.h: No such file or directory
filetools.cpp:60:17: error: io.h: No such file or directory
filetools.cpp:63:17: error: zip.h: No such file or directory
filetools.cpp:64:19: error: unzip.h: No such file or directory
filetools.cpp:1343: error: 'uLong' does not name a type
filetools.cpp: In function 'bool lyx::support::zipFiles(const
lyx::support::DocFileName, const
__gnu_debug_def::vectorstd::pairstd::string, std::string,
std::allocatorstd::pairstd::string, std::string )':
filetools.cpp:1353: error: 'zipFile' was not declared in this scope
filetools.cpp:1353: error: expected `;' before 'zf'
filetools.cpp:1372: error: 'zf' was not declared in this scope
filetools.cpp:1372: error: 'zipOpen' was not declared in this scope
filetools.cpp:1383: error: 'zip_fileinfo' was not declared in this scope
filetools.cpp:1383: error: expected `;' before 'zi'
filetools.cpp:1388: error: 'zi' was not declared in this scope
filetools.cpp:1393: error: 'filetime' was not declared in this scope
filetools.cpp:1397: error: 'Z_DEFLATED' was not declared in this scope
filetools.cpp:1398: error: 'Z_DEFAULT_COMPRESSION' was not declared
in this scope
filetools.cpp:1401: error: 'MAX_WBITS' was not declared in this scope
filetools.cpp:1401: error: 'DEF_MEM_LEVEL' was not declared in this
scope
filetools.cpp:1401: error: 'Z_DEFAULT_STRATEGY' was not declared in
this scope
filetools.cpp:1403: error: 'zipOpenNewFileInZip3' was not declared in
this scope
filetools.cpp:1405: error: 'ZIP_OK' was not declared in this scope
filetools.cpp:1416: error: 'ZIP_OK' was not declared in this scope
filetools.cpp:1425: error: 'zipWriteInFileInZip' was not declared in
this scope
filetools.cpp:1431: error: 'ZIP_OK' was not declared in this scope
filetools.cpp:1436: error: 'zipCloseFileInZip' was not declared in
this scope
filetools.cpp:1442: error: 'zipClose' was not declared in this scope
filetools.cpp:1443: error: 'ZIP_OK' was not declared in this scope
filetools.cpp: At global scope:
filetools.cpp:1457: error: 'uLong' has not been declared
filetools.cpp:1457: error: 'tm_unz' has not been declared
filetools.cpp:1457: warning: unused parameter 'filename'
filetools.cpp:1457: warning: unused parameter 'dosdate'
filetools.cpp:1457: warning: unused parameter 'tmu_date'
filetools.cpp:1493: error: 'unzFile' was not declared in this scope
filetools.cpp:1494: error: expected primary-expression before 'const'
filetools.cpp:1495: error: expected primary-expression before 'int'
filetools.cpp:1496: error: expected primary-expression before 'const'
filetools.cpp:1497: error: expected primary-expression before 'const'
filetools.cpp:1497: error: initializer expression list treated as
compound expression
filetools.cpp:1498: error: expected ',' or ';' before '{' token
filetools.cpp: In function 'bool lyx::support::unzipToDir(const
std::string, const std::string)':
filetools.cpp:1611: error: 'unzFile' was not declared in this scope
filetools.cpp:1611: error: expected `;' before 'uf'
filetools.cpp:1622: error: 'uf' was not declared in this scope
filetools.cpp:1622: error: 'unzOpen' was not declared in this scope
filetools.cpp:1630: error: 'uLong' was not declared in this scope
filetools.cpp:1630: error: expected `;' before 'i'
filetools.cpp:1631: error: 'unz_global_info' was not declared in this
scope
filetools.cpp:1631: error: expected `;' before 'gi'
filetools.cpp:1638: error: 'gi' was not declared in this scope
filetools.cpp:1638: error: 'unzGetGlobalInfo' was not declared in
this scope
filetools.cpp:1639: error: 'UNZ_OK' was not declared in this scope
filetools.cpp:1644: error: 'i' was not declared in this scope
filetools.cpp:1647: error: 'lyx::support::do_extract_currentfile'
cannot be used as a function
filetools.cpp:1647: error: 'UNZ_OK' was not declared in this scope
filetools.cpp:1651: error: 'unzGoToNextFile' was not declared in this
scope
filetools.cpp:1652: error: 'UNZ_OK' was not declared in this scope
filetools.cpp:1659: error: 'unzCloseCurrentFile' was not
Re: [PATCH] Embedding feature patch 1: add zipFiles and unzipToDir to support.
Do that. But also adjust code style. You mean changing 'func(a) int a' to 'func(int a)'? Bo
Re: Compilation broken on Mac (current svn)
On 8/21/07, Bennett Helm [EMAIL PROTECTED] wrote: Attempting to compile on Mac gives me the following error. Any suggestions? Because nobody has adjusted autotools for the inclusion of src/support/minizip. Bo
Re: [Patch - 1.5] fix bug 4123: crash when closing LyX window with document tabs
On Tuesday 21 August 2007 09:11:33 Abdelrazak Younes wrote: As there's apparently nobody, I took the liberty to commit it. Jürgen delegated the task in me and Jean-Marc. :-) I agree with you that the patch should be committed and in that case please do not forget to update status.15x Abdel. -- José Abílio
zip stuff
When things are added to the sources the result should build _at least with the Chosen Build System_. And that's autotools. [I am personally not happy about this choice, but that does not really matter here. Also, the code should roughly follow LyX conventions if it is somewhere under src/*. The current state is far from satisfactory. It does not build with autotools and it looks crappy. Andre'
Re: Compilation broken on Mac (current svn)
On Tue, Aug 21, 2007 at 02:54:06PM -0400, Bennett Helm wrote: Attempting to compile on Mac gives me the following error. Any suggestions? The zip stuff that got dumped into src/support... Reverting 19692 and waiting for a cleaner patch might be an option. Andre'
Re: zip stuff
The current state is far from satisfactory. It does not build with autotools and it looks crappy. minizip might evolve with zlib so I am reluctant to change its source. If you think its style does not fit in src/support/minizip, may be we should put it in the top source directory? Or not putting in the svn at all? I have ask for help from autotools experts to add minizip support for autotools. I have difficulties in coping with m4. Bo
Re: Compilation broken on Mac (current svn)
Reverting 19692 and waiting for a cleaner patch might be an option. If no one can fix autotools in a day, autotools can be dumped because too few people can or are willing to maintain it. Bo
Re: Slow down and speed up after copy and paste.
Abdelrazak Younes wrote: Bo Peng wrote: Just to report, as far as I remember, a known problem. I believe there's a bugzilla item from Darren Freeman. He was the only one with these symptoms AFAIK, up until now. fwiw, i was on linux the last couple of weeks and thought it was sluggish too back on windows now though...
Re: r19659 - /lyx-devel/trunk/src/frontends/qt4/ui/CitationUi.ui
Abdelrazak Younes wrote: compilations to avoid bugs in Qt 4.1. I also do care about code simplification that would results in a switch to 4.2 (I'm thinking about Edwin's toolbar widget for example). a switch to 4.2 might be a good idea for some things, but i wouldn't replace my toolbar widget: it has a more visible tear-off strip and shows a tooltip when hovering it. moreover, it works fine!
Re: Compilation broken on Mac (current svn)
Andre Poenitz wrote: On Tue, Aug 21, 2007 at 02:54:06PM -0400, Bennett Helm wrote: Attempting to compile on Mac gives me the following error. Any suggestions? The zip stuff that got dumped into src/support... Reverting 19692 and waiting for a cleaner patch might be an option. didn't know they had cowboys in germany...
Re: r19659 - /lyx-devel/trunk/src/frontends/qt4/ui/CitationUi.ui
On Tue, Aug 21, 2007 at 08:52:06PM +0200, Enrico Forestieri wrote: On Tue, Aug 21, 2007 at 08:37:25PM +0200, Andre Poenitz wrote: On Tue, Aug 21, 2007 at 07:59:36PM +0200, Enrico Forestieri wrote: There have been already complaints for the dismission of the Qt3 frontend by the FreeBSD people. There are other systems in the world other than Windows and Linux. So they should f*** spend _their_ time on a Qt3 frontend but not mine. Being queer is surely nice and acceptable, but being queer _and blaming others for being less so_ is not. The Qt3 frontend was dismissed even if there were people willing to maintain it. The Qt3 frontend is still available from svn. If there had been a real interest in further development it would have happened. This, btw, holds true for Cygwin users, too. I am a cygwin user, and for having the possibility of using a cygwin version of lyx, I had to make up myself as a developer. I simply don't have the time and the skill to maintain a Qt3 frontend, too. That's true for all of us, that's why there is no Qt3 frontend anymore. Andre'
Re: [PATCH] Embedding feature patch 1: add zipFiles and unzipToDir to support.
On Tue, Aug 21, 2007 at 02:06:14PM -0500, Bo Peng wrote: Do that. But also adjust code style. You mean changing 'func(a) int a' to 'func(int a)'? I mean 'make it look like the rest of LyX source'. And yes, using ANSI C instead of KR is a step in the right direction. Andre'
Re: CharStyle Problem in agu_stdclass.inc
On Mon, Aug 20, 2007 at 09:15:47PM +0300, Martin Vermeer wrote: On Mon, Aug 20, 2007 at 12:23:49PM -0400, Richard Heck wrote: Martin Vermeer wrote: Yes... this requires the patch to layout2layout in order to work. Haven't committed yet, waiting for José's comments. Shouldn't these just be changed to InsetLayout blahblah LyXType charstyle as with the others? The grep was in the trunk. Richard Yes, you could do this manually (i.e., python -tt layout2layout from the command line). Why not. We still need the script in svn for user-written charstyle files. I committed the change for the agu_ and db_ layouts and for Beamer. - Martin
Re: Compilation broken on Mac (current svn)
On Tue, Aug 21, 2007 at 02:06:54PM -0500, Bo Peng wrote: On 8/21/07, Bennett Helm [EMAIL PROTECTED] wrote: Attempting to compile on Mac gives me the following error. Any suggestions? Because nobody has adjusted autotools for the inclusion of src/support/minizip. autotools has to work as long as it is the official build system. If it doesn't, the patch can't go in or it has to be fixed as soon as problems arise. Committing stuff known to break the official build system is generally not permitted. Andre'
Inset configurability: ERT
Attached.
- Martin
Index: src/insets/InsetERT.cpp
===
--- src/insets/InsetERT.cpp (revision 19610)
+++ src/insets/InsetERT.cpp (working copy)
@@ -53,11 +53,7 @@
void InsetERT::init()
{
setButtonLabel();
- Font font(Font::ALL_SANE);
- font.decSize();
- font.decSize();
- font.setColor(Color::latex);
- setLabelFont(font);
+ setLabelFont(layout_.labelfont);
text_.current_font.setLanguage(latex_language);
text_.real_current_font.setLanguage(latex_language);
}
@@ -66,6 +62,7 @@
InsetERT::InsetERT(BufferParams const bp, CollapseStatus status)
: InsetCollapsable(bp, status)
{
+ setLayout(bp);
init();
}
@@ -413,6 +410,7 @@
Font tmpfont = pi.base.font;
getDrawFont(pi.base.font);
pi.base.font.realize(tmpfont);
+ const_castInsetERT (*this).setButtonLabel();
InsetCollapsable::draw(pi, x, y);
pi.base.font = tmpfont;
}
@@ -428,8 +426,7 @@
void InsetERT::getDrawFont(Font font) const
{
font = Font(Font::ALL_INHERIT, latex_language);
- font.setFamily(Font::TYPEWRITER_FAMILY);
- font.setColor(Color::latex);
+ font.realize(layout_.font);
}
Index: lib/layouts/stdinsets.inc
===
--- lib/layouts/stdinsets.inc (revision 19664)
+++ lib/layouts/stdinsets.inc (working copy)
@@ -75,4 +75,15 @@
EndFont
End
+InsetLayout ERT
+ LabelString ERT
+ Font
+ Color latex
+ Family typewriter
+ EndFont
+ LabelFont
+ Color latex
+ SizeSmall
+ EndFont
+End
Re: [PATCH] Embedding feature patch 1: add zipFiles and unzipToDir to support.
I mean 'make it look like the rest of LyX source'. And yes, using ANSI C instead of KR is a step in the right direction. Doing it... to make g++ understand the code. Bo
Re: Compilation broken on Mac (current svn)
On Tuesday 21 August 2007 20:18:49 Bo Peng wrote:
If no one can fix autotools in a day, autotools can be dumped because
too few people can or are willing to maintain it.
The same can be said about any other buildsystem. We are on holidays time
(at least in the Northern hemisphere) so a day is not a really such a big
time period.
When introducing such new features a little bit of patience is expected. And
no a day is not a sign of patience. :-)
Bo
PS: I remember that you have talked about PEPs for new features what is the
rationale behind this feature.
PPS: I am still on a semi-holidays mode so my appearance in this list can be
irregular this week.
PPPS: I have some things to say about the development stage of 1.6 but due
to the reason above I will delay this to next week.
S: I have some ideas about xml, but again more about this next week.
P{5}S: no more P*S's. ;-)
--
José Abílio
Re: CharStyle Problem in agu_stdclass.inc
On Monday 20 August 2007 17:09:33 Martin Vermeer wrote: Yes... this requires the patch to layout2layout in order to work. Haven't committed yet, waiting for José's comments. José? Go on. :-) - Martin -- José Abílio
Re: Inset configurability: ERT
On Tuesday 21 August 2007 20:54:17 Martin Vermeer wrote: Attached. - Martin If this work happily then congratulations for you work Martin. :-) -- José Abílio
Re: zip stuff
On Tue, Aug 21, 2007 at 02:15:05PM -0500, Bo Peng wrote: The current state is far from satisfactory. It does not build with autotools and it looks crappy. minizip might evolve with zlib so I am reluctant to change its source. So it shouldn't be under src/ but similarly positioned as booost If you think its style does not fit in src/support/minizip, may be we should put it in the top source directory? Yes. Or not putting in the svn at all? If it works externally, why not. But didn't you say you need tar like capabilities that's usually not found in whatever-zip? I have ask for help from autotools experts to add minizip support for autotools. I have difficulties in coping with m4. But you can't commit a knowingly non-compiling version. At the very least #if 0 out the stuff. My 'ok' was under the assumption that the feature might not _work_ when compiled with autotools, but not that LyX won't compile anymore. Andre'
Re: Compilation broken on Mac (current svn)
On Tue, Aug 21, 2007 at 09:24:10PM +0200, Edwin Leuven wrote: Andre Poenitz wrote: On Tue, Aug 21, 2007 at 02:54:06PM -0400, Bennett Helm wrote: Attempting to compile on Mac gives me the following error. Any suggestions? The zip stuff that got dumped into src/support... Reverting 19692 and waiting for a cleaner patch might be an option. didn't know they had cowboys in germany... I don't think there are. Andre'
Re: Opinion on the embedding of zip/unzip in lyx using zlib/contrib/minizip.
On Monday 20 August 2007 16:49:20 Bo Peng wrote: Dear list, Because I get no objection to the design of the embedding feature of lyx, I plan to add it to the trunk in the next few weeks. There is, however, a big question on how to zip and unzip files. There is a unzipFile function in src/support/filetools.cpp which calls 'gunzip -c'. I am not sure how lyx distributes gunzip and I doubt if it works under windows. In my current patch, I build a static library minizip.a from zlib-1.2.3/contrib/minizip/ioapi.c, zip.c and unzip.c. I then add functions zipFiles() and unzipToDir() to filetools.cpp using code from minzip.c and minunz.c. This allows lyx to zip and unzip files easily, but requires zlib source and changes to our four build systems. I am not quite sure if this is a good idea so any comment is welcome. Could you add, please, your ideas to a wiki page under development? Even a compilation of previous messages to this list is OK. :-) Cheers, Bo -- José Abílio
Re: Compilation broken on Mac (current svn)
When introducing such new features a little bit of patience is expected. And no a day is not a sign of patience. :-) No one will fix autotools if the patch is not submitted. In the end, I will have to open autoconf manual, something I have been trying to avoid. PS: I remember that you have talked about PEPs for new features what is the rationale behind this feature. Yes. I have talked about this several times but you never expressed your opinion, and then, the trunk was open to Barmarv boys and was broken for quite a while. PPS: I am still on a semi-holidays mode so my appearance in this list can be irregular this week. I see. PPPS: I have some things to say about the development stage of 1.6 but due to the reason above I will delay this to next week. Waiting... S: I have some ideas about xml, but again more about this next week. Waiting... Bo
Re: Compilation broken on Mac (current svn)
On Tue, Aug 21, 2007 at 02:18:49PM -0500, Bo Peng wrote: Reverting 19692 and waiting for a cleaner patch might be an option. If no one can fix autotools in a day, autotools can be dumped because too few people can or are willing to maintain it. As long as there is no consensus on what the replacement will look like autotools stays the preferred build environment (and I hate it, too, but that's not the point). We can re-open the discussion and try to reach a new consensus, but until we have that LyX source has to be buildable with autotools. [And getting consensus more or less boils down to you and Peter agreeing on whether to use scons or cmake, and the survivor showing the rest that we don't use any of the features of autotools we are actively using (or propose a reasonable alternative to those features)[ Andre'
Re: Slow down and speed up after copy and paste.
Bo Peng wrote: Just to report, as far as I remember, a known problem. I believe there's a bugzilla item from Darren Freeman. He was the only one with these symptoms AFAIK, up until now. i reported it here http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg122582.html and catched how to reproduce it (maybe only on linux). http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg122696.html pavel
Re: Compilation broken on Mac (current svn)
On Tue, Aug 21, 2007 at 02:59:14PM -0500, Bo Peng wrote: When introducing such new features a little bit of patience is expected. And no a day is not a sign of patience. :-) No one will fix autotools if the patch is not submitted. You can send the patch to some 'autotool' guy. Jean-Marc is usually a good victim, but he's on real holidays now. In the end, I will have to open autoconf manual, something I have been trying to avoid. No, it would be sufficient if the code were enclosed in #if ZIP_WORKS ... #endif Andre'
Re: Compilation broken on Mac (current svn)
As long as there is no consensus on what the replacement will look like autotools stays the preferred build environment (and I hate it, too, but that's not the point). I actaully agree on this. My point is that I will need several hours to do it, and your or JMarc needs only five minutes, so why should I spend the time? Now that src/support/minizip can be compiled by a C++ compiler, I guess you can add a Makefile.am file pretty quickly. Bo
Re: Compilation broken on Mac (current svn)
On Tue, Aug 21, 2007 at 03:05:11PM -0500, Bo Peng wrote: As long as there is no consensus on what the replacement will look like autotools stays the preferred build environment (and I hate it, too, but that's not the point). I actaully agree on this. My point is that I will need several hours to do it, and your or JMarc needs only five minutes, so why should I spend the time? I don't really know autotools. Jean-Marc is on holydays. I can #ifdef out stuff, but that'd be your job to begin with. Andre'
Re: Opinion on the embedding of zip/unzip in lyx using zlib/contrib/minizip.
Could you add, please, your ideas to a wiki page under development? Will do that later. Even a compilation of previous messages to this list is OK. :-) Here is a comment from my src/EmbeddedFiles.h: /** This file, and the embedding dialog implemented in src/frontends, implements an 'Embedded Files' feature of lyx. Expected features: = 1. With embedding enabled (disabled by default), .lyx file can embed graphics, listings, bib file etc. 2. Embedding of certain files are automatic (graphics, bib etc), and other files can be embedded manually. 3. Embedded file.lyx file is a zip file, with file.lyx, manifest.txt and embedded files. There is no subdirectory in this zip file (with current implementation). 4. If no file is embedded, file.lyx is in plain text format. This is desired by many users because pure-text format allows easy manipulation and better version control. 5. Embedded files can be EMBEDDED, EXTERNAL, or AUTO. In the AUTO mode, external files will be used if available; otherwise the embedded version will be used. In this way, users can work as usual by modifying external listings, graphics, and do not have to worry about embedding. EMBEDDED and EXTERNAL modes ignore or use external files respectively. 6. An embedding dialog is provided to change embedding status (buffer level or individual embedded files), manually embed, extract, view or edit files. Overall, this feature allows two ways of editing .lyx file a. The continuous use of the pure-text .lyx file format with external files. This is the default file format, and allows external editing of .lyx file and better use of version control systems. b. The embedded way. Figures etc are inserted to .lyx file and will be embedded. These embedded files can be viewed or edited through the embedding dialog. This file can be shared with others more easily. The advantage of lyx' embedding approach is that external files will be automatically used and embedded if the file is in AUTO mode. Implementation: == 1. An EmbeddedFiles class is implemented to keep the embedded files ( class EmbeddedFile). (c.f. src/EmbeddedFiles.[h|cpp]) This class keeps a manifest that has a. external relative filename b. inzip filename (no directory structure), name aliasing is used if two external files share the same name. c. embedding mode. It also provides functions to a. manipulate manifest b. scan a buffer for embeddable files c. look up inzipname from external filename d. look up external filename from inzipname 2. When a file is saved, it is scanned for embedded files. (c.f. EmbeddedFiles::update(), Inset::registerEmbeddedFiles()). 3. When a lyx file file.lyx is saved, it is save to tmppath() first. If there is any embedded files, these files are compressed along with file.lyx and a manifest.txt. If there is no embedded file, or if embedding is disabled, file.lyx is saved in the usual pure-text form. (c.f. Buffer::writeFile(), EmbeddedFiles::write()) 4. When a lyx file.lyx file is opened, if it is a zip file, it is decompressed to tmppath(). If manifest.txt and file.lyx exists in tmppath(), the manifest is read to buffer, and tmppath()/file.lyx is read as usual. If file.lyx is not a zip file, it is read as usual. (c.f. bool Buffer::readFile()) 5. A menu item Document - Embedded Files is provided to open a embedding dialog. It handles a EmbddedFiles point directly. From this dialog, a user can disable embedding, change embedding status, or embed other files, extract, view, edit files. 6. When a lyx file is loaded, Embedded files can have a. both external and internal copy b. only external copy (filename()) c. only embedded copy (temppath()/inzipname) And each can have AUTO, EXTERNAL, EMBEDDED status. Proper handling of each case is required. 7. If embedding of a .lyx file with embedded files is disabled, all its embedded files are copied to their respective external filenames. This is why external filename will exist even if a file is at EMBEDDED status. 8. Individual embeddable insets should find ways to handle embedded files. InsetGraphics replace params().filename with its temppath()/inzipname version when the inset is created. The filename appears as /tmp//inzipname when lyx runs. When params().filename is saved, lyx checks if this is an embedded file (check path == temppath()), if so, save filename() instead. (c.f. InsetGraphic::read(), InsetGraphics::edit(), InsetGraphicsParams::write()) */ Cheers, Bo
Re: Compilation broken on Mac (current svn)
I can #ifdef out stuff, but that'd be your job to begin with. Hold on, I used autotools a few years ago and I think I still know how to handle this relatively simple case. :-( Be patient, just another one or two hours... (instead of 10 min if JMarc is here.) Bo
Re: r19659 - /lyx-devel/trunk/src/frontends/qt4/ui/CitationUi.ui
On Tue, Aug 21, 2007 at 08:20:01PM +0200, Enrico Forestieri wrote: [...] Then the Qt build system doesn't let you perform out of tree builds (shadow builds in Qt parliance), even if Qt 4.3 is a big step forward in this respect. I just tried a shadow build of Qt 4.3.0 itself and it worked out-of-the-box. autotools? You can't eat your cake and have it ;-) That's not about pure compilation. This is about having unnecessary abstraction layers _and_ choosing regularily the most expensive method of abstraction. There must be something wrong in the way we use autotools. I build many other programs using autotools but do not experience the same slowness as with lyx. Autotools is indeed only part of the problem (accounts for a factor of two). boost is the other (no hard numbers here, but I wouldn't be surprised if the magnitude was the same) and then there are various small issues. But I would like to say that this is with non Linux platforms, as in that case I don't see a real problem. I really don't care when compilation takes 10 minutes instead of 12, but I am concerned when with scons I can compile in almost half the time. That's the factor of 2 due to autotools. Andre'
Re: r19659 - /lyx-devel/trunk/src/frontends/qt4/ui/CitationUi.ui
On Tue, Aug 21, 2007 at 09:47:08PM +0200, Andre Poenitz wrote: On Tue, Aug 21, 2007 at 08:52:06PM +0200, Enrico Forestieri wrote: On Tue, Aug 21, 2007 at 08:37:25PM +0200, Andre Poenitz wrote: On Tue, Aug 21, 2007 at 07:59:36PM +0200, Enrico Forestieri wrote: There have been already complaints for the dismission of the Qt3 frontend by the FreeBSD people. There are other systems in the world other than Windows and Linux. So they should f*** spend _their_ time on a Qt3 frontend but not mine. Being queer is surely nice and acceptable, but being queer _and blaming others for being less so_ is not. The Qt3 frontend was dismissed even if there were people willing to maintain it. The Qt3 frontend is still available from svn. If there had been a real interest in further development it would have happened. At the time there was interest, but it was nevertheless removed. This, btw, holds true for Cygwin users, too. I am a cygwin user, and for having the possibility of using a cygwin version of lyx, I had to make up myself as a developer. I simply don't have the time and the skill to maintain a Qt3 frontend, too. That's true for all of us, that's why there is no Qt3 frontend anymore. There is no Qt3 frontend anymore because it was brutally murdered. The same holds true for the gtk frontend. If they had stayed in trunk, maybe we could still have a choice, now no more. Now I will stop replying to this thread, because a discussion requires that both parties are willing to listen, but trying to rewrite history really annoys me, so I couldn't resist with this last post. -- Enrico
Re: Compilation broken on Mac (current svn)
Be patient, just another one or two hours... (instead of 10 min if JMarc is here.) Done. Tested under linux. Please test. Bo
Re: Compilation broken on Mac (current svn)
On 21.08.2007, at 22:40, Bo Peng wrote: Be patient, just another one or two hours... (instead of 10 min if JMarc is here.) Done. Tested under linux. Please test. Bo I get an error on MacOS: Making install in po make LyX-1.6.pot-update make[3]: *** No rule to make target `../src/Biblio.cpp', needed by `LyX-1.6.pot-update'. Stop. make[2]: *** [LyX-1.6.pot] Error 2 make[1]: *** [install-recursive] Error 1 make: *** [install-strip] Error 2 Compiled as in INSTALL.MacOSX, summary of ./config step: Configuration Host type:powerpc-apple-darwin8.10.0 Special build flags: assertions pch concept-checks stdlib- debug warnings use-ispell C Compiler: gcc C Compiler LyX flags: C Compiler flags: -Wextra -Wall -I/System/Library/ Frameworks/CoreFoundation.framework/Headers -g -O2 C++ Compiler: g++ (4.0.1) C++ Compiler LyX flags: C++ Compiler flags: -Wextra -Wall -I/System/Library/ Frameworks/CoreFoundation.framework/Headers -g -O2 Linker flags: Linker user flags:-framework Carbon -framework OpenGL - framework AGL -framework QuickTime -framework Cocoa Qt 4 Frontend: Qt 4 version: 4.3.1 Packaging:macosx LyX binary dir: /Applications/_eigene/LyX-svn.app/ Contents/MacOS LyX files dir:/Applications/_eigene/LyX-svn.app/ Contents/Resources Andi
Re: LyX translation updates needed
Well, I hope it will be enough:... Thanks, I added you to the credits and your work will be part of the next release LyX 1.5.2. regards Uwe
Remove unused std::time.
Can I apply the attached patch? scons/msvc complains about no std::time, and std::time is not used in this file. What is this std::time anyway? A function? Bo Index: src/DepTable.cpp === --- src/DepTable.cpp(revision 19698) +++ src/DepTable.cpp(working copy) @@ -25,9 +25,6 @@ #include fstream -#ifndef CXX_GLOBAL_CSTD -using std::time; -#endif using std::endl; using std::flush; using std::getline;
Re: Compilation broken on Mac (current svn)
On 21 aug 2007, at 23.41, Bo Peng wrote: I get an error with rev 19699 on Mac PPC 10.4: Does the attached patch help? Boinc.diff Yes, that did it. Thanks! /Anders
Re: CharStyle Problem in agu_stdclass.inc
On Tue, Aug 21, 2007 at 08:53:54PM +0100, José Matos wrote:
On Monday 20 August 2007 17:09:33 Martin Vermeer wrote:
Yes... this requires the patch to layout2layout in order to work.
Haven't committed yet, waiting for José's comments.
José?
Go on. :-)
This patch. Does it look reasonable?
- Martin
Index: layout2layout.py
===
--- layout2layout.py (revision 19567)
+++ layout2layout.py (working copy)
@@ -80,6 +80,7 @@
re_NoStyle = re.compile(r'^(\s*)(NoStyle)(\s+)(\S+)', re.IGNORECASE)
re_End = re.compile(r'^(\s*)(End)(\s*)$', re.IGNORECASE)
re_Provides = re.compile(r'^(\s*)Provides(\S+)(\s+)(\S+)', re.IGNORECASE)
+re_CharStyle = re.compile(r'^(\s*)CharStyle(\s+)(\S+)$', re.IGNORECASE)
# counters for sectioning styles (hardcoded in 1.3)
counters = {part : \\Roman{part},
@@ -126,7 +127,7 @@
# Skip comments and empty lines
if re_Comment.match(lines[i]) or re_Empty.match(lines[i]):
-i = i + 1
+i += 1
continue
# insert file format if not already there
@@ -134,10 +135,10 @@
match = re_Format.match(lines[i])
if match:
format = int(match.group(4))
-if format 1 and format 4:
+if format 1 and format 5:
lines[i] = Format %d % (format + 1)
only_comment = 0
-elif format == 4:
+elif format == 5:
# nothing to do
return format
else:
@@ -149,11 +150,24 @@
# Don't get confused by LaTeX code
if re_Preamble.match(lines[i]):
-i = i + 1
+i += 1
while i len(lines) and not re_EndPreamble.match(lines[i]):
-i = i + 1
+i += 1
continue
+if format == 4:
+# Handle conversion to long CharStyle names
+match = re_CharStyle.match(lines[i])
+if match:
+lines[i] = InsetLayout CharStyle:%s % (match.group(3))
+i += 1
+lines.insert(i, \tLyXType charstyle)
+i += 1
+lines.insert(i, )
+lines[i] = \tLabelString %s % (match.group(3))
+i += 1
+continue
+
if format == 3:
# convert 'providesamsmath x', 'providesmakeidx x', 'providesnatbib x', 'providesurl x' to
# 'provides amsmath x', 'provides makeidx x', 'provides natbib x', 'provides url x'
@@ -162,7 +176,7 @@
if match:
lines[i] = %sProvides %s%s%s % (match.group(1), match.group(2).lower(),
match.group(3), match.group(4))
-i = i + 1
+i += 1
continue
if format == 2:
@@ -219,7 +233,7 @@
' Series Bold',
' EndFont']
-i = i + 1
+i += 1
continue
# Delete MaxCounter and remember the value of it
@@ -308,7 +322,7 @@
if string.lower(label) == bibliography:
if (latextype_line 0):
lines.insert(i, %sLatexType Bib_Environment % space1)
-i = i + 1
+i += 1
else:
lines[latextype_line] = re_LatexType.sub(r'\1\2\3Bib_Environment', lines[latextype_line])
@@ -337,7 +351,7 @@
if counters.has_key(style):
if labelstring_line 0:
lines.insert(i, '%sLabelString %s' % (space1, counters[style]))
-i = i + 1
+i += 1
else:
new_labelstring = concatenate_label(labelstring, counters[style])
lines[labelstring_line] = re_LabelString.sub(
@@ -346,7 +360,7 @@
if appendixcounters.has_key(style):
if labelstringappendix_line 0:
lines.insert(i, '%sLabelStringAppendix %s' % (space1, appendixcounters[style]))
-i = i + 1
+i += 1
else:
new_labelstring = concatenate_label(labelstring, appendixcounters[style])
lines[labelstringappendix_line] = re_LabelStringAppendix.sub(
@@ -355,14 +369,14 @@
# Now we can safely add the LabelCounter line
lines.insert(labeltype_line + 1, %sLabelCounter %s % (space1, counter))
-i = i + 1
+i += 1
# Add the TocLevel setting for sectioning styles
if
Re: Slow down and speed up after copy and paste.
i reported it here http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg122582.html and catched how to reproduce it (maybe only on linux). http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg122696.html i could not find it in bugz and the reason is, that it is uncorfimed. http://bugzilla.lyx.org/show_bug.cgi?id=4045
Re: Compilation broken on Mac (current svn)
Bo Peng Tue, 21 Aug 2007 13:42:06 -0700 Be patient, just another one or two hours... (instead of 10 min if JMarc is here.) Done. Tested under linux. Please test. Bo I get an error with rev 19699 on Mac PPC 10.4: ... filetools.cpp:59:21: error: direct.h: No such file or directory filetools.cpp:60:17: error: io.h: No such file or directory filetools.cpp:1343: warning: unused parameter 'f' filetools.cpp:1343: warning: unused parameter 'tmzip' filetools.cpp:1343: warning: unused parameter 'dt' filetools.cpp:1457: warning: unused parameter 'filename' filetools.cpp:1457: warning: unused parameter 'dosdate' filetools.cpp:1457: warning: unused parameter 'tmu_date' filetools.cpp: In function 'int lyx::support::do_extract_currentfile (void*, const int*, int*, const char*, const char*)': filetools.cpp:1508: warning: unused variable 'ratio' filetools.cpp: At global scope: filetools.cpp:1497: warning: unused parameter 'popt_overwrite' filetools.cpp: In function 'bool lyx::support::unzipToDir(const std::string, const std::string)': filetools.cpp:1633: warning: unused variable 'fout' filetools.cpp:1660: warning: control reaches end of non-void function make[5]: *** [filetools.lo] Error 1 make[4]: *** [install] Error 2 ... /Anders
Re: [Patch - 1.5] fix bug 4123: crash when closing LyX window with document tabs
José Matos wrote: On Tuesday 21 August 2007 09:11:33 Abdelrazak Younes wrote: As there's apparently nobody, I took the liberty to commit it. Jürgen delegated the task in me and Jean-Marc. :-) As you are in semi holidays I can help you with that task. I think I know the way JMarc and Jurgen want to maintain 1.5. I agree with you that the patch should be committed and in that case please do not forget to update status.15x As I said, I know how 1.5 should be maintained ;-) Abdel.
Re: [Updated PATCH] BufferView/WorkArea/LyXView reorg a.k.a Multiple WorkAreas
Enrico Forestieri wrote: On Tue, Aug 21, 2007 at 09:36:35AM +0200, Abdelrazak Younes wrote: Abdelrazak Younes wrote: Abdelrazak Younes wrote: Abdelrazak Younes wrote: Here is my most recent patch. What is not working yet: - the close tab button: it is implemented but does not show up. - the splash screen: it is implemented but does not show up. I solved the splash screen bug Here is a patch with this fix against latest trunk. Updated and committed. Nuisance: - Even with only one file opened, a toolbar with a tab appears. I know. Haven't looked at it yet but am sure this is solvable. Problems: - The main window bar does not show the filename of a loaded file. However, after opening another file, the name shows up. I'll have a look thanks. - The list of recently opened files is not updated. ditto. Crash: When loading the attached file, the cursor is not visible and the text is out of view. No scrollbar is present, but if you click in the window, the view is adjusted (and the scrollbar appears). However, if you don't click in the window and instead try to roll the mouse wheel in an attempt to scroll the view, lyx crashes: ditto. Abdel.
Re: r19659 - /lyx-devel/trunk/src/frontends/qt4/ui/CitationUi.ui
Enrico Forestieri wrote: On Tue, Aug 21, 2007 at 06:31:33PM +0200, Abdelrazak Younes wrote: Still, I'd be curious to see how many people on X11 use Qt4.1... I bet not a lot. All the predicted integration problem did not really happened AFAICS. There have been already complaints for the dismission of the Qt3 frontend by the FreeBSD people. And they are very welcome to implement a Qt3 frontend if they'd like to :-) I'd even help them (of course I know it will never happen so I can promise anything :-)) There are other systems in the world other than Windows and Linux. Mac? ;-) FWIW, I don't really care about the bells and whistles, there are enough of them to use even in Qt 4.0. But I do care about conditional compilations to avoid bugs in Qt 4.1. I also do care about code simplification that would results in a switch to 4.2 (I'm thinking about Edwin's toolbar widget for example). Then go ahead and require a Qt snapshot such that you can have more fun and less problems. I am just talking about a reasonable compromise. By the time 1.6 is out, 4.2 will be 2 years old; not unreasonable IMHO. PS: Qt 4.1.5 was released October 20, 2006. But Qt 3.3.8 was released February, 14 2007. Yet we don't use it ;-) And that is a real shame. I was personally fad up of maintaining it. But I agree that Georg was making a good job at it when I gave up. Abdel.
Re: Compilation broken on Mac (current svn)
Bo Peng wrote: Be patient, just another one or two hours... (instead of 10 min if JMarc is here.) Done. Tested under linux. Please test. Bo Compiles fine here (linux) A/
Re: Compilation broken on Mac (current svn)
I get an error with rev 19699 on Mac PPC 10.4: Does the attached patch help? Bo Index: src/support/filetools.cpp === --- src/support/filetools.cpp (revision 19698) +++ src/support/filetools.cpp (working copy) @@ -50,15 +50,27 @@ #include fstream #include sstream -#ifdef unix +#ifdef HAVE_UNISTD_H # include unistd.h -# include utime.h +#endif +#ifdef HAVE_DIRECT_H +# include direct.h +#endif +#ifdef HAVE_SYS_TYPES_H # include sys/types.h +#endif +#ifdef HAVE_SYS_STAT_H # include sys/stat.h -#else -# include direct.h +#endif +#ifdef HAVE_IO_H # include io.h #endif +#ifdef HAVE_SYS_UTIME_H +# include sys/utime.h +#endif +#ifdef HAVE_UTIME_H +# include utime.h +#endif #include zip.h #include unzip.h
