Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
are we in some deeper need of having this in branch? second dev stating he
is not completely sure about the branch patch is imho indication we should
let it for the trunk only.
I tend to agree.
And after the other changes that need makin
Pavel Sanda wrote:
> are we in some deeper need of having this in branch? second dev stating he
> is not completely sure about the branch patch is imho indication we should
> let it for the trunk only.
I tend to agree.
Jürgen
Martin Vermeer wrote:
On Sat, Feb 02, 2008 at 07:14:16PM -0500, rgheck wrote:
Abdelrazak Younes wrote:
rgheck wrote:
Thoroughly? Hard to know. Perhaps we should wait a bit and see if we get
any problems in trunk.
It should be fine in trunk but I am not sure it is 100%
rgheck wrote:
I'll tell you, Abdel, after actually working with this code a bit, I can
see for myself the benefit of all the work you've done. It is MUCH
cleaner. Nice job.
Thanks :-)
Here are the locations of the start/stop calls that didn't seem to me to
need the timer bit: In GuiWorkArea:
On Sat, Feb 02, 2008 at 07:14:16PM -0500, rgheck wrote:
> Abdelrazak Younes wrote:
>> rgheck wrote:
>>
>>> Thoroughly? Hard to know. Perhaps we should wait a bit and see if we get
>>> any problems in trunk.
>>
>> It should be fine in trunk but I am not sure it is 100% safe in branch.
>
> OK. Well
Abdelrazak Younes wrote:
rgheck wrote:
Thoroughly? Hard to know. Perhaps we should wait a bit and see if we
get any problems in trunk.
It should be fine in trunk but I am not sure it is 100% safe in branch.
OK. Well, we know the reporter is capable of patching it himself, so
he's welcome
> It should be fine in trunk but I am not sure it is 100% safe in branch.
are we in some deeper need of having this in branch? second dev stating he is
not completely sure about the branch patch is imho indication we should let it
for the trunk only.
pavel
rgheck wrote:
Thoroughly? Hard to know. Perhaps we should wait a bit and see if we get
any problems in trunk. I'll patch it into my local 1.5.4svn tree, which
is what I used for actual work, and see if I run into anything bad.
Others should do so, too, please. I guess the main thing for someone
rgheck wrote:
Thoroughly? Hard to know. Perhaps we should wait a bit and see if we get
any problems in trunk.
It should be fine in trunk but I am not sure it is 100% safe in branch.
There are a number of calls to start/stopBlinkingCursor(), some of those
are important because we don't want t
Jürgen Spitzmüller wrote:
rgheck wrote:
Jurgen??
I do not fully follow this discussion,
It all started because someone made the reasonable request to be able to
stop the cursor blinking. (This is an accessibility issue.) This can be
configured through Qt4 config, so the right way to
10 matches
Mail list logo
