Re: r19659 - /lyx-devel/trunk/src/frontends/qt4/ui/CitationUi.ui
Enrico Forestieri wrote: On Wed, Aug 22, 2007 at 07:24:17PM +0200, Jean-Pierre Chretien wrote: 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. I fully agree with this. In addition on Solaris 8 I get spurious messages about the lyx temporary whenever I cut, paste, and close (see my previous thread about this). I am perfectly frustrated to see the striking new features of lyx-1.5 blurred by the bad implementation of qt4 on Solaris. I'd just like to point out that many of these features would have never happened on the qt3 port. Pretty sure of that. The last 4.3.0 version seems unable to register font changes. Before trying to compile LyX with it, I'd like to be sure that configure with env LD_OPTIONS=-R/usr/local/lib ./configure -release -qt-gif \ -platform solaris-g++ -prefix /usr/local/qt-4.3.0 is OK. Any hint ? I don't think that you will get any help from this list. The queer fish that is not using the mainstream platforms, or that is not using the latest versions of the various libraries, better change his system to conform to the imposed conditions. Someone will explain him that this is how open source works, so he could try to get commit privileges in order to try to adjust things for his platform, but unless he has a very thick skin, I do not recommend it. You are misinterpreting my words Enrico. I'd never say we should not help users with exotic systems. I am only saying that I am personally not qualified for this request. If I can help, I'll help, so are maybe 99% of the developers here. But I am not going to invest time investigate this Solaris issue. Jean-Pierre, if you have problem with Qt, then I suggest to report this to the Qt-interest mailing list. There is a news interface too. My experience is that they are pretty responsive. Abdel.
Re: [PATCH] Layout Modularity, Part I
Richard Heck wrote: Andre Poenitz wrote: On Wed, Aug 22, 2007 at 07:44:17PM -0400, Richard Heck wrote: Andre Poenitz wrote: Looks good in general. Good. I find the naming TextClass_sptr exceptionally ugle (CamelBump and under_score mixed), but I know there are unfortunate precendents (Layout_ptr). I guess I'd prefer TextClassPtr nevertheless. I took it from the existing precedents. The ugly naming does at least signal there's something unusual about the file. Still, I personally don't like this using of shared_ptr. Isn't it possible that, instead of owning the changed TextClass, BufferParams would create this TextClass and register it in the TextClassList under a new identifier (which BufferParam will store)? This way the TextClass will remain accessible after the Buffer is closed... Just an idea. Abdel.
Re: [PATCH] Layout Modularity, Part I
Richard Heck wrote: The pointer in question is a boost::shared_ptr. This is needed because CutAndPaste saves a copy of the layout with each cut or copied selection. We cannot assume the selection vanishes when the document is closed, so there are two options: (i) keep a list of all the layouts that have ever been used by any document; (ii) used some kind of smart pointer. The latter seems preferable, as the former would waste memory. (iii) remember layout base class _and_ module in BufferParams. Maybe the solution is to have a global TextClassModule along the global TextClassList instead of having local copies of TextClass? Or integrate the module access to the TextClassList itself? Abdel.
Re: r19659 - /lyx-devel/trunk/src/frontends/qt4/ui/CitationUi.ui
Abdelrazak Younes [EMAIL PROTECTED] writes: [...] Jean-Pierre, if you have problem with Qt, then I suggest to report this to the Qt-interest mailing list. There is a news interface too. My experience is that they are pretty responsive. Sure, I'm already in the process of subscribing. Thanks for your answers. -- Jean-Pierre
Re: [patch] remove bogust const semantics in DocIterator
Andre Poenitz wrote: A third option would be to eliminate const_iterator semantics completely... What do people feel about this? I don't think wee need the hard constness in this case. If this is the general feeling, I'll just remove the fake one then (because having a behaving DocIterator const *is* useful, and the code is a real mess in this respect). A/
Re: [Updated PATCH] BufferView/WorkArea/LyXView reorg a.k.a Multiple WorkAreas
Enrico Forestieri wrote: Nuisance: - Even with only one file opened, a toolbar with a tab appears. This is fixed. Problems: - The main window bar does not show the filename of a loaded file. However, after opening another file, the name shows up. I don't see this bug. - The list of recently opened files is not updated. This is fixed. Abdel.
Re: cmake needs update?
On Wednesday 22 August 2007 21:38:05 Andre Poenitz wrote: On Wed, Aug 22, 2007 at 07:12:15PM +0100, José Matos wrote: And you know that I would drop m4 for python in an eye blink. ;-) You are too predictable. With respect to m4? Surely. ;-) Andre' -- José Abílio
Re: [Cvslog] r19735 - /lyx-devel/trunk/po/LINGUAS
On Wednesday 22 August 2007 22:39:50 Martin Vermeer wrote: Are you sure? Less than half of them so far. (But I'll try to work on it) Uwe is right. We have defined half as the threshold for the language to be shown, and Finish is not different from other languages in that regard. :-) - Martin -- José Abílio
Re: [Cvslog] r19735 - /lyx-devel/trunk/po/LINGUAS
Martin Vermeer schrieb: Are you sure? Less than half of them so far. Yes, because the other yellow languages in i18n.php are also in the Linguas file. regards Uwe
Re: [PATCH] Simplify bookmars handling and further improvments...
Andre Poenitz wrote: On Wed, Aug 22, 2007 at 04:55:13PM +0200, Alfredo Braunstein wrote: Abdelrazak Younes wrote: Alfredo Braunstein wrote: Abdelrazak Younes wrote: Well, at runtime, in-inset bookmark sort of work now because we already use the paragraph id. What is missing is the saving/loading of in-inset bookmark when a document is opened/closed. I see (missed the point) :-) Still, you are welcome to proceed to your idea ;-) I don't have a good idea unfortunately. As I see it there are many approaches, but all of them are bad in one way or another. 1) the current approach with par ids has two problems a) when the paragraph get erased we lose track of everything b) edition of chars in the paragraph before the position move the bookmarks 2) one idea would be to use a special mark inset. This would solve b) but not a). Aditionally, this implies that we have an undesired object that obstacles edition. We could try to track its existence with a signal in its dtor, but seems difficult to readjust correctly (in particular hard to avoid a large number of operations when a large block gets inserted/deleted etc) 3) finally, registering with the buffer. Then all edit operations have to be done in a centralized way. This is difficult to enforce, we should make Paragraph/ParagraphList/Inset accessor methods private and work our way with friend functions/classes that track the bookmarks. Seems lot of work. Other ideas? 3. A lot of work, but it will pay off.. I've rethink about it, and I think that there's a plausible solution near 2) that requires much less work. The idea is the following: we have special marks inside the insetlist inside paragraphs, administrated by insetlist. They don't occupy editing space, but are adjusted as insets on edition. They are also centrally registerd (smart pointers or such). On deletion, (be it because the position is deleted, or because the paragraph is), they signal their deletion to the central register. Once after each user edition (in some central dispatch), all newly deleted marks are repositioned in the cursor position of the cursor [of the Bufferview] that made the edition (this is ok, because we already track this cursor position in edit routines, and all 'deleted' positions collapse in the final cursor position). What about this? A/
Re: r19659 - /lyx-devel/trunk/src/frontends/qt4/ui/CitationUi.ui
Andre Poenitz wrote: And you do not even try to keep it alive. I explained the reasons in detail back then. If this is not some random accusation and you are really interested why this was no option anymore go read the archives (thread Random Notes). [...] Now that you look at trac you might as well count the people who needed to do stuff in qt3 even if they did not want to. You still don't get it. All your arguments including this one and that in your other mail are based on the assumption that there were only two alternatives: full support or removal from trunk. Under this premise I agree completely with the removal, but that is not what has been requested. There was a third alternative that would have solved almost all problems: Keep it in trunk (with no obligation of anyone to touch it), and let those who care do the work to keep it up to date. With that alternative all your arguments are moot. That alternative would of course not have guaranteed that 1.5.0 would be released with qt3. Maybe it would indeed have been too much work to keep it up to date, and it would have been abandoned, but this would then have been the decision of _those who where doing the work_. What happened instead is that _you_ dictated that those should stop or jump through some extra hoops. I am not demanding anyone to agree with my view of the importance (or nonimportance) of the qt3 frontend. I am neither denying the fact that there where some reasons for removal, and that several developers where in favour to remove it. I am however demanding that nobody is perverting the facts. Georg
Re: selective 'monolithic builds' for autotools
On Saturday 18 August 2007 23:52:00 Andre Poenitz wrote:
Typical use would be to have such --enable-monolithic-* for
{core,mathed,insets,controllers,frontends,qt4,tex2lyx,client,boost}
implemented and 'switched on' for all the areas one is not currently
working on (or invert that logic at some point of time).
Do you intend to commit this?
Andre'
--
José Abílio
Re: Opinion on the embedding of zip/unzip in lyx using zlib/contrib/minizip.
On Tuesday 21 August 2007 21:07:41 Bo Peng wrote: 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 has now become: http://wiki.lyx.org/Devel/Embedding Cheers, Bo -- José Abílio
Re: Opinion on the embedding of zip/unzip in lyx using zlib/contrib/minizip.
This has now become: http://wiki.lyx.org/Devel/Embedding Thanks. Maybe we should have a 'New in 1.6.0' or 'PEP for 1.6.0' page. Bo
Trunk does not compile.
src/frontends/qt4/GuiView.cpp:126: error: invalid use of undefined type `struct QTabBar' /home/bpeng/lyx-devel/qt422/include/QtGui/qtabwidget.h:36: error: forward declaration of `struct QTabBar' If this is another 4.3 only stuff, please make qt 4.3 the minimal required version for lyx 1.6.0, OR install qt 4.1. If this is caused by pch or other build system tricks, Please fix the build system, or build by scons before you submit. Bo
Re: Opinion on the embedding of zip/unzip in lyx using zlib/contrib/minizip.
On Thursday 23 August 2007 15:07:47 Bo Peng wrote: Thanks. Maybe we should have a 'New in 1.6.0' or 'PEP for 1.6.0' page. For the moment I have created a category called LyX_1_6 that has two pages: embedding and xml. See http://wiki.lyx.org/Devel/Devel As soon as new pages are created the category can be changed. And yes, I would like to have one page per feature. For the moment this is not required for code cleanups (but it would be nice nevertheless). Bo -- José Abílio
Re: Trunk does not compile.
Bo Peng wrote: src/frontends/qt4/GuiView.cpp:126: error: invalid use of undefined type `struct QTabBar' /home/bpeng/lyx-devel/qt422/include/QtGui/qtabwidget.h:36: error: forward declaration of `struct QTabBar' fixed. A/
Re: cmake needs update?
On Wednesday 22 August 2007 23:53:54 Andre Poenitz wrote: I jsut tried to create a wiki page to collect all the stuff that's written here. It's currently http://wiki.lyx.org/Devel/Pages and I have no clue how I can rename this 'Pages' into somethoing like 'Build Systems'. Christian? Andre' I have moved its content to http://wiki.lyx.org/Devel/BuildSystems and I have categorised it as LyX_1_6. -- José Abílio
Re: Trunk does not compile.
Alfredo Braunstein wrote: Bo Peng wrote: src/frontends/qt4/GuiView.cpp:126: error: invalid use of undefined type `struct QTabBar' /home/bpeng/lyx-devel/qt422/include/QtGui/qtabwidget.h:36: error: forward declaration of `struct QTabBar' fixed. Thanks, sorry for the inconvenience. Abdel.
Re: Full XeTeX support
On Thursday 26 July 2007 15:36:32 Lyx user wrote: Now that Unicode is supported and everyone is looking towards version 1.6, I would like to suggest full support for XeTeX. It is currently the most comprehensive way to put Unicode characters in a TeX document. Another great feature is direct access to TrueType and OpenType fonts. LyX would have to check if XeTeX is available, and if it is, modify the font selection dialog to allow access to additional fonts. The appropriate commands would then be included in the preamble. It would also be nice to have XeTeX font selection commands (throught the fontspec package) available from the paragraph or character style dialogs. The major limitation of XeTeX right now is poor math support, but it is possible (with the nomath option) to have equations passed to plain TeX/LaTeX with the standard fonts, while having the XeTeX features available in text mode. You can see some of the capabilities of the program here: http://www.ctan.org/tex-archive/macros/xetex/latex/fontspec/fontspec.pdf I have placed this request under the wiki page: http://wiki.lyx.org/Devel/UsersRequests -- José Abílio
Re: cmake needs update?
I have moved its content to http://wiki.lyx.org/Devel/BuildSystems and I have categorised it as LyX_1_6. The discussion is still going on? Then, I chose scons for a lot of reasons, such as flexibility, platform independence. I have doubt in cmake's approach because I am not sure if cmake can achieve what we want. Conceptually, I am wondering: 1. Who is handling Package.cpp.in == Package.cpp? If cmake does it, then the generated vcproject or xcode stuff can not detect changes in Package.cpp.in. If cmakes gives this to make or vcproject, how can cmake make sure these tools can do something like this? If cmake has to re-generated a vcproject after such a change, why cmake is better than autogen.sh? 2. Along the same line, will cmake be able to do 'cmake install version_prefix=16', 'cmake install DESTDIR=destdir' in a platform independent way? If vcproject does not do installation, how would cmake do it, or trick vcproject do it? Overall, scons tries not to depend on another build system to achive maximum power, and I am not sure how cmake can achieve the same. Cheers, Bo
Re: Trunk does not compile.
Thanks, sorry for the inconvenience. So this is another pch problem??? Please try to fix cmake. Bo
Re: Trunk does not compile.
Bo Peng wrote: Thanks, sorry for the inconvenience. So this is another pch problem??? Yes. Please try to fix cmake. This is not about fixing cmake but about me not being careful enough. pch support can be disabled in CMake. In general I am careful with new header but I forgot this time. Abdel.
Re: Trunk does not compile.
Please try to fix cmake. This is not about fixing cmake but about me not being careful enough. pch support can be disabled in CMake. In general I am careful with new header but I forgot this time. This is about cmake's allowing you to compile a lyx.exe without this header. Bo
Re: cmake needs update?
Bo Peng wrote: I have moved its content to http://wiki.lyx.org/Devel/BuildSystems and I have categorised it as LyX_1_6. The discussion is still going on? Then, I chose scons for a lot of reasons, such as flexibility, platform independence. I have doubt in cmake's approach because I am not sure if cmake can achieve what we want. Conceptually, I am wondering: 1. Who is handling Package.cpp.in == Package.cpp? If cmake does it, then the generated vcproject or xcode stuff can not detect changes in Package.cpp.in. If cmakes gives this to make or vcproject, how can cmake make sure these tools can do something like this? If cmake has to re-generated a vcproject after such a change, why cmake is better than autogen.sh? I have my doubt that reconfiguring each time like Scons does is a good thing. With autogen.sh, you have to reconfigure everything IIRC; but I don't install a new compiler everyday. If a new file is added or package.cpp.in is changed, you indeed have to regenerate the vcproject, but this is almost instantaneous because CMake doesn't redo the full configuration. And MSVC will automatically reload the new vcproject. So for me, this is very effective. 2. Along the same line, will cmake be able to do 'cmake install version_prefix=16', 'cmake install DESTDIR=destdir' in a platform independent way? If vcproject does not do installation, how would cmake do it, or trick vcproject do it? I think you can trick a vcproject to do this kind of stuff with post-compile script. But that is not a good solution. In general you want to compile and debug in place (in the buid directory) not in the install directory. When you want to install, you don't really need Visual studio, I believe there is a software called CPack that do this kind of stuff. Overall, scons tries not to depend on another build system to achive maximum power, and I am not sure how cmake can achieve the same. The idea of CMake is the complete opposite: it relies on native build system to achieve maximum power i.e. it does not reinvent the wheel. Most unix software are compiled with Make, most Mac software are compiled with Make/XCode, etc. Abdel.
Re: Trunk does not compile.
Bo Peng wrote: Please try to fix cmake. This is not about fixing cmake but about me not being careful enough. pch support can be disabled in CMake. In general I am careful with new header but I forgot this time. This is about cmake's allowing you to compile a lyx.exe without this header. ??? That's the basic idea behind pch. The same thing would happen with scons I think. Abdel.
Re: Figure scaling: ugly, inefficient
On Wednesday 15 August 2007 11:05:11 Darren Freeman wrote: If nobody else puts their hand up, I might work on this some day, but currently I have other obligations :) I have a background in image processing and I would certainly offer advice to whoever works on it. It seems Darren that you the only one sufficiently annoyed by this feature to do something about it. :-) Have fun, Darren -- José Abílio
Re: Trunk does not compile.
??? That's the basic idea behind pch. The same thing would happen with scons I think. So you think this is acceptable? I did not add pch to scons because of this exact reason. I want a reliable build more than performance. Bo
Re: cmake needs update?
If a new file is added or package.cpp.in is changed, you indeed have to regenerate the vcproject, I understand how cmake works now. I think you can trick a vcproject to do this kind of stuff with post-compile script. But that is not a good solution. In general you want to compile and debug in place (in the buid directory) not in the install directory. When you want to install, you don't really need Visual studio, I believe there is a software called CPack that do this kind of stuff. So in the end, cmake is ONLY for building lyx. It can not provide a platform independent way of distributing lyx, and it will have difficulties in updating po or other stuff. The idea of CMake is the complete opposite I totally agree with you. :-) Bo
Re: Trunk does not compile.
Bo Peng wrote: ??? That's the basic idea behind pch. The same thing would happen with scons I think. So you think this is acceptable? For day to day development, yes. I did not add pch to scons because of this exact reason. I want a reliable build more than performance. On the contrary, for development I want performance first. I am sure we can add a reliable option to CMake so that everything is fine when the time comes for packaging, which doesn't happen everyday in most case. I know that scons install is nice because you can work with your development build in the final install directory. But quite frankly, launching LyX in place is fine enough for me. That might be because I don't use translation at all. Maybe even that can be cured in CMake too. Abdel.
Re: cmake needs update?
Bo Peng wrote: If a new file is added or package.cpp.in is changed, you indeed have to regenerate the vcproject, I understand how cmake works now. I think you can trick a vcproject to do this kind of stuff with post-compile script. But that is not a good solution. In general you want to compile and debug in place (in the buid directory) not in the install directory. When you want to install, you don't really need Visual studio, I believe there is a software called CPack that do this kind of stuff. So in the end, cmake is ONLY for building lyx. It can not provide a platform independent way of distributing lyx, and it will have difficulties in updating po or other stuff. I never said that. What I said is that the two tasks (development and packaging) are different and separate. Our support for packaging is weak at the moment because nobody was interested in improving it, that's all. But I am quite sure that CMake with CPack can be as good as scons for packaging, if not better. Abdel.
Re: [PATCH] Layout Modularity, Part I
Bo Peng wrote:
In my institution, because few people are willing to review others'
grant, there is a submit one, review one policy. If we adopt this rule
here, you should go ahead and review my Embedding patch. :-)
Sure...though I can't promise competence with minizip, etc.
First, could you disclose a little bit how to use this feature? Is
there a GUI to add modules?
There's no feature yet. I'm trying to follow the divide your patch into
logical bits rule. This one just reworks the infrastructure to prepare
for modules, which will come next.
cap::pasteParagraphList(cursor_, buf.paragraphs(),
-buf.params().textclass, el);
+buf.params().getTextClass_sptr(),
el);
BO: sptr means smart pointer? I prefer getTextClassPtr.
If people really want me to change all of these, I'll do so. But this
was modeled on the existing Layout_ptr.
#include vector
-
namespace lyx {
BO: I see a number of such deletions. Are they really needed?
Necessary, surely not. I was just trying to make the style consistent as
I was working.
+ ///Get the LyX TextClass---layout file---this document is using.
BO: kind of confusing: what does this xxx --xxx--xx mean?
Changed a bit.
+textclass_type defaultTextclass()
+{
+ // Initialize textclass to point to article. if `first' is
BO: Just to be picky. I see a lot of Textclass, and more TextClass...
This was copied from old code and should have been changed. And some of
them, like textclass_type, are not changed from old code, and shouldn't
be in this kind of patch. Or so I've been told.
+ /// the base TextClass associated with the document
+ textclass_type baseClass;
+ /// the possibly modular TextClass actually in use
+ TextClass_sptr textClass;
BO: I think we either use baseClass_ and getBaseClass(), or use
baseClass directly. In your patch, I do not see an advantage of using
getBaseClass() over baseClass.
Changed to baseClass_.
Index: src/TextClass_sptr.h
===
--- src/TextClass_sptr.h(revision 0)
+++ src/TextClass_sptr.h(revision 0)
BO: I can not quite follow. Why cannot this definition be put to
TextClass.h? I mean, why a separate file?
Two reasons: (i) A lot of header files only need to typedef, so we can
use this rather than including the whole of TextClass.h; (ii) somewhere
along the way, I had problems with circular includes when I tried to put
this into the main header.
The rest looks fine, but I will have to wait for your part 2 for their
uses. I can confirm that your patch compiles, but I do not know how to
test.
This should lead to no behavioral change. If LyX still works, then
that's good.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Trunk does not compile.
So you think this is acceptable? For day to day development, yes. But please try not to break the trunk. On the contrary, for development I want performance first. ... Bo
Re: cmake needs update?
I never said that. What I said is that the two tasks (development and packaging) are different and separate. Our support for packaging is weak at the moment because nobody was interested in improving it, that's all. But I am quite sure that CMake with CPack can be as good as scons for packaging, if not better. OK. I will take your word. Bo
Re: [PATCH] Layout Modularity, Part I
Sure...though I can't promise competence with minizip, etc. No. You do not have to worry about minizip. No one understands that part of the code. Use zipFiles and unzipToDir as two black boxes. There's no feature yet. I'm trying to follow the divide your patch into logical bits rule. This one just reworks the infrastructure to prepare for modules, which will come next. I was asking for a big picture. BO: sptr means smart pointer? I prefer getTextClassPtr. If people really want me to change all of these, I'll do so. But this was modeled on the existing Layout_ptr. At least remove that s. TextClass_ptr. Necessary, surely not. I was just trying to make the style consistent as I was working. Not a problem. This was copied from old code and should have been changed. And some of them, like textclass_type, are not changed from old code, and shouldn't be in this kind of patch. Or so I've been told. OK. BO: I think we either use baseClass_ and getBaseClass(), or use baseClass directly. In your patch, I do not see an advantage of using getBaseClass() over baseClass. Changed to baseClass_. Thanks. BO: I can not quite follow. Why cannot this definition be put to TextClass.h? I mean, why a separate file? Two reasons: (i) A lot of header files only need to typedef, so we can use this rather than including the whole of TextClass.h; (ii) somewhere along the way, I had problems with circular includes when I tried to put this into the main header. OK. The rest looks fine, but I will have to wait for your part 2 for their uses. I can confirm that your patch compiles, but I do not know how to test. This should lead to no behavioral change. If LyX still works, then that's good. Then you have my OK. Bo
Re: [PATCH] Layout Modularity, Part I
Abdelrazak Younes wrote: Richard Heck wrote: The pointer in question is a boost::shared_ptr. This is needed because CutAndPaste saves a copy of the layout with each cut or copied selection. We cannot assume the selection vanishes when the document is closed, so there are two options: (i) keep a list of all the layouts that have ever been used by any document; (ii) used some kind of smart pointer. The latter seems preferable, as the former would waste memory. (iii) remember layout base class _and_ module in BufferParams. Maybe the solution is to have a global TextClassModule along the global TextClassList instead of having local copies of TextClass? Or integrate the module access to the TextClassList itself? Changes to BufferParams don't help. The problem is in CutAndPaste, where we keep a copy of the TextClass in use with a given selection. Previously, it just held an index into TextClassList, and extending that would lead to solution (i). I suppose you could have some kind of next TextClass-thingy that kept a list of modules that are in use. But that presumes that the contents of the modules don't change while LyX is running---and I'd like to avoid that, since it makes layout editing a pain in the rear. Indeed, with the present change, there is no reason one cannot reload a layout file after making changes to it, something that would have been impossible before, and would still be impossible with any index-based solution. This is something that EVERYONE who has EVER done any real work on layouts desperately wants, with Steve Litt being at the head of the line. And the difficulty of creating and modifying layouts is one of the main barriers to LyX's wider acceptance. I'd say, in fact, that this is the REAL reason to use a shared pointer. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Trunk does not compile.
Bo Peng wrote: So you think this is acceptable? For day to day development, yes. But please try not to break the trunk. I am trying hard in general. Just not in this case. Abdel.
Re: [PATCH] Layout Modularity, Part I
Bo Peng wrote: There's no feature yet. I'm trying to follow the divide your patch into logical bits rule. This one just reworks the infrastructure to prepare for modules, which will come next. I was asking for a big picture. Oh, yes, then: There'll be a UI, and two LFUNs: clear-modules and set-modules, and/or maybe add-module. BO: sptr means smart pointer? I prefer getTextClassPtr. If people really want me to change all of these, I'll do so. But this was modeled on the existing Layout_ptr. At least remove that s. TextClass_ptr. Done. I'll look at your patch tonight. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] Layout Modularity, Part I
Richard Heck wrote: Abdelrazak Younes wrote: Richard Heck wrote: The pointer in question is a boost::shared_ptr. This is needed because CutAndPaste saves a copy of the layout with each cut or copied selection. We cannot assume the selection vanishes when the document is closed, so there are two options: (i) keep a list of all the layouts that have ever been used by any document; (ii) used some kind of smart pointer. The latter seems preferable, as the former would waste memory. (iii) remember layout base class _and_ module in BufferParams. Maybe the solution is to have a global TextClassModule along the global TextClassList instead of having local copies of TextClass? Or integrate the module access to the TextClassList itself? Changes to BufferParams don't help. The problem is in CutAndPaste, where we keep a copy of the TextClass in use with a given selection. Yes, the copy is in fact in the temporary Buffer created in put/pasteClipbaord. I understand that passing the TextClass is not nice but maybe the solution is to store the temporary Buffer instead of discarding it? This would avoid the writing/reading of the clipboard for cutpaste: - buffer.write(lyx) in putClipboard() - theClipboard().getAsLyX() in pasteClipboard(). Previously, it just held an index into TextClassList, and extending that would lead to solution (i). I suppose you could have some kind of next TextClass-thingy that kept a list of modules that are in use. But that presumes that the contents of the modules don't change while LyX is running Why that? If we point to the relevant module, why would you want to discard changes in the contents of the modules. Sorry, I am an absolute beginners with layouts. ---and I'd like to avoid that, since it makes layout editing a pain in the rear. I take your word but I don't really understand the problem. Indeed, with the present change, there is no reason one cannot reload a layout file after making changes to it, something that would have been impossible before, and would still be impossible with any index-based solution. This is something that EVERYONE who has EVER done any real work on layouts desperately wants, with Steve Litt being at the head of the line. And the difficulty of creating and modifying layouts is one of the main barriers to LyX's wider acceptance. I'd say, in fact, that this is the REAL reason to use a shared pointer. Don't need to shout, I trust you ;-) I was just discussing the implementation detail. I am fine with whatever approach you choose at the end. Sorry about that, Abdel.
Re: [PATCH] Layout Modularity, Part I
Abdelrazak Younes wrote: Richard Heck wrote: (iii) remember layout base class _and_ module in BufferParams. Maybe the solution is to have a global TextClassModule along the global TextClassList instead of having local copies of TextClass? Or integrate the module access to the TextClassList itself? Changes to BufferParams don't help. The problem is in CutAndPaste, where we keep a copy of the TextClass in use with a given selection. Yes, the copy is in fact in the temporary Buffer created in put/pasteClipbaord. I understand that passing the TextClass is not nice but maybe the solution is to store the temporary Buffer instead of discarding it? In effect, this would mean that this: typedef limited_stackpairParagraphList, textclass_type CutStack; is replaced by this: typedef limited_stackBuffer CutStack; IIUC, the TextClass problem would vanish by itself, won't it? Maybe it is worth it? Abdel.
Re: [PATCH] Layout Modularity, Part I
Abdelrazak Younes wrote: Previously, it just held an index into TextClassList, and extending that would lead to solution (i). I suppose you could have some kind of next TextClass-thingy that kept a list of modules that are in use. But that presumes that the contents of the modules don't change while LyX is running Why that? If we point to the relevant module, why would you want to discard changes in the contents of the modules. Sorry, I am an absolute beginners with layouts. You modify it on disk, then want to see the changes. ---and I'd like to avoid that, since it makes layout editing a pain in the rear. I take your word but I don't really understand the problem. As things are, every time you modify the layout, you have to close and restart LyX. Very painful. Worse than autotools. ;-) Indeed, with the present change, there is no reason one cannot reload a layout file after making changes to it, something that would have been impossible before, and would still be impossible with any index-based solution. This is something that EVERYONE who has EVER done any real work on layouts desperately wants, with Steve Litt being at the head of the line. And the difficulty of creating and modifying layouts is one of the main barriers to LyX's wider acceptance. I'd say, in fact, that this is the REAL reason to use a shared pointer. Don't need to shout, I trust you ;-) I was shouting for me. I only just realized this application, and how important it is. Thanks for pushing me. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Full XeTeX support
To learn more about XeTeX, see also this video: http://www.river-valley.tv/conferences/tex/tug2007/#Jonathan_Kew2 Regards, Asger
Re: cmake needs update?
On Wed, Aug 22, 2007 at 08:56:36PM -0500, Bo Peng wrote: On 8/22/07, Andre Poenitz [EMAIL PROTECTED] wrote: On Wed, Aug 22, 2007 at 04:26:23PM -0500, Bo Peng wrote: How do I create such a .vcproj file? I'd like to have a look... Under development/scons, run 'scons mode=debug msvs_projects' and double click the generated lyx.vcproject file. You will have to (?) run 'scons intall' before you can debug in msvs. [EMAIL PROTECTED]:/suse/usr/src/lyx/scons-msvc scons -f ../trunk/development/scons/SConstruct mode=release msvs_projects Read what I wrote Under development/scons, run'. Aehm. Where? Neither the source nor the Wiki seems to match... Andre'
Re: cmake needs update?
On Wed, Aug 22, 2007 at 10:15:12PM -0500, Bo Peng wrote: Right now a scon null release build is 32 seconds, autotools is 18 seconds on my machine. Given that one of the main reasons to abolish autotools is to reduce development roundtrip times this does not bode well... This is not a fair comparison because scons null ~ autogen.sh + configure + make + ccache. Anyway, I have submitted a patch to improve scons' efficiency. On my machine, $ time scons --implicit-deps-unchanged 8.374u 0.330s 0:08.71 99.8% 0+0k 0+0io 0pf+0w $ time scons 11.755u 0.387s 0:12.15 99.8%0+0k 0+0io 0pf+0w $ time make 8.034u 0.538s 0:08.60 99.5% 0+0k 0+0io 0pf+0w Good. scons --implicit-deps-unchanged uses cached dependency, roughly like what make is doing, and has similar performance. A complete null build takes scons 2-3 second more, a reasonable amount of time. That depends on whether we talk on 2 seconds on top of 8 seconds or 2 seconds on top of 2 minutes... Anyway, good to see improvements.A Just from a user's point of view: Do I really have to give the full scons commandline or is there some kind of shortcut once the thing is build already. scons --implicit-deps-unchanged -f ../trunk/development/scons/SConstruct mode=release is impractical, and having shell aliases for every imaginable target probably isn't either. Andre'
Re: [PATCH] Layout Modularity, Part I
On Wed, Aug 22, 2007 at 11:03:24PM -0500, Bo Peng wrote: In my institution, because few people are willing to review others' grant, there is a submit one, review one policy. If we adopt this rule here, you should go ahead and review my Embedding patch. :-) First, could you disclose a little bit how to use this feature? Is there a GUI to add modules? cap::pasteParagraphList(cursor_, buf.paragraphs(), - buf.params().textclass, el); + buf.params().getTextClass_sptr(), el); BO: sptr means smart pointer? I prefer getTextClassPtr. I too. Andre'
Re: cmake needs update?
Aehm. Where? Neither the source nor the Wiki seems to match... Under development/scons, run 'scons mode=debug msvs_projects' and HERE. and INSTALL.scons. double click the generated lyx.vcproject file. You will have to (?) run 'scons intall' before you can debug in msvs. Also, I just tested the performance of scons under linux: Full build: scons/autotools = 0.51, so scons is twice as fast as autotools under linux. This is true for single and multi-thread (-j6) builds. I guess autotools spend too much time on if/else/libtool. Cheers, Bo
Re: cmake needs update?
Just from a user's point of view: Do I really have to give the full scons commandline or is there some kind of shortcut once the thing is build already. scons --implicit-deps-unchanged -f ../trunk/development/scons/SConstruct mode=release --implicit-deps-unchanged is not recommended. Best to spend this 2 seconds. -f ../trunk/development/scons/SConstruct can be shortened or removed if you ln -s development/scons/SConstruct to top source directory. I usually do this and build from the top source directory. scons will build in debug or release subdirectory and will not mess up with src in any way. All other options are cached, so I always do 'scons install -j4' after the first successful run. is impractical, and having shell aliases for every imaginable target probably isn't either. I prefer 'scons intall', which builds lyx, tex2lyx, client and install. Because scons only build and install changed stuff, it is fast. You can do 'scons lyx' or 'scons tex2lyx' if you do not want to copy debug/lyx16.exe to /usr/local/bin/lyx16.exe (my case). Bo
Re: r19659 - /lyx-devel/trunk/src/frontends/qt4/ui/CitationUi.ui
On Thu, Aug 23, 2007 at 01:11:52PM +0200, Georg Baum wrote: You still don't get it. All your arguments including this one and that in your other mail are based on the assumption that there were only two alternatives: full support or removal from trunk. Under this premise I agree completely with the removal, but that is not what has been requested. There was a third alternative that would have solved almost all problems: Keep it in trunk (with no obligation of anyone to touch it), and let those who care do the work to keep it up to date. With that alternative all your arguments are moot. No. Because even without obligation most people still would have tried to to put stuff in both frontends - even if they had no real interest in the qt3 frontend - just because they try to be nice. And those resources would not have been available anymore for other work. 1.5 was the first release in a decade that had lots of new GUI stuff. Releases form 0.10 on or so before 1.5 had much smaller GUI changes, and that's not just changes for the sake of changes but as real improvement. I am pretty sure some of this would not have happened if multiple frontends had stayed around. That alternative would of course not have guaranteed that 1.5.0 would be released with qt3. Maybe it would indeed have been too much work to keep it up to date, and it would have been abandoned, but this would then have been the decision of _those who where doing the work_. You miss the point that we do not have unlimited resources. If qt3 lived on for a while and had been killed later even more resources would have gone to the kitchen sink. What happened instead is that _you_ dictated that those should stop or jump through some extra hoops. And you haven't been in Greve to prevent it... Andre'
Re: selective 'monolithic builds' for autotools
On Thu, Aug 23, 2007 at 02:22:45PM +0100, José Matos wrote:
On Saturday 18 August 2007 23:52:00 Andre Poenitz wrote:
Typical use would be to have such --enable-monolithic-* for
{core,mathed,insets,controllers,frontends,qt4,tex2lyx,client,boost}
implemented and 'switched on' for all the areas one is not currently
working on (or invert that logic at some point of time).
Do you intend to commit this?
Part of the --enable-monolithic are already in trunk (controllers,
boost, tex2lyx and client). Visible behaviour is unchanged for people
not using these switches.
Andre'
Re: cmake needs update?
On Thu, Aug 23, 2007 at 03:37:03PM +0100, José Matos wrote: On Wednesday 22 August 2007 23:53:54 Andre Poenitz wrote: I jsut tried to create a wiki page to collect all the stuff that's written here. It's currently http://wiki.lyx.org/Devel/Pages and I have no clue how I can rename this 'Pages' into somethoing like 'Build Systems'. Christian? Andre' I have moved its content to http://wiki.lyx.org/Devel/BuildSystems and I have categorised it as LyX_1_6. Thanks. Andre'
Re: [Updated PATCH] BufferView/WorkArea/LyXView reorg a.k.a Multiple WorkAreas
On Thu, Aug 23, 2007 at 11:09:49AM +0200, Abdelrazak Younes wrote: Enrico Forestieri wrote: Nuisance: - Even with only one file opened, a toolbar with a tab appears. This is fixed. Ok, thanks. Problems: - The main window bar does not show the filename of a loaded file. However, after opening another file, the name shows up. I don't see this bug. It is no more there, probably fixed as a side effect of some other change. - The list of recently opened files is not updated. This is fixed. Ok, thanks. Another problem: lyx allows opening multiple times the same file. And there's still the crash with Qt 4.1 when opening a second file. This does not happen with X11, only on Windows. I by far prefer Qt 4.1 over recent versions, so I would be grateful if you could solve this problem. Alternatively, Qt 4.2 should be declared as the oldest supported version. Oh, wait a moment, given that the close tab button works with Qt 4.3.0, maybe we should not support anything less than that. Hmm, on second thought, it is better requiring Qt 4.3.1 which has already been released. -- Enrico
Re: [PATCH] Layout Modularity, Part I
Andre Poenitz wrote: I too. Andre' You tooed too much already! A/
[O-T?] Renaming a page (Was: cmake needs update?)
On Thu, 23 Aug 2007, Andre Poenitz wrote: I jsut tried to create a wiki page to collect all the stuff that's written here. It's currently http://wiki.lyx.org/Devel/Pages and I have no clue how I can rename this 'Pages' into somethoing like 'Build Systems'. Christian? I saw that Martin already did this ;-) ;-) ;-) Sorry, I'm just kidding Jose', I know you did it. :-) Anyway, for Andre's future reference: To rename a page, you do it the stupid way, i.e. cut the content from the original page and then paste it into the new page. Finally you delete the old page by inserting the text delete and only that text into the page. As a note, the page isn't really deleted, it's still retrievable by an administrator. /Christian PS. I now this way of renaming pages sucks. -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: cmake needs update?
On Thu, Aug 23, 2007 at 09:57:04AM -0500, Bo Peng wrote: I have moved its content to http://wiki.lyx.org/Devel/BuildSystems and I have categorised it as LyX_1_6. The discussion is still going on? Sure. My plan is to come to a conclusion within a few weeks. Then, I added this to the 'Opinions' section in the Wiki. I chose scons for a lot of reasons, such as flexibility, platform independence. I have doubt in cmake's approach because I am not sure if cmake can achieve what we want. Conceptually, I am wondering: If have no idea how cmake works, so hopefully Peter will answer sometime in greter detail. I try to asnwer according to my current knowledge. 1. Who is handling Package.cpp.in == Package.cpp? If cmake does it, then the generated vcproject or xcode stuff can not detect changes in Package.cpp.in. If cmakes gives this to make or vcproject, how can cmake make sure these tools can do something like this? Right now it looks like cmake does it. There is code in development/cmake/src/support/CMakeLists.txt suggesting that, and if you try you'll notice that Package.C is re-created once Package.cpp.in is changed. So it 'works'. If cmake has to re-generated a vcproject after such a change, why cmake is better than autogen.sh? autogen.sh has to be run in the source tree. CMake (and scon, and qmake for that matter) do not require changes to the source tree. Apart from that the main reason to search a replacement is Speed. 2. Along the same line, will cmake be able to do 'cmake install version_prefix=16', 'cmake install DESTDIR=destdir' in a platform independent way? If vcproject does not do installation, how would cmake do it, or trick vcproject do it? By definition, there is no platform independent installation, so I wonder what exactly the requirements are here. (And of course I have no clue how cmake manages it. But KDE uses cmake and runs on Windows and is a bit more complex than LyX, so I doubt there's a problem) Overall, scons tries not to depend on another build system to achive maximum power, and I am not sure how cmake can achieve the same. I guess more people are likely to agree on the opposite, namely that e.g. a generated .vcproj file should be something that feels 'native' when using in Visual Studio. For running cl on the command line one does not need a .vcproj file. [But I have still to see a scons generated .vcproj file to get an impression how it works] Andre'
Re: cmake needs update?
On Thu, 23 Aug 2007, José Matos wrote: On Wednesday 22 August 2007 23:53:54 Andre Poenitz wrote: I jsut tried to create a wiki page to collect all the stuff that's written here. It's currently http://wiki.lyx.org/Devel/Pages and I have no clue how I can rename this 'Pages' into somethoing like 'Build Systems'. Christian? Andre' I have moved its content to http://wiki.lyx.org/Devel/BuildSystems I edited the page and added a link to this thread, just in case. /C -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: r19659 - /lyx-devel/trunk/src/frontends/qt4/ui/CitationUi.ui
On Wed, Aug 22, 2007 at 12:51:36AM +0200, Andre Poenitz wrote: On Tue, Aug 21, 2007 at 10:35:46PM +0200, Enrico Forestieri wrote: 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. Poor little thing still lives a zombie life in the repository. Check it out, dool it up, and be happy. Given your rude behaviour, I will simply let you stew in your own juice. -- Enrico
Re: [PATCH] Simplify bookmars handling and further improvments...
On Thu, Aug 23, 2007 at 01:05:27PM +0200, Alfredo Braunstein wrote: 2) one idea would be to use a special mark inset. This would solve b) but not a). Aditionally, this implies that we have an undesired object that obstacles edition. We could try to track its existence with a signal in its dtor, but seems difficult to readjust correctly (in particular hard to avoid a large number of operations when a large block gets inserted/deleted etc) [...] I've rethink about it, and I think that there's a plausible solution near 2) that requires much less work. The idea is the following: we have special marks inside the insetlist inside paragraphs, administrated by insetlist. They don't occupy editing space, but are adjusted as insets on edition. They are also centrally registerd (smart pointers or such). On deletion, (be it because the position is deleted, or because the paragraph is), they signal their deletion to the central register. Interesting idea actually. Once after each user edition (in some central dispatch), all newly deleted marks are repositioned in the cursor position of the cursor [of the Bufferview] that made the edition (this is ok, because we already track this cursor position in edit routines, and all 'deleted' positions collapse in the final cursor position). 'Newly deleted marks'? What about this? Might work ;-) Andre'
Re: Full XeTeX support
On Thu, 23 Aug 2007, José Matos wrote: On Thursday 26 July 2007 15:36:32 Lyx user wrote: Now that Unicode is supported and everyone is looking towards version 1.6, I would like to suggest full support for XeTeX. It is currently the most comprehensive way to put Unicode characters in a TeX document. Another great feature is direct access to TrueType and OpenType fonts. LyX would have to check if XeTeX is available, and if it is, modify the font selection dialog to allow access to additional fonts. The appropriate commands would then be included in the preamble. It would also be nice to have XeTeX font selection commands (throught the fontspec package) available from the paragraph or character style dialogs. The major limitation of XeTeX right now is poor math support, but it is possible (with the nomath option) to have equations passed to plain TeX/LaTeX with the standard fonts, while having the XeTeX features available in text mode. You can see some of the capabilities of the program here: http://www.ctan.org/tex-archive/macros/xetex/latex/fontspec/fontspec.pdf I have placed this request under the wiki page: http://wiki.lyx.org/Devel/UsersRequests Umm... shouldn't it go into bugzilla? If we want to show them on a wiki page, we could tag them in someway (or a special search), and have that embedded in a wiki page? Jose', are you going all wiki wiki on us? ;-) /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: cmake needs update?
On Thu, Aug 23, 2007 at 10:34:23AM -0500, Bo Peng wrote: If a new file is added or package.cpp.in is changed, you indeed have to regenerate the vcproject, I understand how cmake works now. I think you can trick a vcproject to do this kind of stuff with post-compile script. But that is not a good solution. In general you want to compile and debug in place (in the buid directory) not in the install directory. When you want to install, you don't really need Visual studio, I believe there is a software called CPack that do this kind of stuff. So in the end, cmake is ONLY for building lyx. We are talking about a complete solution. But yes, building is the focus. It can not provide a platform independent way of distributing lyx, There is no 'platform independent way of distribution'. Windows won't like .rpm, Ubuntu won't like .msi. and it will have difficulties in updating po or other stuff. The 'po issue' was not on the table so far. Are you trying to say 'scons does that and cmake not'? [Which might be true, I don't know...] Andre'
Build trouble
In order to build, I have to use the attached in src/support. Would somebody please draw the appropriate lessons? (Age old Fedora) ;-) - Martin Index: filetools.cpp === --- filetools.cpp (revision 19756) +++ filetools.cpp (working copy) @@ -68,12 +68,12 @@ #ifdef HAVE_SYS_UTIME_H # include sys/utime.h #endif -#ifdef HAVE_UTIME_H +//#ifdef HAVE_UTIME_H # include utime.h -#endif +//#endif -#include zip.h -#include unzip.h +#include minizip/zip.h +#include minizip/unzip.h #ifdef WIN32 #define USEWIN32IOAPI Index: Makefile.am === --- Makefile.am (revision 19756) +++ Makefile.am (working copy) @@ -101,7 +101,7 @@ minizip/zip.c \ minizip/zip.h -if INSTALL_WINDOWS +if LYX_WIN_RESOURCE liblyxsupport_la_SOURCES += \ minizip/iowin32.c \ minizip/iowin32.h
Re: cmake needs update?
Right now it looks like cmake does it. Yes. cmake re-generates the project file/make files when Package.cpp.in is changed, or a file is added. It is faster than autogen.sh and configure. The difference is that cmake is a 'two step' system, and scons is 'one-step' (and autotools is a 'three step' system). By definition, there is no platform independent installation, so I wonder what exactly the requirements are here. (And of course I have no clue how cmake manages it. But KDE uses cmake and runs on Windows and is a bit more complex than LyX, so I doubt there's a problem) Abdel says cmake uses something calls cpack for installation. This makes cmake a 'three step' system. :-) I guess more people are likely to agree on the opposite, namely that e.g. a generated .vcproj file should be something that feels 'native' when using in Visual Studio. I am old fashioned, and have not yet appreciated the convenience of a GUI. :-) (Also because I try to avoid MS products). For running cl on the command line one does not need a .vcproj file. [But I have still to see a scons generated .vcproj file to get an impression how it works] It works as usually, just calls scons to build lyx, which is slower than the native nmake code that cmake generates. A sligh advantage is that if you change Package.cpp.in, there is no need to regenerate the project file. Bo
Re: [PATCH] Layout Modularity, Part I
On Thu, Aug 23, 2007 at 11:40:08AM -0400, Richard Heck wrote: Bo Peng wrote: In my institution, because few people are willing to review others' grant, there is a submit one, review one policy. If we adopt this rule here, you should go ahead and review my Embedding patch. :-) Sure...though I can't promise competence with minizip, etc. First, could you disclose a little bit how to use this feature? Is there a GUI to add modules? There's no feature yet. I'm trying to follow the divide your patch into logical bits rule. This one just reworks the infrastructure to prepare for modules, which will come next. That's very nice, and the fist chunk is ok, so it can be applied. I guess Bo just wanted to see the 'Big Picture' first... cap::pasteParagraphList(cursor_, buf.paragraphs(), - buf.params().textclass, el); + buf.params().getTextClass_sptr(), el); BO: sptr means smart pointer? I prefer getTextClassPtr. If people really want me to change all of these, I'll do so. But this was modeled on the existing Layout_ptr. I guess I'll just rename Layout_ptr into LayoutPtr to avoid this in the furture. Andre'
Re: [PATCH] Layout Modularity, Part I
On Thu, Aug 23, 2007 at 10:50:41AM -0500, Bo Peng wrote: Sure...though I can't promise competence with minizip, etc. No. You do not have to worry about minizip. No one understands that part of the code. Use zipFiles and unzipToDir as two black boxes. There's no feature yet. I'm trying to follow the divide your patch into logical bits rule. This one just reworks the infrastructure to prepare for modules, which will come next. I was asking for a big picture. BO: sptr means smart pointer? I prefer getTextClassPtr. If people really want me to change all of these, I'll do so. But this was modeled on the existing Layout_ptr. At least remove that s. TextClass_ptr. TextClassPtr please. Hurts my eyes less. Andre'
Re: cmake needs update?
On Wed, 22 Aug 2007, Joost Verburg wrote: Bo Peng wrote: It would be good to use one build system, but the current situation is that none of them work best under all situations, and for all developers. Abdel and other MSVS users obviously need cmake, linux gurus prefer autotools. I think the currently situation is acceptable as long as the build systems can be updated easily. Of course, if, for example, nobody else understands cmake and Peter decides not to support it, it will die naturally. While cmake can create MSVC projects, the current implementation does not handle all the dependencies like scons does. For example, the thesaurus is not supported. To create Windows releases, scons in the only option right now. Umm... sorry if I've asked this before, but I thought the installer could use a Windows executable of LyX that's been created with any build system on Windows? What am I missing? /Christian Ps. Real life grabbed me and has yanked me into a dark alley, thus claiming my spare time. Next week part of RL called work will instead throw me out to sea for two weeks, and thus off-line for a while. -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Build trouble
On Thu, Aug 23, 2007 at 10:19:47PM +0300, Martin Vermeer wrote: In order to build, I have to use the attached in src/support. Would somebody please draw the appropriate lessons? (Age old Fedora) ;-) autogen.sh -- Enrico
Re: cmake needs update?
It can not provide a platform independent way of distributing lyx, There is no 'platform independent way of distribution'. Windows won't like .rpm, Ubuntu won't like .msi. I meant a uniform interface. I will be able to do 'scons rpm' under *nix, and 'scons msi' under windows. I do not know what cmake will do. It is likely to be 'cmake; cpack; rpmbuild'. and it will have difficulties in updating po or other stuff. The 'po issue' was not on the table so far. Are you trying to say 'scons does that and cmake not'? [Which might be true, I don't know...] Currently, scons can and cmake cannot. I brought up this issue because cmake depends on others to build but I do not know who will update po. cmake, or cpack? Bo
Re: [PATCH] Simplify bookmars handling and further improvments...
Andre Poenitz wrote: On Thu, Aug 23, 2007 at 01:05:27PM +0200, Alfredo Braunstein wrote: 2) one idea would be to use a special mark inset. This would solve b) but not a). Aditionally, this implies that we have an undesired object that obstacles edition. We could try to track its existence with a signal in its dtor, but seems difficult to readjust correctly (in particular hard to avoid a large number of operations when a large block gets inserted/deleted etc) [...] I've rethink about it, and I think that there's a plausible solution near 2) that requires much less work. The idea is the following: we have special marks inside the insetlist inside paragraphs, administrated by insetlist. They don't occupy editing space, but are adjusted as insets on edition. They are also centrally registerd (smart pointers or such). On deletion, (be it because the position is deleted, or because the paragraph is), they signal their deletion to the central register. Interesting idea actually. Once after each user edition (in some central dispatch), all newly deleted marks are repositioned in the cursor position of the cursor [of the Bufferview] that made the edition (this is ok, because we already track this cursor position in edit routines, and all 'deleted' positions collapse in the final cursor position). 'Newly deleted marks'? I mean, all marks with 'deleted' flag. On repositioning, the flag is cleared, so at the end of the repositioning (and this is once after each dispatch) there are no more deleted marks. What about this? Might work ;-) I'll give it a shot when I find some time. ;-) A/
Re: Full XeTeX support
On Thu, Aug 23, 2007 at 07:02:52PM +0200, Asger Ottar Alstrup wrote: To learn more about XeTeX, see also this video: http://www.river-valley.tv/conferences/tex/tug2007/#Jonathan_Kew2 Nice. Looks like a really intresting development. Andre'
Please sign your changes to wiki pages
As the subject says. If you do, I'm less inclined to suspect spam activities, i.e. less work for me. /Christian PS. I haven't seen any spam attacks in a long while... *knock on wood* -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Full XeTeX support
On Thursday 23 August 2007 20:13:35 [EMAIL PROTECTED] wrote: Umm... shouldn't it go into bugzilla? Yes. :-) If we want to show them on a wiki page, we could tag them in someway (or a special search), and have that embedded in a wiki page? And so I did. Have you seen http://wiki.lyx.org/Devel/UsersRequests? Jose', are you going all wiki wiki on us? ;-) Not, unless it is all in python. ;-) Now that you mention trac has some other possibilities... just joking. :-) /Christian -- José Abílio
Re: [Updated PATCH] BufferView/WorkArea/LyXView reorg a.k.a Multiple WorkAreas
On Thursday 23 August 2007 19:49:07 Enrico Forestieri wrote: Hmm, on second thought, it is better requiring Qt 4.3.1 which has already been released. -- Enrico Why, is that a problem? ;-) $ rpm -qi qt4 Name: qt4 Relocations: (not relocatable) Version : 4.3.1 Vendor: Fedora Project Release : 2.fc7 Build Date: Mon 13 Aug 2007 01:23:12 AM WEST Install Date: Wed 15 Aug 2007 11:42:54 AM WEST Build Host: xenbuilder2.fedora.redhat.com Group : System Environment/Libraries Source RPM: qt4-4.3.1-2.fc7.src.rpm Size: 5600420 License: GPLv2 Signature : DSA/SHA1, Mon 13 Aug 2007 03:34:35 PM WEST, Key ID da84cbd430c9ecf8 Packager: Fedora Project URL : http://www.trolltech.com/products/qt/ Summary : Qt toolkit Description : Qt is a software toolkit for developing applications. This package contains base tools, like string, xml, and network handling. And this coming from the same person that packages lyx for Fedora (Rex Dieter). :-) -- José Abílio
Re: cmake needs update?
The discussion is still going on? Sure. My plan is to come to a conclusion within a few weeks. Note that in a few weeks, scons should be able to do 'scons rpm', 'scons sdist' etc, using a snapshot version of scons (Jose will hate this. :-). Bo
Re: r19659 - /lyx-devel/trunk/src/frontends/qt4/ui/CitationUi.ui
On Thursday 23 August 2007 19:30:19 Andre Poenitz wrote: On Thu, Aug 23, 2007 at 01:11:52PM +0200, Georg Baum wrote: That alternative would of course not have guaranteed that 1.5.0 would be released with qt3. Maybe it would indeed have been too much work to keep it up to date, and it would have been abandoned, but this would then have been the decision of _those who where doing the work_. You miss the point that we do not have unlimited resources. Honestly I am not sure that would have so worse. And Georg agreed that qt3 was only for 1.5.x. If qt3 lived on for a while and had been killed later even more resources would have gone to the kitchen sink. What happened instead is that _you_ dictated that those should stop or jump through some extra hoops. And you haven't been in Greve to prevent it... Greve has not our best showcase. Clearly this was a consequence of 1.4 but I think that we have learned the lesson and I hope the best for lyx 2.0 (oops I mean 1.6). Andre' -- José Abílio
Re: Build trouble
On Thu, Aug 23, 2007 at 09:22:08PM +0200, Enrico Forestieri wrote: On Thu, Aug 23, 2007 at 10:19:47PM +0300, Martin Vermeer wrote: In order to build, I have to use the attached in src/support. Would somebody please draw the appropriate lessons? (Age old Fedora) ;-) autogen.sh -- Enrico Could swear that I had done that... second time around it bit ;-/ Update: At least in src/support. In src/frontends/controllers I still get makefile errors on MONOLITHIC_CONTROLLERS, and in qt4 on MONOLITHIC_FRONTEND_QT4. Even when trying a couple of times. Ah well. - Martin
Re: cmake needs update?
On Thursday 23 August 2007 20:54:57 Bo Peng wrote: Note that in a few weeks, scons should be able to do 'scons rpm', 'scons sdist' etc, using a snapshot version of scons (Jose will hate this. :-). Let us pretend that I did not hear this. ;-) Bo -- José Abílio
Re: cmake needs update?
[EMAIL PROTECTED] wrote: While cmake can create MSVC projects, the current implementation does not handle all the dependencies like scons does. For example, the thesaurus is not supported. To create Windows releases, scons in the only option right now. Umm... sorry if I've asked this before, but I thought the installer could use a Windows executable of LyX that's been created with any build system on Windows? Sure. If cmake is able to generate an executable linked to all dependencies, I can use it instead. Currently only scons can do that. Joost
Re: cmake needs update?
On Thu, Aug 23, 2007 at 01:28:19PM -0500, Bo Peng wrote: Just from a user's point of view: Do I really have to give the full scons commandline or is there some kind of shortcut once the thing is build already. scons --implicit-deps-unchanged -f ../trunk/development/scons/SConstruct mode=release --implicit-deps-unchanged is not recommended. Best to spend this 2 seconds. -f ../trunk/development/scons/SConstruct can be shortened or removed if you ln -s development/scons/SConstruct to top source directory. So scons -f ../trunk/SConstruct remains? In that case I'd prefer alias sc='scons -f ../trunk/development/scons/SConstruct' usually do this and build from the top source directory. scons will build in debug or release subdirectory and will not mess up with src in any way. All other options are cached, so I always do 'scons install -j4' after the first successful run. Ok. is impractical, and having shell aliases for every imaginable target probably isn't either. I prefer 'scons intall', which builds lyx, tex2lyx, client and install. Because scons only build and install changed stuff, it is fast. You can do 'scons lyx' or 'scons tex2lyx' if you do not want to copy debug/lyx16.exe to /usr/local/bin/lyx16.exe (my case). Well, I certainly do not want to have my stuff installed just because I happend to build it... Andre'
Re: [Updated PATCH] BufferView/WorkArea/LyXView reorg a.k.a Multiple WorkAreas
On Thu, Aug 23, 2007 at 08:52:00PM +0100, José Matos wrote: On Thursday 23 August 2007 19:49:07 Enrico Forestieri wrote: Hmm, on second thought, it is better requiring Qt 4.3.1 which has already been released. -- Enrico Why, is that a problem? ;-) Not at all. $ ./src/lyx.exe -version LyX 1.6.0svn (not released yet) Built on Aug 23 2007, 16:51:59 Configuration Host type:i686-pc-cygwin Special build flags: aiksaurus assertions warnings use-aspell use-ispell C Compiler: gcc C Compiler LyX flags: C Compiler flags: -pipe -O2 C++ Compiler: g++ (3.4.4) C++ Compiler LyX flags: C++ Compiler flags: -pipe -O2 Linker flags: Linker user flags: -L/usr/local/lib Qt 4 Frontend: Qt 4 version: 4.3.1 Packaging:posix LyX binary dir: /usr/local/bin LyX files dir:/usr/local/share/lyx-1.6.0svn On third thought, maybe we should only allow Qt snaspshots, just to be sure. Don't we already use boost snapshots? -- Enrico
Re: Build trouble
On Thu, Aug 23, 2007 at 10:19:47PM +0300, Martin Vermeer wrote: In order to build, I have to use the attached in src/support. Would somebody please draw the appropriate lessons? (Age old Fedora) ;-) - Martin Index: filetools.cpp === --- filetools.cpp (revision 19756) +++ filetools.cpp (working copy) @@ -68,12 +68,12 @@ #ifdef HAVE_SYS_UTIME_H # include sys/utime.h #endif -#ifdef HAVE_UTIME_H +//#ifdef HAVE_UTIME_H # include utime.h -#endif +//#endif So you have utime.h but it's not picked up by autoconf? This should not happen. Could you just try to run autogen.sh/configure again? -#include zip.h -#include unzip.h +#include minizip/zip.h +#include minizip/unzip.h Also Makefile.am says that minizip is in the path... #ifdef WIN32 #define USEWIN32IOAPI Index: Makefile.am === --- Makefile.am (revision 19756) +++ Makefile.am (working copy) @@ -101,7 +101,7 @@ minizip/zip.c \ minizip/zip.h -if INSTALL_WINDOWS +if LYX_WIN_RESOURCE liblyxsupport_la_SOURCES += \ minizip/iowin32.c \ minizip/iowin32.h I guess this can now be added unconditionally as I have added #ifdef WIN32 to the files.
Re: Build trouble
On Thu, Aug 23, 2007 at 11:00:57PM +0300, Martin Vermeer wrote: On Thu, Aug 23, 2007 at 09:22:08PM +0200, Enrico Forestieri wrote: On Thu, Aug 23, 2007 at 10:19:47PM +0300, Martin Vermeer wrote: In order to build, I have to use the attached in src/support. Would somebody please draw the appropriate lessons? (Age old Fedora) ;-) autogen.sh -- Enrico Could swear that I had done that... second time around it bit ;-/ Update: At least in src/support. In src/frontends/controllers I still get makefile errors on MONOLITHIC_CONTROLLERS, and in qt4 on MONOLITHIC_FRONTEND_QT4. Even when trying a couple of times. Ah well. Try also reconfiguring explicitly. -- Enrico
Re: [Updated PATCH] BufferView/WorkArea/LyXView reorg a.k.a Multiple WorkAreas
Enrico Forestieri wrote: On Thu, Aug 23, 2007 at 11:09:49AM +0200, Abdelrazak Younes wrote: Another problem: lyx allows opening multiple times the same file. Really? I'll have a look... Do you mean multiple BufferView or multiple Buffer? The later would be embarrassing. And there's still the crash with Qt 4.1 when opening a second file. This does not happen with X11, only on Windows. Weird. I by far prefer Qt 4.1 over recent versions, so I would be grateful if you could solve this problem. I'll try but this will take some time as I have to install and compile 4.1. Abdel.
Re: cmake needs update?
On Thu, Aug 23, 2007 at 10:19:28PM +0200, Joost Verburg wrote: [EMAIL PROTECTED] wrote: While cmake can create MSVC projects, the current implementation does not handle all the dependencies like scons does. For example, the thesaurus is not supported. To create Windows releases, scons in the only option right now. Umm... sorry if I've asked this before, but I thought the installer could use a Windows executable of LyX that's been created with any build system on Windows? Sure. If cmake is able to generate an executable linked to all dependencies, I can use it instead. Currently only scons can do that. No, mingw works, too. -- Enrico
Re: cmake needs update?
So scons -f ../trunk/SConstruct remains? I guess you get use to the autotools way of using VPATH build. In scons, you can call scons from top source directory, and build lyx to any specified directory (default to debug or release with mode=debug or mode=release, can be specified with build_dir=anydir). There is no need to go to a subdirectory to build. I prefer 'scons intall', which builds lyx, tex2lyx, client and install. Because scons only build and install changed stuff, it is fast. You can do 'scons lyx' or 'scons tex2lyx' if you do not want to copy debug/lyx16.exe to /usr/local/bin/lyx16.exe (my case). Well, I certainly do not want to have my stuff installed just because I happend to build it... You can use 'scons DESTDIR=lyx1.6-install' to install to another directory. It is best to also use 'version_suffix=16' to avoid messing up your ~/.lyx directory. Bo
Re: cmake needs update?
On Thu, Aug 23, 2007 at 02:18:12PM -0500, Bo Peng wrote: Right now it looks like cmake does it. Yes. cmake re-generates the project file/make files when Package.cpp.in is changed, or a file is added. It is faster than autogen.sh and configure. The difference is that cmake is a 'two step' system, and scons is 'one-step' (and autotools is a 'three step' system). By definition, there is no platform independent installation, so I wonder what exactly the requirements are here. (And of course I have no clue how cmake manages it. But KDE uses cmake and runs on Windows and is a bit more complex than LyX, so I doubt there's a problem) Abdel says cmake uses something calls cpack for installation. This makes cmake a 'three step' system. :-) There is nothing wrong with cutting a complex process into small pieces. I guess more people are likely to agree on the opposite, namely that e.g. a generated .vcproj file should be something that feels 'native' when using in Visual Studio. I am old fashioned, and have not yet appreciated the convenience of a GUI. :-) (Also because I try to avoid MS products). For running cl on the command line one does not need a .vcproj file. [But I have still to see a scons generated .vcproj file to get an impression how it works] It works as usually, just calls scons to build lyx, which is slower than the native nmake code that cmake generates. I guess that'd rate around '2' or '3' on a scale from 0-5... It's means that MSVS is used just for text editing and debugging, but not for as 'IDE' (including e.g. project management) If I use MSVS (which I am luckily rarely forced to do nowadays...) I want MSVS, not some script running magically in the background. Of course that's just an opinion of a untypical Windows user, but I fear that the MSVS diehards have even stronger feelings on that. A sligh advantage is that if you change Package.cpp.in, there is no need to regenerate the project file. A very slight advantage. How often is Package.cpp.in changed, and how expensive is the re-creation of the project file? Andre'
Re: [Updated PATCH] BufferView/WorkArea/LyXView reorg a.k.a Multiple WorkAreas
On Thursday 23 August 2007 21:31:25 Enrico Forestieri wrote: On third thought, maybe we should only allow Qt snaspshots, just to be sure. Don't we already use boost snapshots? Now that you mention it the solution is to carry our own copy of qt, then qt and boost will be on the same level... ;-) -- Enrico -- José Abílio
Re: [Updated PATCH] BufferView/WorkArea/LyXView reorg a.k.a Multiple WorkAreas
On Thu, Aug 23, 2007 at 10:36:10PM +0200, Abdelrazak Younes wrote: Enrico Forestieri wrote: On Thu, Aug 23, 2007 at 11:09:49AM +0200, Abdelrazak Younes wrote: Another problem: lyx allows opening multiple times the same file. Really? I'll have a look... Do you mean multiple BufferView or multiple Buffer? The later would be embarrassing. File-Load and you can open how many times you like the same file. And there's still the crash with Qt 4.1 when opening a second file. This does not happen with X11, only on Windows. Weird. Not more than the fact that the tab close button works with Qt 4.3 but not with 4.2 (and 4.1, for that matter, tested when a toolbar was also appearing with only a file loaded). I by far prefer Qt 4.1 over recent versions, so I would be grateful if you could solve this problem. I'll try but this will take some time as I have to install and compile 4.1. Trolltech already distributes a mingw binary: ftp://ftp.trolltech.com/qt/source/qt-win-opensource-4.1.5-mingw.exe -- Enrico
Re: Build trouble
On Thu, Aug 23, 2007 at 11:00:57PM +0300, Martin Vermeer wrote: On Thu, Aug 23, 2007 at 09:22:08PM +0200, Enrico Forestieri wrote: On Thu, Aug 23, 2007 at 10:19:47PM +0300, Martin Vermeer wrote: In order to build, I have to use the attached in src/support. Would somebody please draw the appropriate lessons? (Age old Fedora) ;-) autogen.sh -- Enrico Could swear that I had done that... second time around it bit ;-/ Update: At least in src/support. In src/frontends/controllers I still get makefile errors on MONOLITHIC_CONTROLLERS, and in qt4 on MONOLITHIC_FRONTEND_QT4. Even when trying a couple of times. Ah well. You seem to have particularily bad karma when it comes to auto stuff. I haven't touched the 'monolithic stuff' for over a week and nobody else had problems... As you have some time over night, 'make distclean' and retry. Or even remove the build tree and retry. Andre'
Re: cmake needs update?
On Thu, Aug 23, 2007 at 10:19:28PM +0200, Joost Verburg wrote: [EMAIL PROTECTED] wrote: While cmake can create MSVC projects, the current implementation does not handle all the dependencies like scons does. For example, the thesaurus is not supported. To create Windows releases, scons in the only option right now. Umm... sorry if I've asked this before, but I thought the installer could use a Windows executable of LyX that's been created with any build system on Windows? Sure. If cmake is able to generate an executable linked to all dependencies, I can use it instead. Currently only scons can do that. How does an executable look like that's not linked to its dependencies? [No joke, I really want to grasp the difference between cmake and scons] Andre'
Re: Build trouble
On Thu, Aug 23, 2007 at 10:35:18PM +0200, Enrico Forestieri wrote: On Thu, Aug 23, 2007 at 11:00:57PM +0300, Martin Vermeer wrote: On Thu, Aug 23, 2007 at 09:22:08PM +0200, Enrico Forestieri wrote: On Thu, Aug 23, 2007 at 10:19:47PM +0300, Martin Vermeer wrote: In order to build, I have to use the attached in src/support. Would somebody please draw the appropriate lessons? (Age old Fedora) ;-) autogen.sh -- Enrico Could swear that I had done that... second time around it bit ;-/ Update: At least in src/support. In src/frontends/controllers I still get makefile errors on MONOLITHIC_CONTROLLERS, and in qt4 on MONOLITHIC_FRONTEND_QT4. Even when trying a couple of times. Ah well. Try also reconfiguring explicitly. Did that already :-( - Martin
Re: [Updated PATCH] BufferView/WorkArea/LyXView reorg a.k.a Multiple WorkAreas
On Thu, Aug 23, 2007 at 10:31:25PM +0200, Enrico Forestieri wrote: On Thu, Aug 23, 2007 at 08:52:00PM +0100, José Matos wrote: On Thursday 23 August 2007 19:49:07 Enrico Forestieri wrote: Hmm, on second thought, it is better requiring Qt 4.3.1 which has already been released. -- Enrico Why, is that a problem? ;-) Not at all. $ ./src/lyx.exe -version LyX 1.6.0svn (not released yet) Built on Aug 23 2007, 16:51:59 Configuration Host type:i686-pc-cygwin Special build flags: aiksaurus assertions warnings use-aspell use-ispell C Compiler: gcc C Compiler LyX flags: C Compiler flags: -pipe -O2 C++ Compiler: g++ (3.4.4) C++ Compiler LyX flags: C++ Compiler flags: -pipe -O2 Linker flags: Linker user flags: -L/usr/local/lib Qt 4 Frontend: Qt 4 version: 4.3.1 Packaging:posix LyX binary dir: /usr/local/bin LyX files dir:/usr/local/share/lyx-1.6.0svn On third thought, maybe we should only allow Qt snaspshots, Qt snapshots are usually pretty old as they are created just once a day. So they can be out-of-date by 24 hours, sometimes even more. Just use qt main from the perforce repository... Or maybe even pull from the developers' private branches directly. *sigh* Are you happy now? Andre'
Re: cmake needs update?
There is nothing wrong with cutting a complex process into small pieces. The problems lie between the programs. It is never clear to me when I need to call autogen.sh, and when I need to call configure.sh. scons gives me a peace of mind. I guess that'd rate around '2' or '3' on a scale from 0-5... It's means that MSVS is used just for text editing and debugging, but not for as 'IDE' (including e.g. project management) cmake does not do 'project management' either. It adds compile and dependency check to your list. Cheers, Bo
Re: [Updated PATCH] BufferView/WorkArea/LyXView reorg a.k.a Multiple WorkAreas
Enrico Forestieri wrote: On Thu, Aug 23, 2007 at 10:36:10PM +0200, Abdelrazak Younes wrote: Enrico Forestieri wrote: On Thu, Aug 23, 2007 at 11:09:49AM +0200, Abdelrazak Younes wrote: Another problem: lyx allows opening multiple times the same file. Really? I'll have a look... Do you mean multiple BufferView or multiple Buffer? The later would be embarrassing. File-Load and you can open how many times you like the same file. Yes. But it's the same Buffer really, the file is opened only once. I'll correct that. This mean by the way that we can now duplicate tabs and work on different part of the same document within the same view :-) And there's still the crash with Qt 4.1 when opening a second file. This does not happen with X11, only on Windows. Weird. Not more than the fact that the tab close button works with Qt 4.3 but not with 4.2 (and 4.1, for that matter, tested when a toolbar was also appearing with only a file loaded). Ah... I wondered where this close button has gone. Qt 4.3 fount it! I by far prefer Qt 4.1 over recent versions, so I would be grateful if you could solve this problem. I'll try but this will take some time as I have to install and compile 4.1. Trolltech already distributes a mingw binary: ftp://ftp.trolltech.com/qt/source/qt-win-opensource-4.1.5-mingw.exe I use MSVC so I need to rebuild it. Abdel.
Re: Build trouble
On Thu, Aug 23, 2007 at 11:53:35PM +0300, Martin Vermeer wrote: On Thu, Aug 23, 2007 at 10:35:18PM +0200, Enrico Forestieri wrote: On Thu, Aug 23, 2007 at 11:00:57PM +0300, Martin Vermeer wrote: On Thu, Aug 23, 2007 at 09:22:08PM +0200, Enrico Forestieri wrote: On Thu, Aug 23, 2007 at 10:19:47PM +0300, Martin Vermeer wrote: In order to build, I have to use the attached in src/support. Would somebody please draw the appropriate lessons? (Age old Fedora) ;-) autogen.sh -- Enrico Could swear that I had done that... second time around it bit ;-/ Update: At least in src/support. In src/frontends/controllers I still get makefile errors on MONOLITHIC_CONTROLLERS, and in qt4 on MONOLITHIC_FRONTEND_QT4. Even when trying a couple of times. Ah well. Try also reconfiguring explicitly. Did that already :-( Does the attached patch help? -- Enrico Index: configure.ac === --- configure.ac(revision 19754) +++ configure.ac(working copy) @@ -410,49 +410,49 @@ AC_ARG_ENABLE(monolithic-boost, AC_HELP_STRING([--enable-monolithic-boost], [Use monolithic boost compilations]),, [enable_monolithic_boost=no]) -AM_CONDITIONAL(MONOLITHIC_BOOST, test $enable_monolithic_boost = yes) +AM_CONDITIONAL(MONOLITHIC_BOOST, test $enable_monolithic_boost = yes) AC_ARG_ENABLE(monolithic-client, AC_HELP_STRING([--enable-monolithic-client], [Use monolithic client compilations]),, [enable_monolithic_client=no]) -AM_CONDITIONAL(MONOLITHIC_CLIENT, test $enable_monolithic_client = yes) +AM_CONDITIONAL(MONOLITHIC_CLIENT, test $enable_monolithic_client = yes) AC_ARG_ENABLE(monolithic-controllers, AC_HELP_STRING([--enable-monolithic-controllers], [Use monolithic controllers compilations]),, [enable_monolithic_controllers=no]) -AM_CONDITIONAL(MONOLITHIC_CONTROLLERS, test $enable_monolithic_controllers = yes) +AM_CONDITIONAL(MONOLITHIC_CONTROLLERS, test $enable_monolithic_controllers = yes) AC_ARG_ENABLE(monolithic-insets, AC_HELP_STRING([--enable-monolithic-insets], [Use monolithic insets compilations]),, [enable_monolithic_insets=no]) -AM_CONDITIONAL(MONOLITHIC_INSETS, test $enable_monolithic_insets = yes) +AM_CONDITIONAL(MONOLITHIC_INSETS, test $enable_monolithic_insets = yes) AC_ARG_ENABLE(monolithic-mathed, AC_HELP_STRING([--enable-monolithic-mathed], [Use monolithic mathed compilations]),, [enable_monolithic_mathed=no]) -AM_CONDITIONAL(MONOLITHIC_MATHED, test $enable_monolithic_mathed = yes) +AM_CONDITIONAL(MONOLITHIC_MATHED, test $enable_monolithic_mathed = yes) AC_ARG_ENABLE(monolithic-core, AC_HELP_STRING([--enable-monolithic-core], [Use monolithic core files compilations]),, [enable_monolithic_core=no]) -AM_CONDITIONAL(MONOLITHIC_CORE, test $enable_monolithic_core = yes) +AM_CONDITIONAL(MONOLITHIC_CORE, test $enable_monolithic_core = yes) AC_ARG_ENABLE(monolithic-tex2lyx, AC_HELP_STRING([--enable-monolithic-tex2lyx], [Use monolithic tex2lyx compilations]),, [enable_monolithic_tex2lyx=no]) -AM_CONDITIONAL(MONOLITHIC_TEX2LYX, test $enable_monolithic_tex2lyx = yes) +AM_CONDITIONAL(MONOLITHIC_TEX2LYX, test $enable_monolithic_tex2lyx = yes) AC_ARG_ENABLE(monolithic-frontend-qt4, AC_HELP_STRING([--enable-monolithic-frontend-qt4], [Use monolithic compilation of the Qt 4 frontend. Only recommended with 512 MB of RAM]),, [enable_monolithic_frontend_qt4=no]) -AM_CONDITIONAL(MONOLITHIC_FRONTEND_QT4, test $enable_monolithic_frontend_qt4 = yes) +AM_CONDITIONAL(MONOLITHIC_FRONTEND_QT4, test $enable_monolithic_frontend_qt4 = yes) AC_DEFINE_UNQUOTED([LYX_DATE],$LYX_DATE,[Date of release]) AC_DEFINE_UNQUOTED([VERSION_INFO],$VERSION_INFO,[Full version info])
Re: cmake needs update?
On Thu, Aug 23, 2007 at 03:54:46PM -0500, Bo Peng wrote: There is nothing wrong with cutting a complex process into small pieces. The problems lie between the programs. It is never clear to me when I need to call autogen.sh, and when I need to call configure.sh. scons gives me a peace of mind. It's funny that this quest for piece doesn't lead you to IDEs. They are the magic all-in-one boxes after all. I guess that'd rate around '2' or '3' on a scale from 0-5... It's means that MSVS is used just for text editing and debugging, but not for as 'IDE' (including e.g. project management) cmake does not do 'project management' either. It adds compile and dependency check to your list. I didn't say that. 'Real integration' with MSVS we probably only get by using qmake + Qt MSVS integration. This includes project management. But this is not that interesting in the scons vs cmake fight. I just wanted to note that that what scons calls 'MSVS support' is only a little bit better than 'no support at all' (and that's still only after reading the mails here, I still haven't seen a scons generated .vcproj file). Andre'
[Patch] Inset configurability: separate charstyle and custom insets
Finally I got where Richard was many weeks ago... the custom inset 'endnote' works! Or would, if I would have endnote.sty on my system. Finally I got where Richard was many weeks ago... the custom inset 'endnote' works! Or would, if I would have endnote.sty on my system. What is now not elegant, is that the term 'charstyle' is being used for two different things: 1) general user-definable insets, and 2) specific oldfashioned charstyle-type insets (the alternative now being 'custom', but there could be more: 'short element', e.g.) I think I'll have to rename 'charstyle-1' to something more appropriate (suggestions?). That will be a big but near-trivial patch. - Martin
Re: Build trouble
On Thu, Aug 23, 2007 at 11:18:47PM +0200, Enrico Forestieri wrote: Does the attached patch help? Even if not, just commit that. Andre'
Re: cmake needs update?
On Thu, Aug 23, 2007 at 03:54:46PM -0500, Bo Peng wrote: There is nothing wrong with cutting a complex process into small pieces. The problems lie between the programs. It is never clear to me when I need to call autogen.sh, and when I need to call configure.sh. scons gives me a peace of mind. Note that JMarc recently introduced some changes, such that make simply regenerates everything when needed. So, you have to run autogen.sh and configure only the first time. Only in weird cases you should need running autogen.sh manually. -- Enrico
Re: Build trouble
On Thu, Aug 23, 2007 at 11:36:36PM +0200, Andre Poenitz wrote: On Thu, Aug 23, 2007 at 11:18:47PM +0200, Enrico Forestieri wrote: Does the attached patch help? Even if not, just commit that. Done. -- Enrico
Simplify building of Package.cpp
This patch gets replaces Package.cpp.in by an ordinary 'Package.cpp'
which gets its data from by #defines config.h.
I think all build systems are adjusted, but I did not test intensively,
though.
Andre'
Index: src/support/Package.cpp.in
===
--- src/support/Package.cpp.in (revision 19756)
+++ src/support/Package.cpp.in (working copy)
@@ -1,751 +0,0 @@
-// -*- C++ -*-
-/**
- * \file package.C
- * This file is part of LyX, the document processor.
- * Licence details can be found in the file COPYING.
- *
- * \author Angus Leeming
- *
- * Full author contact details are available in file CREDITS.
- *
- * Warning! This file is autogenerated from Package.cpp.in.
- * All changes to this file will be lost.
- */
-
-#include config.h
-
-#include support/Package.h
-
-#include debug.h
-#include gettext.h
-
-#include support/environment.h
-#include support/filetools.h
-#include support/lstrings.h
-#include support/ExceptionMessage.h
-#include support/os.h
-
-#if defined (USE_WINDOWS_PACKAGING)
-# include support/os_win32.h
-#endif
-
-#include boost/filesystem/operations.hpp
-#include boost/tuple/tuple.hpp
-
-#include list
-#include utility
-
-#if !defined (USE_WINDOWS_PACKAGING) \
-!defined (USE_MACOSX_PACKAGING) \
-!defined (USE_POSIX_PACKAGING)
-#error USE_FOO_PACKAGING must be defined for FOO = WINDOWS, MACOSX or POSIX.
-#endif
-
-#if defined (USE_MACOSX_PACKAGING)
-# include CoreServices/CoreServices.h // FSFindFolder, FSRefMakePath
-#endif
-
-using std::string;
-
-namespace fs = boost::filesystem;
-
-namespace lyx {
-namespace support {
-
-namespace {
-
-Package package_;
-bool initialised_ = false;
-
-} // namespace anon
-
-
-void init_package(string const command_line_arg0,
- string const command_line_system_support_dir,
- string const command_line_user_support_dir,
- exe_build_dir_to_top_build_dir top_build_dir_location)
-{
- // Can do so only once.
- if (initialised_)
- return;
-
- package_ = Package(command_line_arg0,
- command_line_system_support_dir,
- command_line_user_support_dir,
- top_build_dir_location);
- initialised_ = true;
-}
-
-
-Package const package()
-{
- // Commented out because package().locale_dir() can be called
- // from the message translation code in Messages.cpp before
- // init_package() is called. Lars is on the case...
- // BOOST_ASSERT(initialised_);
- return package_;
-}
-
-
-namespace {
-
-FileName const abs_path_from_binary_name(string const exe);
-
-std::pairFileName, FileName const
-get_build_dirs(FileName const abs_binary,
- exe_build_dir_to_top_build_dir top_build_dir_location);
-
-FileName const get_document_dir(FileName const home_dir);
-
-FileName const get_home_dir();
-
-FileName const get_locale_dir(FileName const system_support_dir);
-
-FileName const get_system_support_dir(FileName const abs_binary,
- string const
command_line_system_support_dir);
-
-FileName const get_temp_dir();
-
-FileName const get_default_user_support_dir(FileName const home_dir);
-
-std::pairFileName, bool const
-get_user_support_dir(FileName const default_user_support_dir,
-string const command_line_user_support_dir);
-
-
-string const with_version_suffix();
-
-} // namespace anon
-
-
-Package::Package(string const command_line_arg0,
-string const command_line_system_support_dir,
-string const command_line_user_support_dir,
-exe_build_dir_to_top_build_dir top_build_dir_location)
- : explicit_user_support_dir_(false)
-{
- home_dir_ = get_home_dir();
- system_temp_dir_ = get_temp_dir();
- temp_dir_ = system_temp_dir_;
- document_dir_ = get_document_dir(home_dir_);
-
- FileName const abs_binary =
abs_path_from_binary_name(command_line_arg0);
- string const bdir = onlyPath(abs_binary.absFilename());
- // We may be using libtools
- if (suffixIs(bdir, .libs/))
- binary_dir_ = FileName(addPath(bdir, ../));
- else
- binary_dir_ = FileName(bdir);
-
- // Is LyX being run in-place from the build tree?
- boost::tie(build_support_dir_, system_support_dir_) =
- get_build_dirs(abs_binary, top_build_dir_location);
-
- if (build_support_dir_.empty())
- system_support_dir_ =
- get_system_support_dir(abs_binary,
- command_line_system_support_dir);
-
- locale_dir_ = get_locale_dir(system_support_dir_);
-
- FileName const default_user_support_dir =
- get_default_user_support_dir(home_dir_);
- boost::tie(user_support_dir_, explicit_user_support_dir_) =
-
Re: Full XeTeX support
On Thu, 23 Aug 2007, José Matos wrote: On Thursday 23 August 2007 20:13:35 [EMAIL PROTECTED] wrote: Umm... shouldn't it go into bugzilla? Yes. :-) If we want to show them on a wiki page, we could tag them in someway (or a special search), and have that embedded in a wiki page? And so I did. Have you seen http://wiki.lyx.org/Devel/UsersRequests? Nice! Jose', are you going all wiki wiki on us? ;-) Not, unless it is all in python. ;-) Now that you mention trac has some other possibilities... just joking. :-) Well, just for you I could change the entire wiki engine ;-) /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
