Re: [patch] intro of absolute LyXText coords + some cursor fixing

[Angus Leeming]

Alfredo Braunstein wrote:

Index: lyxtext.h
+struct  Pos  {
+   int  x;
+   int  y;
+};
No default constructor to initialize these two? Brave man!

+   Pos pos_;
If it's public, you can get rid of the trailing underscore.
Tell the world what 'pos_' is. Give it a nice little comment.


Index: text2.C
+{
+pos_.x = 0;
+pos_.y = 0;
+}
Ah-haa! struct Pos does indeed need a default constructor!
 

Do you plan to go to absolute coordinates for everything? The stuff 
below is a horrible mix of the two...
Index: insets/insettext.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettext.C,v
retrieving revision 1.546
diff -u -p -u -r1.546 insettext.C
--- insets/insettext.C  17 Nov 2003 20:28:10 -  1.546
+++ insets/insettext.C  18 Nov 2003 22:39:28 -
@@ -257,6 +257,9 @@ void InsetText::draw(PainterInfo & pi, i

x += TEXT_TO_INSET_OFFSET;

+   text_.pos_.x = x;
+   text_.pos_.y = y + bv->top_y();
+
paintTextInset(*bv, text_, x, y);
 
if (drawFrame_ == ALWAYS || drawFrame_ == LOCKED)
@@ -340,10 +343,8 @@ void InsetText::edit(BufferView * bv, in
lyxerr << "InsetText::edit xy" << endl;
old_par = -1;
sanitizeEmptyText(bv);
-   text_.setCursorFromCoordinates(x, y + dim_.asc);
-   text_.cursor.x(text_.cursor.x());
-   bv->x_target(text_.cursor.x());
-
+   text_.setCursorFromCoordinates(x - text_.pos_.x, y + bv->top_y()
+  - text_.pos_.y);
text_.clearSelection();
finishUndo();


-- 
Angus

Re: [patch] intro of absolute LyXText coords + some cursor fixing

[Alfredo Braunstein]

Angus Leeming wrote:

> Alfredo Braunstein wrote:
> 
> Index: lyxtext.h
> +struct  Pos  {
> +   int  x;
> +   int  y;
> +};
> No default constructor to initialize these two? Brave man!
> 
> +   Pos pos_;
> If it's public, you can get rid of the trailing underscore.

I left it for two reasons: 1) pos is the most common tmp variable name in
text*.C, so it's really not an option. 2) in the end, it should be private,
and have accessors etc... For the moment I think it's more confortable to
have it public.

> Tell the world what 'pos_' is. Give it a nice little comment.

Ok.

> 
> Index: text2.C
> +{
> +pos_.x = 0;
> +pos_.y = 0;
> +}
> Ah-haa! struct Pos does indeed need a default constructor!

I guess it's a matter of preferences... (I prefer to think them as two
simple variables grouped toghether in a struct for clarity.)

> Do you plan to go to absolute coordinates for everything? The stuff

In the end yes. 

> below is a horrible mix of the two...

But it's absolutely not fault of the patch. The absolute coordinates were
needed, but absent. So it's all the rest that is at fault. We will have
this sort of stuff until all have absolute coords.

