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
--
KaKaRoTo
-------------------------------------------------------
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=121642
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel
