Re: Port of my dynmacro branch to 1.6
Stefan Schimanski wrote: I would be happy to hear some comments or reports how it performs. Feel free to ask if something is unclear in the code. What is the way to proceed now? How did you test this yourself? How ready is it to release quality? Did you write documentation for the feature? Regards, Asger
Re: LyX CVS/SVN diff support.
Oh, I certainly meant that the text should be reduced to a SHA-1. I agree it does not make sense to only reduce the insets. Regards, Asger
Re: LyX CVS/SVN diff support.
Alfredo Braunstein wrote: Amazing review, thanks. On a fast read, I've found that the variant that perfectly fits our edition/CT capabilities is 1-degree, unit cost edit distance. Unfortunately the algorithm cited for this purpose [Sel77, Didn't look at it yet, though.] seems to have time and space complexity of O(|T1||T2|) which doesn't seem very practical (and by the way, this seems roughly similar to what you get with string edit distance in which insets are symbols of an extended alphabet with cost of substitution recursively defined as edit distance, using plain Levenshtein algorithm) Only X percent of insets will have changed when you compare two documents. In a long document, X will be small. Therefore, you can probably optimise most of the problem away so that complexity will not hurt you. Calculate a SHA-1 of the contents of each inset, and use that for initial comparisons, rather than the complete list of characters. Then complexity is the product of the number of insets squared, which shouldn't be to bad. After this, you get a reduced list of insets which are changed, and then you can rerun the algorithm on the text of those only. Regards, Asger
Re: LyX CVS/SVN diff support.
Alfredo Braunstein wrote: [*] There are many of them. Actually it is not really straightforward because the data structure in LyX is not linear but rather a tree, but I think this issue can be solved. Another possible problem is that best known algorithm are worst case O(N^2) where N is the size of the doc. There are variants that are much faster if the documents are similar (for instance a O(N*D) algo where D is the "distance" between them), but this may be a problem if we are trying to integrate it in an automatic context like cvs. See http://arxiv.org/abs/0708.4288 for a recent ph.d. dissertation that contains a bunch of improved algorithms for doing tree diffs, and much more. Regards, Asger
Re: Full XeTeX support
To learn more about XeTeX, see also this video: http://www.river-valley.tv/conferences/tex/tug2007/#Jonathan_Kew2 Regards, Asger
Re: [Patch] One BufferView per Buffer
You are certainly right that fixing a bug is a better way to spend time than arguing pointlessly. However, sometimes there is hope that a clarification of team members different points of view will help make the team work better. In this case, it is clear that people have different point of views. Some think that the quality of LyX is increased best by any combination of code reviews, the fact that more than one person understand the code, that changes are only done in small, incremental steps that are well-documented and discussed before hand, and that everyone does works in the same, disciplined way, slowly, but surely moving forward. Others think that is it better to be more pragmatic and get the job done. To spend more time coding and testing and bug-fixing, rather than discussing and reviewing. So what do you think is right? What is best for LyX? Why? When you have thought about this a bit, then ask yourself some more questions: - Is it OK if someone disagrees with the rules you would like to have? - Does everybody have to agree on how to work together? - Can there be different set of rules for different people? - Could code reviews be voluntary? - Should the rules be flexible or strict? - Should LyX - and thus the rules - try to accommodate as many talented developers as possible? People get upset if they think that someone intentionally breaks the rules. When you get this feeling, ask yourself: Could it be that the other person does not believe in and share the rule you have? In that case, is that person intentionally hurting you by breaking the rule? Or is that person just following his own set of rules. Maybe, maybe not. But before you judge the other person, judge the rule: Maybe the rule is not flexible enough. Everyone is entitled to their own opinion about rules. The more tolerant each person is, the better everybody will get along. The more flexible the rules are, the easier it is to work together. I believe José has very clearly demonstrated this with the very flexible handling of development in the 1.5 cycle. Regards, Asger
Re: [Patch] One BufferView per Buffer
John Levon wrote: On Tue, Aug 14, 2007 at 08:10:10PM +0200, Asger Ottar Alstrup wrote: It seems people have the priorities wrong. I think you need to rank efforts based on how much it brings thing forward per time unit, because LyX is chronically resource starved. Which is why it's a huge problem when uncontrolled development is allowed (see pretty much ever major LyX release, ever, but *especially* the huge quagmire 1.4cvs got itself into). As an exercise for the reader - maybe your skill level will improve - go back and read what I wrote, and tell me what should have been done differently in the 1.4.x cycle. The answer *is* in my post. You just have to read it and understand it, and then you'll find the answer. Regards, Asger
Re: [Patch] One BufferView per Buffer
For what it is worth, I agree with Abdel. Of course, a code review is always good, but testing is better, and coding & bug-fixing is best. It seems people have the priorities wrong. I think you need to rank efforts based on how much it brings thing forward per time unit, because LyX is chronically resource starved. Abdel tested his code, and is confident in it. He has proven his skills many times. He makes mistake, just like everyone else. This has never stopped LyX from progressing, and will not now. The effort of producing an understandable patch series that will ease the review costs so much that other developers with no experience with that code can understand it, is just not worth it. The effort is much better spent testing the result thoroughly, report and fix bugs, and maybe add a bunch of comments in the header files. In the last 5 years of LyX, at most 50% of the code was understood by more than one person. It's ridiculous to think that quality and maintainability is only dependent on how many people understand the code or how well it was reviewed. Quality and maintainability is primarily dependent on these things: 1) The availability of competent developers for productive work. 2) The skill level of the developer behind it. 3) How much the code was tested. Given X minutes of time, doing a code review will reduces factor 1 and 3, while it might improve 2. If you have a competent developer, the likelihood that the skill level will improve is smaller. So it's not worth it in that case. It's much better to ask a competent developer to test it systematically, including all edge cases. Regards, Asger
Re: [PATCH 4114] Enable File -> Revert if buffer is clean but the file is externally modified.
Bo Peng wrote: 5. I like File->reload a lot better than File->revert so I also change the menu name. This part can be removed if you guys like revert better. Note, however, that the LFUN is actually named LFUN_BUFFER_RELOAD. This command is traditionally called Revert. I checked in some random programs: Adobe Photoshop, the Gimp, Mathematica, Picassa. If you want to make it more clear, I suggest to rename it "Revert to saved" instead, but changing to Reload is a mistake. Regards, Asger
Release management dissertation
Hi, See http://www.cyrius.com/publications/michlmayr-phd.pdf for a dissertation about the role of release management in open source projects. I have not read all of it, but it does contain some interesting thoughts about whether to use feature based releases, or time based releases. Also, it touches on what practices and tools seem to make release processes work better in terms of helping the resulting quality of the release. It should be an interesting read at this point, where plans are being made for the process for 1.6. Regards, Asger
Re: [PATCH] Reworking of Paragraph Settings Dialog
Jürgen Spitzmüller wrote: Richard Heck wrote: "Use this paragraph's default alignment (Justified)" That's fine with me, though I'd suggest "the" instead of "this", as that is OK for the multi-paragraph case, too. Oh no, please don't. Use tooltips for verbose hints (you can't imagine how long this label will be in the German translation). Usability is more important. And if need be, the German translation can just omit some of the "unnecessary" details in the text. Regards, Asger
Re: [PATCH] Reworking of Paragraph Settings Dialog
Richard Heck wrote: changes the label to "Default for Current Paragraph"---I think that > makes it a little clearer to users what this does---and makes some > space for adding "(Justifed)" without alignment issues. May I suggest to name it Built-in Alignment for Current Paragraph (Justified) instead? If you don't like the word Built-in, then please make it Default Alignment for Current Paragraph (Justified) to make it *extra* clear what default we are talking about. There is room enough, according to the screen shot. Regards, Asger
Offtopic: Comapping.com launched - discount for LyX developers
Hi, I know this is completely off topic for LyX, but I hope you forgive this shameless plug. I have just helped launch comapping.com, which is the software we used to write the mind map summary of last year's meeting in Denmark - at that time, it was an early beta. Now we have gone live, so I'm just trying to spread the word. I can offer a discount for LyX developers - if you buy an account, just forward the confirmation mail to me and I'll double the subscription from 6 months to one year. Regards, Asger P.S. I'll consider you a LyX developer if you are mentioned in Credits, or ought to be.
Re: r17298 - /lyx-devel/trunk/src/CutAndPaste.C
Lars Gullik Bjønnes wrote: Then you are saying that __func__ is hurting a lot... and that is resolved at compile time, so I just do not belive you. This depends on the compiler. What costs is writing to lyxerr in the first place, not BOOST_CURRENT_FUNCTION. A lyxerr null-wirte is not free. (far from it) Yes, this is the problem. Regards, Asger
Re: r17298 - /lyx-devel/trunk/src/CutAndPaste.C
| > | this I do use BOOST_CURRENT_FUNCTION (and even got flamed for doing so | > | by Asger). We profiled stuff and found that in some critical inner loops, the use of BOOST_CURRENT_FUNCTION hurt performance a lot. If you want to use such stuff, please make sure it is guarded correctly to not hurt performance, which I also explained at the time. Regards, Asger
Re: [part 2] again about LyX's default settings
Uwe Stöhr wrote: This doesn't work here. I think I found another solution without pdfopen/pdfclose. I've had a look in the Acrobat SDK and use now OLE-objects. This works very well with Acrobat 7. I cannot test Acrobat 8, because this would require to uninstall Acrobat 7 what I'm not allowed. (The various CSLID codes cannot be changed manuall in the registry.) So can you test out this program?: http://wiki.lyx.org/uploads/Windows/LyXWinInstaller/PDFViewWin.exe I downloaded this, and double clicked it. And it crashes when I run it. I have Adobe Acrobat Reader 7.0.9 and Windows XP. Regards, Asger
Re: Regarding LyXWinInstaller - proposal
What is the most important in an open source project? - The code? - The developers? - What the users think? Well, I guess all of these things are important. So, let's look at the installers on these accounts: - Uwe's installer is simple code and works. - Uwe's has been the most stable development resource. - Uwe's installer is the most popular among novice users and gives the least support. - Joost's installer is difficult to understand. - Joost is an expert, but disappears from time to time. - Joost's installer is more popular among expert users, and works without administrative privileges. Now it is clear that it *does not* solve the problem if Joost extends the installer with the features that Uwe's installer has. This might make it more popular among users and reduce support, but the most stable resource will *NOT* be able to fix bugs. If Joost's installer should have a chance to become a base for team work, the most stable and dedicated resource - Uwe - has be able to work with it. In my mind, it is clear that neither installer is perfect. But it is *NOT* clear that the best base is Joost's. Therefore, I think Joost's installer should be properly documented such that other people can understand it. Also, it should be able to bundle all components that Uwe's does. And similarly, Uwe's installer should work without administrative priviledges. And when there is code that needs to be developed further, it should go in the SVN so that others can help. It is *ABSURD* that Uwe's code can not be put in SVN - this is EXACTLY preventing team work. Regards, Asger
Re: Regarding LyxWinInstaller
Choose between: 1) Click on a download link once, go and have coffee. Start the installer, click Next, click Next, click Next, click Next, click Next. LyX is easy. 2) Click on a download link. Start the installer, read what it says, choose to download, click next, wait a long time, then read what it says again, choose to download, click next, wait a long time, then read what it says again, choose to download, click next, wait a long time, then read what it says again, choose to download, click next, wait a long time, then read what it says again, choose to download, click next, wait a long time, then read what it says again, choose to download, click next, wait a long time, then read what it says again, choose to download, click next, wait a long time, then read what it says again, choose to download, click next. LyX is crap. Regards, Asger
Re: Can LyX handle large files ?
Abdelrazak Younes wrote: You misunderstood me. I don't deny you are right these are probably too expensive. I am just saying that I am not convinced that this is the major culprit for the slowness on Mac and on Windows for LyX file with a lot of big equation. But hey, every bit of speed we can gain is good :-) Try to make a test program that does nothing but allocate small pieces of memory, fill it up, and then free it again. Before you run it, guess how many allocations you can do in a second. Then run it and learn. Regards, Asger
Re: Can LyX handle large files ?
Abdelrazak Younes wrote: Asger Ottar Alstrup wrote: I've changed it. Please test. There is a fair chance this gives a nice speedup, maybe even on MacOS as well. That would be an easy way out but I am not convinced... Visually speaking, all these if are not very nice... *You* are taking the easy way out. I guess it's time for a little C++ quiz. Look at this line of code: lyxerr[Debug::PAINTING] << "draw " << std::string(str.toUtf8()) << " at " << x << "," << y << std::endl; First, the easy question: How many memory allocations are involved? Then a little harder question: Do you know how expensive memory allocation is? And then the conclusion: Is it such a great idea to do that? Regards, Asger
Re: Can LyX handle large files ?
Abdelrazak Younes wrote:
I know but I was talking about this other debug info at line 240 of
QLPainter that is also using PAINTING:
if (isDrawingEnabled()) {
lyxerr[Debug::PAINTING] << "draw " << std::string(str.toUtf8())
<< " at " << x << "," << y << std::endl;
drawText(x, y, str);
}
So I think I am right there... Well at least for 1.5.
I just got rid of that one as well. This one is particularly expensive:
2 memory allocations involved. I know that I originally wrote that line
for debugging, but it was never meant to be committed as you did in
15723. Sorry for not being clear about that.
This was my initial idea also but I am not sure if this is useful
because is the test is done in any case in the lyxerr << operator. More
exactly this test is done at line 97 of debugstream.h:
std::basic_ostream & operator[](Type t) {
if (debug::match(dt, t))
return *this;
return nullstream;
I guess that's what the person who wrote debugstream thought. "This is
probably good enough." But that person forgot to have a look at
nullstream. It is a piece of absolute crap.
So it boils down to a very simple message for all coders here:
** Don't use lyxerr[] in a critical code path. ***
I have said this many times. I guess I should try all caps:
** lyxerr[] IS **ALWAYS** EXPENSIVE LIKE HELL **
Regards,
Asger
Re: Can LyX handle large files ?
Asger Ottar Alstrup wrote: Try running LyX with a command line parameter "-dbg any" and inspect the output when redrawing. If lots of stuff is coming out, review that output to make sure it is not done like the above. Most of it was done wrong - some of it even using monsters like BOOST_CURRENT_FUNCTION. Who knows what voodoo that shit does? I've changed it. Please test. There is a fair chance this gives a nice speedup, maybe even on MacOS as well. Regards, Asger
Re: Can LyX handle large files ?
Abdelrazak Younes wrote:
As my painting investigation continue, it seems that this problem has
_nothing_ to do with painting on screen at all. Modifying a text line
between two huge formula exhibits the slow behaviour even if only the
text line is repainted on screen (you can use "-dbg painting" to make
sure of that.
You are running to conclusions. Math is painted using a different
mechanism than text - it goes through MathHullInset. The # debug
painting only works for text.
Insert debugging info in the QLPainter around line 253, and you will see
that math indeed draws text on the screen.
"So, for example, if LyX were running
with debug enabled, the debug lines being written to the LyX console
window might cause a noticeable jump in csrss load. But I haven't
tested that."
csrss.exe handles output to the console. If you are printing stuff to
stderr or stdout, this might show in csrss spending a lot of CPU on some
systems.
Another bad thing to do is to have lines line
lyxerr[Debug::PAINTING] << (something here);
because even if Debug::PAINTING is NOT turned on, the (something here)
will be evaluated.
You need to rewrite such things to
if (lyxerr.debugging(Debug::PAINTING)) {
lyxerr << (something here);
}
Try running LyX with a command line parameter "-dbg any" and inspect the
output when redrawing. If lots of stuff is coming out, review that
output to make sure it is not done like the above.
I started my LyX process 45 minutes ago with -dbg any, and the main
window has not come up yet - it's still reading the layout files and
dumping everything character by character.
So it's fair to conclude that debugstream is a piece of crap. I suspect
that even the tiniest lyxerr << statement costs a billion cycles.
I tried to see the best way to hack it out, but the code is so
convoluted that it's probably much simpler to use preprocessing magic to
redefine lyxerr as "//" and be done with it.
Regards,
Asger
Re: 3 important bugs right now - more testing needed!
Michael Gerz wrote: Pardon? You really should have a look at Status.15x! I also noticed that some assertions are violated which indicate serious problems in the core I did look at Status.15x, and did not find anything critical. Please correct me if I overlooked something, but to me it looks very much like the bugzilla db now: Full of annoying things, but nothing that really stops you from working. Polishing is important, but not urgent. Showstopppers are important and urgent. Asger, which bug are you going to address tonight? :-) You can choose between me spending some time to write status e-mails, or getting 0.1 bugs fixed because when I'm done updating and recompiling, my time is up. Regards, Asger
3 important bugs right now - more testing needed!
It seems bug fixing proceeds with a good pace. On my list, there are 3 items now, which should be enough for about one evening: * Spell checking cannot be invoked a second time. This is probably a one-liner. * The first time the spell checker is started, an empty window shown instead of the first misspelled word. Probably also a one-liner. * Cursor is still not visible on MAC Bennett (3/11/06). I propose to revert to the old cursor painting scheme if no progress is made on this. There is about 1 week to the deadline for the test release. It seems Abdel is cooking a painter optimisation, which will require a good deal of testing. Therefore, he should focus on getting that done as soon as possible and leave the bugs for others. So, guys, this is your chance to be a hero. In the testing department, I don't think new showstoppers have appeared for some time, as far as I can tell. Therefore we need more testers, because there *still* are very serious bugs in LyX to be found - bugs that mean that the program can not be used as intended in one serious way or another. Regards, Asger
Re: My Big Fat (Greek?) Cursor
Joost Verburg wrote: Abdelrazak Younes wrote: BTW2, every app that I know (except emacs, but it's easy to switch to this scheme also) use Ctrl+y for Undo. Why on earth do we still use Shift+Ctrl+z? Could we please add Ctrl+y as and additional default? Ctrl+Y? Every application I know uses Ctrl+Z. I guess he meant Redo, in which case I agree. Regards, Asger
Re: Help needed with wide streams
Enrico Forestieri wrote: The point is that I am not able to link with debug info (-g) as the final link stage fails with a "Memory exhausted" error. You could try to compile most of the code without debug info, except for the files you are interested in debugging. Just pass -g to the files you want to debug, and to the linker, but omit it from all other files you compile. Regards, Asger
6 showstoppers
My take on which of the known bugs are showstoppers for the test release: * The title bar does not contain the document name when a new window is opened (Joost 4/11/06). Should be a simple fix for those in the know. * Spell checking cannot be invoked a second time. I can not reproduce because I do not have aspell. I guess cmake does not support aspell yet? * The first time the spell checker is started, an empty window shown instead of the first misspelled word. * TOC crashes (simply make a few sections, subsections, sections; then add TOC before all sections and click on the left button) * Copy/paste using middle mouse button inserts musical notes. I guess this is X specific, since middle button on Windows does not paste. A windows hacker could have a look at this to do the X people a favour. * Cursor is still not visible on MAC Bennett (3/11/06). I though that Abdel reverted to the old painting scheme, so this is a little strange to me... Regards, Asger
Re: [PATCH] convert MathParser to unicode
Abdelrazak Younes wrote: Please review this patch; I am not quite sure these are the correct fixes for the MSVC warning. But it seems to parse math correctly. > -CatCode theCatcode[256]; +CatCode theCatcode[sizeof(lyx::char_type)]; Hm, is sizeof(lyx::char_type) not 4? I think you mean 1 << (sizeof(lyx::char_type) * 8) and then it becomes obvious that this is probably not such a great idea: Allocating 32 MB for this table where you only fill in the first 256 slots seems a little excessive. Regards, Asger
Re: How about a debugging spree?
Bo Peng wrote: We have repeated long bug list posted to this list and it is hard to keep track of them. I propose that we put a file status.15x in trunk and start a debugging spree. I am interested in knowing who will be our champion (although the answer is almost obvious :-) when I get back. Agreed? I think this is a good idea, except that I think showstoppers should still be sent to the list from time to time to encourage discussion and also make sure that they are not forgotten. And when they are fixed, it's visible, and therefore our heroes become visible. I think it's important to triage aggressively in the bug list, such that the work always seems manageable by focusing on the most important, even though the reality probably is that 100s of bugs are waiting for us. Regards, Asger
Status: 4 showstoppers downs and 4 new ones coming up. Bring in the cavalry!
Peter & Abdel are certified heroes. They squashed a good deal of bugs yesterday, and put things back on track in this everlasting LyX drama. Hope is restored! But no crisis without a new one building up. Here is a new batch of bad guys to go after. Showstoppers: - Printing the tutorial crashes LyX. Reproduce: Ctrl+p & enter. It happens at the very start of Buffer::makeLaTeXFile, because encodings.getEncoding(params().inputenc) returns 0. - Open user guide. Type something. Open the tutorial. Switch back to user guide. Choose File, revert. The tabs disappears. The title of the window is wrong. Switch to another application and back to force a refresh, and everything is fine. - Ctrl+w (close) closes the entire application, even if I have several documents open. It should only close the current document. Probably old behaviour exposed by the new tabs. - Copy/paste using middle mouse button inserts musical notes. I guess this is X specific, since middle button on Windows does not paste, but it's such a fundamental operation that it has to be promoted to a showstopper. Showstopper, but not reproducible: - I got a crash opening the user guide. I had another small document open, and opened the user-guide. There was an auto-save version of it, which I decided to ignore. Then it said boom. Can not reproduce. Other problems: - Mac is unusable because of poor performance, among other things. Options: a) Reimplement partial coord cache refresh and redraw. b) Implement a caching painting scheme, such that only changed paint requests are done. Although this is not a showstopper since performance is as poor as 1.4, it is hero material anyway. - No UTF-8 support in LaTeX export. Georg, can you explain what needs to be done? - Branches are not unicode clean. Someone needs to review the branch code and make it do the right thing. - URLs in documents causes pdf LaTeX error. José says that "provide(url)" or similar is missing somewhere. So, now that our heroes have cleared out some of the worst bad guys from the field, it's time to ramp up on the testing to find some more bugs. If you find a showstopper, that brings a little bit of hero status for you. Finding hopeless showstoppers is definitely heroic. Regards, Asger
Status: 3 hopeless showstoppers + more
Hi, More bugs are being reported recently, and none of the old ones have been fixed. Thus, we are moving in the wrong direction. Showstoppers without hope: - Selection with the mouse. Does not work in math nor in tables. It kind of works in insets, although problems have been reported with this as well. To reproduce, make a formula or a table, type some text and try to select it with the mouse. We need a volunteer to investigate this. - Crashes with multiple windows open. It seems that Buffer contains Rows of paragraphs, and this is no good in a multiple view setting. Options: a) Rework Buffer to not have Rows (big change, risky), b) Disable multiple views completely for now, c) Disable multiple views of same document only. Seems to me option C would be safe and still provide some benefit to the user. - Cursor trouble: Full refresh on each blink. Abdel says it's a lot of work to fix this without the pixamp. Options a) Spend that time, b) Revert to old painting scheme. Given that the removal of the pixmap did not give us any noticable speed-up, I think we should revert this change which was done the last Monday of the meeting. Showstoppers with hope: - In math the cursor blinks at the start of the math inset and then seems to go the correct place afterwards. I suggest that Peter's patch which disables immediate cursor updates is applied, unless someone can track down the bug in the math code. Other problems without hope: - Mac is unusable because of poor performance, among other things. Options: a) Revert commit from 14th of July which disabled partial refresh. This is a little dangerous, since it is known that this might cause invalid coord cache entries. b) Do a), but also implement partial coord cache refresh to make it safe. c) Implement a caching painting scheme, such that only changed paint requests are done. - No UTF-8 support in LaTeX export. - Nice icons in change tracking missing. Other problems with hope: - Copy/paste using middle mouse button inserts musical notes. - Branches are not unicode clean. Reported by Helge. - URLs in documents causes LaTeX error. Reported by Helge. Change tracking is being worked on, and will be done before the 14th. The tab bar work is settling down. I think all other pending patches have all been applied, but it's difficult to keep track off. We have a bunch of problems without any hope. At the same time, people are getting too busy to work on LyX. So, the future does not look too bright for LyX. In other words, we are back in deep shit again. Therefore, I would suggest to freeze the code even more until progress has been made on the hopeless showstoppers. We have some difficult problems to solve, and those will require a concentrated effort to nail. The positive side to this is that each person who conquers a hopeless showstopper is instantly a hero. Regards, Asger
Re: Coord cache and single par update
Martin Vermeer wrote: On Wed, Nov 01, 2006 at 11:36:08PM +0100, Asger Ottar Alstrup wrote: [Partial refresh requires partial coord cache refresh] Hmmm, I don't think this is done in 1.4, and still single par update works just fine there... I guess that in the common case, things work out correctly because the coordinates and sizes of insets are corrected when drawn. I can imagine that the problem can occur when you delete insets without triggering a full refresh. In that case, the coord cache would contain obsolete references to deleted insets, which is a recipe for trouble. Of course, the problem disappears at the next refresh, so in practice this might not cause too much trouble. > in 1.5 the infrastructure is there but it isn't working properly, as whole-screen updates have been layered on top of it with reckless disregard for what was already there, which thus is now completely useless. There was no partial refresh before the meeting in Denmark either. You have to search further back to find when it was disabled. I am a bit angry about this. It would have been so easy to see what exactly is getting rendered using the PAINTING debug flag. What about first getting the old singlepar/singlerow functionality back into a working state? Then we can see what is missing and provide it. See above. Do we want to take the risk? If we did in 1.4, we might as well in 1.5, but why not try to implement partial coord cache refresh while you are at it? Regards, Asger
Coord cache and single par update
Hi, To implement partial update (single paragraph update), it is not enough just to redraw only those parts of the screen. You also have to implement partial update of the coord cache. Right now, the only possible operation for the coord cache is to clear all of it. To implement partial update, it is necessary to change it such that you selectively remove only those parts of the coord cache which reside in the paragraph you want to redraw. The reason is that if you have a paragraph with an inset in it, the coordinates of the inset is recorded in the coord cache. If you type something in this paragraph (without changing the height of the paragraph), the inset might move, and thus you need to update the coordinates of insets in the same paragraph in the coord cache. (I assume that you understand that the coord cache contains several caches: One for paragraphs, one for insets, and a third one I forget. You have to make sure that all caches are correctly updated of course - it's not just the insets cache. Remember that the coord cache is calculated in two steps: First, sizes are calculated. Then, *when drawing* the positions are recorded.) Regards, Asger
Re: New Mac Profile
Abdelrazak Younes wrote:
No, I was interested in the details of QLPainter::text(), especially the
QPainter::drawText(). This info was not there. It is in your newer
screenshot.
This profile matches what I found on Windows.
If we manage to speed-up Qt drawing operation, we will win. I can't
imagine that there is nothing we can't do. There must be some Qt settings.
As I said before, I believe the best is to draw less. There is
absolutely no need for redrawing the entire screen on every key press.
I just added a debug statement to QLPainter.C:
if (isDrawingEnabled()) {
lyxerr << "draw " << std::string(str.toUtf8()) << " at " << x << ","
<< y << std::endl;
drawText(x, y, str);
}
You should try this. On every cursor blink, we redraw the entire screen.
This might be a result of André's reorganisation of how we paint, or it
may be an old bug. In any case, it is very wasteful.
If I disable cursor blinking by adding a return in WorkArea::showCursor,
the result is that we redraw exactly once per key press.
So the conclusion is that
- showCursor causes an unnecessary full refresh
- drawing text is slow, so draw less text
Regards,
Asger
Re: Just 2 show stoppers from a test release
Bennett Helm wrote: I think this comment involves a misunderstanding of how dire the situation currently is on Mac. Even on a window with 6 lines of text 30 characters long there is noticeable lag in typing. Moreover, LyX on Mac will not start from the GUI; there's no cursor; menus are messed up (and the Preferences dialog is inaccessible); etc. LyX-1.5 is *completely* unusable on Mac. Then we have to 1) find someone who can fix these problems one by one, 2) or accept that Mac is not a supported platform in the test-release. In terms of option 1, I suggest to make a list of problems with descriptions of how to reproduce them and track that they get fixed one by one: - Speed. I bet the only way to fix this is to draw less. Either by reimplementing the "single par" mechanism (which it seems is not even enough), or have a caching painter front to enable partial redraw of just the bits that have changed from last refresh. This is a big and somewhat complicated change, and I think your only bet is to convince Abdel to do this. The good thing about it is that it will help all other platforms, including remote X use, which must be complicated fucked up right now. - LyX will not start from the GUI. What does this mean? - There's no cursor. Should be workable. Try to change the size of the cursor widget to find out if it is misplaced. Try to change the z-order to see if it is hidden behind the pixmap. Try other things to find it. - Menus are messed up (preferences is inaccessible). Does anybody know anything about this? I suggest that you keep track of this list, update and resend it from time to time, and in this way, we'll monitor the situation. If the list does not shrink, the logical consequence is that Mac will not be supported until someone can work on it concentrated. Regards, Asger
Re: Just 2 show stoppers from a test release
Michael Gerz wrote: Asger Ottar Alstrup wrote: An update on the status of 1.5.svn. Nice work, guys - we are down to just 2 known show-stoppers for a test release: I think you are a bit too optimistic. Why? Do you know of other show-stoppers? Once again, I do not think change tracking is not a show-stopper for a test release, although it would be great it was useful. No, there are about various FIXMEs that deserve some attention. Jose proposed November 13th as the release date. I am going to meet this deadline! Thanks for the update - sounds good. Regards, Asger
Just 2 show stoppers from a test release
Hi, An update on the status of 1.5.svn. Nice work, guys - we are down to just 2 known show-stoppers for a test release: - Selection with the mouse. Does not work in math nor in tables. It works in all footnotes, floats & notes and miniboxes, even when nested. To reproduce, make a formula or a table, type some text and try to select it with the mouse. Anybody have any leads? - In math the cursor blinks at the start of the math inset and then seems to go the correct place afterwards. There was a patch from Peter which does the trick by disabling immediate cursor updates when typing. This is an improvement all in all and therefore should go in with a comment about why. Better would be to change it such that the instant cursor update remains in text, but not in math. That would make it releasable in my book. Show-stopper for 1.5 final, but not for a test-release: - LaTeX Encoding: UTF-8 support. Should supposedly be easy if you know how to do this, which is why I suggest to make it a show-stopper. Let's hope Georg finds the time somehow, but I do not think this should block a test-release. - Nice icons on change tracking toolbar. Things off the radar for now: - Fix math parser problems with sin x and friends. Patch prepared, and reviewed. - Table toolbar in menu problem. (Peter reported missing the drag-able table insertion gadget, but that exists in the toolbar. Is that not good enough?) - Various crashes with multiple views. What is the status on the change tracking? Except for icons, is that work complete for now? Any other pending patches that would be good to have in a test release? There are performance problems on Mac. I suggest that Mac users either work with small windows, big fonts or wait until we have partial refresh one way or another. Personally, I think such a change is too big to allow in 1.5.0, unless someone does it very, very soon. Regards, Asger
Re: [Cvslog] r15605 - /lyx-devel/trunk/src/rowpainter.C
Abdelrazak Younes wrote: Andre Poenitz wrote: On Sun, Oct 29, 2006 at 04:39:51PM -, [EMAIL PROTECTED] wrote: -bool const inside = (y + rit->descent() >= 0 - && y - rit->ascent() < ww); RowPainter rp(pi, text, pit, *rit, x, y); // Clear background of this row // (if paragraph background was not cleared) Good in theory but it looks as if this is the kind of infomration that would be useful for a 'non-drawing real painter' (as opposed to the original nullpainter) OK... Andre (or Asger), could you please point me to the places in the code that were using the null pointer. I would like to add the "non-drawing" feature before 1.5 in order to get some speed for Mac. I think the only important space is right above. Regards, Asger
Only 5 showstoppers known
Hi, My attempt at a status of 1.5.svn in terms of show-stoppers. The list includes just 5 known show stoppers: - In math the cursor blinks at the start of the math inset and then seems to go the correct place afterwards. Any other known cursor regressions? - Selection. Does not work in math, tables, but does in footnotes. - Fix math parser problems with sin x and friends. Make a new document, type Ctrl+m "\sin x" and save the document and then reopen to see the problem. - Fix toolbar in menu problem. To reproduce, insert a table and put the cursor there. Peter posted a patch to make the toolbars movable, but that did not help on my machine. Any other ideas? - Various crashes with multiple views. Possible interaction with the coord cache. Not easily reproducible. Things off the radar for now: - Cursor seems to work now in text, so André's rendering change can probably stay. - Encodings. UTF-8 is not supported for LaTeX output, but no known regressions from 1.4 as far as I know. I guess UTF-8 should be listed in the document encodings list, so people can choose it themselves. I guess this is not a show stopper anymore. UTF-8 support can come in 1.5.1, or 1.6.x if noone steps up to the plate. What is missing from these lists? Regards, Asger
Re: Is it time to rename .C to .cpp now?
Michael Gerz wrote: Sorry but I can't fix all open change tracking issues in one week. (I may ask for some assistance after the weekend, when it becomes clear what is missing) Notice that José is the release manager - not me. I do not get to set the target. When that is said, and with all due respect, I do not think perfect change tracking should block a test release. The purpose of the test release is to get the software tested by a wider, willing audience so that the currently UNKNOWN important problems are identified so they can be fixed before a pre-release can be rolled out to an even wider audience. Having a list of known issues with change tracking (and other things) will not stop that from happening. If the known issues are not show-stoppers, or likely to hide or introduce other problems when they are fixed, I think it's fine just to list them. Regards, Asger
Re: Is it time to rename .C to .cpp now?
John Levon wrote: I'm honestly not sure if you're joking. Same goes for Asger. I think further clean-up work, reorganisations, refactoring, or other maneuvers that primarily help the developers at the risk of breaking things for the users should wait until 1.6.svn opens. The only exception to this I can think of are things that substantially makes developers more effective in their work. And renaming a bunch of files does nothing but waste at least 15 minutes of ALL developers time due to the recompile involved. I believe in release early and often, and the most important thing José can do now is to make a list of show-stoppers that block a public test release, and encourage people to work on those issues. My take on a show-stopper list right now: - Fix cursor trouble - Fix encoding - Fix math parser problems with sinx and friends - Fix toolbar in menu problem I've probably missing two or three issues, maybe 5, but look people: The list is VERY SHORT! Therefore I believe LyX will benefit tremendously from a stronger focus at this point. The program is sooo close to be ready for the first test release. It is important to take this opportunity now, and not in a few weeks or months when new problems have been introduced, and the importance of the limitations has been diluted. Right now, there is a pretty clear picture of what the main problems are, and therefore it's important to act now. The most difficult ones that were blocking some things have been taken care of, so it should be possible to do this. There are already patches for most of the above! In a few months, 100s of big and small issues will have come and gone, and everybody will have lost track of what really needs to be done, and what would be nice to have done. Such a state can go on for eons. I believe there IS a feature freeze for LyX right now, although it seems the list has already partially forgotten this in just 2 days. José IS the release manager, and he did impose a feature freeze. It is even more important to enforce this to some extent. Yes, the freeze for 1.4 was painful, but that was because it was too long in time. The trick to make a freeze a joy is to get it over with quickly by focusing on what needs to be done. These important issues will NOT go away by themselves. The important bugs HAVE to be taken care of at some point or another. In such a situation, it will almost NEVER help to work on another feature. Every new feature just increases the back log of things that needs to be done. I really encourage all to work towards reducing the list of show-stoppers, because it is within reach right now. Yes, there are problems with the cursor, and those might be difficult to fix. Take a crack at this now, and if you fail, revert Andrés rendering change while it's still managable. That will fix the problem, possible at the expense of a minor performance gain. Do not postpone this problem, because it only becomes bigger and bigger with time. Take an action on the encoding issue now, because the problem only becomes bigger and bigger with time. If each and every one of you has this mindset, you will reach the goal very quickly, because 1.5.svn is closer to be a releasable in a test version than it ever was. I would aim for a test release in a week. Regards, Asger
Re: About scrolling speed
Abdelrazak Younes wrote: The wikipedia link that Martin's provided indicated that this is not about anti-aliasing on/off but about different methods for anti-aliasing (sharpness versus contrast). Could you please check that before we settle on any solution? It is about anti-aliasing. You can see for yourself by changing the setRenderHint calls to take "false" as the second parameter to disable anti-aliasing. Regards, Asger
Re: Is it time to rename .C to .cpp now?
Bo Peng wrote: Is there any reason *not* to do it now? It does not help the user. Use your energy on things that will help the user. Regards, Asger
Re: About scrolling speed
Martin Vermeer wrote: By the way, I cannot see any text rendering difference between the two version. Looks to me that the text is anti-aliased in both cases. Looks to me that this setRenderHint() is just a helper for something else. In windows, you can turn off anti-aliasing. The Qt setRenderHint overrides that setting. When you turned anti-aliasing off, you should not comment out the setRenderHint, but rather call it with a ",false" as second parameter. I notice now that one of the machines we were using had anti-aliasing turned off in windows, so that's the explanation. I guess you can remove those setRenderHint lines, so that we respect the windows setting people might have. Regards, Asger
Re: About scrolling speed
Abdelrazak Younes wrote: Before Denmark, the UserGuide PageDown test was at 18 seconds. Now it is at 25 seconds. I hope you have some more code in store for speed ;-) It might very well be the anti-aliasing we enabled. Can you try to revert that? Just search for setRenderHint and comment those guys out. If this is the case, I guess anti-aliasing should be optional through some preference setting. If that doesn't help, you should try to revert the nullpainter change and test again. It might be those extra paragraphs that have to be drawn outside the screen for real now that makes the difference. Finally, it could be André's new rendering scheme which is slower on your setup. Also, we'd like some MacOSX users to try the new code before we make the final judgement. One conclusion is clear: The only sure way to get substantially faster rendering is to draw less on the screen, as discussed earlier today, either by introducing the old singlePar optimisation, or do some drawing-caching scheme. The profilings were conflicting depending on the tools used, but on Windows using Glowcode, my results showed that rendering alone took around 70% of all time. updateMetrics was next in line with 7%. The rest was scattered all over the place. Regards, Asger
Re: The cursor is seriously broken..
Bo Peng wrote: On 10/23/06, Abdelrazak Younes <[EMAIL PROTECTED]> wrote: I just merged my tree with SVN and I see now big black blinking square instead of the cursor. Anybody else seeing that? Yes. ugly, black, blinking stuff. André changed the cursor to become a new widget, rather than something drawn on the screen. There are still bugs with it - I suppose he is fixing those on the plane right now. Regards, Asger
Re: GUII
Peter Kümmel wrote: Asger Ottar Alstrup wrote: Andre Pönitz wrote: Quoting Peter Kümmel <[EMAIL PROTECTED]>: [Use precompiled headers for VS] Ah, here is the official request. ;) I've added support for precompiled headers on msvc. You could enable it with the option -Dpch=1. I've added most headers (it's maybe an overkill), but they could be disabled with the macros LYX_DONT_PRECOMPILE_* in config.C.cmake/config.C I'm interested in some speedup numbers. Before it was 17.30 minutes. After it is 10 minutes. Regards, Asger
Re: rowpainter.C: unused var
Jean-Marc Lasgouttes wrote: "Andre" == Andre Pönitz <[EMAIL PROTECTED]> writes: I guess this is not something I can consider for 1.4. Andre> If we don't get mispositioning/coordcache crashes in 1.4, then Andre> not. I do have crashes with pageup in 1.4. Then the nullpainter fix is your medicine. Regards, Asger
Re: r15501 - in /lyx-devel/trunk/src/frontends/qt4: GuiFontMe...
Abdelrazak Younes wrote: [EMAIL PROTECTED] wrote: Author: poenitz Date: Mon Oct 23 10:46:09 2006 New Revision: 15501 URL: http://www.lyx.org/trac/changeset/15501 Log: do not draw to intermediate pixmap Andre, please delete commented out code if the solution work. Such things tends to stay forever. André is working like a maniac against the clock to finish the speed work. He will not be able to give it the proper polishing right now, so it would be helpful if you could give a hand with that tomorrow or tonight when he is done. He is working in GuiWorkaround.C only, so clean-ups other places can be done now. Regards, Asger
Re: Conclusions
Abdelrazak Younes wrote: Asger Ottar Alstrup wrote: I hope that the focus will remain. Without someone leading the way and telling where the goal is, LyX will wander around like a zombie and get more and more broken, just like it has for the last months. Quite frankly I feel offended by this last sentences. It looks like you're repeatedly saying that we (me principally) did nothing good in the last months. I'm very sorry about that. My critique is not personal. I have not mentioned any names at any point. Please check the archives. My critique is systematic. For months, LyX has not been usable for anything. Some of the bugs were new, some of them old. But the fact is that LyX was UNUSABLE CONSISTENTLY FOR AT LEAST A FEW MONTHS. This is my definition of BEING IN DEEP SHIT. This is not the fault of any one person. This is because there were nobody able to do what was necessary to stop this: Define the target, and move aggressively towards that target. Those that have tried to take leadership have just been flamed to death. So LyX was caught in a decision vacuum. It is simply not possible to implement any decisions that might upset somebody. From time to time, someone did that, and was still flamed to death. And it is not any single person that is at fault. Everybody have been way too fast to complain about the consequences of any given action. If you take a step back and look at this (like it has been possible for me and Jürgen as outsiders) it is clear that this will never lead to anywhere, I am trying to instill a chance of attitude for those with an open mind: When you are in deep shit, you can not afford the luxury of doing only things that will not offend anyone. You will have to break some eggs. Once you have the omelet, you can start preparing the side dishes. Regards, Asger
Re: Conclusions
Jean-Marc Lasgouttes wrote: There were cases where meeting indeed had this benefit; I think that here this "wake-up call" comedy only managed to hide the real work that was done in Denmark. The fact that we did not get to see the svn logs from you (and probably jug) did not help either; all we got to read were your silly diatribes. Use svn log. Jürgen committed from my account, because we did not want to waste time doing unnecessary compiles. We worked all days from morning till night. We did a lot of work. Most of it did not result in commits, because we were trying to find out how things worked, was supposed to work, fix it to work like it should, and then remove all the poor work-arounds that did nothing but break things more. We had fun while doing it. I'm sorry if that offends you. You mean that now we want to get unicode to work, while the only plan before was to get unicode to work? Sorry, but I fail to see the paradigm shift. I hope that the focus will remain. Without someone leading the way and telling where the goal is, LyX will wander around like a zombie and get more and more broken, just like it has for the last months. Finally, things are moving in the right direction: Every day, LyX is becoming better. To enhance that focus, we had to remove some things from the radar that were obscuring the goal. Now it's up to you. Feel free to break the momentum. Whatever you do, I'll be back next year and do my best again. Regards, Asger
Re: Conclusions
The main message I'm trying to get across is that I believe a wake-up call was needed. LyX was moving in the wrong direction, and someone had to shout and do some aggressive moves to make people realize that. Me and Jürgen decided to do that as outsiders, and to me it looks like it worked. Now everyone is talking about how to fix the *important* problems, and most importantly *working towards that*, and I believe that is the biggest contribution I can give, because I'm gone in a few hours. Regards, Asger
Re: Conclusions
Georg Baum wrote: I don't think you should call that whining. Maybe you can not imagine how your activities look from outside, but I can. I certainly can. Why do you think we took those photographs with the cleenexes? We did that because we know that there would be whining. It will be interesting to see how long it will continue. I guess we should shoot some more pictures to satisfy the thirst. Maybe one of an omelet? Regards, Asger
Re: Conclusions
Jean-Marc Lasgouttes wrote: As Georg already pointed out, several of the problems were very new, and probably did not warrant seeing Asger W. Bush declare "War on Bugs" (with the appropriate suspension of civil liberties), along with the claims of victory a few hours later. I had a lot of fun this weekend. You would have as well, if you had been here. I hope we'll manage to get this to a reasonable state (as in "be able to process all kind of accents in 1.4 files people use in real life") Yes, that seems like a reasonable release criteria. This seems very interesting to me. Our current performance on the mac in particular is a shame (especially seeing how fast xforms was with exactly the same core). André committed the first proof-of-concept, with one known bug: cursor leaves wrong background color in colored insets. Give it a spin, and report back whether it helps. I'm recompiling on windows right now. Regards, Asger
Re: How to cook an omelet
Abdelrazak Younes wrote: And I repeat myself: dialog bugs are far far far easier to solve than core bugs. So it's not like we are in such hurry with regard to qt4. Could you fix these, which are the only bugs I know of in the front-end? - The preferences dialog has the wrong size initially - The table toolbar appears in the menu line in strange ways. Regards, Asger
Re: rowpainter.C: unused var
Jean-Marc Lasgouttes wrote: I see. Isn't there some performance price? Yes, but it is not noticeable in our testing. After all, we only paint two extra paragraphs. I guess this is not something I can consider for 1.4. Sure it is. Without, the coord cache is full of crap, and that causes assertions and crashes. [Smarter redraw] Are there plans to implement that for 1.5? We have looked a lot on performance work for 1.5, we have done a lot of profiling, but there are no easy ways out. The best bet is André's patch which will avoid an extra copy of the complete workarea pixmap. That should help a lot, especially on windows. Other than that, we strongly suggest to wait until 1.6 for this work, because it will require time to stabilize. The reasoning is this: 1.4 is dead slow, 1.5 can be as well. Ideas for doing less drawing include: - Reintroduce the "draw only this paragraph" optimisation from the old days. This is a little complicated, because that means we have to only clear out part of the coord cache, and then rebuild just that part. - Add a caching layer in the painter. Instead of drawing, collect all drawing requests in a data-structure. The first time, just draw on the screen from this data structure. Then remember the data-structure which illustrates what is on the screen. When the next redraw comes, collect all the drawing requests in a new instance of the data structure. Then start comparing from the start and end of the old and the new datastructures to find the middle part which is different. This will correspond to the part of the screen which will need to be updated. Then do just those paints. Extend the middle part until you get background fill requests, because then we now the drawing requests are selfcontained. Regards, Asger
Re: Conclusions
I do not know whether the messages send during this meeting were seen as particularly bright and witty, but I am personally appalled by the pompous bullshit we have been served. We fixed *a lot* of VERY HARD TO FIX bugs, and now LyX is usable again. Some of those bugs have been chased for MONTHS. Check out LyX from this Thursday, and compare with what there is in SVN now. If that is not progress, then you are smoking crack. We backed down on the UTF-8 decision, and agreed that Georg could go ahead with his patch to support the other encodings. GTK is in a branch. Qt3 can be resurrected if someone wants to, but all others on the list were positive about this. The only known bug in Qt4 is the initial size of the preferences window. André has a proof-of-concept patch ready which will hopefully speed up Qt4 front-end a lot on windows (and also some on Linux) by avoiding an extra double buffer. All in all, I think we have done the only responsible thing: We have rescued the trunk, which was COMPLETELY broken. We have introduced a freeze because otherwise, the trunk will break again. Just look at what has happened the last few months. LyX was becoming progressively worse- 1.5 will be monotonously better than 1.4. So. Stop whining. Or have some cheese with it: http://www.lyx.org/images/whineandcheese2.jpg Regards, Asger
Re: GUII
Oh, one more thing: You need to add something like /Fp"\build\bin\debug\lyx-qt4.pch" as well, to make sure all projects use the same precompiled header. Regards, Asger
Re: GUII
Andre Pönitz wrote:
Quoting Peter Kümmel <[EMAIL PROTECTED]>:
>>> [Use precompiled headers for VS]
Ah, here is the official request. ;)
First: Is it worth the effort? How big is the speedup?
I did a test. Use the attached config.h.cmake. Make a config.cpp file
with just one line:
#include "config.h"
in it.
Now, change all project files to use precompiled headers through
config.h (add /Yu"config.h" to command line for all .cpp files).
Finally, add the config.cpp file to your project, for instance lyx-qt4,
and make that generate the precompiled header (add /Yc"config.h" to the
command line instead of /Yu"config.h".)
Enjoy.
My compile times were halved.
Regards,
Asger
/*
* \file config.h
* This file is part of LyX, the document processor.
* Licence details can be found in the file COPYING.
*
* This is the compilation configuration file for LyX.
* It was generated by autoconfs configure.
* You might want to change some of the defaults if something goes wrong
* during the compilation.
*/
#ifndef _CONFIG_H
#define _CONFIG_H
#cmakedefine HAVE_IO_H 1
#cmakedefine HAVE_LIMITS_H 1
#cmakedefine HAVE_LOCALE_H 1
#cmakedefine HAVE_PROCESS_H 1
#cmakedefine HAVE_STDLIB_H 1
#cmakedefine HAVE_SYS_STAT_H 1
#cmakedefine HAVE_SYS_TIME_H 1
#cmakedefine HAVE_SYS_TYPES_H 1
#cmakedefine HAVE_SYS_UTIME_H 1
#cmakedefine HAVE_SYS_SOCKET_H 1
#cmakedefine HAVE_UNISTD_H 1
#cmakedefine HAVE_INTTYPES_H 1
#cmakedefine HAVE_UTIME_H 1
#cmakedefine HAVE_STRING_H 1
#cmakedefine HAVE_STRINGS_H 1
#cmakedefine HAVE_ISTREAM 1
#cmakedefine HAVE_OSTREAM 1
#cmakedefine HAVE_IOS 1
#cmakedefine HAVE_LOCALE 1
#cmakedefine HAVE_OPEN 1
#cmakedefine HAVE_CLOSE 1
#cmakedefine HAVE_POPEN 1
#cmakedefine HAVE_PCLOSE 1
#cmakedefine HAVE__OPEN 1
#cmakedefine HAVE__CLOSE 1
#cmakedefine HAVE__POPEN 1
#cmakedefine HAVE__PCLOSE 1
#cmakedefine HAVE_GETPID 1
#cmakedefine HAVE__GETPID 1
#cmakedefine HAVE_MKDIR 1
#cmakedefine HAVE__MKDIR 1
#cmakedefine HAVE_PUTENV 1
#cmakedefine HAVE_MKTEMP 1
#cmakedefine HAVE_MKSTEMP 1
#cmakedefine HAVE_STRERROR 1
#cmakedefine HAVE_STD_COUNT 1
#cmakedefine HAVE_ASPRINTF 1
#cmakedefine HAVE_WPRINTF 1
#cmakedefine HAVE_SNPRINTF 1
#cmakedefine HAVE_POSIX_PRINTF 1
#cmakedefine HAVE_FCNTL 1
#cmakedefine HAVE_INTMAX_T 1
#cmakedefine HAVE_INTTYPES_H_WITH_UINTMAX 1
#cmakedefine HAVE_DECL_ISTREAMBUF_ITERATOR 1
#cmakedefine CXX_GLOBAL_CSTD 1
#cmakedefine HAVE_GETCWD 1
#cmakedefine HAVE_STPCPY 1
#cmakedefine HAVE_STRCASECMP 1
#cmakedefine HAVE_STRDUP 1
#cmakedefine HAVE_STRTOUL 1
#cmakedefine HAVE___FSETLOCKING 1
#cmakedefine HAVE_MEMPCPY 1
#cmakedefine HAVE___ARGZ_COUNT 1
#cmakedefine HAVE___ARGZ_NEXT 1
#cmakedefine HAVE___ARGZ_STRINGIFY 1
#cmakedefine HAVE_SETLOCALE 1
#cmakedefine HAVE_TSEARCH 1
#cmakedefine HAVE_GETEGID 1
#cmakedefine HAVE_GETGID 1
#cmakedefine HAVE_GETUID 1
#cmakedefine HAVE_WCSLEN 1
#cmakedefine HAVE_WPRINTF 1
#cmakedefine HAVE_LONG_DOUBLE 1
#cmakedefine HAVE_LONG_LONG 1
#cmakedefine HAVE_WCHAR_T 1
#cmakedefine HAVE_WINT_T 1
#cmakedefine HAVE_STDINT_H_WITH_UINTMAX 1
#cmakedefine HAVE_LC_MESSAGES 1
#cmakedefine HAVE_SSTREAM 1
#cmakedefine HAVE_ARGZ_H 1
#cmakedefine SIZEOF_WCHAR_T_IS_2 1
#cmakedefine SIZEOF_WCHAR_T_IS_4 1
#ifdef SIZEOF_WCHAR_T_IS_2
# define SIZEOF_WCHAR_T 2
#else
# ifdef SIZEOF_WCHAR_T_IS_4
#define SIZEOF_WCHAR_T 4
# endif
#endif
#cmakedefine HAVE_ALLOCA 1
#cmakedefine HAVE_SYMBOL_ALLOCA 1
#if defined(HAVE_SYMBOL_ALLOCA) && !defined(HAVE_ALLOCA)
#define HAVE_ALLOCA
#endif
#cmakedefine HAVE_ASPELL_ASPELL_H 1
#cmakedefine HAVE_ASPELL_H 1
#cmakedefine HAVE_ICONV_CONST 1
#ifdef HAVE_ICONV_CONST
#define ICONV_CONST const
#else
#define ICONV_CONST
#endif
#cmakedefine PACKAGE "${PACKAGE}"
#cmakedefine PACKAGE_VERSION ${PACKAGE_VERSION}
#cmakedefine USE_POSIX_PACKAGING 1
#cmakedefine USE_WINDOWS_PACKAGING 1
#cmakedefine PATH_MAX ${PATH_MAX}
#ifdef _MSC_VER
#undef HAVE_OPEN // use _open instead
#define pid_t int
#define PATH_MAX 512
#endif
#ifdef _WIN32
#undef HAVE_MKDIR // use _mkdir instead
#endif
#define BOOST_ALL_NO_LIB 1
#if defined(HAVE_OSTREAM) && defined(HAVE_LOCALE) && defined(HAVE_SSTREAM)
# define USE_BOOST_FORMAT 1
#else
# define USE_BOOST_FORMAT 0
#endif
#cmakedefine ENABLE_ASSERTIONS 1
#if !defined(ENABLE_ASSERTIONS)
# define BOOST_DISABLE_ASSERTS 1
#endif
#define BOOST_ENABLE_ASSERT_HANDLER 1
#define BOOST_DISABLE_THREADS 1
#define BOOST_NO_WSTRING 1
#ifdef __CYGWIN__
# define BOOST_POSIX 1
# define BOOST_POSIX_API 1
# define BOOST_POSIX_PATH 1
#endif
#if defined(HAVE_NEWAPIS_H)
# define WANT_GETFILEATTRIBUTESEX_WRAPPER 1
#endif
#if defined(MAKE_INTL_LIB) && defined(_MSC_VER)
#define __attribute__(x)
#define inline
#define uintmax_t UINT_MAX
#endif
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#if BOOST_VERSION < 103300
# include
#else
# include
#endif
#include
#include
#include
#include
#include
#
Re: rowpainter.C: unused var
Jean-Marc Lasgouttes wrote: Asger> The nullpainter is no good, because it can not calculate the Asger> metrics of text, so it's basically useless. It was the cause of Asger> wrong metrics in the coordcache, which caused all sorts of Asger> problems. what did you replace it with? We use the real painter. Regards, Asger
Conclusions
Hm, action please. We suggest that all capable enthusiasts immediately go to lyx.org and read the news. EOT
Re: r15492 - /lyx-devel/trunk/src/support/lstrings.C
Edwin Leuven wrote: Lars Gullik Bjønnes wrote: | -if (str.length() > 2 and str[0] == '0' && | +if (str.length() > 2 && str[0] == '0' && I think this should we reverted, this is only working around buggy compilers. We don't need that in our sources. that buggy compiler is msvc2005, so it may be better to keep it in... Why do you think we fixed the bug? http://www.lyx.org/images/whineandcheese1.jpg Sob sob, Asger
Re: [Cvslog] r15482 - /lyx-devel/trunk/src/text.C
Michael Gerz wrote: Currently, the status bar (at the bottom) is not updated if you move the cursor. Is somebody willing to fix this or shall I file a bug report? Jürgen will commit a fix shortly. Regards, Asger
Re: rowpainter.C: unused var
Michael Gerz wrote: /home/software/lyx-trunk/src/rowpainter.C:865: warning: unused variable `const bool inside' > Asger, is it safe to remove the variable? Yes, and you can nuke the nullpainter as well while you are at it. The nullpainter is no good, because it can not calculate the metrics of text, so it's basically useless. It was the cause of wrong metrics in the coordcache, which caused all sorts of problems. Regards, Asger
Solution
Hi, People are unhappy about various things. We have the solution for this: http://www.lyx.org/images/whineandcheese2.jpg Regards, The chefs
Re: How to cook an omelet
Georg Baum wrote: For information I attach here the patch I was working on yesterday before the freeze announcement. It already works for the case where you have only one encoding in the document. I also had an idea how to treat multiple encodings that would need a similar amount of changes. Then you would need to add an utf8 encoding to the list (and all the numbers in lib/encoding can probably be removed), some error handling for the case where iconv fails, and then you can use every encoding you could use in 1.4 + utf8. The patch looks great! Please apply it. When we made the decision to freeze, LyX was in such a terrible state that we had to do something drastic. Fortunately, we made a lot of progress just the hours after, and the "only" serious problems we see now are broken cursor movement, and bad performance. Of course, there are other things, but undo, redo, cut/copy/paste, delete and all that seems to work correctly now. We had a look at the bug list and did not find any real show-stoppers there. (Of course, we might have overlooked something - then please let us know.) So in light of these developments, a revised plan could be to fix the cursor things, do some basic performance work, you could do the encoding stuff, and very shortly after that, do a pre-release of LyX 1.5.svn as soon as possible so that the hidden serious bugs are shaken out. Regards, Asger
Re: How to cook an omelet
Juergen Spitzmueller wrote: Lars Gullik Bjønnes wrote: Discussions are made and concluded in the kitchen, those not able to get out of the living room get no say. Espeically not if they does not help with providing solutions instead of problems. I see. I'll shut up, then. Just remember that on meetings, every day is a Friday. No smilies. Regards, The drunken duo, Asger & Jürgen
Re: How to cook an omelet
Georg, the last few commits have resurrected LyX back from the dead. You are therefore allowed to do a few of your pet features outside the kernel, just because you are such a nice guy. Hope that will keep you motivated. Regards, Asger & Jürgen P.S. On meetings, every day is a Friday!
Re: How to cook an omelet
Georg Baum wrote: ** NO NEW FEATURES ARE ALLOWED FROM RIGHT NOW ** I do not agree with this one if it means all new features, not just those that require changes to the core. The sooner we fix the basic things, the sooner we can introduce new and small features. The fact is that right now, things are not improving. Maybe basic features working last weekend, but they don't know. We HAVE to react to that. I partially do not agree, and I feel betrayed: A long time everything is allowed, and then from one day to the other we are in a freeze. Basic functionality like latex encodings that has been working in previous releases is not allowed to come back, but new features like multiple windows are allowed to be finished. We are not trying to be unfair, or unreasonable. We just have to draw a line somewhere, because we feel that something has to change compared to how things are going now. The sooner people use their energy on fixing things, the sooner new features can come in again. This decision is silly IMHO, and it will also give bad press if release n+1 removes some features that were available in release n. We will ready to accept bad press, if that is what will happen. LyX is *seriously* broken right now. It is NOT useable for ANY work. Don't think we are just talking here. We are 5 people working full time to fix things now for several days in a row. Unfortunately, our progress is slow, so we conclude that we have to do something to prevent the boat from sinking. I would have done different things in a different order if it would have been clear that this freeze comes now. For example I have several smaller changes in the pipeline that are pretty safe, e.g. some of the bugs marked with fileformat. Of course, bug fixes are allowed. That is the point of the freeze: To improve the quality of the program, not to make it worse. If that decision is a final one then don't expect any further 1.5 work from me. We are 5 people working on LyX now, but we also know that most of us will not work on LyX from Tuesday on. So we are very interested in finding a way to keep all talent motivated and help with making LyX a great application. You could have come to Denmark and participated in the discussion. All of you know that this kind of decision has always been made at meetings, because it's just not possible to discuss this on mail. At start, the five of us did not agree on this decision, but when we discussed the matter in depth, we all agreed on the decision. We hope that you will reconsider and help us fix the show stoppers. The sooner we reach the critical point where trunk is usable again, the sooner the fun can begin again for all of us. Maybe you should also talk about why the current state is like it is. And maybe some of you should have a look on the many open bugs in 1.4. Fixing these has had a far too low priority IMO. 1.4 was released with some known regressions wrt 1.3. Now it looks like 1.5 will be released with even more regressions + the already existing 1.4 bugs. Try to explain that to any user. I would not be able to do so. We are all unhappy about the current state, but we are where we are. We did discuss whether we should seriously revert to the 1.4 code base, and maybe even start fixing the issues in 1.4 instead of continuing with the trunk. In the end, that was considered too drastic, so we decided that we should try for maybe 6 months to rescue the trunk. Do you think this is the wrong decision? Regards, Asger & Juergen
Re: How to cook an omelet
Michael Gerz wrote: Does Denmark agree that bug fixes are welcome at all times? We are just starting organizing a national election to decide this. So far the polls say yes, but you know what happened with the Euro. Regards, Denmark
How to cook an omelet
Hi, We have discussed the state of SVN, and concluded the following: *** Trunk is very broken right now Basic things like editing, cut, copy & paste, navigation, undo/redo and so on are broken. Everytime a bug is fixed, 10 new ones are discovered. Everytime a fix is committed, 5 new buggy features have been added in the mean time. When things are as broken as they are, we need to take the right steps to fix it. We decide the following rules to bring things back on track: ** NO NEW FEATURES ARE ALLOWED FROM RIGHT NOW ** ** NO MORE CLEAN-UP IS ALLOWED FROM RIGHT NOW ** ** ONLY ONGOING WORK CAN CONTINUE FROM RIGHT NOW ** So ongoing work like unicode, change tracking, and multiple windows can continue. Other work has to wait, including performance work. Once things are back to working, 1.5 should be released. It might be a slow release, it might not support the encodings people want, but at least it will be useful for most people that use LyX now. Those that are unhappy about the release will have to settle with 1.4, or wait until 1.6 is released. When 1.5 is released, development can open again for 1.6, and stuff like performance and new encodings can be added. We hope you will agree with this, and understand that we won't have to do the drastic thing we had to do with 0.13 where we dropped years of development and started over again from a stable base. In a situation where LyX becomes worse every other day, we can not afford the luxury of setting an ambitious goal for the release. We will have to disappoint some people's expectations for the sake of not loosing the progress that has been made. Regards, Asger, Juergen, André, José & Lars
Re: Multiple windows
- Cursor should only blink in active window
Re: [PATCH] new LFUN_WINDOW_NEW
Abdelrazak Younes wrote: I am sure I implement that in the right way. Please someone who knows about LFUNs, review the patch. You forgot the patch. Regards, Asger
CMake problems
Hi, Two things: - ENABLE_ASSERTIONS is not defined in config.h. #define ENABLE_ASSERTIONS 1 - InsetMathMBox.C is compiled, although it should not be. Looking at development\cmake\src\mathed\CMakeLists.txt, it seems that the casing is wrong - the B is small. Don't know if that is the reason. Regards, Asger
Re: Good morning, Denmark!
Michael Gerz wrote: Hello everybody! Still busy with Unicode? Who is actually attending the LyX developers meeting in Denmark? Hi, The basics of Unicode is done. Georg did most of it. The user guide and friends can be opened and produce seemingly correct LaTeX output now. Present - André - still not able to compile LyX - Jürgen - struggling with a Windows machine - Lars - eating - me - fixing whatever I come across Later today, José will join us. Regards, Asger
Re: Bug: screen not updated HOME/END
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Index: GuiWorkArea.C
| ===
| --- GuiWorkArea.C (revision 15390)
| +++ GuiWorkArea.C (working copy)
| @@ -426,7 +426,7 @@
|
| void GuiWorkArea::update(int x, int y, int w, int h)
| {
| - viewport()->update(x, y, w, h);
| + viewport()->repaint(x, y, w, h);
| }
We'll test this patch and report back.
Doesn't help. To reproduce:
Open user guide, press ctrl+end, then ctrl+home.
Regards,
Asger
Cmake does not build lyx2lyx_version.py.in
This means that lyx2lyx does not work, and therefore I can not load any documents. Regards, Asger
UTF-8 export to LaTeX works
Hi,
I just committed a few fixes to get UTF-8 latex export working.
Regards,
Asger
Index: bufferparams.C
===
--- bufferparams.C (revision 15381)
+++ bufferparams.C (working copy)
@@ -839,26 +839,32 @@
texrow.newline();
}
- if (inputenc == "auto") {
- string const doc_encoding =
- language->encoding()->latexName();
+ // TODO: Some people want to support more encodings than UTF-8. They
can have a field day around here
+ if (true) {
+ os << "\\usepackage[utf8]{inputenc}\n";
+ texrow.newline();
+ } else {
+ if (inputenc == "auto") {
+ string const doc_encoding =
+ language->encoding()->latexName();
- // Create a list with all the input encodings used
- // in the document
- std::set encodings =
- features.getEncodingSet(doc_encoding);
+ // Create a list with all the input encodings used
+ // in the document
+ std::set encodings =
+ features.getEncodingSet(doc_encoding);
- os << "\\usepackage[";
- std::set::const_iterator it = encodings.begin();
- std::set::const_iterator const end = encodings.end();
- for (; it != end; ++it)
- os << lyx::from_ascii(*it) << ',';
- os << lyx::from_ascii(doc_encoding) << "]{inputenc}\n";
- texrow.newline();
- } else if (inputenc != "default") {
- os << "\\usepackage[" << lyx::from_ascii(inputenc)
- << "]{inputenc}\n";
- texrow.newline();
+ os << "\\usepackage[";
+ std::set::const_iterator it = encodings.begin();
+ std::set::const_iterator const end =
encodings.end();
+ for (; it != end; ++it)
+ os << lyx::from_ascii(*it) << ',';
+ os << lyx::from_ascii(doc_encoding) << "]{inputenc}\n";
+ texrow.newline();
+ } else if (inputenc != "default") {
+ os << "\\usepackage[" << lyx::from_ascii(inputenc)
+ << "]{inputenc}\n";
+ texrow.newline();
+ }
}
if (use_geometry || nonstandard_papersize) {
Index: mathed/InsetMathMBox.C
===
--- mathed/InsetMathMBox.C (revision 15381)
+++ mathed/InsetMathMBox.C (working copy)
@@ -25,10 +25,10 @@
#include "paragraph.h"
#include "texrow.h"
+using lyx::odocstream;
using std::auto_ptr;
using std::endl;
-
InsetMathMBox::InsetMathMBox(BufferView & bv)
: text_(&bv), bv_(&bv)
{
@@ -73,7 +73,7 @@
ws << "}";
} else {
ws << "\\mbox{\n";
- text_.write(*bv_->buffer(), ws.os());
+// text_.write(*bv_->buffer(), ws.os());
ws << "}";
}
}
Index: output_latex.C
===
--- output_latex.C (revision 15381)
+++ output_latex.C (working copy)
@@ -292,12 +292,14 @@
}
}
- if (bparams.inputenc == "auto" &&
- language->encoding() != previous_language->encoding()) {
- os << "\\inputencoding{"
- << lyx::from_ascii(language->encoding()->latexName())
- << "}\n";
- texrow.newline();
+ if (false) {
+ if (bparams.inputenc == "auto" &&
+ language->encoding() != previous_language->encoding()) {
+ os << "\\inputencoding{"
+ << lyx::from_ascii(language->encoding()->latexName())
+ << "}\n";
+ texrow.newline();
+ }
}
// In an an inset with unlimited length (all in one row),
Index: paragraph_pimpl.C
===
--- paragraph_pimpl.C (revision 15381)
+++ paragraph_pimpl.C (working copy)
@@ -666,7 +666,7 @@
// I assume this is hack treating typewriter as verbatim
if (font.family() == LyXFont::TYPEWRITER_FAMILY) {
if (c != '\0') {
- os << c;
+ os.put(c);
}
break;
}
@@ -691,7 +691,7 @@
}
if (pnr == phrases_nr && c != '\0') {
- os << c;
+
Compile error in InsetMathMBox.C
I had to add using lyx::odocstream; at the top of InsetMathMBox.C, but now I get: InsetMathMBox.C ..\..\..\lyx-devel\src\mathed\InsetMathMBox.C(76) : error C2664: 'LyXText::write' : cannot convert parameter 2 from 'lyx::odocstream' to 'std::ostream &' Any ideas? Regards, Asger
Re: Math does not work
Georg Baum wrote: Can you please try whether this patch works, too? It has the advantage that it does not do an implicit encoding conversion when calling cur.insert(c), so non-ASCII characters like ü should work, too. I don't have patch, so just commit. To me, it looks obviously correct. Regards, Asger
Re: Math does not work
Asger Ottar Alstrup wrote:
Maybe the problem was introduced in revision 14861 by baum, where he
converted lfun arguments to docstring. Line 705 (was line 695 in 14860)
was changed from only calling interpret with the first character to be
called with all characters.
I'm trying to call interpret with just one character again, to see if
that helps.
Yes, that was the problem. It's tricky: There are two different
interpret functions - one taking a character and another taking a
string. Baum changed it to take a string, and then it broke because it
called the wrong method.
Patch attached, will commit shortly.
Regards,
Asger
Index: converter.C
===
--- converter.C (revision 15373)
+++ converter.C (working copy)
@@ -322,7 +322,7 @@
Alert::error(_("Cannot convert file"),
bformat(_("No information for converting %1$s "
"format files to %2$s.\n"
- "Define a convertor in the
preferences."),
+ "Define a converter in the
preferences."),
lyx::from_ascii(from_format), lyx::from_ascii(to_format)));
return false;
}
Index: cursor.C
===
--- cursor.C(revision 15373)
+++ cursor.C(working copy)
@@ -864,7 +864,7 @@
lyxerr << "can't enter recursive macro" << endl;
InsetMathNest * const in = inset().asInsetMath()->asNestInset();
- if (in && in->interpret(*this, s))
+ if (in && in->interpretString(*this, s))
return true;
plainInsert(createInsetMath(name));
return true;
Index: mathed/InsetMathNest.C
===
--- mathed/InsetMathNest.C (revision 15373)
+++ mathed/InsetMathNest.C (working copy)
@@ -675,7 +675,7 @@
if (cmd.argument().size() != 1) {
recordUndo(cur);
string const arg = lyx::to_utf8(cmd.argument());
- if (!interpret(cur, arg))
+ if (!interpretString(cur, arg))
cur.insert(arg);
break;
}
@@ -705,9 +705,12 @@
// FIXME: Change to
// } else if (!interpret(cur, cmd.argument()[0])) {
// when interpret accepts UCS4 characters
- } else if (!interpret(cur, lyx::to_utf8(cmd.argument( {
- cmd = FuncRequest(LFUN_FINISHED_RIGHT);
- cur.undispatched();
+ } else {
+ std::string arg0 = lyx::to_utf8(docstring(1,
cmd.argument()[0]));
+ if (!interpretChar(cur, arg0[0])) {
+ cmd = FuncRequest(LFUN_FINISHED_RIGHT);
+ cur.undispatched();
+ }
}
break;
@@ -913,19 +916,19 @@
case LFUN_ERT_INSERT:
// interpret this as if a backslash was typed
recordUndo(cur, Undo::ATOMIC);
- interpret(cur, '\\');
+ interpretChar(cur, '\\');
break;
case LFUN_MATH_SUBSCRIPT:
// interpret this as if a _ was typed
recordUndo(cur, Undo::ATOMIC);
- interpret(cur, '_');
+ interpretChar(cur, '_');
break;
case LFUN_MATH_SUPERSCRIPT:
// interpret this as if a ^ was typed
recordUndo(cur, Undo::ATOMIC);
- interpret(cur, '^');
+ interpretChar(cur, '^');
break;
// FIXME: We probably should swap parts of "math-insert" and "self-insert"
@@ -933,9 +936,10 @@
// math-insert only handles special math things like "matrix".
case LFUN_MATH_INSERT: {
recordUndo(cur, Undo::ATOMIC);
- if (cmd.argument() == "^" || cmd.argument() == "_")
- interpret(cur, cmd.argument()[0]);
- else
+ if (cmd.argument() == "^" || cmd.argument() == "_") {
+ std::string arg0 = lyx::to_utf8(docstring(1,
cmd.argument()[0]));
+ interpretChar(cur, arg0[0]);
+ } else
cur.niceInsert(lyx::to_utf8(cmd.argument()));
break;
}
@@ -1162,7 +1166,7 @@
}
-bool InsetMathNest::interpret(LCursor & cur, char c)
+bo
Re: Math does not work
Asger Ottar Alstrup wrote: Abdelrazak Younes wrote: Asger Ottar Alstrup wrote: Click Ctrl+M, type 1. The 1 goes into the main text, not the math. Old one also. I think this one is related to unicode. I've been step debugging through it and all key inputs inside mathed are translated into spaces... which make the cursor goes out of mathed! Well, that's not what happens for me. When I press 1, that is correctly converted to UTF-8 representation of 1. From line 708 in MathHull::doDispatch, it goes to InsetMathNest::interpret because arg has size 1. Then in line 1346 of InsetMathNest.C, cur.pos() == 0, and thus interpret returns false. Then line 709 in MathHull decides that we probably want to end editing. I'm not sure where the mistake is, but it does not look like a unicode problem to me. Maybe the problem was introduced in revision 14861 by baum, where he converted lfun arguments to docstring. Line 705 (was line 695 in 14860) was changed from only calling interpret with the first character to be called with all characters. I'm trying to call interpret with just one character again, to see if that helps. Regards, Asger
Re: Math does not work
Abdelrazak Younes wrote: Asger Ottar Alstrup wrote: Click Ctrl+M, type 1. The 1 goes into the main text, not the math. Old one also. I think this one is related to unicode. I've been step debugging through it and all key inputs inside mathed are translated into spaces... which make the cursor goes out of mathed! Well, that's not what happens for me. When I press 1, that is correctly converted to UTF-8 representation of 1. From line 708 in MathHull::doDispatch, it goes to InsetMathNest::interpret because arg has size 1. Then in line 1346 of InsetMathNest.C, cur.pos() == 0, and thus interpret returns false. Then line 709 in MathHull decides that we probably want to end editing. I'm not sure where the mistake is, but it does not look like a unicode problem to me. Regards, Asger
Re: Crash in TOC dialog
Abdelrazak Younes wrote: OK, then give me a crash course in how to change a Qt4 dialog. Are you ready? Double click on the "frontends/qt4/ui/QTocUI.ui" :-) I have to select which program to use to edit that file. I guess it's designer.exe. And lo and behold, that worked. Now, how do I change the order of those buttons? Hm, let me try to break the layout. OK, that worked. Make the changes, and make a new layout for our friends. Then let's try preview. Ups, the layout is foobar: the bottom line is at the top. I guess breaking the layout was not such a brilliant idea. Revert to trunk, and try again... Hm, struggle, struggle. How can I reorder the elements in the layout? I have tried a million things, but I am simply unable to do this. Is designer really such a broken tool? OK, I'll just change the texts, and then edit the file in a text editor to swap these two fuckers. OK, the columns attributes seem to do the trick. Open in designer and preview. Yep, it looks right. Now, try to compile LyX, and see what happens. Ah, I get the stupid mac-ending bug. OK, fix that, and then wait for linking... Hm, those linking times are ridiculuous. Let me disable debugging info for now... OK, it linked, and it works. Great, patch attached. Committing in a few seconds. If the patch applies to 1.4, be happy. I don't have 1.4 checked out, so someone else have to pick that up. Regards, Asger Index: src/frontends/qt4/ui/QTocUi.ui === --- src/frontends/qt4/ui/QTocUi.ui (revision 15373) +++ src/frontends/qt4/ui/QTocUi.ui (working copy) @@ -1,7 +1,4 @@ - - - QTocUi @@ -47,17 +44,17 @@ - + -&Out +<- &Promote - + -&In +&Demote -> @@ -172,7 +169,6 @@ - typeCO tocTV
Re: Subfigure in image dialog requires mind reading skills to use
Georg Baum wrote: Asger Ottar Alstrup wrote: SVN, Windows, Qt4: Extra options tab has a "Subfigure" check-box with associated "Caption" input field. I click it and write something, but it has no effect whatsoever. I guess this only makes sense in some special LaTeX environment, but please explain that in the dialog, or insert that fancy environment automatically when clicking the check box. Ignore this. The plan is to remove it and add a subfigure inset. I have a half finished one from one or two years ago if you want to start another project;-) In that case, once I learn how to do Qt4 dialogs, I'll remove this gunk. How much of that dialog should go? Regards, Asger (who loves to break eggs, omelets, beers and what not)
Re: Crash in TOC dialog
Abdelrazak Younes wrote: Asger Ottar Alstrup wrote: Also, I propose to change the "In" and "Out" buttons like this: [ <- Promote ] [ Demote -> ] where promote was out, and demote was in. Agreed. Please do the change yourself. OK, then give me a crash course in how to change a Qt4 dialog. Regards, Asger
Subfigure in image dialog requires mind reading skills to use
SVN, Windows, Qt4: Extra options tab has a "Subfigure" check-box with associated "Caption" input field. I click it and write something, but it has no effect whatsoever. I guess this only makes sense in some special LaTeX environment, but please explain that in the dialog, or insert that fancy environment automatically when clicking the check box.
Re: Unicode LaTeX export
Jean-Marc Lasgouttes wrote: And seriously, nobody will be pleased when you tell them that our TeX files are utf8. This is not a good encoding for latex now. I've been playing around with LyX head for a few minutes now, and there are so many problems. Math editing does not work *at all*. Make a table, and it crashes all over the place. I can't believe we are discussing to stop UTF-8 export because then we can not mix Russian and Hebrew. You can not write a document in Hebrew and Russian in any LyX version. Do I need to remind you that nobody are pleased with documents full of only numbers? Right now, in fact you can only use LyX to write a budget full of numbers and nothing else. There is nothing that stops anyone from extending LyX to export in multiple marsian encodings, but LyX has been broken for months, so my conclusion is that at this point, we have to break some eggs to make an omelet. Regards, Asger
Math does not work
Click Ctrl+M, type 1. The 1 goes into the main text, not the math.
Preferences zoom does not work in Qt4
Tools, options, set zoom to 200, and click Apply. Nothing happens. Click Save, nothing happens. Open preferences again, and see that the zoom is back to 150. Thanks for nothing.
Toolbar buttons are greyed out
svn, Windows, MSVC, qt4: 1. New document. 2. Click Find in the toolbar 3. Click Close in Find dialog Many toolbar buttons are grey now - including Find. They should not be grey. Click on the canvas, and they are re-enabled. The same thing happens with lots of other dialogs, include TOC. This is annoying and confusing.
Crash in TOC dialog
1. New document 2. Write something 3. Mark that as a Section 4. Open TOC - you will see you something there 5. Click In buttons until you see a crash Also, I propose to change the "In" and "Out" buttons like this: [ <- Promote ] [ Demote -> ] where promote was out, and demote was in. Regards, Asger
Re: Unicode LaTeX export - decision
Georg Baum wrote: You misunderstood me. My proposal was not to do the internal conversion. My proposal was to the same with all latex() methods that I did with plaintext(): Output to UCS4 streams and do the conversion to utf8 in the file stream. Sounds good to me. Lars talks about compression might not work with this, but if you can handle that, we have a plan: First step: (Georg volunteered :-) - Write UCS4 streams which are converted to UTF-8 by magic - So the LaTeX file is in UTF-8 encoding Next steps: - Fix compression problems - If there are problems with LaTeX support for UTF-8, we will work to fix that in LaTeX camp (or use workaround hacks in LyX) - If you need a LaTeX file in something else than UTF-8, then use an external converter (which LyX can automatically invoke) Regards, Asger & Lars
Re: Unicode LaTeX export
Georg Baum wrote: I don't think either that there would be a performance problem. What might be a problem is that an inset knows more about its content (and, more importantly, about the context) and could do a better conversion than an external converter could do. For example, I am 100% sure that ucs4 characters exist that need to be translated to different LaTeX macros in math mode and in text mode. In LyX we always know whether we are in text or math mode. An external script would need to parse LaTeX, and if you think that that is easy have a look at tex2lyx (which btw is far from perfect). Perfect is the enemy of good. Why cares about those unicode characters? We can hack those somehow if they are important. In summary and IMHO: let's keep the core C++ LyX simple and only support utf8. With my proposal the core would be simple and not even know about utf8, only ucs4, except for the cases like the example above. IMO we do not need to answer now the question whether the conversion will be external or not if we follow my proposal. I really would like to know what others think. Tell me a little more about your proposal. What are the pros and cons compared to UTF-8 + external conversion? So far, I've got: Pro: - LyX can do smart conversions depending on context (not important to me) Con: - More complicated code Which to me means that UTF-8 + external conversion wins. Regards, Asger
Re: Unicode LaTeX export
Georg Baum wrote:
No. What is exported currently to LaTeX is a mixture of utf8 (e.g.
InsetCommandParams) and ucs4 code points as numbers. It would be pretty
easy to always do utf8 export, but this does not make sense IMO before it
is clear how LaTeX export to other encodings than utf8 should look like.
I think the first question to answer is: Do we need to handle different
encodings in insets, or are we going to export to utf8 and converting if
necessary? The latter would be more simple, but it might not be flexible
enough.
LaTeX can do UTF8, it seems.
http://mail.nl.linux.org/linux-utf8/2004-04/msg0.html
Just use "\usepackage[utf8]{inputenc}".
Let's do UTF-8 all over the place as the first step.
I can't believe nobody did this so far!
Georg, you can do that in a hour, can't you?
LyX 1.5 would instantly become useful again, and thus there is a chance
we would have testers!
After that, we can consider to support the encodings LyX-1.4 can use, to
the same level as LyX-1.4, but I would say that this is a second
priority: UTF-8 is superior in almost any way.
After that, we can see if more should be done, but I have not heard many
requests for strange encodings, so why bother at all?
Regards,
Asger
Unicode LaTeX export
Hi, Are there any preliminary patches for LaTeX export that we can build on? Regards, Asger
Re: Compiling with MSVC - and request for general status
Bo Peng wrote: zlib.lib exists in zlib123-dll\lib, and zlib.h in zlib123-dll\include. I have tried various extra_inc_path variations, but I'm not able to get it to work. Which zlib are you using? It is stated clearly in INSTALL.scons that you need official zlib package (not the mingw one). scons looks for zdll.lib, not zlib.lib. As far as I can see, I am using the official one: http://www.zlib.net/zlib123-dll.zip I got the cmake version to build, so this is not critical. I think the chances are probably high that it's scons tool itself which is broken. After all, I am just using some random nightly build. For instance, "scons -h" does not work as it should: It does not print help, but tries to compile. (Except if I run it in a directory without any scons files, where it works, strangely enough) Regards, Asger
Re: Compiling with MSVC - and request for general status
Enrico Forestieri wrote: On Sun, Oct 15, 2006 at 03:08:32PM +0200, Asger Ottar Alstrup wrote: Asger Ottar Alstrup wrote: [Configure.py does not work when invoked from LyX, but >> command line does] Is this a known problem? Try creating \Resources\lyxrc.dist with a path prefix entry, something like: \path_prefix "C:\path\to\dir\with\latex\executable" OK, that lead me to the answer: I had put the build directory under lyx-devel, rather than next to it, so LyX could not find the lib directory. Therefore, I added LYX_DIR_14x environment variable to the process using VC debug feature. That meant that LYX_DIR_14x was NOT set for ::system calls, and thus configure.py did not get that. So it seems there is no bug in LyX - it was my setup. But one more question: Where does output from lyxerr end up? I do not see it on the console... Regards, Asger
Re: Compiling with MSVC - and request for general status
Asger Ottar Alstrup wrote: I'm downloading and installing MikTeX now. I have installed MikTeX now, and I can run LaTeX from a command prompt. However, LyX does not find LaTeX when reconfiguring from within LyX. The configure script surely runs, because there is lots of spew in the DOS window, but it can not find LaTeX. When I run lib/configure.py from a command line (with the exact same current directory and parameters as invoked from LyX), it does indeed find LaTeX, and furthermore pops up with some MikTeX installation windows. In other words, it seems to work that way. So, the configure.py script does not work when invoked from LyX. The only explanation I can think of is that the Systemcall we use is wrong. Looking at systemcall.C line 46, I see that we use ::system. That should be fine, though so I'm at a loss... Is this a known problem? Regards, Asger