Basically, I cannot do (nor would be wise) all in one step (and I cannot do
it alone! it's a boring nightmare to do). This changes can be done more or
less automatically if you start with a working version (as in every step
you can check that all works well). We don't have that.

This path pretends to be a preliminary step to have a working version.

Why this particular piece is ugly:

in inset::draw we have screen coordinates x,y translated to absolute doc
coords (i.e. y += top_y)
in inset::edit we translate screen coordinates to lyxtext coordinates (x -=
txt.x , y += top_y - txt.y)
(see my coordinates status on the first mail)

Alfredo

> Index: insets/insettext.C
> ===
> RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettext.C,v
> retrieving revision 1.546
> diff -u -p -u -r1.546 insettext.C
> --- insets/insettext.C  17 Nov 2003 20:28:10 -  1.546
> +++ insets/insettext.C  18 Nov 2003 22:39:28 -
> @@ -257,6 +257,9 @@ void InsetText::draw(PainterInfo & pi, i
> 
> x += TEXT_TO_INSET_OFFSET;
> 
> +   text_.pos_.x = x;
> +   text_.pos_.y = y + bv->top_y();
> +
> paintTextInset(*bv, text_, x, y);
>  
> if (drawFrame_ == ALWAYS || drawFrame_ == LOCKED)
> @@ -340,10 +343,8 @@ void InsetText::edit(BufferView * bv, in
> lyxerr << "InsetText::edit xy" << endl;
> old_par = -1;
> sanitizeEmptyText(bv);
> -   text_.setCursorFromCoordinates(x, y + dim_.asc);
> -   text_.cursor.x(text_.cursor.x());
> -   bv->x_target(text_.cursor.x());
> -
> +   text_.setCursorFromCoordinates(x - text_.pos_.x, y + bv->top_y()
> +  - text_.pos_.y);
> text_.clearSelection();
> finishUndo();
> 
> 

Re: [patch] intro of absolute LyXText coords + some cursor fixing

[Angus Leeming]

Alfredo Braunstein wrote:
>> below is a horrible mix of the two...
> 
> But it's absolutely not fault of the patch. The absolute coordinates
> were needed, but absent. So it's all the rest that is at fault. We
> will have this sort of stuff until all have absolute coords.

Sorry, I should have made myself clear. I think your idea is a good 
one. I was merely highlighting that 'intermediate code' will be hard 
for the unenlightened (me!) to follow unless it evolves to 'absolute 
coords everywhere' code.

> Basically, I cannot do (nor would be wise) all in one step

Agreed.

> Why this particular piece is ugly:

Oh, I just got bored reading the patch and scrolled to the end ;-)

> in inset::draw we have screen coordinates x,y translated to absolute
> doc coords (i.e. y += top_y)
> in inset::edit we translate screen coordinates to lyxtext
> coordinates (x -= txt.x , y += top_y - txt.y)
> (see my coordinates status on the first mail)

Yes, I understand. I've been reading your mails ;-)

-- 
Angus

why qt is slower than xforms

[Alfredo Braunstein]

I think that one of the problems is an extra redraw:

- update calls workarea::setScrollBarParams
- setScrollBarParams calls scrollbar_->setValue
- scrollbar_->setValue emits a signal (the scrollbar has changed)
- an extra update is called

Is there a way to call setValue without the scrollbar emitting valueChanged?

Alfredo

Re: why qt is slower than xforms

[Alfredo Braunstein]

Alfredo Braunstein wrote:

> Is there a way to call setValue without the scrollbar emitting
> valueChanged?

A workaround (can be possibly backported?):

Index: QContentPane.C
===
RCS file:
/usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QContentPane.C,v
retrieving revision 1.26
diff -u -p -u -r1.26 QContentPane.C
--- QContentPane.C  21 Sep 2003 16:02:53 -  1.26
+++ QContentPane.C  19 Nov 2003 10:26:39 -
@@ -91,7 +91,8 @@ QContentPane::QContentPane(QWorkArea * p
 
 void QContentPane::scrollBarChanged(int val)
 {
-   wa_->scrollDocView(val);
+   if (wa_->scrollbar_->draggingSlider())
+   wa_->scrollDocView(val);
 }
 
 

Re: Bug ??

[Juergen Spitzmueller]

Martin Vermeer wrote:
On Tue, Nov 18, 2003 at 09:26:51PM +0200, Josef Carel spake thusly:
 

Hello:
Im not sure it is a bug but in any case I need some help.
Im just in the begining of using Lyx, version 1.3.3
I can't centered images inserted through float system and
I can't find how to move it from the left side.
It is a bug or something wrong with my procedure ?

Thanks a lot

Josef Carel


Hi,

you should center the paragraph containing the image. Place the cursor
beside the image and center the paragraph through its menu. 

- Martin

Note that this will lead to, say, non-standard behaviour in 1.3.3 (too 
much space between figure and caption). You need to enter \centering in 
ERT (Insert->TeX) just before the figure (inside the float) to avoid the 
extra space. This bug has been fixed in the devel tree.

Jürgen.

Re: why qt is slower than xforms

[Jean-Marc Lasgouttes]

> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes:

Alfredo> Alfredo Braunstein wrote:
>> Is there a way to call setValue without the scrollbar emitting
>> valueChanged?

Alfredo> A workaround (can be possibly backported?):

Does it work when clicking in the scrollbar instead of dragging? Can't
you check whether 'val' actually changed value?

JMarc

Re: tex2lyx and optional arguments

[Jean-Marc Lasgouttes]

> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:

Georg> Am Dienstag, 18. November 2003 09:37 schrieb Andre Poenitz:
>> On Mon, Nov 17, 2003 at 08:58:36PM +0100, Georg Baum wrote: > Am
>> Montag, 17. November 2003 09:52 schrieb Andre Poenitz: > > Looks
>> good. Is this ready for 'commit'?
>> >
>> > Yes. Maybe with the size() -> !empty() change suggested by Angus.
>> BTW, > this construct is used at a few other places in tex2lyx,
>> some from me, > some from others.
>> 
>> Feel free to correct that.

Georg> See attached.

Thanks a lot. Applied.

JMarc

Re: why qt is slower than xforms

[Alfredo Braunstein]

Alfredo Braunstein wrote:

> A workaround (can be possibly backported?):

... but breaking the mouse wheel. Attached again with a fix.
This behaves as a x2 boost under qt for me in some situations (like
scrolling with page-down). 

Alfredo
Index: QContentPane.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QContentPane.C,v
retrieving revision 1.26
diff -u -p -u -r1.26 QContentPane.C
--- QContentPane.C	21 Sep 2003 16:02:53 -	1.26
+++ QContentPane.C	19 Nov 2003 10:52:22 -
@@ -91,7 +91,8 @@ QContentPane::QContentPane(QWorkArea * p
 
 void QContentPane::scrollBarChanged(int val)
 {
-	wa_->scrollDocView(val);
+	if (wa_->scrollbar_->draggingSlider())
+		wa_->scrollDocView(val);
 }
 
 
@@ -131,6 +132,7 @@ void QContentPane::mouseMoveEvent(QMouse
 void QContentPane::wheelEvent(QWheelEvent * e)
 {
 	wa_->scrollbar_->setValue(wa_->scrollbar_->value() - e->delta());
+	wa_->scrollDocView(wa_->scrollbar_->value());
 }
 
 

Re: why qt is slower than xforms

[Alfredo Braunstein]

Jean-Marc Lasgouttes wrote:

> Does it work when clicking in the scrollbar instead of dragging? Can't

Ups, no ;-)

> you check whether 'val' actually changed value?

It doesn't work. The problem is that the signal is emmited when the value
has been just changed.

I have to run... but I'll think of a solution.

Alfredo

Re: why qt is slower than xforms

[Jean-Marc Lasgouttes]

> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes:

>> you check whether 'val' actually changed value?

Alfredo> It doesn't work. The problem is that the signal is emmited
Alfredo> when the value has been just changed.

You can also cache the value somewhere.

JMarc

Re: scrolling (three questions)

[Angus Leeming]

Angus Leeming wrote:

> On Thursday 30 October 2003 2:00 pm, Ronald Florence wrote:
>> Angus Leeming <[EMAIL PROTECTED]> writes:
>> > The fix is trivial (for Qt too) and requires that
>> > LyX responds only to a subset of mouse events from the underlying
>> > X11, MacOS or Win32 graphics libraries. In the xforms frontend we
>> > use a timer, so:
>> > // The timer runs for 200ms
>> > static Timer timer(200);
>> > if (timer.running())
>> > return;
>> > timer.start();
>> > dispatch(mouse_event_to_the_lyx_core);
>> >
>> > This could go in, almost as is, to the mouseEventHandler in
>> > QContentPane.C. Feel free to try ;-)
>>
>> Is this fix going into LyX-1.3.4?
> 
> In order for any fix to go in, I'd need to know the Qt equivalent of
> XEvent::xmotion.[x,y].

Well, I had a go. See below. Unfortunately, it doesn't work as I'd 
like. Qt emits a mouseMoveEvent signal only when --- you've guessed 
it --- the mouse is moved. No signal is emitted when the mouse is 
just pressed but otherwise doing nothing. This differs from xforms 
that emits event calls when this happens (using a timer to 
artificially generate events).

So, shold we do what xforms does and start a timer on a mouse press 
event so that we can generate 'pseudo' mouse events every 'interval' 
msecs?

Angus


void QContentPane::mouseMoveEvent(QMouseEvent * e)
{
// Check if the mouse is above or below the workarea
if (e->y() <= y() || e->y() >= y() + height()) {
// The mouse button is depressed and we are outside the
// workarea. That means we are simultaneously selecting
// text and scrolling the view.
// Use a Timeout to react to a drag events only every
// 200ms. All intervening events are discarded,
// allowing the user to control position easily.
static int const discard_interval = 200;
static Timeout timeout(discard_interval);

if (timeout.running())
return;

// The timeout is not running, so process the
// event, first starting the timeout to discard future
// events.
timeout.start();
}

FuncRequest cmd(LFUN_MOUSE_MOTION, e->x(), e->y(),
q_motion_state(e->state()));
wa_->dispatch(cmd);
}

Re: [Patch] XML sanitation part II

[Martin Vermeer]

On Tue, Nov 18, 2003 at 10:12:31AM +0100, Lars Gullik Bjønnes spake thusly:
 
> Martin Vermeer <[EMAIL PROTECTED]> writes:

...

> | Does this more clearly illustrate the idea?
> >
> | Check-in later today, shout to object ;-)
> 
> Object!
> 
> I am all for cleaning up and parametization. But I am not quite sure
> what implications this will have. What I do not like (seemingly) is
> that docbook get it cleaned up, latex stays ugly. We need to have
> solutions that make the .layout format better and that works with all
> first-class output formats.
> 
> How does this listitem stuff fit with LaTeX? Does it fit at all?
> 
> -- 
>   Lgb

It appears this requires a more explicit explanation (bend a model in
iron wire, as we say over here). So here is for your edification :) a
patch containing not only the changes I made, but also the agu-dtd
document class that I am preparing to support the AGU XML format. This
stuff is sort-of working, but still very incomplete.

You see, the main difference between LaTeX and XML is, that while
LaTeX is a (one!) mark-up language, XML is a meta-language or
'language construction kit'. (So when Microsoft say that their Office
formats will be XML based, that means next to nothing :)

This means that, whereas LaTeX has lots of add-on packages, the core
language is pretty fixed. This is why the hard-wired stuff for
item-environments works without much parametrization. Also LaTeX is
much less verbose with its mark-up than most XML dialects.

Though I have said earlier that the AGU format is a variant of
DocBook, the differences in syntax between original DocBook and
AGU DTD are massive compared to what you can find between any two
LaTeX document classes.

If you compare these two XML formats for item-environments, you see

---

  
The catalog.jar and catalog-apps.jar paths, used during the
configuration step.
  
  
The java archives used by the XSLT, if the XSLT used is a java one.
  
   
---

for an 'itemize' layout list in DocBook. For AGU it becomes

---

  
The catalog.jar and catalog-apps.jar paths, used during the
configuration step.
  
  
The java archives used by the XSLT, if the XSLT used is a java one.
  

---

You see that pretty much everything that *can* be different, *is*
different. I don't think that three added parameters in the .layout
file format is too high a price to pay to describe this. They are all
three syntactically meaningful. But really I see no way to make them
useful for the LaTeX side of things. There they are just a solution
looking for a problem. (Yes, I did look at it. See output_latex.C
patch :)

There is of course the alternative of adding a new XML output type in
addition to linuxdoc and docbook (which I think BTW we should at some
point try to merge). Disadvantages are massive code duplication with
the associated maintenance load, and doing nothing to ease the job for
other people wanting to add their XML document classes by writing a
set of .layout files, no coding required. We should open up our
architecture! 

As you will also see when reading the patch, finally latexparam is
used (more) consistently, not just as a jack-of-all-trades to shore up
the shortcomings of the .layout format for describing XML document
classes.

(BTW I am amazed that José got this stuff to work as well as it does,
given the still extremely LaTeX-centric architecture of both the LyX
core and the .layout file syntax! XML *is* really very different from
LaTeX and IMHO it is time to take that into account realistically. 
Without fragmenting LyX of course, there I agree.)

As for docbook being cleaned up and latex being ugly, I don't agree.
This mistaken appearance comes from docbook being still very
incomplete, while latex is mature. In fact the docbook code is *still*
pretty ugly as a workaround for LyX architectural limitations, and
what I did, didn't actually touch the ugliness at all.

I hope this clears up things a bit.

Hoping for one (or more) of three outcomes:

1) a serious in-depth discussion
2) go-ahead for checking this in (with or without the AGU stuff)
3) clear (and realistic, finite-execution-time :) instructions as to
   what to change/do differently in order to make this check-inable.

