NoWhereMan wrote: > Btw I don't think the Event NickArray (I don't see anything else, > correct me if I'm wrong :)) is the way to go for plugins; at least > not the only. I mean, passing an _array_ to the event trigger? This > means the trigger will have to cycle _again_ over the array (the > cycle have been already done) and this means slowing it down; I would > rather add another event, say, CLNick or whatever you want it to > sound like called right within the loop.
About this point I wasn't clear; the "slowing it down" means there's a gap between the computational fase and the moment when you display the results. If you can display the results _while_ you're still calculating sizes, of course it will _look_ faster. At the moment it's not that bad, really; btw, it's a way of thinking I've got from working at my blog :D ; if the visitor has to wait for the page to generate before he can see anything, he'll may think the browser or the server hung; of course this does not apply to a client application, moreover I don't even know if you could _do_ this, as you should update the number of contacts in the group label and I don't know if you can do it without having to redraw the whole CL (I guess you're working hard to avoid this, too :)) As Phil pointed me in chat, passing an array (again, I know, the _name_ of the array... you should really update the dev wiki, this is not stated well, and I had to figure this out myself; very annoying... I don't mind "you have to do this to get the value" I want to know "_why_ I have to do it") would mean less calls, so if you have N plugins, calls are N*N_groups, my way you would have N*N_contacts, and there's no waste of time when a new contact gets online, as you pass a singleton array to the event. Still this sounds a bit "dirty" to me. I mean, if the event expect to receive an array with all the contacts of a group (or the whole contact array, I don't remember ATM and it doesn't matter for what I'm saying) it should be always fed with always those contacts. "What a waste of time!". Sure, but it would be more "consistent", wouldn'it ? If you instead have an event _always_ expecting a group of options which is related to a single user, then you could never be wrong that _that_'s what you'll get. And don't forget how much your code would gain in readability: less foreach and more code ;) yes, more calls, but what did you think a class do, when it's inherited? ;) I hope I was clear, and sorry to bug you with my philosphical questions. But you know, at least lePhilousophe should like them, LOL About the CL right padding value... this does not exists as a formal definition, btw I think the Xbegin was good for that; using the buddy_xpad IMO is not correct because would leave (always IMO) too much blank space on the left (while it is still correct on the right). 2*$Xbegin would still fit better as it is a small amount of pixel from the inner border. Of course, again "stupid" matters, but I would like you to discuss them :P (now you understand while my project is always slowing down, rotfl) bye :) -- _____/\/o\/\/here/\/\an_____ NoWhereBlog: www.nowhereland.it deviantArt: http://nowhereland.deviantart.com ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
