Re: Qt books
Hello Xu, Please adjust your email settings as we are receiving your emails twice. For the rest, just believe André :-) Abdel On Jun 7, 2011, at 11:01 AM, Xu Wang wrote: > > > On Tue, Jun 7, 2011 at 12:38 AM, Andre Poenitz > wrote: > On Mon, Jun 06, 2011 at 03:18:01PM -0700, Xu Wang wrote: > > Hi, I would like to learn Qt. I learn much better from physical books than > > online resources, although I've heard the Qt manual is very good. > > > > Does anyone have suggestions for me? > > Your question is a bit off-topic here. Try qt-inter...@qt.nokia.com > or something similar. > > I should have been more precise. I'm interested in learning qt4 for pretty > much the sole purpose of programming for LyX. As I do not know anything about > qt4, I do not know if there are different approaches to learning it, one of > which is more useful for LyX. > > > Google's first hit for "qt books" is http://developer.qt.nokia.com/books > which happens to be the "official" site. The first one (Blanchette/ > Summerfield) is a very good start. > > Even though it's a few years old? > > > > How much does Qt change from year to year? I am trying to figure out how new > > the book that I look for should be. > > It should be Qt _4_. There's about one minor release per year, but > currently Qt 5 is being discussed. This will still take a while though, > and people try fairly hard to keep incompatibilities small, certainly > less than the Qt 3 -> Qt 4 jump six years ago. > > > Is there any chance that LyX will stop using Qt in the recent future? > > Unlikely from my point of view, given that there are no serious > alternatives for the kind of cross-platformness LyX exhibits. > > Andre' > > Thank you for your response Andre', > > Xu >
Re: Sorry for this...
On May 31, 2011, at 11:18 PM, Christian Ridderström wrote: > Hi, > > I'm trying to figure out if my mails get through or not... They get through... > /Christian > > -- > Christian Ridderström, Cell phone: +46-70 687 39 44 Are you aware that your phone number is visible to the rest of the world? :-) Abdel.
Re: #7581: Advanced search buffer always article class
On May 23, 2011, at 2:18 PM, Richard Heck wrote: > On 05/23/2011 08:12 AM, Tommaso Cucinotta wrote: >> Il 23/05/2011 08:22, LyX Ticket Tracker ha scritto: >>> However, there are still things left that need to be copied. For instance, >>> both Insert> Citation and Insert> Cross Reference do not seem to work in >>> the search buffer. Shall I file separate reports for these? >>> >> do you know whether these were working when we were cloning >> the whole BufferParams (2.0.0 version) ? >> > I don't think it would work. That buffer has no access to the bibliography or > reference info from the working buffer. Probably what you would need to do is > copy the reference cache and the bibinfo cache, though you'd also have to > make sure they were updated as well whenever they changed in the main buffer, > or the main buffer switched, etc. Seems very delicate. > > In a way, what we want really is for the search buffer to treat the main > buffer as its parent, but only for certain purposes. Maybe there is some way > to accomplish that Maybe the solution is to create a special EmbeddedBuffer class that will constantly refer to the document Buffer (const access to the params, ref cache, etc). EmbeddedBuffer would inherit Buffer and would offer only const access to the params/etc. Abdel.
Re: r38781 - in lyx-devel/trunk/src: . frontends/qt4
On May 19, 2011, at 10:01 AM, Vincent van Ravesteijn wrote: > On 19-5-2011 9:39, Abdel Younes wrote: >> >> On May 18, 2011, at 10:33 PM, sw...@lyx.org wrote: >> >>> Author: switt >>> Date: Wed May 18 22:33:57 2011 >>> New Revision: 38781 >>> URL: http://www.lyx.org/trac/changeset/38781 >>> >>> Log: >>> #7564 make the move forward to next match after text replacement optional >>> and suppress it when replace a word by selected suggestion >>> >>> Modified: >>> lyx-devel/trunk/src/frontends/qt4/Menus.cpp >>> lyx-devel/trunk/src/lyxfind.cpp >>> lyx-devel/trunk/src/lyxfind.h >>> >>> Modified: lyx-devel/trunk/src/frontends/qt4/Menus.cpp >>> == >>> --- lyx-devel/trunk/src/frontends/qt4/Menus.cpp Tue May 17 23:53:05 >>> 2011(r38780) >>> +++ lyx-devel/trunk/src/frontends/qt4/Menus.cpp Wed May 18 22:33:57 >>> 2011(r38781) >>> @@ -789,7 +789,7 @@ >>> MenuItem w(MenuItem::Command, >>> toqstr(suggestion), >>> FuncRequest(LFUN_WORD_REPLACE, >>> >>> replace2string(suggestion,selection, >>> - true, true, >>> false, false))); >>> + true, true, >>> false, false, false))); >> >> I think it's really time to use an enum instead of all these booleans >> > > struct ? Or struct... Abdel.
Re: Road to LyX 2.1 - #1 (2011-05-15)
On May 19, 2011, at 9:03 AM, Vincent van Ravesteijn wrote: > On Wed, May 18, 2011 at 10:58 PM, Pavel Sanda wrote: > > > > Did I say you need to ask permission ? Did I say you need to wait before > > doing something ? > ... > > You somehow think that you need permission before pushing a feature ? > > one reading of "After that, you and me decide when it merges to trunk-stable" > is like that. its actually connected to the question above and if i get it > completely wrong, then sorry. > > It's not like asking the maintainer for "permission". it's more like "if > there are > no serious comments on a patch, if there are no bugs introduced and if it is > understandable to others", it will automatically get merged into trunk-stable > after some period of testing. Pavel, all, So far Vincent did not force on you anything and he is adapting his maintainer role to the current conservative developpers. I think it is really time now to let Vincent proceed with his strategy. What Vincent did is to cheery pick the svn commits in svn trunk and reformat them to git topic branches. He also created a "trunk-stable" branch that will eventually becomes 2.1 if his strategy proves to be successful. I am personally very confident that Vincent will succeed and I suggest that we let him a few weeks to prove his case and also that we support him in doing so. If that doesn't work, we can always forget about "trunk-stable" and continue with "development" like now. A - For a supportive developer, supporting Vincent means: 1) developing in git branches 2) merge those branches in development when the supportive developer thinks the feature is mostly implemented 3) tell Vincent when the feature is mostly stable and do not introduce regression; then Vincent will decide to merge the branch or not B - For a supportive but conservative developer that just don't want to use branches: 1) develop locally his feature 2) when the feature is mostly ready, rebase from "development", commit and push to "development". This means that this feature will be available in one big patch with no history. 3) tell Vincent when the feature is mostly stable and do not introduce regression; then Vincent will decide to merge the branch or not C - For the non supportive developer: 1) git commit and push all changes to "development" 2) Vincent (or some helper) will then have to cherry pick those commits and gather them in a branch before merging to trunk-stable Vincent is essentially doing C now with svn-trunk. I suggest that we switch to git and that each developer decided if we want to do A, B or C. I will do A personally but I would understand if people start by doing C, then B, then A. Abdel.
Re: r38781 - in lyx-devel/trunk/src: . frontends/qt4
On May 18, 2011, at 10:33 PM, sw...@lyx.org wrote: > Author: switt > Date: Wed May 18 22:33:57 2011 > New Revision: 38781 > URL: http://www.lyx.org/trac/changeset/38781 > > Log: > #7564 make the move forward to next match after text replacement optional and > suppress it when replace a word by selected suggestion > > Modified: > lyx-devel/trunk/src/frontends/qt4/Menus.cpp > lyx-devel/trunk/src/lyxfind.cpp > lyx-devel/trunk/src/lyxfind.h > > Modified: lyx-devel/trunk/src/frontends/qt4/Menus.cpp > == > --- lyx-devel/trunk/src/frontends/qt4/Menus.cpp Tue May 17 23:53:05 > 2011(r38780) > +++ lyx-devel/trunk/src/frontends/qt4/Menus.cpp Wed May 18 22:33:57 > 2011(r38781) > @@ -789,7 +789,7 @@ > MenuItem w(MenuItem::Command, > toqstr(suggestion), > FuncRequest(LFUN_WORD_REPLACE, > > replace2string(suggestion,selection, > - true, true, > false, false))); > + true, true, > false, false, false))); I think it's really time to use an enum instead of all these booleans Abdel.
Re: MacOS native spellchecking bug
On Nov 14, 2010, at 2:21 PM, Stephan Witt wrote: > Am 14.11.2010 um 13:17 schrieb Abdel Younes: > >> >> On Nov 14, 2010, at 1:01 PM, Stephan Witt wrote: >> >>> Am 14.11.2010 um 12:37 schrieb Abdel Younes: >>> >>>> Hi Stephan, >>>> >>>> The first built I made enabled the native spellchecker, I didn't install >>>> other engine yet. I would like to report a bug, I am not sure this bug is >>>> only for MacOS with the native engine: >>>> >>>> 1) Open UserGuide.lyx >>>> 2) Copy the whole text of Section 1.1 >>>> 3) Create a new Document and set the language to French >>>> 4) Paste the clipboard >>>> 5) Select the whole text and set the language to French in order to get >>>> rid of the foreign language underlining >>>> Result: many words are rightfully maked as misspelled but some of them are >>>> not: "beautiful", "poetry", etc >>>> 6) Righ-click on "beautiful" >>>> Result 1: the "Add to personal dictionary" item appears in the context >>>> menu >>>> Result 2: "beautiful" is now correctly marked as misspelled. >>>> >>>> This is the kind of problems that you have in programs such as Thunderbird >>>> or OpenOffice when you switch the language. I hope this is fixable. I will >>>> try now to install and compile with hunspell to see if I can reproduce. >>>> But I guess I will not because the bug is really in the native MacOS >>>> engine to which we send full paragraphs. Hunspell or Aspell should (I >>>> hope) not be affected because we spellcheck word by word. >>> >>> I tried it with aspell and more - but not all - words are marked as >>> misspelled. >>> And it's "stable" - in the sense of words being not misspelled on screen >>> and when using the context menu it remaining "correct". >> >> Some words are valid French words, that's why. > > have - ??? > uses - ??? No, I was talking about "document" or "concept"... > > Maybe have is checked as hâve. Don't know this word :-) > But uses? Don't know either. > > Anyway, aspell is more accurate for now. That's not my point. The native spellchecker is correct when you check word by words. The issue here is that it fails if you give it too much words to check.` Abdel.
Re: MacOS native spellchecking bug
On Nov 14, 2010, at 1:01 PM, Stephan Witt wrote: > Am 14.11.2010 um 12:37 schrieb Abdel Younes: > >> Hi Stephan, >> >> The first built I made enabled the native spellchecker, I didn't install >> other engine yet. I would like to report a bug, I am not sure this bug is >> only for MacOS with the native engine: >> >> 1) Open UserGuide.lyx >> 2) Copy the whole text of Section 1.1 >> 3) Create a new Document and set the language to French >> 4) Paste the clipboard >> 5) Select the whole text and set the language to French in order to get rid >> of the foreign language underlining >> Result: many words are rightfully maked as misspelled but some of them are >> not: "beautiful", "poetry", etc >> 6) Righ-click on "beautiful" >> Result 1: the "Add to personal dictionary" item appears in the context menu >> Result 2: "beautiful" is now correctly marked as misspelled. >> >> This is the kind of problems that you have in programs such as Thunderbird >> or OpenOffice when you switch the language. I hope this is fixable. I will >> try now to install and compile with hunspell to see if I can reproduce. But >> I guess I will not because the bug is really in the native MacOS engine to >> which we send full paragraphs. Hunspell or Aspell should (I hope) not be >> affected because we spellcheck word by word. > > I tried it with aspell and more - but not all - words are marked as > misspelled. > And it's "stable" - in the sense of words being not misspelled on screen and > when using the context menu it remaining "correct". Some words are valid French words, that's why. Abdel.
Re: MacOS/CMake/Qt4.7 compilation report
On Nov 14, 2010, at 12:23 PM, Stephan Witt wrote:
> Am 14.11.2010 um 09:16 schrieb Abdel Younes:
>
>> Hello,
>>
>> I am trying to use cmake on MacOS (10.6). I didn't on purpose read the Mac
>> INSTALL/README in order to judge how easy it is to compile LyX under MacOS.
>> So far, I am pleased. big kudoes to Peter/Kornel/Stefan/Bennett!
>
> Fine. Thanks for the kudos.
Deserved. And sorry for misspelling your first name.
>
>> Here is what I did:
>>
>> 1) install the latest Xcode 3.something, not so much for Xcode but because
>> it brings in gcc and MacOS development libraries.
>
> One question here: before installing Xcode, did you have the svn command line
> tool, already? Or comes it with Xcode only?
> Perhaps you have tested this and can remember?
Yes, it came with XCode. It was not there before.
>
>> 2) install Qt-4.7 from Nokia
>> 3) install cmake from cmake web site
>
> cmake is in macports too. maybe it's good enough and easier to install - in
> terms of key strokes...
>
>> 4) install MacPorts
>> 5) update MacPorts: sudo port -v selfupdate
>> 6) install gmake:sudo port -v selfupdate
>
> gmake makes a difference?
I don't know but XCode didn't bring in make and MacPorts only offered GNU make
("sudo install gmake")
>
>> 7) mkdir devel/lyx
>> 8) svn co svn svn://svn.lyx.org/lyx/lyx-devel/trunk
>> 9) mkdir trunk/build
>> 10) cd trunk/build
>> 11) cmake ../development/cmake/
>> 12) make
>> 13) ./bin/LyX2.0 -sysdir ../lib
>>
>> And it works I am able to load all help documents. By the way what is
>> the font problem I should be having with Qt-4.7? The rendering seems quite
>> good on the UserGuide, AFAICS.
>
> I can show you two screenshots to illustrate it (with Qt4.6.3), as fas as I
> understand it.
> The first one I made with preconfigured fonts. (Times, Helvetica, Courier)
>
>
>
> The second one with modified screen fonts. (Georgia, Geneva, Courier New)
>
>
>
> Two problems are "fixed" now:
> * the display of a-umlaut with Times.
> * the fi ligature with monospaced Courier. Note the cursor position and the
> length of the misspelled marker line.
OK thanks, I'll have a look.
>
>> Now I am going to install Latex (any recommendation here?)
>
> MacTeX is the one I've installed here. I did not test any other.
I installed that now; seems to work. But there is no update program, is there?
I mean so that we are not forced to download the 1.6Gb package when you want to
upgrade...
Abdel.
MacOS native spellchecking bug
Hi Stephan, The first built I made enabled the native spellchecker, I didn't install other engine yet. I would like to report a bug, I am not sure this bug is only for MacOS with the native engine: 1) Open UserGuide.lyx 2) Copy the whole text of Section 1.1 3) Create a new Document and set the language to French 4) Paste the clipboard 5) Select the whole text and set the language to French in order to get rid of the foreign language underlining Result: many words are rightfully maked as misspelled but some of them are not: "beautiful", "poetry", etc 6) Righ-click on "beautiful" Result 1: the "Add to personal dictionary" item appears in the context menu Result 2: "beautiful" is now correctly marked as misspelled. This is the kind of problems that you have in programs such as Thunderbird or OpenOffice when you switch the language. I hope this is fixable. I will try now to install and compile with hunspell to see if I can reproduce. But I guess I will not because the bug is really in the native MacOS engine to which we send full paragraphs. Hunspell or Aspell should (I hope) not be affected because we spellcheck word by word. Abdel.
MacOS/No LaTeX installation and LyXHTML export
Hi Richard, Just a simple report of the LyXHTML export of the with latest trunk under MacOS and no LaTeX installed. The export went fine (and instantaneous!). Except for the expected errors for the pdf and eps to png conversion, I had absolutely no problem. You may want to have a look at these errors when I load the resulting UserGuide.xtml under Safari: This page contains the following errors: error on line 2922 at column 19: Entity 'epsi' not defined error on line 3767 at column 31: Entity 'InvisibleTimes' not defined error on line 3768 at column 29: Entity 'DifferentialD' not defined error on line 4083 at column 17: Entity 'dtdot' not defined error on line 4264 at column 29: Entity 'af' not defined error on line 4342 at column 39: Entity 'af' not defined error on line 4400 at column 31: Entity 'grave' not defined error on line 4424 at column 29: Entity 'Dot' not defined error on line 4460 at column 31: Entity 'breve' not defined error on line 4484 at column 33: Entity 'OverBar' not defined error on line 4535 at column 39: Entity 'af' not defined error on line 4540 at column 42: Entity 'af' not defined error on line 4656 at column 27: Entity 'af' not defined error on line 4841 at column 30: Entity 'af' not defined error on line 4847 at column 33: Entity 'af' not defined error on line 5000 at column 27: Entity 'af' not defined error on line 5047 at column 43: Entity 'ThinSpace' not defined error on line 5055 at column 46: Entity 'ThinSpace' not defined error on line 5117 at column 27: Entity 'af' not defined error on line 8376 at column 17: Entity 'ap' not defined Below is a rendering of the page up to the first error. The above message is wrong though as the rendering went up until the end of the document. Congrats anyway for such an excellent addition to LyX! Abdel.
MacOS/CMake/Qt4.7 compilation report
Hello, I am trying to use cmake on MacOS (10.6). I didn't on purpose read the Mac INSTALL/README in order to judge how easy it is to compile LyX under MacOS. So far, I am pleased. big kudoes to Peter/Kornel/Stefan/Bennett! Here is what I did: 1) install the latest Xcode 3.something, not so much for Xcode but because it brings in gcc and MacOS development libraries. 2) install Qt-4.7 from Nokia 3) install cmake from cmake web site 4) install MacPorts 5) update MacPorts: sudo port -v selfupdate 6) install gmake:sudo port -v selfupdate 7) mkdir devel/lyx 8) svn co svn svn://svn.lyx.org/lyx/lyx-devel/trunk 9) mkdir trunk/build 10) cd trunk/build 11) cmake ../development/cmake/ 12) make 13) ./bin/LyX2.0 -sysdir ../lib And it works I am able to load all help documents. By the way what is the font problem I should be having with Qt-4.7? The rendering seems quite good on the UserGuide, AFAICS. Now I am going to install Latex (any recommendation here?) I am also going to read the INSTALL/README ion order to know what I should tweak in CMake for proper spellchecking/etc. One thing maybe worth of reporting is this warning from cmake: -- Configuring done CMake Warning at src/CMakeLists.txt:95 (add_executable): Cannot generate a safe linker search path for target LyX2.0 because files in some directories may conflict with libraries in implicit directories: link library [libiconv.dylib] in /usr/lib may be hidden by files in: /opt/local/lib Some of these libraries may not be found correctly. CMake Warning at src/tex2lyx/CMakeLists.txt:33 (add_executable): Cannot generate a safe linker search path for target tex2lyx2.0 because files in some directories may conflict with libraries in implicit directories: link library [libiconv.dylib] in /usr/lib may be hidden by files in: /opt/local/lib Some of these libraries may not be found correctly. CMake Warning at src/client/CMakeLists.txt:20 (add_executable): Cannot generate a safe linker search path for target lyxclient2.0 because files in some directories may conflict with libraries in implicit directories: link library [libiconv.dylib] in /usr/lib may be hidden by files in: /opt/local/lib Some of these libraries may not be found correctly. For step 11 (cmake) here is the option cmake found/set: -- LYX_CPACK: OFF(Use the CPack management (Implies LYX_INSTALL option)) -- LYX_INSTALL : OFF(Build install projects/rules (implies a bunch of other options)) -- LYX_NLS : OFF(Use nls) -- LYX_ASPELL : OFF(Require aspell) -- LYX_ENCHANT : OFF(Require Enchant) -- LYX_HUNSPELL : OFF(Require Hunspell) -- LYX_DEBUG: OFF(Build debug version) -- LYX_RELEASE : ON (Build release version) -- LYX_PROFILE : OFF(Build profile version) -- LYX_USE_EXTERNAL_BOOST : OFF(Use external boost) -- LYX_USE_EXTERNAL_LIBINTL : ON (Use external libintl) -- LYX_PACKAGE_SUFFIX : ON (Use version suffix for packaging) -- LYX_PROGRAM_SUFFIX : ON (Append version suffix to binaries) -- LYX_INSTALL_PREFIX : OFF(Install path for LyX) -- LYX_DISABLE_PCH : ON (Disable precompiled headers) -- LYX_MERGE_FILES : OFF(Merge source files into one compilation unit) -- LYX_DEBUG_GLIBC : OFF(Enable libstdc++ debug mode) -- LYX_DEBUG_GLIBC_PEDANTIC : OFF(Enable libstdc++pedantic debug mode) -- LYX_STDLIB_DEBUG : OFF(Use debug stdlib) -- LYX_CONCEPT_CHECKS : OFF(Enable concept-checks) -- LYX_QUIET: OFF(Don't generate verbose makefiles) -- LYX_SHARED_LIBRARIES : OFF(Build shared libraries) -- -- Using GCC version 4.2.1 -- Looking for Q_WS_X11 -- Looking for Q_WS_X11 - not found. -- Looking for Q_WS_MAC -- Looking for Q_WS_MAC - found -- Looking for Q_WS_WIN -- Looking for Q_WS_WIN - not found. -- Found Qt-Version 4.7.0 -- Looking for iconv -- Looking for iconv - not found -- Found iconv library: /usr/lib/libiconv.dylib -- Found Z: /usr/lib/libz.dylib -- Looking for dgettext -- Looking for dgettext - not found -- -- - PACKAGE : LyX2.0 -- - PACKAGE_VERSION : 2.0.0svn -- - PROGRAM_SUFFIX : 2.0 -- - LYX_DATE: 2010-11-10 -- - LYX_DIR_VER : LYX_DIR_20x -- - LYX_USERDIR_VER : LYX_USERDIR_20x -- - LYX_ABS_TOP_SRCDIR : /Users/younes/devel/lyx/trunk -- - LYX_ABS_INSTALLED_DATADIR : /usr/local/lyx2.0 -- - LYX_ABS_INSTALLED_LOCALEDIR : /usr/local/lyx2.0/locale -- - LYX_INSTALL_SUFFIX : 2.0 Abdel.
Re: copying and pasting a LyX environment? (like Word's Format Painter)
Jean-Marc Lasgouttes a écrit : "Abdel" == Abdel <[EMAIL PROTECTED]> writes: Abdel> OK, thanks. My main problem is that while a MenuItem is of Abdel> Submenu kind, sometimes (depends on the document you load and Abdel> the time of day) its associated submenu is empty. This happens Abdel> only for the Navigate menu, others works fine. I think this is related to your next question. Menu objects are "uninstantiated" menus, and expand should be called on the one you want to open (File, Edit...) before doing anything else. I agree this is not a very good API (instantiated menus should be a different C++ class), but I do not think it is a big problem, actually. Well, my problem then is that I don't understand the API :-( Abdel> In my opinion we should just be able to use getMenu() without Abdel> having to expand it. In this case MenuVackend member menulist_ Abdel> should of course be mutable (because getMenu is a const Abdel> function). So the MenuBackend should make sure that the menu Abdel> you ask for is always up to date. I don't like mutable variables :) The question is probably why you want to get these menus. Are you trying to use MenuBackend to build your dynamic ToC stuff? No, I just wanted this Navigate menu to work, that's all. In this case I think you are using the wrong approach. You should take the horrible code from MenuBackend and merge it into toc.C. This code should return the ToC as a tree (not a list of strings) and MenuBackend and your code should use that directly. Well I have already written my own tree generation code in QTocDialog.C. I have just compared my code with the code from the MenuBackend and it is indeed similar (I prefer mine ;-)). I think I'll just give up on the Navigate menu and put a popup menu in one toolbar instead. The first Item in this menu would be to open the full blown TocDialog, the rest would be the standard navigate stuff. Abdel> Another problem that I have is with the MenuItem::func() Abdel> member. I store it this way in a QLAction which is a lyx Abdel> tailored QAction: QLAction * action = new Abdel> QLAction(*(owner_->view()), label, m->func()); So the Abdel> FuncRequest is stored in the QLAction and is called when you Abdel> click on the corresponding MenuItem. The problem is that this Abdel> make lyx crashing for some MenuItem randomly (not all). It Abdel> seems that this FuncRequest is not constant for a given Abdel> MenuItem... weird. I'd have to see the crash. I'll try to work on that next week-end. Abdel> My idea is that in the future, maybe for 1.5, there should be a Abdel> unique configuration file which will describe all available Abdel> FuncRequests, together with associated label, icon, tooltip, Abdel> number of argument (if any), etc. All these will be converted Abdel> into QLAction. These QLAction would then be available as Abdel> MenuItem or Toolbar button indifferently. I am not sure we want that, in particular for labels. Do we really want to enforce the way the menu appears? It would still be defined in a configuration file (the FuncRequest one). But I think this is not really important. In any case we could still provide a way to change the labels if really needed (ex: right-clicking on a menuItem could allow changing its label, shortcut, etc). Abdel> I realize now that my explanation is a bit abstract so I attach Abdel> my ports of QView, QLMenubar and QLPopupmenu to this mail Abdel> (QLAction is defined in QView.[hC] Abdel> Sorry Jean-Marc, you asked for it ;-) No problem. Thanks, Abdel. JMarc
Re: No automake-1.9 on mingw/msys yet...
Angus Leeming a écrit : Michael Gerz wrote: Note how the bar.h header file forward declares "class Foo;" rather than including foo.h (which it could have done instead). Qt3 tends to forward declare a lot less stuff than Qt4. However, that tends to increase compile times, not link times. The Qt4 link improvements probably lie elsewhere. Hum, I'm no expert in that domain but maybe the linker has to "unique" each and every methods that are defined in the duplicate headers. As mingw gcc 3.4 has no support for precompiled header the linker has to do this triage and this should take time, shouldn't it? (this is a question, I'm really not knowledgeable in that field) Maybe it's just that the mingw linker is not as optimized as the linux one and tends to keep multiple instances of the same code in memory... There is an experimental port of gcc 4 to mingw somewhere (thisiscoolgcc IIRC). It might be worth a try to test if things are better with this and precompiled header. Abdel. Angus
Re: No automake-1.9 on mingw/msys yet...
Michael Gerz a écrit : Beck, Andrew Thomas - BECAT001 wrote: Don't take it personally, but I actually prefer dynamic linking of stuff that is clearly an external library. Especially since it's used by a few things. What's the drama with linking it dynamically? I suspect it might improve link time/memory somewhat. Well, linking dynamically with qtwin and MinGW is so extraordinary slw. (takes hours and an infinite amount of memory) If Abdel is right You put doubt on my sincerity? :-) and qt 4.1 links very fast with MinGW, then qtwin is to blame. Abdel, what do you mean by forward declarations? Do you think we can improve link times by modifying the qtwin sources? I am asking because we had a very good cooperation with Christian Ehrlicher, the maintainer of qtwin, in the past. Maybe he can help us improving the situation. Angus has already explained that very well and I agree that it is not a valuable project. There might be a good side effect: push people in the Qt4.1 direction ;-) Abdel. Michael
Re: No automake-1.9 on mingw/msys yet...
Angus Leeming a écrit : Michael Gerz wrote: I post it from time to time :-) If only I could convince Angus that static linking is much better than dynamic linking. Than the whole LyX/Win family would be united again :-) You can't convince me, because it's not ;-) Let's be clear: it's a kludge to get decent compile times using the MinGW compiler. FYI, dynamic linking with Qt4.1 with full debug (-g) is very quick so I guess it should be possible to reduce this compile times significantly by re-architecturing the Qt3win port (I mean the library, not the frontend) by using more forward declaration. But this is of course beyond the scope of the Lyx project. Let's also be clear: compile times are better for you, but not significantly better for me. Same here. It's unacceptable in both cases because I can't use the computer for many hours (Windows is not very good at multitasking). Abdel Uniting the scripts is a different issue. I'm sure that it's not beyond the wit of man to modify development/Win32/packaging/build_lyxwin.sh so that there are both static and dynamic routes. Usage: sh build_lyxwin.sh static '1.3.7pre9' or sh build_lyxwin.sh dynamic '1.3.7pre9' where '1.3.7pre9' is an optional extra (as now).
Re: copying and pasting a LyX environment? (like Word's Format Painter)
Jean-Marc Lasgouttes a écrit :
"Abdel" == Abdel <[EMAIL PROTECTED]> writes:
Abdel> Well this use the Lyx Menu Backend which I have great
Abdel> difficulty to understand. It keeps crashing a lot so I gave up
Abdel> on that (But I have ported the menubar to Qt4.1).
The Navigation part is kind of horrible indeed. The rest should be
easier. Feel free to ask me.
OK, thanks. My main problem is that while a MenuItem is of Submenu kind,
sometimes (depends on the document you load and the time of day) its
associated submenu is empty. This happens only for the Navigate menu,
others works fine. It seems that the submenu is filled in after you ask
for it. So IMHO, there is a chicken and eggs problem here.
Ex: in this code snippet I had to put a continue here in order to avoid
potential crash:
if (m->kind() == MenuItem::Submenu) {
QMenu * subMenu = qMenu->addMenu(toqstr(getLabel(*m)));
if (m->submenuname().empty()) {
lyxerr[Debug::GUI]
<< "ERROR Submenu name empty formenuItem "
<< m->label() << endl;
continue;
}
Second, I really don't understand why we have to expand the menu we are
looking for into a new local menu:
Menu submenu;
// This has caused a crash once:
//owner_->backend().expand(*(m->submenu()), submenu, owner_->view());
// So I just do that:
Menu const & fromLyxMenu = owner_->backend().getMenu(m->submenuname());
owner_->backend().expand(fromLyxMenu, submenu, owner_->view());
In my opinion we should just be able to use getMenu() without having to
expand it. In this case MenuVackend member menulist_ should of course be
mutable (because getMenu is a const function). So the MenuBackend should
make sure that the menu you ask for is always up to date.
Another problem that I have is with the MenuItem::func() member. I store
it this way in a QLAction which is a lyx tailored QAction:
QLAction * action = new QLAction(*(owner_->view()), label, m->func());
So the FuncRequest is stored in the QLAction and is called when you
click on the corresponding MenuItem. The problem is that this make lyx
crashing for some MenuItem randomly (not all). It seems that this
FuncRequest is not constant for a given MenuItem... weird.
For comparison, in QLToolbar I create QActions (not QLAction) on the fly
and it works well.
My idea is that in the future, maybe for 1.5, there should be a unique
configuration file which will describe all available FuncRequests,
together with associated label, icon, tooltip, number of argument (if
any), etc. All these will be converted into QLAction. These QLAction
would then be available as MenuItem or Toolbar button indifferently.
I realize now that my explanation is a bit abstract so I attach my ports
of QView, QLMenubar and QLPopupmenu to this mail (QLAction is defined in
QView.[hC]
Sorry Jean-Marc, you asked for it ;-)
Abdel.
JMarc
// -*- C++ -*-
/**
* \file QtView.h
* This file is part of LyX, the document processor.
* Licence details can be found in the file COPYING.
*
* \author Lars Gullik Bjornes
* \author John Levon
*
* Full author contact details are available in file CREDITS.
*/
#ifndef QTVIEW_H
#define QTVIEW_H
// Must be here because of moc.
#include
#include "frontends/LyXView.h"
#include
#include
#include
//Added by qt3to4:
#include
class QToolBar;
class FuncRequest;
//class string;
namespace lyx {
namespace frontend {
class QCommandBuffer;
/**
* QLAction - Qt interface with LyX' FuncRequest.
*
* QLAction can be used in LyX menubar and/or toolbars.
*/
class QLAction: public QAction {
Q_OBJECT
public:
QLAction(LyXView & lyxView, std::string const & text,
FuncRequest const & func, std::string const & tooltip="");
QLAction(LyXView & lyxView, std::string const & icon, std::string const
& text,
FuncRequest const & func, std::string const & tooltip="");
private slots:
void action();
private:
FuncRequest const & func_;
LyXView & lyxView_;
};
/**
* QtView - Qt implementation of LyXView
*
* Qt-private implementation of the main LyX window.
*/
class QtView : public QMainWindow, public LyXView {
Q_OBJECT
public:
/// create a main window of the given dimensions
QtView(unsigned int w, unsigned int h);
~QtView();
/// show - display the top-level window
void show();
/// show busy cursor
virtual void busy(bool) const;
/// display a status message
virtual void message(std::string const & str);
/// clear status message
virtual void clearMessage();
/// add the command buffer
void addCommandBuffer(QToolBar * toolbar);
/// menu item ha
Re: copying and pasting a LyX environment? (like Word's Format Painter)
I have transfered this thread to lyx-devel where it belongs.
Andre Poenitz a écrit :
On Tue, Jan 10, 2006 at 02:26:48PM +0100, Abdel wrote:
This functionality could be implemneted in the Navigate menu in the
Qt frontend: Make the menu a list view, allowm multiple selection,
create and connect actions to movce things a level in or out.
I was thinking about modifying the TOC dialog to do exactly this: allow
moving a section and all it's dependencies to any upper or lower node
you want. The TOC could even become a dock widget on the left "a la
MSWord" and allow on-the-fly updating. Do you reckon the Navigate-Menu
code is cleaner for this?
The current Navigate menu?
Well this use the Lyx Menu Backend which I have great difficulty to
understand. It keeps crashing a lot so I gave up on that (But I have
ported the menubar to Qt4.1).
I'd think this is pure GUI stuff and should only call a few (new)
LFUNs (section-depth-{in,de}crease or similar) working on a selection
or something.
Yep, the idea would be to expand the QTocDialog functionality for doing
these (new) calls. I have already ported that to the new QTreeWidget
with a nice recursive function to go down the sections.
Could be extended to shift whole sections up and down.
I guess we could re-use cut&paste for this, couldn't we?
Probably, yes. But c&p is close to the dirty corners in LyX, so
'obvious' stuff might not be implemnetable as easy as it looks.
Anyway, this will have to wait until the main developers have time to
help me. I hope you deliver 1.4.0 very soon guys.
Abdel.
Less than 200 lines for the in/out part I'd bet.
Once you know what to do, it's always short to implement it ;-)
It usually is ;-}
Andre'
Re: No doc installed with Lyx-1.3.6-pre7 (windows)
Angus Leeming a écrit : Jean-Marc Lasgouttes wrote: "Abdel" == Abdel <[EMAIL PROTECTED]> writes: Abdel> Dear Angus, I've just tried your new package. It seems that the Abdel> documents in \Resources\lyx\doc\ are missing... This happens because, in 1.3.x the docs are in a different repository, and Angus is too lazy to get them :) Ok, the lazy bum finally got them. Funnily enough, the new version is LyX-1.3.6-pre7, so I can just tell Abdel he's wrong ;-) (The version he was using was -pre6.) That's called anticipation... You changed the future based on my prediction :-) Angus
No doc installed with Lyx-1.3.6-pre7 (windows)
Dear Angus, I've just tried your new package. It seems that the documents in \Resources\lyx\doc\ are missing... Abdel.
Re: Screen update improvements
Martin Vermeer a écrit : On Wed, Jan 04, 2006 at 12:55:42PM +0100, Abdel wrote: Jean-Marc Lasgouttes a écrit : "Abdel" == Abdel <[EMAIL PROTECTED]> writes: ... I guess so yes. Following patch will do so. Index: QWorkArea.C === RCS file: /var/cvs/lyx/lyx-devel/src/frontends/qt2/QWorkArea.C,v retrieving revision 1.29 diff -u -r1.29 QWorkArea.C --- QWorkArea.C 18 Jul 2005 00:29:12 - 1.29 +++ QWorkArea.C 4 Jan 2006 11:52:18 - @@ -57,7 +57,10 @@ content_->show(); - content_->setBackgroundColor(lcolorcache.get(LColor::background)); + // It is said that this help reduce flicker + content_->setBackgroundMode(NoBackground); + // If we go back to a custom backgound call: + // content_->setBackgroundColor(lcolorcache.get(LColor::background)); QHBoxLayout * vl = new QHBoxLayout(this); vl->addWidget(content_, 5); A technical remark: please attach patches as real attachments, so whitespace and formatting is preserved faithfully. Here, tabs have been replaced by blanks and I had to do some manual work to make it apply. Point taken, I'll do that next time. Thanks. Nice detective work BTW! My initial supposition about what was going wrong was not very smart... ;-) Bye, Abdel. - Martin
Re: Screen update improvements
Jean-Marc Lasgouttes a écrit : "Abdel" == Abdel <[EMAIL PROTECTED]> writes: Abdel> So forget what I said about system wide QT blablabla. IMO this Abdel> simple patch is very safe and it improves windows experience Abdel> significantly. With this change, Lyx-1.4.0 becomes usable for Abdel> small to medium documents under windows. So this patch helps qt4 too, right? No. It's a Qt3 thing. I manage to compile with the official qt3 (pfiou, never again!*) and I have verified that this patch eliminates the flickering under windows. Abdel. *FYI, final linking of libqt2 with full debug (-g) is 5 minutes and 20 megs with Qt4.1. Final dynamic linking of lyx-qt.exe is 5 minutes and 200 megs. Compare that with 300 megs and a lot of time for both operation for static linking with Qt3. JMarc
Re: Screen update improvements
Abdel a écrit :
Right now, I cannot compile with qt3, sorry. With my Qt4 port, there is
no flicker but I have tested this nonetheless with a different syntax:
viewport()->setAttribute(Qt::WA_OpaquePaintEvent);
The result is not good: all the "float buttons" (foot, figure, table,
etc) are black on black. The weird thing is that this behavior affects
also my previously compiled Qt3 version. I presume that floats are not
"painted" by the lyx core but use the background color instead, aren't
they? Apparently setting this attribute is propagated system wide by Qt4.
Silly me! This is because while testing the color preference panel I
inadvertently modified this background to black... ;-{
So forget what I said about system wide QT blablabla. IMO this simple
patch is very safe and it improves windows experience significantly.
With this change, Lyx-1.4.0 becomes usable for small to medium documents
under windows.
Abdel.
Index: QWorkArea.C
===
RCS file: /var/cvs/lyx/lyx-devel/src/frontends/qt2/QWorkArea.C,v
retrieving revision 1.29
diff -u -r1.29 QWorkArea.C
--- QWorkArea.C 18 Jul 2005 00:29:12 - 1.29
+++ QWorkArea.C 4 Jan 2006 11:52:18 -
@@ -57,7 +57,10 @@
content_->show();
- content_->setBackgroundColor(lcolorcache.get(LColor::background));
+ // It is said that this help reduce flicker
+ content_->setBackgroundMode(NoBackground);
+ // If we go back to a custom backgound call:
+ //
content_->setBackgroundColor(lcolorcache.get(LColor::background));
QHBoxLayout * vl = new QHBoxLayout(this);
vl->addWidget(content_, 5);
Re: lyx-1.4.0 and Qt-4.1
Andre Poenitz a écrit : On Mon, Jan 09, 2006 at 10:45:17AM +0100, Abdel wrote: I think we should get rid of them in the long run and favour 'proper' Qt 4 classes (even if the Q3* stuff is officially part of Qt4) I am getting rid of most of them right now. Nice. [...] By the way is there a rule concerning the \author field in the source? There is no hard rule as far as I can tell. If it's a bit more involved than simple search & replace or other 'cosmetic' changes it might be appropriate to add a new \author entry. For a Qt 3 -> Qt 4 port (especially when not using the Q3* support classes) I'd expect most of the .C and some of the .h files getting additonal \author entries. That's what I thought, thanks, Abdel. Andre'
Re: lyx-1.4.0 and Qt-4.1
Andre Poenitz a écrit : On Tue, Dec 27, 2005 at 11:43:05AM +0100, Abdel wrote: Dear developpers, I could not sleep last night so I tried as an exercise to see if lyx could be ported easily to the fresh Qt-4.1. As you might guess it was more difficult than I originally thought. But after much work it compiles and loads! Whohey. It tool me almost two weeks to covert less than 100 kLOC from Qt 3.3. to 4.0. There is a problem QImage which doesn't support any image format. I suspect the Painter is not correctly started. Because of that, the program could not load any document (more on that later). But the menubar, the "Browse file" dialog and the about box are functional. I don't know if this is interesting to you and if you planned already to port to Qt4.1 sometimes in the future. I've even heard somebody at Trolltech pondering that issue ;-} I resolved the problem by using QImageReader instead. If so, I am willing to help completing this port if someone more knowledgeable than me take lead. If not, it was fun anyway and I learned a bit about Qt4 in the process. IMO it is much cleaner that Qt3 It really is. (Disclaimer: I knew close to nothing on these two before yesterday). I could send my qt4 directory to anyone interested in any case. What I did: 1) copy "src/frontends/qt2" to "src/frontends/qt4" 2) launch qt3to4 porting tool to all .C and .h 3) replace uic with uic3 in all Makefiles 4) remove "-tr qt_" from UICFLAGS in all Makefiles 5) compile and fix... So this uses the Q3* suport classes? I think we should get rid of them in the long run and favour 'proper' Qt 4 classes (even if the Q3* stuff is officially part of Qt4) I am getting rid of most of them right now. In any case, getting the beast up and running is a big step forward in this area. Thanks. But all the credits goes to you all and specially John Levon who wrote portable code. By the way is there a rule concerning the \author field in the source? I know nothing about the auto-tools so I just modified the Makefile, sorry about that. The big remaining problem is with QPicture. In order to let lyx start, I had to comment line "src/graphics/GraphicsCacheItem.C":340 _QPicture_? We should not have used this at all? [...] displayed filename: D:\msys\home\yns\src\lyx-devel\lib\images\banner.ppm Recognised Fileformat: ppm The file contains ppm format data. Just convert the ppm to png and use this. Less hassle than anything else. I have resolved that problem but it's true that a format change would be probably better. I would say SVG instead. Thanks for taking the time to answer this, Abdel. Andre'
Re: [Patch] (Re: Screen update improvements)
Jean-Marc Lasgouttes a écrit : "Abdel" == Abdel <[EMAIL PROTECTED]> writes: Abdel> Hum, actually I think there might be another reason. Michael, Abdel> could you please try this patch: This seems quite interesting. Do you have reasons to think it should help, or is it just that it looks nicer? I think it should help definitely this use case: someone who keep an arrow key pressed in order to move within the text. This is because, the problem with the "repaint" function is that it ask Qt to repaint immediately. So multiply that by the autorepeat settings of some desktop that could be very high for some people and I guess that the end result is an unresponsive application. This is just a guess, I haven't read the Cursor code in detail. Abdel. JMarc
Re: How to speed up LyXText::breakParagraph?
Andre Poenitz a écrit :
On Wed, Jan 04, 2006 at 11:53:45AM +0100, Abdel wrote:
From what I see it uses size() and operator[] so deque would be fine
here also. But maybe rewriting this patch to use ParagraphList::iterator
and algorithm::find would be better, wouldn't it? This way we won't rely
on vector property.
We heavily rely on operator[] being reasonably fast, i.e. O(1)
maybe O(ln n). Certainly not O(n).
Note that my dual vector-list approach should offer o(1) operator[] access.
Like it is now, IMHO, lyx-1.4 is close to unusable under window. Is
Andre had something that IIRC would replace the official insert() by a
homegrown one, presumably faster. (What's the status of that?)
I think it is possible to rewrite the ParagraphList class that would not
need the removal of the official insert(), only a cosmetic change.
IMHO, a good solution would be to use a list member to store
the paragraphs and a vector::iterator> for the
interface. This way ParagraphList::insert would call list::insert and
then update the vector or list iterator. I believe this would imply
minimal change to the code using ParagraphList; we would just need to
replace "insert(XXX.begin()+pos, Par)" with "insert(pos, Par)". Here is
a class prototype (not tested):
class ParagraphList
{
[...]
};
What do think?
Ok if it works. Could be even faster than the custom swap-based insert()
implmentation as swapping paragraphs is still slower than assigning
Paragraph pointers.
I would be happy to work on this once the signal is emitted :-)
Abdel.
Andre'
Re: [Patch] (Re: Screen update improvements)
Lars Gullik Bjønnes a écrit : Abdel <[EMAIL PROTECTED]> writes: | Martin Vermeer a écrit : | > On Sun, Jan 08, 2006 at 04:38:21PM +0100, Michael Gerz wrote: | >> Abdel wrote: | >> | >>>>> About the flickering, I don't know. You could verify with my earlier | >>>>> published PAINTING debug patch, precisely which rows are getting | >>>>> updated by the LyX painter. | >>>> AFAIK, this flickering is not due to lyx internal repainting (i.e | >>>> to the pixmap) but to the screen update. What Michael sees is a | >>>> background repaint immediately followed by the pixmap repaint on | >>>> screen. And this is what my simple patch is fixing (as advised by | >>>> Jean-Marc) by eliminating the superfluous background repainting. | >>> | >>> Hum, actually I think there might be another reason. Michael, | >>> could you please try this patch: | >>> | >>> Index: qscreen.C | >>> === | >>> | >>> - owner_.getContent()->repaint( | >>> + owner_.getContent()->update( | >> Abdel, Martin, | >> | >> I must confess that I am a bit puzzled. If I understand correctly, | >> it doesn't matter how clever we are as long as the background is | >> repainted every time. | >> | >> Maybe these results will help you to sort out things: | >> | >> 1. With a fresh lyx-devel snapshot (retrieved from CVS yesterday), | >> the flickering occurs with every character insertion/deletion and | >> text selection but not when moving the cursor. | >> 2. With the additional simple QWorkarea.C patch proposed by J-M, I | >> see no flickering at all (even without Martin's recent patch | >> proposals) | >> 3. With the above qscreen.C patch (as an alternative to 2.), the | >> flickering is still there. (It also doesn't help to also replace | >> "repaint" by "update" in method removeCursor) | >> | >> AFAICS, Martin's work is orthogonal to Abdel's. I leave it to you | >> to draw the final conclusion. Do we loose anything if we change | >> QWorkarea.C? | >> | >> Thank you very much for all the efforts in advance! You make people | >> really happy! | >> | >> Michael | > Yes, I agree... I think "flicker" and "speed" are orthogonal | > problems. | > The fact that cursor movement doesn't produce flicker is because then | > there literally is no screen update. | > - Martin | | Yep and IMHO the no-background change is a must for windows. If it | doesn't change anything under linux and Mac (it shouldn't) let it be | in. If you think it's a risk, put an #ifdef QT_WIN and #endif around | it. What I think is that changes like these are too late for 1.4.0. But we expect 1.4.1 do be done fairly quick after 1.4.0 is released. No problem but make sure that this is said in the announcement for 1.4.0 - i.e: Windows user should not upgrade to 1.4.0 but wait for 1.4.1. Thanks, Abdel.
Re: lyx-1.4.0 and Qt-4.1
Andre Poenitz a écrit : On Thu, Dec 29, 2005 at 08:51:02PM +0100, Abdel wrote: Hello, Judging from the absence of answer, I suppose this matter is not interesting to you :-( You culd have as well assumed people were absent from ailing lists. Would be closer to the truth at least in my case. Welcome back then :-). By the way, I am using the gmane news interface so no need to "reply all". Thanks in advance. It's OK, I understand that you are all very busy with the release of 1.4.0. I have worked some more on the port so if there is any interest in the future, just let me know. FYI, the changes from Qt3 to Qt4 are quite big and I think it's worth keeping both version in parallel. Actually I don't think there won't be a need to maintain two Qt frontends in parallel. As soon as some Qt 4.x version works, 3.x should be removed. Well, the port now works for editing except for the blinking cursor... and performance is very good. Concerning the dialogs, I had once something that worked more or less, using non ported ui files and Q3xxx classes but I had here and there lots of crashes. So I decided to go for the full monty: I have ported all the ui files to Qt4 format. Of course now the dialogs are broken because the signal and slot connections needs to be restored but they shows no problem. Back to the subject, I think it will take sometime before all the dialogs are restored to a functional state (more so because I am alone doing this) so in the mean time two versions will need to be maintained in parallel. Of course, it all depends on what you mean by "works" ;-) In any case, I have noticed that the Qt3 frontend has not seen much change for the last year so it would be an easy task to maintain Qt3 in parallel. Abdel. Andre'
Re: [Patch] (Re: Screen update improvements)
Martin Vermeer a écrit : On Sun, Jan 08, 2006 at 04:38:21PM +0100, Michael Gerz wrote: Abdel wrote: About the flickering, I don't know. You could verify with my earlier published PAINTING debug patch, precisely which rows are getting updated by the LyX painter. AFAIK, this flickering is not due to lyx internal repainting (i.e to the pixmap) but to the screen update. What Michael sees is a background repaint immediately followed by the pixmap repaint on screen. And this is what my simple patch is fixing (as advised by Jean-Marc) by eliminating the superfluous background repainting. Hum, actually I think there might be another reason. Michael, could you please try this patch: Index: qscreen.C === - owner_.getContent()->repaint( + owner_.getContent()->update( Abdel, Martin, I must confess that I am a bit puzzled. If I understand correctly, it doesn't matter how clever we are as long as the background is repainted every time. Maybe these results will help you to sort out things: 1. With a fresh lyx-devel snapshot (retrieved from CVS yesterday), the flickering occurs with every character insertion/deletion and text selection but not when moving the cursor. 2. With the additional simple QWorkarea.C patch proposed by J-M, I see no flickering at all (even without Martin's recent patch proposals) 3. With the above qscreen.C patch (as an alternative to 2.), the flickering is still there. (It also doesn't help to also replace "repaint" by "update" in method removeCursor) AFAICS, Martin's work is orthogonal to Abdel's. I leave it to you to draw the final conclusion. Do we loose anything if we change QWorkarea.C? Thank you very much for all the efforts in advance! You make people really happy! Michael Yes, I agree... I think "flicker" and "speed" are orthogonal problems. The fact that cursor movement doesn't produce flicker is because then there literally is no screen update. - Martin Yep and IMHO the no-background change is a must for windows. If it doesn't change anything under linux and Mac (it shouldn't) let it be in. If you think it's a risk, put an #ifdef QT_WIN and #endif around it. Abdel.
Re: [Patch] (Re: Screen update improvements)
Abdel a écrit : Martin Vermeer a écrit : On Sun, Jan 08, 2006 at 12:40:02PM +0100, Michael Gerz wrote: Martin Vermeer wrote: using qtwin on Windows, I cannot see any difference. The flickering still occurs even if I select text in a single row. (BTW: The best way to cause flickering is editing a short document that does not cover the full screen; you can see easily how the gray background at the bottom flickers). Another thing that astonishes me: Why do we have to do a full redraw if a single character is inserted/deleted? It shouldn't be necessary in most cases. With an updated tree you shouldn't see _any_ full-screen update for typing characters generally, except occasionally when you cause a rebreak that changes paragraph height. Otherwise only the current paragraph should refresh. About the flickering, I don't know. You could verify with my earlier published PAINTING debug patch, precisely which rows are getting updated by the LyX painter. AFAIK, this flickering is not due to lyx internal repainting (i.e to the pixmap) but to the screen update. What Michael sees is a background repaint immediately followed by the pixmap repaint on screen. And this is what my simple patch is fixing (as advised by Jean-Marc) by eliminating the superfluous background repainting. Hum, actually I think there might be another reason. Michael, could you please try this patch: Index: qscreen.C === RCS file: /var/cvs/lyx/lyx-devel/src/frontends/qt2/qscreen.C,v retrieving revision 1.29 diff -u -r1.29 qscreen.C --- qscreen.C 19 May 2005 16:34:02 - 1.29 +++ qscreen.C 8 Jan 2006 13:24:45 - @@ -144,7 +144,7 @@ break; } - owner_.getContent()->repaint( + owner_.getContent()->update( cursor_x_, cursor_y_, cursor_w_, cursor_h_); }
Re: [Patch] (Re: Screen update improvements)
Martin Vermeer a écrit : On Sun, Jan 08, 2006 at 12:40:02PM +0100, Michael Gerz wrote: Martin Vermeer wrote: using qtwin on Windows, I cannot see any difference. The flickering still occurs even if I select text in a single row. (BTW: The best way to cause flickering is editing a short document that does not cover the full screen; you can see easily how the gray background at the bottom flickers). Another thing that astonishes me: Why do we have to do a full redraw if a single character is inserted/deleted? It shouldn't be necessary in most cases. With an updated tree you shouldn't see _any_ full-screen update for typing characters generally, except occasionally when you cause a rebreak that changes paragraph height. Otherwise only the current paragraph should refresh. About the flickering, I don't know. You could verify with my earlier published PAINTING debug patch, precisely which rows are getting updated by the LyX painter. AFAIK, this flickering is not due to lyx internal repainting (i.e to the pixmap) but to the screen update. What Michael sees is a background repaint immediately followed by the pixmap repaint on screen. And this is what my simple patch is fixing (as advised by Jean-Marc) by eliminating the superfluous background repainting. Abdel. Did the patch apply cleanly? That means you must have the singlepar stuff in your local tree... strange. - Martin
Re: How to speed up LyXText::breakParagraph?
Jean-Marc Lasgouttes a écrit : "Abdel" == Abdel <[EMAIL PROTECTED]> writes: Abdel> Oups I just notice a Cut&Paste problem. The prototype I am Abdel> proposing is as follow, sorry about that. Optionnally, insert Abdel> could return a reference or a pointer to the newly inserted Abdel> paragraph but I think that the get(size_t) function is cleaner. I guess Lars won't like it because ParagraphList is not a good stl container anymore... I guess what we are looking after is some templatized container, and I am actually surprised that it does not exists already. Well, if the class provide "insert", "erase" and "find", isn't that enought? I think it is even possible to derive ParagraphList from vector::iterator> if we need the container interface. I can write a new proposal if you want. BTW, don't you define ParagraphList::Iter twice? Typo, sorry. I haven't tested this, I wrote the class within the email. JMarc
Re: Screen update improvements
Jean-Marc Lasgouttes a écrit : "Abdel" == Abdel <[EMAIL PROTECTED]> writes: Abdel> I guess so yes. Following patch will do so. Do you see some improvement with the patch? I guess only qt3 could benefit. Right now, I cannot compile with qt3, sorry. With my Qt4 port, there is no flicker but I have tested this nonetheless with a different syntax: viewport()->setAttribute(Qt::WA_OpaquePaintEvent); The result is not good: all the "float buttons" (foot, figure, table, etc) are black on black. The weird thing is that this behavior affects also my previously compiled Qt3 version. I presume that floats are not "painted" by the lyx core but use the background color instead, aren't they? Apparently setting this attribute is propagated system wide by Qt4. Abdel. JMarc
Re: How to speed up LyXText::breakParagraph?
Oups I just notice a Cut&Paste problem. The prototype I am proposing is
as follow, sorry about that. Optionnally, insert could return a
reference or a pointer to the newly inserted paragraph but I think that
the get(size_t) function is cleaner.
class ParagraphList
{
public:
///
typedef std::list::iterator Pli;
typedef std::list::const_iterator Iter;
protected:
typedef std::vector::iterator Iter;
list ParList_;
vector PliVector_;
public:
///
ParagraphList()
{
// Reserve Memory for 10 iterators
// which would represent 100 paragraph
// I guess this is enough?
PliVector_.reserve(10);
}
Paragrah& get(size_t pos)
{
BOOST_ASSERT(pos < PliVector_.size())
return *PliVector_[pos];
}
/// Erases the paragraph at position pos.
bool erase(size_t pos)
{
if (pos >= PliVector_.size())
{
// What happened here?
return false
}
size_t new_size=PliVector_.size()-1;
PliVector.resize(new_size);
if (pos == PliVector_.size())
{
PliVector[pos] = ParList_.pop_back(Par);
}
else
{
ParList_.erase(PliVector_[pos]);
}
// Warning: I think Vector resize does not keep data
// in this case. So it is safer to update the vector
// entirely
Pli pli = ParList_.begin();
for (size_t i=0; i PliVector_.size())
{
// What happened here?
return false;
}
size_t new_size=PliVector_.size()+1;
PliVector.resize(new_size);
if (pos == PliVector_.size())
{
PliVector[pos] = ParList_.push_back(Par);
}
else
{
Pli pli = ParList_.insert(PliVector_[pos], Par);
for (size_t i=pos; i
Martin Vermeer a écrit :
On Tue, Jan 03, 2006 at 07:52:13PM +0100, Abdel wrote:
Hello,
On windows with 1.4.0cvs on for big documents (ex: Extended.lyx),
there is a big delay (~1s) before a "Carriage Return" is shown on
screen after typing the "enter" key in the middle of a paragraph. The
same will happen when you type "Backspace" at the beginning of a
paragraph. On the contrary, if you type Ctrl-Z immediately after, the
screen update is instantaneous.
For both keys, 1.3.7pre is very quick.
I am trying to investigate if I could speed-up this a bit because
this is very, very irritating. I found that the big delay is in
"LyXText::breakParagraph" and more precisely in "::breakParagraph",
paragraph_funcs.C:97. The time consuming operation is the insertion
of a new paragraph inside the ParagraphList which is in fact a
std::vector :
ParagraphList::iterator tmp =
pars.insert(pars.begin() + par_offset + 1, Paragraph());
I have compiled this file with -O3 but the slowness is still there.
Indeed insertion inside a vector is known to be inefficient. I have
read the history about ParagraphList_fwd.h
(http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/src/ParagraphList_fwd.h)
and I guess there might be some valid reason to choose a vector
instead of a list but performance wise, it shows, definitely. I have
tried to replace with a list but this won't compile because some
source needs the [] operator. I have also tried a deque and the
results are a bit better. The weird thing is that the slowness is not
at the same place. Indeed, within a "Standard" environment, the
paragraph insertion at the beginning seems to be very fast but the
following operation is slowing things down:
for (pos_type i = pos_end; i >= pos; --i)
par.eraseIntern(i);
Within a "List" environment, the behavior is the same as with a
vector based class: the slowness is in the paragraph insertion at the
beginning.
But I don't know if this is safe, so my question is: is there any
assumption in the code that the ParagraphList use a contiguous
memory? Deque does not... But "Extended.lyx" loads fine and all seems
correct (math, table, etc...).
There is a pending patch which could use the property... or
not (bug 2015) ;-)
From what I see it uses size() and operator[] so deque would be fine
here also. But maybe rewriting this patch to use ParagraphList::iterator
and algorithm::find would be better, wouldn't it? This way we won't rely
on vector property.
I think a better solution wou
Re: Screen update improvements
Jean-Marc Lasgouttes a écrit : "Abdel" == Abdel <[EMAIL PROTECTED]> writes: Abdel> Michael Gerz a écrit : Martin, your row signature patch is excellent as it reduces screen flickering significantly (you could the flicking on Windows with qtwin). Abdel> FYI, without this patch (I have not update my cvs yet), my Qt4 Abdel> port has zero flickering :-) I think this patch is solving here Abdel> a problem which is in the Qt3 frontend. During my port, I have Abdel> erased all the calls to the "QWidget::repaint" function and I Abdel> just have one "update" to the screen. In other word, I let Qt Abdel> decide when to draw. Concerning flicker, I read that using setBackgroundMode(NoBackground) on a custom Widget help avoiding clearing the windows first. Is that true? I guess so yes. Following patch will do so. Reference: http://developer.kde.org/documentation/books/kde-2.0-development/ch09lev1sec2.html There are also some double bufferning tricks there. JMarc Index: QWorkArea.C === RCS file: /var/cvs/lyx/lyx-devel/src/frontends/qt2/QWorkArea.C,v retrieving revision 1.29 diff -u -r1.29 QWorkArea.C --- QWorkArea.C 18 Jul 2005 00:29:12 - 1.29 +++ QWorkArea.C 4 Jan 2006 11:52:18 - @@ -57,7 +57,10 @@ content_->show(); - content_->setBackgroundColor(lcolorcache.get(LColor::background)); + // It is said that this help reduce flicker + content_->setBackgroundMode(NoBackground); + // If we go back to a custom backgound call: + // content_->setBackgroundColor(lcolorcache.get(LColor::background)); QHBoxLayout * vl = new QHBoxLayout(this); vl->addWidget(content_, 5);
Re: How to speed up LyXText::breakParagraph?
Martin Vermeer a écrit :
On Tue, Jan 03, 2006 at 07:52:13PM +0100, Abdel wrote:
Hello,
On windows with 1.4.0cvs on for big documents (ex: Extended.lyx), there
is a big delay (~1s) before a "Carriage Return" is shown on screen after
typing the "enter" key in the middle of a paragraph. The same will
happen when you type "Backspace" at the beginning of a paragraph. On the
contrary, if you type Ctrl-Z immediately after, the screen update is
instantaneous.
For both keys, 1.3.7pre is very quick.
I am trying to investigate if I could speed-up this a bit because this
is very, very irritating. I found that the big delay is in
"LyXText::breakParagraph" and more precisely in "::breakParagraph",
paragraph_funcs.C:97. The time consuming operation is the insertion of a
new paragraph inside the ParagraphList which is in fact a std::vector :
ParagraphList::iterator tmp =
pars.insert(pars.begin() + par_offset + 1, Paragraph());
I have compiled this file with -O3 but the slowness is still there.
Indeed insertion inside a vector is known to be inefficient. I have read
the history about ParagraphList_fwd.h
(http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/src/ParagraphList_fwd.h)
and I guess there might be some valid reason to choose a vector instead
of a list but performance wise, it shows, definitely. I have tried to
replace with a list but this won't compile because some source needs the
[] operator. I have also tried a deque and the results are a bit better.
The weird thing is that the slowness is not at the same place. Indeed,
within a "Standard" environment, the paragraph insertion at the
beginning seems to be very fast but the following operation is slowing
things down:
for (pos_type i = pos_end; i >= pos; --i)
par.eraseIntern(i);
Within a "List" environment, the behavior is the same as with a vector
based class: the slowness is in the paragraph insertion at the beginning.
But I don't know if this is safe, so my question is: is there any
assumption in the code that the ParagraphList use a contiguous memory?
Deque does not... But "Extended.lyx" loads fine and all seems correct
(math, table, etc...).
There is a pending patch which could use the property... or
not (bug 2015) ;-)
From what I see it uses size() and operator[] so deque would be fine
here also. But maybe rewriting this patch to use ParagraphList::iterator
and algorithm::find would be better, wouldn't it? This way we won't rely
on vector property.
I think a better solution would be to use a map or maybe a vector of
pointer.
Like it is now, IMHO, lyx-1.4 is close to unusable under window. Is
there some unofficial patch that would speed up things a bit?
Andre had something that IIRC would replace the official insert() by a
homegrown one, presumably faster. (What's the status of that?)
I think it is possible to rewrite the ParagraphList class that would not
need the removal of the official insert(), only a cosmetic change.
IMHO, a good solution would be to use a list member to store
the paragraphs and a vector::iterator> for the
interface. This way ParagraphList::insert would call list::insert and
then update the vector or list iterator. I believe this would imply
minimal change to the code using ParagraphList; we would just need to
replace "insert(XXX.begin()+pos, Par)" with "insert(pos, Par)". Here is
a class prototype (not tested):
class ParagraphList
{
public:
///
typedef std::vector BaseType;
typedef std::vector ::iterator Iter;
typedef std::vector ::const_iterator ConstIter;
typedef std::list::iterator Pli;
typedef std::list::const_iterator Iter;
protected:
typedef std::vector::iterator Iter;
list ParList_;
vector PliVector_;
public:
///
ParagraphList()
{
// Reserve Memory for 10 iterators
// which would represent 100 paragraph
// I guess this is enough?
PliVector_.reserve(10);
}
Paragrah& get(size_t pos)
{
BOOST_ASSERT(pos < PliVector_.size())
return *PliVector_[pos];
}
/// Erases the paragraph at position pos.
bool erase(size_t pos)
{
if (pos >= PliVector_.size())
{
// What happened here?
return false
}
size_t new_size=PliVector_.size()-1;
PliVector.resize(new_size);
if (pos == PliVector_.size())
{
PliVector[pos] = ParList_.pop_back(Par);
}
else
{
P
How to speed up LyXText::breakParagraph?
Hello, On windows with 1.4.0cvs on for big documents (ex: Extended.lyx), there is a big delay (~1s) before a "Carriage Return" is shown on screen after typing the "enter" key in the middle of a paragraph. The same will happen when you type "Backspace" at the beginning of a paragraph. On the contrary, if you type Ctrl-Z immediately after, the screen update is instantaneous. For both keys, 1.3.7pre is very quick. I am trying to investigate if I could speed-up this a bit because this is very, very irritating. I found that the big delay is in "LyXText::breakParagraph" and more precisely in "::breakParagraph", paragraph_funcs.C:97. The time consuming operation is the insertion of a new paragraph inside the ParagraphList which is in fact a std::vector : ParagraphList::iterator tmp = pars.insert(pars.begin() + par_offset + 1, Paragraph()); I have compiled this file with -O3 but the slowness is still there. Indeed insertion inside a vector is known to be inefficient. I have read the history about ParagraphList_fwd.h (http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/src/ParagraphList_fwd.h) and I guess there might be some valid reason to choose a vector instead of a list but performance wise, it shows, definitely. I have tried to replace with a list but this won't compile because some source needs the [] operator. I have also tried a deque and the results are a bit better. The weird thing is that the slowness is not at the same place. Indeed, within a "Standard" environment, the paragraph insertion at the beginning seems to be very fast but the following operation is slowing things down: for (pos_type i = pos_end; i >= pos; --i) par.eraseIntern(i); Within a "List" environment, the behavior is the same as with a vector based class: the slowness is in the paragraph insertion at the beginning. But I don't know if this is safe, so my question is: is there any assumption in the code that the ParagraphList use a contiguous memory? Deque does not... But "Extended.lyx" loads fine and all seems correct (math, table, etc...). I think a better solution would be to use a map or maybe a vector of pointer. Like it is now, IMHO, lyx-1.4 is close to unusable under window. Is there some unofficial patch that would speed up things a bit? Thanks, Abdel.
Re: Screen update improvements
Angus Leeming a écrit : Abdel wrote: your row signature patch is excellent as it reduces screen flickering significantly (you could the flicking on Windows with qtwin). FYI, without this patch (I have not update my cvs yet), my Qt4 port has zero flickering :-) Right. Because Qt4 double buffers everything. I think this patch is solving here a problem which is in the Qt3 frontend. During my port, I have erased all the calls to the "QWidget::repaint" function and I just have one "update" to the screen. In other word, I let Qt decide when to draw. Also right (and good). But if we regenerate a pixmap a hundred times and Qt displays it only once, then there's some redundancy there, no? Totally, both painting should be minimum. I just wanted to point out that (IMHO) the flickering is not due to the pixmap repaint but more to the screen repaint. But as I said, I am not an expert and I am sure that this patch is necessary. Abdel.
Re: Screen update improvements
Michael Gerz a écrit :
Martin,
your row signature patch is excellent as it reduces screen flickering
significantly (you could the flicking on Windows with qtwin).
FYI, without this patch (I have not update my cvs yet), my Qt4 port has
zero flickering :-)
I think this patch is solving here a problem which is in the Qt3
frontend. During my port, I have erased all the calls to the
"QWidget::repaint" function and I just have one "update" to the screen.
In other word, I let Qt decide when to draw.
I think the screen redraw that you see is due to an excessive call to
repaint() that are not necessary. IMHO this patch tries to reduce the
number of painting on the intermediate pixmap and this is good because,
as a side effect it reduces also the number of screen repaint.
But I am not an expert so maybe this is just because Qt4 is supposed to
be totally double-buffered.
Abdel.
However, I don't understand why we have to redraw the whole screen in
case of selections. Doesn't your nice "always draw current row" patch
capture selections?
I tried the following modification and couldn't find anything going
wrong. Could you please enlighten me?
Thanks, Michael
Index: rowpainter.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/rowpainter.C,v
retrieving revision 1.162
diff -u -r1.162 rowpainter.C
--- rowpainter.C1 Jan 2006 23:06:23 - 1.162
+++ rowpainter.C2 Jan 2006 19:47:28 -
@@ -826,7 +826,7 @@
for (pit_type pit = vi.p1; pit <= vi.p2; ++pit) {
Paragraph const & par = text->getPar(pit);
yy += par.ascent();
- paintPar(pi, *bv.text(), pit, 0, yy, select ||
!vi.singlepar);
+ paintPar(pi, *bv.text(), pit, 0, yy, /*select ||*/
!vi.singlepar);
yy += par.descent();
}
Re: lyx 1.4.0 for windows: compilation progress report and impression
Helge Hafting a écrit : On Fri, Dec 23, 2005 at 04:42:17PM +0100, Jean-Marc Lasgouttes wrote: "Abdel" == Abdel <[EMAIL PROTECTED]> writes: Abdel> Jean-Marc Lasgouttes a écrit : "Abdel" == Abdel <[EMAIL PROTECTED]> writes: Abdel> Oups, I have just discovered the math and table bars right Abdel> clicking on the top toolbar. All I can say is WAHOU !!! :-) Abdel> Sorry for that. Actually, it is possible to edit ui/default.ui to have these toolbars appear automatically when needed. Abdel> Very good! This should be the default IMHO. Not everybody appreciates to have toolbars popping up at seemingly random times. What we need is an user interface to set these values. That'd be nice. In the meantime, what exactly do I do to my "default.ui" in order to enable this labor-saving behaviour? Under windows, the location would be: \Resources\LyX\ui\default.ui Modify the toolbar section like this: Toolbars "standard" "on,top" "extra" "on,top" "table" "table,bottom" "math" "math,bottom" "minibuffer" "off,bottom" End I copied a default.ui from /usr/share/lyx/ui to .lyx/ui but found no trivial way of enabling automatic toolbars. Attached my default.ui Helge Hafting # -*- text -*- # file default.ui # This file is part of LyX, the document processor. # Licence details can be found in the file COPYING. # author John Levon # Full author contact details are available in file CREDITS. # This is the default LyX user interface definition file. # The syntax should be straightforward enough. # The interface is designed (partially) following the KDE Human Interface # Guidelines (http://usability.kde.org/hig/) Include "stdmenus.ui" Include "stdtoolbars.ui" # Which toolbars to use. # # The second parameter are the flags : # # on: the toolbar is visible # off: the toolbar is not visible # math: the toolbar is visible only when in math # table: the toolbar is visible only when in a table # top: the toolbar should be at the top of the window # bottom: the toolbar should be at the bottom of the window # left: the toolbar should be at the left of the window # right: the toolbar should be at the right of the window # Toolbars "standard" "on,top" "extra" "on,top" "table" "table,bottom" "math" "math,bottom" "minibuffer" "off,bottom" End
Re: lyx-1.4.0 and Qt-4.1
Hello, Don't worry this is not (yet) an help request, just a status report on my qt4 port. From now, I will just wait until lyx-1.4 is released and for someone who is interested to help me. The good news (see attached) is that I am able to load any lyx document without crashing :-). The bad news is that resize to a greater size than the initial size doesn't redraw the screen (but resize to smaller size work). I first tried to fix the current code but this was too complicated. So I simplified the code wherever possible by using Qt4 feature. Here are the class that were "re-enginered": - QLToolbar: replaced button with action. - QContentpane: simplified a bit - QLPainter: get rid of start() and end(), QPainter created on the fly - QWorkarea: now inherits QScrollArea - Qtwiew: switched to QMainApplication (Qt4). - emptytable: use QTableWidget instead of local QtTableView and maybe other thinks that I forgot. voila! Happy new year to all, Abdel. Abdel a écrit : Dear developpers, I could not sleep last night so I tried as an exercise to see if lyx could be ported easily to the fresh Qt-4.1. As you might guess it was more difficult than I originally thought. But after much work it compiles and loads! There is a problem QImage which doesn't support any image format. I suspect the Painter is not correctly started. Because of that, the program could not load any document (more on that later). But the menubar, the "Browse file" dialog and the about box are functional. I don't know if this is interesting to you and if you planned already to port to Qt4.1 sometimes in the future. If so, I am willing to help completing this port if someone more knowledgeable than me take lead. If not, it was fun anyway and I learned a bit about Qt4 in the process. IMO it is much cleaner that Qt3 (Disclaimer: I knew close to nothing on these two before yesterday). I could send my qt4 directory to anyone interested in any case. What I did: 1) copy "src/frontends/qt2" to "src/frontends/qt4" 2) launch qt3to4 porting tool to all .C and .h 3) replace uic with uic3 in all Makefiles 4) remove "-tr qt_" from UICFLAGS in all Makefiles 5) compile and fix... I know nothing about the auto-tools so I just modified the Makefile, sorry about that. The big remaining problem is with QPicture. In order to let lyx start, I had to comment line "src/graphics/GraphicsCacheItem.C":340 // There must be a format to load from. BOOST_ASSERT(!formats.empty()); I have attached my modified "src/frontends/qt4/Qimage.C". Please find below, the output of lyx -dbg graphics. Thanks, Abdel. D:\msys\home\yns\src\lyx-devel\src>.\lyx-qt -dbg graphics Setting debug level to graphics Debugging `graphics' (Graphics conversion and loading) LoaderQueue: priority set to 10 images at a time, 100 milliseconds between calls Recognised Fileformat: agr filetools(getFormatFromContents) Couldn't find a known format! Ignoring obsolete use_tempdir flag. filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) File type not recognised before EOF! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! Language code:C Setting new locale for Qt:C LoaderQueue: waking up QPainter::begin(), paintdevice returned engine == 0, type: 3 QPainter::end: Painter is not active, aborted QPainter::begin(), paintdevice returned engine == 0, type: 2 Painter started successfully. QColor::setNamedColor: unknown color name 'grey40' QPainter::end: Painter is not active, aborted QPainter::begin(), paintdevice returned engine == 0, type: 3 QPainter::end: Painter is not active, aborted lyx: Disabling LyX socket. LoaderQueue: 1 items in the queue QPainter::begin(), paintdevice returned engine == 0, type: 2 Painter started successfully. QPainter::end: Painter is not active, aborted Recognised Fileformat: ppm [GrahicsCacheItem::convertToDisplayFormat] Attempting to convert image file: D:/msys/home/yns/src/lyx-devel/lib/images/banner.ppm with displayed filename: D:\msys\home\yns\src\lyx-d
Re: lyx-1.4.0 and Qt-4.1
Lars Gullik Bjønnes a écrit : Abdel <[EMAIL PROTECTED]> writes: | > Then I'd suggest that you create a bug "Implement qt4 frontend", and | > attach the diff to it. | | Why not create a qt4 directory (same as xform or gtk) along qt2 in the | cvs repository once 1.5cvs is opened? But I can certainly do what you | suggest once I have something that can load a document without | crashing. The qt2 dir is misnamed as it is now, it is supposed to be called "qt". After 1.4.0 is release we will switch to subversion for the source repository, that will make dir renaming a bit easier. When the actuall porting to qt4 begin is suspect that a lot of the files in the (now) qt2 dir can stay as is. So the there might be some separate implementations for qt4 perhaps a subdir, perhaps just single files. We will see when that work is begun in ernest. (But it will be located under "frontends/qt/" Hum, I've read that qt3 was quite source compatible with qt2. This is not the case for qt4. The qt3to4 porting tool renames a lot of classes and variables to their Q3XXX equivalents in the Q3Support package. I have begun already to port to the real Qt4 classes that are IMO cleaner and more intuitive. I have not touched the ui files for now but I guess that it would be better to convert them to Qt4 format as well. We can re-discuss this anyway when the time comes. Abdel. > -- >Lgb
Re: lyx-1.4.0 and Qt-4.1
Georg Baum a écrit : On Thursday 29 December 2005 20:51, Abdel wrote: Hello, Judging from the absence of answer, I suppose this matter is not interesting to you :-( It's OK, I understand that you are all very busy with the release of 1.4.0. I have worked some more on the port so if there is any interest in the future, just let me know. FYI, the changes from Qt3 to Qt4 are quite big and I think it's worth keeping both version in parallel. I will try to keep my port in sync with the qt2 frontend. I suggest a little different approach: Don't create a copy of the qt2 frontend, but modify the qt2 frontend in place. You'll need a second tree if you want a clean qt3 compile, but the advantage is that you can simply do a cvs diff in the qt2 dir to get the differences to the current sources. I'll think about that, thanks for the suggestion. Then I'd suggest that you create a bug "Implement qt4 frontend", and attach the diff to it. Why not create a qt4 directory (same as xform or gtk) along qt2 in the cvs repository once 1.5cvs is opened? But I can certainly do what you suggest once I have something that can load a document without crashing. Then others can take your work up. I am sure that it will be appreciated when the time comes (probably for 1.5 or even later) Good night, Abdel. Georg
Re: lyx-1.4.0 and Qt-4.1
Lars Gullik Bjønnes a écrit : Abdel <[EMAIL PROTECTED]> writes: | Hello, | | Judging from the absence of answer, I suppose this matter is not | interesting to you :-( Oh it is, but as you rightly suspect: not right now. | It's OK, I understand that you are all very busy with the release of | 1.4.0. I have worked some more on the port so if there is any interest | in the future, just let me know. FYI, the changes from Qt3 to Qt4 are | quite big and I think it's worth keeping both version in parallel. I | will try to keep my port in sync with the qt2 frontend. | Right now, I am having big headache on QWorkarea and QContentpane | widget dimensions... At this point I am wasting time so I think I will | just give up. Please don't forget completely about this. This will be more important in the next development round. Thanks a lot for looking at this. Word taken, thank you. I might bother you after 1.4 is released to help me understand the inner working of lyx. Bye, Abdel.
Re: lyx-1.4.0 and Qt-4.1
Hello, Judging from the absence of answer, I suppose this matter is not interesting to you :-( It's OK, I understand that you are all very busy with the release of 1.4.0. I have worked some more on the port so if there is any interest in the future, just let me know. FYI, the changes from Qt3 to Qt4 are quite big and I think it's worth keeping both version in parallel. I will try to keep my port in sync with the qt2 frontend. Right now, I am having big headache on QWorkarea and QContentpane widget dimensions... At this point I am wasting time so I think I will just give up. Regards, Abdel. Abdel a écrit : Dear developpers, I could not sleep last night so I tried as an exercise to see if lyx could be ported easily to the fresh Qt-4.1. As you might guess it was more difficult than I originally thought. But after much work it compiles and loads! There is a problem QImage which doesn't support any image format. I suspect the Painter is not correctly started. Because of that, the program could not load any document (more on that later). But the menubar, the "Browse file" dialog and the about box are functional. I don't know if this is interesting to you and if you planned already to port to Qt4.1 sometimes in the future. If so, I am willing to help completing this port if someone more knowledgeable than me take lead. If not, it was fun anyway and I learned a bit about Qt4 in the process. IMO it is much cleaner that Qt3 (Disclaimer: I knew close to nothing on these two before yesterday). I could send my qt4 directory to anyone interested in any case. What I did: 1) copy "src/frontends/qt2" to "src/frontends/qt4" 2) launch qt3to4 porting tool to all .C and .h 3) replace uic with uic3 in all Makefiles 4) remove "-tr qt_" from UICFLAGS in all Makefiles 5) compile and fix... I know nothing about the auto-tools so I just modified the Makefile, sorry about that. The big remaining problem is with QPicture. In order to let lyx start, I had to comment line "src/graphics/GraphicsCacheItem.C":340 // There must be a format to load from. BOOST_ASSERT(!formats.empty()); I have attached my modified "src/frontends/qt4/Qimage.C". Please find below, the output of lyx -dbg graphics. Thanks, Abdel. D:\msys\home\yns\src\lyx-devel\src>.\lyx-qt -dbg graphics Setting debug level to graphics Debugging `graphics' (Graphics conversion and loading) LoaderQueue: priority set to 10 images at a time, 100 milliseconds between calls Recognised Fileformat: agr filetools(getFormatFromContents) Couldn't find a known format! Ignoring obsolete use_tempdir flag. filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) File type not recognised before EOF! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! filetools(getFormatFromContents) Couldn't find a known format! Language code:C Setting new locale for Qt:C LoaderQueue: waking up QPainter::begin(), paintdevice returned engine == 0, type: 3 QPainter::end: Painter is not active, aborted QPainter::begin(), paintdevice returned engine == 0, type: 2 Painter started successfully. QColor::setNamedColor: unknown color name 'grey40' QPainter::end: Painter is not active, aborted QPainter::begin(), paintdevice returned engine == 0, type: 3 QPainter::end: Painter is not active, aborted lyx: Disabling LyX socket. LoaderQueue: 1 items in the queue QPainter::begin(), paintdevice returned engine == 0, type: 2 Painter started successfully. QPainter::end: Painter is not active, aborted Recognised Fileformat: ppm [GrahicsCacheItem::convertToDisplayFormat] Attempting to convert image file: D:/msys/home/yns/src/lyx-devel/lib/images/banner.ppm with displayed filename: D:\msys\home\yns\src\lyx-devel\lib\images\banner.ppm Recognised Fileformat: ppm The file contains ppm format data. The image loader can load the following directly: Qt4 Problem: No Format available! Of these, LyX recognises the following formats: Converting it to format. Converter c-tor: from_file: D:/msys/home/yns/src/lyx-devel/lib/images/banner.ppm to_file
Re: lyx 1.4.0 for windows: compilation progress report and impression
Jose' Matos a écrit : On Friday 23 December 2005 15:52, Abdel wrote: You should select a DocBook textclass for your document. Hum, I am not willing to change my document class, I want to keep using latex. There is a latex2xml thing but it the resulting Xml is not as structured as the lyx document. IMO, the exported XML should reflect the structure of the document as lyx knows it. Then, this XML could be used for a number of thing: Database import, XSLT transformation (doxygen, openoffice, xhtml, etc). You know what I mean? But then you need to some kind of more intelligent convertion, read xslt. It is not true that all document types support the same or compatible structures. There are things that are allowed in latex that are not allowed in docbook and vice-versa, you replace docbook or latex above with xhtml, html, tei-lite or any other you choose. I know that. Let me clarify something: The Lyx/latex/pdf is perfect for document processing. I don't need anything else. In the XML file, I don't care much about the formatting, I am only interested in the contents. In other word, it's OK if I loose the latex decoration (header, etc) I would just like to be able to extract a part of the document (with xslt) and link it with a doxygen tag for example. Inside a section tag for example, Latex formatting would be very fine especially for math. I am not sure what I say is clear...
Re: lyx 1.4.0 for windows: compilation progress report and impression
Michael Gerz a écrit : Abdel wrote: As I have polluted your list with my help request I thought that you might be interested in the result. Thanks to Angus and Michael, I managed to compile lyx-1.4.0 with Mingw without Aspell and "po" support. Some note about the compilation: 1) I first try to compile with the Qt dll but the memory was exhausted. 2) linking libqt2 took > 400 MB of RAM 3) linking lyx-qt.exe took one hour, 650 MB of RAM and sometimes more than 1 GB of Virtual Memory 4) the final lyx.exe is 189913 KB, the stripped one is 7307 KB. 5) On Mingw/Msys, ln -s is equivalent to a copy. May I suggest that you use "mv" instead? I have a question about the linking stage. Do you think that a compilation without debug (maybe using '-Os' instead of '-g -O') would reduce the processing time? If not, then I think I will stay selfishly with this exe. If yes, I could try to help the windows installer guys. Well, once again: Read my recipe! I did, really! I followed it scrupulously except for the aspell and po things. It tells you how to get a LyX binary in reasonable time - even with some debug information, Hum I beg to differ here, the linking stage is very heavy with 'enable-debug', I will try with with Aspell and with po support (at least it was possible last week). I think my problems come from my cvs client. I suspect it converts text files to dos format. Install all the required tools, and two or three hours later (depending on your machine), you will be a happy man! Definitely more with my machine, really. Michael PS: I am not annoyed. I am just wondering why you want to waste your time if someone else (me) has already wasted enough time in the past. No PB. Thanks a lot for your help. Abdel.
Re: lyx 1.4.0 for windows: compilation progress report and impression
Jean-Marc Lasgouttes a écrit : "Abdel" == Abdel <[EMAIL PROTECTED]> writes: Abdel> I have a question about the linking stage. Do you think that a Abdel> compilation without debug (maybe using '-Os' instead of '-g Abdel> -O') would reduce the processing time? If not, then I think I Abdel> will stay selfishly with this exe. If yes, I could try to help Abdel> the windows installer guys. If linux is a good indication, configuring with --disable-debug will speed up linking a lot. I'll try that, thanks. To speed up LyX itself, use --disable-stdlib-debug (will be disabled on release). It was already disabled. Abdel> So far it looks very good. The GUI is much nicer (nice picture Abdel> :-)), My living room :) Nice. Paris? Abdel> 1) Lyx flicker when you move the cursor with a left click or Abdel> when you select something with the mouse. This doesn't happen Abdel> with lyx-1.3.7pre5 I guess the windows situation has some specificities, but the fact is that 1.4.0cvs redraws much more than 1.3, and this causes problems. The flickers are probably due to bad double-buffering in qt/win, though. Selecting is a bit slow. We have almost a patch in hand to fix the slowness when typing. Except for the flickering, typing is fine. It is very quick for me, no slowness at all, even for big paragraph. Abdel> 3) Using a laptop, I always work with figure maximized. But Abdel> when I minimize and then click on the task bar, lyx would Abdel> maximize and immediately resize itself to what I think is the Abdel> default window size. I guess this is a qt/win bug. We do not do that. Abdel> 6) I am not much a toolbar user but I think the icons for Abdel> "insert figure float" and "insert graphics" should be Abdel> different. Same for the table float. How would you improve them? Maybe a small 'fig:' in italic below a reduced graphic icon? And a 'tab:' below the a reduced tab icon? Abdel> 7) I have read somewhere in the list that lyx-1.4.0 would be Abdel> able to export to XML. I cannot find the option. You should select a DocBook textclass for your document. Hum, I am not willing to change my document class, I want to keep using latex. There is a latex2xml thing but it the resulting Xml is not as structured as the lyx document. IMO, the exported XML should reflect the structure of the document as lyx knows it. Then, this XML could be used for a number of thing: Database import, XSLT transformation (doxygen, openoffice, xhtml, etc). You know what I mean? Thank for the comments. You are very welcome, Abdel. JMarc
Re: lyx 1.4.0 for windows: compilation progress report and impression
Jean-Marc Lasgouttes a écrit : "Abdel" == Abdel <[EMAIL PROTECTED]> writes: Abdel> Oups, I have just discovered the math and table bars right Abdel> clicking on the top toolbar. All I can say is WAHOU !!! :-) Abdel> Sorry for that. Actually, it is possible to edit ui/default.ui to have these toolbars appear automatically when needed. Very good! This should be the default IMHO. Abdel JMarc
Re: lyx 1.4.0 for windows: compilation progress report and impression
Oups, I have just discovered the math and table bars right clicking on the top toolbar. All I can say is WAHOU !!! :-) Sorry for that. While I am on it, a 8th point on my list: 8) When you click on a reference, the slider of the ref window will go to the top and then come back to its position. Abdel. Abdel a écrit : Hello, As I have polluted your list with my help request I thought that you might be interested in the result. Thanks to Angus and Michael, I managed to compile lyx-1.4.0 with Mingw without Aspell and "po" support. Some note about the compilation: 1) I first try to compile with the Qt dll but the memory was exhausted. 2) linking libqt2 took > 400 MB of RAM 3) linking lyx-qt.exe took one hour, 650 MB of RAM and sometimes more than 1 GB of Virtual Memory 4) the final lyx.exe is 189913 KB, the stripped one is 7307 KB. 5) On Mingw/Msys, ln -s is equivalent to a copy. May I suggest that you use "mv" instead? I have a question about the linking stage. Do you think that a compilation without debug (maybe using '-Os' instead of '-g -O') would reduce the processing time? If not, then I think I will stay selfishly with this exe. If yes, I could try to help the windows installer guys. So far it looks very good. The GUI is much nicer (nice picture :-)), the menu structure is better once you get used to it (a transition tutorial for lyx-1.3.x user would be nice). The program loads quickly on my machine (<1 second) and the UserGuide.lyx loaded in less than 2 seconds the first time. I have a compaq laptop (1.2 Ghz, 769 MB). On the bad side I have a couple of comment. I understand that this is not even a beta so please stop reading here if this is not useful to you now. 1) Lyx flicker when you move the cursor with a left click or when you select something with the mouse. This doesn't happen with lyx-1.3.7pre5 2) The figures stayed in "Converting to loadable format" so I Tools->Reconfigure. But the reconfigure didn't happen immediately; it happened when I started Lyx again. Subsequent reconfigure happens immediately. I guess this will be handled by the lyx installer. 3) Using a laptop, I always work with figure maximized. But when I minimize and then click on the task bar, lyx would maximize and immediately resize itself to what I think is the default window size. 4) I was very disappointed that there were no tool bar for math and tables. The math and table panel are not very useful for full screen user. I guess a new toolbar would be much work but what about docking the panels? I mean splitting the screen with the panel on the bottom and the normal lyx buffer on the top. 5) The table panel lost its ability to add or remove lines or column. 6) I am not much a toolbar user but I think the icons for "insert figure float" and "insert graphics" should be different. Same for the table float. 7) I have read somewhere in the list that lyx-1.4.0 would be able to export to XML. I cannot find the option. That's all for now ;-). Thanks for this wonderful software. I am at your disposition if you want me to do some test. Merry Christmas to you all, Abdel.
lyx 1.4.0 for windows: compilation progress report and impression
Hello, As I have polluted your list with my help request I thought that you might be interested in the result. Thanks to Angus and Michael, I managed to compile lyx-1.4.0 with Mingw without Aspell and "po" support. Some note about the compilation: 1) I first try to compile with the Qt dll but the memory was exhausted. 2) linking libqt2 took > 400 MB of RAM 3) linking lyx-qt.exe took one hour, 650 MB of RAM and sometimes more than 1 GB of Virtual Memory 4) the final lyx.exe is 189913 KB, the stripped one is 7307 KB. 5) On Mingw/Msys, ln -s is equivalent to a copy. May I suggest that you use "mv" instead? I have a question about the linking stage. Do you think that a compilation without debug (maybe using '-Os' instead of '-g -O') would reduce the processing time? If not, then I think I will stay selfishly with this exe. If yes, I could try to help the windows installer guys. So far it looks very good. The GUI is much nicer (nice picture :-)), the menu structure is better once you get used to it (a transition tutorial for lyx-1.3.x user would be nice). The program loads quickly on my machine (<1 second) and the UserGuide.lyx loaded in less than 2 seconds the first time. I have a compaq laptop (1.2 Ghz, 769 MB). On the bad side I have a couple of comment. I understand that this is not even a beta so please stop reading here if this is not useful to you now. 1) Lyx flicker when you move the cursor with a left click or when you select something with the mouse. This doesn't happen with lyx-1.3.7pre5 2) The figures stayed in "Converting to loadable format" so I Tools->Reconfigure. But the reconfigure didn't happen immediately; it happened when I started Lyx again. Subsequent reconfigure happens immediately. I guess this will be handled by the lyx installer. 3) Using a laptop, I always work with figure maximized. But when I minimize and then click on the task bar, lyx would maximize and immediately resize itself to what I think is the default window size. 4) I was very disappointed that there were no tool bar for math and tables. The math and table panel are not very useful for full screen user. I guess a new toolbar would be much work but what about docking the panels? I mean splitting the screen with the panel on the bottom and the normal lyx buffer on the top. 5) The table panel lost its ability to add or remove lines or column. 6) I am not much a toolbar user but I think the icons for "insert figure float" and "insert graphics" should be different. Same for the table float. 7) I have read somewhere in the list that lyx-1.4.0 would be able to export to XML. I cannot find the option. That's all for now ;-). Thanks for this wonderful software. I am at your disposition if you want me to do some test. Merry Christmas to you all, Abdel.
Re: lyx configure fails (was Re: qt3-win: cannot compile with mingw)
Abdel a écrit : Paul A. Rubin a écrit : Abdel wrote: My sed version is the one with MSYS-1.0.11 (GNU sed 3.02). Please note that I am not using MSYS DTK, I have hand installed the needed software (autoconf, automake, libtool, etc). Sorry, late arrival to this thread, so I apologize if I'm repeating something said elsewhere. The version of sed you're using is known to choke on DOS scripts (due to the CR/LF line terminators IIRC). Upgrading to sed 4.anything should eliminate at least that problem. This was documented (repeatedly and painfully) in the user list. The only version of sed-4 for windows is from GnuWin32 not Mingw nor MSYS. So I am a bit scared at the consequence of replacing it because the build process is so fragile. And I was told to stick with MSYS and Mingw... And this advice was right. One should never mix Gnuwin32 stuff with MSYS stuff because Gnuwin32 assumes you are running within CMD and MSYS assumes you are running within sh. So Gnuwin32 sed is fine for lyx installation but definitely not for compilation. Anyway, lyx is now in the link stage (ld taking 400 megs, crossing my fingers) but it's a partial build because I was not able to build the po subdir. I'll try to replace sed and see what's happening. Thanks for the info, Abdel. Paul
Re: lyx configure fails (was Re: qt3-win: cannot compile with mingw)
Good morning Angus, Angus Leeming a écrit : Abdel wrote: For my defense I'd say that I have invested a lot of time already on that. I think I am close but it's really not fun. Courage! Why not skip the po directory for now and try $ cd src && make Yes that's what I did yesterday. But lyx-qt.exe failed to link at the end... Memory exhausted! 500 Megs of ram and 700 Megs of VM were used but that wasn't enough :-( . I have compiled the static version of qt this night. Let's see if it is better. Abdel.
Re: lyx configure fails (was Re: qt3-win: cannot compile with mingw)
Paul A. Rubin a écrit : Abdel wrote: My sed version is the one with MSYS-1.0.11 (GNU sed 3.02). Please note that I am not using MSYS DTK, I have hand installed the needed software (autoconf, automake, libtool, etc). Sorry, late arrival to this thread, so I apologize if I'm repeating something said elsewhere. The version of sed you're using is known to choke on DOS scripts (due to the CR/LF line terminators IIRC). Upgrading to sed 4.anything should eliminate at least that problem. This was documented (repeatedly and painfully) in the user list. The only version of sed-4 for windows is from GnuWin32 not Mingw nor MSYS. So I am a bit scared at the consequence of replacing it because the build process is so fragile. And I was told to stick with MSYS and Mingw... Anyway, lyx is now in the link stage (ld taking 400 megs, crossing my fingers) but it's a partial build because I was not able to build the po subdir. I'll try to replace sed and see what's happening. Thanks for the info, Abdel. Paul
Re: lyx configure fails (was Re: qt3-win: cannot compile with mingw)
Angus Leeming a écrit :
Abdel wrote:
Angus Leeming a écrit :
Abdel wrote:
Hello Angus,
sed: -e expression #2, char 2: Unterminated `s' command
Try the attached dos2unix.sed script as
$ sed -f dos2unix.sed configure.ac > tmp
it does the same:
sed: file dos2unix.sed line 1: Unterminated `s' command
Ok. We have several options.
Option 2 below was fine bu I also had to correct configure. I had to
change configure as recommended by Mickael in his recipe:
5.7 Edit file ./configure: Change line 12520 (move conftest.$ac_ext in
front of FLAGS)
ac_link='$CXX -o conftest$ac_exeext conftest.$ac_ext $CXXFLAGS $CPPFLAGS
$LDFLAGS $LIBS >&5'
But in my case it was lines 12001 and 15515.
>
> 1. If you have the MSYS-DTK installed then you'll have dos2unix.exe:
>
> $ dos2unix.exe configure.ac
>
> However, that changes more than just line endings; it may or may not
break
> stuff...
>
> 2. Recreate my sed script yourself. From an MSYS terminal window:
>
> $ sed 's/^M$//' configure.ac > tmp
> $ mv tmp configure.ac
>
> where ^M is generated as the key sequence Cntl-V Cntl-M.
>
> 3. Try the scripts (attached) again. This time they're compressed so the
> transport process doesn't mess them up.
>
> $ gunzip dos2unix.sed.gz
> $ sed -f dos2unix.sed configure.ac > tmp
>
> 4. Use the 1.4 configure script at.
>http://www.lyx.org/~leeming/configure.gz
> Don't run autogen.sh or it'll be overwritten.
Now the fun begins...
| sed 's/\\//g' > layouts_l10n.pot
sed: -e expression #2, char 8: Unterminated `s' command
make[3]: *** [layouts_l10n.pot] Error 1
make[3]: Leaving directory `D:/msys/home/yns/src/lyx-devel/po'
make[2]: *** [LyX.pot-update] Error 2
make[2]: Leaving directory `D:/msys/home/yns/src/lyx-devel/po'
D:\mingw\bin\make.exe[1]: *** [LyX.pot] Error 2
D:\mingw\bin\make.exe[1]: Leaving directory
`D:/msys/home/yns/src/lyx-devel/po'
D:\mingw\bin\make.exe: *** [all-recursive] Error 1
This looks like the same kind of error. I looked at the po/Makefile but
I don't know sed at all. Line 735 is this:
${top_srcdir}/lib/layouts/*.layout ${top_srcdir}/lib/layouts/*.inc \
| sed 's/\\//g' > $@
Is that a correct sed expression? I tried a make clean && make and then,
there is a different error:
$ cd po
[EMAIL PROTECTED] ~/src/lyx-devel/po
$ make clean
FIND: Parameter format not correct
rm -f *.insert-header
rm -f remove-potcdate.sed
rm -f stamp-poT
rm -f core core.* LyX.po LyX.1po LyX.2po *.new.po
rm -fr *.o
[EMAIL PROTECTED] ~/src/lyx-devel/po
$ make
FIND: Parameter format not correct
make LyX.pot-update
FIND: Parameter format not correct
make[1]: Entering directory `D:/msys/home/yns/src/lyx-devel/po'
sed -e '/^#/d' remove-potcdate.sin > t-remove-potcdate.sed
mv t-remove-potcdate.sed remove-potcdate.sed
make l10n_pots
FIND: Parameter format not correct
make[2]: Entering directory `D:/msys/home/yns/src/lyx-devel/po'
cat xforms_l10n.pot qt_l10n.pot layouts_l10n.pot languages_l10n.pot
ui_l10n.pot | \
msguniq -o LyX.po && rm -f xforms_l10n.pot qt_l10n.pot layouts_l10n.pot
languag es_l10n.pot ui_l10n.pot
:5: end-of-line within string
:6: end-of-line within string
:7: end-of-line within string
:8: end-of-line within string
D:\mingw\bin\msguniq.exe: : warning: Charset
"ISO-8859-1Content-Transfer-
Encoding:" is not a portable encoding name.
Message conversion to
user's charset might not work.
D:\mingw\bin\msguniq.exe: found 4 fatal errors
make[2]: *** [l10n_pots] Error 1
make[2]: Leaving directory `D:/msys/home/yns/src/lyx-devel/po'
make[1]: *** [LyX.pot-update] Error 2
make[1]: Leaving directory `D:/msys/home/yns/src/lyx-devel/po'
D:\mingw\bin\make.exe: *** [LyX.pot] Error 2
Sorry for all this. I'll maybe wait for a formal (beta) delivery of lyx
1.4
And who is going to compile that?
For my defense I'd say that I have invested a lot of time already on
that. I think I am close but it's really not fun.
Thanks,
Abdel.
Re: lyx configure fails (was Re: qt3-win: cannot compile with mingw)
Michael Gerz a écrit : Abdel wrote: I completely agree and I first try the static version but all the demo and examples crashed, including the Qtdesigner. I'll try to find sometime to compile in debug mode and see what's happening. Ah. I forgot to mention: Ignore this! ok... Next time I'll compile static. You should install MSYS-1.0.11 and msysDTK-1.0.1 before you install all other msys packages. I guess there is some overlapping. And rename the directory of the former MinGW installation. Having two different versions of MinGW on the same machine looks like another promising source of problems... IMHO, this all MSYS-AutoXXX-Perl is a mess! You should really think about changing your building process with something that is really portable: scons is good candidate (http://www.scons.org). It's written in python (you will get rid of perl :-)). Abdel. Michael
Re: lyx configure fails (was Re: qt3-win: cannot compile with mingw)
Michael Gerz a écrit : Abdel wrote: With the shared version all demos and examples compile and execute OK. Ouf... But the linkage only took an hour and sometimes more than 400 Megs! I understand why Michael insist on compiling static Qt. Well, I told you! (What is the shared version good for, as long as LyX is the only app using qtwin? (Why do people make their lives more difficult than necessary? (You are wasting your time))) I completely agree and I first try the static version but all the demo and examples crashed, including the Qtdesigner. I'll try to find sometime to compile in debug mode and see what's happening. I had lots of trouble trying to compile aspell so I gave up. Why? It should be pretty simple. Did you follow my recipe? Did you download the right version (0.60.4)? Yes. I modified './common/file_util.cpp' as you recommended. Plus I had to put '#undef printf' at the end of './common/gettext.h'. Then the compilation stopped with the following: Making all in . D:\mingw\bin\make.exe[1]: Entering directory `D:/msys/home/yns/src/aspell-0.60.4' /bin/perl gen/mk-static-filter.pl modules/filter/url-filter.info modules/filter/email-filter.info modules/filter/tex-filter.info modules/filter/sgml-filter.info modules/filter/html-filter.info modules/filter/context-filter.info modules/filter/nroff-filter.info modules/filter/texinfo-filter.info process_begin: CreateProcess((null), /bin/perl gen/mk-static-filter.pl modules/filter/url-filter.info modules/filter/email-filter.info modules/filter/tex-filter.info modules/filter/sgml-filter.info modules/filter/html-filter.info modules/filter/context-filter.info modules/filter/nroff-filter.info modules/filter/texinfo-filter.info, ...) failed. make (e=3): The system cannot find the path specified. D:\mingw\bin\make.exe[1]: *** [gen/static_filters.src.cpp] Error 3 D:\mingw\bin\make.exe[1]: Leaving directory `D:/msys/home/yns/src/aspell-0.60.4' D:\mingw\bin\make.exe: *** [all-recursive] Error 1 So I gave up. Have you installed all the latest MinGW packages? I had many problems in the past with the MSYS DTK (1.0.11) so I had installed the latest mingw package manually in the mingw directory (including perl, automake and autoconf). I guess this is source of all my problems. I will try a parallel install of MSYS+MINGW and see what happens. Abdel. Michael -- 1 MinGW & MSYS 1.1 Download the following packages from http://www.mingw.org/download.shtml binutils-2.16.91-...tar.gz gcc-core-3.4.4-...tar.gz gcc-g++-3.4.4-...tar.gz mingw32-make-3.80.0-3.tar.gz mingw-runtime-3.9.tar.gz mingw-utils-0.3.tar.gz MSYS-1.0.11-...exe msys-autoconf-2.59.tar.bz2 msys-automake-1.8.2.tar.bz2 msysDTK-1.0.1.exe msys-libtool-1.5.tar.bz2 w32api-3.5.tar.gz 1.2 Install in C:\MinGW binutils, gcc-core, gcc-g++, mingw32-make, mingw-runtime, mingw-utils, w32api 1.3 Install ... in C:\msys MSYS, msys-autoconf, msys-automake, msysDTK, msys-libtool -- 2. Gettext & Libiconv 2.1 Download the following packages from http://www.gnu.org/software/gettext/gettext.html gettext-tools-0.13.1.bin.woe32.zip gettext-runtime-0.13.1.bin.woe32.zip libiconv-1.9.1.bin.woe32.zip 2.2 Extract the three packages in C:\MinGW -- 3 qtwin 3.1 Get the latest CVS version Open the MSYS window/bash. In your home directory, enter cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/qtwin login (no password) cvs -z3 -d :pserver:[EMAIL PROTECTED]:/cvsroot/qtwin co \ -r QT_WIN32_3_3_BRANCH qt-3 3.2 Compile a static (!) QT library (dynamic linking with MinGW causes nightmares!) Open Window command line (run cmd.exe) and enter cd set QMAKESPEC=win32-g++ setenv.bat configure.bat -release -static -- 4. Aspell 4.1 Download the following packages from http://aspell.net/ aspell-0.60.4.tar.gz aspell6-en-6.0-0.tar.bz2 aspell6-de-20030222-1.tar.bz2 4.2 Extract all files in your MSYS home directory 4.3 Enter cd aspell-0.60.4 ./configure --enable-static --disable-shared --prefix=c:/Programme/Aspell-0.60.4 4.4 Edit file ./common/file_util.cpp: Add before line 29 #include "asc_ctype.hpp" 4.5 Enter make make install 4.6 Compile the German dictionary cd ../aspell6-de-20030222-1 export PATH=/c/Programme/Aspell-0.60.4/bin:$PATH ./configure make make install 4.7 Repeat 4.6 for the English dictionary --
Re: lyx configure fails (was Re: qt3-win: cannot compile with mingw)
Angus Leeming a écrit : Abdel wrote: Hello Angus, With the shared version all demos and examples compile and execute OK. Ouf... But the linkage only took an hour and sometimes more than 400 Megs! I understand why Michael insist on compiling static Qt. I had lots of trouble trying to compile aspell so I gave up. You can always go back to this later. Now onto lyx... The configure fails with: checking types of arguments for select... int,int *,struct timeval * Your configure.ac has DOS-style line endings. I believe that there's some magic in the build_lyxwin.sh script to clean that up... You're right but it failed apparently: sed: -e expression #2, char 2: Unterminated `s' command Try the attached dos2unix.sed script as $ sed -f dos2unix.sed configure.ac > tmp it does the same: sed: file dos2unix.sed line 1: Unterminated `s' command I guess my version of sed is bad but I cannot find any other on mingw site. Sorry for all this. I'll maybe wait for a formal (beta) delivery of lyx 1.4 Thanks a lot anyway, Abdel. $ mv tmp configure.ac s/ $// s/$/ /
lyx configure fails (was Re: qt3-win: cannot compile with mingw)
Abdel a écrit : Angus Leeming a écrit : Abdel wrote: The path seems OK here. First entries are: D:\install\qt\qt-3\bin;D:\mingw\bin;D:\msys\bin; Maybe is it a problem of mingw32-make? I am using version 3.80. I am lost :-( I see that you eventually managed to get mails through to the Qt/Win free mailing list and that your problem is now resolved. Hum yes but all the examples crash. VC6 says: Unhandled exception in demo.exe: 0xC005: Access Violation. I am affraid that lyx will do the same. I guess this is because I compiled qt with -static (on the advice of Michael Gerz), I'll try the shared version. Hello Angus, With the shared version all demos and examples compile and execute OK. Ouf... But the linkage only took an hour and sometimes more than 400 Megs! I understand why Michael insist on compiling static Qt. I had lots of trouble trying to compile aspell so I gave up. Now onto lyx... I am using your build_lyxwin.sh adapted to my config. I also modified the configure call to: CONFIGURE="../configure --prefix='/d/program/lyx-140' --without-x --without-pspell --without-aspell --with-included-gettext --with-frontend=qt QTDIR='$QT_DIR'" The configure fails with: checking types of arguments for select... int,int *,struct timeval * ../configure: line 34812: syntax error near unexpected token `"s/^\\([' ../configure: line 34812: ` "s/^\\([_$as_cr_alnum]*_cv_[_$as_cr_alnum]*\\)=\\(.*\\)/\\1=\\2/p"' Failed to configure LyX My sed version is the one with MSYS-1.0.11 (GNU sed 3.02). Please note that I am not using MSYS DTK, I have hand installed the needed software (autoconf, automake, libtool, etc). Please find below the output of autogen.sh and make distclean: [EMAIL PROTECTED] ~/src/lyx-devel $ ./autogen.sh Using automake (GNU automake) 1.9.6 Using autoconf (GNU Autoconf) 2.59 Locating GNU m4... /bin/m4 Generate acinclude.m4... done. Building macros... . done. Building config header template... . done. Building Makefile templates... . done. Building configure... . done. Building lib/configure ... done. run "./configure ; make" [EMAIL PROTECTED] ~/src/lyx-devel $ ./configure --prefix='/d/program/lyx-140' --without-x --without-pspell --without-aspell --with-included-gettext --with-fro ntend=qt QTDIR='/home/yns/src/qt-3' configuring LyX version 1.4.0cvs WARNING: This is a development version. Expect bugs. checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking target system type... i686-pc-mingw32 checking what packaging should be used... windows checking for install target... LyX checking whether to enable maintainer-specific portions of Makefiles... yes checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... ./configure: eval: line 1: unexpected EOF while looking for matching `"' ./configure: eval: line 2: syntax error: unexpected end of file no checking whether make sets $(MAKE)... (cached) no checking for a BSD-compatible install... /bin/install -c checking for gawk... (cached) gawk checking for kpsewhich... kpsewhich checking for gm4... no checking for gnum4... no checking for m4... m4 checking for a Python interpreter with version >= 1.5.2... python checking for python... /d/program/Python24/python checking for python version... 2.4 checking for python platform... win32 checking for python script directory... d:\program\Python24\Lib\site-packages checking for python extension module directory... d:\program\Python24\Lib\site-packages checking for gcc... gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for library containing strerror... none required checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for AIX... no checking what frontend should be used for the GUI... qt checking for a good enough C++ compiler... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking whether the C++ compiler understands explicit... yes checking whether C library functions are already in the global namespace... no checking for conforming std::count... yes checking how to run the C++ preprocessor... g++ -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... y
Re: qt3-win: cannot compile with mingw
Angus Leeming a écrit : Abdel wrote: The path seems OK here. First entries are: D:\install\qt\qt-3\bin;D:\mingw\bin;D:\msys\bin; Maybe is it a problem of mingw32-make? I am using version 3.80. I am lost :-( I see that you eventually managed to get mails through to the Qt/Win free mailing list and that your problem is now resolved. Hum yes but all the examples crash. VC6 says: Unhandled exception in demo.exe: 0xC005: Access Violation. I am affraid that lyx will do the same. I guess this is because I compiled qt with -static (on the advice of Michael Gerz), I'll try the shared version. To build LyX itself: have a look at the README and .sh scripts in development/Win32/packaging OK. I have try to compile with win32-msvc (I have VC++ 6.0) also. It does go farther but fail at some point during the compilation. VC++6 is not supported by lyx anyway (AFAIK). That's right. LyX is written in modern C++ and VC6 doesn't understand it. Well, in my experience, combined with STLport and a few pragma, it can accept pretty advanced C++. AFAIK, only some advanced template use cases are not supported. Thanks, Abdel.
Re: qt3-win: cannot compile with mingw
Angus Leeming a écrit : Abdel wrote: The path seems OK here. First entries are: D:\install\qt\qt-3\bin;D:\mingw\bin;D:\msys\bin; Maybe is it a problem of mingw32-make? I am using version 3.80. I am lost :-( I see that you eventually managed to get mails through to the Qt/Win free mailing list and that your problem is now resolved. Hum yes but all the examples crash. VC6 says: Unhandled exception in demo.exe: 0xC005: Access Violation. I am affraid that lyx will do the same. I guess this is because I compiled qt with -static (on the advice of Michael Gerz), I'll try the shared version. To build LyX itself: have a look at the README and .sh scripts in development/Win32/packaging OK. I have try to compile with win32-msvc (I have VC++ 6.0) also. It does go farther but fail at some point during the compilation. VC++6 is not supported by lyx anyway (AFAIK). That's right. LyX is written in modern C++ and VC6 doesn't understand it. Well, in my experience, combined with STLport and a few pragma, it can accept pretty advanced C++. AFAIC, only some advanced template use cases are not supported. Thanks, Abdel.
Re: qt3-win: cannot compile with mingw
Angus Leeming a écrit : Abdel wrote: Well I think I have used yours already: set QTDIR=D:\install\qt\qt-3 set MINGW=D:\mingw set MSYS=D:\msys set PATH=%QTDIR%\bin;%MINGW%\bin;%MSYS%\bin;%PATH% set QMAKESPEC=win32-g++ cd qt-3 configure.bat -fast -verbose and echo statements indicate that these environment variables are all as you'd expect? echo %QTDIR% echo %MINGW% echo %MSYS% echo %PATH% echo %QMAKESPEC% Yes. I ask because I've had problems using set PATH=...;%PATH% in the past. The path seems OK here. First entries are: D:\install\qt\qt-3\bin;D:\mingw\bin;D:\msys\bin; Maybe is it a problem of mingw32-make? I am using version 3.80. I am lost :-( I have try to compile with win32-msvc (I have VC++ 6.0) also. It does go farther but fail at some point during the compilation. VC++6 is not supported by lyx anyway (AFAIK). Thanks, Abdel.
Re: qt3-win: cannot compile with mingw
Angus Leeming a écrit : YOUNES Abdelrazak (M3SYSTEM) wrote: Sorry for disturbing this list but the kde-cygwin mailing list is apparently dead :-( It's not. It's fine. Last mails to the list are dated today (20 Dec). Admittedly, it's a very low volume mailing list... Personally, I read it as a newsgroup gmane.comp.kde.devel.cygwin You could also try the web interface http://news.gmane.org/gmane.comp.kde... Actually, this is exactly what I did. I tried to post to gmane.comp.kde.devel.cygwin with thunderbird. (The same I do with lyx-devel) I received a failure notice from [EMAIL PROTECTED]: <[EMAIL PROTECTED]>: Sorry, no mailbox here by that name. (#5.1.1) The first one was about an hypothetical cygwin make which I never installed. I have double-checked but there is no cygwin reference in the path nor in the registry. Finally I just hacked the configure.bat to just use mingw32-make. You need to specify some environment variables to tell Qt's configure script what flavour of compilation environment you're using. This was all detailed quite nicely on a qt/win free web page, but I can't find it anymore since they changed web sites. Now *this* is something you should get them to fix! I'll post my own personal wrapper to configure this evening if I get the chance. Well I think I have used yours already: set QTDIR=D:\install\qt\qt-3 set MINGW=D:\mingw set MSYS=D:\msys set PATH=%QTDIR%\bin;%MINGW%\bin;%MSYS%\bin;%PATH% set QMAKESPEC=win32-g++ cd qt-3 configure.bat -fast -verbose Abdel. Angus
[Bug] Tex2lyx produced file not readable
Hello,
I think I found a bug in the latest version of Tex2lyx for windows. I am
using lyx-1.3.7pre5 for windows (XP).
I can send you complete files if needed.
Hope this helps,
Abdel.
lyx -dbg any gives :
[~Local
Settings/Temp/lyx_tmpdir1672a00960/1672a00960]->
>[~Local Settings\Temp\lyx_tmpdir1672a00960\1672a00960]
LyX: \the_end read in inset! Error in document! [around line 18549 of
file ~Loca
l Settings\Temp\lyx_tmpdir1672a00960\1672a00960]
[~Local
HSettings/Temp/lyx_tmpdir1672a00960/1672a00960]->
>[~Local Settings\Temp\lyx_tmpdir1672a00960\1672a00960]
LyX: Missing \end_inset at this point. Read: `' [around line 18549 of
file ~Local Settings\Temp\lyx_tmpdir1672a00960\1672a00960]
Here is the relevant portion of the genrated lyx file, ending at line 18549:
select
\begin_inset ERT
status collapsed
\begin_layout Standard
\backslash
\end_layout
\end_inset
the data to be displayed via a pull-down selection box (VNSE, VFTE, etc
\begin_inset ERT
status collapsed
\begin_layout Standard
{
\end_layout
\end_inset
\begin_inset ERT
status collapsed
\begin_layout Standard
\backslash
dots
\end_layout
\end_inset
\begin_inset ERT
status collapsed
\begin_layout Standard
}
\end_layout
\end_inset
The file continues with the following:
)
\begin_inset ERT
status collapsed
\begin_layout Standard
}
\end_layout
\end_inset
\end_layout
Here is the corresponding latex file (generated with OpenOffice,
Writer2latex41 and Jex)
___
\liststyleWWviiiNumxxxviii
\begin{enumerate}
\item {\selectlanguage{english}
select \ the data to be displayed via a pull-down selection box (VNSE,
VFTE, etc{\dots})}
\item {\selectlanguage{english}
fix the alpha value and get the corresponding percentage value and
vice-versa.}
\end{enumerate}
\bigskip
{\selectlanguage{english}
${}$ }
{\centering\selectlanguage{english}
\label{bkm:Ref32232953}\textcolor{black}{Figure
}\textcolor{black}{6.5}\textcolor{black}{\nobreakdash-}\textcolor{black}{13}\textcolor{black}{:
Statistic Properties of errors}
\par}