- Martin



y.diff.gz
Description: application/gunzip


pgp0.pgp
Description: PGP signature

Re: [Patch] XML sanitation part II

[Jose' Matos]

On Wednesday 19 November 2003 15:29, Martin Vermeer wrote:

  One of the problems with Martin's messages is that you need to think a bit 
about them. ;-)

[...]

> You see, the main difference between LaTeX and XML is, that while
> LaTeX is a (one!) mark-up language, XML is a meta-language or
> 'language construction kit'. (So when Microsoft say that their Office
> formats will be XML based, that means next to nothing :)

  With all the cleaning your cleaning going on I am tempted to rename docbook 
to SGML and the make docbook as an instance of that. :-)

  The support for xml can be done with the flavour dialect.
This will add

in the begin and take care of specific xml details inside.

 and/or adding a new attribute to the layout class describing its header.   
This is also be usefull to linuxdoc.

"  PUBLIC \"-//OASIS//DTD DocBook V4.1//EN\""  for SGML docbook
" system" for linuxdoc
"  PUBLIC \"-//AGU//DTD article American Geophysical Union DTD version 
3.42//EN" for AGU
"  PUBLIC \"-//W3C//...XHTML...//EN\"" for xhtml

> This means that, whereas LaTeX has lots of add-on packages, the core
> language is pretty fixed. This is why the hard-wired stuff for
> item-environments works without much parametrization. Also LaTeX is
> much less verbose with its mark-up than most XML dialects.
>
> Though I have said earlier that the AGU format is a variant of
> DocBook, the differences in syntax between original DocBook and
> AGU DTD are massive compared to what you can find between any two
> LaTeX document classes.

  True.

