[16:07:25] -----------------------------------------
[16:07:25] >>> GOT TCL/TK ERROR : {{invalid command name
"::plugins::findplugins"}}
>>> Stack:
invalid command name "::plugins::findplugins"
while executing
"::plugins::findplugins"
(procedure "::plugins::UpdatedPlugins" line 5)
invoked from within
"::plugins::UpdatedPlugins"
(procedure "::autoupdate::UpdateLangPlugin" line 10)
invoked from within
"::autoupdate::UpdateLangPlugin"
(procedure "::autoupdate::check_web_version" line 54)
invoked from within
"::autoupdate::check_web_version $token"
("eval" body line 1)
invoked from within
"eval $state(-command) {$token}"
("eval" body line 12)
invoked from within
"eval ::error $errorlist"
(procedure "http::reset" line 11)
invoked from within
"http::reset ::http::1 timeout"
("after" script)
>>> Code: NONE
[16:07:25] -----------------------------------------
[16:07:25] >>> AMSN version: 0.96b - AMSN date: 12/22/2005
[16:07:25] >>> TCL version : 8.5a3 - TK version : 8.5a3
[16:07:25] >>> tcl_platform array content : byteOrder littleEndian
osVersion 2.6.15-1.1955_FC5 platform unix machine i686 threaded 1 os
Linux wordSize 4 user tjikkun
[16:07:25] -----------------------------------------
On Sun, 2006-03-19 at 22:09 -0800, Karol Krizka wrote:
> Hi everyone,
> Over the past week I worked on the plugin system and improved it a
it.
> Here are sme notes.
>
> RegisterPlugin
> This was quite a useless proc because all it did was add the plugin to
> known plugins and was required to be called every plugin. So I figured
> that it might be a good idea to have the proc executed autmaticily
after
> the plugin is loaded. This will also allow the plugin not having to
> unregister itself if it fails loading. For example like the chameloen
> plugin is doing now.
>
> knownplugins
> This basically held names of plugins that are loaded or were loaded in
> previous life. There are two other variables that hold this
information.
> loadedplugins has a list of currently loaded plugins and ::*_cfg are
> configs of previously loaded plugins. So to get rid of this
duplication,
> I removed knownplugins list.
>
> ::*_cfg
>
> This was seveal arrays in the global namespace that held the config of
> previously loaded, but now unloadd pluins. Two probems i saw with this
> were that (1) it is in th global namespace and (2) hard to keep track
of
> because there was a different one for each plugin. So first I moved it
> into ::plugins:: and sencond I created a single array called "config"
> which has names of plugins as keys and the value is it's config as a
list
> (via "array get")
>
> restoring config in LoadPlugin
> Currently old configuration is restored after the plugin is
initialized
> because the default config is created in the init proc. I was thinking
> what if the plugin initialized with needing somehting from the
> configuration? So wouldn't it better to have the config set outside
any
> proc and then restore the configuration before calling the init proc?
> What does everyone think?
>
> ::plugins::getInfo plugin param
>
> New proc that returns the parameter that is set inside plugininfo.xml.
> The parameter has to be exactly as the name of the tag inside the
file.
> If such a parameter is not found, The proc returns blank.
>
> All my changes shouldn't break compability with any of the plugins. If
> you find something that does please tell me and I will try to fix it.
I
> will also announce this on the forums for those that want to get a
head
> start developing plugins for 0.96 after my changes have been
disscussed
> here on the mailing list.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the live
webcast and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel
