Re: mail size and attachments for the mailinglist
José Matos wrote: I did so I suppose the list got it. Certainly we are interested, I was expecting someone more knowledge to answer (Hello Georg, or Angus). :-) I got it, too, so the list definitely received it. I have not yet answered for the very same reason: not enough time. Georg
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
Re: [Cvslog] r15605 - /lyx-devel/trunk/src/rowpainter.C
Andre Poenitz wrote: On Mon, Oct 30, 2006 at 11:12:41AM +0100, Abdelrazak Younes wrote: Andre Poenitz wrote: 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) I have implemented that and got rid of the NullPainter altogether: Did it make any difference speed-wise? I didn't noticed any improvement on Windows. But it could make a difference one day on Mac, maybe... Abdel.
Re: Status: 3 hopeless showstoppers + more
Martin Vermeer wrote: On Thu, Nov 02, 2006 at 08:50:45PM +, John Levon wrote: On Thu, Nov 02, 2006 at 08:28:45PM +0100, Asger Ottar Alstrup wrote: More bugs are being reported recently, and none of the old ones have been fixed. Thus, we are moving in the wrong direction. Or people have been doing some testing... regards john Agreed. This is what happens every time. And 1.5 hasn't been in any broad use yet... You mean every four years? Abdel.
Re: Status: 3 hopeless showstoppers + more
Enrico Forestieri wrote: On Fri, Nov 03, 2006 at 01:18:08AM +0100, Abdelrazak Younes wrote: Enrico Forestieri wrote: On Fri, Nov 03, 2006 at 12:07:56AM +, José Matos wrote: On Friday 03 November 2006 12:05 am, Enrico Forestieri wrote: Bo, View-Source seems currently broken. I don't know how much non-showstoppers are required to equal a showstopper but I think three should suffice, so you have your chance to enter the hall of fame ;-) What is broken? I have used today, and now as I have double checked and it works for me... Really? When I select View source I only see a line % Preview source code for paragraph and nothing else. If I select Display complete source then it works. Maybe this is also a byproduct fix of the backing pixmap fix by Abdel? Man, why are you all so eager to put the blame on me? :-) No, this has nothing to do with my pixmap fix. But maybe the following one has to do with it ;-) After File-Close I don't see the banner but still the document previously opened, even if it has actually been closed. This one is mine yes, should be easy to fix. Abdel.
Re: Bug 2960: Inserting an URL cause latex/pdflatex failure
On Thursday 02 November 2006 2:13 pm, Helge Hafting wrote:
More lyx-1.5svn testing:
Insert a URL into the document, fill in the URL field with
http://www.free-firewall.org
Try view-pdflatex or view-latex,
get the error message
Undefined control sequence \url{http://www.free-firewall.org}
I am sorry, I can not reproduce the bug.
The attached file works for me.
What document class are you using?
I looked to the latex output and it is correct, I don't see ant regression
when compared with 1.4
--
José Abílio
url-example.lyx
Description: application/lyx
Re: Namespace problems
Joost Verburg wrote: Hi, I'm not able to compile LyX 1.5svn anymore with MSVC 2005 on Windows now the namespaces have all been changed. Compilation of support/mkdir.C and tex2lyx/tex2lyx.C fails. Can someone take a look at this? I'm trying to make the Windows installer available for 1.5. I am afraid not many people use MSVC with scons these days. If you post your compile error someone could probably help though. Out of curiosity Joost, don't you know C++? Abdel.
Re: Status: 3 hopeless showstoppers + more
José Matos wrote: On Thursday 02 November 2006 7:28 pm, Asger Ottar Alstrup wrote: - No UTF-8 support in LaTeX export. What needs to be done here? I would like to help fixing it. Any pointers? I explained it already at least two times but here we go again: - uncomment the utf8 line in lib/encodings - increase the file format number - write revert_inputenc in lyx2lyx that changes utf8 to auto. - make sure that generate_encoding_info.py uses the encodings that are valid in 1.4, not the changed ones for conversion of the document contents to utf8. Since we can get it now for free it would be good to add all other encodings that are currently supported by inputenc at the same time. See also http://bugzilla.lyx.org/show_bug.cgi?id=2927 for a related problem. I don't understand at all why this is without hope. It takes a bit of time to implement and test, but is still easy compared to the other hopeless bugs. If you are lazy you can of course leave out the file format change, but since a reasonable conversion from utf8 to auto is possible I would do it. Georg
Re: Status: 3 hopeless showstoppers + more
Enrico Forestieri wrote: On Fri, Nov 03, 2006 at 01:18:08AM +0100, Abdelrazak Younes wrote: Enrico Forestieri wrote: On Fri, Nov 03, 2006 at 12:07:56AM +, José Matos wrote: On Friday 03 November 2006 12:05 am, Enrico Forestieri wrote: Bo, View-Source seems currently broken. I don't know how much non-showstoppers are required to equal a showstopper but I think three should suffice, so you have your chance to enter the hall of fame ;-) What is broken? I have used today, and now as I have double checked and it works for me... Really? When I select View source I only see a line % Preview source code for paragraph and nothing else. If I select Display complete source then it works. Maybe this is also a byproduct fix of the backing pixmap fix by Abdel? Man, why are you all so eager to put the blame on me? :-) No, this has nothing to do with my pixmap fix. Well, I was actually saying that maybe José doesn't see it because you fixed it with your patch. So, it is the other way around ;-) Ahh... OK. But I am not responsible for this nice side effect either. I still have to recompile with that applied. Isn't it time to go to bed? Yes, seems so (for you at least) ;-) ;-) Short night... Abdel.
Re: Status: 4 showstoppers downs and 4 new ones coming up. Bring in the cavalry!
Asger Ottar Alstrup wrote: 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. Confirmed. - 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. Confirmed. But I won't call that a show-stopper for an alpha release as there is no crash. The feature just need some polishing. - 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. I can't reproduce that. Ctrl+w works fine here. - 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. Until you can reproduce it reliably, this is not a show-stopper. 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. b) should be easy to do using QPixmapCache. Abdel.
Re: Status: 3 hopeless showstoppers + more
On Fri, 2006-11-03 at 00:05 +0100, Abdelrazak Younes wrote: Asger Ottar Alstrup wrote: - 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. Option d) disable multi-window and implement multiple WorkArea within a QTabWidget. This will allow to open two tabs showing different part of the same document. This is a nice work-around of the bad Paragraph row model as the two BufferView will have a fortiori the same dimensions. - 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. I have now restored the backing pixmap. -dbg painting will print at the console which area is refreshed. Yes, this is a very good idea. Note that we still are not where we should be (and where 1.4 is): still after every keypress, the whole screen will be refreshed in the second update step. The culprit appears to be the statement view()-buffer()-changed() in lyxfunc.C. This sends a signal LyXView to redraw the whole screen in WorkArea. There is no way to specify anything less than a full screen. Unfortunately commenting out this line isn't good either: then not even the current row gets updated (but it will be if you cover and expose theLyX window...) This should be redone somehow to do a current-paragraph update if Update::SinglePar is set. Can you do that with signal-slot? - Martin ... Other problems without hope: - Mac is unusable because of poor performance, among other things. I believe it is precisely this issue. Options: a) Revert commit from 14th of July which disabled partial refresh. I am afraid this is not possible. The BufferView class has changed a _lot_ since that time. Literally, you're correct. Materially something like this is necessary. 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. Let's cross that bridge when we get to it. I won't say this is without hope. This just needs some time to implement the correct solution. This is for sure not a show-stopper OK. - Martin signature.asc Description: This is a digitally signed message part
Re: Status: 3 hopeless showstoppers + more
Martin Vermeer wrote: - 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. I have now restored the backing pixmap. -dbg painting will print at the console which area is refreshed. Yes, this is a very good idea. Thanks. Note that we still are not where we should be (and where 1.4 is): still after every keypress, the whole screen will be refreshed in the second update step. The culprit appears to be the statement view()-buffer()-changed() in lyxfunc.C. This sends a signal LyXView to redraw the whole screen in WorkArea. There is no way to specify anything less than a full screen. Unfortunately commenting out this line isn't good either: then not even the current row gets updated (but it will be if you cover and expose theLyX window...) This should be redone somehow to do a current-paragraph update if Update::SinglePar is set. Can you do that with signal-slot? Yes, the signal can be emitted with any number of argument. So you reckon that a boolean (singlePar) should suffice? We just need to change the signal and the WorkArea::redraw() method to accept this boolean, very easy. You reckon this would be enough? Abdel.
Re: Status: 4 showstoppers downs and 4 new ones coming up. Bring in the cavalry!
Abdelrazak Younes wrote: Asger Ottar Alstrup wrote: - 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. Confirmed. Me too. That was a misunderstanding on my side, I'll fix that soon. Georg
Re: Status: 3 hopeless showstoppers + more
Martin Vermeer wrote:
The culprit appears to be the statement
view()-buffer()-changed()
in lyxfunc.C. This sends a signal LyXView to redraw the whole screen in
WorkArea. There is no way to specify anything less than a full screen.
Unfortunately commenting out this line isn't good either: then not even
the current row gets updated (but it will be if you cover and expose
theLyX window...)
This should be redone somehow to do a current-paragraph update if
Update::SinglePar is set. Can you do that with signal-slot?
Here is a patch that does so. Please test and commit if it works.
Abdel.
Index: buffer.h
===
--- buffer.h(revision 15694)
+++ buffer.h(working copy)
@@ -119,7 +119,7 @@
bool hasParWithID(int id) const;
/// This signal is emitted when the buffer is changed.
- boost::signalvoid() changed;
+ boost::signalvoid(bool) changed;
/// This signal is emitted when some parsing error shows up.
boost::signalvoid(std::string) errors;
/// This signal is emitted when some message shows up.
Index: frontends/LyXView.C
===
--- frontends/LyXView.C (revision 15694)
+++ frontends/LyXView.C (working copy)
@@ -169,7 +169,7 @@
bufferChangedConnection_ =
buf.changed.connect(
- boost::bind(WorkArea::redraw, work_area_));
+ boost::bind(WorkArea::redraw, work_area_, _1));
errorsConnection_ =
buf.errors.connect(
Index: frontends/WorkArea.C
===
--- frontends/WorkArea.C(revision 15694)
+++ frontends/WorkArea.C(working copy)
@@ -138,7 +138,7 @@
}
-void WorkArea::redraw()
+void WorkArea::redraw(bool singlePar)
{
if (!buffer_view_)
return;
@@ -148,7 +148,7 @@
return;
}
- buffer_view_-updateMetrics(false);
+ buffer_view_-updateMetrics(singlePar);
updateScrollbar();
Index: frontends/WorkArea.h
===
--- frontends/WorkArea.h(revision 15694)
+++ frontends/WorkArea.h(working copy)
@@ -80,7 +80,7 @@
virtual void setScrollbarParams(int height, int pos, int line_height) =
0;
/// redraw the screen, without using existing pixmap
- virtual void redraw();
+ virtual void redraw(bool singlePar = false);
///
void checkAndGreyOut();
///
Index: lyxfunc.C
===
--- lyxfunc.C (revision 15694)
+++ lyxfunc.C (working copy)
@@ -1723,7 +1723,7 @@
needSecondUpdate = view()-fitCursor();
if (needSecondUpdate || updateFlags != Update::None) {
- view()-buffer()-changed();
+ view()-buffer()-changed(updateFlags
Update::SinglePar);
}
lyx_view_-updateStatusBar();
MSVC warning with toolbars.c
Bo or Peter, Please fix this: Generating Code... d:\devel\lyx\trunk\src\frontends\toolbars.c(144) : warning C4715: 'lyx::Toolbars::getToolbarState' : not all control paths return a value Abdel.
Re: MSVC warning with toolbars.c
Abdelrazak Younes wrote: Bo or Peter, Please fix this: Generating Code... d:\devel\lyx\trunk\src\frontends\toolbars.c(144) : warning C4715: 'lyx::Toolbars::getToolbarState' : not all control paths return a value Abdel. Done: Index: frontends/Toolbars.C === --- frontends/Toolbars.C(revision 15699) +++ frontends/Toolbars.C(working copy) @@ -141,6 +141,9 @@ lyxerr[Debug::GUI] Toolbar::display: no toolbar named name endl; + + // return dummy for msvc + return ToolbarBackend::OFF; } -- Peter Kümmel
Re: Status: 3 hopeless showstoppers + more
Abdelrazak Younes wrote: Martin Vermeer wrote: The culprit appears to be the statement view()-buffer()-changed() in lyxfunc.C. This sends a signal LyXView to redraw the whole screen in WorkArea. There is no way to specify anything less than a full screen. Unfortunately commenting out this line isn't good either: then not even the current row gets updated (but it will be if you cover and expose theLyX window...) This should be redone somehow to do a current-paragraph update if Update::SinglePar is set. Can you do that with signal-slot? Here is a patch that does so. Please test and commit if it works. It seems to work. I have only one #. per inserted characters now. Will commit soon. Abdel.
Re: Status: 3 hopeless showstoppers + more
On Thu, Nov 02, 2006 at 07:51:07PM -0600, Bo Peng wrote: On Friday 03 November 2006 12:05 am, Enrico Forestieri wrote: I have used today, and now as I have double checked and it works for me... Really? When I select View source I only see a line % Preview source code for paragraph and nothing else. If I select Display complete source then it works. Maybe this is also a byproduct fix of the backing pixmap fix by Abdel? I still have to recompile with that applied. Works here for the latest revision. for paragraph should be followed by a paragraph number. Please provide more details: os, compiler, file loaded and I will also try to see what might have gone wrong. I see that it works on linux, so this must be specific to cygwin. Compiler is gcc and it happens with every file loaded. This must have to do with wide streams, but it is curious that it works for complete source. I fear that I'll have to have a look as I don't think that you have Qt4 for cygwin. However, this problem should also happen with a mingw build, but I think that nobody is using mingw these days... IMO, the fact that a free software project on Windows supports a closed source compiler and not gcc is kinda of peculiar... -- Enrico
Re: Status: 4 showstoppers downs and 4 new ones coming up. Bring in the cavalry!
Georg Baum wrote:
Abdelrazak Younes wrote:
Asger Ottar Alstrup wrote:
- 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.
Confirmed.
Me too. That was a misunderstanding on my side, I'll fix that soon.
This fix goes in.
Georg
Log:
Fix thinko in Buffer::makeLaTeXFile
* src/encoding.[Ch]
(getEncoding): rename to getFromLyXName
(getFromLaTeXName): new, it does what the name says
* src/buffer.C
(Buffer::makeLaTeXFile): Fix crash by using getFromLaTeXName instead
of getFromLyXName.
Avoid crash for unknown encodings.
* src/language.C
(Languages::read): Adjust to name change above
Index: src/encoding.h
===
--- src/encoding.h (Revision 15699)
+++ src/encoding.h (Arbeitskopie)
@@ -56,8 +56,10 @@ public:
Encodings();
///
void read(std::string const filename);
- ///
- Encoding const * getEncoding(std::string const encoding) const;
+ /// Get encoding from LyX name \p name
+ Encoding const * getFromLyXName(std::string const name) const;
+ /// Get encoding from LaTeX name \p name
+ Encoding const * getFromLaTeXName(std::string const name) const;
///
Encoding const * symbol_encoding() { return symbol_encoding_; }
Index: src/buffer.C
===
--- src/buffer.C (Revision 15699)
+++ src/buffer.C (Arbeitskopie)
@@ -817,9 +817,20 @@ bool Buffer::makeLaTeXFile(string const
OutputParams const runparams,
bool output_preamble, bool output_body)
{
- string const encoding = (params().inputenc == auto) ?
- params().language-encoding()-iconvName() :
- encodings.getEncoding(params().inputenc)-iconvName();
+ string encoding;
+ if (params().inputenc == auto)
+ encoding = params().language-encoding()-iconvName();
+ else {
+ Encoding const * enc = encodings.getFromLaTeXName(params().inputenc);
+ if (enc)
+ encoding = enc-iconvName();
+ else {
+ lyxerr Unknown inputenc value `
+ params().inputenc
+ '. Using `auto' instead. endl;
+ encoding = params().language-encoding()-iconvName();
+ }
+ }
lyxerr[Debug::LATEX] makeLaTeXFile encoding:
encoding ... endl;
Index: src/language.C
===
--- src/language.C (Revision 15699)
+++ src/language.C (Arbeitskopie)
@@ -39,7 +39,7 @@ void Languages::read(string const file
{
// We need to set the encoding of latex_lang
latex_lang = Language(latex, latex, Latex, false, iso8859-1,
- encodings.getEncoding(iso8859-1),
+ encodings.getFromLyXName(iso8859-1),
latex, );
LyXLex lex(0, 0);
@@ -72,9 +72,9 @@ void Languages::read(string const file
if (lex.next())
latex_options = lex.getString();
- Encoding const * encoding = encodings.getEncoding(encoding_str);
+ Encoding const * encoding = encodings.getFromLyXName(encoding_str);
if (!encoding) {
- encoding = encodings.getEncoding(iso8859-1);
+ encoding = encodings.getFromLyXName(iso8859-1);
lyxerr Unknown encoding encoding_str endl;
}
Index: src/encoding.C
===
--- src/encoding.C (Revision 15699)
+++ src/encoding.C (Arbeitskopie)
@@ -224,15 +224,45 @@ char_type Encodings::transformChar(char_
}
-Encoding const * Encodings::getEncoding(string const encoding) const
+Encoding const * Encodings::getFromLyXName(string const name) const
{
- EncodingList::const_iterator it = encodinglist.find(encoding);
+ EncodingList::const_iterator it = encodinglist.find(name);
if (it != encodinglist.end())
return it-second;
else
return 0;
}
+
+namespace {
+
+class LaTeXNamesEqual : public std::unary_functionstd::pairstd::string, Encoding, bool {
+ public:
+ LaTeXNamesEqual(string const LaTeXName)
+ : LaTeXName_(LaTeXName) {}
+ bool operator()(std::pairstd::string, Encoding const encoding) const
+ {
+ return encoding.second.latexName() == LaTeXName_;
+ }
+ private:
+ string LaTeXName_;
+};
+
+} // namespace anon
+
+
+Encoding const * Encodings::getFromLaTeXName(string const name) const
+{
+ EncodingList::const_iterator const it =
+ std::find_if(encodinglist.begin(), encodinglist.end(),
+ LaTeXNamesEqual(name));
+ if (it != encodinglist.end())
+ return it-second;
+ else
+ return 0;
+}
+
+
Encodings::Encodings()
{
symbol_encoding_ = Encoding(symbol, , );
Re: Status: 3 hopeless showstoppers + more
Georg Baum wrote: José Matos wrote: On Thursday 02 November 2006 7:28 pm, Asger Ottar Alstrup wrote: - No UTF-8 support in LaTeX export. What needs to be done here? I would like to help fixing it. Any pointers? I explained it already at least two times but here we go again: - uncomment the utf8 line in lib/encodings - increase the file format number - write revert_inputenc in lyx2lyx that changes utf8 to auto. I just saw that I already implemented that for the general unicode conversion, so I enabled the utf8 encoding in lib/encodings. Georg
Re: Status: 3 hopeless showstoppers + more
Enrico Forestieri wrote: On Thu, Nov 02, 2006 at 07:51:07PM -0600, Bo Peng wrote: On Friday 03 November 2006 12:05 am, Enrico Forestieri wrote: I have used today, and now as I have double checked and it works for me... Really? When I select View source I only see a line % Preview source code for paragraph and nothing else. If I select Display complete source then it works. Maybe this is also a byproduct fix of the backing pixmap fix by Abdel? I still have to recompile with that applied. Works here for the latest revision. for paragraph should be followed by a paragraph number. Please provide more details: os, compiler, file loaded and I will also try to see what might have gone wrong. I see that it works on linux, so this must be specific to cygwin. Compiler is gcc and it happens with every file loaded. This must have to do with wide streams, but it is curious that it works for complete source. I fear that I'll have to have a look as I don't think that you have Qt4 for cygwin. However, this problem should also happen with a mingw build, but I think that nobody is using mingw these days... IMO, the fact that a free software project on Windows supports a closed source compiler and not gcc is kinda of peculiar... It's the other way around: a closed source compiler supports a free software project. Abdel.
Re: Namespace problems
Abdelrazak Younes wrote: I am afraid not many people use MSVC with scons these days. If you post your compile error someone could probably help though. Aren't you're a MSVC user as well? Or does it work fine with CMake? Out of curiosity Joost, don't you know C++? I just thought that everyone would be able to reproduce this. I'll try to fix it or I'll post the errors. Joost
Re: Status: 3 hopeless showstoppers + more
On Fri, Nov 03, 2006 at 11:41:13AM +0100, Abdelrazak Younes wrote: Enrico Forestieri wrote: On Thu, Nov 02, 2006 at 07:51:07PM -0600, Bo Peng wrote: On Friday 03 November 2006 12:05 am, Enrico Forestieri wrote: I have used today, and now as I have double checked and it works for me... Really? When I select View source I only see a line % Preview source code for paragraph and nothing else. If I select Display complete source then it works. Maybe this is also a byproduct fix of the backing pixmap fix by Abdel? I still have to recompile with that applied. Works here for the latest revision. for paragraph should be followed by a paragraph number. Please provide more details: os, compiler, file loaded and I will also try to see what might have gone wrong. I see that it works on linux, so this must be specific to cygwin. Compiler is gcc and it happens with every file loaded. This must have to do with wide streams, but it is curious that it works for complete source. I fear that I'll have to have a look as I don't think that you have Qt4 for cygwin. However, this problem should also happen with a mingw build, but I think that nobody is using mingw these days... IMO, the fact that a free software project on Windows supports a closed source compiler and not gcc is kinda of peculiar... It's the other way around: a closed source compiler supports a free software project. I didn't know you was a sophist... -- Enrico
Re: Namespace problems
Joost Verburg wrote: Abdelrazak Younes wrote: I am afraid not many people use MSVC with scons these days. If you post your compile error someone could probably help though. Aren't you're a MSVC user as well? yes. Or does it work fine with CMake? yes. Out of curiosity Joost, don't you know C++? I just thought that everyone would be able to reproduce this. I'll try to fix it or I'll post the errors. Good. Abdel.
Re: Status: 3 hopeless showstoppers + more
José Matos wrote: Thank you. Note that I still don't see utf-8 as an option for encoding in Document-Settings, what is missing? I forgot that in my list. See the FIXME in src/frontends/qt4/QDocumentDialog.C. Georg
Re: Status: 3 hopeless showstoppers + more
On Friday 03 November 2006 10:38 am, Georg Baum wrote: I just saw that I already implemented that for the general unicode conversion, so I enabled the utf8 encoding in lib/encodings. Thank you. Note that I still don't see utf-8 as an option for encoding in Document-Settings, what is missing? Georg -- José Abílio
Re: Status: 3 hopeless showstoppers + more
On Fri, Nov 03, 2006 at 11:56:43AM +0100, Enrico Forestieri wrote: On Fri, Nov 03, 2006 at 11:41:13AM +0100, Abdelrazak Younes wrote: Enrico Forestieri wrote: On Thu, Nov 02, 2006 at 07:51:07PM -0600, Bo Peng wrote: On Friday 03 November 2006 12:05 am, Enrico Forestieri wrote: I have used today, and now as I have double checked and it works for me... Really? When I select View source I only see a line % Preview source code for paragraph and nothing else. If I select Display complete source then it works. Maybe this is also a byproduct fix of the backing pixmap fix by Abdel? I still have to recompile with that applied. Works here for the latest revision. for paragraph should be followed by a paragraph number. Please provide more details: os, compiler, file loaded and I will also try to see what might have gone wrong. I see that it works on linux, so this must be specific to cygwin. Compiler is gcc and it happens with every file loaded. This must have to do with wide streams, but it is curious that it works for complete source. I fear that I'll have to have a look as I don't think that you have Qt4 for cygwin. However, this problem should also happen with a mingw build, but I think that nobody is using mingw these days... IMO, the fact that a free software project on Windows supports a closed source compiler and not gcc is kinda of peculiar... It's the other way around: a closed source compiler supports a free software project. I didn't know you was a sophist... s/was/were/ still have to get my coffee... -- Enrico
Re: [patch] new InsetCommandParams
Georg, I have updated your patch as you can see in the attachments. I
find this way easier. I think you will find it easier to review, too.
The draft documentations is also attached. I have written it
considering the new User Guide (UserGuideNV.lyx). Consider this as the
section 5.8.
And, don't worry, I am following the lyx-devel list. Altough, it is
difficult to read 30+ mails everyday :).
regards,
Ugras
Index: src/LyXAction.C
===
--- src/LyXAction.C (Revision 15688)
+++ src/LyXAction.C (Arbeitskopie)
@@ -366,6 +366,8 @@ void LyXAction::init()
{ LFUN_WINDOW_NEW, window-new, NoBuffer },
{ LFUN_WINDOW_CLOSE, window-close, NoBuffer },
{ LFUN_UNICODE_INSERT, unicode-insert, Noop },
+ { LFUN_NOMENCL_INSERT, nomencl-insert, Noop },
+ { LFUN_NOMENCL_PRINT, nomencl-print, Noop },
{ LFUN_NOACTION, , Noop }
};
Index: src/LaTeXFeatures.C
===
--- src/LaTeXFeatures.C (Revision 15688)
+++ src/LaTeXFeatures.C (Arbeitskopie)
@@ -386,6 +386,11 @@ string const LaTeXFeatures::getPackages(
if (isRequired(xy))
packages \\usepackage[all]{xy}\n;
+ if (isRequired(nomencl)) {
+ packages \\usepackage{nomencl}\n
+ \\makeglossary\n;
+ }
+
return packages.str();
}
Index: src/insets/insetnomencl.h
===
--- src/insets/insetnomencl.h (Revision 0)
+++ src/insets/insetnomencl.h (Revision 0)
@@ -0,0 +1,68 @@
+// -*- C++ -*-
+/**
+ * \file insetnomencl.h
+ * This file is part of LyX, the document processor.
+ * Licence details can be found in the file COPYING.
+ *
+ * \author O. U. BARAN (derived from Index counterpart of Lars Gullik Bjnnes. Thanks Lars)
+ *
+ * Full author contact details are available in file CREDITS.
+ */
+
+#ifndef INSET_NOMENCL_H
+#define INSET_NOMENCL_H
+
+
+#include insetcommand.h
+
+
+namespace lyx {
+
+class LaTeXFeatures;
+
+/** Used to insert notation labels
+ */
+class InsetNomencl : public InsetCommand {
+public:
+ ///
+ InsetNomencl(InsetCommandParams const );
+ ///
+ docstring const getScreenLabel(Buffer const ) const;
+ ///
+ EDITABLE editable() const { return IS_EDITABLE; }
+ ///
+ InsetBase::Code lyxCode() const;
+ ///
+ int docbook(Buffer const , odocstream ,
+ OutputParams const ) const;
+private:
+ virtual std::auto_ptrInsetBase doClone() const {
+ return std::auto_ptrInsetBase(new InsetNomencl(params()));
+ }
+};
+
+
+class InsetPrintNomencl : public InsetCommand {
+public:
+ ///
+ InsetPrintNomencl(InsetCommandParams const );
+ /// Updates needed features for this inset.
+ void validate(LaTeXFeatures features) const;
+ ///
+ EDITABLE editable() const { return NOT_EDITABLE; }
+ ///
+ InsetBase::Code lyxCode() const;
+ ///
+ bool display() const { return true; }
+ ///
+ docstring const getScreenLabel(Buffer const ) const;
+private:
+ virtual std::auto_ptrInsetBase doClone() const {
+ return std::auto_ptrInsetBase(new InsetPrintNomencl(params()));
+ }
+};
+
+
+} // namespace lyx
+
+#endif
Index: src/insets/insetbase.h
===
--- src/insets/insetbase.h (Revision 15688)
+++ src/insets/insetbase.h (Arbeitskopie)
@@ -322,7 +322,11 @@ public:
///
VSPACE_CODE,
///
- MATHMACROARG_CODE
+ MATHMACROARG_CODE,
+ ///
+ NOMENCL_CODE, // 45
+ ///
+ NOMENCL_PRINT_CODE
};
/** returns the Code corresponding to the \c name.
Index: src/insets/insetcommandparams.C
===
--- src/insets/insetcommandparams.C (Revision 15688)
+++ src/insets/insetcommandparams.C (Arbeitskopie)
@@ -109,14 +109,23 @@ InsetCommandParams::findInfo(std::string
return info;
}
- // InsetIndex, InsetPrintIndex, InsetLabel
- if (name == index || name == printindex || name == label) {
+ // InsetIndex, InsetPrintIndex, InsetLabel, InsetPrintNomencl
+ if (name == index || name == printindex || name == label ||
+ name == printglossary) {
static const char * const paramnames[] = {name, };
static const bool isoptional[] = {false};
static const CommandInfo info = {1, paramnames, isoptional};
return info;
}
+ // InsetNomencl
+ if (name == nomenclature) {
+ static const char * const paramnames[] = {sortas, name, explanation, };
+ static const bool isoptional[] = {true, false, false};
+ static const CommandInfo info = {3, paramnames, isoptional};
+ return info;
+ }
+
// InsetRef
if (name == eqref || name == pageref || name == vpageref ||
name == vref || name == prettyref || name == ref) {
Index: src/insets/insetnomencl.C
===
--- src/insets/insetnomencl.C (Revision 0)
+++ src/insets/insetnomencl.C (Revision 0)
@@ -0,0 +1,76 @@
+/**
+ * \file insetnomencl.C
+ * This file is part of LyX, the document processor.
+ * Licence details can be found in the file COPYING.
+ *
+ * \author O.
Re: Status: 3 hopeless showstoppers + more
On Friday 03 November 2006 11:00 am, Georg Baum wrote:
I forgot that in my list. See the FIXME in
src/frontends/qt4/QDocumentDialog.C.
I found it later with this comment:
// FIXME: This list is incomplete. It should not be hardcoded but come from
// the available encodings in src/encodings.C
// FIXME: default is no valid encoding anymore. Nevertheless it occurs also
// in other source files.
char const * encodings[] = { LaTeX default, latin1, latin2,
latin3, latin4, latin5, latin9,
koi8-r, koi8-u, cp866, cp1251,
iso88595, pt154, 0
};
Something for 1.6 no doubt. I will change it by hand now.
Georg
--
José Abílio
Re: New Mac Profile
Abdelrazak Younes wrote: Once you're done you could perhaps update Bennett's recipe for MacOSX? I am sure Peter (the author of the CMake support) would be happy to help you for any request you have. Hi Andreas, don't hesitate to ask me. I've tested the cmake build under linux and it compiles out of the box without problems. It would be great to also have a solid build system under MacOSX. Peter
Re: [patch] new InsetCommandParams
On 11/2/06, José Matos [EMAIL PROTECTED] wrote: On Thursday 02 November 2006 12:15 pm, Georg Baum wrote: Ozgur Ugras BARAN wrote: Oh, this is bad news, since I have almost completed the multiple indices stuff.. Do you have the code? :-) Yes I do.. At least 80% of it :)) I can finish it this weekend. You can be lucky that the nomencl stuff is allowed at all. It is not me who is lucky, but the users. I can't care less if nomencl support is in lyx 1.5, since I will not use it in near future. I have just used nomencl it in the past with lyx and it hurt a bit. With my code, I am just paying back to this great software. which I think I owe a lot. I am following the spirit of the law. If your code is small and self-contained I don't have a problem considering it. I am doing this since you have working in the list, you have announced it before, and showed some of it for comment. It is not that big. I will send the patch and you decide, whether it can go in or not. If it can not go in, we can put it in trunk after the release of 1.5. If for some reason it can be included then we should really focus on smaller development cycles, more focused. Agreed.. The only problem is handling the conversion scripts would be too difficult. But xml format can solve this problem, if it is designed well. We are in good shape for 1.6 since we have a target there, xml file format. A 6 month development cycle would be ideal. Georg -- José Abílio Ugras
RE: small reorganization of graphics dialog
From: José Matos [mailto:[EMAIL PROTECTED] If no one shouts until tomorrow you can put in. it is in: http://www.lyx.org/trac/changeset/15707 (would be nice if someone can try it out...)
citation dialog
Title: citation dialog the attached adds a toolbutton that clears the search box (and restores the full citation list): http://leuven.ecodip.net/lyx/cit.png ok to commit? cit.patch Description: cit.patch
Re: [patch] new InsetCommandParams
On Friday 03 November 2006 11:35 am, Ozgur Ugras BARAN wrote: It is not that big. I will send the patch and you decide, whether it can go in or not. If it can not go in, we can put it in trunk after the release of 1.5. Thank you. -- José Abílio
Re: small reorganization of graphics dialog
On Friday 03 November 2006 11:36 am, Leuven, E. wrote: (would be nice if someone can try it out...) It seems to work for me. I have tried to change an existing document and to insert a new figure. It worked in both cases. -- José Abílio
Re: Status: 3 hopeless showstoppers + more
OK, one useless question, should the lyx name be utf8 or utf-8? -- José Abílio
Re: Status: 3 hopeless showstoppers + more
On Friday 03 November 2006 12:09 pm, José Matos wrote: OK, one useless question, should the lyx name be utf8 or utf-8? Regardless I have committed the change that allows to export utf-8 encoding. -- José Abílio
[patch] fix math parser bug
A colleague of mine discovered a math parser bug that was introduced in 1.4.
The attached test file works fine in 1.3 but produces a LaTeX error in 1.4.
The reason is special treatment of things like {}_0 that was introduced in
1.4.
The attached patch (against 1.4) refines this treatment by testing for empty
braces. It works fine for me.
Jean-Marc, is this OK fot 1.4.4? I will commit to trunk later.
Georg
un-bug.lyx
Description: application/lyx
Index: src/mathed/math_parser.C
===
--- src/mathed/math_parser.C (Revision 15635)
+++ src/mathed/math_parser.C (Arbeitskopie)
@@ -814,9 +814,13 @@ void Parser::parse1(MathGridInset grid
cell-back() = MathAtom(new MathScriptInset(cell-back(), up));
MathScriptInset * p = cell-back().nucleus()-asScriptInset();
// special handling of {}-bases
+ // Test for empty brace inset, otherwise \xxx{\vec{H}}_{0}
+ // where \xxx is an unknown command gets misparsed to
+ // \xxx\vec{H}_{0}, and that is invalid LaTeX.
// is this always correct?
- if (p-nuc().size() == 1
- p-nuc().back()-asBraceInset())
+ if (p-nuc().size() == 1
+ p-nuc().back()-asBraceInset()
+ p-nuc().back()-asBraceInset()-cell(0).empty())
p-nuc() = p-nuc().back()-asNestInset()-cell(0);
parse(p-cell(p-idxOfScript(up)), FLAG_ITEM, mode);
if (limits) {
Re: Status: 3 hopeless showstoppers + more
José Matos wrote: OK, one useless question, should the lyx name be utf8 or utf-8? I don't care. I used utf8 because it was used in latex. I am not 100% sure whether the name is hardcoded somewhere, but I think it is only in lyx2lyx. Georg
Re: Namespace problems
Abdelrazak Younes wrote: I just thought that everyone would be able to reproduce this. I'll try to fix it or I'll post the errors. Good. I fixed the mkdir problem but still can't get tex2lyx to compile with SCons. It's somehow related to the Unicode conversion of the lyxerr output in support/package.C.in, but I don't see what's wrong. Does tex2lyx compilation work with CMake? Here is the error message: support.lib(package.obj) : error LNK2019: unresolved external symbol class std: :basic_stringunsigned long,struct std::char_traitsunsigned long,class std::al locatorunsigned long const __cdecl lyx::_(class std::basic_stringchar,struc t std::char_traitschar,class std::allocatorchar const ) ([EMAIL PROTECTED]@@YA?BV?$ [EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@2@@std@@[EMAIL PROTECTED] [EMAIL PROTECTED]@std@@[EMAIL PROTECTED]@2@@3@@Z) referenced in function bool __cdecl lyx::support::`anonymous namespace'::check_command_line_dir(class std::basic_st ringchar,struct std::char_traitschar,class std::allocatorchar const ,cla ss std::basic_stringchar,struct std::char_traitschar,class std::allocatorcha r const ,class std::basic_stringchar,struct std::char_traitschar,class st d::allocatorchar const ) ([EMAIL PROTECTED]@[EMAIL PROTECTED] @@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@2@@std@@[EMAIL PROTECTED]) release\common\tex2lyx\tex2lyx.exe : fatal error LNK1120: 1 unresolved externals Joost
Re: Status: 3 hopeless showstoppers + more
On Fri, 2006-11-03 at 10:58 +0100, Abdelrazak Younes wrote: Martin Vermeer wrote: - 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. I have now restored the backing pixmap. -dbg painting will print at the console which area is refreshed. Yes, this is a very good idea. Thanks. Note that we still are not where we should be (and where 1.4 is): still after every keypress, the whole screen will be refreshed in the second update step. The culprit appears to be the statement view()-buffer()-changed() in lyxfunc.C. This sends a signal LyXView to redraw the whole screen in WorkArea. There is no way to specify anything less than a full screen. Unfortunately commenting out this line isn't good either: then not even the current row gets updated (but it will be if you cover and expose theLyX window...) This should be redone somehow to do a current-paragraph update if Update::SinglePar is set. Can you do that with signal-slot? Yes, the signal can be emitted with any number of argument. Great! That's where I got stuck. So you reckon that a boolean (singlePar) should suffice? We just need to change the signal and the WorkArea::redraw() method to accept this boolean, very easy. You reckon this would be enough? Probably. I expect you would need to do a bit of tinkering around the above statement to get it working always right... but that's worth it. Abdel. - Martin signature.asc Description: This is a digitally signed message part
Re: Status: 3 hopeless showstoppers + more
Sorry... off to the summer cottage... other takers?
- Martin
On Fri, 2006-11-03 at 11:08 +0100, Abdelrazak Younes wrote:
Martin Vermeer wrote:
The culprit appears to be the statement
view()-buffer()-changed()
in lyxfunc.C. This sends a signal LyXView to redraw the whole screen in
WorkArea. There is no way to specify anything less than a full screen.
Unfortunately commenting out this line isn't good either: then not even
the current row gets updated (but it will be if you cover and expose
theLyX window...)
This should be redone somehow to do a current-paragraph update if
Update::SinglePar is set. Can you do that with signal-slot?
Here is a patch that does so. Please test and commit if it works.
Abdel.
plain text document attachment (singlePar_update.patch)
Index: buffer.h
===
--- buffer.h (revision 15694)
+++ buffer.h (working copy)
@@ -119,7 +119,7 @@
bool hasParWithID(int id) const;
/// This signal is emitted when the buffer is changed.
- boost::signalvoid() changed;
+ boost::signalvoid(bool) changed;
/// This signal is emitted when some parsing error shows up.
boost::signalvoid(std::string) errors;
/// This signal is emitted when some message shows up.
Index: frontends/LyXView.C
===
--- frontends/LyXView.C (revision 15694)
+++ frontends/LyXView.C (working copy)
@@ -169,7 +169,7 @@
bufferChangedConnection_ =
buf.changed.connect(
- boost::bind(WorkArea::redraw, work_area_));
+ boost::bind(WorkArea::redraw, work_area_, _1));
errorsConnection_ =
buf.errors.connect(
Index: frontends/WorkArea.C
===
--- frontends/WorkArea.C (revision 15694)
+++ frontends/WorkArea.C (working copy)
@@ -138,7 +138,7 @@
}
-void WorkArea::redraw()
+void WorkArea::redraw(bool singlePar)
{
if (!buffer_view_)
return;
@@ -148,7 +148,7 @@
return;
}
- buffer_view_-updateMetrics(false);
+ buffer_view_-updateMetrics(singlePar);
updateScrollbar();
Index: frontends/WorkArea.h
===
--- frontends/WorkArea.h (revision 15694)
+++ frontends/WorkArea.h (working copy)
@@ -80,7 +80,7 @@
virtual void setScrollbarParams(int height, int pos, int line_height) =
0;
/// redraw the screen, without using existing pixmap
- virtual void redraw();
+ virtual void redraw(bool singlePar = false);
///
void checkAndGreyOut();
///
Index: lyxfunc.C
===
--- lyxfunc.C (revision 15694)
+++ lyxfunc.C (working copy)
@@ -1723,7 +1723,7 @@
needSecondUpdate = view()-fitCursor();
if (needSecondUpdate || updateFlags != Update::None) {
- view()-buffer()-changed();
+ view()-buffer()-changed(updateFlags
Update::SinglePar);
}
lyx_view_-updateStatusBar();
signature.asc
Description: This is a digitally signed message part
Re: Status: 3 hopeless showstoppers + more
On Fri, 2006-11-03 at 11:28 +0100, Abdelrazak Younes wrote: Abdelrazak Younes wrote: Martin Vermeer wrote: The culprit appears to be the statement view()-buffer()-changed() in lyxfunc.C. This sends a signal LyXView to redraw the whole screen in WorkArea. There is no way to specify anything less than a full screen. Unfortunately commenting out this line isn't good either: then not even the current row gets updated (but it will be if you cover and expose theLyX window...) This should be redone somehow to do a current-paragraph update if Update::SinglePar is set. Can you do that with signal-slot? Here is a patch that does so. Please test and commit if it works. It seems to work. I have only one #. per inserted characters now. Will commit soon. Abdel. It appears that I have some beers at the summer cottage. Some of them will be going tonight in your honour. Abdel, my hero! A virtual one to you too. - Martin signature.asc Description: This is a digitally signed message part
Re: LyX 1.5 translations
Helge Hafting [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: | Helge Hafting [EMAIL PROTECTED] writes: | | | Michael Gerz wrote: | | Lars Gullik Bjønnes wrote: | | | | IMHO we should not merge translations from 1.4 at all. (or at most on | | a case by case basis. And if translators want it (I don't want it for | | NB f.ex.), msgmerge can be used for this.) | | | | Lars, I am a careful man :-) | | | | Right now, I am checking the state of the 1.4 and 1.5 translations | | on a case-by-case basis. If the 1.4 translations are better (for | | many languages they are significantly better!), I will remerge. | | Otherwise, I won't. | | | | I will put nb.po on my black list. | | Any particular problem with nb.po? Helge Hafting | | No. Only that it is missing translations and have a few fuzzy entries. | | I am working slowly on them help would be appreciated. | | I can look at it, like I did for 1.3. It should be simpler now, with | only one frontend. | Should I start with the nb.po that is in lyx1.5svn right now, or | should I wait | for some merge from 1.4? I am not planning any merge from 1.4 for nb.po. So IMHO you should just use what is in Ãlyx1.5svn right now. -- Lgb
RE: small reorganization of graphics dialog
José wrote: It seems to work for me. I have tried to change an existing document and to insert a new figure. It worked in both cases. thanks
Re: Status: 3 hopeless showstoppers + more
Abdelrazak Younes [EMAIL PROTECTED] writes: | Asger Ottar Alstrup wrote: | - 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. | | I could not resist, I fix that one also, I am a triple hero! you fixed the crash? not a,b or c? I think that at least c should be done. Such is life does not cut it as good enough for 1.5 imho. -- Lgb
Debug output - not wanted
People, when adding debug output please use the provided mechanisms so that all other do not have to see the messages. Currently trunk is close to untestable because of massive amounts of debug output. -- Lgb
Re: Namespace problems
I am afraid not many people use MSVC with scons these days. If you post your compile error someone could probably help though. Even if Joost is the only one to use scons/msvc, I am responsible for fixing it, if this is a scons problem. Bo
Re: Status: 3 hopeless showstoppers + more
Lars Gullik Bjønnes wrote: Abdelrazak Younes [EMAIL PROTECTED] writes: | Asger Ottar Alstrup wrote: | - 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. | | I could not resist, I fix that one also, I am a triple hero! you fixed the crash? Yes. not a,b or c? No. I think that at least c should be done. Such is life does not cut it as good enough for 1.5 imho. I don't care much. Abdel.
too much painting
when i click in the workarea (to put the cursor in another part of the text) the screen is repainted *twice* whereas it seems to me that no repainting is necessary at all there is also a lot of painting going on when selecting text: - when selecting a word the whole screen is repainted - the screen is repainted even when the selection does not change (moving the mouse with the left button pushed down always triggers a repaint) sorry for the noise if these are known issues ...
Re: Namespace problems
Bo Peng wrote: I am afraid not many people use MSVC with scons these days. If you post your compile error someone could probably help though. Even if Joost is the only one to use scons/msvc, I am responsible for fixing it, if this is a scons problem. The CMake system does not yet support all libraries. I need Aiksaurus support, external gettext etc. That's why I use SCons for the official Windows builds. It looks like this is a SCons problems, because CMake also compiles tex2lyx and Abdel reports that it works fine. Bo, could you try to compile tex2lyx with SCons? Joost
Re: too much painting
Leuven, E. wrote: when i click in the workarea (to put the cursor in another part of the text) the screen is repainted *twice* whereas it seems to me that no repainting is necessary at all there is also a lot of painting going on when selecting text: - when selecting a word the whole screen is repainted - the screen is repainted even when the selection does not change (moving the mouse with the left button pushed down always triggers a repaint) sorry for the noise if these are known issues ... The mouse events in GuiWorkArea should be reviewed to see whether there are superfluous calls to WorkArea::redraw(). Sorry, I dont'have to do that. Abdel.
Re: Namespace problems
Joost Verburg wrote: Bo Peng wrote: I am afraid not many people use MSVC with scons these days. If you post your compile error someone could probably help though. Even if Joost is the only one to use scons/msvc, I am responsible for fixing it, if this is a scons problem. The CMake system does not yet support all libraries. I need Aiksaurus support, external gettext etc. That's why I use SCons for the official Windows builds. It looks like this is a SCons problems, because CMake also compiles tex2lyx and Abdel reports that it works fine. Wait, I never said that. I never even tried to compile tex2lyx with CMake. Sorry for the confusion. Abdel.
Re: too much painting
Abdelrazak Younes wrote: Leuven, E. wrote: when i click in the workarea (to put the cursor in another part of the text) the screen is repainted *twice* whereas it seems to me that no repainting is necessary at all there is also a lot of painting going on when selecting text: - when selecting a word the whole screen is repainted - the screen is repainted even when the selection does not change (moving the mouse with the left button pushed down always triggers a repaint) sorry for the noise if these are known issues ... The mouse events in GuiWorkArea should be reviewed to see whether there are superfluous calls to WorkArea::redraw(). Sorry, I dont'have to do that. I dont'have _time_ to do that.
Re: Namespace problems
Bo Peng wrote: I am afraid not many people use MSVC with scons these days. If you post your compile error someone could probably help though. Even if Joost is the only one to use scons/msvc, I am responsible for fixing it, if this is a scons problem. Sure. Scons is still way ahead of CMake in terms of packaging, compile options, etc. I was just offering a hint as to why nobody saw this on MSVC. Abdel.
Re: Namespace problems
I fixed the mkdir problem but ... http://www.lyx.org/trac/changeset/15709 This is certainly not a scons problem. But why does cmake compile? If cmake does not detect HAVE_DIRECT_H, whcih mkdir it uses? Checking tex2lyx now. Bo
Re: Namespace problems
Bo Peng wrote: http://www.lyx.org/trac/changeset/15709 This is certainly not a scons problem. But why does cmake compile? If cmake does not detect HAVE_DIRECT_H, whcih mkdir it uses? I think CMake doesn't detect any mkdir at all, so it uses the API call. This is indeed unrelated to SCons. Thanks for checking tex2lyx. Joost
Re: small reorganization of graphics dialog
Am Freitag, 3. November 2006 14:44 schrieb Leuven, E.: José wrote: It seems to work for me. I have tried to change an existing document and to insert a new figure. It worked in both cases. Load a document with a figure which is _not_ displayed in lyx. Go to graphics dialog-Extra options Enable Show in LyX == OK button remains gray. Kornel -- Kornel Benko [EMAIL PROTECTED] pgpghqnlSLsVC.pgp Description: PGP signature
Re: Bug 2959: Can't modify document branches - and badness with non-ascii names
Helge Hafting wrote: I opened an existing document, went to document-settings-branches, and discovered: 1. I can't activate/deactivate the existing branch. The branch name is non-ascii. I can add a new one and activate/deactivate it, if the name is ascii. 2. Adding a new branch with a non-ascii name destroys the non-ascii characters in the name. I get a square instead. Clearly, the new branch entryfield and the list box uses different encodings! Maybe this explains (1) too. Such a branch cannot be removed either, while a branch with a ascii name is removeable. 3. I can't change branch colors at all - even if the name *is* ascii-only. I did not try 3. but the non-ascii problems should now be fixed. The reason was probably that several std::algorithms like find where used with utf8 strings, and that failed somewhere. A simple conversion of branch names to docstring solved the problem. There is still a problem with deactivating branches: It works by double clicking on the branch, but the button does only work for activating. Georg
1.5.0 on Mac
Here's an update on the status of 1.5.0 on Mac, with issues listed in rough order of importance. I'm trying to pick out issues that may be unique to Mac. 1. Speed is *much* improved. It could be better -- there seems to be a fraction of a second lag between when I press a key and when the letter appears on screen -- but the time lag doesn't obviously vary with the amount of text on the screen (as was the case previously). Right now, the speed of normal text entry makes LyX-1.5 usable on my not-fast-but-still-not-outdated computer. (Not sure how it would be on my slow-but-still-usable laptop.) 1a. Speed is still an issue typing in insets: noticeable lag between typing and text appearing on screen. This does not seem to be compounded by having nested insets, and it seems to be compounded only a little by the amount of text in the inset. (This is especially a problem in math environments.) 1b. Some operations that with 1.4 are pretty much instantaneous (inserting a footnote, dragging the mouse, switching to LyX from another application, opening dialogs, etc.) take quite a long time to complete in 1.5. (Shall I produce another profile? ... Of what circumstances? -- My recent profiles have just been of my typing in a window already full of text, but with no insets.) 2. Cursor is still not visible. 3. There are some drawing oddities -- lines occasionally overlapping vertically, math characters not properly aligned vertically. Not sure if anyone else has seen these, but I don't have the time now to determine if there's an obvious pattern. 4. Many issues with toolbars (most obvious of which are that icons are spaced too widely and that changes in the visibility of the toolbars with the GUI do not stick after the screen is redrawn). 5. Many issue with dialogs (most obviously: the Preferences dialog -- which can only be accessed now via keyboard command, not from the menu -- appears initially too small and must be resized; not possible to select buttons with the keyboard). 6. Some oddities with View menu: DVI does not appear in the menu, even though a converter and viewer are defined in Preferences. 7. Menu bar disappears (instead of being disabled) when dialogs appear. Let me know if you want more details on any of these. Bennett
RE: small reorganization of graphics dialog
Load a document with a figure which is _not_ displayed in lyx. Go to graphics dialog-Extra options Enable Show in LyX == OK button remains gray. thanks, will have a look...
LyX-1.5.0 on Mac: Crashes
LyX-1.5.0 on Mac reliably crashes in two situations: 1. On launch from GUI (by double-clicking on the LyX icon). As I reported before, this happens only when using the GUI; I can successfully start LyX from the Terminal, with or without gdb. Hence the only debug information I get is this, printed out in Console.app when I try launching from the GUI (note that the number changes everytime): Wrong command line option `-psn_0_182321153'. Exiting. 2. On quit. Here's the backtrace: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x65646f69 std::string::compare (this=0x65646f75, [EMAIL PROTECTED]) at /opt/ local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp orts_lang_gcc42/work/build/powerpc-apple-darwin8.8.0/libstdc++-v3/ include/bits/basic_string.h:595 595 /opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp orts_lang_gcc42/work/build/powerpc-apple-darwin8.8.0/libstdc++-v3/ include/bits/basic_string.h: No such file or directory. in /opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp orts_lang_gcc42/work/build/powerpc-apple-darwin8.8.0/libstdc++-v3/ include/bits/basic_string.h (gdb) bt #0 std::string::compare (this=0x65646f75, [EMAIL PROTECTED]) at /opt/ local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp orts_lang_gcc42/work/build/powerpc-apple-darwin8.8.0/libstdc++-v3/ include/bits/basic_string.h:595 #1 0x006052ec in std::operator char, std::char_traitschar, std::allocatorchar ([EMAIL PROTECTED], [EMAIL PROTECTED]) at /opt/ local/include/gcc42/c++/bits/stl_pair.h:2217 #2 0x0070421c in std::_Rb_treestd::string, std::pairstd::string const, boost::shared_ptrlyx::graphics::CacheItem , std::_Select1ststd::pairstd::string const, boost::shared_ptrlyx::graphics::CacheItem , std::lessstd::string, std::allocatorstd::pairstd::string const, boost::shared_ptrlyx::graphics::CacheItem ::find (this=0x11e8eb70, [EMAIL PROTECTED]) at /opt/local/include/gcc42/c++/ bits/stl_tree.h:1376 #3 0x007042c0 in std::mapstd::string, boost::shared_ptrlyx::graphics::CacheItem, std::lessstd::string, std::allocatorstd::pairstd::string const, boost::shared_ptrlyx::graphics::CacheItem ::find (this=0x11e8eb70, [EMAIL PROTECTED]) at /opt/local/include/gcc42/c++/ bits/stl_map.h:541 #4 0x002857d8 in lyx::graphics::Cache::remove (this=0xb8e248, [EMAIL PROTECTED]) at GraphicsCache.C:90 #5 0x00286744 in lyx::graphics::Loader::Impl::resetFile (this=0x11e1f670, [EMAIL PROTECTED]) at GraphicsLoader.C:223 #6 0x00286950 in lyx::graphics::Loader::Impl::~Impl (this=0x11e1f670) at GraphicsLoader.C:204 #7 0x00706188 in boost::checked_deletelyx::graphics::Loader::Impl (x=0x11e1f670) at ../../boost/boost/checked_delete.hpp:34 #8 0x0014c01c in lyx::graphics::PreviewImage::Impl::~Impl (this=0x140606c0) at PreviewImage.C:121 #9 0x006b1f80 in boost::checked_deletelyx::graphics::PreviewImage::Impl (x=0x140606c0) at ../../boost/boost/checked_delete.hpp:34 #10 0x006aeea4 in boost::checked_deletelyx::graphics::PreviewImage (x=0x11e4d8a0) at ../../boost/boost/checked_delete.hpp:34 #11 0x005fc478 in boost::detail::sp_counted_base::release (this=0x132a3db0) at ../boost/boost/detail/ sp_counted_base_gcc_ppc.hpp:153 #12 0x006ae044 in std::pairstd::string const, boost::shared_ptrlyx::graphics::PreviewImage ::~pair (this=0x1405efe0) at /opt/local/include/gcc42/c++/bits/stl_pair.h:69 #13 0x006ae32c in std::_Rb_treestd::string, std::pairstd::string const, boost::shared_ptrlyx::graphics::PreviewImage , std::_Select1ststd::pairstd::string const, boost::shared_ptrlyx::graphics::PreviewImage , std::lessstd::string, std::allocatorstd::pairstd::string const, boost::shared_ptrlyx::graphics::PreviewImage ::destroy_node (this=0x11e60e80, __p=0x1405efd0) at /opt/local/include/gcc42/c++/ bits/stl_tree.h:400 #14 0x006ae388 in std::_Rb_treestd::string, std::pairstd::string const, boost::shared_ptrlyx::graphics::PreviewImage , std::_Select1ststd::pairstd::string const, boost::shared_ptrlyx::graphics::PreviewImage , std::lessstd::string, std::allocatorstd::pairstd::string const, boost::shared_ptrlyx::graphics::PreviewImage ::_M_erase (this=0x11e60e80, __x=0x1405efd0) at /opt/local/include/gcc42/c++/ bits/stl_tree.h:1325 #15 0x006ae3c0 in std::_Rb_treestd::string, std::pairstd::string const, boost::shared_ptrlyx::graphics::PreviewImage , std::_Select1ststd::pairstd::string const, boost::shared_ptrlyx::graphics::PreviewImage , std::lessstd::string, std::allocatorstd::pairstd::string const, boost::shared_ptrlyx::graphics::PreviewImage ::~_Rb_tree (this=0x65646f75) at /opt/local/include/gcc42/c++/bits/stl_tree.h:592 #16 0x00141000 in lyx::graphics::PreviewLoader::Impl::~Impl
Re: 1.5.0 on Mac
Bennett Helm wrote: 3. There are some drawing oddities -- lines occasionally overlapping vertically, math characters not properly aligned vertically. Not sure if anyone else has seen these, but I don't have the time now to determine if there's an obvious pattern. This reminds me of a metrics debugger I did some time ago (see attached). I'll put it in, it can be activated by a line #define DEBUG_METRICS in rowpainter.C. This can be useful to test whether the metrics calculation is correct. 5. Many issue with dialogs (most obviously: the Preferences dialog -- which can only be accessed now via keyboard command, not from the menu -- appears initially too small and must be resized; not possible to select buttons with the keyboard). I see the too small size also on linux. The size is OK if you simply close it and reopen it again. Why can the size that is automatically computed for the second and further openings not be used for the first one? Georg
Re: 1.5.0 on Mac
Bennett Helm wrote:
3. There are some drawing oddities -- lines occasionally overlapping
vertically, math characters not properly aligned vertically. Not sure
if anyone else has seen these, but I don't have the time now to
determine if there's an obvious pattern.
This reminds me of a metrics debugger I wrote some time ago. I put this in
(does not change anything if DEBUG_METRICS is not defined), but this can be
very useful to track down metrics problems. Define DEBUG_METRICS and see
whether there is a pattern.
5. Many issue with dialogs (most obviously: the Preferences dialog --
which can only be accessed now via keyboard command, not from the
menu -- appears initially too small and must be resized; not possible
to select buttons with the keyboard).
The dialog is too small on linux, too, but only if you open it the first
time. Why can't the size that is used for the second and subsequent times
not be used for the first time?
GeorgIndex: src/rowpainter.C
===
--- src/rowpainter.C (Revision 15703)
+++ src/rowpainter.C (Arbeitskopie)
@@ -156,6 +156,11 @@ int RowPainter::leftMargin() const
}
+// If you want to debug inset metrics uncomment the following line:
+// #define DEBUG_METRICS
+// This draws green lines around each inset.
+
+
void RowPainter::paintInset(pos_type const pos, LyXFont const font)
{
InsetBase const * inset = par_.getInset(pos);
@@ -168,6 +173,9 @@ void RowPainter::paintInset(pos_type con
font;
pi.ltr_pos = (text_.bidi.level(pos) % 2 == 0);
pi.erased_ = erased_ || par_.isDeleted(pos);
+#ifdef DEBUG_METRICS
+ int const x1 = int(x_);
+#endif
bv_.coordCache().insets().add(inset, int(x_), yo_);
InsetText const * const in = inset-asTextInset();
// non-wide insets are painted completely. Recursive
@@ -181,6 +189,35 @@ void RowPainter::paintInset(pos_type con
inset-draw(pi, int(x_), yo_);
refreshInside = tmp;
x_ += inset-width();
+#ifdef DEBUG_METRICS
+ Dimension dim;
+ BOOST_ASSERT(text_.maxwidth_ 0);
+ int const w = text_.maxwidth_ - leftMargin() - text_.rightMargin(*bv_.buffer(), par_);
+ MetricsInfo mi(bv_, font, w);
+ inset-metrics(mi, dim);
+ if (inset-width() dim.wid)
+ lyxerr Error: inset to_ascii(inset-getInsetName())
+ draw width inset-width()
+ metrics width dim.wid . std::endl;
+ if (inset-ascent() dim.asc)
+ lyxerr Error: inset to_ascii(inset-getInsetName())
+ draw ascent inset-ascent()
+ metrics ascent dim.asc . std::endl;
+ if (inset-descent() dim.des)
+ lyxerr Error: inset to_ascii(inset-getInsetName())
+ draw ascent inset-descent()
+ metrics descent dim.des . std::endl;
+ BOOST_ASSERT(inset-width() = dim.wid);
+ BOOST_ASSERT(inset-ascent() = dim.asc);
+ BOOST_ASSERT(inset-descent() = dim.des);
+ int const x2 = x1 + dim.wid;
+ int const y1 = yo_ + dim.des;
+ int const y2 = yo_ - dim.asc;
+ pi.pain.line(x1, y1, x1, y2, LColor::green);
+ pi.pain.line(x1, y1, x2, y1, LColor::green);
+ pi.pain.line(x2, y1, x2, y2, LColor::green);
+ pi.pain.line(x1, y2, x2, y2, LColor::green);
+#endif
}
Re: 1.5.0 on Mac
On Friday 03 November 2006 3:25 pm, Bennett Helm wrote: 5. Many issue with dialogs (most obviously: the Preferences dialog -- which can only be accessed now via keyboard command, not from the menu -- appears initially too small and must be resized; not possible to select buttons with the keyboard). Regarding dialogs I get this on linux for some other dialogs as well. The document's settings is one of them. Trying to resize it a bit and I get a jump to the right size. -- José Abílio
RE: small reorganization of graphics dialog
Kornel wrote: Load a document with a figure which is _not_ displayed in lyx. Go to graphics dialog-Extra options Enable Show in LyX == OK button remains gray. should work now...
RE: Re: 1.5.0 on Mac
5. Many issue with dialogs (most obviously: the Preferences dialog -- which can only be accessed now via keyboard command, not from the menu -- appears initially too small and must be resized; not possible to select buttons with the keyboard). I see the too small size also on linux. The size is OK if you simply close it and reopen it again. Why can the size that is automatically computed for the second and further openings not be used for the first one? strange, i don't see this on my windows laptop. next week i'll be closer to my linux one and will try to investigate...
Re: LyX-1.5.0 on Mac: Crashes
Bennett Helm [EMAIL PROTECTED] writes: LyX-1.5.0 on Mac reliably crashes in two situations: 1. On launch from GUI (by double-clicking on the LyX icon). As I reported before, this happens only when using the GUI; I can successfully start LyX from the Terminal, with or without gdb. Hence the only debug information I get is this, printed out in Console.app when I try launching from the GUI (note that the number changes everytime): Wrong command line option `-psn_0_182321153'. Exiting. LyX must accept any option starting with '-psn' and pass it oon to the Qt initialisation. On Mac this gives the app a link to the Window system. Hm, I thought that was already in LyX... /Andreas
Re: mail size and attachments for the mailinglist
Georg Baum wrote: José Matos wrote: I did so I suppose the list got it. Certainly we are interested, I was expecting someone more knowledge to answer (Hello Georg, or Angus). :-) I got it, too, so the list definitely received it. I have not yet answered for the very same reason: not enough time. Georg Thanks for your replies, all i wanted to know is if the mail and attachment arrived at the list. bernhard
Re: small reorganization of graphics dialog
Am Freitag, 3. November 2006 17:34 schrieb Leuven, E.: Kornel wrote: Load a document with a figure which is _not_ displayed in lyx. Go to graphics dialog-Extra options Enable Show in LyX == OK button remains gray. should work now... confirmed. I like it. Kornel -- Kornel Benko [EMAIL PROTECTED] pgp6Rz5urfi2c.pgp Description: PGP signature
Re: Namespace problems
Checking tex2lyx now. This is caused by src/tex2lyx/gettext.h/C, which is not well patched for unicode. Trying to get a patch. Bo
[PATCH] full intl support for tex2lyx.
Hi, The reported scons/tex2lyx problem with msvc is caused by imcomplete intl/unicode support for tex2lyx. I have tested that if we remove src/tex2lyx/gettext.h/C and copy src/gettext.h/C and src/messages.h/C when compling tex2lyx, tex2lyx would compile under both linux and msvc. Any objection to this change? (Is there any reason we use a separate gettext.h/C in the first place?) Bo
Re: LyX 1.5 translations
Helge Hafting wrote: I am working slowly on them help would be appreciated. I can look at it, like I did for 1.3. It should be simpler now, with only one frontend. Should I start with the nb.po that is in lyx1.5svn right now, or should I wait for some merge from 1.4? I already merged with 1.4 where appropriate. However in case of nb.po, the trunk was already in a better state than 1.4. Basic line: All translators should use the po files from trunk. Michael
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
Bo Peng wrote: What is TabWidget? I will be satisfied with a split (vertical or horizontal) window option, even if there are at most two windows, and the split has to be half half. I agree. A split window would be fine. Michael
Toolbars
Bo, if I start LyX 1.5, the standard toolbar and the extra toolbar are shown. All other toolbars are invisible. However, if I look at ViewToolbars, all toolbars seem to be deactivated. If I click on ViewToolbarsStandard, nothing happens, no matter how often I try. Moreover, I cannot activate the minibuffer. Am too stupid or is the toolbar menu totally broken? Ahhh... wait... there is a localization problem! If I switch from German to English interface, everything works perfectly. I guess there is one _(...) to much in the code! Michael
Re: Toolbars
Michael Gerz wrote: Ahhh... wait... there is a localization problem! If I switch from German to English interface, everything works perfectly. I guess there is one _(...) to much in the code! Bo, this will probably not work (not related to the problem above): ./MenuBackend.C: docstring label = char_type(uppercase(cit-name[0])) + _(cit-name.substr(1)); You apply _(...) to a substring that is not defined in the po files. Beside that: Great work :-) I wish you nice holidays. You are a LyX hero! Michael
Re: Toolbars
Ahhh... wait... there is a localization problem! If I switch from German to English interface, everything works perfectly. I guess there is one _(...) to much in the code! I only have an English environment so I can not test. Anyway, maybe you can tell what goes wrong: 1. src/MenuBackend.C, line 771 docstring label = char_type(uppercase(cit-name[0])) + _(cit-name.substr(1)); 2. src/lyxfunc.C: line 362: argument is the menu item. flags = lyx_view_-getToolbarState(to_utf8(cmd.argument())); 3. src/lyxfunc.C: 1699 lyx_view_-toggleToolbarState(argument); 4. src/frontends/Toolbars.C: 132 ToolbarBackend::Flags Toolbars::getToolbarState(string const name) 5. src/frontends/Toolbars.C: 150 void Toolbars::toggleToolbarState(string const name) Bo
Re: [PATCH] full intl support for tex2lyx.
On Sat, Nov 04, 2006 at 12:27:48PM +1800, Bo Peng wrote: Hi, The reported scons/tex2lyx problem with msvc is caused by imcomplete intl/unicode support for tex2lyx. I have tested that if we remove src/tex2lyx/gettext.h/C and copy src/gettext.h/C and src/messages.h/C when compling tex2lyx, tex2lyx would compile under both linux and msvc. Any objection to this change? (Is there any reason we use a separate gettext.h/C in the first place?) I don't understand what the problem is. At least on *nix and cygwin tex2lyx seems working ok. -- Enrico
Re: Toolbars
./MenuBackend.C: docstring label = char_type(uppercase(cit-name[0])) + _(cit-name.substr(1)); You apply _(...) to a substring that is not defined in the po files. I guess the problem was: tomenu.add(MenuItem(MenuItem::Command, label, FuncRequest(LFUN_TOOLBAR_TOGGLE_STATE, _(cit-name; The last cit-name was _ed so a translated string is passed to LFUN_TOOLBAR_TOGGLE_STATE. Could you remove _() and test for me? The cit-name.substr(1) is indeed wrong. I guess docstring label = _(cit-name); label = char_type(label[0]) + label.substr(1); should work. Please also test. Beside that: Great work :-) I wish you nice holidays. You are a LyX hero! Thanks. I envied Abdel for his triple heros. :-) Bo
Re: [PATCH] full intl support for tex2lyx.
I don't understand what the problem is. At least on *nix and cygwin tex2lyx seems working ok. Compare src/tex2lyx/gettext.h and src/gettext.h tex2lyx still uses std::string const _(std::string) while lyx uses docstring const _(std::string) Therefore, tex2lyx uses the no-translation _(). and support/package.C.in uses a different gettext.h with translation. Then, there is a link problem. I do not have time to trace why gcc passes and the problem can be fixed by using tex2lyx/gettext.h for packages.C. However, I see no reason for a separate _() function for tex2lyx and propose that we remove tex2lyx/gettext.* and use the src/gettext.*. Bo
Re: Toolbars
Bo Peng wrote: ./MenuBackend.C: docstring label = char_type(uppercase(cit-name[0])) + _(cit-name.substr(1)); You apply _(...) to a substring that is not defined in the po files. I guess the problem was: tomenu.add(MenuItem(MenuItem::Command, label, FuncRequest(LFUN_TOOLBAR_TOGGLE_STATE, _(cit-name; The last cit-name was _ed so a translated string is passed to LFUN_TOOLBAR_TOGGLE_STATE. Could you remove _() and test for me? The cit-name.substr(1) is indeed wrong. I guess docstring label = _(cit-name); label = char_type(label[0]) + label.substr(1); should work. Please also test. Beside that: Great work :-) I wish you nice holidays. You are a LyX hero! Thanks. I envied Abdel for his triple heros. :-) I will be back in about an hour. You don't have to stay awake. I will check your bug fix proposal. If it works, I will just commit. Michael
Re: [PATCH] full intl support for tex2lyx.
On Sat, Nov 04, 2006 at 02:01:11PM +1800, Bo Peng wrote: I don't understand what the problem is. At least on *nix and cygwin tex2lyx seems working ok. Compare src/tex2lyx/gettext.h and src/gettext.h tex2lyx still uses std::string const _(std::string) while lyx uses docstring const _(std::string) Therefore, tex2lyx uses the no-translation _(). and support/package.C.in uses a different gettext.h with translation. Then, there is a link problem. I do not have time to trace why gcc passes and the problem can be fixed by using tex2lyx/gettext.h for packages.C. However, I see no reason for a separate _() function for tex2lyx and propose that we remove tex2lyx/gettext.* and use the src/gettext.*. If I understand it correctly, that funtion is a stub put there to not bring useless stuff in tex2lyx. I think that you can simply change std::string with docstring and be done. -- Enrico
Re: [PATCH] full intl support for tex2lyx.
If I understand it correctly, that funtion is a stub put there to not bring useless stuff in tex2lyx. I think that you can simply change std::string with docstring and be done. OK. this also works, but I really do not like the idea of a separate gettext.h. You know, it took me three hours to track down this simple problem because I missed the fact that there are two versions of gettext.h!! Sharing packages.C (and other supporting files) between tex2lyx and lyx is fine, but using different versions of gettext.h is, let me just say, wrong. I still propse that we get rid of tex2lyx/gettext. Bo
Re: Status: 3 hopeless showstoppers + more
Juergen Spitzmueller wrote: I think we could just take some from the KDE classic iconset, where the other icons are taken from IIRC. Like the attached, for instance. I committed the icons as xpm files. There is still one icon missing for note-next. Michael
Re: LyX localization (czech)
Pavel Sanda wrote: If appropriate, we took your translations from the 1.4.X stable branch such that your prior work didn't get lost. this was not good note ;) Don't worry, Pavel. In case of cs.po, I kept the 1.5 translations which were better than the 1.4 translations. 1. more menu items in english dont have their corresponding x character. (box,date,paste...) Yes. I put it on my todo list. 2. in older version dialogs get resized due to the size of the strings used inside the dialog. now it is no more (at least in preferences dialog) and some translated parts would be hard-to-decode for users. Yes, this is a nuissance. Some dialogs really look bad when they are opened for the first time. Box in menu should have Box... instead of Box No, the current format is correct (no ...). No dialog is opened here. 4. i tried to play with toc dialog, however, lyx always seqfaults (simply make few section, subsection, section; then add TOC before all section and click by the left button) I will check. 5. edit-text style-capitalize/lower/upper case either doesnt change anything for me. Confirmed, I broke it recently. (collision with change tracking) #: src/frontends/qt4/ui/FloatPlacementUi.ui:16 msgid Form #: src/frontends/qt4/ui/FontUi.ui:16 msgid FontUi #: lib/ui/stdtoolbars.ui:148 msgid review #: src/lengthcommon.C:39 msgid Line Width % (line in the sense of line of the table or row of text?) Edwin, could you help for the issues above? 7. there have been some patches for cs_*.lyx docs in 1.4. so the current version of docs in 1.4 should replace the docs in 1.5. Could you please help us? I guess nobody is able to understand Czech in the mailing list. in attachment i send the patch for the current cs.po. I will apply it at the weekend. Thanks for the comments! Michael
Bug report #1
Hello, just in case someone is interested in bug reports: please see the attached file. I think there is still a lot of work ahead of us... Michael Bugs (highest priority first): - Spell checking cannot be invoked a second time! - In the TOC dialog, switching between the different TOC types (TOC, Table, Float, etc.) is broken - Pavel: TOC crashes (simply make a few sections, subsections, sections; then add TOC before all sections and click on the left button) - If you open DocumentSettings... for the first time, the dialog is much too small to show its content; if you invoke it the second time, everything is fine - If you open EditTest Style... for the first time, the choice text for Never ToggledSize doesn't fit in the selection box (note that in German, texts are a bit longer than in English). Interestingly, if you invoke the dialog a second time, its button sizes are adjusted to their content. - In the math control panel, Detach panel is broken (only 1 button is visible in the detached panel) - In the math control panel, switching between different functions is broken (retry a couple of times) - edit-text style-capitalize/lower/upper case doesn't work due to the change tracking-related changes Polishing: - No icon for note-next in the review toolbar - In TOC, the buttons Up, Down, Promote, and Demote are not self-explaining. Why don't we group them in two pairs: Section Up/Down, Level Up/Down? The arrangement of the buttons may also give some hint to the user. - In the math control panel, there is no icon for Set Math Font - In the math control panel, the buttons are too small - In the Math Delimiters dialog, there is no need to repeat the term Size for all values in the selection box; the label is already named Size - some English menu items don't have a '' character. (box,date,paste...) - src/frontends/qt4/ui/QCitationUi.ui:70 Selected citations: should be Selected Citations:
LyX 1.5 bugs
Hi, I just compiled the current LyX 1.5svn on Windows. There are still many major bugs. Here are some things I noticed during the first few minutes of testing: * Performance is bad. On my system, scrolling the User Guide takes 10 seconds with LyX 1.4 and more than 30 seconds with LyX 1.5. Although I have a modern computer, it all feels very slow. * The multi-window thing is broken. When I have the same document in two windows, only the last selected paragraph in one of the windows gets updated. When I switch windows I get crashes all the time. * Spell checking is broken. The first time I run it an empty window is shown instead of the first misspelled word. After clicking a button I'm able to correct some words, but afterwards the spell checker will never run again. * Window positions are not remembered correctly. Each time I open a window again it has moved towards the bottom of the screen. Maybe the inner window position is applied to the outer window? * The visual table size selection on the the Insert Table dialog is gone. * Icons in the toolbars do not have the correct size, they are stretched a few pixels compared to 1.4. This makes the images look jagged and the initial window size has also become to small to show the whole toolbar. * Toolbars always show on the top of the screen, even though they are set to bottom in the ui file. * The initial size of Preferences window is too small. When I try to resize it the window jumps to the right size. * There should be a close button on the tabs. Joost
wiki is broken?
Hi, I tried to create a lyx 1.5.0 status wiki page that collects all bug reports (bugzilla is too cumbersome for this task at this stage), but get PmWiki can't process your request. Is wiki still working? Bo
How about a debugging spree?
Dear all, 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? Bo status.15x == Debugging spree: Rules: 1. bugs that aim for 1.5.0 should be listed here. 2. whoever fixes a bug sign his name before the bug and move it to the end of this file, along with a lyx-devel announcement. 3. we need to figure out a price for the champion (and second place). BUGS: - Spell checking cannot be invoked a second time! - In the TOC dialog, switching between the different TOC types (TOC, Table, Float, etc.) is broken - Pavel: TOC crashes (simply make a few sections, subsections, sections; then add TOC before all sections and click on the left button) - If you open DocumentSettings... for the first time, the dialog is much too small to show its content; if you invoke it the second time, everything is fine - If you open EditTest Style... for the first time, the choice text for Never ToggledSize doesn't fit in the selection box (note that in German, texts are a bit longer than in English). Interestingly, if you invoke the dialog a second time, its button sizes are adjusted to their content. - In the math control panel, Detach panel is broken (only 1 button is visible in the detached panel) - In the math control panel, switching between different functions is broken (retry a couple of times) - edit-text style-capitalize/lower/upper case doesn't work due to the change tracking-related changes Polishing: - No icon for note-next in the review toolbar - In TOC, the buttons Up, Down, Promote, and Demote are not self-explaining. Why don't we group them in two pairs: Section Up/Down, Level Up/Down? The arrangement of the buttons may also give some hint to the user. - In the math control panel, there is no icon for Set Math Font - In the math control panel, the buttons are too small - In the Math Delimiters dialog, there is no need to repeat the term Size for all values in the selection box; the label is already named Size - some English menu items don't have a '' character. (box,date,paste...) - src/frontends/qt4/ui/QCitationUi.ui:70 Selected citations: should be Selected Citations: * Performance is bad. On my system, scrolling the User Guide takes 10 seconds with LyX 1.4 and more than 30 seconds with LyX 1.5. Although I have a modern computer, it all feels very slow. * The multi-window thing is broken. When I have the same document in two windows, only the last selected paragraph in one of the windows gets updated. When I switch windows I get crashes all the time. * Spell checking is broken. The first time I run it an empty window is shown instead of the first misspelled word. After clicking a button I'm able to correct some words, but afterwards the spell checker will never run again. * Window positions are not remembered correctly. Each time I open a window again it has moved towards the bottom of the screen. Maybe the inner window position is applied to the outer window? * The visual table size selection on the the Insert Table dialog is gone. * Icons in the toolbars do not have the correct size, they are stretched a few pixels compared to 1.4. This makes the images look jagged and the initial window size has also become to small to show the whole toolbar. * Toolbars always show on the top of the screen, even though they are set to bottom in the ui file. * The initial size of Preferences window is too small. When I try to resize it the window jumps to the right size. * There should be a close button on the tabs. CREDITS:
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
Re: How about a debugging spree?
Bo Peng wrote: Dear all, 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? Agreed, I'll put this file in svn. * Performance is bad. On my system, scrolling the User Guide takes 10 seconds with LyX 1.4 and more than 30 seconds with LyX 1.5. Although I have a modern computer, it all feels very slow. FIXED: This was due to spurious message in QLPainter.C, I've put that in Debug::PAINTING, so 1.5 is faster than 1.4 on Windows XP on my 3 years old laptop (18s for the UserGuide test). * The multi-window thing is broken. When I have the same document in two windows, only the last selected paragraph in one of the windows gets updated. FIXED: This was due my singlePar optimization. With my last commit, the optimization is enabled only if the WorkArea has the focus. When I switch windows I get crashes all the time. Backtrace please, I don't see that, or it's very new. Abdel.
Re: How about a debugging spree?
Asger Ottar Alstrup wrote: 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. Yes, please continue to do that. 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. Most probably yes. Abdel.
Re: mail size and attachments for the mailinglist
José Matos wrote: > I did so I suppose the list got it. Certainly we are interested, I was > expecting someone more knowledge to answer (Hello Georg, or Angus). :-) I got it, too, so the list definitely received it. I have not yet answered for the very same reason: not enough time. Georg
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
Re: [Cvslog] r15605 - /lyx-devel/trunk/src/rowpainter.C
Andre Poenitz wrote: On Mon, Oct 30, 2006 at 11:12:41AM +0100, Abdelrazak Younes wrote: Andre Poenitz wrote: 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) I have implemented that and got rid of the NullPainter altogether: Did it make any difference speed-wise? I didn't noticed any improvement on Windows. But it could make a difference one day on Mac, maybe... Abdel.
Re: Status: 3 hopeless showstoppers + more
Martin Vermeer wrote: On Thu, Nov 02, 2006 at 08:50:45PM +, John Levon wrote: On Thu, Nov 02, 2006 at 08:28:45PM +0100, Asger Ottar Alstrup wrote: More bugs are being reported recently, and none of the old ones have been fixed. Thus, we are moving in the wrong direction. Or people have been doing some testing... regards john Agreed. This is what happens every time. And 1.5 hasn't been in any broad use yet... You mean every four years? Abdel.
Re: Status: 3 hopeless showstoppers + more
Enrico Forestieri wrote: On Fri, Nov 03, 2006 at 01:18:08AM +0100, Abdelrazak Younes wrote: Enrico Forestieri wrote: On Fri, Nov 03, 2006 at 12:07:56AM +, José Matos wrote: On Friday 03 November 2006 12:05 am, Enrico Forestieri wrote: Bo, View->Source seems currently broken. I don't know how much non-showstoppers are required to equal a showstopper but I think three should suffice, so you have your chance to enter the hall of fame ;-) What is broken? I have used today, and now as I have double checked and it works for me... Really? When I select "View source" I only see a line % Preview source code for paragraph and nothing else. If I select "Display complete source" then it works. Maybe this is also a byproduct fix of the backing pixmap fix by Abdel? Man, why are you all so eager to put the blame on me? :-) No, this has nothing to do with my pixmap fix. But maybe the following one has to do with it ;-) After File->Close I don't see the banner but still the document previously opened, even if it has actually been closed. This one is mine yes, should be easy to fix. Abdel.
Re: Bug 2960: Inserting an URL cause latex/pdflatex failure
On Thursday 02 November 2006 2:13 pm, Helge Hafting wrote:
> More lyx-1.5svn testing:
>
> Insert a URL into the document, fill in the URL field with
> http://www.free-firewall.org
>
> Try view->pdflatex or view->latex,
> get the error message
> "Undefined control sequence" \url{http://www.free-firewall.org}
I am sorry, I can not reproduce the bug.
The attached file works for me.
What document class are you using?
I looked to the latex output and it is correct, I don't see ant regression
when compared with 1.4
--
José Abílio
url-example.lyx
Description: application/lyx
Re: Namespace problems
Joost Verburg wrote: Hi, I'm not able to compile LyX 1.5svn anymore with MSVC 2005 on Windows now the namespaces have all been changed. Compilation of support/mkdir.C and tex2lyx/tex2lyx.C fails. Can someone take a look at this? I'm trying to make the Windows installer available for 1.5. I am afraid not many people use MSVC with scons these days. If you post your compile error someone could probably help though. Out of curiosity Joost, don't you know C++? Abdel.
Re: Status: 3 hopeless showstoppers + more
José Matos wrote: > On Thursday 02 November 2006 7:28 pm, Asger Ottar Alstrup wrote: >> - No UTF-8 support in LaTeX export. > > What needs to be done here? I would like to help fixing it. Any > pointers? I explained it already at least two times but here we go again: - uncomment the utf8 line in lib/encodings - increase the file format number - write revert_inputenc in lyx2lyx that changes utf8 to auto. - make sure that generate_encoding_info.py uses the encodings that are valid in 1.4, not the changed ones for conversion of the document contents to utf8. Since we can get it now for free it would be good to add all other encodings that are currently supported by inputenc at the same time. See also http://bugzilla.lyx.org/show_bug.cgi?id=2927 for a related problem. I don't understand at all why this is without hope. It takes a bit of time to implement and test, but is still easy compared to the other hopeless bugs. If you are lazy you can of course leave out the file format change, but since a reasonable conversion from utf8 to auto is possible I would do it. Georg
