yeah, right! good point!, I also though of putting it into one canvas
(that's when I said, maybe Tom cuold make it into a single widget) but I
didn't think about plugin's incompatibility, I didn't want it to be
done,
only because it would be much more complicated!
anyways, if Phil is ready to do it, it would be great :) just keep it as
it is now, but as I said, make it not destroy the widgets!
by the way, I remembered a little problem I had a while ago at the job,
where I used Tk for a gui, and I had a text widget with a dump of a log
file from my app.. and I would 'clear' the text widget with a delete 0.0
end... if the text widget was huge, it would freeze my pc with 100% cpu
for a while.. I found a solution by 'destroy $tw; text $tw; pack $tw'...
and it was instantenuous (and we couldn't even see the widget being
recreated)
for amsn, I just tried this ida.. I commented the tag deleton and the
delte 0.0 end, and added a destroy $pgBuddy, and recreated the text
widget
the same way it was created in cmsn_draw_main... the CL redraw became
almost instantenuous, it became really fast! but with a huge flickering,
that's the only problem.. this explains why it's so slow when you draw
the
CL witht he offline group expanded or not (where most users are)... the
problem is not in writing the users, it's in deleting the old CL's
content!!!
we should make sure of what I just said by making a 'clear_pgbuddy' proc
where we would delete the tags and the content, and time it with the
profiler... see how much time it takes, if it's significant...
problem with that, is :
1 - the flickering
2 - all nicks become '...' because the widget's width on creation is
0x0...
I'm thinking about having "pgBuddy1" and "pgBuddy2".. when we
cmsn_draw_online, we would :
pack forget $pgBuddy1; pack $pgBuddy2; destroy $pgBuddy1; text $pgBuddy1
..; set pgBuddy $pgBuddy1
(switching 1 and 2 depending on a variable)
so we get all the time one empty text widget created but not packed, and
the one we work on, when we want tos how the CL, we would pack the empty
one and work on it (without deleting its content) and we would have the
old one deleted and recreated but not packed...
we could even pack the new CL once it's completly drawn.. this would be
equal to having 'double buffering' for the CL.. + we could use the old
CL
width and height for truncation calculations...
anyways, it's just an idea.. I don't want it to be done and we finally
release all the work was for nothing since it doesn't improve
anything...
but if it does improve and with a huge diff... we could flag it for a
TODO... (who likes code refactoring ?? :P)
KaKaRoTo
On Fri, 03 Feb 2006 13:55:14 -0500, Harry Vennik <[EMAIL PROTECTED]>
wrote:
> I think technically it is a good idea, but in practice we'd better
just
> wait
> for the new CL, and stay compatible until then.
>
> Op vrijdag 3 februari 2006 19:37, schreef Le Philousophe - Phil:
>> Hi,
>> I would like to do a so good thing and in same time a so bad thing :
>> remove
>> all these controls and replace all by a canvas with images and texts
>> and no
>> more children windows... But I know the big trouble : it will make
>> plugins
>> incompatible....
>> What do you think ?
>> Phil
>>
>> Le Friday 03 February 2006 10:20, Youness Alaoui a écrit :
>> > indeed, no more flickering of the CL on update.. AT ALL! :D
youpiii :)
>> > but we still got the top part flickering.. the reason is simple :
>> > #Clear the children of top to avoid memory leaks:
>> > foreach child [winfo children $pgBuddyTop] {
>> > destroy $child
>> > }
>> > pack $pgBuddyTop -expand false -fill x -before $pgBuddy
>> >
>> >
>> > that's in cmsn_draw_online... so it means the top part gets
recreated
>>
>> and
>>
>> > repacked, which obviously makes it flicker.. I suggest refactoring
>>
>> the
>>
>> > code so that it's updated instead of recreated...
>> > Tom, you want to make that into a single widget? :P just kidding!
>> > main things to modify :
>> > 1 - remove destroy things
>> > 2 -keep pack (in case we switch from cmsn_draw_offline!)
>> > 3 - instead of creating a label/canvas (in clickableDisplayPIcture
>>
>> proc)
>>
>> > depending on showdisplaycontactlist skin var, keep it into a one
>>
>> canvas
>>
>> > for both, addd an option to clickableDisplayPicture, if skin var is
>> > enabled, we draw the frame around the DP, if not, we draw the
>>
>> $image_type
>>
>> > (status buddy icon) instead of DP and without any frame! (delete
>>
>> preivous
>>
>> > canvas content!)
>> > 4 - don't recreate the colobar label, just call ::skin::getColorbar
>>
>> and
>>
>> > it will automatically refresh itself (always using the same name
for
>>
>> the
>>
>> > image)
>> > 5 - do similar changes everywhere, like in clear_disp or other proc
>>
>> like
>>
>> > it...
>> > 6 - create all text/canvas/label widgets in the same place
pgBuddyTop
>>
>> is
>>
>> > created the first time!
>> >
>> > is that it ?
>> > I'm sure someone will manage this code refactoring!
>> > Thanks!
>> >
>> > KaKaRoTo
>> >
>> >
>> >
>> > On Thu, 02 Feb 2006 09:45:10 -0500, Arieh Schneier
>> >
>> > <[EMAIL PROTECTED]> wrote:
>> > >> > I have a small problem with your last changes Youness...I use
the
>> > >> > pop3 plugin and I don't see the text for the pop3 plugin
anymore,
>> > >> > just the top of an icon (seems hidden)...Do you have the same
>> > >> > problem?
>> > >
>> > > Fixed in cvs.
>> > >
>> > >
>> > > PS Youness some great work there, lots of small changes, but
such a
>>
>> big
>>
>> > > difference :). No more lag on redisplay of cl :), also I was
finding
>> > > the amsn became unusable during login and its 'better' now. Still
>>
>> can't
>>
>> > > use it
>> > > when the connection is made and it is downloading the cl (Im
>>
>> guessing
>>
>> > > that
>> > > is whats happening) too much cpu usage.
>> > >
>> > >
>> > >
>> > >
>> > > -------------------------------------------------------
>> > > This SF.net email is sponsored by: Splunk Inc. Do you grep
through
>>
>> log
>>
>> > > files
>> > > for problems? Stop! Download the new AJAX search engine that
makes
>> > > searching your log files as easy as surfing the web. DOWNLOAD
>>
>> SPLUNK!
>>
>>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=12164
>>
>> > >2 _______________________________________________
>> > > Amsn-devel mailing list
>> > > Amsn-devel@lists.sourceforge.net
>> > > https://lists.sourceforge.net/lists/listinfo/amsn-devel
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through
log
>> files for problems? Stop! Download the new AJAX search engine that
>> makes
>> searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK!
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
>> _______________________________________________
>> Amsn-devel mailing list
>> Amsn-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/amsn-devel
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
> _______________________________________________
> Amsn-devel mailing list
> Amsn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amsn-devel
