item->orig_from = orig_from;
+ item->from_format = from_format;
+ item->to_format = to_format;
+ item->errorList = errorList;
+ item->conversionFlags = conversionflags;
+ queue.push_back(item);
+}
+
+
+list Converters::getQueue() const
+{
+ return queu
/Buffer.cpp
@@ -3660,6 +3660,13 @@ Buffer::ExportStatus Buffer::doExport(string const &
target, bool put_in_tempdir
}
}
+ list queue = theConverters().getQueue();
+ list::const_iterator cit = queue.begin();
+ list::const_iterator cend = queue.end();
+
ig_from,
+string const & from_format, string const & to_format,
+ ErrorList * errorList, int conversionflags)
+{
+ QueuedItem * item = new QueuedItem;
+ item->buffer = buffer;
+ item->from_file = from_file;
+ item->to
On Mon, 2005-06-06 at 15:17, Lars Gullik Bjønnes wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> I am fine with this.
> (I'd better be...)
Done.
- Martin
signature.asc
Description: This is a digitally signed message part
Martin Vermeer <[EMAIL PROTECTED]> writes:
I am fine with this.
(I'd better be...)
--
Lgb
n Vermeer <[EMAIL PROTECTED]> writes:
> >
> | ...
> |
> >> OK, that settles it then for me: put in the event queue and reverse the
> >> new stuff in workAreaKeyPress to a simple showCursor call. Then everything
> >> will be consistent, if slow.
les it then for me: put in the event queue and reverse the
>> new stuff in workAreaKeyPress to a simple showCursor call. Then everything
>> will be consistent, if slow.
>>
>> I verified that this works properly using an old version of your event
>> queue patch: doesn
On Wed, Jun 01, 2005 at 03:12:05PM +0300, Martin Vermeer wrote:
> On Wed, Jun 01, 2005 at 01:31:55PM +0200, Lars Gullik Bjønnes wrote:
> > Martin Vermeer <[EMAIL PROTECTED]> writes:
...
> OK, that settles it then for me: put in the event queue and reverse the
> new stuff i
Lars Gullik Bjønnes wrote:
Martin Vermeer <[EMAIL PROTECTED]> writes:
[...]
| No, I meant that just the other way around. The fact that fast mouse
| scrolling exists allows us to make keyboard scrolling slow... as your
| event queue for ex. does. The slowness will drive people to u
On Wed, Jun 01, 2005 at 01:31:55PM +0200, Lars Gullik Bjønnes wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> | On Wed, Jun 01, 2005 at 10:55:24AM +0200, Lars Gullik Bjønnes wrote:
> >> Martin Vermeer <[EMAIL PROTECTED]> writes:
> >
> | ...
> |
Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Wed, Jun 01, 2005 at 10:55:24AM +0200, Lars Gullik Bjønnes wrote:
>> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
| ...
|
>> What the event queue accomplishes is to say that: "We do not allow
>> auto-repeat
On Wed, Jun 01, 2005 at 10:55:24AM +0200, Lars Gullik Bjønnes wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
...
> What the event queue accomplishes is to say that: "We do not allow
> auto-repeat events to queue up faster than we are able to handle
> them."
e want to force mousy behaviour?
>> | I don't like your use of a key event queue in the front-end for
>> | achieving the effect. It's unnatural.
>>
>> Ohhh :-)
>>
>> Well I disagree.
>>
>> What the event queue accomplishes is to say t
Martin> + if (s == "Up" || s == "Down" || s == "Left" || s == "Right")
Martin> + screen().showCursor(*bv_);
Of course testing directly keys is not acceptable, but we could
imagine to have a LyXAction flag that tells whether an action requires
a screen update...
JMarc
rprising behaviour. And in pratices
> >> you force users to use the mouse for scrolling more than a couple of
> >> screen fulls.
> >
> | No, I meant that just the other way around. The fact that fast mouse
> | scrolling exists allows us to make keyboard scrolling slow...
>> | _every_ intermediate screenful. OTOH fast scrolling using the mouse
>> | exists.
>>
>> I don't. I think it is really surprising behaviour. And in pratices
>> you force users to use the mouse for scrolling more than a couple of
>> screen fulls.
>
| No, I
don't. I think it is really surprising behaviour. And in pratices
> you force users to use the mouse for scrolling more than a couple of
> screen fulls.
No, I meant that just the other way around. The fact that fast mouse
scrolling exists allows us to make keyboard scrolling slow... as
>> | have somewhat thoroughly tested this with the User Guide.
> >>
> >> Go ahead. I will redo my test afterwards.
> >
> | So done.
>
> Ok. I did my tests.
>
> I must admit that I now find it unusable. No feedback on screen when
> using cursor keys for moveme
a couple of
screen fulls.
>> The scrolling problem is fixed by adding in the event queue,
>
| Fixed in what way?
syncing the screen updates with the downward movement.
>> but the
>> cursor on auto-repeat is not fixed by that. We absolutely want the
>> cursor on-screen
ent (on auto-repeat)
>
> Same with PageDown/PageUp. (except from the scrollbar)
Which I think is good enough. I don't want to pay the price of rendering
_every_ intermediate screenful. OTOH fast scrolling using the mouse
exists.
> The scrolling problem is fixed by adding in the even
So done.
Ok. I did my tests.
I must admit that I now find it unusable. No feedback on screen when
using cursor keys for movement (on auto-repeat)
Same with PageDown/PageUp. (except from the scrollbar)
The scrolling problem is fixed by adding in the event queue, but the
cursor on auto-repeat is
On Tue, 2005-05-31 at 09:55, Lars Gullik Bjønnes wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> >> So it seems to fix most problems we have and feels uniformly better that
> >> what we have right now? If so...
> >
> | Yes, I believe so.
> >
> | Therefore I will commit the attached, if no
Martin Vermeer <[EMAIL PROTECTED]> writes:
>> So it seems to fix most problems we have and feels uniformly better that
>> what we have right now? If so...
>
| Yes, I believe so.
>
| Therefore I will commit the attached, if no new objections come up. I
| have somewhat thoroughly tested this with t
On Mon, 2005-05-30 at 16:01, Andre Poenitz wrote:
> On Mon, May 30, 2005 at 12:15:19PM +0300, Martin Vermeer wrote:
> > > How "asynchrounous" is Martin's approach, i.e. how long will LyX be busy
> > > after a user released PageDown?
> >
> > The time it takes to render one screen (or slightly over)
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> Key events are not coalesced (or have you dont something I have
| Lars> not noticed?) without my patch. Sure my patch also does not do
| Lars> it, but it could... Note that p
behavior.)
>
| And I cleaned it up a bit.
>
| If people feels that this make behaviour better I think we should
| commit this for 1.4.
I did some testing with current cvs (optimized build). the keyevent
queue helps in some cases. But it is seldom and not really noticebla.
I tested over a "s
On Mon, May 30, 2005 at 12:15:19PM +0300, Martin Vermeer wrote:
> > How "asynchrounous" is Martin's approach, i.e. how long will LyX be busy
> > after a user released PageDown?
>
> The time it takes to render one screen (or slightly over). I see no
> large backlogs.
So it seems to fix most proble
at 12:12:07AM +0200, Lars Gullik Bjønnes wrote:
> >> >> | Actually I have now had time to think about this for two weeks, and my
> >> >> | considered opinion is a bit different...
> >> >>
> >> >> What you write belowe seems very sane. But
Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Mon, 2005-05-30 at 12:46, Lars Gullik Bjønnes wrote:
>> Martin Vermeer <[EMAIL PROTECTED]> writes:
>>
>> >> How "asynchrounous" is Martin's approach, i.e. how long will LyX be busy
>> >> after a user released PageDown?
>> >
>> | The time it takes to
On Mon, 2005-05-30 at 12:46, Lars Gullik Bjønnes wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> >> How "asynchrounous" is Martin's approach, i.e. how long will LyX be busy
> >> after a user released PageDown?
> >
> | The time it takes to render one screen (or slightly over). I see no
> |
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> Key events are not coalesced (or have you dont something I have
| Lars> not noticed?) without my patch. Sure my patch also does not do
| Lars> it, but it could... Note that p
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Key events are not coalesced (or have you dont something I have
Lars> not noticed?) without my patch. Sure my patch also does not do
Lars> it, but it could... Note that pruning is only done if the screen
Lars> update cannot keep
had time to think about this for two weeks, and my
>> >> | considered opinion is a bit different...
>> >>
>> >> What you write belowe seems very sane. But I think that my keyevent
>> >> queue is still needed? (but to fix a different problem)
>> &g
Martin Vermeer <[EMAIL PROTECTED]> writes:
>> How "asynchrounous" is Martin's approach, i.e. how long will LyX be busy
>> after a user released PageDown?
>
| The time it takes to render one screen (or slightly over). I see no
| large backlogs.
Try that on a slower computer...
--
Lgb
On Mon, 2005-05-30 at 11:49, Andre Poenitz wrote:
> On Mon, May 30, 2005 at 09:56:06AM +0200, Lars Gullik Bjønnes wrote:
> > | I have the feeling that pruning repeat key events is not wrong in
> > | principle, but at best not needed. Without it, you know precisely
> > | (under my scheme) that keepi
gt; | considered opinion is a bit different...
> >>
> >> What you write belowe seems very sane. But I think that my keyevent
> >> queue is still needed? (but to fix a different problem)
> >
> | Which problem?
> >
> | I have the feeling that pruning repeat key
On Mon, May 30, 2005 at 09:56:06AM +0200, Lars Gullik Bjønnes wrote:
> | I have the feeling that pruning repeat key events is not wrong in
> | principle, but at best not needed. Without it, you know precisely
> | (under my scheme) that keeping the PgDown key down for 0.5 secs will get
> | you 10 sc
Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Sun, May 29, 2005 at 09:58:22PM +0300, Martin Vermeer wrote:
>> On Sat, May 28, 2005 at 12:12:07AM +0200, Lars Gullik Bjønnes wrote:
|
>> > | +inline flags operator|(flags const f, flags const g)
>> > | +{
>> > | +int const intf(static_ca
e seems very sane. But I think that my keyevent
>> queue is still needed? (but to fix a different problem)
>
| Which problem?
>
| I have the feeling that pruning repeat key events is not wrong in
| principle, but at best not needed. Without it, you know precisely
| (under my scheme) tha
On Sun, May 29, 2005 at 09:58:22PM +0300, Martin Vermeer wrote:
> On Sat, May 28, 2005 at 12:12:07AM +0200, Lars Gullik Bjønnes wrote:
> > | +inline flags operator|(flags const f, flags const g)
> > | +{
> > | + int const intf(static_cast(f));
> > | + int const intg(static_cast(g));
> > | + ret
On Sat, May 28, 2005 at 12:12:07AM +0200, Lars Gullik Bjønnes wrote:
> | Actually I have now had time to think about this for two weeks, and my
> | considered opinion is a bit different...
>
> What you write belowe seems very sane. But I think that my keyevent
> queue is still need
| Actually I have now had time to think about this for two weeks, and my
| considered opinion is a bit different...
What you write belowe seems very sane. But I think that my keyevent
queue is still needed? (but to fix a different problem)
| +inline flags operator|(flags const f, flags const g
On Fri, May 27, 2005 at 04:28:32PM -0400, Bennett Helm wrote:
> On May 27, 2005, at 2:59 PM, Martin Vermeer wrote:
>
> >Actually I have now had time to think about this for two weeks, and my
> >considered opinion is a bit different...
>
> This patch fixes problems on the Mac with dropping charact
On May 27, 2005, at 2:59 PM, Martin Vermeer wrote:
Actually I have now had time to think about this for two weeks, and my
considered opinion is a bit different...
This patch fixes problems on the Mac with dropping characters and with
reordering characters. Also, scrolling feels much better.
On Thu, May 19, 2005 at 09:46:27AM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Thu, May 12, 2005 at 06:47:50PM +0200, Lars Gullik Bjønnes wrote:
> >> this is kindo a proof-of-concept.
> >
> | Is there a specific reason
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, May 12, 2005 at 06:47:50PM +0200, Lars Gullik Bjønnes wrote:
>> this is kindo a proof-of-concept.
>
| Is there a specific reason this queue is in the frontend and not in the
| core?
>
| If it were in the core we could have an &
On Mon, May 16, 2005 at 11:36:42AM -0400, Bennett Helm wrote:
> 1.0%62.8% LyX lengthcombo.C:72
> 0.7%60.2% LyX lengthcombo.C:72
> 57.6% 59.1% LyX lengthcombo.C:72
> 0.7%0.7%LyX NO_SRC_FILE:?
> 0.6%0
On May 13, 2005, at 3:54 PM, Martin Vermeer wrote:
On Fri, May 13, 2005 at 03:23:16PM -0400, Bennett Helm wrote:
On May 13, 2005, at 10:56 AM, Martin Vermeer wrote:
(I tried doing a "Function Trace" within Shark, specifying
QFontEngineMac::doTextTask as the function to trace, but I get the
followin
On May 13, 2005, at 4:38 PM, Andre Poenitz wrote:
On Fri, May 13, 2005 at 10:39:16AM -0400, Bennett Helm wrote:
Setting granularity to be "Source Line" gives the following:
59.4% 61.3% LyX lengthcombo.C:63
0.8%0.8%LyX NO_SRC_FILE:?
0.7%0.8%
On Sun, May 15, 2005 at 07:11:02PM +0200, Helge Hafting wrote:
> On Sun, May 15, 2005 at 05:09:39PM +0300, Martin Vermeer wrote:
> > Lars,
> >
> > Now that I have had some time to think it over, I am more and more
> > inclined to suspect that there is something to my dark fear.
> >
> > As I under
On Sun, May 15, 2005 at 05:09:39PM +0300, Martin Vermeer wrote:
> qt-mt, doesn't that mean Qt multi-threading? Or am I holding the wrong
> end of the stick?
I think that's the thread-safe version of the library. It does not use
multiple threads by itself.
Andre'
On Sun, May 15, 2005 at 05:09:39PM +0300, Martin Vermeer wrote:
> Lars,
>
> Now that I have had some time to think it over, I am more and more
> inclined to suspect that there is something to my dark fear.
>
> As I understand it, LyX, Qt and X all process events in a "linear"
> fashion. This mean
rocessEvents-handled keystroke may slip in, and land on the wrong
> | place. Having this happen only very rarely (but sometimes) is in a way
> | even worse, more treacherous than having it all the time up-front.
>
> ???
>
> Those events received while the timer goes (tick) is pu
Andre Poenitz wrote:
> Could you just comment out the whole body of LengthCombo::noPercents()
> in src/frontend/qt2/lengthcombo.C (this is lines 62-69 or so)
> and try again?
It would certainly be a big surprise if that function would be called while
typing.
Jürgen
On Fri, May 13, 2005 at 10:39:16AM -0400, Bennett Helm wrote:
> Setting granularity to be "Source Line" gives the following:
>
> 59.4% 61.3% LyX lengthcombo.C:63
> 0.8%0.8%LyX NO_SRC_FILE:?
> 0.7%0.8%LyX lengthcombo.C:63
>
On Thu, May 12, 2005 at 06:47:50PM +0200, Lars Gullik Bjønnes wrote:
> this is kindo a proof-of-concept.
Is there a specific reason this queue is in the frontend and not in the
core?
If it were in the core we could have an 'update' lfuns, and a 'dont need
up-to-date cache
On Fri, May 13, 2005 at 03:23:16PM -0400, Bennett Helm wrote:
> On May 13, 2005, at 10:56 AM, Martin Vermeer wrote:
>
> >>(I tried doing a "Function Trace" within Shark, specifying
> >>QFontEngineMac::doTextTask as the function to trace, but I get the
> >>following error message: "Failed to subver
On May 13, 2005, at 10:56 AM, Martin Vermeer wrote:
(I tried doing a "Function Trace" within Shark, specifying
QFontEngineMac::doTextTask as the function to trace, but I get the
following error message: "Failed to subvert traced functions. Verify
that all of the symbols to trace exist in the target
ore treacherous than having it all the time up-front.
???
Those events received while the timer goes (tick) is put on the queue.
--
Lgb
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Bennett Helm <[EMAIL PROTECTED]> writes:
>
| | On May 12, 2005, at 8:07 PM, Lars Gullik Bjønnes wrote:
>>
>>> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
>>>
>>> | | this is kindo a proof-of-concept.
>>> | This is a revised version of the
On Fri, May 13, 2005 at 05:37:18PM +0200, Lars Gullik Bjønnes wrote:
...
> Note that we now send keyevents to the core every 25ms (+ the time it
> takes to handle them) 25ms should not be noticable when typing unless
> (as the case is on your box) the time to handle the event is really
> long...
Bennett Helm <[EMAIL PROTECTED]> writes:
| On May 12, 2005, at 8:07 PM, Lars Gullik Bjønnes wrote:
>
>> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
>>
>> | | this is kindo a proof-of-concept.
>>>
>> | This is a revised version of the patch. This time is also prunes key
>> | events that is caus
On Friday 13 May 2005 13:41, Jean-Marc Lasgouttes wrote:
> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
> Lars> Hmm... what part of "song" did you not understand?
>
> I do not think the event is broadcasted on the radio, but I may be
> mistaken.
That only proves you didn't r
On Fri, May 13, 2005 at 10:39:16AM -0400, Bennett Helm wrote:
> Jean-Marc -
>
> I'm not sure what I'm doing here, but here goes anyway.
...
> >I think that there is a way with Shark.app to have a profile of the
> >code in a function. Could you try that with
> >QFontEngineMac::doTextTask? I am c
Jean-Marc -
I'm not sure what I'm doing here, but here goes anyway.
On May 13, 2005, at 9:43 AM, Jean-Marc Lasgouttes wrote:
Your latest profile showed that a _lot_ of time is spent in
QFontEngineMac::doTextTask, with mostly none of that dispatched to the
lower-level functions. Can you confirm that
> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
Bennett> With this new version of the patch, I cannot duplicate either
Bennett> the re-ordering problem or the problem of dropping
Bennett> characters. However, typing feels a bit slower than before,
Bennett> with characters appearing on
On May 12, 2005, at 8:07 PM, Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| | this is kindo a proof-of-concept.
| This is a revised version of the patch. This time is also prunes key
| events that is caused by auto-repeat. (Gives imho very nice
behavior.)
And I clea
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Hmm... what part of "song" did you not understand?
I do not think the event is broadcasted on the radio, but I may be
mistaken.
And seriously, most of the interest of the show is visual...
JMarc
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Jose'" == Jose' Matos <[EMAIL PROTECTED]> writes:
>
| Jose'> The paper shows the UK is in tune with the remaining Europe
| Jose'> when voting, while perhaps surprisingly France is out of tune.
| Jose'> Thus we conclude that Jean-Marc does
> "Jose'" == Jose' Matos <[EMAIL PROTECTED]> writes:
Jose'> The paper shows the UK is in tune with the remaining Europe
Jose'> when voting, while perhaps surprisingly France is out of tune.
Jose'> Thus we conclude that Jean-Marc does not care about it. (Now
Jose'> this is far fetched...)
We
On Friday 13 May 2005 00:16, Lars Gullik Bjønnes wrote:
>
> >> | Do you want more comments or are you feeling fragile?
> >>
> >> Keep it comming.
> >> (Rock on, baby!)
> |
> | I bet you're excited by the up-coming Eurovision song contest :)
>
> Hey, do you follow that?
Sure they do, as a proof o
On Fri, May 13, 2005 at 02:07:53AM +0200, Lars Gullik Bjønnes wrote:
> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
>
> | | this is kindo a proof-of-concept.
> >
> | This is a revised version of the patch. This time is also prunes key
> | events that is caused by auto-repeat. (Gives imho very n
Lars Gullik Bjønnes wrote:
> | Creation sounds a bit biblical. "For recruits" is what I was
> | suggesting.
>
> I thought you wanted be to pound the dateing scene harder (there got to
> be a pun in there...)
Never pound too hard on an all male m/l...
> I was never much of a bug fixer... (unless
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> Angus Leeming <[EMAIL PROTECTED]> writes:
>>
>> | Can you advertise?
>>
>> For creation of recruits?
>
| Creation sounds a bit biblical. "For recruits" is what I was suggesting.
I thought you wanted be to pound the date
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Can you advertise?
>
> For creation of recruits?
Creation sounds a bit biblical. "For recruits" is what I was suggesting.
> (I have a lot of code buried away... just waiting for 1.5.x to pop
> up...)
Thank goodness M
timeout.
void generateSyntheticMouseEvent();
@@ -114,6 +119,9 @@ private:
bool track_scrollbar_;
/// owning widget
QWorkArea * wa_;
+
+ QTimer step_timer_;
+ std::queue > keyeventQueue_;
/// the double buffered pixmap
boost::scoped_p
Angus Leeming <[EMAIL PROTECTED]> writes:
| Can you advertise?
For creation of recruits?
(I have a lot of code buried away... just waiting for 1.5.x to pop
up...)
--
Lgb
Lars Gullik Bjønnes wrote:
>>> That was awfully nice of you.
>>
> | I'm a nice guy.
>
> Prove it. Come to Paris and let me re-verify again.
I'm working on it. Life's a bit messy ATM, but a Eurostar to Paris for the
w/e is something I'm striving for.
> I might be a new recruit, but I know how to
Angus Leeming <[EMAIL PROTECTED]> writes:
>>
>> That was awfully nice of you.
>
| I'm a nice guy.
Prove it. Come to Paris and let me re-verify again.
| FC4 test 3.
Actually it was FC3...
>> with what is supplied there, there are no such problems.
>
| Well, you seem quite happy to use 'new',
.3 it is not possible to default
> construct QKeyEvents... this means that they are impossible to store
> in a std::queue... bummer... on Fc4,
FC4 test 3.
> with what is supplied there, there are no such problems.
Well, you seem quite happy to use 'new', so wrap 'em in a shared_ptr.
--
Angus
ble to store
in a std::queue... bummer... on Fc4, with what is supplied there,
there are no such problems.
--
Lgb
Lars Gullik Bjønnes wrote:
> | Do I have to add a smiley?
>
> Smilies are for sissies.
Good.
>>> | Do you want more comments or are you feeling fragile?
>>>
>>> Keep it comming.
>>> (Rock on, baby!)
>>
> | I bet you're excited by the up-coming Eurovision song contest :)
>
> Hey, do you follow
Angus Leeming <[EMAIL PROTECTED]> writes:
>> | sync_non_user_events() doesn't appear to be used.
>>
>> only becuase you didn't get a diff of all my modifications...
>> I make the sync_non_user_events for testing... I added it to the token
>> loop when reading lyx files...
>
| Then don't ask me to
Lars Gullik Bjønnes wrote:
> I think
>
> qApp->processEvents(5);
>
> is just the same thing. Does that exist for earlier qt versions?
doc.troll.no ?
Certainly, QEventLoop does not exist for Qt < 3.1
> | sync_non_user_events() doesn't appear to be used.
>
> only becuase you didn't get a diff o
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> | Lars Gullik Bjønnes wrote:
Comments bitte please por favor.
>>>
>> | It's a very small patch...
>>
>> That is the nice thing about it...
>
| Why isn't step_timer a QContentPane member?
artifact of proof-of-concept
I
Lars Gullik Bjønnes wrote:
> | Lars Gullik Bjønnes wrote:
>>> Comments bitte please por favor.
>>
> | It's a very small patch...
>
> That is the nice thing about it...
Why isn't step_timer a QContentPane member? More than one LyX window? Why
create step_timer on the heap and not on the stack?
Pu
What happens above and beyond keystrokes being collected and
| dispatched in neat little packets of 50 msec?
??
They are just kept in a queue...
In my updated patch queued up auto-repeat keyevents are pruned.
| - Why does the call to processEvents now only rarely find any unprocessed
| keyboard event
rn the LyX key state from Qt's
@@ -73,6 +75,9 @@ mouse_button::state q_motion_state(Qt::B
return b;
}
+QTimer * step_timer;
+std::queue keyeventQueue;
+
} // namespace anon
@@ -90,6 +95,11 @@ QContentPane::QContentPane(QWorkArea * p
boost::bind(&QContentPane::generateSynt
Lars Gullik Bjønnes wrote:
> Comments bitte please por favor.
It's a very small patch...
--
Angus
On Thu, May 12, 2005 at 06:47:50PM +0200, Lars Gullik Bjønnes wrote:
> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
>
> | | Then we just need a timer that kicks in some 10-20 times a second to
> | | check the queue and do the real work.
> >
> | and with the queue doing t
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
>
| | | Then we just need a timer that kicks in some 10-20 times a second to
| | | check the queue and do the real work.
>>
| | and with the queue doing the right thing we can act
one by this queue. Otherwise leave processEvents
| out altogether.
To my knowledge
qapp->processEvents() == qapp->eventLoop()->processEvents(AllEvents, 3000)
So I don't really see how that will make a difference.
--
Lgb
Bennett Helm <[EMAIL PROTECTED]> writes:
| On May 12, 2005, at 12:56 PM, Lars Gullik Bjønnes wrote:
>
>> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
>>
>> | Would be nice if people could try this a bit and see if the problems
>> | seen earlier can be reproduced with this patch applied.
>>>
>>
t tim I tested ly.xe". That's an improvement.
Ah... proof of principle.
I think the reordering problem would go when using the eventLoop version
of processEvents, when available. I.e. _without_ the ExcludeUserInput
arg, the intended behaviour of which (storing up keystrokes rather than
drop
I am not sure that I saw this earlier, but I don't see it with this
patch. If there is a timestamp on the events we could use that and put
the events in a priority queue...
--
Lgb
On May 12, 2005, at 12:56 PM, Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Would be nice if people could try this a bit and see if the problems
| seen earlier can be reproduced with this patch applied.
| - most likely a check for update in progress is needed in the
On Thu, 2005-05-12 at 19:56, Lars Gullik BjÃnnes wrote:
> [EMAIL PROTECTED] (Lars Gullik BjÃnnes) writes:
>
> | Would be nice if people could try this a bit and see if the problems
> | seen earlier can be reproduced with this patch applied.
> >
> | - most likely a check for update in progress is n
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Would be nice if people could try this a bit and see if the problems
| seen earlier can be reproduced with this patch applied.
>
| - most likely a check for update in progress is needed in the
| keyeventTimeout
| - event coalescing would be nice.
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| | Then we just need a timer that kicks in some 10-20 times a second to
| | check the queue and do the real work.
>
| and with the queue doing the right thing we can actually put
| processEvents allover as much as we want to to make the interact
On Sat, 22 Feb 2003, Alfredo Braunstein wrote:
> Allan Rae wrote:
>
> > A 20 second scan of the code in LoadQueue.C suggests that push_front()
> > and pop_front() is the reason your queue is acting like a stack.
> >
> > Try pushing on one end and popping off the othe
1 - 100 of 118 matches
Mail list logo
