Re: Towards LyX 1.3.6 [status update #1]
On Thu, Mar 31, 2005 at 02:32:23PM +0100, Angus Leeming wrote:
> Jean-Marc Lasgouttes wrote:
> > PS: actually I had some problems with your .fig file:
> > 1/ I had to add \usepackage{color} in the preamble. Is this
> > expected?
>
> It's pretty common, although it is possible to create XFig figures that
> don't require color.
>
> --
> Angus
I see that you can give _one_ requirement to an external template. Could
that be generalized so we could demand color in addition to graphicx?
(Or would Requirement "graphicx,color" do the trick?)
BTW I have also the problem that I cannot have black special text.
Colour must be 'default' (or a real colour) or LaTeX barfs. Do others
see this?
- Martin
pgpAv9JW0bgW3.pgp
Description: PGP signature
Problem with TeX within math edit mode
In 1.3.5 I can do the following to get a 3-digit number with the middle digit underlined in math mode (eg, 1_2_3) 1. Insert->Math->Inline Formula 2. Type a number 3. Insert->TeX 4. Type "underline" (without the quotes) 5. Type a number 6. Press right-arrow 7. Type a number With the current 1.4 CVS tree, step 5 above results in a pair of empty brackets underlined with the second typed number to the right, not underlined. In neither version does Ctrl-U give me underlined text in math mode. Thanks Rob
LyX archaeology
I think that this http://www.devel.lyx.org/~leeming/www-user/archaeology/lyx_timeline.php is just about ready to go. However, we're missing archives for 1.1.4 fix1 1.1.4 fix2 1.1.4 fix3 1.1.5.5 and patches to enable earlier sources to be compiled against XForms 1.0. -- Angus
Re: [Patch] fix grid lines in AMS arrays
Martin Vermeer wrote:
> On Thu, Mar 31, 2005 at 09:52:57AM +0200, Jean-Marc Lasgouttes wrote:
>> > "Georg" == Georg Baum
>> > <[EMAIL PROTECTED]>
>> > writes:
>>
>> Georg> I thought the reason for using the istringstream was to get rid
>> Georg> of whitespace or other stuff that might be in cmd.argument
>> Georg> after the first word. Is that wrong? And if we get rid of it
>> Georg> here we should get rid of it in all the other insets, too (not
>> Georg> necessarily now)...
>>
>> Then you can use FuncRequest::getArg(1). I am not sure it has the best
>> possible implementation, but at least this is a consistent interface.
I had a closer look, and it turned out that more arguments are only needed
in MathGridInset for append-column etc. cmd.argument can be used directly
at all other places. I did not change MathGridInset to use
FuncRequest::getArg(1) because I wanted to be on the safe side.
> Should we at this point just add a comment to this effect at a strategic
> location, e.g., math_gridinset?
Simply changing the implementation was not more work, so I did that instead
of the comment.
Updated and tested patch attached. Since getStatus and doDispatch should
handle the same lfuns I also implemented the missing doDispatch methods.
This is going in unless I get a no.
GeorgIndex: src/mathed/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/ChangeLog,v
retrieving revision 1.480
diff -u -p -r1.480 ChangeLog
--- src/mathed/ChangeLog 30 Mar 2005 09:05:30 - 1.480
+++ src/mathed/ChangeLog 31 Mar 2005 17:16:41 -
@@ -1,3 +1,20 @@
+2005-03-31 Georg Baum <[EMAIL PROTECTED]>
+
+ * math_amsarrayinset.[Ch], math_tabularinset.[Ch],
+ math_splitinset.[Ch] (infoize): implement
+ * math_amsarrayinset.[Ch], math_splitinset.[Ch],
+ math_substackinset.[Ch] (doDispatch): implement
+ * math_casesinset.C (getStatus, doDispatch): use cmd.argument directly
+ * math_gridinset.C (getStatus): ditto
+ * math_arrayinset.C (infoize): generalize
+
+2005-03-30 Martin Vermeer <[EMAIL PROTECTED]>
+
+ * math_amsarrayinset.[Ch] (getStatus):
+ * math_splitinset.[Ch] (getStatus):
+ * math_substackinset.[Ch]: suppress output of vertical gridlines
+ where appropriate
+
2005-03-27 Georg Baum <[EMAIL PROTECTED]>
* math_amsarrayinset.[Ch] (validate): new, require amsmath
Index: src/mathed/math_amsarrayinset.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_amsarrayinset.C,v
retrieving revision 1.26
diff -u -p -r1.26 math_amsarrayinset.C
--- src/mathed/math_amsarrayinset.C 30 Mar 2005 09:05:30 - 1.26
+++ src/mathed/math_amsarrayinset.C 31 Mar 2005 17:11:36 -
@@ -17,8 +17,19 @@
#include "math_streamstr.h"
#include "math_support.h"
+#include "cursor.h"
+#include "funcrequest.h"
+#include "FuncStatus.h"
+#include "gettext.h"
+#include "undo.h"
+
+#include "support/lstrings.h"
+#include "support/std_ostream.h"
+
+
using std::string;
using std::auto_ptr;
+using lyx::support::bformat;
MathAMSArrayInset::MathAMSArrayInset(string const & name, int m, int n)
@@ -90,11 +101,57 @@ void MathAMSArrayInset::draw(PainterInfo
}
+void MathAMSArrayInset::doDispatch(LCursor & cur, FuncRequest & cmd)
+{
+ switch (cmd.action) {
+ case LFUN_TABULAR_FEATURE: {
+ recordUndo(cur);
+ string const s = cmd.argument;
+ if (s == "add-vline-left" || s == "add-vline-right") {
+ cur.undispatched();
+ break;
+ }
+ }
+ default:
+ MathGridInset::doDispatch(cur, cmd);
+ }
+}
+
+
+bool MathAMSArrayInset::getStatus(LCursor & cur, FuncRequest const & cmd,
+ FuncStatus & flag) const
+{
+ switch (cmd.action) {
+ case LFUN_TABULAR_FEATURE: {
+ string const s = cmd.argument;
+ if (s == "add-vline-left" || s == "add-vline-right") {
+ flag.message(bformat(
+ N_("Can't add vertical grid lines in '%1$s'"),
+name_));
+ flag.enabled(false);
+ return true;
+ }
+ return MathGridInset::getStatus(cur, cmd, flag);
+ }
+ default:
+ return MathGridInset::getStatus(cur, cmd, flag);
+}
+}
+
+
void MathAMSArrayInset::write(WriteStream & os) const
{
os << "\\begin{" << name_ << '}';
MathGridInset::write(os);
os << "\\end{" << name_ << '}';
+}
+
+
+void MathAMSArrayInset::infoize(std::ostream & os) const
+{
+ string name = name_;
+ name[0] = lyx::support::uppercase(name[0]);
+ os << name << ' ';
}
Index: src/mathed/math_amsarrayinset.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_amsarrayinset.h,v
retrieving revision 1.19
diff -u -p -r1.19 math_amsarrayinset.h
--- src/mathed/math_amsarrayinset.h 30 Mar 2005 09:05:30 - 1.19
+++ src/mathed/math_amsarrayinset.h 31 Mar 2005 17:11:36 -
@@ -32,7 +32,14 @@ public:
MathAMSArrayInset const * asAMSArrayInset() const { return this; }
///
+ virtual void doDispatch(LCursor & cur, FuncRequest & cmd);
+ ///
+ bool get
Re: appendix again
Georg Baum wrote: > The attached patch adds a dummy comment to prevent the deletion of the > empty paragraph. I don't like this, but neither the current solution nor > the previous one handle \appendix commands as written by LyX correctly. > Unfortunately I have no idea how to do this better at the moment, so I > propose to apply this patch. It is in now. Georg
Re: [patch] new scrollbar code
Andreas Vox wrote: > Georg Baum <[EMAIL PROTECTED]> writes: > >> - Create a document with some paragraphs (~20, only text, one line each) >> - resize the main window to the smallest possible height >> - drag the scrollbar from top to bottom. It will not follow the cursor >> immediately, and if you don't drag it to the lowest possible position it >> will jump back to the top. It will also jump back if you drag it to the >> end, but will afterwards jump to the bottom. > > I see similar behaviour without the patch. If I drag the scrollbar down it > will jump back up again. Maybe not all the way, but still annoying (tested > with UserGuide). I rechecked with a clean build and get indeed the same behaviour. > I have Qt 3.3.3 on Mac and preview on (haven't seen this mentioned in > earlier posts, but it might be useful to consider this setting when > comparing results). Switching this on or off makes no difference for me. > Re small documents: > > I made a CV recently which consisted of just a table and a picture on top. > Although it was larger than the screen size I didn't get any scrollbar at > all! > (still without the patch) That's clearly unacceptable. This is a known problem of the current code and one of the reasons to change it. Georg
Re: [Patch] fixing error message positioning
On Wed, 2005-03-30 at 15:46, Jean-Marc Lasgouttes wrote: > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > > Martin> Patch attached. Error positioning works now perfectly even at > Martin> the end of my 300+ page production test document, containing a > Martin> mix of traditional and external material graphics. > > Looks fine to me, although the int() casts are really ugly... But I > know it is not your doing. > > JMarc This is in now. - Martin signature.asc Description: This is a digitally signed message part
Re: Towards LyX 1.3.6 [status update #1]
On Thu, 2005-03-31 at 15:56, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Make a small text file in which you embed the attached XFig
> Martin> figure as an external inset. Then insert an erroneous ERT,
> Martin> (e.g. \crash) both in the paragraph before and the one after
> Martin> it; run LaTeX and see if the error boxes land right.
>
> Everything seems allright with this patch. Does anybody have
> objections? This is 1.3.x-only.
>
> JMarc
>
> PS: actually I had some problems with your .fig file:
> 1/ I had to add \usepackage{color} in the preamble. Is this
> expected?
Ah yes, I used coloured text. Don't suppose this can be easily validated
for.
> 2/ when there is an error in the pstex_t file, the log analyzer
> believes that the error is in the main file and thus misuses line
> numbers. This is very confusing...
--
Martin Vermeer [EMAIL PROTECTED]
Helsinki University of Technology
Dept. of Surveying, Inst. of Geodesy
P.O. Box 1200, FIN-02015 HUT, Finland
signature.asc
Description: This is a digitally signed message part
Re: [patch] new scrollbar code
Alfredo Braunstein wrote: I think you didn't understand what I suggested. I suggested to do a fullrebreak on start (foreground or background) and then keep outer paragraphs sizes. Only update sizes when drawing paragraphs on-screen, and live with outdated sizes for out-of-screen outer paragraphs. I think that this may work very well. I agree that this will help a lot, especially if the clipboard does not throw away the sizes of full paragraphs copied/pasted. And when the window is resized, we need a full rebreak like in the old days. Regards, Asger
Re: [patch] new scrollbar code
John Levon wrote: > Hmm, I wonder if we could rebreak in full below a certain document size. > This would fix the most apparent breakages whilst still giving us the > load time boost we need for big docs (where we use the approximation). > An idea? Interesting... Alfredo
Re: Towards LyX 1.3.6 [status update #1]
Jean-Marc Lasgouttes wrote:
> PS: actually I had some problems with your .fig file:
> 1/ I had to add \usepackage{color} in the preamble. Is this
> expected?
It's pretty common, although it is possible to create XFig figures that
don't require color.
--
Angus
Re: [rework docs] a new round of asking and proposing - part two: proposals 1-5
> "G" == G Milde <[EMAIL PROTECTED]> writes: G> It would be nice, if we had a lyx-function "view-or-update" (with G> arguments dvi, ps, or pdf) that just updates if there is an open G> viewer for the current buffers document. G> This could save us one keybinding and enable the "view/update dvi" G> button missed by the test users. It is probably a bit difficult to do at LyX level. What we need is to find applications that know how to do that by themselves (like firefox for html, for example). JMarc
[PATCHes] Correctly translate getStatus result
I getStatus we set the error messages using N_(), so that we can transmit the English version to the lyxserver. However, we do not do the translation before displaying in the minibuffer... The following pair of patches fixes that. OK? JMarc Index: src/ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v retrieving revision 1.1021.2.76 diff -u -p -r1.1021.2.76 ChangeLog --- src/ChangeLog 29 Mar 2005 14:17:57 - 1.1021.2.76 +++ src/ChangeLog 30 Mar 2005 14:22:09 - @@ -1,3 +1,8 @@ +2005-03-30 Jean-Marc Lasgouttes <[EMAIL PROTECTED]> + + * lyxfunc.C (dispatch): translate message before sending it to the + minibuffer. + 2005-03-29 Angus Leeming <[EMAIL PROTECTED]> * lyx_main.C (c-tor): call os::internal_path on each file passed Index: src/lyxfunc.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxfunc.C,v retrieving revision 1.394.2.9 diff -u -p -r1.394.2.9 lyxfunc.C --- src/lyxfunc.C 24 Feb 2005 11:47:33 - 1.394.2.9 +++ src/lyxfunc.C 30 Mar 2005 14:22:09 - @@ -1539,7 +1539,7 @@ void LyXFunc::dispatch(FuncRequest const } // end of switch exit_with_message: - sendDispatchMessage(getMessage(), ev, verbose); + sendDispatchMessage(_(getMessage()), ev, verbose); } Index: src/ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v retrieving revision 1.2145 diff -u -p -r1.2145 ChangeLog --- src/ChangeLog 29 Mar 2005 14:47:53 - 1.2145 +++ src/ChangeLog 31 Mar 2005 13:19:53 - @@ -1,3 +1,8 @@ +2005-03-30 Jean-Marc Lasgouttes <[EMAIL PROTECTED]> + + * lyxfunc.C (dispatch): translate message before sending it to the + minibuffer. + 2005-03-29 Angus Leeming <[EMAIL PROTECTED]> * lyx_main.C (priv_exec): call os::internal_path on each file passed Index: src/lyxfunc.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxfunc.C,v retrieving revision 1.649 diff -u -p -r1.649 lyxfunc.C --- src/lyxfunc.C 7 Mar 2005 11:03:44 - 1.649 +++ src/lyxfunc.C 31 Mar 2005 13:19:53 - @@ -1495,7 +1495,7 @@ void LyXFunc::dispatch(FuncRequest const view()->owner()->updateLayoutChoice(); } } - sendDispatchMessage(getMessage(), cmd); + sendDispatchMessage(_(getMessage()), cmd); }
Re: [patch] new scrollbar code
On Thu, Mar 31, 2005 at 02:05:38PM +0200, Alfredo Braunstein wrote: > > Fair enough. I suspect the real answer is full rebreaking... > > Always optimitic, huh? Hmm, I wonder if we could rebreak in full below a certain document size. This would fix the most apparent breakages whilst still giving us the load time boost we need for big docs (where we use the approximation). An idea? regards john
Re: [rework docs] a new round of asking and proposing - part two: proposals 1-5
On 27.03.05, Uwe Stöhr wrote: > 1. The last months I teached LyX to some colleagues and they all > complained that there is no button in the toolbar for "view/update dvi". > Therefore I designed a new toolbar with new buttons. It looks like in > the attached file toolbar.png. I added two buttons for dvi > ... It would be nice, if we had a lyx-function "view-or-update" (with arguments dvi, ps, or pdf) that just updates if there is an open viewer for the current buffers document. This could save us one keybinding and enable the "view/update dvi" button missed by the test users. Is such a function feasible? (Please invent a better name for it.) Guenter -- G.Milde web.de
Re: [patch] new scrollbar code
Georg Baum wrote: > Alfredo Braunstein wrote: > >> Georg Baum wrote: >> >> You mean pagedown on the keyboard, or clicking on the scrollbar >> background (i.e. scrollbar pgdown) > > I mean the key on the keyboard. Ah ok. But I think this is unrelated. Regards, Alfredo
Re: [patch] new scrollbar code
Georg Baum <[EMAIL PROTECTED]> writes: > > Alfredo Braunstein wrote: ... > > Could you describe some behaviour you find weird in a few steps? Thanks. > > - Create a document with some paragraphs (~20, only text, one line each) > - resize the main window to the smallest possible height > - drag the scrollbar from top to bottom. It will not follow the cursor > immediately, and if you don't drag it to the lowest possible position it > will jump back to the top. It will also jump back if you drag it to the > end, but will afterwards jump to the bottom. I see similar behaviour without the patch. If I drag the scrollbar down it will jump back up again. Maybe not all the way, but still annoying (tested with UserGuide). I have Qt 3.3.3 on Mac and preview on (haven't seen this mentioned in earlier posts, but it might be useful to consider this setting when comparing results). Re small documents: I made a CV recently which consisted of just a table and a picture on top. Although it was larger than the screen size I didn't get any scrollbar at all! (still without the patch) That's clearly unacceptable. Cheers /Andreas
Re: Towards LyX 1.3.6 [status update #1]
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Make a small text file in which you embed the attached XFig
Martin> figure as an external inset. Then insert an erroneous ERT,
Martin> (e.g. \crash) both in the paragraph before and the one after
Martin> it; run LaTeX and see if the error boxes land right.
Everything seems allright with this patch. Does anybody have
objections? This is 1.3.x-only.
JMarc
PS: actually I had some problems with your .fig file:
1/ I had to add \usepackage{color} in the preamble. Is this
expected?
2/ when there is an error in the pstex_t file, the log analyzer
believes that the error is in the main file and thus misuses line
numbers. This is very confusing...
Index: src/insets/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/ChangeLog,v
retrieving revision 1.552.2.22
diff -u -p -r1.552.2.22 ChangeLog
--- src/insets/ChangeLog 7 Mar 2005 14:03:08 - 1.552.2.22
+++ src/insets/ChangeLog 31 Mar 2005 12:51:37 -
@@ -1,3 +1,11 @@
+2005-03-31 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
+
+ * insetgraphics.C (latex): fix off-by-one error in number of
+ newlines.
+
+ * insetexternal.C (write): compute correctly the number of lines
+ in output.
+
2005-02-26 Michael Schmitt <[EMAIL PROTECTED]>
* insetbib.C: change screen label
Index: src/insets/insetexternal.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetexternal.C,v
retrieving revision 1.53.2.4
diff -u -p -r1.53.2.4 insetexternal.C
--- src/insets/insetexternal.C 10 Jan 2005 19:17:30 - 1.53.2.4
+++ src/insets/insetexternal.C 31 Mar 2005 12:51:37 -
@@ -26,6 +26,7 @@
#include "support/filetools.h"
#include "support/forkedcall.h"
#include "support/lstrings.h"
+#include "support/lyxalgo.h"
#include "support/package.h"
#include "support/path.h"
@@ -146,8 +147,9 @@ int InsetExternal::write(string const &
}
updateExternal(format, buf);
- os << doSubstitution(buf, cit->second.product);
- return 0; // CHECK (FIXME check what ? - jbl)
+ string const outstring = doSubstitution(buf, cit->second.product);
+ os << outstring;
+ return lyx::count(outstring.begin(), outstring.end(), '\n');
}
Index: src/insets/insetgraphics.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetgraphics.C,v
retrieving revision 1.146.2.6
diff -u -p -r1.146.2.6 insetgraphics.C
--- src/insets/insetgraphics.C 10 Jan 2005 19:17:30 - 1.146.2.6
+++ src/insets/insetgraphics.C 31 Mar 2005 12:51:37 -
@@ -779,10 +779,7 @@ int InsetGraphics::latex(Buffer const *b
os << latex_str;
// Return how many newlines we issued.
- int const newlines =
- int(lyx::count(latex_str.begin(), latex_str.end(),'\n') + 1);
-
- return newlines;
+ return int(lyx::count(latex_str.begin(), latex_str.end(),'\n'));
}
Re: [patch] new scrollbar code
Asger Alstrup wrote: >> Well, we could just keep (maybe outdated) paragraphs sizes, and just >> update on-screen ones when drawing. Then the scrollbar computation would >> be only a loop over all outer paragraphs. > > Only looking at outer paragraphs ignores the two most important ones. I think you didn't understand what I suggested. I suggested to do a fullrebreak on start (foreground or background) and then keep outer paragraphs sizes. Only update sizes when drawing paragraphs on-screen, and live with outdated sizes for out-of-screen outer paragraphs. I think that this may work very well. Regards, Alfredo
Re: [patch] new scrollbar code
Angus Leeming wrote: > I haven't been following this thread very closely, but isn't the problem > one of calculating the length of the document when it is first loaded? > Thereafter, the scrollbar would change size only when the document was > modified. (This could happen just by scrolling through a read-only > document I guess as figures are loaded and therefore the graphics inset > changes size.) > > Alfredo, would it be expensive to do a one time, accurate calculation of > the document height? If so, why? Would use of the nullpainter help? It's not terribly expensive, a fullRebreak of the UG is a matter of about a second on some fast computer (1.3.x does that on loading, and there is some loading time where it just said "rebreaking document" or something). We don't need the second drawing step, as all vertical height can be computed in the metrics phase. The problem, as Asger pointed out, is to mantain this information up-to-date. Think for instance of a change in evironment-depth, that may affect several screens down of paragrahs. IMO, though, we can live with 'old data size', and only update the information when drawing on screen. I may try to implement something like that this weekend. Regards, Alfredo
Re: [patch] new scrollbar code
Alfredo Braunstein wrote: > Georg Baum wrote: > > You mean pagedown on the keyboard, or clicking on the scrollbar background > (i.e. scrollbar pgdown) I mean the key on the keyboard. Georg
Re: Towards LyX 1.3.6 [status update #1]
Asger Alstrup wrote: >> And if there are two different "My file.lyx" with different paths? I'd >> suggest doing as emacs does in such a case and display >> >>My file.lyx >>My file.lyx<2> > > The convention is to use "My file.lyx (2)", but this is best. Hmmm. What we're suggesting here is allowing MakeDisplayPath to interrogate the list of available buffers. The function is used 52 times in LyX 1.3.x. I really don't want to change its signature to pass it this list. The alternative is to all the function to access the global list as extern BufferList bufferlist; but that is ugly, ugly, ugly. H. I think I'm going to leave things as they are for now. I don't consider current behaviour to be a serious problem and I really don't want to break anything in making such a change. > Excel for instance simply disallows opening a second document with the > same name, although the path is different. I guess they have found that > people mix up and ruin their work when they have two identically named > documents open. We tend to assume that people are intelligent and proceed from there. Maybe that's not the MS way, but I'd hate to change it. -- Angus
Re: [patch] new scrollbar code
Alfredo Braunstein wrote: Small documents are important too. Sure, I am only noting that it is a feature that only *exists* in small documents. Thus, it cannot be so fundamentally important. It serves as important feedback on the size of the document. Well, we could just keep (maybe outdated) paragraphs sizes, and just update on-screen ones when drawing. Then the scrollbar computation would be only a loop over all outer paragraphs. Since you mentioned that tables are the biggest problem, I would suggest to come up with a light-weight improved estimate for those, and see how much that helps. Then address images next. I.e. go down the path outlined in my earlier mail, except that the priorities are: - Tables - Images - Paragraph text size - Other stuff Only looking at outer paragraphs ignores the two most important ones. Regards, Asger
Re: [patch] new scrollbar code
Alfredo Braunstein wrote: >>> I believe it is monotoneously better to estimate all figures at say >>> 200x200 pixels, rather than at 0x0 pixels like it does now. >> >> Well, perhaps, but I doubt it significantly helps. >> >>> My point is that this estimation routine can be continuously refined >>> until it represents a complete rendering of the paragraph. We need to >>> try and find out how fine-grained the estimate has to be in order for >>> the scroll bar to be usable. >> >> Fair enough. I suspect the real answer is full rebreaking... > > Always optimitic, huh? I haven't been following this thread very closely, but isn't the problem one of calculating the length of the document when it is first loaded? Thereafter, the scrollbar would change size only when the document was modified. (This could happen just by scrolling through a read-only document I guess as figures are loaded and therefore the graphics inset changes size.) Alfredo, would it be expensive to do a one time, accurate calculation of the document height? If so, why? Would use of the nullpainter help? -- Angus
Problem with lyx
Please can you help me? My system is Windows 2000 and when I try to run Lyx 1.3.3, for the first time, I receive the message: Lyx wasn´t able to find any layout description! Check the contents of the file "textclass.lst" Sorry has to exit Thanks, Carlos H. Klein
Re: [patch] new scrollbar code
Asger Alstrup wrote: > Alfredo Braunstein wrote: >> I'm not sure about that. Specially since there's no difference in the >> scrollbar size in a mid-sized document vs a big document like UG, because >> most toolkits have a minimum size for the widget. > > Small documents are important too. Sure, I am only noting that it is a feature that only *exists* in small documents. Thus, it cannot be so fundamentally important. >> It shouldn't jump at all (otherwise is just a bug). > > The size should not change more than a few pixels either. > >> Constant time per paragraph, O(number of paragraphs) total time > > And can't we afford this? If so, our paragraph list traversal sucks and > should be changed. I wasn't saying anything about affordability, just clarifying that we need to compute the size of all paragraphs, not only onscreen ones. >> The biggest problem seems to be very high insets, like long tabulars > > Great, then try to address those, and see what is the next problem. This > is exactly the approach I'm advocating. > >> This could be, the question is how to do this consistently. >> Otherwise we will always have problems with corner cases. > > It is still monotoneously better than ignoring the problem. Hey, don be so picky. I'm very glad we are discussing this, it is certainly much better than ignoring the problem. >>>Ultimately, if such patching up does not fix the problem, we have to >>>admit that it was a mistake, and introduce full document word breaking >>>again. >> >> It may be, but I am afraid that we cannot afford this. > > We used to be able to afford it, so it is affordable. It might not be > feasible with the current rewritten core, but then the rewrite is not > complete or a failure. I was talking in terms of man-power. >> An alternative you didn't mention would be to have background computation >> of the exact size (including full rebreak etc). > > This is similar to what web-browsers do as they receive the data, so that > might be acceptable. But I thought the problem was that keeping the data > up-to-date as the document changes is the problem? You will not avoid that > can of worms with background rebreak. Well, we could just keep (maybe outdated) paragraphs sizes, and just update on-screen ones when drawing. Then the scrollbar computation would be only a loop over all outer paragraphs. Regards, Alfredo
Re: [patch] new scrollbar code
Hi Georg, Georg Baum wrote: > Alfredo Braunstein wrote: > >> The fact that it resizes itself is normal (altough the resizing should be >> smooth). It shouldn't jump. I don't understand if both of you are seeing >> the same behaviour as I do and find it ugly or if you are seeing >> something different. > > I am actually not sure if it is all the same. It seems different indeed. >> Could you describe some behaviour you find weird in a few steps? Thanks. > > - Create a document with some paragraphs (~20, only text, one line each) > - resize the main window to the smallest possible height > - drag the scrollbar from top to bottom. It will not follow the cursor > immediately, and if you don't drag it to the lowest possible position it > will jump back to the top. It will also jump back if you drag it to the > end, but will afterwards jump to the bottom. This is very strange, I cannot reproduce. > I see also the jumping and getting stuck when pressing PgDown that John > observed. You mean pagedown on the keyboard, or clicking on the scrollbar background (i.e. scrollbar pgdown) > BTW, this is qt 3.3.3 (stock SuSE 9.2) and yor second version of the > patch. This is qt-3.3.4-0.fc3.0 on fc3. >>> Resizing the main window does not work properly: The scrollbar height is >>> not updated when I resize the window at the top border (see image) >>> resizing at the bottom works. >> >> Truly weird. > > This happens with both qt 3.4 and 3.3.3 Cannot reproduce either. Regards, Alfredo PS: in any case, your test case should be one of these in which the scheme works fine (all paragraphs are equal in vertical size). So I find this really strange.
Re: [patch] new scrollbar code
Alfredo Braunstein wrote: I'm not sure about that. Specially since there's no difference in the scrollbar size in a mid-sized document vs a big document like UG, because most toolkits have a minimum size for the widget. Small documents are important too. It shouldn't jump at all (otherwise is just a bug). The size should not change more than a few pixels either. Constant time per paragraph, O(number of paragraphs) total time And can't we afford this? If so, our paragraph list traversal sucks and should be changed. The biggest problem seems to be very high insets, like long tabulars Great, then try to address those, and see what is the next problem. This is exactly the approach I'm advocating. This could be, the question is how to do this consistently. Otherwise we will always have problems with corner cases. It is still monotoneously better than ignoring the problem. Ultimately, if such patching up does not fix the problem, we have to admit that it was a mistake, and introduce full document word breaking again. It may be, but I am afraid that we cannot afford this. We used to be able to afford it, so it is affordable. It might not be feasible with the current rewritten core, but then the rewrite is not complete or a failure. An alternative you didn't mention would be to have background computation of the exact size (including full rebreak etc). This is similar to what web-browsers do as they receive the data, so that might be acceptable. But I thought the problem was that keeping the data up-to-date as the document changes is the problem? You will not avoid that can of worms with background rebreak. Regards, Asger
Re: [patch] new scrollbar code
John Levon wrote: > On Thu, Mar 31, 2005 at 01:54:11PM +0200, Asger Alstrup wrote: > >> I believe it is monotoneously better to estimate all figures at say >> 200x200 pixels, rather than at 0x0 pixels like it does now. > > Well, perhaps, but I doubt it significantly helps. > >> My point is that this estimation routine can be continuously refined >> until it represents a complete rendering of the paragraph. We need to try >> and find out how fine-grained the estimate has to be in order for the >> scroll bar to be usable. > > Fair enough. I suspect the real answer is full rebreaking... Always optimitic, huh? ;-) Alfredo
Re: Towards LyX 1.3.6 [status update #1]
> "Asger" == Asger Alstrup <[EMAIL PROTECTED]> writes: Asger> The tradition about displaying nice paths on windows does not Asger> exist: Either you do the complicated: Asger>C:\Documents and settings\alstrup\My documents\My file.lyx Asger> C:\Documents and settings\alstrup\Desktop\My second file.lyx Asger> C:\My third file.lyx Asger> or you ignore the path and just do (like all the Microsoft Asger> tools including Office does) Asger>My file.lyx My second file.lyx My third file.lyx OK, sorry, I have been mistaken... I though there was a simplified shorthand notation like C:\My Documents\ that points to the full path. This is wrong obviously (I just checked under windows 2000, which is all I have). JMarc
Re: [patch] new scrollbar code
Alfredo Braunstein wrote: > The fact that it resizes itself is normal (altough the resizing should be > smooth). It shouldn't jump. I don't understand if both of you are seeing > the same behaviour as I do and find it ugly or if you are seeing something > different. I am actually not sure if it is all the same. > Could you describe some behaviour you find weird in a few steps? Thanks. - Create a document with some paragraphs (~20, only text, one line each) - resize the main window to the smallest possible height - drag the scrollbar from top to bottom. It will not follow the cursor immediately, and if you don't drag it to the lowest possible position it will jump back to the top. It will also jump back if you drag it to the end, but will afterwards jump to the bottom. I see also the jumping and getting stuck when pressing PgDown that John observed. BTW, this is qt 3.3.3 (stock SuSE 9.2) and yor second version of the patch. >> Resizing the main window does not work properly: The scrollbar height is >> not updated when I resize the window at the top border (see image) >> resizing at the bottom works. > > Truly weird. This happens with both qt 3.4 and 3.3.3 Georg
Re: [patch] new scrollbar code
On Thu, Mar 31, 2005 at 01:54:11PM +0200, Asger Alstrup wrote: > I believe it is monotoneously better to estimate all figures at say 200x200 > pixels, rather than at 0x0 pixels like it does now. Well, perhaps, but I doubt it significantly helps. > My point is that this estimation routine can be continuously refined until > it represents a complete rendering of the paragraph. We need to try and > find out how fine-grained the estimate has to be in order for the scroll > bar to be usable. Fair enough. I suspect the real answer is full rebreaking... regards john
Re: Towards LyX 1.3.6 [status update #1]
Angus Leeming wrote: Asger Alstrup wrote: The tradition about displaying nice paths on windows does not exist: So you think that having such functionality is a bad thing for LyX/Win? The only real problem here seems to be the ~ abbreviation. Well, it is not necessarily a bad thing, but it is not a tradition, and therefore people will find it strange. I think we should go for the second option. or you ignore the path and just do (like all the Microsoft tools including Office does) My file.lyx My second file.lyx My third file.lyx And if there are two different "My file.lyx" with different paths? I'd suggest doing as emacs does in such a case and display My file.lyx My file.lyx<2> The convention is to use "My file.lyx (2)", but this is best. Excel for instance simply disallows opening a second document with the same name, although the path is different. I guess they have found that people mix up and ruin their work when they have two identically named documents open. Regards, Asger
Re: [patch] new scrollbar code
John Levon wrote:
To improve further, consider the insets in the paragraph by having a
default size for each type and take that into account. Now, we are linear
There's no such thing as a linear size for figures, so this is
guaranteed to go wrong in the worst possible cases (very large figures).
I believe it is monotoneously better to estimate all figures at say 200x200
pixels, rather than at 0x0 pixels like it does now.
The linear bit in my sentence refers to the time it takes to estimate the
height of a paragraph: The algorithm is roughly something like this:
int x = 0;
int y = average-character-height;
for (int i = 0; i != numberOfInsets-in-paragraph; ++i) {
// First estimate size of the text
x += average-character-width
* number-of-characters-in-paragraph
/ numberOfInsets-in-paragraph;
y += (x / width-available) * average-character-height;
x = x % width-available;
// Next estimate size of the insets
x += average-width-of-inset-at-position(i);
if (x > width-available) {
y += average-height;
x = x % width-available;
}
}
Notice small constant factors and linear time in number of insets. That
should be fast enough, and improve tremendously on a totally static estimate.
My point is that this estimation routine can be continuously refined until
it represents a complete rendering of the paragraph. We need to try and
find out how fine-grained the estimate has to be in order for the scroll
bar to be usable.
Regards,
Asger
Re: [patch] new scrollbar code
Asger Alstrup wrote: > I believe that a fixed sized scroll bar is a significant regression in > terms of usability. I'm not sure about that. Specially since there's no difference in the scrollbar size in a mid-sized document vs a big document like UG, because most toolkits have a minimum size for the widget. > Also, I think that a very unreliable scroll bar is a problem. The scroll > bar can change a few pixels, but if it jumps much more than that, it is > confusing. It shouldn't jump at all (otherwise is just a bug). > I did not test the new scrollbar, but if you use a uniform estimated size > on all paragraphs, I think the obvious thing is to improve this by > estimating the height as a function of the number of characters in the > paragraph and the width available for the paragraph. You can define a > function for this which calculates in constant time by using mean values > for the character width and word length. Constant time per paragraph, O(number of paragraphs) total time > To improve further, consider the insets in the paragraph by having a > default size for each type and take that into account. Now, we are linear > time in the number of insets, but no loading or rendering of insets are > necessary to get the estimate, so it is still very fast. The biggest problem seems to be very high insets, like long tabulars > If this is still not accurate enough, then I'd go for better handling of > the biggest elements that can appear in a document: images, tables and > such. This could be, the question is how to do this consistently. Otherwise we will always have problems with corner cases. > Ultimately, if such patching up does not fix the problem, we have to admit > that it was a mistake, and introduce full document word breaking again. It may be, but I am afraid that we cannot afford this. > The scrollbar is one of the single most important features in a word > processor. You use it all the time. You want that to be reliable and not > seem strange. Sure, it is important. The problem is if what we have is good enough or not. An alternative you didn't mention would be to have background computation of the exact size (including full rebreak etc). Alfredo
Re: Towards LyX 1.3.6 [status update #1]
Asger Alstrup wrote: > The tradition about displaying nice paths on windows does not exist: So you think that having such functionality is a bad thing for LyX/Win? The only real problem here seems to be the ~ abbreviation. > Either you do the complicated: > >C:\Documents and settings\alstrup\My documents\My file.lyx >C:\Documents and settings\alstrup\Desktop\My second file.lyx >C:\My third file.lyx Not a good solution. This thing is meant to be displayed on the Window header. > or you ignore the path and just do (like all the Microsoft tools > including Office does) > >My file.lyx >My second file.lyx >My third file.lyx And if there are two different "My file.lyx" with different paths? I'd suggest doing as emacs does in such a case and display My file.lyx My file.lyx<2> > You never want to present the 8.3 name. Agreed. -- Angus
Re: [patch] new scrollbar code
On Thu, Mar 31, 2005 at 01:08:48PM +0200, Asger Alstrup wrote: > I believe that a fixed sized scroll bar is a significant regression in > terms of usability. Asger, we lost the ability to have a properly working scrollbar after the core rewrite. I'm sure there are reasons it's difficult to do this, so I am afraid we are stuck with it, and complaining will only irritate people (usually my forte) The question is how can we salvage the situation to make it as good as we can. > To improve further, consider the insets in the paragraph by having a > default size for each type and take that into account. Now, we are linear There's no such thing as a linear size for figures, so this is guaranteed to go wrong in the worst possible cases (very large figures). regards john
Re: [patch] new scrollbar code
On Thu, Mar 31, 2005 at 11:12:51AM +0200, Alfredo Braunstein wrote: > This is easy. OTOH, I'm a bit confused by your 'unusable'. Setting the > widget to fixed size would make no difference in useability AFAICS. Having the widget constantly change size on you is extremely disconcerting. > qt version? Please give detailed instructions. Later regards john
Re: Towards LyX 1.3.6 [status update #1]
The tradition about displaying nice paths on windows does not exist: Either you do the complicated: C:\Documents and settings\alstrup\My documents\My file.lyx C:\Documents and settings\alstrup\Desktop\My second file.lyx C:\My third file.lyx or you ignore the path and just do (like all the Microsoft tools including Office does) My file.lyx My second file.lyx My third file.lyx You never want to present the 8.3 name. Regards, Asger
Re: [patch] new scrollbar code
I believe that a fixed sized scroll bar is a significant regression in terms of usability. Also, I think that a very unreliable scroll bar is a problem. The scroll bar can change a few pixels, but if it jumps much more than that, it is confusing. I did not test the new scrollbar, but if you use a uniform estimated size on all paragraphs, I think the obvious thing is to improve this by estimating the height as a function of the number of characters in the paragraph and the width available for the paragraph. You can define a function for this which calculates in constant time by using mean values for the character width and word length. To improve further, consider the insets in the paragraph by having a default size for each type and take that into account. Now, we are linear time in the number of insets, but no loading or rendering of insets are necessary to get the estimate, so it is still very fast. If this is still not accurate enough, then I'd go for better handling of the biggest elements that can appear in a document: images, tables and such. Ultimately, if such patching up does not fix the problem, we have to admit that it was a mistake, and introduce full document word breaking again. The scrollbar is one of the single most important features in a word processor. You use it all the time. You want that to be reliable and not seem strange. Regards, Asger
Re: [patch] new scrollbar code
Alfredo Braunstein wrote:
>>> Dragging the scrollbar on the Qt frontend is very broken (I tried with
>>> small document). It constantly resizes itself, jumps about. etc
>>
>> I see this, too (also qt).
>
> The fact that it resizes itself is normal (altough the resizing should be
> smooth). It shouldn't jump. I don't understand if both of you are seeing
> the same behaviour as I do and find it ugly or if you are seeing something
> different.
>
> Could you describe some behaviour you find weird in a few steps? Thanks.
In case we are testing different things, here's an updated patch. It
suffices to uncomment the commented line in WorkArea.C:78 to test a
fixed-size widget scrollbar.
Regards, Alfredo
Index: BufferView.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.C,v
retrieving revision 1.260
diff -u -p -u -r1.260 BufferView.C
--- BufferView.C 22 Feb 2005 11:41:19 - 1.260
+++ BufferView.C 31 Mar 2005 10:00:28 -
@@ -148,12 +148,6 @@ void BufferView::update(bool fitcursor,
}
-void BufferView::updateScrollbar()
-{
- pimpl_->updateScrollbar();
-}
-
-
void BufferView::scrollDocView(int value)
{
pimpl_->scrollDocView(value);
Index: BufferView.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.h,v
retrieving revision 1.185
diff -u -p -u -r1.185 BufferView.h
--- BufferView.h 22 Feb 2005 11:41:19 - 1.185
+++ BufferView.h 31 Mar 2005 10:00:28 -
@@ -85,8 +85,6 @@ public:
/// move the screen to fit the cursor. Only to be called with
/// good y coordinates (after a bv::metrics)
bool fitCursor();
- /// reset the scrollbar to reflect current view position
- void updateScrollbar();
/// FIXME
bool available() const;
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.580
diff -u -p -u -r1.580 BufferView_pimpl.C
--- BufferView_pimpl.C 25 Feb 2005 11:55:29 - 1.580
+++ BufferView_pimpl.C 31 Mar 2005 10:00:29 -
@@ -100,7 +100,6 @@ using std::string;
using std::mem_fun_ref;
using std::vector;
-
extern BufferList bufferlist;
@@ -113,6 +112,10 @@ unsigned int const saved_positions_num =
// to these connections we avoid a segfault upon startup, and also at exit.
// (Lgb)
+boost::signals::connection pagedowncon;
+boost::signals::connection pageupcon;
+boost::signals::connection lineupcon;
+boost::signals::connection linedowncon;
boost::signals::connection dispatchcon;
boost::signals::connection timecon;
boost::signals::connection doccon;
@@ -152,6 +155,15 @@ BufferView::Pimpl::Pimpl(BufferView & bv
// Setup the signals
doccon = workarea().scrollDocView
.connect(boost::bind(&BufferView::Pimpl::scrollDocView, this, _1));
+ pageupcon = workarea().scrollPageUp
+ .connect(boost::bind(&BufferView::Pimpl::scrollPageUp, this));
+
+ pagedowncon = workarea().scrollPageDown
+ .connect(boost::bind(&BufferView::Pimpl::scrollPageDown, this));
+ lineupcon = workarea().scrollLineUp
+ .connect(boost::bind(&BufferView::Pimpl::scrollLineUp, this));
+ linedowncon = workarea().scrollLineDown
+ .connect(boost::bind(&BufferView::Pimpl::scrollLineDown, this));
resizecon = workarea().workAreaResize
.connect(boost::bind(&BufferView::Pimpl::workAreaResize, this));
dispatchcon = workarea().dispatch
@@ -365,7 +377,6 @@ void BufferView::Pimpl::setBuffer(Buffer
}
update();
- updateScrollbar();
owner_->updateMenubar();
owner_->updateToolbars();
owner_->updateLayoutChoice();
@@ -399,16 +410,15 @@ void BufferView::Pimpl::resizeCurrentBuf
// Reset the "Formatting..." message
owner_->clearMessage();
- updateScrollbar();
}
-void BufferView::Pimpl::updateScrollbar()
+void BufferView::Pimpl::updateScrollbar(ViewMetricsInfo const & vi)
{
if (!bv_->text()) {
lyxerr[Debug::DEBUG] << BOOST_CURRENT_FUNCTION
<< " no text in updateScrollbar" << endl;
- workarea().setScrollbarParams(0, 0, 0);
+ workarea().setScrollbarParams(0, 0);
return;
}
@@ -424,35 +434,71 @@ void BufferView::Pimpl::updateScrollbar(
<< " curr par: " << cursor_.bottom().pit()
<< " default height " << defaultRowHeight() << endl;
- // It would be better to fix the scrollbar to understand
- // values in [0..1] and divide everything by wh
- int const wh = workarea().workHeight() / 4;
- int const h = t.getPar(anchor_ref_).height();
- workarea().setScrollbarParams(t.paragraphs().size() * wh, anchor_ref_ * wh + int(offset_ref_ * wh / float(h)), int (wh * defaultRowHeight() / float(h)));
-// workarea().setScrollbarParams(t.paragraphs().size(), anchor_ref_, 1);
+ int const h1 = t.getPar(vi.p1).height();
+ int const h2 = t.getPar(vi.p2).height();
+ double const chop1 = (- vi.y1) / double(h1);
+ double const chop2 = (vi.y2 - workarea().workHeight()) / double(h2);
+ double const tot = t.paragraphs().
Re: [patch] new scrollbar code
Georg Baum wrote: > Am Mittwoch, 30. MÃrz 2005 19:51 schrieb John Levon: >> On Wed, Mar 30, 2005 at 04:28:11PM +0200, Alfredo Braunstein wrote: >> >> > Lots of testing needed... >> >> Dragging the scrollbar on the Qt frontend is very broken (I tried with >> small document). It constantly resizes itself, jumps about. etc > > I see this, too (also qt). The fact that it resizes itself is normal (altough the resizing should be smooth). It shouldn't jump. I don't understand if both of you are seeing the same behaviour as I do and find it ugly or if you are seeing something different. Could you describe some behaviour you find weird in a few steps? Thanks. > I noticed also that there is almost always a brown area below the > document, even if the document is larger than the screen. > > Resizing the main window does not work properly: The scrollbar height is > not updated when I resize the window at the top border (see image) > resizing at the bottom works. Truly weird. Thanks for the testing. Alfredo
Re: [patch] new scrollbar code
John Levon wrote: > On Wed, Mar 30, 2005 at 09:01:02PM +0200, Alfredo Braunstein wrote: > >> On your document indeed the scrollbar resizes a lot (the reason is >> obvious, we have paragraphs of very different vertical size). > > OK, we need to go to Mac-style scrollbars where the widget is of a > fixed size. It's unusable otherwise IMHO. This is easy. OTOH, I'm a bit confused by your 'unusable'. Setting the widget to fixed size would make no difference in useability AFAICS. >> Still I don't find >> it's completely broken, scrolling from top to bottom is possible (even if >> 'speed' is very variable). I don't see jumps. > > I see both jumps and the document getting stuck with no progress being > made when holding down the button to continuously scroll. qt version? Please give detailed instructions. Alfredo
Re: [Patch] fix grid lines in AMS arrays
On Thu, Mar 31, 2005 at 09:52:57AM +0200, Jean-Marc Lasgouttes wrote: > > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: > > Georg> Martin Vermeer wrote: > >> Looks great, except that Jean-Marc is right: you can still in three > >> places replace > >> > >> istringstream is(cmd.argument); string s; is >> s; > >> > >> by simply > >> > >> string const s = cmd.argument; > > Georg> I thought the reason for using the istringstream was to get rid > Georg> of whitespace or other stuff that might be in cmd.argument > Georg> after the first word. Is that wrong? And if we get rid of it > Georg> here we should get rid of it in all the other insets, too (not > Georg> necessarily now)... > > Then you can use FuncRequest::getArg(1). I am not sure it has the best > possible implementation, but at least this is a consistent interface. > > JMarc Should we at this point just add a comment to this effect at a strategic location, e.g., math_gridinset? - Martin pgphLEobzWyZN.pgp Description: PGP signature
RE: Re: Towards LyX 1.3.6 [status update #1]
JMarc>>> It should look like C:\Desktop\UserGuide.lyx, I believe. Really? Why? Who Says? JMarc>>> Probably the ~/ part of MakeDisplayPath should only JMarc>>> be done on Unix.On windows, I guess there is some API JMarc>>> to turn get those shorter file names. Angus>> Mmmm, but this is not too important either way. Angus>> Perhaps Asger might know? Rob> GetShortPathName Rob> http://msdn.microsoft.com/library/default.asp?url= Rob> /library/en-us/fileio/base/getshortpathname.asp Thanks, Rob. Hmmm. My reading of this is that the function returns the "8.3" form of the input path: "C:\Program Files" --> "C:\PROGRM~1" Is that what we really want here? I don't think so. Actually, I'm unsure what Jean-Marc has in mind. Jean-Marc? -- Angus
Re: The LyX licence --- a gentle nudge
Hello, Angus Leeming wrote: In light of all this, I'm asking whether I can have your permission to add your names to http://www.lyx.org/blanket-permission.txt : "The following people hereby grant permission to licence their contributions to LyX under the Gnu General Public Licence, version 2 or later." I can't remember what I contributed to LyX, but I grant this permission for whatever I contributed to LyX. -- Regards Hartmut Goebel | Hartmut Goebel | We build the crazy compilers | | [EMAIL PROTECTED] | Compiler Manufacturer|
Re: Polish translation 1.4cvs
> "Tomasz" == Tomasz Luczak <[EMAIL PROTECTED]> writes: Tomasz> Jean-Marc Lasgouttes wrote: >>> "Tomasz" == Tomasz Luczak <[EMAIL PROTECTED]> writes: Tomasz> Hi I send updated translation pl.po into polish for 1.4.0cvs Tomasz> version >> Thanks a lot Tomasz. It is in now. >> Tomasz> New update of polish translation. There are in attachment Tomasz> pl.diff and pl.po files. Applied, thanks. JMarc
