Some bugs
Since I can't access bugzilla. I only tried for about 10 minutes so please don't think this is exhaustive. On the whole, the current CVS isn't too bad. A couple of bad assertions, but after a few of these are fixed, I think we can let Michael S loose. Massive improvement on last time... what have you lot been doing? :) 1. crash by new doc, insert comment, then repeatedly click on the button to open and close the inset, until you get: Assertion triggered in void LyXText::dispatch(LCursor&, FuncRequest&) by failing check "cur.text() == this" in file text3.C:361 2. the cursor is placed outside inset's red boundaries, this looks very confusing. I think we need to add a buffer to inset's dimensions 3. Button insets are still not centred. I think someone closed this bug. It needs re-opening. 4. control-X on selected text in a table cell cuts the whole cell instead of just the selection 5. Any text cut from a table cell is gone forever 6. I have to click exactly in the middle of an empty table to cell in order to place the cursor there. 7. selection progression in table cells is broken. After selecting all text in a cell, another 'Right' should select the cell itself, and only then the next cell to the right. There's no way to select a table cell with the keyboard right now. 8. (usability issue) - minipage is just way too hard to find. We might consider a submenu for 'Box' that has "Minipage", "Parbox", "Framed Box" etc. 9. A new ERT inset has a width of zero, this is near impossible to use. 10. Pasting a paragraph about 50 times (lots of control-Vs) gives: Assertion triggered in Point::Point(int, int) by failing check "y > -3000" in file coordcache.h:27 During this, the scrollbar is completely wrong. 11. Creating a new figure float, the 'Figure #:' of the caption is only seen on pressing return 12. Lars's on-screen translated things like 'Part' etc. are broken. I get 'Teil' in the DVI and not on screen. 13. Undo is missing out lots of edits. Try entering 1,2,3,4 in a table (one on each row of the table) then try to undo them. Generally broken in fact. 14. The footnote in the User Guide (first one) is inheriting the font from its containing paragraph. Not good ... 15. Right Address is (predictably enough) broken john
some bugs
1. Click on an inset to display the relevant dialog. 2. Change document. Dialog remains open. Clearly this is erroneous as insets and their dialogs are buffer dependent. Presumably the way to resolve this is to connect the inset->hide and hideBufferDependent signals? 2. I have two documents open with current cvs lyx. I'm not sure how, but one has footnotes displayed in the NEW_INSET style, whilst the other has them in old style. Isn't this impossible Trust me, it's here in front of me. (I did have NEW_INSETS enabled, but have turned that off and recompiled the whole code base to track down bugs for the 1.1.6 release.) 3. Open up a NEW_INSET footnote. It contains a reference inset. Clicking on this inset sometimes opens the dialog, sometimes doesn't, but always seems to highlight (mark) some surrounding text. Things work fine with the old code in this regard. 4. Insert->Cross reference launches the reference dialog, but the list of possible labels is not displayed. I'll have a look at this. Angus
Some bugs
Hi! I have found a few new bugs. Please have a look. Michael Place a paragraph that is aligned to the right and has a line above into a minipage -> the line is not drawn correctly (in order to observe this, there must be some text in front/after the minipage and the size of the minipage should be set to 50% of page width) In math mode, enter "a", "^", "_", "", "". The subscript of the superscript is deleted correctly but a small dot remains as the superscript of "a" on screen. Adding a column after the last column of a table still causes a freed memory access error! (Use "njamd", a fast memory checker, to check this) #0 0x080f522e in LyXTabular::AppendColumn (this=0x45b76f88, cell=0) at tabular.C:310 #1 0x0818378e in InsetTabular::tabularFeatures (this=0x446a6f70, bv=0x44796fec, feature=APPEND_COLUMN, value=@0xb254) at insettabular.C:1731 #2 0x081e95f6 in FormTabular::input (this=0x444d2f00, ob=0x46120f00) at FormTabular.C:558 #3 0x08210894 in FormBaseDeprecated::InputCB (ob=0x46120f00, data=0) at FormBaseDeprecated.C:212 #4 0x0820ff5e in C_FormBaseDeprecatedInputCB (ob=0x46120f00, d=0) at FormBaseDeprecated.C:54 ... This one should be really simple to fix; I guess it is just an out-of-bounds errors. * Insert one line of text into a note; delete the line and undo the deletion -> freed memory access error! #0 Paragraph::id (this=0x446b8fdc) at paragraph.C:2073 #1 0x0818feb4 in InsetText::getParFromID (this=0x460feef8, id=1) at insettext.C:2345 #2 0x08194264 in InsetCollapsable::getParFromID (this=0x460fee9c, id=1) at insetcollapsable.C:570 #3 0x080efc80 in Paragraph::Pimpl::getParFromID (this=0x45dbbfac, id=1) at paragraph_pimpl.C:539 #4 0x080ede8e in Paragraph::getParFromID (this=0x45cd1fdc, id=1) at paragraph.C:2165 #5 0x0809c555 in Buffer::getParFromID (this=0x45b4ae60, id=1) at buffer.C:3765 #6 0x0811dbe1 in LyXText::ownerParagraph (this=0x45cade70, id=1, p=0x447b0fdc) at text2.C:2595 #7 0x08121d5d in textHandleUndo (bv=0x44796fec, undo=0x4619afe4) at undo_funcs.C:151 #8 0x08121991 in textUndo (bv=0x44796fec) at undo_funcs.C:48 #9 0x080524e8 in BufferView::menuUndo (this=0x44796fec) at BufferView2.C:241 #10 0x080cafce in LyXFunc::dispatch (this=0x41909f7c, ac=16, do_not_use_this_arg=@0xbfffee98) at lyxfunc.C:827 -- === Michael Schmitt Telefon: +49 651 97551-40 Institut für TelematikTelefax: +49 651 97551-12 Bahnhofstrasse 30-32 WWW: http://www.ti.fhg.de D-54292 Trier E-Mail: mailto:[EMAIL PROTECTED] ===
Re: Some bugs
On Fri, Feb 11, 2005 at 01:11:24AM +, John Levon wrote: > Since I can't access bugzilla. I only tried for about 10 minutes so please I filed all these now. john
Re: Some bugs
On Fri, 2005-02-11 at 03:11, John Levon wrote:
> Since I can't access bugzilla. I only tried for about 10 minutes so please
> don't think this is exhaustive. On the whole, the current CVS isn't too bad. A
> couple of bad assertions, but after a few of these are fixed, I think we can
> let Michael S loose. Massive improvement on last time... what have you lot
> been
> doing? :)
>
> 1. crash by new doc, insert comment, then repeatedly click on the
>button to open and close the inset, until you get:
>
> Assertion triggered in void LyXText::dispatch(LCursor&, FuncRequest&) by
> failing check "cur.text() == this" in file text3.C:361
I get the same assertion in CVS of now, in the following way:
1) new document
2) insert math inset
3) inside math inset: insert text box (Control-M)
4) click inside this box.
The file created contains this:
\begin_inset Formula \[
\mbox{
\begin_layout Standard
\end_layout
}\]
\end_inset
Putting stuff inside the text box makes no difference. Clicking on it
crashes.
...
> john
- Martin
signature.asc
Description: This is a digitally signed message part
Re: Some bugs
On Mon, Feb 14, 2005 at 04:47:12PM +0200, Martin Vermeer wrote: > 1) new document > 2) insert math inset > 3) inside math inset: insert text box (Control-M) > 4) click inside this box. mbox is broken in many ways right now. Andre'
Re: Some bugs
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> 3. Button insets are still not centred. I think someone closed John> this bug. It needs re-opening. What do you mean by not centered? I can see that the include inset can behave in a very weird way if one use just after it, though. John> 8. (usability issue) - minipage is just way too hard to find. We John> might consider a submenu for 'Box' that has "Minipage", John> "Parbox", "Framed Box" etc. We used to have that, and I removed it... Is minipage such a useful beast to warrant menu bloat, apart from the fact that we are used to see it? John> 11. Creating a new figure float, the 'Figure #:' of the caption John> is only seen on pressing return I am not sure where this one comes from. John> 12. Lars's on-screen translated things like 'Part' etc. are John> broken. I get 'Teil' in the DVI and not on screen. As I commented in bugzilla, there are several solutions, but the core functionality works. John> 14. The footnote in the User Guide (first one) is inheriting the John> font from its containing paragraph. Not good ... Not good indeed. John> 15. Right Address is (predictably enough) broken I think the current behaviour is what we decided to be 'good enough'. What I would suggest is some nice drawing (but what?) in the margin suggesting that the text is as much on the right as possible. This dubious feature did not deserve the complicated code to support it. JMarc
Re: Some bugs
On Mon, Feb 21, 2005 at 06:47:15PM +0100, Jean-Marc Lasgouttes wrote: > John> 3. Button insets are still not centred. I think someone closed > John> this bug. It needs re-opening. > > What do you mean by not centered? I can see that the include inset can > behave in a very weird way if one use just after it, though. Physically on the screen: e.g. TOC button is not in the middle of the workarea. > John> 8. (usability issue) - minipage is just way too hard to find. We > John> might consider a submenu for 'Box' that has "Minipage", > John> "Parbox", "Framed Box" etc. > > We used to have that, and I removed it... Is minipage such a useful > beast to warrant menu bloat, apart from the fact that we are used to > see it? Well, personally I used minipage quite often, and from reports of users etc. it seems quite a lot of them do too. Maybe, it's not. > John> 15. Right Address is (predictably enough) broken > > I think the current behaviour is what we decided to be 'good enough'. > What I would suggest is some nice drawing (but what?) in the margin > suggesting that the text is as much on the right as possible. This > dubious feature did not deserve the complicated code to support it. I don't know, but I agree that the old right address code was a nightmare john
Re: some bugs
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> 2. I have two documents open with current cvs lyx. I'm not sure Angus> how, but one has footnotes displayed in the NEW_INSET style, Angus> whilst the other has them in old style. Isn't this Angus> impossible Trust me, it's here in front of me. (I did have Angus> NEW_INSETS enabled, but have turned that off and recompiled the Angus> whole code base to track down bugs for the 1.1.6 release.) If you opened a document with new_insets defined and then saved it, then it uses new insets for floats, even if you re-open it without new_insets (am I wrong?). JMarc
Re: some bugs
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: | | Angus> 2. I have two documents open with current cvs lyx. I'm not sure | Angus> how, but one has footnotes displayed in the NEW_INSET style, | Angus> whilst the other has them in old style. Isn't this | Angus> impossible Trust me, it's here in front of me. (I did have | Angus> NEW_INSETS enabled, but have turned that off and recompiled the | Angus> whole code base to track down bugs for the 1.1.6 release.) | | If you opened a document with new_insets defined and then saved it, | then it uses new insets for floats, even if you re-open it without | new_insets (am I wrong?). No, you are correct. Lgb
Re: Some bugs
On Fri, Dec 14, 2001 at 08:42:32AM +0100, Michael Schmitt wrote: > Place a paragraph that is aligned to the right and has a line above into > a minipage -> the line is not drawn correctly > (in order to observe this, there must be some text in front/after the > minipage and the size of the minipage should be set to 50% of page width) fix attached (thanks for the good report) regards john -- "Of all manifestations of power, restraint impresses the most." - Thucydides Index: src/ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v retrieving revision 1.457 diff -u -r1.457 ChangeLog --- src/ChangeLog 2001/12/12 12:07:38 1.457 +++ src/ChangeLog 2001/12/14 09:05:24 @@ -1,3 +1,7 @@ +2001-12-14 John Levon <[EMAIL PROTECTED]> + + * text.C: fix line above/below drawing in insets + 2001-12-12 Lars Gullik Bjønnes <[EMAIL PROTECTED]> * lyxlength.[Ch] (operator!=): new function Index: src/text.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v retrieving revision 1.213 diff -u -r1.213 text.C --- src/text.C 2001/12/12 09:56:00 1.213 +++ src/text.C 2001/12/14 09:05:33 @@ -,8 +,8 @@ y_top += asc; int const w = (inset_owner ? inset_owner->width(p.bv, font) : ww); - int const xp = static_cast(inset_owner ? p.x : 0); - p.pain->line(xp, p.yo + y_top, w, p.yo + y_top, + int const xp = static_cast(inset_owner ? p.xo : 0); + p.pain->line(xp, p.yo + y_top, xp + w, p.yo + y_top, LColor::topline, Painter::line_solid, Painter::line_thick); @@ -3493,9 +3493,9 @@ y_bottom -= asc; int const w = (inset_owner ? inset_owner->width(p.bv, font) : ww); - int const xp = static_cast(inset_owner ? p.x : 0); + int const xp = static_cast(inset_owner ? p.xo : 0); int const y = p.yo + y_bottom; - p.pain->line(xp, y, w, y, LColor::topline, Painter::line_solid, + p.pain->line(xp, y, xp + w, y, LColor::topline, Painter::line_solid, Painter::line_thick); y_bottom -= asc;
Re: Some bugs
On Fri, Dec 14, 2001 at 08:42:32AM +0100, Michael Schmitt wrote:
> Adding a column after the last column of a table still causes a freed
> memory access error! (Use "njamd", a fast memory checker, to check this)
well, this patch doesn't make njamd complain, and things still work.
I'm not proposing this as a fix because I can't be bothered to decipher
the code and check everything is OK ...
regards
john
Index: tabular.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/tabular.C,v
retrieving revision 1.107
diff -u -r1.107 tabular.C
--- tabular.C 2001/12/11 17:26:51 1.107
+++ tabular.C 2001/12/14 09:20:31
@@ -307,12 +307,12 @@
c_info[i][j] = cell_info[i][j - 1];
}
// care about multicolumns
- if (cell_info[i][column + 1].multicolumn==CELL_BEGIN_OF_MULTICOLUMN) {
- cell_info[i][column + 1].multicolumn =
CELL_PART_OF_MULTICOLUMN;
+ if (c_info[i][column + 1].multicolumn==CELL_BEGIN_OF_MULTICOLUMN) {
+ c_info[i][column + 1].multicolumn = CELL_PART_OF_MULTICOLUMN;
}
if ((column + 1) == columns_ ||
- cell_info[i][column + 2].multicolumn !=
CELL_PART_OF_MULTICOLUMN) {
- cell_info[i][column + 1].multicolumn = LyXTabular::CELL_NORMAL;
+ c_info[i][column + 2].multicolumn != CELL_PART_OF_MULTICOLUMN)
+{
+ c_info[i][column + 1].multicolumn = LyXTabular::CELL_NORMAL;
}
}
cell_info = c_info;
--
"Of all manifestations of power, restraint impresses the most."
- Thucydides
RE: Some bugs
On 14-Dec-2001 Michael Schmitt wrote: > Insert one line of text into a note; delete the line and undo the > deletion -> freed memory access error! > >#0 Paragraph::id (this=0x446b8fdc) at paragraph.C:2073 >#1 0x0818feb4 in InsetText::getParFromID (this=0x460feef8, id=1) This is a stupid error of myself in InsetText::paragraph(Paragraph *), as the code I put there to delete the paragraphs is WRONG! I fixed this already here a few days ago but wanted to finish the whole undo/redo fix stuff before commiting. But it seems it is better to commit often also half backed stuff as otherwise one will have to loose a lot of time solving conflicts, so most probably I will commit the whole stuff soon also if I didn't finish it and it still has some problems! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Drop that pickle!
Re: Some bugs
On Fri, Dec 14, 2001 at 11:56:40AM +0100, Juergen Vigna wrote: > fix stuff before commiting. But it seems it is better to commit often > also half backed stuff as otherwise one will have to loose a lot of time > solving conflicts, so most probably I will commit the whole stuff soon > also if I didn't finish it and it still has some problems! that's 3 times today already ! I know it's friday, but I'm sure JMarc and Andre are very sorry now ... you could have just backed out their changes you know., regards john -- "Of all manifestations of power, restraint impresses the most." - Thucydides
Re: Some bugs
On 14-Dec-2001 John Levon wrote: > that's 3 times today already ! I know it's friday, but I'm sure JMarc and Andre are Only 3 times that far to few! And I don't think they need you as their advocate it seems they have attained full age some time ago! They were at least so intelligent to not answer my whines! > very sorry now ... I really hope so! > you could have just backed out their changes you know., Could I?! I'll comit soon anyway! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The rule on staying alive as a program manager is to give 'em a number or give 'em a date, but never give 'em both at once.
Re: Some bugs
On Fri, Dec 14, 2001 at 11:56:40AM +0100, Juergen Vigna wrote: > But it seems it is better to commit often also half backed stuff as > otherwise one will have to loose a lot of time solving conflicts, so most > probably I will commit the whole stuff soon also if I didn't finish it > and it still has some problems! I promise not to touch undo/redo until January. Does that sound ok? Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: Some bugs
On 14-Dec-2001 Juergen Vigna wrote: >> you could have just backed out their changes you know., > > Could I?! I'll comit soon anyway! And why should I back out a change which caused only one little conflict I fixed in about 5 secs! You all are responsilbe if I spend more time sending stupid mails then fixing real bugs! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ How can you think and hit at the same time? -- Yogi Berra
Re: Some bugs
On 14-Dec-2001 Andre Poenitz wrote: > On Fri, Dec 14, 2001 at 11:56:40AM +0100, Juergen Vigna wrote: >> But it seems it is better to commit often also half backed stuff as >> otherwise one will have to loose a lot of time solving conflicts, so most >> probably I will commit the whole stuff soon also if I didn't finish it >> and it still has some problems! > > I promise not to touch undo/redo until January. > > Does that sound ok? No that doesn't sound ok! Work on that code fix remaining bugs and send me the patches! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ I/O, I/O, It's off to disk I go, A bit or byte to read or write, I/O, I/O, I/O...
Re: Some bugs
On Fri, Dec 14, 2001 at 12:14:50PM +0100, Juergen Vigna wrote: > And why should I back out a change which caused only one little > conflict I fixed in about 5 secs! You all are responsilbe if I > spend more time sending stupid mails then fixing real bugs! first you hurt me , then you make me laugh ... is there no end ??? oh, and ben says you all suck for not applying his mmap deptable patch [1] john [1] not really - "Of all manifestations of power, restraint impresses the most." - Thucydides
Re: Some bugs
On 14-Dec-2001 John Levon wrote: > On Fri, Dec 14, 2001 at 12:14:50PM +0100, Juergen Vigna wrote: > >> And why should I back out a change which caused only one little >> conflict I fixed in about 5 secs! You all are responsilbe if I >> spend more time sending stupid mails then fixing real bugs! > > first you hurt me , then you make me laugh ... is there no end ??? Well I guess there's always a Saturday after a Friday, but for myself you have to wait till Monday as on weekends I tend to not go too near a computer. > oh, and ben says you all suck for not applying his mmap deptable patch [1] Well I have to agree and not only because of not applying a patch and most of all Asger who is only there to tell us some wise words without effectively doing anything. Also on meetings he drinks a lot of beer, hacks into the code a lot of bugs, lies drunken in places he's not supposed to and really thinks he will get away with it just not posting mails on Fridays, but today you got what you deserve! Jug P.S.: Did I tell you that I didn't sleep well tonight cause Kai had a bit of fever and held me awake most of the time. P.P.S.: In a second thought I added the Cc: to Asger so he'll not loose todays wisdoms! -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ "Is this foreplay?" "No, this is Nuke Strike. Foreplay has lousy graphics. Beat me again." -- Duckert, in "Bad Rubber," Albedo #0 (comics)
Re: Some bugs
On Fri, 14 Dec 2001, Juergen Vigna wrote: [Blah, blah, blah, blah, blah] So, when and where is the next LyX developer's meeting going to be held? It seems Juergen needs some fun to lighten up. He could sure need to drink some beer, introduce a bunch of bugs in the code, and sleep in forbidden places. Greets, Asger
Re: Some bugs
On 17-Dec-2001 Lars Gullik Bjønnes wrote: >| So, when and where is the next LyX developer's meeting going to be held? > > Hey!! We never decide that until after New Years. Well if you both wouldn't had drunken that much on the last meeting you probably should know that we already have a volunteer in the west of Europe near the Atlantic Ocean ;) >| It seems Juergen needs some fun to lighten up. He could sure need to drink >| some beer, introduce a bunch of bugs in the code, and sleep in forbidden >| places. You know it's hard for me, my code doesn't have bugs! > Yes... he is really only a copy cat. (and we should give him the > opportunity to play it out.) ??? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Winter is the season in which people try to keep the house as warm as it was in the summer, when they complained about the heat.
Re: Some bugs
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> On Fri, Dec 14, 2001 at 08:42:32AM +0100, Michael Schmitt wrote: >> Place a paragraph that is aligned to the right and has a line above >> into a minipage -> the line is not drawn correctly (in order to >> observe this, there must be some text in front/after the minipage >> and the size of the minipage should be set to 50% of page width) John> fix attached (thanks for the good report) Applied (in my tree). JMarc
LyX 2.0 - some bugs
In this mail I've collected all the bugs with LyX 2.0beta1 I've spotted so far. Overall, the experience has been very pleasant, but there are some glitches worth correcting. My platform is (for now) Win XP SP3 Polish. If something is unclear, please ask - I'm writing this in a hurry, hoping that it will help developing LyX further anyway. Also, most of these bugs seems small to me. If the need arises, I can file individual tickets, but I hope it won't be neccessary. [BUG #1] Branch insets "override" all the rmb menus, so for example the user cannot spellcheck single word inside the branch inset via rmb anymore. This makes working with branches a whole lot harder. [BUG #2] In LyX 1.6.x, after toggling particular branch from the document properties, all the related insets were opened/closed. That was very convenient and saved a lot of my time, as I'm using branches (sometimes even nested ones) and heavily depend on these. This behaviour is no longer present in LyX 2.0beta1. I'm not 100% sure whether it is a feature or a bug, but if it is the former, maybe adding an option to rmb menu to "open all/close all" insets of the particular branch would be useful instead? [BUG #3] I cannot add words with special (national) characters to the personal dictionary - the request seems to be simply ignored by LyX. This has been tested with the default aspell engine. [BUG #4] I'm not entirely sure, but isn't "private" dictionary cleaned after restarting/reloading LyX? Considering the discussion on lyx-devel that I've seen some time ago, this might be the result of some other aspell-related bug. [BUG #5] The dotted line used to mark misspelled words is almost invisible (under some conditions). Is the color/thickness of the line configurable? [BUG #6] Document settings cannot be reverted via "undo". Or is it by design? [BUG #7] It would be nice if under win32 LyX automatically searched for thesaurus files inside the already installed OpenOffice / LibreOffice / GoOO / ... directories. That way LyX would be much more useful by default. [BUG #8] Previewing PDFs with Adobe Acrobat 9 isn't "seamless" - it gives some error message. I don't rememer exact message, as I've recently upgraded to Acrobat Reader 10. There, it is a total failure - the previewed document doesn't even open, only the reader's window appears. Switching to other viewer fixed the problem. AFAIK, "pdfview.exe" treats Acrobat differently, so this bug is probably related to it. [BUG #9] This bug dates back to bug #3949, which is marked as a duplicate of bug #3962, which in turn is marked as fixed. Still, after installing Scientific Workplace 5.0 and the LyX 2.0beta1, greek letters in math mode are not displayed correctly. The reason is probably correctly explained in #3949, but for me it still looks like not solved. I'm not using SWP myself, but I'm in the process of convincing someone else to LyX :) Regards, Michał Skrzypek
paste & paragraphs and some bugs
Is there a special reason why the layout of the first (pasted) paragraph is
not kept when pasting? Most of the time I find this annyoing (e.g. when I try
to cut'n'paste a quotation).
Two bugs. Create a document with 5 pars:
one
two
three
four
five
(1.) select paragraph 2 and 3 ("two three"), cut -> crash
(2.) select par 2 and 3, copy, insert a new paragraph between four and five,
hit paste and look: "two" is pasted between four and five (as it should) but
"three" is pasted at the end of the document, preceeded by a blank line.
Juergen.
po-Patches, plus some bugs...
Hi Folks,
as promised, I took some time to look through the german po-files.
Attached are 2 patches for de.po and de_menus.bind.
They are against 1.1.4pre1.
Furthermore I found 2 (minor) glitches:
- The ballon tool tips are not translated. I'm not sure wether this
has ever since been the case, but i thought they have been at some
point...
- When using a different keymap table (in my case german):
The umlauts (ä,ö etc.) show up quite strange (like painted by LyX
itself, not using the font), the sharp s (ß) is written as \{ss}
(*not* in TeX-Mode!).
Also, the german keyboard table needs the AltGr key for some
characters (namely |,\, and @); This seems not to be supported by
that map.
Sorry if those already have been reported - I'm only following the list
very loosely.
Cheers,
Pit
--
~~
Dr. Peter "Pit" Suetterlin http://www.astro.uu.nl/~suetter
Sterrenkundig Instituut Utrecht
Tel.: +31 (0)30 253 5225 [EMAIL PROTECTED]
__
de_menus.diff.gz
de.po.diff.gz
Re: LyX 2.0 - some bugs
> From: Michal > Sent: Sun, 28 November, 2010 3:00:59 > Subject: LyX 2.0 - some bugs > > [BUG #1] > Branch insets "override" all the rmb menus, so for example the user > cannot spellcheck single word inside the branch inset via rmb anymore. > This makes working with branches a whole lot harder. > This is a general problem with LyX right click menus, both in 2.0 and 1.6: as soon as context-specific items are defined, they erase the default ones, rather than adding to them. For instance, there isn't even cut/copy/paste in note, math or character style insets. I agree it would be great if this were changed.
Re: LyX 2.0 - some bugs
Michal wrote: > In this mail I've collected all the bugs with LyX 2.0beta1 I've > spotted so far. Overall, the experience has been very pleasant, but > there are some glitches worth correcting. My platform is (for now) Win > XP SP3 Polish. > > If something is unclear, please ask - I'm writing this in a hurry, > hoping that it will help developing LyX further anyway. Michal, thanks for your feedback. you reported however too many bugs to deal with them directly in this list. please push them into bugzilla so we can deal each of them individually. thanks, pavel
Re: LyX 2.0 - some bugs
On Sun, 28 Nov 2010 19:28:56 + (GMT) Jim Oldfield wrote: > > [BUG #1] > > [...] > This is a general problem with LyX right click menus, both in 2.0 and > 1.6: as soon as context-specific items are defined, they erase the > default ones, rather than adding to them. For instance, there isn't > even cut/copy/paste in note, math or character style insets. I agree > it would be great if this were changed. Yes, I agree, this is a general problem. However, this bug is more specific and so it does NOT occur in LyX 1.6.8 - rmb menu inside a branch is the same as the outside one there. While fixing the general problem would be nice, the problem mentioned there is, the way I see it, more urgent, but also seems easier to fix. Michał Skrzypek
Re: LyX 2.0 - some bugs
On Sun, 28 Nov 2010 21:15:44 +0100 Pavel Sanda wrote: > [...] > Michal, thanks for your feedback. you reported however too many bugs > to deal with them directly in this list. please push them into > bugzilla so we can deal each of them individually. I kind of hoped that at least some of the bugs are simple enough to disappear after just mentioning them :) Reporting 9 bugs on bugzilla seems like a time-consuming task, so I can't promise anything, but I'll try, probably in a few days. Thank you, Michał Skrzypek
Re: LyX 2.0 - some bugs
Am 29.11.2010 um 04:26 schrieb Michal: > On Sun, 28 Nov 2010 21:15:44 +0100 > Pavel Sanda wrote: >> [...] >> Michal, thanks for your feedback. you reported however too many bugs >> to deal with them directly in this list. please push them into >> bugzilla so we can deal each of them individually. >I kind of hoped that at least some of the bugs are simple enough to > disappear after just mentioning them :) > >Reporting 9 bugs on bugzilla seems like a time-consuming task, so I > can't promise anything, but I'll try, probably in a few days. I don't want to be offending. But honestly, fixing bugs is a time-consuming task too. And I've not seen any bug disappearing by mentioning. Some bugs are resorting when the sun light is raising... ...but I've not heard of it about software bugs. :-) Stephan
Re: LyX 2.0 - some bugs
On Mon, Nov 29, 2010 at 8:40 AM, Stephan Witt wrote: >> Reporting 9 bugs on bugzilla seems like a time-consuming task, so I >> can't promise anything, but I'll try, probably in a few days. > > I don't want to be offending. > > But honestly, fixing bugs is a time-consuming task too. > And I've not seen any bug disappearing by mentioning. > Some bugs are resorting when the sun light is raising... > ...but I've not heard of it about software bugs. :-) > To continue the digression.. Some people consider reporting bugs as a form of contributing to an open-source project (and it is, if whining is avoided), so take it as our---non-programmers---chance to shine. ;) Regards Liviu > Stephan > > -- Do you know how to read? http://www.alienetworks.com/srtest.cfm http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader Do you know how to write? http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail
Re: LyX 2.0 - some bugs
> I don't want to be offending. > > But honestly, fixing bugs is a time-consuming task too. > And I've not seen any bug disappearing by mentioning. > Some bugs are resorting when the sun light is raising... > ...but I've not heard of it about software bugs. :-) You don't want to be offending, so what is your point? Everyone there seems to be short on time (including me). It's all obvious. I'm just guessing there, but maybe it is your way then to suggest that it is me being offending? Well, just in case: I was merely stating the facts, explaining the inevitable delay. It won't do any better if I'd just disappeared for a week without a word, would it? So here I am, explaining everything about why I have explained everything :) As for disappearing - some bugs do 'disappear' in a sense, that merely mentioning their existence gives a developer enough clue about exactly which missing semicolon is the whole reason of a problem... I tend to agree though, that it is kind of a rare luxury in a bug-squashing profession :) Regards, Michał Skrzypek
Re: LyX 2.0 - some bugs
Am 29.11.2010 um 12:42 schrieb Michal: >> I don't want to be offending. >> >> But honestly, fixing bugs is a time-consuming task too. >> And I've not seen any bug disappearing by mentioning. >> Some bugs are resorting when the sun light is raising... >> ...but I've not heard of it about software bugs. :-) >You don't want to be offending, so what is your point? Everyone > there seems to be short on time (including me). It's all obvious. > >I'm just guessing there, but maybe it is your way then to suggest > that it is me being offending? Well, just in case: I was merely stating > the facts, explaining the inevitable delay. It won't do any better if > I'd just disappeared for a week without a word, would it? So here I am, > explaining everything about why I have explained everything :) I have to admit I think it costs not much time to report a bug in LyX's bug tracker. Fortunately, it's not bugzilla. :-) And some of the bugs you reported are easier to fix with example files. Regards, Stephan
Re: LyX 2.0 - some bugs
2010/11/28 Michal : > In this mail I've collected all the bugs with LyX 2.0beta1 I've > spotted so far. Overall, the experience has been very pleasant, but > there are some glitches worth correcting. My platform is (for now) Win > XP SP3 Polish. > > If something is unclear, please ask - I'm writing this in a hurry, > hoping that it will help developing LyX further anyway. > > Also, most of these bugs seems small to me. If the need arises, I > can file individual tickets, but I hope it won't be neccessary. > > [BUG #1] > Branch insets "override" all the rmb menus, so for example the user > cannot spellcheck single word inside the branch inset via rmb anymore. > This makes working with branches a whole lot harder. This was bug http://www.lyx.org/trac/ticket/6642. Now fixed in r36604--r36609. > [BUG #2] > In LyX 1.6.x, after toggling particular branch from the document > properties, all the related insets were opened/closed. That was very > convenient and saved a lot of my time, as I'm using branches (sometimes > even nested ones) and heavily depend on these. This behaviour is no > longer present in LyX 2.0beta1. > > I'm not 100% sure whether it is a feature or a bug, but if it is > the former, maybe adding an option to rmb menu to "open all/close all" > insets of the particular branch would be useful instead? Fixed at r36610. > > [BUG #3] > I cannot add words with special (national) characters to the > personal dictionary - the request seems to be simply ignored by LyX. > This has been tested with the default aspell engine. This looks like bug: http://www.lyx.org/trac/ticket/7043. > > [BUG #4] > I'm not entirely sure, but isn't "private" dictionary cleaned after > restarting/reloading LyX? Considering the discussion on lyx-devel that > I've seen some time ago, this might be the result of some other > aspell-related bug. Indeed. > > [BUG #5] > The dotted line used to mark misspelled words is almost invisible > (under some conditions). Is the color/thickness of the line > configurable? > No, this is hardcoded. Under which conditions is it almost invisible ? I fixed the fact that the color was hardcoded in r36612. > [BUG #6] > Document settings cannot be reverted via "undo". Or is it by design? That might be by design. It's rather unwanted that settings are undone and the user doesn't see this happen. Vincent
Re: LyX 2.0 - some bugs
Vincent van Ravesteijn wrote: > > [BUG #6] > > Document settings cannot be reverted via "undo". Or is it by design? > > That might be by design. It's rather unwanted that settings are undone > and the user doesn't see this happen. this is a regression which works in 1.6, i remember to use it... pavel
Re: LyX 2.0 - some bugs
Hello On Tue, Nov 30, 2010 at 1:37 AM, Vincent van Ravesteijn wrote: >> [BUG #5] >> The dotted line used to mark misspelled words is almost invisible >> (under some conditions). Is the color/thickness of the line >> configurable? >> > > No, this is hardcoded. Under which conditions is it almost invisible ? > In almost all conditions (on my 13 inch netbook and with my young eyes). You need to make a decent effort to spot the misspelled words in a document. Perhaps this is because of the yellowish background; in Opera the same dotted line is used, but since the background is white it's much easier to spot the misspelled words. I just tried to change the background to white, but spotting the dotted lines is still not immediate. I would suspect that a wavy line might be more desirable (as in MS Word, gtkspell, OOo, etc.), and if I remember this was the original implementation (although then the wavy line was too big :) ). Regards Liviu
Re: LyX 2.0 - some bugs
> > [BUG #1] > > Branch insets "override" all the rmb menus, so for example the > > user cannot spellcheck single word inside the branch inset via rmb > > anymore. This makes working with branches a whole lot harder. > > This was bug http://www.lyx.org/trac/ticket/6642. > > Now fixed in r36604--r36609. Not quite a duplicate - #6642 description deals with Note's rmbs, which are broken both in LyX 1.6.8 and 2.0beta1. The rmb menus inside branches are only broken in LyX 2.0beta1. Does this fix also correct rmb menus for branches? If it does so, there would be no need for me to report it, assuming that it has been fixed also in 2.0. I suppose that the difference between 1.6.8 and 2.0beta1 is that in the former rmb menu for branch is only set on the branch 'tag' (the box with the tick-mark, along with the branch name), while for the latter the same menu is also set for the whole contents of the branch as well. If it is still so, then the problem will somewhat remain in 2.0 (although to a much smaller degree): the rmb menu will always have branch options inside a branch, no matter how far 'inside' it the user is. That way the menu will be cluttered too much, but that's just my opinion. Right now I have no means of checking whether this is the case (are there nightly builds anywhere?). I'll wait for your response before entering this into Trac. > > [BUG #2] > [...] > > [BUG #3] > > I cannot add words with special (national) characters to the > > personal dictionary - the request seems to be simply ignored by LyX. > > This has been tested with the default aspell engine. > > This looks like bug: http://www.lyx.org/trac/ticket/7043. #7043 is about adding personal words doing nothing. Well, for me LyX added most of the words to the dictionary (those containing only 'ASCII-encodeable' characters) - I mean, I've observed it as the dotted line disappearing (and maybe it is not the same thing as adding to the dictionary, because of the BUG #4). The problem I've noticed is that after a restart of LyX, same words were underlined again. Anyway, I think I'll just wait for beta2, because #7043 seems much more critical, and fixing it would also probably fix this issue. The problems with spellchecking libraries are way above my head anyway. > > [BUG #4] > > I'm not entirely sure, but isn't "private" dictionary cleaned > > after restarting/reloading LyX? Considering the discussion on > > lyx-devel that I've seen some time ago, this might be the result of > > some other aspell-related bug. > > Indeed. I'll just wait then until beta2 and recheck (see above). > > [BUG #5] > > The dotted line used to mark misspelled words is almost invisible > > (under some conditions). Is the color/thickness of the line > > configurable? > > > > No, this is hardcoded. Under which conditions is it almost invisible ? I meant working conditions - mine, specifically :). I'm mainly using 21" CRT display Philips Brilliance 201P (screen in almost pristine condition), with color temperature 6500K (the so called 'DTP' setting), at 1280x1...@100hz, under artificial lighting, no ICC profile, standard 96dpi. The color theme used is the LyX's default one, 'Zoom %' is set to 150% and the font used on screen is 'Liberation Serif'; I strongly recommend that BTW. I have to look closely to spot the dotted underlines (I don't have any problems with my eyes). Reducing brightness helps a little, but then other details are harder to read. > I fixed the fact that the color was hardcoded in r36612. I remember seeing some screenshot (probably from wiki) in which the line was 'wavy' and somewhat thickier - much more visible. I think that this thickness should also be configurable, as while the same underlining might be distracting for some, it may be hard to spot for others. Not to mention, visually impaired ones... I've reported this as http://www.lyx.org/trac/ticket/7112 > > [BUG #6] > > Document settings cannot be reverted via "undo". Or is it by > > design? > > That might be by design. It's rather unwanted that settings are undone > and the user doesn't see this happen. Strange thing - maybe I'm missing something there, but the 'undo' now worked for me, but only after using it twice. I remember someone reporting exactly that on this list, so now I think this bug is probably irrelevant. As for not doing it 'by design', IMO it would be wrong. A lot of options from document settings are changing the contents of a document - change of the document class being the most drastic one, but also deletion of a branch, changing the language, etc. Another thing is, that LyX should also inform the user somewhat about what has been (un)done - maybe in a status bar. As for an example of a good GUI design for this, take a look at OpenOffice, where you can unfold a list with descriptions of recently done operations and then apply a few undos/redos at once with a single click. Until this kind of int
Re: LyX 2.0 - some bugs
Ok, so I have reported (some of) the bugs to Trac. Just for reference, I've detailed this process below. > [BUG #1] > Branch insets "override" all the rmb menus, so for example the > user cannot spellcheck single word inside the branch inset via rmb > anymore. This makes working with branches a whole lot harder. Maybe duplicate of #6642, at least partially fixed in r36604--r36609, I'll wait for an answer (from Vincent van Ravesteijn) before reporting. > [BUG #2] > In LyX 1.6.x, after toggling particular branch from the document > properties, all the related insets were opened/closed. That was very > convenient and saved a lot of my time, as I'm using branches > (sometimes even nested ones) and heavily depend on these. This > behaviour is no longer present in LyX 2.0beta1. > > I'm not 100% sure whether it is a feature or a bug, but if it is > the former, maybe adding an option to rmb menu to "open all/close all" > insets of the particular branch would be useful instead? Fixed at r36610, no need to report. > [BUG #3] > I cannot add words with special (national) characters to the > personal dictionary - the request seems to be simply ignored by LyX. > This has been tested with the default aspell engine. Probable duplicate of #7043, I'll retest with 2.0beta2. > [BUG #4] > I'm not entirely sure, but isn't "private" dictionary cleaned > after restarting/reloading LyX? Considering the discussion on > lyx-devel that I've seen some time ago, this might be the result of > some other aspell-related bug. The validity of this bug report is unclear, I'll retest with 2.0beta2. > [BUG #5] > The dotted line used to mark misspelled words is almost invisible > (under some conditions). Is the color/thickness of the line > configurable? Partial fix in r36612. Rephrased, then reported as http://www.lyx.org/trac/ticket/7112 > [BUG #6] > Document settings cannot be reverted via "undo". Or is it by > design? Probably irrelevant, discarded. > [BUG #7] > It would be nice if under win32 LyX automatically searched for > thesaurus files inside the already installed OpenOffice / LibreOffice > / GoOO / ... directories. That way LyX would be much more useful by > default. Reported as http://www.lyx.org/trac/ticket/7113 > [BUG #8] > Previewing PDFs with Adobe Acrobat 9 isn't "seamless" - it gives > some error message. I don't rememer exact message, as I've recently > upgraded to Acrobat Reader 10. There, it is a total failure - the > previewed document doesn't even open, only the reader's window > appears. Switching to other viewer fixed the problem. AFAIK, > "pdfview.exe" treats Acrobat differently, so this bug is probably > related to it. Reported as http://www.lyx.org/trac/ticket/7114 > [BUG #9] > This bug dates back to bug #3949, which is marked as a duplicate > of bug #3962, which in turn is marked as fixed. Still, after > installing Scientific Workplace 5.0 and the LyX 2.0beta1, greek > letters in math mode are not displayed correctly. The reason is > probably correctly explained in #3949, but for me it still looks like > not solved. I'm not using SWP myself, but I'm in the process of > convincing someone else to LyX :) Reported as http://www.lyx.org/trac/ticket/7115 Regards, Michał Skrzypek
Re: LyX 2.0 - some bugs
> I have to admit I think it costs not much time to report a bug in > LyX's bug tracker. Fortunately, it's not bugzilla. :-) > And some of the bugs you reported are easier to fix with example > files. Well, I've just reported the bugs (see my other mail on this list). For the record, the preparation, rechecking and everything took me well over 3 hours, and it is just today. To me it seems 'hardly unnoticeable' :) Obviously, with bugzilla it would take at least twice this amount, and if I remember my last time with this system correctly, the main problem has been somewhat related to entering the correct shoe size of mine :D Could you please specify to which bug reports should I attach examples? Regards, Michał Skrzypek
Re: LyX 2.0 - some bugs
Am 30.11.2010 um 08:21 schrieb Michal: >> I have to admit I think it costs not much time to report a bug in >> LyX's bug tracker. Fortunately, it's not bugzilla. :-) >> And some of the bugs you reported are easier to fix with example >> files. >Well, I've just reported the bugs (see my other mail on this > list). For the record, the preparation, rechecking and everything > took me well over 3 hours, and it is just today. To me it seems > 'hardly unnoticeable' :) Thanks for your effort! >Could you please specify to which bug reports should I attach > examples? Only if it's not too much work... * For ticket 7115 a screen shot and a small example file would be helpful. http://www.lyx.org/trac/ticket/7115 But as I cannot solve it, I'm only guessing. * "[BUG #3] I cannot add words with special (national) characters to the personal dictionary - the request seems to be simply ignored by LyX. This has been tested with the default aspell engine." Provide a small example, please. I'd like to go for this, and it's helpful to know which special characters don't work for you. * To answer your question [BUG #4]: AFAIK, words added to aspell's personal dictionary stay there forever. At least until you find the dictionary file and remove the word from it manually. So, if you state that this is the bug... you're right. It's a defect in aspell's API and I've plans for a work around for that. Thanks again and regards, Stephan
Re: LyX 2.0 - some bugs
> >Could you please specify to which bug reports should I attach > > examples? > > Only if it's not too much work... Thank you, it is very considerate of you. Such a rare thing nowadays! :) > * For ticket 7115 a screen shot and a small example file would be > helpful. http://www.lyx.org/trac/ticket/7115 > > But as I cannot solve it, I'm only guessing. Unfortunately, I don't own a copy of Scientific Workplace. But simply opening new document, entering math mode and typing in '\alpha' is enough - instead of a letter, a square appears. I've just added this information as a comment. > * "[BUG #3] >I cannot add words with special (national) characters to the > personal dictionary - the request seems to be simply ignored by LyX. > This has been tested with the default aspell engine." > > Provide a small example, please. I'd like to go for this, and it's > helpful to know which special characters don't work for you. I am not sure whether this bug is valid at all (that's why I haven't entered it into Trac). From what I've read elsewhere, adding a word successfully might somehow depend on whether rmb menu was used vs the spellchecker window. There's something different going on, that's for sure. While I was trying to reproduce BUG #3, I noticed, that for instance any word with a Polish letter 'ś' is accepted as valid; the underline disappears after adding this letter, but it does not always come back. It's kind of difficult to describe. I've ATTACHED a .lyx file along with associated screenshot, but I don't even know how to begin describing it. While trying to trigger this problem in a more reproducible way, I've even encountered a crash after simply cutting and pasting a line of text from this file. Seems like some kind of encoding bug (well, at least). I'd like to help, but I don't know what is going on. Something is seriously broken, that's for sure. If you are willing to try to fix this, please tell me what and how to test, because I don't want to flood you with minor bug reports, which will only blur the whole image. By the way, the GUI glitch after shrinking LyX window (visible on the bottom of the screenshot) seems kind of funny; I haven't noticed that bug before. > * To answer your question [BUG #4]: > AFAIK, words added to aspell's personal dictionary stay there forever. > At least until you find the dictionary file and remove the word from > it manually. So, if you state that this is the bug... you're right. > It's a defect in aspell's API and I've plans for a work around for > that. Thank you for this info. Removing a word should obviously always be possible, so it is strange that the aspell API does not cover this. BTW adding words only to a specific document and storing these in .lyx file would be a nice feature to have... See you next bug :) Michał Skrzypek spelltest.lyx Description: application/lyx <>
Re: LyX 2.0 - some bugs
Am 30.11.2010 um 11:58 schrieb Michal: >> * For ticket 7115 a screen shot and a small example file would be >> helpful. http://www.lyx.org/trac/ticket/7115 >> >> But as I cannot solve it, I'm only guessing. >Unfortunately, I don't own a copy of Scientific Workplace. Me too. I don't have Windows either - just for the record. > But simply opening new document, entering math mode and typing in '\alpha' > is enough - instead of a letter, a square appears. I've just added this > information as a comment. > >> * "[BUG #3] >> I cannot add words with special (national) characters to the >> personal dictionary - the request seems to be simply ignored by LyX. >> This has been tested with the default aspell engine." >> >> Provide a small example, please. I'd like to go for this, and it's >> helpful to know which special characters don't work for you. >I am not sure whether this bug is valid at all (that's why I haven't > entered it into Trac). From what I've read elsewhere, adding a word > successfully might somehow depend on whether rmb menu was used vs the > spellchecker window. > >There's something different going on, that's for sure. While I was > trying to reproduce BUG #3, I noticed, that for instance any word with > a Polish letter 'ś' is accepted as valid; the underline disappears > after adding this letter, but it does not always come back. It's kind of > difficult to describe. > >I've ATTACHED a .lyx file along with associated screenshot, but I > don't even know how to begin describing it. While trying to trigger this > problem in a more reproducible way, I've even encountered a crash after > simply cutting and pasting a line of text from this file. Thanks. I'll investigate. >Seems like some kind of encoding bug (well, at least). I'd like to > help, but I don't know what is going on. Something is seriously broken, > that's for sure. If you are willing to try to fix this, please tell me > what and how to test, because I don't want to flood you with minor bug > reports, which will only blur the whole image. I'll do so if I need more info. >By the way, the GUI glitch after shrinking LyX window (visible on > the bottom of the screenshot) seems kind of funny; I haven't noticed > that bug before. Hmm... not here. See the attached screen shot... > >> * To answer your question [BUG #4]: >> AFAIK, words added to aspell's personal dictionary stay there forever. >> At least until you find the dictionary file and remove the word from >> it manually. So, if you state that this is the bug... you're right. >> It's a defect in aspell's API and I've plans for a work around for >> that. >Thank you for this info. Removing a word should obviously always be > possible, so it is strange that the aspell API does not cover this. You are not alone having this opinion. But the author of aspell is very conservative and has a point here, too. He's afraid of unexpected behavior when more then one process is using the personal dictionary file. >BTW adding words only to a specific document and storing these in > .lyx file would be a nice feature to have... Good idea. But too late for LyX2.0, I'd guess. > See you next bug :) I'm almost sure. :-) Stephan <>
Re: LyX 2.0 - some bugs
Liviu Andronic wrote: > I would suspect that a wavy line might be more desirable (as in MS > Word, gtkspell, OOo, etc.), and if I remember this was the original > implementation (although then the wavy line was too big :) ). so we are at circles, since the wavy line was killed not so long ago :) not that i have opinion about this issue. pavel
Re: LyX 2.0 - some bugs
Am 30.11.2010 um 17:33 schrieb Pavel Sanda:
> Liviu Andronic wrote:
>> I would suspect that a wavy line might be more desirable (as in MS
>> Word, gtkspell, OOo, etc.), and if I remember this was the original
>> implementation (although then the wavy line was too big :) ).
>
> so we are at circles, since the wavy line was killed not so long ago :)
> not that i have opinion about this issue.
To break the circle I propose to adjust the line thickness to zoom factor.
The attached patch does this. I think it's better now.
The problem is the somewhat obfuscated rowpainter code.
This makes the patch hard to read, sorry.
Perhaps some kind soul is able to apply and test it?
Stephan
Index: src/rowpainter.cpp
===
--- src/rowpainter.cpp (Revision 36657)
+++ src/rowpainter.cpp (Arbeitskopie)
@@ -63,6 +63,15 @@
xo_(x), yo_(y), width_(text_metrics_.width())
{
bidi_.computeTables(par_, pi_.base.bv->buffer(), row_);
+ // derive the line thickness from zoom factor
+ // the zoom is given in percent
+ scale_ = lyxrc.zoom / 100.0;
+ // (increase thickness at 150%, 250% etc.)
+ line_thickness_ = scale_ < 1.0 ? 1.0 : int(scale_ + 0.5);
+ line_offset_ = int(1.5 * line_thickness_) + (scale_ < 1.0 ? 1 : 2);
+
+ // adjust left margin to zoom too
+ // xo_ += 4 * scale;
x_ = row_.x + xo_;
//lyxerr << "RowPainter: x: " << x_ << " xo: " << xo_ << " yo: " << yo_
<< endl;
@@ -349,20 +358,19 @@
if (lang == pi_.base.bv->buffer().params().language)
return;
- int const y = yo_ + 1 + desc;
- pi_.pain.line(int(orig_x), y, int(x_), y, Color_language);
+ int const y = yo_ + 1 + desc + int(line_thickness_/2);
+ pi_.pain.line(int(orig_x), y, int(x_), y, Color_language,
+ Painter::line_solid, line_thickness_);
}
-void RowPainter::paintMisspelledMark(double orig_x, int desc, bool changed)
+void RowPainter::paintMisspelledMark(double orig_x, bool changed)
{
- // derive the offset from zoom factor specified by user in percent
// if changed the misspelled marker gets placed slightly lower than
normal
// to avoid drawing at the same vertical offset
- int const offset = int(1.5 * lyxrc.zoom / 100.0); // [percent]
- int const y = yo_ + desc + (changed ? offset : 0) + 1;
+ int const y = yo_ + (changed ? line_thickness_ + 1 : 0) + line_offset_;
pi_.pain.line(int(orig_x), y, int(x_), y, Color_misspelled,
- Painter::line_onoffdash, 2.0);
+ Painter::line_onoffdash, line_thickness_);
}
@@ -399,7 +407,7 @@
paintForeignMark(orig_x, orig_font.language());
if (lyxrc.spellcheck_continuously && misspelled_) {
- paintMisspelledMark(orig_x, 2, changed);
+ paintMisspelledMark(orig_x, changed);
}
}
@@ -854,9 +862,9 @@
FontMetrics const & fm
=
theFontMetrics(pi_.base.bv->buffer().params().getFont());
int const y_bar = change_running.deleted() ?
- yo_ - fm.maxAscent() / 3 : yo_ + fm.maxAscent()
/ 6;
+ yo_ - fm.maxAscent() / 3 : yo_ + line_offset_;
pi_.pain.line(change_last_x, y_bar, int(x_), y_bar,
- change_running.color(), Painter::line_solid,
0.5);
+ change_running.color(), Painter::line_solid,
line_thickness_);
// Change might continue with a different author or type
if (change.changed() && !highly_editable_inset) {
@@ -914,9 +922,9 @@
FontMetrics const & fm
=
theFontMetrics(pi_.base.bv->buffer().params().getFont());
int const y_bar = change_running.deleted() ?
- yo_ - fm.maxAscent() / 3 : yo_ + fm.maxAscent()
/ 6;
+ yo_ - fm.maxAscent() / 3 : yo_ + line_offset_;
pi_.pain.line(change_last_x, y_bar, int(x_), y_bar,
- change_running.color(), Painter::line_solid, 0.5);
+ change_running.color(), Painter::line_solid,
line_thickness_);
change_running.setUnchanged();
}
}
Index: src/rowpainter.h
===
--- src/rowpainter.h(Revision 36657)
+++ src/rowpainter.h(Arbeitskopie)
@@ -59,7 +59,7 @@
private:
void paintForeignMark(double orig_x, Language const * lang, int desc =
0);
- void paintMisspelledMark(double orig_x, int desc, bool changed);
+ void paintMisspelledMark(double orig_x, bool changed);
void paintHebrewComposeChar(pos_type & vpos, FontInfo const & font);
void paintArabicComposeChar(pos_type & vpos, FontInfo const & font);
Re: LyX 2.0 - some bugs
Stephan Witt wrote: > To break the circle I propose to adjust the line thickness to zoom factor. > The attached patch does this. I think it's better now. > The problem is the somewhat obfuscated rowpainter code. > This makes the patch hard to read, sorry. > > Perhaps some kind soul is able to apply and test it? i tried it and thickness zoom works. however my suspiction that together with change tracking the current code produce some mess was confirmed :) pavel
Re: LyX 2.0 - some bugs
Am 02.12.2010 um 17:47 schrieb Pavel Sanda: > Stephan Witt wrote: >> To break the circle I propose to adjust the line thickness to zoom factor. >> The attached patch does this. I think it's better now. >> The problem is the somewhat obfuscated rowpainter code. >> This makes the patch hard to read, sorry. >> >> Perhaps some kind soul is able to apply and test it? > > i tried it and thickness zoom works. however my suspiction that together > with change tracking the current code produce some mess was confirmed :) Sorry, I'm not sure I understand you. Do you refer to the screen appearance or to the rowpainter code? Stephan
Re: LyX 2.0 - some bugs
Stephan Witt wrote: > > i tried it and thickness zoom works. however my suspiction that together > > with change tracking the current code produce some mess was confirmed :) > > Sorry, I'm not sure I understand you. > Do you refer to the screen appearance or to the rowpainter code? i speak about the appearance. load additional manual, which has CT turned on by default, write some nonsense, the text get two chaotical underlines - blue for CT, red for spell. pavel
Re: LyX 2.0 - some bugs
Stephan Witt wrote: > Ok, but that's what I tried too. I attach some screen shot to compare > the two versions, unpatched first - patched second. I cannot see any chaos. this is how it looks on linux qt 4.6.3, Century Schoolbook L font. (patched version) pavel <><>
Re: LyX 2.0 - some bugs
Am 02.12.2010 um 18:41 schrieb Pavel Sanda: > Stephan Witt wrote: >> Ok, but that's what I tried too. I attach some screen shot to compare >> the two versions, unpatched first - patched second. I cannot see any chaos. > > this is how it looks on linux qt 4.6.3, Century Schoolbook L font. > (patched version) Do you refer to the different vertical line positions? This was changed to avoid the blue lines covering the red lines. A consequence of the change from wavy to dotted line. The unpatched version does the same. I admit, the row offset is to less now. Stephan PS. Try to mix it with a different language and look at the result. Then there is a 3rd line to paint.
Re: LyX 2.0 - some bugs
Stephan Witt wrote: > > Am 02.12.2010 um 18:41 schrieb Pavel Sanda: > > > Stephan Witt wrote: > >> Ok, but that's what I tried too. I attach some screen shot to compare > >> the two versions, unpatched first - patched second. I cannot see any chaos. > > > > this is how it looks on linux qt 4.6.3, Century Schoolbook L font. > > (patched version) > > Do you refer to the different vertical line positions? i refer to the the red line jumping like a goat on the hills. this is intended? if you look closely you can see strange drawing artifacts as well (thin full red lines)... pavel
Re: LyX 2.0 - some bugs
Am 02.12.2010 um 19:49 schrieb Pavel Sanda: > Stephan Witt wrote: >> >> Am 02.12.2010 um 18:41 schrieb Pavel Sanda: >> >>> Stephan Witt wrote: Ok, but that's what I tried too. I attach some screen shot to compare the two versions, unpatched first - patched second. I cannot see any chaos. >>> >>> this is how it looks on linux qt 4.6.3, Century Schoolbook L font. >>> (patched version) >> >> Do you refer to the different vertical line positions? > > i refer to the the red line jumping like a goat on the hills. this is > intended? Yes. Do you have another idea? The problem is as follows: When drawing the misspelled marker you don't know in advance if a change follows later in line and vice versa. If you paint both lines with constant different vertical offset it looks weird when only one of them is present. A possible solution could be the painting of change tracking markers below a possible spell check marker. So, documents without change tracking will be presented normal. A document without spelling mistakes and change tracking enabled would suffer then. The optimal solution would be a two pass algorithm for the computation of the offsets... > if you look closely you can see strange drawing artifacts as well (thin full > red lines)... Yes, I can see them now. I'll try it on Linux then... Stephan
Re: LyX 2.0 - some bugs
Stephan Witt wrote: > >> Do you refer to the different vertical line positions? > > > > i refer to the the red line jumping like a goat on the hills. this is > > intended? > > Yes. Do you have another idea? aha :) i didn't got that its intended... > The optimal solution would be a two pass algorithm for the computation of the > offsets... i see. this looks too much work for a little gain. pavel
Re: LyX 2.0 - some bugs
Pavel Sanda wrote: > Stephan Witt wrote: btw i have unrelated question. the "native" string translation. this is standard naming in mac world or our invetion? i wonder whether it should be translated or is it terminus technicus like other aspell/enchant/hunspell strings which i'm going to kill right now... pavel
Re: LyX 2.0 - some bugs
Am 02.12.2010 um 21:12 schrieb Pavel Sanda: > Pavel Sanda wrote: > > btw i have unrelated question. > the "native" string translation. this is standard naming in mac world or our > invetion? i wonder whether it should be translated or is it terminus technicus > like other aspell/enchant/hunspell strings which i'm going to kill right > now... It's our invention. See here: http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg160501.html I think, translating this is ok. Stephan
Re: LyX 2.0 - some bugs
Stephan Witt wrote: > Am 02.12.2010 um 21:12 schrieb Pavel Sanda: > > > Pavel Sanda wrote: > > > > btw i have unrelated question. > > the "native" string translation. this is standard naming in mac world or our > > invetion? i wonder whether it should be translated or is it terminus > > technicus > > like other aspell/enchant/hunspell strings which i'm going to kill right > > now... > > It's our invention. See here: > > http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg160501.html i see, so using applespell is correct, right? while "native" make some sense in english all translations here are completely misleading. pavel
Re: LyX 2.0 - some bugs
Am 02.12.2010 um 21:32 schrieb Pavel Sanda: > Stephan Witt wrote: >> Am 02.12.2010 um 21:12 schrieb Pavel Sanda: >> >>> Pavel Sanda wrote: >>> >>> btw i have unrelated question. >>> the "native" string translation. this is standard naming in mac world or our >>> invetion? i wonder whether it should be translated or is it terminus >>> technicus >>> like other aspell/enchant/hunspell strings which i'm going to kill right >>> now... >> >> It's our invention. See here: >> >> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg160501.html > > i see, so using applespell is correct, right? Hmm.. I'm not sure. Perhaps "Mac OS Speller" or "OS Spell Service"? > while "native" make some sense in english all translations here are > completely misleading. I see. Stephan
Re: LyX 2.0 - some bugs
Stephan Witt wrote: > > i see, so using applespell is correct, right? > > Hmm.. I'm not sure. > Perhaps "Mac OS Speller" or "OS Spell Service"? i will use Mac OS Speller, thanks. pavel
Re: LyX 2.0 - some bugs
Am 02.12.2010 um 20:08 schrieb Stephan Witt: > Am 02.12.2010 um 19:49 schrieb Pavel Sanda: > >> Stephan Witt wrote: >>> >>> Am 02.12.2010 um 18:41 schrieb Pavel Sanda: >>> Stephan Witt wrote: > Ok, but that's what I tried too. I attach some screen shot to compare > the two versions, unpatched first - patched second. I cannot see any > chaos. this is how it looks on linux qt 4.6.3, Century Schoolbook L font. (patched version) > >> if you look closely you can see strange drawing artifacts as well (thin full >> red lines)... > > Yes, I can see them now. > I'll try it on Linux then... The outcome is this (with Qt 4.5.3 - the font does not matter): <> Looks ok - I cannot see any artifacts. Of course this isn't any evidence. But I can see another effect. It interacts with selections. See below: * variation 1 - the misspelled marker clipped 100% <> * variation 2 - the misspelled marker gets partly clipped. <> Stephan
Re: LyX 2.0 - some bugs
On 30/11/2010 17:33, Pavel Sanda wrote: Liviu Andronic wrote: I would suspect that a wavy line might be more desirable (as in MS Word, gtkspell, OOo, etc.), and if I remember this was the original implementation (although then the wavy line was too big :) ). so we are at circles, since the wavy line was killed not so long ago :) not that i have opinion about this issue. Well, the way the wavy line looks is probably due to my poor 10 minutes coding time attempt to implement it because I didn't find a ready to use solution in Qt. Now, instead of insisting on the dotted line, couldn't we try to improve the wavy line drawing instead? Abdel.
Re: LyX 2.0 - some bugs
Am 03.12.2010 um 15:31 schrieb Abdelrazak Younes: > On 30/11/2010 17:33, Pavel Sanda wrote: >> Liviu Andronic wrote: >> >>> I would suspect that a wavy line might be more desirable (as in MS >>> Word, gtkspell, OOo, etc.), and if I remember this was the original >>> implementation (although then the wavy line was too big :) ). >>> >> so we are at circles, since the wavy line was killed not so long ago :) >> not that i have opinion about this issue. >> > > Well, the way the wavy line looks is probably due to my poor 10 minutes > coding time attempt to implement it because I didn't find a ready to use > solution in Qt. > Now, instead of insisting on the dotted line, couldn't we try to improve the > wavy line drawing instead? No problem. Who is "we", please? :-) Seriously, the rowpainter code is full of hard codes values and with interesting interactions to other classes, e. g. Row. I'm not in the position to have fun with the changes I'd like to see. Stephan
Re: LyX 2.0 - some bugs
On 03/12/2010 15:52, Stephan Witt wrote: Am 03.12.2010 um 15:31 schrieb Abdelrazak Younes: On 30/11/2010 17:33, Pavel Sanda wrote: Liviu Andronic wrote: I would suspect that a wavy line might be more desirable (as in MS Word, gtkspell, OOo, etc.), and if I remember this was the original implementation (although then the wavy line was too big :) ). so we are at circles, since the wavy line was killed not so long ago :) not that i have opinion about this issue. Well, the way the wavy line looks is probably due to my poor 10 minutes coding time attempt to implement it because I didn't find a ready to use solution in Qt. Now, instead of insisting on the dotted line, couldn't we try to improve the wavy line drawing instead? No problem. Who is "we", please? :-) "We" is Vincent and you of course :-) Seriously, the rowpainter code is full of hard codes values and with interesting interactions to other classes, e. g. Row. I'm not in the position to have fun with the changes I'd like to see. What changes you'd like to see? Abdel.
Re: LyX 2.0 - some bugs
Op 3-12-2010 15:54, Abdelrazak Younes schreef: On 03/12/2010 15:52, Stephan Witt wrote: Am 03.12.2010 um 15:31 schrieb Abdelrazak Younes: On 30/11/2010 17:33, Pavel Sanda wrote: Liviu Andronic wrote: I would suspect that a wavy line might be more desirable (as in MS Word, gtkspell, OOo, etc.), and if I remember this was the original implementation (although then the wavy line was too big :) ). so we are at circles, since the wavy line was killed not so long ago :) not that i have opinion about this issue. Well, the way the wavy line looks is probably due to my poor 10 minutes coding time attempt to implement it because I didn't find a ready to use solution in Qt. Now, instead of insisting on the dotted line, couldn't we try to improve the wavy line drawing instead? No problem. Who is "we", please? :-) "We" is Vincent and you of course :-) What :O... I ? I was being really quiet on this subject ... Vincent
Re: LyX 2.0 - some bugs
On 03/12/2010 15:58, Vincent van Ravesteijn wrote: Op 3-12-2010 15:54, Abdelrazak Younes schreef: On 03/12/2010 15:52, Stephan Witt wrote: Am 03.12.2010 um 15:31 schrieb Abdelrazak Younes: On 30/11/2010 17:33, Pavel Sanda wrote: Liviu Andronic wrote: I would suspect that a wavy line might be more desirable (as in MS Word, gtkspell, OOo, etc.), and if I remember this was the original implementation (although then the wavy line was too big :) ). so we are at circles, since the wavy line was killed not so long ago :) not that i have opinion about this issue. Well, the way the wavy line looks is probably due to my poor 10 minutes coding time attempt to implement it because I didn't find a ready to use solution in Qt. Now, instead of insisting on the dotted line, couldn't we try to improve the wavy line drawing instead? No problem. Who is "we", please? :-) "We" is Vincent and you of course :-) What :O... I ? I was being really quiet on this subject ... Oh well, the probability that you were involved was big... so was affirmation to be true :-) Anyway, I was probably talking about JMarc now that I read the thread. Abdel.
Re: LyX 2.0 - some bugs
Am 03.12.2010 um 15:54 schrieb Abdelrazak Younes: > On 03/12/2010 15:52, Stephan Witt wrote: >> Am 03.12.2010 um 15:31 schrieb Abdelrazak Younes: >> >> >>> On 30/11/2010 17:33, Pavel Sanda wrote: >>> Liviu Andronic wrote: > I would suspect that a wavy line might be more desirable (as in MS > Word, gtkspell, OOo, etc.), and if I remember this was the original > implementation (although then the wavy line was too big :) ). > > so we are at circles, since the wavy line was killed not so long ago :) not that i have opinion about this issue. >>> Well, the way the wavy line looks is probably due to my poor 10 minutes >>> coding time attempt to implement it because I didn't find a ready to use >>> solution in Qt. >>> Now, instead of insisting on the dotted line, couldn't we try to improve >>> the wavy line drawing instead? >>> >> No problem. Who is "we", please? :-) >> > > "We" is Vincent and you of course :-) What, me? :-) >> Seriously, the rowpainter code is full of hard codes values and with >> interesting interactions to other classes, e. g. Row. >> I'm not in the position to have fun with the changes I'd like to see. > > What changes you'd like to see? AFAICS, the location and coding of some constants. I did no serious investigation until now... Only one example: I tried to adjust the left margin to zoom factor. Guess what happened... The cursor was misplaced badly. Another example: Imagine you want to increase the thickness of the change bar. Where to start and what classes has to be changed? But it may very well be the fact that I didn't get the big picture. Anyway, I expect endless discussions. Stephan
Re: LyX 2.0 - some bugs
Stephan Witt wrote: > I did no serious investigation until now... > Only one example: > I tried to adjust the left margin to zoom factor. Guess what happened... > The cursor was misplaced badly. and soon you'll get another ones ... few times i tried to touch painting stuff and escaped as far as possible :) pavel
Re: LyX 2.0 - some bugs
Another example: Imagine you want to increase the thickness of the change bar. Where to start and what classes has to be changed? void RowPainter::paintChangeBar() sounds like it :) ;) and pi_.pain.fillRectangle(5, yo_ - row_.ascent(), 3, height, Color_changebar); 5 is the offset from the left border, and 3 is the thickness. VIncent
Re: LyX 2.0 - some bugs
On 03/12/2010 16:18, Pavel Sanda wrote: Stephan Witt wrote: I did no serious investigation until now... Only one example: I tried to adjust the left margin to zoom factor. Guess what happened... The cursor was misplaced badly. and soon you'll get another ones ... few times i tried to touch painting stuff and escaped as far as possible :) Quite frankly when I look at this LaTeX dependent code I find the painting code very simple in comparison :-) Abdel.
Re: LyX 2.0 - some bugs
Op 3-12-2010 16:19, Abdelrazak Younes schreef: On 03/12/2010 16:18, Pavel Sanda wrote: Stephan Witt wrote: I did no serious investigation until now... Only one example: I tried to adjust the left margin to zoom factor. Guess what happened... The cursor was misplaced badly. and soon you'll get another ones ... few times i tried to touch painting stuff and escaped as far as possible :) Quite frankly when I look at this LaTeX dependent code I find the painting code very simple in comparison :-) Abdel. Anyone wants to opt for the RTL stuff ??? Vincent
Re: LyX 2.0 - some bugs
On 03/12/2010 16:13, Stephan Witt wrote: Am 03.12.2010 um 15:54 schrieb Abdelrazak Younes: On 03/12/2010 15:52, Stephan Witt wrote: Am 03.12.2010 um 15:31 schrieb Abdelrazak Younes: On 30/11/2010 17:33, Pavel Sanda wrote: Liviu Andronic wrote: I would suspect that a wavy line might be more desirable (as in MS Word, gtkspell, OOo, etc.), and if I remember this was the original implementation (although then the wavy line was too big :) ). so we are at circles, since the wavy line was killed not so long ago :) not that i have opinion about this issue. Well, the way the wavy line looks is probably due to my poor 10 minutes coding time attempt to implement it because I didn't find a ready to use solution in Qt. Now, instead of insisting on the dotted line, couldn't we try to improve the wavy line drawing instead? No problem. Who is "we", please? :-) "We" is Vincent and you of course :-) What, me? :-) Seriously, the rowpainter code is full of hard codes values and with interesting interactions to other classes, e. g. Row. I'm not in the position to have fun with the changes I'd like to see. What changes you'd like to see? AFAICS, the location and coding of some constants. I did no serious investigation until now... Only one example: I tried to adjust the left margin to zoom factor. Guess what happened... The cursor was misplaced badly. Another example: Imagine you want to increase the thickness of the change bar. Where to start and what classes has to be changed? True some things need to be generalized to work proportionally and not be painted absolutely like now. Nothing unfixable though... just a bit of code shuffling here and there. The row painter code in particular should be more aware of the BufferView geometry. Abdel.
Re: LyX 2.0 - some bugs
Abdelrazak Younes wrote: >> and soon you'll get another ones ... >> few times i tried to touch painting stuff and escaped as far as possible >> :) >> > > Quite frankly when I look at this LaTeX dependent code I find the painting > code very simple in comparison :-) then we should establish refugees camp soon :) p
Re: LyX 2.0 - some bugs
Am 03.12.2010 um 16:20 schrieb Vincent van Ravesteijn: > Another example: >> Imagine you want to increase the thickness of the change bar. >> Where to start and what classes has to be changed? > > void RowPainter::paintChangeBar() sounds like it :) ;) > > and > >pi_.pain.fillRectangle(5, yo_ - row_.ascent(), 3, height, Color_changebar); > > 5 is the offset from the left border, and 3 is the thickness. Of course. But I'd expect the text and the cursor shifts to the left at least 3 pixels when the change bar has a thickness of 6 instead of 3. And then there's the clipping for selections... etc. Pandoras box... Stephan
Re: LyX 2.0 - some bugs
On 03/12/2010 16:23, Vincent van Ravesteijn wrote: Op 3-12-2010 16:19, Abdelrazak Younes schreef: On 03/12/2010 16:18, Pavel Sanda wrote: Stephan Witt wrote: I did no serious investigation until now... Only one example: I tried to adjust the left margin to zoom factor. Guess what happened... The cursor was misplaced badly. and soon you'll get another ones ... few times i tried to touch painting stuff and escaped as far as possible :) Quite frankly when I look at this LaTeX dependent code I find the painting code very simple in comparison :-) Abdel. Anyone wants to opt for the RTL stuff ??? Hum I have a better one: the graphics stuff!!! Abdel.
Re: LyX 2.0 - some bugs
On 12/03/2010 12:21 PM, Abdelrazak Younes wrote: Hum I have a better one: the graphics stuff!!! Speaking of which, can you look again at #6949? Richard
Re: LyX 2.0 - some bugs
Stephan Witt wrote: > Looks ok - I cannot see any artifacts. Of course this isn't any evidence. Stephan what is the current state-of-art patch for 7120? Others, do you like more the current thick line or zoomming-line style for spellchech errs? pavel
Re: LyX 2.0 - some bugs
On Fri, Dec 10, 2010 at 6:34 PM, Pavel Sanda wrote: > Stephan what is the current state-of-art patch for 7120? > Others, do you like more the current thick line or zoomming-line style > for spellchech errs? > I hate to nag, but the current implementation is very eye-catchy. But I feel like loosing objectivity, and I may simply need to get used to it. Regards Liviu
Re: LyX 2.0 - some bugs
Le 10 déc. 2010 à 21:35, Liviu Andronic a écrit : On Fri, Dec 10, 2010 at 6:34 PM, Pavel Sanda wrote: >> Stephan what is the current state-of-art patch for 7120? >> Others, do you like more the current thick line or zoomming-line style >> for spellchech errs? >> > I hate to nag, but the current implementation is very eye-catchy. But > I feel like loosing objectivity, and I may simply need to get used to > it. We might try to find a red that is less red. JMarc
Re: LyX 2.0 - some bugs
Am 10.12.2010 um 18:34 schrieb Pavel Sanda: > Stephan Witt wrote: >> Looks ok - I cannot see any artifacts. Of course this isn't any evidence. > > Stephan what is the current state-of-art patch for 7120? A little bit buried. But it may resurrect. Starting to dig soon. :-) > Others, do you like more the current thick line or zoomming-line style > for spellchech errs? I like the zooming line. Stephan
Re: LyX 2.0 - some bugs
Am 10.12.2010 um 18:34 schrieb Pavel Sanda:
> Stephan Witt wrote:
>> Looks ok - I cannot see any artifacts. Of course this isn't any evidence.
>
> Stephan what is the current state-of-art patch for 7120?
See the attached patch.
Stephan
Index: src/rowpainter.cpp
===
--- src/rowpainter.cpp (Revision 36843)
+++ src/rowpainter.cpp (Arbeitskopie)
@@ -63,6 +63,13 @@
xo_(x), yo_(y), width_(text_metrics_.width())
{
bidi_.computeTables(par_, pi_.base.bv->buffer(), row_);
+ // derive the line thickness from zoom factor
+ // the zoom is given in percent
+ scale_ = lyxrc.zoom / 100.0;
+ // (increase thickness at 150%, 250% etc.)
+ line_thickness_ = scale_ < 1.0 ? 1.0 : int(scale_ + 0.5);
+ line_offset_ = int(1.5 * line_thickness_) + (scale_ < 1.0 ? 1 : 2);
+
x_ = row_.x + xo_;
//lyxerr << "RowPainter: x: " << x_ << " xo: " << xo_ << " yo: " << yo_
<< endl;
@@ -349,20 +356,19 @@
if (lang == pi_.base.bv->buffer().params().language)
return;
- int const y = yo_ + 1 + desc;
- pi_.pain.line(int(orig_x), y, int(x_), y, Color_language);
+ int const y = yo_ + 1 + desc + int(line_thickness_/2);
+ pi_.pain.line(int(orig_x), y, int(x_), y, Color_language,
+ Painter::line_solid, line_thickness_);
}
-void RowPainter::paintMisspelledMark(double orig_x, int desc, bool changed)
+void RowPainter::paintMisspelledMark(double orig_x, bool changed)
{
- // derive the offset from zoom factor specified by user in percent
// if changed the misspelled marker gets placed slightly lower than
normal
// to avoid drawing at the same vertical offset
- int const offset = int(1.5 * lyxrc.zoom / 100.0); // [percent]
- int const y = yo_ + desc + (changed ? offset : 0) + 1;
+ int const y = yo_ + (changed ? line_thickness_ + 1 : 0) + line_offset_;
pi_.pain.line(int(orig_x), y, int(x_), y, Color_error,
- Painter::line_onoffdash, 2.0);
+ Painter::line_onoffdash, line_thickness_);
}
@@ -399,7 +405,7 @@
paintForeignMark(orig_x, orig_font.language());
if (lyxrc.spellcheck_continuously && misspelled_) {
- paintMisspelledMark(orig_x, 2, changed);
+ paintMisspelledMark(orig_x, changed);
}
}
@@ -854,9 +860,9 @@
FontMetrics const & fm
=
theFontMetrics(pi_.base.bv->buffer().params().getFont());
int const y_bar = change_running.deleted() ?
- yo_ - fm.maxAscent() / 3 : yo_ + fm.maxAscent()
/ 6;
+ yo_ - fm.maxAscent() / 3 : yo_ + line_offset_;
pi_.pain.line(change_last_x, y_bar, int(x_), y_bar,
- change_running.color(), Painter::line_solid,
0.5);
+ change_running.color(), Painter::line_solid,
line_thickness_);
// Change might continue with a different author or type
if (change.changed() && !highly_editable_inset) {
@@ -914,9 +920,9 @@
FontMetrics const & fm
=
theFontMetrics(pi_.base.bv->buffer().params().getFont());
int const y_bar = change_running.deleted() ?
- yo_ - fm.maxAscent() / 3 : yo_ + fm.maxAscent()
/ 6;
+ yo_ - fm.maxAscent() / 3 : yo_ + line_offset_;
pi_.pain.line(change_last_x, y_bar, int(x_), y_bar,
- change_running.color(), Painter::line_solid, 0.5);
+ change_running.color(), Painter::line_solid,
line_thickness_);
change_running.setUnchanged();
}
}
Index: src/rowpainter.h
===
--- src/rowpainter.h(Revision 36843)
+++ src/rowpainter.h(Arbeitskopie)
@@ -59,7 +59,7 @@
private:
void paintForeignMark(double orig_x, Language const * lang, int desc =
0);
- void paintMisspelledMark(double orig_x, int desc, bool changed);
+ void paintMisspelledMark(double orig_x, bool changed);
void paintHebrewComposeChar(pos_type & vpos, FontInfo const & font);
void paintArabicComposeChar(pos_type & vpos, FontInfo const & font);
void paintChars(pos_type & vpos, FontInfo const & font,
@@ -68,7 +68,7 @@
void paintFromPos(pos_type & vpos, bool changed);
void paintInset(Inset const * inset, pos_type const pos);
void paintInlineCompletion(Font const & font);
-
+
/// return left margin
int leftMargin() const;
@@ -104,6 +104,9 @@
int const yo_;// current baseline
double x_;
int width_;
+ double scale_;
+ int line_thickness_;
+ int line_offset_;
};
} //
Re: LyX 2.0 - some bugs
Stephan Witt wrote: > Am 10.12.2010 um 18:34 schrieb Pavel Sanda: > > > Stephan Witt wrote: > >> Looks ok - I cannot see any artifacts. Of course this isn't any evidence. > > > > Stephan what is the current state-of-art patch for 7120? > > See the attached patch. since nobody responded feel free to put it in if you consider zooming better alternative than current state. pavel
Re: LyX 2.0 - some bugs
Am 13.12.2010 um 13:07 schrieb Pavel Sanda: > Stephan Witt wrote: >> Am 10.12.2010 um 18:34 schrieb Pavel Sanda: >> >>> Stephan Witt wrote: Looks ok - I cannot see any artifacts. Of course this isn't any evidence. >>> >>> Stephan what is the current state-of-art patch for 7120? >> >> See the attached patch. > > since nobody responded feel free to put it in if you consider zooming > better alternative than current state. I did it. The patch I actually applied contains less changes to rowpainters header. There is no need to save the zoom factor as rowpainter state. Stephan
Anybody Wanna Own Some Bugs?
Abdel has asked to be removed as default owner for the dialog and frontend-qt4 bugs, and I've also removed him as default owner of the file and menu bugs. Would anyone like to replace him? The only thing this really means is that you get an email when a bug in that category has been filed, so you can do some initial triage. While we're at it, the current list of compoments and owners is below. Let me know if there are any other changes you think would be appropriate. Richard BiDi Supportspitz build lasgouttes changes vfr citationrgheck compare vfr configure lasgouttes converters rgheck cursor lasgouttes dialogs nobody docbook export jamatos documentation uwestoehr externaljrioux filergheck fontlasgouttes frontend-qt4nobody general lasgouttes insetgraphics uwestoehr insets rgheck insettext lasgouttes keyboardlasgouttes latex exportlasgouttes layout rgheck literatelasgouttes lyx2lyx rgheck lyxfunc rgheck lyxserver lasgouttes lyxtext rgheck master/childspitz mathed spitz menus nobody minibuffer rgheck outlinerrgheck painter lasgouttes pdf sanda preview-latex lasgouttes search tommaso selection lasgouttes shortcuts uwestoehr spell stwitt tabular skostysh tex2lyx lasgouttes translationsuwestoehr undo/redo lasgouttes version control sanda website chr windows-installer uwestoehr xhtml exportrgheck
Re: paste & paragraphs and some bugs
On Tue, 19 Aug 2003, Juergen Spitzmueller wrote: > Is there a special reason why the layout of the first (pasted) paragraph is > not kept when pasting? Most of the time I find this annyoing I agree... any objections to adding this to bugzilla? /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: paste & paragraphs and some bugs
Isn't described in bug #922? > > Is there a special reason why the layout of the first (pasted) paragraph is > > not kept when pasting? Most of the time I find this annyoing > > I agree... any objections to adding this to bugzilla? > > /Christian
Re: paste & paragraphs and some bugs
On Wed, 20 Aug 2003, Uwe Stöhr wrote: > Isn't this described in bug #922? Maybe... not quite I think, so to be on the size side I've added http://bugzilla.lyx.org/show_bug.cgi?id=1332 since http://bugzilla.lyx.org/show_bug.cgi?id=922 doesn't seem to be exactly the same, although related. 1332 can always be marked as a duplicate. /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: po-Patches, plus some bugs...
> "Peter" == Peter Suetterlin <[EMAIL PROTECTED]> writes:
Hi Pit,
Thanks for the patches, I'll commit them soon.
Peter> - The ballon tool tips are not translated. I'm not sure wether
Peter> this has ever since been the case, but i thought they have been
Peter> at some point...
They used to be translated. It is probably due to Lars recent changes.
Peter> - When using a different keymap table (in my case german): The
Peter> umlauts (ä,ö etc.) show up quite strange (like painted by LyX
Peter> itself, not using the font), the sharp s (ß) is written as
Peter> \{ss} (*not* in TeX-Mode!).
This bug has been identified, and thus should be fixed soon.
Peter> Also, the german keyboard table
Peter> needs the AltGr key for some characters (namely |,\, and @);
Peter> This seems not to be supported by that map.
What is the modifier associated to AltGr?
JMarc
Re: Anybody Wanna Own Some Bugs?
On 19/04/2014 19:22, Richard Heck wrote: Abdel has asked to be removed as default owner for the dialog and frontend-qt4 bugs, and I've also removed him as default owner of the file and menu bugs. Would anyone like to replace him? The only thing this really means is that you get an email when a bug in that category has been filed, so you can do some initial triage. While we're at it, the current list of compoments and owners is below. Let me know if there are any other changes you think would be appropriate. Some suggestions below... in general, too many components and sometime not clear keyword for the user. Richard BiDi Support spitz build lasgouttes Split between autoconf (lasgouttes) and cmake (Kornel) changes vfr Rename to track-change citation rgheck Split between "citation&reference" (rgheck) and bibliography (Jürgen) compare vfr Merge with "Track-Change" configure lasgouttes Rename to "configure.py" to avoid confusion with autoconf converters rgheck cursor lasgouttes dialogs nobody docbook export jamatos documentation uwestoehr externaljrioux Rename to "External Inset"? file rgheck File Management ? font lasgouttes frontend-qt4 nobody Merge with "dialogs". Some items in there are related to scrolling and editing performance, I would move to a new "Editing" component. general lasgouttes insetgraphics uwestoehr Remove. insets rgheck insettext lasgouttes Remove. keyboard lasgouttes latex exportlasgouttes layout rgheck literate lasgouttes Literate Programming lyx2lyx rgheck lyxfunc rgheck lyxserver lasgouttes lyxtext rgheck Remove master/child spitz Multipart Document mathed spitz "Math Editing" menus nobody minibuffer rgheck outlinerrgheck painter lasgouttes Merge with new "Editing components" pdf sanda Export PDF preview-latex lasgouttes search tommaso selection lasgouttes shortcuts uwestoehr Merge with Dialogs spell stwitt Spell Checking tabular skostysh Table Editing tex2lyx lasgouttes translations uwestoehr undo/redo lasgouttes Remove version control sanda website chr windows-installer uwestoehr xhtml export rgheck
Re: Anybody Wanna Own Some Bugs?
Abdelrazak Younes wrote: >> undo/redo lasgouttes > > Remove I think this one should remain. P
Re: Anybody Wanna Own Some Bugs?
2014-04-19 19:22 GMT+02:00 Richard Heck: > > Abdel has asked to be removed as default owner for the dialog and > frontend-qt4 bugs, and I've also removed him as default owner of the file > and menu bugs. Would anyone like to replace him? The only thing this really > means is that you get an email when a bug in that category has been filed, > so you can do some initial triage. > > While we're at it, the current list of compoments and owners is below. > Let me know if there are any other changes you think would be appropriate. > I have signed for the frontend and dialog components now. I think I am not the best choice for mathed and a very bad choice for bidi, so if someone more knowledgeable want to take those, please do. Jürgen > > Richard > > > > BiDi Supportspitz > build lasgouttes > changes vfr > citationrgheck > compare vfr > configure lasgouttes > converters rgheck > cursor lasgouttes > dialogs nobody > docbook export jamatos > documentation uwestoehr > externaljrioux > filergheck > fontlasgouttes > frontend-qt4nobody > general lasgouttes > insetgraphics uwestoehr > insets rgheck > insettext lasgouttes > keyboardlasgouttes > latex exportlasgouttes > layout rgheck > literatelasgouttes > lyx2lyx rgheck > lyxfunc rgheck > lyxserver lasgouttes > lyxtext rgheck > master/childspitz > mathed spitz > menus nobody > minibuffer rgheck > outlinerrgheck > painter lasgouttes > pdf sanda > preview-latex lasgouttes > search tommaso > selection lasgouttes > shortcuts uwestoehr > spell stwitt > tabular skostysh > tex2lyx lasgouttes > translationsuwestoehr > undo/redo lasgouttes > version control sanda > website chr > windows-installer uwestoehr > xhtml exportrgheck > >
Re: Anybody Wanna Own Some Bugs?
Op 22 apr. 2014 09:47 schreef "Jürgen Spitzmüller" : > > 2014-04-19 19:22 GMT+02:00 Richard Heck: > >> >> Abdel has asked to be removed as default owner for the dialog and frontend-qt4 bugs, and I've also removed him as default owner of the file and menu bugs. Would anyone like to replace him? The only thing this really means is that you get an email when a bug in that category has been filed, so you can do some initial triage. >> >> While we're at it, the current list of compoments and owners is below. >> Let me know if there are any other changes you think would be appropriate. > > > I have signed for the frontend and dialog components now. I think I am not the best choice for mathed and a very bad choice for bidi, so if someone more knowledgeable want to take those, please do. > You could sign me up for those two. However, I'm not sure what it means to be the ticket owner. Vincent
Re: Anybody Wanna Own Some Bugs?
2014-04-24 0:29 GMT+02:00 Vincent van Ravesteijn : > > You could sign me up for those two. > Done. > However, I'm not sure what it means to be the ticket owner. > I think the main purpose is that someone knowledgeable in the respective area checks the severity of the bug, maybe invites people to fix it or fixes it himself. Having an owner at least should assure that urgent issues do not vanish in the dust of trac. Jürgen > Vincent >
