Re: Ready for RC1?
Helge Hafting wrote:
> Peter Kümmel wrote:
>> Helge Hafting wrote:
>>
>>> Lars Gullik Bjønnes wrote:
>>>
| What is the problem that you are trying to solve here?
Is it my old pet? "Countinued scorrling after key-release"?
What was wrong with my patch from months back?
>>> I tried this with todays svn.
>>> The patch will indeed prevent scrolling after key-release,
>>> so it fixes the pageup/pagedown case.
>>>
>>>
>>
>> My patch eats the pageup/pagedown key events, but I don't
>> know what Lars' patch does.
>>
>>
>>> It does not help for jumpscrolling using the scrollbar - LyX will
>>> then overshoot a lot, if the scrolling work needs more than 100% cpu.
>>>
>>
>>
>> Attached a patch which is not mentioned to go in, but does it
>> at least fix the overshooting when scrolling by clicking in
>> the scrollbar?
>>
>>
>> Index: src/frontends/qt4/GuiWorkArea.cpp
>> ===
>> --- src/frontends/qt4/GuiWorkArea.cpp (revision 18599)
>> +++ src/frontends/qt4/GuiWorkArea.cpp (working copy)
>> @@ -234,6 +234,7 @@
>> void GuiWorkArea::adjustViewWithScrollBar(int)
>> {
>> scrollBufferView(verticalScrollBar()->sliderPosition());
>> + QApplication::syncX();
>> }
>>
> This fixed it perfectly!
Great to hear!
But you still need a patch for the key scrolling.
> No more overshooting. Performance was unchanged, not better, no worse.
>
> I have the impression that "syncX" isn't too popular, but I wonder:
> Will it really be a problem? The vast majority of fast machines
> out there don't need 100% cpu to scroll. That means they
> are idle between the scrollbar autorepeats. syncX is
> probably not a problem for those?
We will never know, if we not test, so I apply the change.
>
> A slow-display machine will scroll less (not slower - it was already
> using 100% cpu, scrolling slower than the autorepeat anyway.)
> So it will scroll less, because it don't overshoot.
>
> I also tested "syncX" performance over the network. I used ssh
> to get to a machine 20kM from here, and then ssh back to
> this machine again where I ran the patched LyX. This sends the
> graphics on a roundtrip 20kM back and forth - twice as bad as
> just using a remote LyX. The scrolling was a little slower, but
> it still stops perfectly. And the slowness wasn't too bad, not
> something I mind when working remotely. ADSL has its limitations
> anyway.
>
> Please - if you can't come up with something better for 1.5.0, just
> apply this.
> It is simple, it works perfectly, and don't seem to kill performance.
> Unless it has some other horrible drawback that didn't show up
> in my tests. The overshooting certainly was horrible.
>
> Helge Hafting
>
>
>
>
>
>
>
--
Peter Kümmel
Re: Ready for RC1?
Peter Kümmel wrote:
Helge Hafting wrote:
Lars Gullik Bjønnes wrote:
| What is the problem that you are trying to solve here?
Is it my old pet? "Countinued scorrling after key-release"?
What was wrong with my patch from months back?
I tried this with todays svn.
The patch will indeed prevent scrolling after key-release,
so it fixes the pageup/pagedown case.
My patch eats the pageup/pagedown key events, but I don't
know what Lars' patch does.
It does not help for jumpscrolling using the scrollbar - LyX will
then overshoot a lot, if the scrolling work needs more than 100% cpu.
Attached a patch which is not mentioned to go in, but does it
at least fix the overshooting when scrolling by clicking in
the scrollbar?
Index: src/frontends/qt4/GuiWorkArea.cpp
===
--- src/frontends/qt4/GuiWorkArea.cpp (revision 18599)
+++ src/frontends/qt4/GuiWorkArea.cpp (working copy)
@@ -234,6 +234,7 @@
void GuiWorkArea::adjustViewWithScrollBar(int)
{
scrollBufferView(verticalScrollBar()->sliderPosition());
+ QApplication::syncX();
}
This fixed it perfectly!
No more overshooting. Performance was unchanged, not better, no worse.
I have the impression that "syncX" isn't too popular, but I wonder:
Will it really be a problem? The vast majority of fast machines
out there don't need 100% cpu to scroll. That means they
are idle between the scrollbar autorepeats. syncX is
probably not a problem for those?
A slow-display machine will scroll less (not slower - it was already
using 100% cpu, scrolling slower than the autorepeat anyway.)
So it will scroll less, because it don't overshoot.
I also tested "syncX" performance over the network. I used ssh
to get to a machine 20kM from here, and then ssh back to
this machine again where I ran the patched LyX. This sends the
graphics on a roundtrip 20kM back and forth - twice as bad as
just using a remote LyX. The scrolling was a little slower, but
it still stops perfectly. And the slowness wasn't too bad, not
something I mind when working remotely. ADSL has its limitations
anyway.
Please - if you can't come up with something better for 1.5.0, just
apply this.
It is simple, it works perfectly, and don't seem to kill performance.
Unless it has some other horrible drawback that didn't show up
in my tests. The overshooting certainly was horrible.
Helge Hafting
Re: Ready for RC1?
Lars Gullik Bjønnes wrote: Peter Kümmel <[EMAIL PROTECTED]> writes: | Helge Hafting wrote: | > Lars Gullik Bjønnes wrote: | >> | What is the problem that you are trying to solve here? | >> | >> Is it my old pet? "Countinued scorrling after key-release"? | >> | >> What was wrong with my patch from months back? | >> | > | > I tried this with todays svn. | > The patch will indeed prevent scrolling after key-release, | > so it fixes the pageup/pagedown case. | > | | My patch eats the pageup/pagedown key events, but I don't | know what Lars' patch does. Mine is more general, as it drops all keyevents that we hare unable to handle due to too fast auto-repeat. (This is basically the same patch we had for years with the XForms frontend, so you can see that the approach has been proven to work...) Please apply then - it makes scrolling _useful_ on machines that need 100% cpu to scroll. Then all we need is an equivalent solution for the scrollbar . . . Helge Hafting
Re: Ready for RC1?
Peter Kümmel <[EMAIL PROTECTED]> writes: | Helge Hafting wrote: | > Lars Gullik Bjønnes wrote: | >> | What is the problem that you are trying to solve here? | >> | >> Is it my old pet? "Countinued scorrling after key-release"? | >> | >> What was wrong with my patch from months back? | >> | > | > I tried this with todays svn. | > The patch will indeed prevent scrolling after key-release, | > so it fixes the pageup/pagedown case. | > | | My patch eats the pageup/pagedown key events, but I don't | know what Lars' patch does. Mine is more general, as it drops all keyevents that we hare unable to handle due to too fast auto-repeat. (This is basically the same patch we had for years with the XForms frontend, so you can see that the approach has been proven to work...) -- Lgb
Re: Ready for RC1?
Helge Hafting wrote:
> Lars Gullik Bjønnes wrote:
>> | What is the problem that you are trying to solve here?
>>
>> Is it my old pet? "Countinued scorrling after key-release"?
>>
>> What was wrong with my patch from months back?
>>
>
> I tried this with todays svn.
> The patch will indeed prevent scrolling after key-release,
> so it fixes the pageup/pagedown case.
>
My patch eats the pageup/pagedown key events, but I don't
know what Lars' patch does.
> It does not help for jumpscrolling using the scrollbar - LyX will
> then overshoot a lot, if the scrolling work needs more than 100% cpu.
Attached a patch which is not mentioned to go in, but does it
at least fix the overshooting when scrolling by clicking in
the scrollbar?
Index: src/frontends/qt4/GuiWorkArea.cpp
===
--- src/frontends/qt4/GuiWorkArea.cpp (revision 18599)
+++ src/frontends/qt4/GuiWorkArea.cpp (working copy)
@@ -234,6 +234,7 @@
void GuiWorkArea::adjustViewWithScrollBar(int)
{
scrollBufferView(verticalScrollBar()->sliderPosition());
+ QApplication::syncX();
}
>
> It is possible to use your patch and Peter Kümmels event_4 together.
> This cuts down on the scrollbar problems, but don't solve them completely.
>
> Helge Hafting
>
>
--
Peter Kümmel
Re: Ready for RC1?
Lars Gullik Bjønnes wrote: | What is the problem that you are trying to solve here? Is it my old pet? "Countinued scorrling after key-release"? What was wrong with my patch from months back? I tried this with todays svn. The patch will indeed prevent scrolling after key-release, so it fixes the pageup/pagedown case. It does not help for jumpscrolling using the scrollbar - LyX will then overshoot a lot, if the scrolling work needs more than 100% cpu. It is possible to use your patch and Peter Kümmels event_4 together. This cuts down on the scrollbar problems, but don't solve them completely. Helge Hafting
Re: Ready for RC1? Corrected test of event4
Sorry for the previous test of event4 - I patched the wrong tree. :-( event4 solves the problem for pageup/pagedown! I can scroll through half the userguide at 100% cpu, release the key, and LyX stops instantly! This is very good. The scrollbar still overshoots. I can only make it overshoot slightly when clicking the scrollbar arrows, I was not able to make LyX roll for several pages with those. This is big improvement. Only jumpscrolling using the scrollbar is still a problem. I can easily have LyX roll for several pages extra. Again, thanks for looking into this. Helge Hafting
Re: Ready for RC1?
Peter Kümmel wrote:
Dov Feldstern wrote:
(I hope I'm referring to the correct version of the patch:) As Helge
already reported, on very slow systems (I tested this by running under
valgrind), if you type quickly, some keystrokes get swallowed...
Nice idea to slow down with valgrind.
I've reproduced the error and fixed it.
The problem was, not only page up/down keys were dropped.
This code does not work (because of the implicit casts?)
static const int delayed_keys = Qt::Key_PageDown | Qt::Key_PageUp;
if (e->key() & delayed_keys) {
I have to replace it by
if (e->key() == Qt::Key_PageDown || e->key() == Qt::Key_PageUp) {
With running valgrind I could also reproduce the scroll bar
behavior reported by Helge, but here I could fix it with
the patch.
Thank you for putting so much work into this!
Unfortunately, event_4 helps only a little for me.
It seems to help most for short periods of scrolling.
If I scroll a long way, such as through an entire chapter of the userguide
before releasing the mouse, then LyX still overshoot with several pages.
Using the scrollbar arrows or the page down key is no better. (I don't
need to scroll through a whole chapter when using the arrows)
Test machine:
2.4GHz pentium IV, running debian linux.
Graphics: radeon 7000, which is kind of oldish but it has
always been fine for non-3D use.
Problems happen only when the cpu get to 100% load. No
problems as long as there is some capacity left.
I have heard that LyX repaints everything even on single-line scroll.
That means the arrow-down scroll probably will improve
if LyX is optimized to just shift the screen bitmap and repaint
only the exposed area. This would also help jump scrolling, as
a "jump" usually is less than half a screen.
Perhaps such optimization is the way to go, seeing that nobody
but me have these problems. Optimization helps everybody,
by making LyX snappier, and it also makes this particular problem
much less likely.
Helge Hafting
Re: Ready for RC1?
Lars Gullik Bjønnes wrote: Peter Kümmel <[EMAIL PROTECTED]> writes: | | The idea of the patch was to drop those events if | the last event wasn't processed. For mouse clicks, arrow keys, etc that is kindo ok, but for regular chars it is not acceptable. If I press 'abc' really fast, I still expect to get all three chars, even if a bit delayed.. This is important. When testing the new "listings" stuff (with the event_2 patch, I think), I noticed that typing inside a caption inside a listing inset was very slow. Now, I hope the slowness can be improved. But LyX would also happily swallow about every other keystroke at normal typing speed. So throwing away anything that goes in "too fast" sure isn't an option. LyX should ideally be so fast that we can't type ahead with text, but when we can anyway, LyX should remember it. Scrolling is very different. Helge Hafting
Re: Ready for RC1?
Peter Kümmel <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| >
| > | > "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
| > |
| > | Peter> I've reproduced the error and fixed it. The problem was, not
| > | Peter> only page up/down keys were dropped. This code does not work
| > | Peter> (because of the implicit casts?)
| > |
| > | Peter> static const int delayed_keys = Qt::Key_PageDown |
| > | Peter> Qt::Key_PageUp; if (e->key() & delayed_keys) {
| > |
| > | I know this stuff is very difficult to get right, but I do not like at
| > | all the idea of testing explicitely qt::pageup/down. We should not
| > | depend on these hardcoded keys. For example, your patch will fail for
| > | people who use the emacs bindings and use Ctrl+v for page down. I am
| > | not asking for adding another case for Ctrl+v (!) but I'd prefer a
| > | solution which does not take this into account (especially since I do
| > | not understand why only PageDown would be a problem (why is paragraph
| > | down not a problem?)
| >
| > What is the problem that you are trying to solve here?
| >
|
| The bug is the overshooting when the user scrolls by
|
| - clicking in the scroll bar
| - pressing page up/down keys
| - arrow keys
| - arrow buttons on the scroll bar
| - using the mouse wheel
| - key bindings
|
|
| The idea of the patch was to drop those events if
| the last event wasn't processed.
For mouse clicks, arrow keys, etc that is kindo ok, but for regular
chars it is not acceptable. If I press 'abc' really fast, I still
expect to get all three chars, even if a bit delayed..
--
Lgb
Re: Ready for RC1?
Peter Kümmel <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| >
| > | Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > |
| > | | > "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
| > | |
| > | | Peter> I've reproduced the error and fixed it. The problem was, not
| > | | Peter> only page up/down keys were dropped. This code does not work
| > | | Peter> (because of the implicit casts?)
| > | |
| > | | Peter> static const int delayed_keys = Qt::Key_PageDown |
| > | | Peter> Qt::Key_PageUp; if (e->key() & delayed_keys) {
| > | |
| > | | I know this stuff is very difficult to get right, but I do not like at
| > | | all the idea of testing explicitely qt::pageup/down. We should not
| > | | depend on these hardcoded keys. For example, your patch will fail for
| > | | people who use the emacs bindings and use Ctrl+v for page down. I am
| > | | not asking for adding another case for Ctrl+v (!) but I'd prefer a
| > | | solution which does not take this into account (especially since I do
| > | | not understand why only PageDown would be a problem (why is paragraph
| > | | down not a problem?)
| > |
| > | What is the problem that you are trying to solve here?
| >
| > Is it my old pet? "Countinued scorrling after key-release"?
| >
| > What was wrong with my patch from months back?
|
| It only fixes scrolling with keys.
So you already fixed the mouse scrolling then?
(Because just before I added this patch, key scrolling was way off, as
of now. both mouse scrolling and key scrolling work fine in my
scenario)
--
Lgb
Re: Ready for RC1?
On Friday 25 May 2007 15:57:28 José Matos wrote: > Hi, > are we ready for RC1, in the goals that I have stated to RC1 I had > proposed a week between beta 3 and release candidate 1 to avoid any error > that had evaded our search us before. There are important patches that are being discussed and that I felt worthy enough to delay the release again. I propose tomorrow, around 10 pm WET (UTC+2 ?) as the new deadline. -- José Abílio
Re: Ready for RC1?
Angus Leeming wrote: > Peter Kümmel wrote: >> Yes, I also don't like the hardcoding. The problem is that if we start >> to drop events we have to differentiate between good and bad events, and >> it is hard to find a solution for all cases. So it would be better not >> to drop any key. But what is the alternative? A XSync call could block >> the main thread, but suppresses it the auto generated key events? Does >> it not eat user generated events? > > At the time that this filtering code is called, you already know what > key bindings the LyX user is using. So, you could replace the hard-coded > Qt::Key_PageDown, etc with > lyx::PageDownKeyEvent() > where this function encapsulates the different cua.bind, emacs.bind, etc > syntax. Very good, in principle we then only need to check the return values of a list of functions, (if we not drop this ansatz). > > Regards, > Angus > -- Peter Kümmel
Re: Ready for RC1?
Peter Kümmel wrote: Yes, I also don't like the hardcoding. The problem is that if we start to drop events we have to differentiate between good and bad events, and it is hard to find a solution for all cases. So it would be better not to drop any key. But what is the alternative? A XSync call could block the main thread, but suppresses it the auto generated key events? Does it not eat user generated events? At the time that this filtering code is called, you already know what key bindings the LyX user is using. So, you could replace the hard-coded Qt::Key_PageDown, etc with lyx::PageDownKeyEvent() where this function encapsulates the different cua.bind, emacs.bind, etc syntax. Regards, Angus
Re: Ready for RC1?
Jean-Marc Lasgouttes wrote:
>> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
>
> Peter> I've reproduced the error and fixed it. The problem was, not
> Peter> only page up/down keys were dropped. This code does not work
> Peter> (because of the implicit casts?)
>
> Peter> static const int delayed_keys = Qt::Key_PageDown |
> Peter> Qt::Key_PageUp; if (e->key() & delayed_keys) {
>
> I know this stuff is very difficult to get right, but I do not like at
> all the idea of testing explicitely qt::pageup/down. We should not
> depend on these hardcoded keys. For example, your patch will fail for
> people who use the emacs bindings and use Ctrl+v for page down. I am
> not asking for adding another case for Ctrl+v (!) but I'd prefer a
> solution which does not take this into account (especially since I do
> not understand why only PageDown would be a problem (why is paragraph
> down not a problem?)
>
> JMarc
>
Yes, I also don't like the hardcoding. The problem is that if we start
to drop events we have to differentiate between good and bad events, and
it is hard to find a solution for all cases. So it would be better not
to drop any key. But what is the alternative? A XSync call could block
the main thread, but suppresses it the auto generated key events? Does
it not eat user generated events?
Peter
Re: Ready for RC1?
Peter Kümmel wrote:
> Lars Gullik Bjønnes wrote:
>> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>>
>> | Lars Gullik Bjønnes wrote:
>> | > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
>> | > | Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
>> | > writes:
>> | > | | | > "Peter" == Peter Kümmel
>> | > <[EMAIL PROTECTED]> writes:
>> | > | | | | Peter> I've reproduced the error and fixed it. The problem
>> | > was, not
>> | > | | Peter> only page up/down keys were dropped. This code does not work
>> | > | | Peter> (because of the implicit casts?)
>> | > | | | | Peter> static const int delayed_keys = Qt::Key_PageDown |
>> | > | | Peter> Qt::Key_PageUp; if (e->key() & delayed_keys) {
>> | > | | | | I know this stuff is very difficult to get right, but I do
>> | > not like at
>> | > | | all the idea of testing explicitely qt::pageup/down. We should not
>> | > | | depend on these hardcoded keys. For example, your patch will fail for
>> | > | | people who use the emacs bindings and use Ctrl+v for page down. I am
>> | > | | not asking for adding another case for Ctrl+v (!) but I'd prefer a
>> | > | | solution which does not take this into account (especially since I do
>> | > | | not understand why only PageDown would be a problem (why is paragraph
>> | > | | down not a problem?)
>> | > | | What is the problem that you are trying to solve here?
>> | > Is it my old pet? "Countinued scorrling after key-release"?
>> |
>> | Only the keyboard part is the same.
>>
>> In what sense?
>>
>> | > What was wrong with my patch from months back?
>> |
>> | I guess nothing (and I told you to commit at the time). FYI I posted
>> | your last version of the patch in bugzilla:
>> |
>> | http://bugzilla.lyx.org/show_bug.cgi?id=3320
>>
>> So why are you trying other exotic patches now?
>
> See the archive.
In short, I've tried different approaches and all have failed.
And the scroll bar scrolling overshooting is still not fixed.
For the key processing your patch should be enough.
>
>> (At the time I felt that the patch was a bit hackish, X11 only and had
>> too little testing.)
>>
>
>
--
Peter Kümmel
Re: Ready for RC1?
Lars Gullik Bjønnes wrote: > | > (At the time I felt that the patch was a bit hackish, X11 only and had > | > too little testing.) Do you know QApplication::syncX, but it is maybe call to XSync with false. I've also used XSync in the scroll event but then the scrolling behavior was really bad. > | > | Peter went through several patch and approach because each of those > | was failing one test or another AFAIU. > > I'll let Peter tell me why my approach was ditched then. > Initially I thought I could fix all other overshoots, --more elegantly, without X11 headers-- but I ended with current hack. -- Peter Kümmel
Re: Ready for RC1?
Lars Gullik Bjønnes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> | Lars Gullik Bjønnes wrote:
> | > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
> | > | Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
> | > writes:
> | > | | | > "Peter" == Peter Kümmel
> | > <[EMAIL PROTECTED]> writes:
> | > | | | | Peter> I've reproduced the error and fixed it. The problem
> | > was, not
> | > | | Peter> only page up/down keys were dropped. This code does not work
> | > | | Peter> (because of the implicit casts?)
> | > | | | | Peter> static const int delayed_keys = Qt::Key_PageDown |
> | > | | Peter> Qt::Key_PageUp; if (e->key() & delayed_keys) {
> | > | | | | I know this stuff is very difficult to get right, but I do
> | > not like at
> | > | | all the idea of testing explicitely qt::pageup/down. We should not
> | > | | depend on these hardcoded keys. For example, your patch will fail for
> | > | | people who use the emacs bindings and use Ctrl+v for page down. I am
> | > | | not asking for adding another case for Ctrl+v (!) but I'd prefer a
> | > | | solution which does not take this into account (especially since I do
> | > | | not understand why only PageDown would be a problem (why is paragraph
> | > | | down not a problem?)
> | > | | What is the problem that you are trying to solve here?
> | > Is it my old pet? "Countinued scorrling after key-release"?
> |
> | Only the keyboard part is the same.
>
> In what sense?
>
> | > What was wrong with my patch from months back?
> |
> | I guess nothing (and I told you to commit at the time). FYI I posted
> | your last version of the patch in bugzilla:
> |
> | http://bugzilla.lyx.org/show_bug.cgi?id=3320
>
> So why are you trying other exotic patches now?
See the archive.
> (At the time I felt that the patch was a bit hackish, X11 only and had
> too little testing.)
>
--
Peter Kümmel
Re: Ready for RC1?
Lars Gullik Bjønnes wrote:
> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
>
> | Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> |
> | | > "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
> | |
> | | Peter> I've reproduced the error and fixed it. The problem was, not
> | | Peter> only page up/down keys were dropped. This code does not work
> | | Peter> (because of the implicit casts?)
> | |
> | | Peter> static const int delayed_keys = Qt::Key_PageDown |
> | | Peter> Qt::Key_PageUp; if (e->key() & delayed_keys) {
> | |
> | | I know this stuff is very difficult to get right, but I do not like at
> | | all the idea of testing explicitely qt::pageup/down. We should not
> | | depend on these hardcoded keys. For example, your patch will fail for
> | | people who use the emacs bindings and use Ctrl+v for page down. I am
> | | not asking for adding another case for Ctrl+v (!) but I'd prefer a
> | | solution which does not take this into account (especially since I do
> | | not understand why only PageDown would be a problem (why is paragraph
> | | down not a problem?)
> |
> | What is the problem that you are trying to solve here?
>
> Is it my old pet? "Countinued scorrling after key-release"?
>
> What was wrong with my patch from months back?
It only fixes scrolling with keys.
>
> Index: src/frontends/qt4/GuiWorkArea.cpp
> ===
> --- src/frontends/qt4/GuiWorkArea.cpp (revision 18535)
> +++ src/frontends/qt4/GuiWorkArea.cpp (working copy)
> @@ -45,6 +45,9 @@
> #include
> #include
>
> +#ifdef Q_WS_X11
> +# include
> +#endif
> #include
> #include
>
> @@ -412,6 +415,13 @@
> }
>
>
> +#ifdef Q_WS_X11
> + extern "C" {
> + int XEventsQueued(Display * display, int mode);
> + int XSync(Display *, bool);
> + }
> +#endif
> +
> void GuiWorkArea::keyPressEvent(QKeyEvent * e)
> {
>
> @@ -422,6 +432,16 @@
> << " key=" << e->key()
> << endl;
>
> +#ifdef Q_WS_X11
> + if (e->isAutoRepeat()) {
> + if (XEventsQueued(QX11Info::display(), 0 /* QueuedAlready */) >
> 0) {
> + XSync(QX11Info::display(), true);
> + e->ignore();
> + return;
> + }
> + }
> +#endif
> +
> boost::shared_ptr sym(new QKeySymbol);
> sym->set(e);
> processKeySym(sym, q_key_state(e->modifiers()));
>
--
Peter Kümmel
Re: Ready for RC1?
Dov Feldstern wrote:
> Jean-Marc Lasgouttes wrote:
>>> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
>>
>> Peter> I've reproduced the error and fixed it. The problem was, not
>> Peter> only page up/down keys were dropped. This code does not work
>> Peter> (because of the implicit casts?)
>>
>> Peter> static const int delayed_keys = Qt::Key_PageDown |
>> Peter> Qt::Key_PageUp; if (e->key() & delayed_keys) {
>>
>> I know this stuff is very difficult to get right, but I do not like at
>> all the idea of testing explicitely qt::pageup/down. We should not
>> depend on these hardcoded keys. For example, your patch will fail for
>> people who use the emacs bindings and use Ctrl+v for page down. I am
>> not asking for adding another case for Ctrl+v (!) but I'd prefer a
>> solution which does not take this into account (especially since I do
>> not understand why only PageDown would be a problem (why is paragraph
>> down not a problem?)
>>
>> JMarc
>>
>>
>
> Peter, there's one thing I don't understand regarding this whole issue:
> doesn't holding the key down generate only *one* "key-down" and *one*
> "key-up" event? Whereas just pressing a key without holding it geenrates
> a single "keypress" event for every time it's pressed? (I don't know of
A page up/down key press event will be only dropped, if the last one wasn't
processed, so the auto repeated key press events could also produce
multiple scroll events.
> these are the correct terms, I don't know Qt at all, but the idea is
> probably the same). So couldn't we use that to differentiate? In other
> words, we should process every keypress event, and if that takes longer
> than it takes the user to generate them -- well, we should still process
> each one, because otherwise characters get swallowed; and if the
> keypresses are navigation keys, we should process those too --- every
> keypress the user presses means something. OTOH, if the user holds a
> key, we should just scroll or move or whatever as long as it's down, and
> stop as soon as the key is let go. How much we actually move or scroll
> or whatever will depend on the machine's speed, but that's fine: the
> important thing in this case is not to overshoot...
> I don;t know how mouse events fit in exactly, but I suspect it's
> similar: clicking multiple times on the scrollbar *should* "overshoot"
> --- i.e., every click should count. Holding the mouse button there,
> however, should not overshoot: as soon as the user stops pressing, the
> scrolling should stop.
>
> Again, I don't really know what I'm talking about, and I haven't been
> following the details of this issue very closely, but just in case this
> can be of some help...
>
Re: Ready for RC1?
Lars Gullik Bjønnes wrote:
> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> | > "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
> |
> | Peter> I've reproduced the error and fixed it. The problem was, not
> | Peter> only page up/down keys were dropped. This code does not work
> | Peter> (because of the implicit casts?)
> |
> | Peter> static const int delayed_keys = Qt::Key_PageDown |
> | Peter> Qt::Key_PageUp; if (e->key() & delayed_keys) {
> |
> | I know this stuff is very difficult to get right, but I do not like at
> | all the idea of testing explicitely qt::pageup/down. We should not
> | depend on these hardcoded keys. For example, your patch will fail for
> | people who use the emacs bindings and use Ctrl+v for page down. I am
> | not asking for adding another case for Ctrl+v (!) but I'd prefer a
> | solution which does not take this into account (especially since I do
> | not understand why only PageDown would be a problem (why is paragraph
> | down not a problem?)
>
> What is the problem that you are trying to solve here?
>
The bug is the overshooting when the user scrolls by
- clicking in the scroll bar
- pressing page up/down keys
- arrow keys
- arrow buttons on the scroll bar
- using the mouse wheel
- key bindings
The idea of the patch was to drop those events if
the last event wasn't processed.
--
Peter Kümmel
Re: Ready for RC1?
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Lars Gullik Bjønnes wrote:
| > | > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| > | > | Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
| > | > writes:
| > | > | | | > "Peter" == Peter Kümmel
| > | > <[EMAIL PROTECTED]> writes:
| > | > | | | | Peter> I've reproduced the error and fixed it. The problem
| > | > was, not
| > | > | | Peter> only page up/down keys were dropped. This code does not work
| > | > | | Peter> (because of the implicit casts?)
| > | > | | | | Peter> static const int delayed_keys = Qt::Key_PageDown |
| > | > | | Peter> Qt::Key_PageUp; if (e->key() & delayed_keys) {
| > | > | | | | I know this stuff is very difficult to get right, but I do
| > | > not like at
| > | > | | all the idea of testing explicitely qt::pageup/down. We should not
| > | > | | depend on these hardcoded keys. For example, your patch will fail
for
| > | > | | people who use the emacs bindings and use Ctrl+v for page down. I am
| > | > | | not asking for adding another case for Ctrl+v (!) but I'd prefer a
| > | > | | solution which does not take this into account (especially since I
do
| > | > | | not understand why only PageDown would be a problem (why is
paragraph
| > | > | | down not a problem?)
| > | > | | What is the problem that you are trying to solve here?
| > | > Is it my old pet? "Countinued scorrling after key-release"?
| > | | Only the keyboard part is the same.
| > In what sense?
|
| Peter's patch fix also the scrollbar lagging issues reported by Helge.
What scrollbar lagging issues? Similar to the continued scrolling
after key-release? (except that now it is mouse-button-release instead?)
|
| > | > What was wrong with my patch from months back?
| > | | I guess nothing (and I told you to commit at the time). FYI I
| > posted
| > | your last version of the patch in bugzilla:
| > | | http://bugzilla.lyx.org/show_bug.cgi?id=3320
| > So why are you trying other exotic patches now?
| Me?
no. you all.
| I am just giving some help and some direction. Peter is doing the
| work. I guess he weighted the pro and cons of your approach.
|
| > (At the time I felt that the patch was a bit hackish, X11 only and had
| > too little testing.)
|
| Peter went through several patch and approach because each of those
| was failing one test or another AFAIU.
I'll let Peter tell me why my approach was ditched then.
--
Lgb
Re: Ready for RC1?
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| > | Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
| > writes:
| > | | | > "Peter" == Peter Kümmel
| > <[EMAIL PROTECTED]> writes:
| > | | | | Peter> I've reproduced the error and fixed it. The problem
| > was, not
| > | | Peter> only page up/down keys were dropped. This code does not work
| > | | Peter> (because of the implicit casts?)
| > | | | | Peter> static const int delayed_keys = Qt::Key_PageDown |
| > | | Peter> Qt::Key_PageUp; if (e->key() & delayed_keys) {
| > | | | | I know this stuff is very difficult to get right, but I do
| > not like at
| > | | all the idea of testing explicitely qt::pageup/down. We should not
| > | | depend on these hardcoded keys. For example, your patch will fail for
| > | | people who use the emacs bindings and use Ctrl+v for page down. I am
| > | | not asking for adding another case for Ctrl+v (!) but I'd prefer a
| > | | solution which does not take this into account (especially since I do
| > | | not understand why only PageDown would be a problem (why is paragraph
| > | | down not a problem?)
| > | | What is the problem that you are trying to solve here?
| > Is it my old pet? "Countinued scorrling after key-release"?
|
| Only the keyboard part is the same.
In what sense?
Peter's patch fix also the scrollbar lagging issues reported by Helge.
| > What was wrong with my patch from months back?
|
| I guess nothing (and I told you to commit at the time). FYI I posted
| your last version of the patch in bugzilla:
|
| http://bugzilla.lyx.org/show_bug.cgi?id=3320
So why are you trying other exotic patches now?
Me? I am just giving some help and some direction. Peter is doing the
work. I guess he weighted the pro and cons of your approach.
(At the time I felt that the patch was a bit hackish, X11 only and had
too little testing.)
Peter went through several patch and approach because each of those was
failing one test or another AFAIU.
Abdel.
Re: Ready for RC1?
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| > | Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
| > writes:
| > | | | > "Peter" == Peter Kümmel
| > <[EMAIL PROTECTED]> writes:
| > | | | | Peter> I've reproduced the error and fixed it. The problem
| > was, not
| > | | Peter> only page up/down keys were dropped. This code does not work
| > | | Peter> (because of the implicit casts?)
| > | | | | Peter> static const int delayed_keys = Qt::Key_PageDown |
| > | | Peter> Qt::Key_PageUp; if (e->key() & delayed_keys) {
| > | | | | I know this stuff is very difficult to get right, but I do
| > not like at
| > | | all the idea of testing explicitely qt::pageup/down. We should not
| > | | depend on these hardcoded keys. For example, your patch will fail for
| > | | people who use the emacs bindings and use Ctrl+v for page down. I am
| > | | not asking for adding another case for Ctrl+v (!) but I'd prefer a
| > | | solution which does not take this into account (especially since I do
| > | | not understand why only PageDown would be a problem (why is paragraph
| > | | down not a problem?)
| > | | What is the problem that you are trying to solve here?
| > Is it my old pet? "Countinued scorrling after key-release"?
|
| Only the keyboard part is the same.
In what sense?
| > What was wrong with my patch from months back?
|
| I guess nothing (and I told you to commit at the time). FYI I posted
| your last version of the patch in bugzilla:
|
| http://bugzilla.lyx.org/show_bug.cgi?id=3320
So why are you trying other exotic patches now?
(At the time I felt that the patch was a bit hackish, X11 only and had
too little testing.)
--
Lgb
Re: Ready for RC1?
Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
|
| | > "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
| |
| | Peter> I've reproduced the error and fixed it. The problem was, not
| | Peter> only page up/down keys were dropped. This code does not work
| | Peter> (because of the implicit casts?)
| |
| | Peter> static const int delayed_keys = Qt::Key_PageDown |
| | Peter> Qt::Key_PageUp; if (e->key() & delayed_keys) {
| |
| | I know this stuff is very difficult to get right, but I do not like at
| | all the idea of testing explicitely qt::pageup/down. We should not
| | depend on these hardcoded keys. For example, your patch will fail for
| | people who use the emacs bindings and use Ctrl+v for page down. I am
| | not asking for adding another case for Ctrl+v (!) but I'd prefer a
| | solution which does not take this into account (especially since I do
| | not understand why only PageDown would be a problem (why is paragraph
| | down not a problem?)
|
| What is the problem that you are trying to solve here?
Is it my old pet? "Countinued scorrling after key-release"?
Only the keyboard part is the same.
What was wrong with my patch from months back?
I guess nothing (and I told you to commit at the time). FYI I posted
your last version of the patch in bugzilla:
http://bugzilla.lyx.org/show_bug.cgi?id=3320
Abde.
Re: Ready for RC1?
Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
|
| | > "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
| |
| | Peter> I've reproduced the error and fixed it. The problem was, not
| | Peter> only page up/down keys were dropped. This code does not work
| | Peter> (because of the implicit casts?)
| |
| | Peter> static const int delayed_keys = Qt::Key_PageDown |
| | Peter> Qt::Key_PageUp; if (e->key() & delayed_keys) {
| |
| | I know this stuff is very difficult to get right, but I do not like at
| | all the idea of testing explicitely qt::pageup/down. We should not
| | depend on these hardcoded keys. For example, your patch will fail for
| | people who use the emacs bindings and use Ctrl+v for page down. I am
| | not asking for adding another case for Ctrl+v (!) but I'd prefer a
| | solution which does not take this into account (especially since I do
| | not understand why only PageDown would be a problem (why is paragraph
| | down not a problem?)
|
| What is the problem that you are trying to solve here?
Is it my old pet? "Countinued scorrling after key-release"?
What was wrong with my patch from months back?
Works for me!
Re: Ready for RC1?
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
|
| | > "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
| |
| | Peter> I've reproduced the error and fixed it. The problem was, not
| | Peter> only page up/down keys were dropped. This code does not work
| | Peter> (because of the implicit casts?)
| |
| | Peter> static const int delayed_keys = Qt::Key_PageDown |
| | Peter> Qt::Key_PageUp; if (e->key() & delayed_keys) {
| |
| | I know this stuff is very difficult to get right, but I do not like at
| | all the idea of testing explicitely qt::pageup/down. We should not
| | depend on these hardcoded keys. For example, your patch will fail for
| | people who use the emacs bindings and use Ctrl+v for page down. I am
| | not asking for adding another case for Ctrl+v (!) but I'd prefer a
| | solution which does not take this into account (especially since I do
| | not understand why only PageDown would be a problem (why is paragraph
| | down not a problem?)
|
| What is the problem that you are trying to solve here?
Is it my old pet? "Countinued scorrling after key-release"?
What was wrong with my patch from months back?
Index: src/frontends/qt4/GuiWorkArea.cpp
===
--- src/frontends/qt4/GuiWorkArea.cpp (revision 18535)
+++ src/frontends/qt4/GuiWorkArea.cpp (working copy)
@@ -45,6 +45,9 @@
#include
#include
+#ifdef Q_WS_X11
+# include
+#endif
#include
#include
@@ -412,6 +415,13 @@
}
+#ifdef Q_WS_X11
+ extern "C" {
+ int XEventsQueued(Display * display, int mode);
+ int XSync(Display *, bool);
+ }
+#endif
+
void GuiWorkArea::keyPressEvent(QKeyEvent * e)
{
@@ -422,6 +432,16 @@
<< " key=" << e->key()
<< endl;
+#ifdef Q_WS_X11
+ if (e->isAutoRepeat()) {
+ if (XEventsQueued(QX11Info::display(), 0 /* QueuedAlready */) >
0) {
+ XSync(QX11Info::display(), true);
+ e->ignore();
+ return;
+ }
+ }
+#endif
+
boost::shared_ptr sym(new QKeySymbol);
sym->set(e);
processKeySym(sym, q_key_state(e->modifiers()));
--
Lgb
Re: Ready for RC1?
This drawer patch should go in: http://bugzilla.lyx.org/show_bug.cgi?id=3500 Stefan Am 25.05.2007 um 16:57 schrieb José Matos: Hi, are we ready for RC1, in the goals that I have stated to RC1 I had proposed a week between beta 3 and release candidate 1 to avoid any error that had evaded our search us before. We have bugs but nothing so glaring that we can not ship the first release candidate. If you don't disagree I would like to release either tonight or next Sunday. Objections, patches to consider, etc... -- José Abílio PGP.sig Description: Signierter Teil der Nachricht
Re: Ready for RC1?
Jean-Marc Lasgouttes wrote:
"Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
Peter> I've reproduced the error and fixed it. The problem was, not
Peter> only page up/down keys were dropped. This code does not work
Peter> (because of the implicit casts?)
Peter> static const int delayed_keys = Qt::Key_PageDown |
Peter> Qt::Key_PageUp; if (e->key() & delayed_keys) {
I know this stuff is very difficult to get right, but I do not like at
all the idea of testing explicitely qt::pageup/down. We should not
depend on these hardcoded keys. For example, your patch will fail for
people who use the emacs bindings and use Ctrl+v for page down. I am
not asking for adding another case for Ctrl+v (!) but I'd prefer a
solution which does not take this into account (especially since I do
not understand why only PageDown would be a problem (why is paragraph
down not a problem?)
JMarc
Peter, there's one thing I don't understand regarding this whole issue:
doesn't holding the key down generate only *one* "key-down" and *one*
"key-up" event? Whereas just pressing a key without holding it geenrates
a single "keypress" event for every time it's pressed? (I don't know of
these are the correct terms, I don't know Qt at all, but the idea is
probably the same). So couldn't we use that to differentiate? In other
words, we should process every keypress event, and if that takes longer
than it takes the user to generate them -- well, we should still process
each one, because otherwise characters get swallowed; and if the
keypresses are navigation keys, we should process those too --- every
keypress the user presses means something. OTOH, if the user holds a
key, we should just scroll or move or whatever as long as it's down, and
stop as soon as the key is let go. How much we actually move or scroll
or whatever will depend on the machine's speed, but that's fine: the
important thing in this case is not to overshoot...
I don;t know how mouse events fit in exactly, but I suspect it's
similar: clicking multiple times on the scrollbar *should* "overshoot"
--- i.e., every click should count. Holding the mouse button there,
however, should not overshoot: as soon as the user stops pressing, the
scrolling should stop.
Again, I don't really know what I'm talking about, and I haven't been
following the details of this issue very closely, but just in case this
can be of some help...
Re: Ready for RC1?
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
|
| Peter> I've reproduced the error and fixed it. The problem was, not
| Peter> only page up/down keys were dropped. This code does not work
| Peter> (because of the implicit casts?)
|
| Peter> static const int delayed_keys = Qt::Key_PageDown |
| Peter> Qt::Key_PageUp; if (e->key() & delayed_keys) {
|
| I know this stuff is very difficult to get right, but I do not like at
| all the idea of testing explicitely qt::pageup/down. We should not
| depend on these hardcoded keys. For example, your patch will fail for
| people who use the emacs bindings and use Ctrl+v for page down. I am
| not asking for adding another case for Ctrl+v (!) but I'd prefer a
| solution which does not take this into account (especially since I do
| not understand why only PageDown would be a problem (why is paragraph
| down not a problem?)
What is the problem that you are trying to solve here?
--
Lgb
Re: Ready for RC1?
> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
Peter> I've reproduced the error and fixed it. The problem was, not
Peter> only page up/down keys were dropped. This code does not work
Peter> (because of the implicit casts?)
Peter> static const int delayed_keys = Qt::Key_PageDown |
Peter> Qt::Key_PageUp; if (e->key() & delayed_keys) {
I know this stuff is very difficult to get right, but I do not like at
all the idea of testing explicitely qt::pageup/down. We should not
depend on these hardcoded keys. For example, your patch will fail for
people who use the emacs bindings and use Ctrl+v for page down. I am
not asking for adding another case for Ctrl+v (!) but I'd prefer a
solution which does not take this into account (especially since I do
not understand why only PageDown would be a problem (why is paragraph
down not a problem?)
JMarc
Re: Ready for RC1?
Dov Feldstern wrote:
> (I hope I'm referring to the correct version of the patch:) As Helge
> already reported, on very slow systems (I tested this by running under
> valgrind), if you type quickly, some keystrokes get swallowed...
Nice idea to slow down with valgrind.
I've reproduced the error and fixed it.
The problem was, not only page up/down keys were dropped.
This code does not work (because of the implicit casts?)
static const int delayed_keys = Qt::Key_PageDown | Qt::Key_PageUp;
if (e->key() & delayed_keys) {
I have to replace it by
if (e->key() == Qt::Key_PageDown || e->key() == Qt::Key_PageUp) {
With running valgrind I could also reproduce the scroll bar
behavior reported by Helge, but here I could fix it with
the patch.
Attached the updated patch.
Peter
Index: src/frontends/qt4/GuiWorkArea.cpp
===
--- src/frontends/qt4/GuiWorkArea.cpp (revision 18512)
+++ src/frontends/qt4/GuiWorkArea.cpp (working copy)
@@ -190,8 +190,11 @@
// Initialize the vertical Scroll Bar
QObject::connect(verticalScrollBar(), SIGNAL(actionTriggered(int)),
- this, SLOT(adjustViewWithScrollBar(int)));
+ this, SLOT(generateLyxScrollEvent()));
+ QObject::connect(verticalScrollBar(), SIGNAL(sliderReleased()),
+ this, SLOT(lyxScrollEvent()));
+
// disable context menu for the scrollbar
verticalScrollBar()->setContextMenuPolicy(Qt::NoContextMenu);
@@ -211,6 +214,53 @@
}
+
+class LyxScrollEvent : public QEvent
+{
+public:
+ LyxScrollEvent() : QEvent(QEvent::Type(id))
+ {}
+ static int id;
+ static bool locked;
+};
+
+// Qt doc: user event type between 1000 and 65535
+int LyxScrollEvent::id = 31415;
+bool LyxScrollEvent::locked = false;
+
+
+class LyxKeyEvent : public QKeyEvent
+{
+public:
+ LyxKeyEvent(QKeyEvent * e) :
+ QKeyEvent(QEvent::Type(id), e->key(),
+ e->modifiers(), e->text(), e->isAutoRepeat(),
e->count())
+ {}
+ static int id;
+ static bool locked;
+};
+
+int LyxKeyEvent::id = 27182;
+bool LyxKeyEvent::locked = false;
+
+
+
+bool GuiWorkArea::event(QEvent * event)
+{
+ if (event->type() == LyxKeyEvent::id) {
+ lyxKeyEvent(dynamic_cast(event));
+ LyxKeyEvent::locked = false;
+ return true;
+ } else if (event->type() == LyxScrollEvent::id) {
+ lyxScrollEvent();
+ LyxScrollEvent::locked = false;
+ return true;
+ } else {
+ return QAbstractScrollArea::event(event);
+ }
+}
+
+
void GuiWorkArea::setScrollbarParams(int h, int scroll_pos, int
scroll_line_step)
{
if (verticalScrollBarPolicy() != Qt::ScrollBarAlwaysOn)
@@ -231,12 +281,30 @@
}
-void GuiWorkArea::adjustViewWithScrollBar(int)
+void GuiWorkArea::lyxScrollEvent()
{
scrollBufferView(verticalScrollBar()->sliderPosition());
}
+void GuiWorkArea::generateLyxScrollEvent()
+{
+ // This gives the old slow (the scroll bar couldn't follow the mouse)
+ // scrolling on Windows. Is it really better?
+ // Windows/Qt is here not as fast as X11
+ //lyxScrollEvent();return;
+
+ // multiple scroll events are merged into one
+ if (!LyxScrollEvent::locked) {
+ LyxScrollEvent::locked = true;
+ LyxScrollEvent* scrollEvent = new LyxScrollEvent;
+ QCoreApplication::postEvent(this, scrollEvent);
+ LYXERR(Debug::GUI) << "scrolling: one event posted" << endl;
+ } else {
+ LYXERR(Debug::GUI) << "scrolling: waiting for processing last
scrolling event" << endl;
+ }
+}
+
void GuiWorkArea::dragEnterEvent(QDragEnterEvent * event)
{
if (event->mimeData()->hasUrls())
@@ -389,13 +457,14 @@
int const lines = qApp->wheelScrollLines() * e->delta() / 120;
verticalScrollBar()->setValue(verticalScrollBar()->value() -
lines * verticalScrollBar()->singleStep());
- adjustViewWithScrollBar();
+
+ generateLyxScrollEvent();
}
void GuiWorkArea::generateSyntheticMouseEvent()
{
-// Set things off to generate the _next_ 'pseudo' event.
+ // Set things off to generate the _next_ 'pseudo' event.
if (synthetic_mouse_event_.restart_timeout)
synthetic_mouse_event_.timeout.start();
@@ -414,7 +483,26 @@
void GuiWorkArea::keyPressEvent(QKeyEvent * e)
{
+ if (e->key() == Qt::Key_PageDown || e->key() == Qt::Key_PageUp) {
+ if (!LyxKeyEvent::locked) {
+ LyxKeyEvent::locked = true;
+ QCoreApplication::postEvent(this, new LyxKeyEvent(e));
+ e->ignore();
+ LYXERR(Debug::GUI) << "key processing : event queued"
<< endl;
+ } else {
+ e->ignore();
+
Re: Ready for RC1?
Peter Kümmel wrote: José Matos wrote: On Friday 25 May 2007 18:11:28 Peter Kümmel wrote: I still think my scrolling patch http://marc.info/?l=lyx-devel&m=117968102228177&w=2 is better than nothing. Try to scroll on Linux with and without the patch, and at least when scrolling with keys you will see an improvment. What are the drawbacks? I have the thread open but sometimes it is easier to ask for an abstract. :-) Currently I don't know if it breaks something. It doesn't help on setups like Helge's, but it improves the scrolling with keys. Dov had applied the patch and didn't report any new errors. The drawback is that it isn't the final patch on this issue. We still have to figure out what's going on on X11. The patch improves the scrolling on some fast Linux systems, doesn't help on sytems like Helge's, changes the scrolling behaviour a bit on Windows (the scrollbar slider is in sync with the mouse). Additionally there was not much testing, so let it apply to RC1 then we will have tests ;) Peter (I hope I'm referring to the correct version of the patch:) As Helge already reported, on very slow systems (I tested this by running under valgrind), if you type quickly, some keystrokes get swallowed...
Re: Ready for RC1?
> Objections, patches to consider, etc... Only a patch: I would like to have the next unicodesymbols patch in because this is another step to better unicode support: http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg118499.html If this is too late for pre1 it would be nice if it can go in before 1.5.0. regards Uwe
Re: Ready for RC1?
José Matos wrote: > On Friday 25 May 2007 18:11:28 Peter Kümmel wrote: >> I still think my scrolling patch >> http://marc.info/?l=lyx-devel&m=117968102228177&w=2 >> is better than nothing. Try to scroll on Linux >> with and without the patch, and at least when scrolling >> with keys you will see an improvment. > > What are the drawbacks? I have the thread open but sometimes it is easier > to > ask for an abstract. :-) > Currently I don't know if it breaks something. It doesn't help on setups like Helge's, but it improves the scrolling with keys. Dov had applied the patch and didn't report any new errors. The drawback is that it isn't the final patch on this issue. We still have to figure out what's going on on X11. The patch improves the scrolling on some fast Linux systems, doesn't help on sytems like Helge's, changes the scrolling behaviour a bit on Windows (the scrollbar slider is in sync with the mouse). Additionally there was not much testing, so let it apply to RC1 then we will have tests ;) Peter
Re: Ready for RC1?
On Friday 25 May 2007 16:08:48 Stefan Schimanski wrote: > On Mac (and probably other platforms, depending on the used font) the > cursor movement is broken (it skips lines). Moreover the target_x > code in Cursor is broken. I am working on a fix right now. I consider > it a bug which shouldn't be in a release candidate > > Stefan I will let you test your patch, please get feedback from others and as soon as you are confident in the results put it in. If nothing goes wrong I will release rc1 next Sunday. -- José Abílio
Re: Ready for RC1?
On Friday 25 May 2007 20:16:40 Abdelrazak Younes wrote: > Farsi... I don't forget my promisses. :-) -- José Abílio
Re: Ready for RC1?
On Friday 25 May 2007 18:11:28 Peter Kümmel wrote: > > I still think my scrolling patch > http://marc.info/?l=lyx-devel&m=117968102228177&w=2 > is better than nothing. Try to scroll on Linux > with and without the patch, and at least when scrolling > with keys you will see an improvment. What are the drawbacks? I have the thread open but sometimes it is easier to ask for an abstract. :-) -- José Abílio
Re: Ready for RC1?
On Friday 25 May 2007 17:48:30 Jean-Marc Lasgouttes wrote: > Are we sure that the format is frozen, or will you allow further > changes? There is no such guarantee yet. Why should we care? :-) The premise is there for 1.5.0. :-) > JMarc -- José Abílio
Re: Ready for RC1?
José Matos wrote: Hi, are we ready for RC1, in the goals that I have stated to RC1 I had proposed a week between beta 3 and release candidate 1 to avoid any error that had evaded our search us before. We have bugs but nothing so glaring that we can not ship the first release candidate. If you don't disagree I would like to release either tonight or next Sunday. Objections, patches to consider, etc... I am going to finish the cursor handling with multi-view. Give me ten minutes. Abdel.
Re: Ready for RC1?
José Matos wrote: Hi, are we ready for RC1, in the goals that I have stated to RC1 I had proposed a week between beta 3 and release candidate 1 to avoid any error that had evaded our search us before. We have bugs but nothing so glaring that we can not ship the first release candidate. If you don't disagree I would like to release either tonight or next Sunday. Objections, patches to consider, etc... Farsi...
Re: Ready for RC1?
are we ready for RC1, in the goals that I have stated to RC1 I had proposed a week between beta 3 and release candidate 1 to avoid any error that had evaded our search us before. There is no pending (listings) patch in my tree and the fact that shift-page down no longer crashes lyx make me believe that RC1 is ready. BTW, when I use shift-page down to select a huge portion of EmbededObjects.lyx, lyx enters a infinite loop of QClipboard::setData: Cannot set X11 selection owner for PRIMARY QClipboard::setData: Cannot set X11 selection owner for PRIMARY QClipboard::setData: Cannot set X11 selection owner for PRIMARY QClipboard::setData: Cannot set X11 selection owner for PRIMARY QClipboard::setData: Cannot set X11 selection owner for PRIMARY QClipboard::setData: Cannot set X11 selection owner for PRIMARY QClipboard::setData: Cannot set X11 selection owner for PRIMARY QClipboard::setData: Cannot set X11 selection owner for PRIMARY QClipboard::setData: Cannot set X11 selection owner for PRIMARY QClipboard::setData: Cannot set X11 selection owner for PRIMARY QClipboard::setData: Cannot set X11 selection owner for PRIMARY QClipboard::setData: Cannot set X11 selection owner for PRIMARY QClipboard::setData: Cannot set X11 selection owner for PRIMARY QClipboard::setData: Cannot set X11 selection owner for PRIMARY QClipboard::setData: Cannot set X11 selection owner for PRIMARY QClipboard::setData: Cannot set X11 selection owner for PRIMARY QClipboard::setData: Cannot set X11 selection owner for PRIMARY QClipboard::setData: Cannot set X11 selection owner for PRIMARY QClipboard::setData: Cannot set X11 selection owner for PRIMARY Cheers, Bo
Re: Ready for RC1?
José Matos wrote: > Hi, > are we ready for RC1, in the goals that I have stated to RC1 I had > proposed a > week between beta 3 and release candidate 1 to avoid any error that had > evaded our search us before. > > We have bugs but nothing so glaring that we can not ship the first > release > candidate. > > If you don't disagree I would like to release either tonight or next > Sunday. > > Objections, patches to consider, etc... > I still think my scrolling patch http://marc.info/?l=lyx-devel&m=117968102228177&w=2 is better than nothing. Try to scroll on Linux with and without the patch, and at least when scrolling with keys you will see an improvment. -- Peter Kümmel
Re: Ready for RC1?
> "José" == José Matos <[EMAIL PROTECTED]> writes: José> Hi, are we ready for RC1, in the goals that I have stated to RC1 José> I had proposed a week between beta 3 and release candidate 1 to José> avoid any error that had evaded our search us before. José> We have bugs but nothing so glaring that we can not ship the José> first release candidate. Are we sure that the format is frozen, or will you allow further changes? JMarc
Re: Ready for RC1?
Am 25.05.2007 um 16:57 schrieb José Matos: Hi, are we ready for RC1, in the goals that I have stated to RC1 I had proposed a week between beta 3 and release candidate 1 to avoid any error that had evaded our search us before. We have bugs but nothing so glaring that we can not ship the first release candidate. If you don't disagree I would like to release either tonight or next Sunday. Objections, patches to consider, etc... On Mac (and probably other platforms, depending on the used font) the cursor movement is broken (it skips lines). Moreover the target_x code in Cursor is broken. I am working on a fix right now. I consider it a bug which shouldn't be in a release candidate Stefan -- José Abílio PGP.sig Description: Signierter Teil der Nachricht
