Andre Poenitz wrote:
Couldn't we split off the 'secondary' update goals (like scrollbar and
paragraph style box update) from 'core update' (i.e. metrics + drawing)?
This way no other widget than the main text widget will be touched
during the critical phase and no 'spontaneous' Qt events will be
On Tue, 2005-05-10 at 09:43, Asger Ottar Alstrup wrote:
This would mean having our own event queue on top of Qt's... And I
thought toolkits were made to relieve developers from re-inventing the
wheel all the time. This somehow doesn't feel Right.
Martin already implemented it. It wasn't
Martin Vermeer [EMAIL PROTECTED] writes:
I think this looks good, if you can get somebody else to test it to
verify your claims :-) then it should be committed.
But please just get rid of the commented processEventes.
--
Lgb
Great! I was frankly a bit surprised that Qt would fire events without any
reason. Good to learn that it doesn't.
FYI, the native Windows API does not do this either, except if you try to
use multimedia. When you start a movieclip, windows will process messages.
Urgh! When you go look in the
On Tue, 2005-05-10 at 10:57, Asger Alstrup wrote:
Great! I was frankly a bit surprised that Qt would fire events without any
reason. Good to learn that it doesn't.
FYI, the native Windows API does not do this either, except if you try to
use multimedia. When you start a movieclip, windows
On Tue, May 10, 2005 at 10:03:30AM +0300, Martin Vermeer wrote:
I tested the situations where the processEvents() call had been added,
to see if the reasons for doing so were still valid: I found none. The
symbol panel scrollbar in the math dialog; at least the tabular dialog
refresh; and
Martin Vermeer wrote:
As you have seen by now, Martin demonstrated that this will not work.
Actually no, that claim is too strong. But Alfredo found that this would
work, but I don't know how thoroughly he tested.
It was me, but I must confess that my testing could have been more
intensive.
Andre Poenitz wrote:
Couldn't we split off the 'secondary' update goals (like scrollbar and
paragraph style box update) from 'core update' (i.e. metrics + drawing)?
This way no other widget than the main text widget will be touched
during the critical phase and no 'spontaneous' Qt events will be
On Tue, 2005-05-10 at 09:43, Asger Ottar Alstrup wrote:
> > This would mean having our own event queue on top of Qt's... And I
> > thought toolkits were made to relieve developers from re-inventing the
> > wheel all the time. This somehow doesn't feel Right.
>
> Martin already implemented it.
Martin Vermeer <[EMAIL PROTECTED]> writes:
I think this looks good, if you can get somebody else to test it to
verify your claims :-) then it should be committed.
But please just get rid of the commented "processEvente"s.
--
Lgb
Great! I was frankly a bit surprised that Qt would fire events without any
reason. Good to learn that it doesn't.
FYI, the native Windows API does not do this either, except if you try to
use multimedia. When you start a movieclip, windows will process messages.
Urgh! When you go look in the
On Tue, 2005-05-10 at 10:57, Asger Alstrup wrote:
> Great! I was frankly a bit surprised that Qt would fire events without any
> reason. Good to learn that it doesn't.
>
> FYI, the native Windows API does not do this either, except if you try to
> use multimedia. When you start a movieclip,
On Tue, May 10, 2005 at 10:03:30AM +0300, Martin Vermeer wrote:
> I tested the situations where the processEvents() call had been added,
> to see if the reasons for doing so were still valid: I found none. The
> symbol panel scrollbar in the math dialog; at least the tabular dialog
> refresh; and
Martin Vermeer wrote:
>> As you have seen by now, Martin demonstrated that this will not work.
>
> Actually no, that claim is too strong. But Alfredo found that this would
> work, but I don't know how thoroughly he tested.
It was me, but I must confess that my testing could have been more
On Mon, May 09, 2005 at 09:32:43AM +0300, Martin Vermeer wrote:
On Sun, May 08, 2005 at 08:41:26PM +0100, John Levon wrote:
On Sun, May 08, 2005 at 10:37:33PM +0300, Martin Vermeer wrote:
But... isn't this cursor drawing and hiding an asynchronous process
taking place every 400 msec?
Martin Vermeer wrote:
1) keystrokes
2) mouse movements/clicks
3) things coming from the dialogs through kernel dispatch.
4) (The minibuffer?)
The basic question is this: The common thing for all of these is that they
are consequences of a processEvent call, right?
So, if we can just delay
On Mon, May 09, 2005 at 04:49:05PM +0200, Asger Alstrup wrote:
Martin Vermeer wrote:
1) keystrokes
2) mouse movements/clicks
3) things coming from the dialogs through kernel dispatch.
4) (The minibuffer?)
The basic question is this: The common thing for all of these is that they
are
Martin Vermeer wrote:
No, I actually don't think so.
Do they have _anything_ in common? All I can think of is
1) they are all handled asynchronously, through
signals/slots, and
2) they are represented by LFUNs.
But I don't see how that gives a single point of control. Or does it?
How?
What I
On Mon, May 09, 2005 at 05:27:47PM +0200, Asger Alstrup wrote:
What I fail to understand is how such thinks can be invoked during an
update.
Right, that's what I'm missing from Martin's explanation too. We can
only get such problems if we enter the event loop during an update.
john
Martin Vermeer wrote:
On Mon, May 09, 2005 at 04:49:05PM +0200, Asger Alstrup wrote:
Martin Vermeer wrote:
1) keystrokes
2) mouse movements/clicks
3) things coming from the dialogs through kernel dispatch.
4) (The minibuffer?)
The basic question is this: The common thing for all of
On Mon, May 09, 2005 at 04:53:15PM +0100, John Levon wrote:
On Mon, May 09, 2005 at 05:27:47PM +0200, Asger Alstrup wrote:
What I fail to understand is how such thinks can be invoked during an
update.
Right, that's what I'm missing from Martin's explanation too. We can
only get such
On Mon, May 09, 2005 at 07:40:13PM +0300, Martin Vermeer wrote:
#4 0x080a48f2 in boost::assertion_failed (expr=0x83a8359 updating,
function=0x83c8f00 CoordCacheBaseInsetBase CoordCache::insets(),
file=0x83bcf51 ../../src/coordcache.h, line=131) at boost.C:56
#5 0x081d072a in
On Mon, May 09, 2005 at 05:43:22PM +0100, John Levon wrote:
On Mon, May 09, 2005 at 07:40:13PM +0300, Martin Vermeer wrote:
#4 0x080a48f2 in boost::assertion_failed (expr=0x83a8359 updating,
function=0x83c8f00 CoordCacheBaseInsetBase CoordCache::insets(),
file=0x83bcf51
On Mon, May 09, 2005 at 07:50:56PM +0300, Martin Vermeer wrote:
#35 0x027b2f94 in QWidget::setUpdatesEnabled ()
And thus, we have our black beast.
My guess is the environment drop down update.
john
On Mon, May 09, 2005 at 06:41:16PM +0100, John Levon wrote:
On Mon, May 09, 2005 at 07:50:56PM +0300, Martin Vermeer wrote:
#35 0x027b2f94 in QWidget::setUpdatesEnabled ()
And thus, we have our black beast.
My guess is the environment drop down update.
Meaning, in teletubby english?
-
On Mon, May 09, 2005 at 08:42:57PM +0300, Martin Vermeer wrote:
#35 0x027b2f94 in QWidget::setUpdatesEnabled ()
And thus, we have our black beast.
My guess is the environment drop down update.
Meaning, in teletubby english?
We can't update any widgets at all during update(). All
On Mon, May 09, 2005 at 06:47:22PM +0100, John Levon wrote:
On Mon, May 09, 2005 at 08:42:57PM +0300, Martin Vermeer wrote:
#35 0x027b2f94 in QWidget::setUpdatesEnabled ()
And thus, we have our black beast.
My guess is the environment drop down update.
Meaning, in
On Mon, May 09, 2005 at 09:13:03PM +0300, Martin Vermeer wrote:
We can't update any widgets at all during update(). All the changing of
the environment drop down (say, to 'Section' when moving the cursor) has
to be done after the fact.
Not in my test case. All cells of the table are
On Mon, May 09, 2005 at 07:31:51PM +0100, John Levon wrote:
On Mon, May 09, 2005 at 09:13:03PM +0300, Martin Vermeer wrote:
We can't update ... at all, is that an imperative? I.e., should we
disable interrupts as one would have on a microprocessor two decades
ago? And if so, how (in
Martin Vermeer wrote:
Qt is processing the event queue when we change a widget, it appears.
OK, if Qt is acting like that, we have to face up to it. Even if we
could find some way to stop it from doing that, it would probably be
fragile. It is better to admit the fact, and respond appropriately.
On Mon, May 09, 2005 at 05:06:59PM +0300, Martin Vermeer wrote:
For things coming from the dialogs, I haven't come to a conclusion yet.
I can certainly shortcircuit multiple redraw in BufferView_pimpl's
update, which would be a brute-force catch-all. The LFUNs would still be
all processed in
On Mon, May 09, 2005 at 06:11:20PM +0300, Martin Vermeer wrote:
The basic question is this: The common thing for all of these is that they
are consequences of a processEvent call, right?
No, I actually don't think so.
Do they have _anything_ in common? All I can think of is
1) they
Andre Poenitz wrote:
I maintain that the only reliable solution is not to nest update and do
at least a metrics + null-painter phase after each user interaction
(unless some cur.noUpdate() explicitly declared the situation as 'safe
to omit redraw').
So we all agree that nested updates are evil.
On Mon, May 09, 2005 at 09:23:05PM +0200, Asger Ottar Alstrup wrote:
John Levon wrote:
Qt is processing the event queue when we change a widget, it appears.
OK, if Qt is acting like that, we have to face up to it. Even if we
could find some way to stop it from doing that, it would probably
On Mon, May 09, 2005 at 09:55:50PM +0200, Asger Ottar Alstrup wrote:
Andre Poenitz wrote:
...
Please try omitting processEvent() calls and fixing resulting UI
glitches withour resorting to processEvents().
As you have seen by now, Martin demonstrated that this will not work.
Actually
Martin Vermeer wrote:
I haven't demonstrated anything. I provided John with a backtrace, from
which he claimed to see this, without actually presenting the argument.
I want to hear it. If valid, we can only have a good heuristic solution,
if not, Andre is right and we can have a provably
Martin Vermeer wrote:
As you have seen by now, Martin demonstrated that this will not work.
Actually no, that claim is too strong. But Alfredo found that this would
work, but I don't know how thoroughly he tested.
Uhh... Did I?
Alfredo (freaking out)
On Mon, May 09, 2005 at 09:55:50PM +0200, Asger Ottar Alstrup wrote:
So we all agree that nested updates are evil. However, Martins work has
demonstrated that Qt will signal events when we just update widgets on
the screen.
Couldn't we split off the 'secondary' update goals (like scrollbar
On Mon, May 09, 2005 at 09:32:43AM +0300, Martin Vermeer wrote:
> On Sun, May 08, 2005 at 08:41:26PM +0100, John Levon wrote:
> > On Sun, May 08, 2005 at 10:37:33PM +0300, Martin Vermeer wrote:
> >
> > > But... isn't this cursor drawing and hiding an asynchronous process
> > > taking place every
Martin Vermeer wrote:
> 1) keystrokes
> 2) mouse movements/clicks
> 3) things coming from the dialogs through kernel dispatch.
> 4) (The minibuffer?)
The basic question is this: The common thing for all of these is that they
are consequences of a processEvent call, right?
So, if we can just
On Mon, May 09, 2005 at 04:49:05PM +0200, Asger Alstrup wrote:
> Martin Vermeer wrote:
> > 1) keystrokes
> > 2) mouse movements/clicks
> > 3) things coming from the dialogs through kernel dispatch.
> > 4) (The minibuffer?)
>
> The basic question is this: The common thing for all of these is that
Martin Vermeer wrote:
No, I actually don't think so.
Do they have _anything_ in common? All I can think of is
1) they are all handled asynchronously, through
signals/slots, and
2) they are represented by LFUNs.
But I don't see how that gives a single point of control. Or does it?
How?
What I
On Mon, May 09, 2005 at 05:27:47PM +0200, Asger Alstrup wrote:
> What I fail to understand is how such thinks can be invoked during an
> update.
Right, that's what I'm missing from Martin's explanation too. We can
only get such problems if we enter the event loop during an update.
john
Martin Vermeer wrote:
> On Mon, May 09, 2005 at 04:49:05PM +0200, Asger Alstrup wrote:
>> Martin Vermeer wrote:
>> > 1) keystrokes
>> > 2) mouse movements/clicks
>> > 3) things coming from the dialogs through kernel dispatch.
>> > 4) (The minibuffer?)
>>
>> The basic question is this: The common
On Mon, May 09, 2005 at 04:53:15PM +0100, John Levon wrote:
> On Mon, May 09, 2005 at 05:27:47PM +0200, Asger Alstrup wrote:
>
> > What I fail to understand is how such thinks can be invoked during an
> > update.
>
> Right, that's what I'm missing from Martin's explanation too. We can
> only
On Mon, May 09, 2005 at 07:40:13PM +0300, Martin Vermeer wrote:
> #4 0x080a48f2 in boost::assertion_failed (expr=0x83a8359 "updating",
> function=0x83c8f00 "CoordCacheBase& CoordCache::insets()",
> file=0x83bcf51 "../../src/coordcache.h", line=131) at boost.C:56
> #5 0x081d072a in
On Mon, May 09, 2005 at 05:43:22PM +0100, John Levon wrote:
> On Mon, May 09, 2005 at 07:40:13PM +0300, Martin Vermeer wrote:
>
> > #4 0x080a48f2 in boost::assertion_failed (expr=0x83a8359 "updating",
> > function=0x83c8f00 "CoordCacheBase& CoordCache::insets()",
> > file=0x83bcf51
On Mon, May 09, 2005 at 07:50:56PM +0300, Martin Vermeer wrote:
> #35 0x027b2f94 in QWidget::setUpdatesEnabled ()
And thus, we have our black beast.
My guess is the environment drop down update.
john
On Mon, May 09, 2005 at 06:41:16PM +0100, John Levon wrote:
> On Mon, May 09, 2005 at 07:50:56PM +0300, Martin Vermeer wrote:
>
> > #35 0x027b2f94 in QWidget::setUpdatesEnabled ()
>
> And thus, we have our black beast.
>
> My guess is the environment drop down update.
Meaning, in teletubby
On Mon, May 09, 2005 at 08:42:57PM +0300, Martin Vermeer wrote:
> > > #35 0x027b2f94 in QWidget::setUpdatesEnabled ()
> >
> > And thus, we have our black beast.
> >
> > My guess is the environment drop down update.
>
> Meaning, in teletubby english?
We can't update any widgets at all during
On Mon, May 09, 2005 at 06:47:22PM +0100, John Levon wrote:
> On Mon, May 09, 2005 at 08:42:57PM +0300, Martin Vermeer wrote:
>
> > > > #35 0x027b2f94 in QWidget::setUpdatesEnabled ()
> > >
> > > And thus, we have our black beast.
> > >
> > > My guess is the environment drop down update.
> >
>
On Mon, May 09, 2005 at 09:13:03PM +0300, Martin Vermeer wrote:
> > We can't update any widgets at all during update(). All the changing of
> > the environment drop down (say, to 'Section' when moving the cursor) has
> > to be done after the fact.
>
> Not in my test case. All cells of the table
On Mon, May 09, 2005 at 07:31:51PM +0100, John Levon wrote:
> On Mon, May 09, 2005 at 09:13:03PM +0300, Martin Vermeer wrote:
> > "We can't update ... at all", is that an imperative? I.e., should we
> > "disable interrupts" as one would have on a microprocessor two decades
> > ago? And if so,
Martin Vermeer wrote:
Qt is processing the event queue when we change a widget, it appears.
OK, if Qt is acting like that, we have to face up to it. Even if we
could find some way to stop it from doing that, it would probably be
fragile. It is better to admit the fact, and respond appropriately.
On Mon, May 09, 2005 at 05:06:59PM +0300, Martin Vermeer wrote:
> For things coming from the dialogs, I haven't come to a conclusion yet.
> I can certainly shortcircuit multiple redraw in BufferView_pimpl's
> update, which would be a brute-force catch-all. The LFUNs would still be
> all processed
On Mon, May 09, 2005 at 06:11:20PM +0300, Martin Vermeer wrote:
> > The basic question is this: The common thing for all of these is that they
> > are consequences of a processEvent call, right?
>
> No, I actually don't think so.
>
> Do they have _anything_ in common? All I can think of is
>
Andre Poenitz wrote:
I maintain that the only reliable solution is not to nest update and do
at least a metrics + null-painter phase after each user interaction
(unless some cur.noUpdate() explicitly declared the situation as 'safe
to omit redraw').
So we all agree that nested updates are evil.
On Mon, May 09, 2005 at 09:23:05PM +0200, Asger Ottar Alstrup wrote:
> John Levon wrote:
> >>Qt is processing the event queue when we change a widget, it appears.
> OK, if Qt is acting like that, we have to face up to it. Even if we
> could find some way to stop it from doing that, it would
On Mon, May 09, 2005 at 09:55:50PM +0200, Asger Ottar Alstrup wrote:
> Andre Poenitz wrote:
...
> >Please try omitting processEvent() calls and fixing resulting UI
> >glitches withour resorting to processEvents().
>
> As you have seen by now, Martin demonstrated that this will not work.
Martin Vermeer wrote:
> I haven't demonstrated anything. I provided John with a backtrace, from
> which he claimed to see this, without actually presenting the argument.
> I want to hear it. If valid, we can only have a good heuristic solution,
> if not, Andre is right and we can have a provably
Martin Vermeer wrote:
>> As you have seen by now, Martin demonstrated that this will not work.
>
> Actually no, that claim is too strong. But Alfredo found that this would
> work, but I don't know how thoroughly he tested.
Uhh... Did I?
Alfredo (freaking out)
On Mon, May 09, 2005 at 09:55:50PM +0200, Asger Ottar Alstrup wrote:
> So we all agree that nested updates are evil. However, Martins work has
> demonstrated that Qt will signal events when we just update widgets on
> the screen.
Couldn't we split off the 'secondary' update goals (like
62 matches
Mail list logo
