Darren Freeman wrote:
On Sun, 2007-09-30 at 12:47 -0400, Richard Heck wrote:
Should be easy to solve.
Can you fix this, Abdel? Unfortunately, I do not have time now, as I'd
really, really nice if a fix could be included in 1.5.2. I have been
thinking I need to go back to using 1.4.5.
On Sun, 2007-09-30 at 12:47 -0400, Richard Heck wrote:
> > Should be easy to solve.
> Can you fix this, Abdel? Unfortunately, I do not have time now, as I'd
> really, really nice if a fix could be included in 1.5.2. I have been
> thinking I need to go back to using 1.4.5.1 myself, this gets so b
Dov Feldstern <[EMAIL PROTECTED]> writes:
> I strongly recommend
> http://www.catb.org/~esr/writings/taoup/html/ch05s02.html (the book in
> general, this chapter specifically is relevant to this discussion)
Very interesting indeed.
JMarc
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
"standard" is the key word yes. INI-like or XML is easy to parse and
is understood by a lot of application. Designing an UI to change an
XML or an INI file is easy. XML offers much more possibilities of
extension though.
On Mon, Oct 01, 2007 at 06:56:44PM +0200, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
> >On Mon, Oct 01, 2007 at 09:48:00AM +0200, Abdelrazak Younes wrote:
> >>Jean-Marc Lasgouttes wrote:
> >>>Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> >>>
> Edwin Leuven wrote:
> >Richard Heck wrot
On Mon, Oct 01, 2007 at 06:36:16PM +0200, Jean-Marc Lasgouttes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> >> Could give a more precise scenario where this happens?
> >
> > Would be irrelevant. There is no reason that the status update is
> > triggered _only_ by a cursor move.
>
> It i
Andre Poenitz wrote:
On Mon, Oct 01, 2007 at 09:48:00AM +0200, Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Edwin Leuven wrote:
Richard Heck wrote:
Well, toolbars have not been designed for several dozens of entries.
calling this a desi
On Mon, Oct 01, 2007 at 05:10:00PM +0200, Abdelrazak Younes wrote:
> Jean-Marc Lasgouttes wrote:
> >Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> >
> >>>Assuming the two choices are ini or xml, I fail to see the advantages
> >>>of xml for what we want to do.
> >>Structured tree-like structure.
>
On Mon, Oct 01, 2007 at 04:06:10PM +0200, Jean-Marc Lasgouttes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> > Are you just trying to avoid the discussion?
>
> No, I just believe that the model of updating after the lfun execution
> is a robust one.
>
> > If not and you genuinely
Andre Poenitz <[EMAIL PROTECTED]> writes:
>> Could give a more precise scenario where this happens?
>
> Would be irrelevant. There is no reason that the status update is
> triggered _only_ by a cursor move.
It is not a cursor move, it is any action going through dispatch.
Then the update mechani
On Mon, Oct 01, 2007 at 12:19:20PM +0200, Jean-Marc Lasgouttes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> > Moreover, with the current architecture, a status change is not
> > immediately reflected in the relevant icon, you will have to trigger a
> > new action to update all the ot
On Mon, Oct 01, 2007 at 09:48:00AM +0200, Abdelrazak Younes wrote:
> Jean-Marc Lasgouttes wrote:
> >Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> >
> >>Edwin Leuven wrote:
> >>>Richard Heck wrote:
> >Well, toolbars have not been designed for several dozens of entries.
> >>>calling this a desi
On Mon, Oct 01, 2007 at 12:18:01PM +0200, Jean-Marc Lasgouttes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> >> why not use signals: if a tabular gets focucs it sends an enabled
> >> signal to the associated actions, and a disabled signal when it
> >> looses focus?
> >
> > That would
Andre Poenitz wrote:
> Of course not using math is objectable.
I use it _rarely_, if only to celebrate otherness.
Jürgen
On Mon, Oct 01, 2007 at 11:34:38AM +0200, Edwin Leuven wrote:
> Jürgen Spitzmüller wrote:
> >Do you have some (subjective or objective) measures on the speed
> >improvement?
>
> no, but richard was complaining that the panels took a bit of time to update
>
> >I.e., is it worth to shove this in
On Mon, Oct 01, 2007 at 11:33:55AM +0200, Abdelrazak Younes wrote:
> Edwin Leuven wrote:
> >Abdelrazak Younes wrote:
> >>>However, I would be surprised to see someone come up with a
> >>>proper alternative to the general idea of polling getStatus
> >>
> >>No but we could add an option for not polli
On Mon, Oct 01, 2007 at 11:27:10AM +0200, Edwin Leuven wrote:
> Abdelrazak Younes wrote:
> >>However, I would be surprised to see someone come up
> >>with a proper alternative to the general idea of polling getStatus
> >
> >No but we could add an option for not polling getStatus and return early
>
On Mon, Oct 01, 2007 at 09:41:23AM +0200, Jürgen Spitzmüller wrote:
> Abdelrazak Younes wrote:
> > > Ah, silly me. Much simpler patch attached.
> >
> > Looks better ;-)
>
> I guess it cannot do any harm. And it improves the situation
> significantly for people like me who only use the math toolbar
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
FWIW, I agree that the toolbar design is awkward, and that a rewrite
would be welcome.
The first thing to do would be to move *all* code related to toolbar
and menubar handling to the frontend. We should do the toolbar/menubar
Action unifica
Jean-Marc Lasgouttes wrote:
Edwin Leuven <[EMAIL PROTECTED]> writes
Jürgen Spitzmüller wrote:
Do you have some (subjective or objective) measures on the speed
improvement?
no, but richard was complaining that the panels took a bit of time to update
A simple test to see wheth
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Assuming the two choices are ini or xml, I fail to see the advantages
of xml for what we want to do.
Structured tree-like structure.
It is great to represent data that does not have a tree structure, right;)
INI is s
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> I think you are only trying to scare yourself ;-)
It might be...
JMarc
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> Assuming the two choices are ini or xml, I fail to see the advantages
>> of xml for what we want to do.
>
> Structured tree-like structure.
It is great to represent data that does not have a tree structure, right;)
> I reckon that even more people
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Are you just trying to avoid the discussion?
No, I just believe that the model of updating after the lfun execution
is a robust one.
That what I understood yes :-)
If not and you genuinely want to discuss then I'
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
"standard" is the key word yes. INI-like or XML is easy to parse and
is understood by a lot of application. Designing an UI to change an
XML or an INI file is easy. XML offers much more possibilities of
extension though.
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> "standard" is the key word yes. INI-like or XML is easy to parse and
> is understood by a lot of application. Designing an UI to change an
> XML or an INI file is easy. XML offers much more possibilities of
> extension though. the layout-like format
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
XML because it's easy to parse and modify via a GUI.
And also because I like XML :-)
I see :)
But an INI-like format could do too:
We should probably try to reduce the number of formats we use:
lyx-format-like (pr
> The only way this could happen is when this other app automatically put the
> X11 selection in the X11 clipboard (which is bad).
no its not bad, once you get accustomed to it its very useful on contrary.
(btw i dont use any desktop manager here and works too).
pavel
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> XML because it's easy to parse and modify via a GUI.
>
> And also because I like XML :-)
I see :)
> But an INI-like format could do too:
We should probably try to reduce the number of formats we use:
lyx-format-like (prefs, bindings), layout lik
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Are you just trying to avoid the discussion?
No, I just believe that the model of updating after the lfun execution
is a robust one.
> If not and you genuinely want to discuss then I'd say yes,
> basically. This example shows that we do a lot of
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
>> Why? I do not like using a gui name to look up a function. lfun+arg
>> looks better to me.
>
> Hum, thinking a bit more about it, we should probably have an ascii ID
>
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> Why? I do not like using a gui name to look up a function. lfun+arg
>> looks better to me.
>
> lfun+arg might be very long, especially if the action is a command
> sequence. And the name is defined already in the menu description file
> (stmenu.inc)
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
The first thing to do would be to move *all* code related to toolbar
and menubar handling to the frontend. We should do the toolbar/menubar
Action unification we were talking about back before 1.
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Why? I do not like using a gui name to look up a function. lfun+arg
looks better to me.
Hum, thinking a bit more about it, we should probably have an ascii ID
and a GUI description string, ex:
name="select-all"
desc
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
The first thing to do would be to move *all* code related to toolbar
and menubar handling to the frontend. We should do the toolbar/menubar
Action unification we were talking about back before 1.4.0 (in
Christmas 2005?),
> I'll leave trunk to you BTW.
http://www.lyx.org/trac/changeset/20637
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
But please note that was just a show case to demonstrate the inherent
problem in our current architecture.
Is the fact that LyX should update itself due to external causes so
common that it becomes a fundamental problem?
Jürgen Spitzmüller wrote:
> > you should also apply the attached. it does the same but for the popup
> > menus on the math toolbar...
>
> Thanks, done.
I'll leave trunk to you BTW.
Jürgen
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> The first thing to do would be to move *all* code related to toolbar
> and menubar handling to the frontend. We should do the toolbar/menubar
> Action unification we were talking about back before 1.4.0 (in
> Christmas 2005?), basically:
Yes.
> We
Leuven, E. wrote:
> you should also apply the attached. it does the same but for the popup
> menus on the math toolbar...
Thanks, done.
Jürgen
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> But please note that was just a show case to demonstrate the inherent
> problem in our current architecture.
Is the fact that LyX should update itself due to external causes so
common that it becomes a fundamental problem?
JMarc
JMarc wrote:
> The alternative is not to disable the parent button, but
> only the individual entries at display time.
then we can get rid of the updating of the parent altogether as in attached...
x.patch
Description: x.patch
you should also apply the attached. it does the same but for the popup menus on
the math toolbar...
-Original Message-
From: Jürgen Spitzmüller [mailto:[EMAIL PROTECTED]
Sent: Mon 10/1/07 12:35
To: LyX Devel
Subject: Re: Slowness Progress
Jean-Marc Lasgouttes wrote:
> OK, but it se
Also sprach Helge Hafting:
> Not that I want to leave everything needlessly enabled, but can't
> people request just about any action from the minibuffer anyway?
> So ideally, every action need to check if it is possible. Or do the
> minibuffer do its own checking?
The enabled flag also concerns
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
scenario 1:
- clear out the clipboard (on Windows I can do that in MS word).
- go to LyX: the "paste" icon is not disabled.
- move the cursor: the "paste" icon is disabled.
OK, I see. Is LyX notified when this happens?
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> scenario 1:
> - clear out the clipboard (on Windows I can do that in MS word).
> - go to LyX: the "paste" icon is not disabled.
> - move the cursor: the "paste" icon is disabled.
OK, I see. Is LyX notified when this happens? It could do an extra
upd
Jean-Marc Lasgouttes wrote:
> OK, but it seems you do a gratuitous change of indentation in the
> "#if 0" part.
Copy'n'paste issue. I'll fix this.
Jürgen
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Moreover, with the current architecture, a status change is not
immediately reflected in the relevant icon, you will have to trigger a
new action to update all the other action statuses. Take the "paste"
action for exampl
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes:
> Jean-Marc Lasgouttes wrote:
>> It looks OK. The alternative is not to disable the parent button, but
>> only the individual entries at display time.
>
> I think this would be rather confusing.
> I'm tempted to commit the attached version of Edwin's
Jean-Marc Lasgouttes wrote:
> It looks OK. The alternative is not to disable the parent button, but
> only the individual entries at display time.
I think this would be rather confusing.
I'm tempted to commit the attached version of Edwin's patch.
Jürgen
Index: src/frontends/qt4/IconPalette.cpp
=
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
why not use signals: if a tabular gets focucs it sends an enabled
signal to the associated actions, and a disabled signal when it
looses focus?
That would be the best solution but we would need an "LFUN manager" that
wil
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes:
>> patch for 1.5 attached. could you apply it if you want it?
>
> Yes. Objections anybody?
It looks OK. The alternative is not to disable the parent button, but
only the individual entries at display time.
JMarc
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Moreover, with the current architecture, a status change is not
> immediately reflected in the relevant icon, you will have to trigger a
> new action to update all the other action statuses. Take the "paste"
> action for example; it the clipboard is
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> why not use signals: if a tabular gets focucs it sends an enabled
>> signal to the associated actions, and a disabled signal when it
>> looses focus?
>
> That would be the best solution but we would need an "LFUN manager" that
> will receive the dif
Edwin Leuven wrote:
> Jürgen Spitzmüller wrote:
> > Do you have some (subjective or objective) measures on the speed
> > improvement?
>
> no, but richard was complaining that the panels took a bit of time to
> update
Right. I remember he measured 20ms for the panel. Reasoning enough.
> > I.e., is
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes:
> I guess it cannot do any harm. And it improves the situation
> significantly for people like me who only use the math
> toolbars/panels very rarely.
>
> Any objections?
No, it looks good.
JMarc
Edwin Leuven <[EMAIL PROTECTED]> writes:
> Jürgen Spitzmüller wrote:
>> Do you have some (subjective or objective) measures on the speed
>> improvement?
>
> no, but richard was complaining that the panels took a bit of time to update
A simple test to see whether toolbars matter is to comment out
Jürgen Spitzmüller wrote:
Do you have some (subjective or objective) measures on the speed improvement?
no, but richard was complaining that the panels took a bit of time to update
I.e., is it worth to shove this in for 1.5.2? I take it that the risks are
low (my previous question).
as i wr
Edwin Leuven wrote:
Abdelrazak Younes wrote:
However, I would be surprised to see someone come up with a
proper alternative to the general idea of polling getStatus
No but we could add an option for not polling getStatus and return
early in case when the LFUN is disabled. The later should be
Abdelrazak Younes wrote:
However, I would be surprised to see someone come up
with a proper alternative to the general idea of polling getStatus
No but we could add an option for not polling getStatus and return early
in case when the LFUN is disabled. The later should be done anyway. The
onl
Edwin Leuven wrote:
> > because in the panels, we currently have all or nothing enabled, right?
>
> because all the actions in the panels are the same type
> so yes
Do you have some (subjective or objective) measures on the speed improvement?
I.e., is it worth to shove this in for 1.5.2? I take i
Jürgen Spitzmüller wrote:
> I guess it cannot do any harm. And it improves the situation significantly
> for people like me who only use the math toolbars/panels very rarely.
I committed this.
Jürgen
Abdelrazak Younes wrote:
> Summary: we should always check the action status before we proceed.
Probably. I just wanted to point out that this is not exactly an easy change.
Jürgen
Jürgen Spitzmüller wrote:
Helge Hafting wrote:
Leave every option enabled
and just don't do anything when the user tries something impossible.
This should be an easy patch.
I doubt this will be much easier (you still have to check). And it's risky: we
had countless crashes in tha past because
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
And here is an updated patch for that.
I'd say: apply. This is the right thing to do anyway.
Done.
Abdel.
Abdelrazak Younes wrote:
> And here is an updated patch for that.
I'd say: apply. This is the right thing to do anyway.
Jürgen
Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
And not even compiled... here is another one that compiles and seems to
work fine.
This looks very sensible.
I asked the reporters on bugzilla for testing, to assure the this
fixes the bug.
Note that there might be
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Edwin Leuven wrote:
Richard Heck wrote:
Well, toolbars have not been designed for several dozens of entries.
calling this a design is very nice
I didn't dare to say it ;-)
FWIW, I agree that the toolbar design is aw
Abdelrazak Younes wrote:
> > Ah, silly me. Much simpler patch attached.
>
> Looks better ;-)
I guess it cannot do any harm. And it improves the situation significantly for
people like me who only use the math toolbars/panels very rarely.
Any objections?
Jürgen
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
From a quick glance at the patch it seems that you don't need to change
the ActionVector. Adding a QLToolbar::isVisible() should be enough.
Ah, silly me. Much simpler patch attached.
Looks better ;-)
Abdel.
Abdelrazak Younes wrote:
> From a quick glance at the patch it seems that you don't need to change
> the ActionVector. Adding a QLToolbar::isVisible() should be enough.
Ah, silly me. Much simpler patch attached.
Jürgen
Index: src/frontends/qt4/QLToolbar.cpp
===
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
And not even compiled... here is another one that compiles and seems to
work fine.
This looks very sensible.
I asked the reporters on bugzilla for testing, to assure the this fixes the
bug.
Note that there might be a need for a similar fix
Jürgen Spitzmüller wrote:
Jean-Marc Lasgouttes wrote:
Second, every toolbar is updated every time through here EVEN IF IT IS
NOT DISPLAYED. I found this out because hiding the standard toolbar
made no difference. This is a waste.
This should definitely be fixed.
How about the attached?
From
Jean-Marc Lasgouttes wrote:
> > Second, every toolbar is updated every time through here EVEN IF IT IS
> > NOT DISPLAYED. I found this out because hiding the standard toolbar
> > made no difference. This is a waste.
>
> This should definitely be fixed.
How about the attached?
Jürgen
Index: src/fr
Jürgen Spitzmüller wrote:
Edwin Leuven wrote:
the attached patch checks only the first action on a panel instead of all
(this won't change the behavior for the panels we ship)
because in the panels, we currently have all or nothing enabled, right?
because all the actions in the panels are t
Edwin Leuven wrote:
> the attached patch checks only the first action on a panel instead of all
>
> (this won't change the behavior for the panels we ship)
because in the panels, we currently have all or nothing enabled, right?
Jürgen
Helge Hafting wrote:
> Leave every option enabled
> and just don't do anything when the user tries something impossible.
> This should be an easy patch.
I doubt this will be much easier (you still have to check). And it's risky: we
had countless crashes in tha past because an "impossible" action
Abdelrazak Younes wrote:
> And not even compiled... here is another one that compiles and seems to
> work fine.
This looks very sensible.
I asked the reporters on bugzilla for testing, to assure the this fixes the
bug.
Jürgen
Abdelrazak Younes wrote:
One question, there is still something I don't understand in this
issue. In principle the X11 Clipboard should not be triggered if the
only thing you did was to select something in some other apps. The
only way this could happen is when this other app automatically put
On Sun, Sep 30, 2007 at 11:11:49PM +0200, Jean-Marc Lasgouttes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> > Edwin Leuven wrote:
> >> Richard Heck wrote:
> Well, toolbars have not been designed for several dozens of entries.
> >>
> >> calling this a design is very nice
> >
> >
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Edwin Leuven wrote:
>> Richard Heck wrote:
Well, toolbars have not been designed for several dozens of entries.
>>
>> calling this a design is very nice
>
> I didn't dare to say it ;-)
FWIW, I agree that the toolbar design is awkward, and that
Edwin Leuven wrote:
Richard Heck wrote:
Well, toolbars have not been designed for several dozens of entries.
calling this a design is very nice
I didn't dare to say it ;-)
Indeed. But maybe there is a way around that problem, short of
reverting to the math panel.
the attached patch che
On Sun, Sep 30, 2007 at 10:19:04PM +0200, Abdelrazak Younes wrote:
> One question, there is still something I don't understand in this issue.
At the core of the issue is that qApp->clipboard()->text() is expensive.
So anything that removes these calls is Good(tm).
Andre'
Abdelrazak Younes wrote:
Richard Heck wrote:
Abdelrazak Younes wrote:
Richard Heck wrote:
First, the slowness is coming during the update of the standard
toolbar, in particular, during the update of the PASTE button, and
more precisely during the getStatus() call, and yet more precisely,
dur
Richard Heck wrote:
Abdelrazak Younes wrote:
Richard Heck wrote:
First, the slowness is coming during the update of the standard
toolbar, in particular, during the update of the PASTE button, and
more precisely during the getStatus() call, and yet more precisely,
during the theClipboard().emp
Richard Heck wrote:
Abdelrazak Younes wrote:
Richard Heck wrote:
First, the slowness is coming during the update of the standard
toolbar, in particular, during the update of the PASTE button, and
more precisely during the getStatus() call, and yet more precisely,
during the theClipboard().emp
Richard Heck wrote:
Jean-Marc Lasgouttes wrote:
Richard Heck <[EMAIL PROTECTED]> writes:
Second, every toolbar is updated every time through here EVEN IF IT IS
NOT DISPLAYED. I found this out because hiding the standard toolbar
made no difference. This is a waste.
This should definitely
Richard Heck wrote:
Well, toolbars have not been designed for several dozens of entries.
calling this a design is very nice
Indeed. But maybe there is a way around that problem, short of reverting
to the math panel.
the attached patch checks only the first action on a panel instead of all
On Sun, Sep 30, 2007 at 06:01:05PM +0200, Jean-Marc Lasgouttes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> > Ah... "Sending Mail" and "Bromarv" somehow has a strong connotation to
> > "Black Hole"...
> >
> > Could it be that I sent the mails, but _in Bromarv_?
>
> Yes.
I case you are
Richard Heck wrote:
> > Should be easy to solve.
>
> Can you fix this, Abdel? Unfortunately, I do not have time now, as I'd
> have to learn a lot about this code before I'd know what to do, and I
> have a lecture to give next weekend at a big conference. It would be
> really, really nice if a fix c
Abdelrazak Younes wrote:
Richard Heck wrote:
First, the slowness is coming during the update of the standard
toolbar, in particular, during the update of the PASTE button, and
more precisely during the getStatus() call, and yet more precisely,
during the theClipboard().empty() check. So I did
On Sun, Sep 30, 2007 at 05:50:31PM +0200, Andre Poenitz wrote:
> On Sun, Sep 30, 2007 at 05:34:20PM +0200, Jean-Marc Lasgouttes wrote:
> > Andre Poenitz <[EMAIL PROTECTED]> writes:
> >
> > > I remember sending at least two messages to the list saying that calling
> > > QClipboard::text() is an ext
Jean-Marc Lasgouttes wrote:
Richard Heck <[EMAIL PROTECTED]> writes:
Second, every toolbar is updated every time through here EVEN IF IT IS
NOT DISPLAYED. I found this out because hiding the standard toolbar
made no difference. This is a waste.
This should definitely be fixed.
And it
Andre Poenitz <[EMAIL PROTECTED]> writes:
> Ah... "Sending Mail" and "Bromarv" somehow has a strong connotation to
> "Black Hole"...
>
> Could it be that I sent the mails, but _in Bromarv_?
Yes.
JMarc
On Sun, Sep 30, 2007 at 05:37:53PM +0200, Jean-Marc Lasgouttes wrote:
> Richard Heck <[EMAIL PROTECTED]> writes:
>
> > Second, every toolbar is updated every time through here EVEN IF IT IS
> > NOT DISPLAYED. I found this out because hiding the standard toolbar
> > made no difference. This is a wa
On Sun, Sep 30, 2007 at 05:34:20PM +0200, Jean-Marc Lasgouttes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> > I remember sending at least two messages to the list saying that calling
> > QClipboard::text() is an extremely expensive operation and should be
> > avoided.
>
> I am not sure
Richard Heck <[EMAIL PROTECTED]> writes:
> Second, every toolbar is updated every time through here EVEN IF IT IS
> NOT DISPLAYED. I found this out because hiding the standard toolbar
> made no difference. This is a waste.
This should definitely be fixed.
> Third, even under the best of circumst
Andre Poenitz <[EMAIL PROTECTED]> writes:
> I remember sending at least two messages to the list saying that calling
> QClipboard::text() is an extremely expensive operation and should be
> avoided.
I am not sure I ever saw your rumored Bromarv message about how
selection should be done.
JMarc
Andre Poenitz wrote:
On Sat, Sep 29, 2007 at 11:27:56AM -0400, Richard Heck wrote:
and I'm getting times on the order of 125ms just for that one call.
I remember sending at least two messages to the list saying that calling
QClipboard::text() is an extremely expensive operation and should be
Richard Heck wrote:
Abdelrazak Younes wrote:
I can't reproduce the selection problem (because I'm not on X11) but
could you please apply this patch and report if the slowness problem
still persist?
Unfortunately, that did not help. But here are some more things I've
found out.
First, the slo
1 - 100 of 105 matches
Mail list logo
