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
rgheck wrote:
> Jurgen??
I do not fully follow this discussion, but the patch itself looks sensible to
me. If it is thoroughly tested, it can go in.
Jürgen
the rest of patch seems ok to me. i tested it as well.
OK, thanks. I'll commit it when that's possible again.
Oh, I see! I guess I don't need to do that
Jurgen??
rh
Pavel Sanda wrote:
By the by, it's NOT possible to set 0ms for blink in Qt4Config (on Linux
anyway), though you can do this directly in .config/Trolltech.conf, as Mark
i guess you tried to put 0 directly there :D
the trick is to go to 10ms and then pres down button and you get "no bli
sh By the by, it's NOT possible to set 0ms for blink in Qt4Config (on Linux
> anyway), though you can do this directly in .config/Trolltech.conf, as Mark
i guess you tried to put 0 directly there :D
the trick is to go to 10ms and then pres down button and you get "no blinking"
string
which is
Ignore the previous one. I overlooked something Abdel said, namely, that
we "do other things" on cursor blinks. This patch undoes that
connection, so that the cursor can blink (or not) independently of other
things. I've also made another change, to reflect JMarc's observation
that "we aren't
IGNORE this one. It misses Abdel's point about the other stuff we do on
blink.
rh
Richard Heck wrote:
Attached. Pavel, if it works for you, go ahead and commit.
It should probably also go to branch. OK, Jurgen?
rh
Attached. Pavel, if it works for you, go ahead and commit.
It should probably also go to branch. OK, Jurgen?
rh
Index: frontends/qt4/GuiWorkArea.cpp
===
--- frontends/qt4/GuiWorkArea.cpp (revision 22743)
+++ frontends/qt4/GuiWorkA
> default rate if the user hasn't specified), call
> QApplication::cursorFlashTime() on any platform---that'll give you the
> required blink rate in milliseconds, with 0 meaning no blinking of
> course:-)
write the patch i will test it and commit it.
pavel
Pavel Sanda <[EMAIL PROTECTED]> writes:
>> We should make sure that LyX honors this setting.
> no it does not.
But it should :)
JMarc
On this page I see:
>
> KDE and Qt applications
>
> In KDE applications the cursor blink rate is not set by KDE, but by the
> underlying Qt libraries. To change it, perform the following steps:
>
> 1. start qtconfig
> 2. on the "Interface" tab either
Pavel Sanda wrote:
In any case, I think we should use QApplication::cursorFlashTime() instead
of the hardcoded 400 ms.
Abdel, resisting courageously the temptation to make a patch...
clearly you need Eve :D
I am just coming from a week in Cairo :-P
But I am now overloaded with real-life wor
> In any case, I think we should use QApplication::cursorFlashTime() instead
> of the hardcoded 400 ms.
>
> Abdel, resisting courageously the temptation to make a patch...
clearly you need Eve :D
pavel
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> In any case, I think we should use QApplication::cursorFlashTime()
> instead of the hardcoded 400 ms.
Note that cursorflashtime is the time for ON + OFF. There should be a
division by 2 somewhere. And we are told not to cache the value.
JMarc
> We should make sure that LyX honors this setting.
no it does not.
p
Mark Summerfield <[EMAIL PROTECTED]> writes:
> I wish there was a Preference option for this. A minority of people
> simply cannot work with software that blinks
> (http://www.jurta.org/prog/noblink.en.html).
On this page I see:
KDE and Qt applications
In KDE applications t
hard-code this value. But, and this is a big
but, beware that we are doing a certain number of things at each cursor
blink so 0 might work well.
In any case, I think we should use QApplication::cursorFlashTime()
instead of the hardcoded 400 ms.
Abdel, resisting courageously the temptation to make a patch...
>> I wish there was a Preference option for this. A minority of people
>> simply cannot work with software that blinks
>> (http://www.jurta.org/prog/noblink.en.html).
>
> We just add the K people and now the cursor blinking haters :-)
>
> Just kidding, your request is much more sane and even sensib
frontends/Workarea.cpp
(1) In the Workarea::Workarea() constructor, change
cursor_timeout_(400) to cursor_timeout_(50)
(2) In the Workarea::hideCursor() method, add the call showCursor();
as the last statement in the method.
That kills cursor blink while still making sure the cursor is red
1) In the Workarea::Workarea() constructor, change
cursor_timeout_(400) to cursor_timeout_(50)
(2) In the Workarea::hideCursor() method, add the call showCursor();
as the last statement in the method.
That kills cursor blink while still making sure the cursor is redrawn
fast enough as you nav
>>>>> "Joao" == Joao Cardoso <[EMAIL PROTECTED]> writes:
Joao> Well, it was not only the cursor blink that consumed cpu time;
Joao> it was the lyxserver! As a matter of fact, the cursor blink only
Joao> wasted a *very* small amount of cpu.
Yes, on some
ts
> > | > of that.
> >
> > No, this is our prolem. It is the cursor blink that uses CPU.
> > (And now with the simplification of code it is easier to fix...)
> >
> > Lgb
>
> I'm not shure if this is a feature or a bug...
>
> If it i
31 matches
Mail list logo
