On Sun, May 21, 2006 at 07:16:28PM +0200, QnD [Joachim Staib] wrote:
> 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 sounds good, but the only problem I see with this is how a plugin
can connect to the creation of the window if it is loaded _after_ the
window has been created. For example, the GUI plugin starts and then
from the GUI plugin, another plugin is loaded.
I think it should be able to only modify windows after they are
created. This will help reduce some complexity.
> 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);
> }
Sounds like we need to have an Abstract... for many objects.
A concrete specification would be necessary. A lot of work will be done
in the GUI plugins, translating the Licq specification into whatever
windowing system it uses. I believe this will be a major down point if
other people start to make GUI plugins. It just seems like a lot of
complexity. The on the other hand, how many GUI plugins are we really
going to have?
> 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();
Where would the XML code reside? I'm not quite sure I understand who
makes the XML code and where it is.
XML does sound like it is the best way, since it provides an extendible
format that is easily parsed. I am interested in creating an API for
this, but as you said, it is fairly complex. Could you please answer
the question about where the XML code resides at first? Perhaps that
can help me grasp the basics of this idea.
Jon
--
________________________________________________________
Jon Keating ICQ: 16325723
[EMAIL PROTECTED] MSN: [EMAIL PROTECTED]
http://www.licq.org GPG: 2290A71F
http://www.thejon.org HOME: Minamiashigara, Japan
pgpk8AONaxTBy.pgp
Description: PGP signature