[...]

> I hope this clears up things a bit.
>
> Hoping for one (or more) of three outcomes:
>
> 1) a serious in-depth discussion
> 2) go-ahead for checking this in (with or without the AGU stuff)

  After your last patch I favour this one, but then I am suspect. :-)

> 3) clear (and realistic, finite-execution-time :) instructions as to
>what to change/do differently in order to make this check-inable.
>
> - Martin

-- 
José Abílio

Re: [PATCH] remove non-ascii in translatable strings

[Jean-Marc Lasgouttes]

> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

Jean-Marc> The following patch for 1.3.4cvs (should be easy to port to
Jean-Marc> 1.4.0cvs) remove all use of non-ascii characters in strings
Jean-Marc> seen by gettext.

Since nobody complained, I applied it. I'll do the same for 1.4.0cvs.

JMarc

Re: POT file generation broken

[Jean-Marc Lasgouttes]

> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes:

Michael> I guess that your recent proposal to remove all non-ASCII
Michael> characters will circumvent the problem though it does not
Michael> really remove the cause. I think in the long term, we have to
Michael> switch to UTF-8 anyway because the gettext manual says:

I committed the patch to 1.3.4cvs and will do the same to 1.4.0cvs
soon. I think that this solves the problem until we switch to unicode.

BTW, Michael, could you contact the translators to warn them that it
would be a good idea to update their translations and send the results
to [EMAIL PROTECTED]

