John Levon wrote:
> Look at the ChangeLogs, find the date, then look for the relevant
> commits via cvs log
This seems to be the one:
2002-09-11 John Levon <[EMAIL PROTECTED]>
* qscreen.C: use repaint() not update() for immediate change
is it? AFAICT is not related.
>> > It will fl
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> | Why the hell is this needed? The graphics stuff knows absolutely
>> | NOTHING about Paragraphs.
>>>
>> | Lars, could you find out WHY these are needed please?
>>
>> Becuse this is with safe_iterators and they need more in
On Thu, Nov 20, 2003 at 05:28:38PM +, Angus Leeming wrote:
> John, you know the Qt stuff better than anyone else. Does my proposal
> seem reasonable to you? To recap:
>
> xforms generates 'pseudo' XEvents in its main interation loop. See
> below for a refresher ;-)
You missed out *why* the
On Thu, Nov 20, 2003 at 06:04:23PM +0100, Alfredo Braunstein wrote:
> > http://marc.theaimsgroup.com/?l=lyx-devel&m=103173336232091&w=2
>
> How can I search in cvs for a patch with the date of the mail?
Look at the ChangeLogs, find the date, then look for the relevant
commits via cvs log
> You
did you apply it ?
Or there are any further thinks to do for me ?
thanks Felix
--
Felix Kurth
pgp public key: http://www.fkurth.de/keys/felix.fkurth.asc
key fingerprint: D401 DCF8 2BF8 50DF 2FAD 8136 C29B 83EE C0A1 F2AD
Andre Poenitz wrote:
>> There's still the eternal problem with with full-row insets: if you have
>> a line like this
>>
>> blah blah blah
>> BUTTON
>> -- - - - - - -
>> |here is some text
>> --- - - - - -
>
> Also
>
>
> blah blah blah blah blah [I] blah
Andre Poenitz wrote:
> void InsetCommand::draw(PainterInfo & pi, int x, int y_abs) const
> {
> BufferView const & bv = *pi.base.bv;
> xo_ = x;
> yo_ = y;
> button_.draw(pi, x, y)
> }
>
> still looks nicer. So if the translation could be done in the lower
But it wo
Lars Gullik Bjønnes wrote:
> | Why the hell is this needed? The graphics stuff knows absolutely
> | NOTHING about Paragraphs.
>>
> | Lars, could you find out WHY these are needed please?
>
> Becuse this is with safe_iterators and they need more info than
> regular iterators.
>
> So I know why.
>
Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
>>> 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
>
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> These are the changes needed to _compile_ with the new debug-mode in
>> Gcc 3.4.
>>
>> I have not begun testing yet.
>
| What, what, what?
>
| Why the hell is this needed? The graphics stuff knows absolutely
| NOTHING ab
Lars Gullik Bjønnes wrote:
> These are the changes needed to _compile_ with the new debug-mode in
> Gcc 3.4.
>
> I have not begun testing yet.
What, what, what?
Why the hell is this needed? The graphics stuff knows absolutely
NOTHING about Paragraphs.
Lars, could you find out WHY these are n
John Levon wrote:
>> Is that what you where refering to? They don't seem to be so much
>> related,
>
> No. That's not our sources :)
Oops sorry. ;-)
> See http://marc.theaimsgroup.com/?l=lyx-devel&m=103175980626933&w=2
>
> and
>
> http://marc.theaimsgroup.com/?l=lyx-devel&m=103173336232091&w
On Thu, Nov 20, 2003 at 05:38:10PM +0100, Alfredo Braunstein wrote:
> Is that what you where refering to? They don't seem to be so much related,
No. That's not our sources :)
See http://marc.theaimsgroup.com/?l=lyx-devel&m=103175980626933&w=2
and
http://marc.theaimsgroup.com/?l=lyx-devel&m=103
John Levon <[EMAIL PROTECTED]> writes:
| On Thu, Nov 20, 2003 at 05:34:19PM +0100, Lars Gullik Bj?nnes wrote:
>
>> I have not begun testing yet.
>
| Have fun ... you can't do anything w/o it triggering
Then I'll fix one problem at a time (or try to).
--
Lgb
John Levon wrote:
> On Thu, Nov 20, 2003 at 09:33:26AM +0100, Alfredo Braunstein wrote:
>
>> qt seems to emit only when the value is actually changed (good). The
>> problem is that on update, we redraw and then call to adjust the
>> scrollbar, with a new value, and this calls an update again.
>
On Thu, Nov 20, 2003 at 05:34:19PM +0100, Lars Gullik Bj?nnes wrote:
> I have not begun testing yet.
Have fun ... you can't do anything w/o it triggering
john
--
Khendon's Law:
If the same point is made twice by the same person, the thread is over.
These are the changes needed to _compile_ with the new debug-mode in
Gcc 3.4.
I have not begun testing yet.
Index: src/graphics/PreviewLoader.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/graphics/PreviewLoader.C,v
retrieving
Angus Leeming wrote:
>> 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 signa
Alfredo Braunstein wrote:
>> It just seems strange to do a lot of work to avoid automatic drawing.
>> Drawing is needed at this point anyway, so let it draw and just loose the
>> explicit drawing that only xforms need.
>
> I think it's not true, as we know the cursor y position (and thus the
> sc
> "Claus" == Claus Hindsgaul <[EMAIL PROTECTED]> writes:
Claus> I have attached an updated Danish po-file for LyX 1.3.x, da.po
Claus> Please adopt it into the 1.3.x branch.
I just did it, but I noticed a (small) problem afterwards. You have
entries like
#: src/frontends/qt2/QDocument.C:92
ms
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> 2003-11-19 Angus Leeming <[EMAIL PROTECTED]> * lyxtextclass.C
Angus> (LyXTextClass): fix warning about variable initialization in
Angus> constructor being re-ordered to match declaration.
Angus> I probably won't be near this comput
On Thu, Nov 20, 2003 at 09:33:26AM +0100, Alfredo Braunstein wrote:
> qt seems to emit only when the value is actually changed (good). The problem
> is that on update, we redraw and then call to adjust the scrollbar, with a
> new value, and this calls an update again.
ICBW, but this behaviour mi
Andre Poenitz wrote:
> On Thu, Nov 20, 2003 at 01:44:43PM +, Angus Leeming wrote:
> But
>
> void InsetCommand::draw(PainterInfo & pi, int x, int y_abs) const
> {
> xo_ = x;
> yo_ = y;
> button_.draw(pi, x, y)
> }
>
> still looks nicer.
Oops! Yes. That was what I was
On Fri, Oct 10, 2003 at 08:51:53AM +, Angus Leeming wrote:
> Lars Gullik Bjønnes wrote:
>
> > Angus Leeming <[EMAIL PROTECTED]> writes:
> >
> > | Is this the solution to the long link times we have?
> > | http://article.gmane.org/gmane.comp.lib.boost.devel/26446
> >
> > Spell it out, don't f
On Thu, Nov 20, 2003 at 01:44:43PM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> > One question: what should now be the meaning of y in Inset::draw()?
> >
> > Currently it is 'screen absolute' as far as I can tell. Do we change
> > that?
> >
> > Going to 'doc absolute' would mean adding l
Andre Poenitz wrote:
> One question: what should now be the meaning of y in Inset::draw()?
>
> Currently it is 'screen absolute' as far as I can tell. Do we change
> that?
>
> Going to 'doc absolute' would mean adding lots of top_y() all over
> the place when calling the low-level drawing routi
On Thu, Nov 20, 2003 at 01:37:04PM +0100, Braunstein Alfredo wrote:
> Andre Poenitz wrote:
>
> > On Wed, Nov 19, 2003 at 12:11:13AM +0100, Alfredo Braunstein wrote:
> >> This patch introduces document absolute coordinates in LyXText, and use
> >> them to solve the target_x problem (almost all oper
Jean-Marc Lasgouttes wrote:
>> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>
> Alfredo> So for adjusting qt without touching xforms we need to set
> Alfredo> the scrollbar value without invoking the signal. Something
> Alfredo> like the attached works (altough it is not so nic
Andre Poenitz wrote:
> On Wed, Nov 19, 2003 at 12:11:13AM +0100, Alfredo Braunstein wrote:
>> This patch introduces document absolute coordinates in LyXText, and use
>> them to solve the target_x problem (almost all operation are still done
>> as before, but now we can possibly simplify/correct co
Helge Hafting wrote:
>> So for adjusting qt without touching xforms we need to set the scrollbar
>> value without invoking the signal. Something like the attached works
>> (altough it is not so nice maybe). Alternatively, we can just disconnect
>> the signal before setValue and reconnect it after.
On Wed, Nov 19, 2003 at 12:11:13AM +0100, Alfredo Braunstein wrote:
> This patch introduces document absolute coordinates in LyXText, and use them
> to solve the target_x problem (almost all operation are still done as
> before, but now we can possibly simplify/correct code using the absolute
> coo
Jean-Marc Lasgouttes wrote:
>> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>
> Alfredo> So say you are with the cursor in the last 't' of 'text',
> Alfredo> then you go up and the cursor goes to before the B of BUTTON
> Alfredo> with x_target set appropriately to the x coordin
Andre Poenitz wrote:
> This is the same with separated xo_/yo_.
Ups, sorry Andre, just commited exactly that (+ a couple of bugs fixed, in
particular y0_ coordinate was set wrongly)
> Note that these could (and should) be made completely private by moving
> parts of InsetText::draw to some new
On Wed, Nov 19, 2003 at 12:11:13AM +0100, Alfredo Braunstein wrote:
> This patch introduces document absolute coordinates in LyXText, and use them
> to solve the target_x problem (almost all operation are still done as
> before, but now we can possibly simplify/correct code using the absolute
> coo
Alfredo Braunstein wrote:
Jean-Marc Lasgouttes wrote:
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.
qt seems to emit only when the value i
> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes:
Alfredo> So say you are with the cursor in the last 't' of 'text',
Alfredo> then you go up and the cursor goes to before the B of BUTTON
Alfredo> with x_target set appropriately to the x coordinate of the
Alfredo> 't'.
I probably
Andre Poenitz wrote:
> blah blah blah blah blah [I] blah blah blah blah blah blah blah blah
> blah blah blah BOXblah blah blah blah blah blah
>bu bu bub bu bu bu
>bu bu bu b ub bub
> blah blah blah blah blah blah blah blah blah blah blah blah bla
On Wed, Nov 19, 2003 at 12:11:13AM +0100, Alfredo Braunstein wrote:
> - target_x handling
> - cursorUp/Down entering/exiting insets (LFUN_FINISHED_UP/DOWN where not
> handled correctly)
> - pageUp/Down (take the userguide, press page down: scrolling gets stuck at
> some point)
>
>
> There's still
On Thu, Nov 20, 2003 at 09:10:42AM +0100, Alfredo Braunstein wrote:
> PS: to make *me* happy, you should look at the two chunks below and tell if
> replacing the first one with the second one will miss something important.
Even if it did (I can't see anything obvious), I'd go for the second
versio
> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes:
Alfredo> So for adjusting qt without touching xforms we need to set
Alfredo> the scrollbar value without invoking the signal. Something
Alfredo> like the attached works (altough it is not so nice maybe).
Alfredo> Alternatively, we c
On Wed, Nov 19, 2003 at 09:20:15AM +, 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_;
>
Jean-Marc Lasgouttes wrote:
>>> 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.
qt seems to emit only when the value is actually c
On Tue, Nov 18, 2003 at 10:16:29PM +0100, Georg Baum wrote:
> 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'?
>
Lars Gullik BjÃnnes wrote:
> | 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?
Sort of. They ar
44 matches
Mail list logo
