> > Search on "window.setTimeout" and you will find 7 hits in 0.6.5.
> > (Why aren't these qx.client.Timer.once?)
>
> Because of unnecessary overhead? (I don't know, just guessing.) For
> timeout functions that don't need access to an instance via "this",
> wrapping the timeout inside a qooxdo
Andreas Junghans <[EMAIL PROTECTED]> writes:
>> Mhh, yes. We think the same. Normally if the system gets more mature
>> we try to do it. Currently, where all is in flux, and even the new
>> Makefile system is developed I don't think there is a realistic
>> reason to add backward-compatible code. I
> However this is not related to the queue, but to the state handling
> and a missing event. Even if your work-around works in this case, the
> only way where thiscould be solved - in a good way - is the event
> handler. IMHO we need some special blur (window) handling for the
> active wind
> > Search on "window.setTimeout" and you will find 7 hits in 0.6.5.
> > (Why aren't these qx.client.Timer.once?)
>
> Maybe because it is not so well known.
I should think so. They are used in Table, and need access to "this" (via a
closure with "self") as Derrell found out.
> > There are 3 use
Hi Sebastian,
Am 17.02.2007 um 14:50 schrieb Sebastian Werner:
>> There are currently around 30 calls to flushGlobalQueues() scattered
>> around the framework. With the auto-flush in place, I'd like to
>> remove many of them (after careful testing of course), but only after
>> 0.7 is released. I'
Am 17.02.2007 um 14:46 schrieb Andreas Junghans:
> Hi there,
>
> the auto-flush mechanism is now commited to the trunk. In my tests,
> it behaved as expected, and I didn't notice any negative effects. If
> there are any problems with it, please let me know.
Fine. We will do :)
>
> There are curr
Hi there,
the auto-flush mechanism is now commited to the trunk. In my tests,
it behaved as expected, and I didn't notice any negative effects. If
there are any problems with it, please let me know.
There are currently around 30 calls to flushGlobalQueues() scattered
around the framework. W
Hi Sebastian,
Am 17.02.2007 um 12:39 schrieb Sebastian Werner:
1.) In all the Makefiles provided with qooxdoo, set
APPLICATION_LINEBREAKS_BUILD to true. IMHO, the size savings simply
don't justify the loss of stack traces. Developers will copy these
Makefiles and will curse at
Hello,
I'm working on a rich text editor widget, working fine using
qx.ui.embed.Iframe and inspirated from www.rtef.info . I have planned to
release this widget in opensource, soon.
For the moment, I encountered troubles with Safari and the use of
qx.ui.embed.Iframe in qx.ui.pageview.tabview.TabVi
Am 17.02.2007 um 12:14 schrieb Andreas Junghans:
> Hi Sebastian,
>
> Am 17.02.2007 um 10:41 schrieb Sebastian Werner:
>
>> Am 17.02.2007 um 01:48 schrieb Andreas Junghans:
>>
>>> While we're at it, I have some more suggestions for the build
>>> process
>>> (at the risk of running into the "I do
Hi Sebastian,
Am 17.02.2007 um 12:01 schrieb Sebastian Werner:
> We have some time until 0.7 gets released. Maybe you want to
> incorporate your changes ASAP - before we apply the 0.7 convertion on
> Tuesday.
Will do.
> The one thing which remains and I don't like is that the
> start handling u
Hi Sebastian,
Am 17.02.2007 um 10:41 schrieb Sebastian Werner:
> Am 17.02.2007 um 01:48 schrieb Andreas Junghans:
>
>> While we're at it, I have some more suggestions for the build process
>> (at the risk of running into the "I don't like it" wall ;-)):
>
> There is no wall. This is not very prod
OK, ok. Maybe you are right. I don't know. In my opinion timers
always slow down stuff. It seems that the others think that this
change would be an improvement, too. As the time we have developed
the engine, which is more than one year ago, we made the decision to
not use timers/intervals t
Hi,
Am 17.02.2007 um 10:15 schrieb Sebastian Werner:
It seems to me that the library would benefit from a default to do
a flush after all other things have run.
Normally they do. The only cases, just to repeat, are async running
stuff e.g. timers, xmlhttp requests, etc.
Yes, but they are im
Am 17.02.2007 um 01:48 schrieb Andreas Junghans:
> Hi,
>
> Am 16.02.2007 um 17:37 schrieb [EMAIL PROTECTED]:
>
>> My intention and hope is to be able to copy over new versions of
>> qooxdoo with
>> no changes to the qooxdoo internals at all, including to any
>> tools. Therefore
>> what I need fo
Hi Hugh,
Am 17.02.2007 um 08:28 schrieb Hugh Gibson:
>> Our argument at the development time was the same. Background
>> intervals are really ugly. I you want to use them, use them. But I
>> don't like to have such things in the framework. Finally.
>
> Search on "window.setTimeout" and you will f
Am 17.02.2007 um 08:28 schrieb Hugh Gibson:
>> To use a timeout in these cases is always a good idea.
>
> I'm going to put my naive user hat on here.
>
> qooxdoo hides browser complexity. I've really enjoyed the fact that
> I can just program to a fixed API, and it works in various browsers.
>
Am 17.02.2007 um 08:28 schrieb Hugh Gibson:
>> Our argument at the development time was the same. Background
>> intervals are really ugly. I you want to use them, use them. But I
>> don't like to have such things in the framework. Finally.
>
> Search on "window.setTimeout" and you will find 7 hit
18 matches
Mail list logo