Note that translators are free to translate the ugly "<>" with a
nicer "«texte»". It is only in the original texts that we forbid
non-ascii.

JMarc

Re: [patch] intro of absolute LyXText coords + some cursor fixing

[Lars Gullik Bjønnes]

Alfredo Braunstein <[EMAIL PROTECTED]> writes:

>> Index: text2.C
>> +{
>> +pos_.x = 0;
>> +pos_.y = 0;
>> +}
>> Ah-haa! struct Pos does indeed need a default constructor!
>
| I guess it's a matter of preferences... (I prefer to think them as two
| simple variables grouped toghether in a struct for clarity.)

So this is two independant variables grouped together for clarity
because thay are not really independant?

or if they truly are independant I'd rather go for the "every variable
for itself" approach.


-- 
Lgb

[13x patch]: squash warning

[Angus Leeming]

2003-11-19  Angus Leeming  <[EMAIL PROTECTED]>

* lyxtextclass.C (LyXTextClass): fix warning about variable
initialization in constructor being re-ordered to match declaration.

I probably won't be near this computer till next week, so please apply this 
for me.

Angus
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.1021.2.22
diff -u -p -r1.1021.2.22 ChangeLog
--- src/ChangeLog	20 Oct 2003 13:09:54 -	1.1021.2.22
+++ src/ChangeLog	20 Nov 2003 00:00:27 -
@@ -1,3 +1,8 @@
+2003-11-19  Angus Leeming  <[EMAIL PROTECTED]>
+
+	* lyxtextclass.C (LyXTextClass): fix warning about variable
+	initialization in constructor being re-ordered to match declaration.
+
 2003-10-03  Jean-Marc Lasgouttes  <[EMAIL PROTECTED]>
 
 	* lengthcommon.C: add empty unit_name* entries for UNIT_NONE (bug
Index: src/lyxtextclass.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxtextclass.C,v
retrieving revision 1.22.2.3
diff -u -p -r1.22.2.3 lyxtextclass.C
--- src/lyxtextclass.C	13 Nov 2003 15:51:44 -	1.22.2.3
+++ src/lyxtextclass.C	20 Nov 2003 00:00:28 -
@@ -50,8 +50,12 @@ struct compare_name {
 
 LyXTextClass::LyXTextClass(string const & fn, string const & cln,
 			   string const & desc, bool texClassAvail )
-	: name_(fn), latexname_(cln), description_(desc),
-	  floatlist_(new FloatList), ctrs_(new Counters), texClassAvail_(texClassAvail)
+	: texClassAvail_(texClassAvail),
+	  name_(fn),
+	  latexname_(cln),
+	  description_(desc),
+	  floatlist_(new FloatList),
+	  ctrs_(new Counters)
 {
 	outputType_ = LATEX;
 	columns_ = 1;