Hi,
please allow me to add my 2 cents here.
I second Fred in this discussion. His suggestion sounds very
reasonable to me and I think this whole discussion is just a
misunderstanding. Maybe Fred was not clear enough in first mails.
On 2008-12-12 07:02:56 +0100 Richard Frith-Macdonald
On 12 Dec 2008, at 09:06, Andreas Schik wrote:
No. As Class2 inherits from Class1, each subclass of Class2 will
inherit from Class1 as well.
That was my suggestion ... Fred said 'these classes will inherit from
another'
And in how far would this be different? I think you both mean
Yes most of this discussion was just a misunderstanding. What I tried to
propose, but failed to, was as simple new class layout:
NSObject - GSTheme - GSTiledTheme - CustomTheme1
|
\-CustomTheme2
Where we would only provide the first three classes.
GSTheme will
Wolfgang Lux wrote:
Fred Kiefer wrote:
The bigger issue is that the redraw takes so long. Here it could be that
we draw too much, but it could also be that we just flush too much over
to X. The first issue should be simple to detect, we just need to put a
write statement before the call to
I may be totally misunderstanding this whole issue, but to me your mail
sounds as the only potential blocking argument against my proposal is
that the mechanism to select a new theme may need to be a bit more
complex then now. Lets look into that later.
Richard Frith-Macdonald wrote:
On 10 Dec
On 12 Dec 2008, at 00:20, Fred Kiefer wrote:
What I am suggesting is to separate these two concepts also in two
classes.
What I don't see is how this would duplicate code, as these classes
will
inherit from another and that way share most of the code.
Ah ... sounds like your design is
Fred Kiefer wrote:
The bigger issue is that the redraw takes so long. Here it could be
that
we draw too much, but it could also be that we just flush too much
over
to X. The first issue should be simple to detect, we just need to
put a
write statement before the call to drawRect: in
On 9 Dec 2008, at 23:39, Wolfgang Lux wrote:
At this point, the gui appears to highlight the clicked button. At
least
the ktrace output shows that the process attempts to read the
directories
ThemeTiles, ThemeTiles/German.lproj, and ThemeTiles/English.lproj in
the
gui's Resources
Richard Frith-Macdonald wrote:
Ah ... so if I understand correctly, you are saying that the X
library checks and reads from the socket at times *other* than when
we call XPending() in the handler which deals with run loop
events. Thus there is a window between us checking for pending
Richard Frith-Macdonald wrote:
On 10 Dec 2008, at 18:56, Fred Kiefer wrote:
There is the GSTheme class which wastes time looking for non existing
tiles. Here I would suggest that we split up the class. Have the
standard theme class that exactly does what used to be in the gui
drawing code.
Fred Kiefer wrote:
The bigger issue is that the redraw takes so long. Here it could be that
we draw too much, but it could also be that we just flush too much over
to X. The first issue should be simple to detect, we just need to put a
write statement before the call to drawRect: in NSView and
Lately I've been tracking down a rather obscure timing issue which
manifests itself -- at least -- by a delayed processing of events.
For instance, if I click a button very quickly, the button gets
highlighted upon the ButtonPress event, but it remains highlighted
and the ButtonRelease event
to highlighted and mark the control as needing display. This gets picked
up by the _handleAutodisplay: mechanism on NSWindow. This is very likely
to happen when the run loop has nothing else to do.
Fred
Wolfgang Lux wrote:
Lately I've been tracking down a rather obscure timing issue which
13 matches
Mail list logo
