> --- Ursprüngliche Nachricht ---
> Von: Jon Keating <[EMAIL PROTECTED]>
> An: licq-devel@lists.sourceforge.net
> Betreff: [Licq-devel] Licq Meeting 2006-05-16 (#6)
> Datum: Fri, 19 May 2006 16:31:45 +0900
>
> Hello,
>
> Here is the log for this week's meeting. The items discussed were:
>
> * How plugins can modify the GUI
> * Options dialog
> * Multiple instances of one protocol
> * Some admin stuff.
>
> Not a whole lot, but the plugins modifying/influencing the GUI is a big
> topic by itself.
>
> Jon
>
> --
> ________________________________________________________
> Jon Keating ICQ: 16325723
> [EMAIL PROTECTED] MSN: [EMAIL PROTECTED]
> http://www.licq.org GPG: 2290A71F
> http://www.thejon.org HOME: Minamiashigara, Japan
>
Hi,
sadly I couldn't participate on the last meeting. However, I've read the log
and wanted to present you my thoughts.
The GUI stuff: Although it's quite a hard thing to do an XML-like engine
should be the best. Concerning the question how plugins can modify other
plugins my ideas were:
A plugin (whatever - the main gui plugin for example) registers certain
windows. Maybe at the beginning of the proto description there is a
RegisterWindow("mainWindow");
RegisterWindow("optionsWindow");
RegisterWindow("conversationWindow");
or something like this.
Another protocol plugin has then the ability to connect a function to the
creation of this window by doing something like
ConnectModifier(FindWindow("mainWindow"), (connectionCB)my_mwModifier);
This info is passed to the "renderer", the engine which either renders the
XML stuff to QT or GTK or HTML or so.
Whenever the window is rendered now by the information the mainwindow-plugin
has given, after the original xml is loaded the function my_mwModifier would
be called in this example.
This function can access the vboxes, hboxes and whatever of the window
(because they were given names when creating them), maybe something like
{
AbstractWindow* mainWnd;
AbstractWindowElement* toolbar1;
mainWnd = CurrentRenderer->findWindow("mainWindow");
if (!mainWnd)
return;
toolbar1 = mainWnd->GetElement("toolbar1box");
if (!toolbar1)
return;
toolbar1->AppendToCode(asprintf("<button text='test' name='testbutton'
enabled='false' onclick='%p'/>", (cbFunction)testButtonClickFunction);
}
after the window is altered it gets rendererd.
same eg. for the main menu. in the xml code the menu is called mainMenu and
separated into units. the xml code could be something like
<menulist name="mainMenu">
<listsection name="generalstuff">
<menuitem name="mi1">Menu Item 1 </menuitem>
<menuitem name="mi2">Menu Item 2 </menuitem>
</listsection>
<listsection name="pluginitems">
</listsection>
...
</menulist>
A plugin could now register its functions by doing a
AbstractWindowElement* pluginSection;
pluginSection =
CurrentRenderer->findWindow("mainWindow")->GetSection("mainMenu")->GetSection("pluginitems");
pluginSection->AppendCode("<menuitem name='mi_licq'>Licq plugin menu
item</menuitem>");
pluginSection->Render();
This would be a quite easy and elegant way in my eyes.
The problem of many instances of one type is really not that easy. I also
think that Jon's idea is the best.
Regards
Joachim
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Licq-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/licq-devel
