> -------- Original-Nachricht --------
> Datum: Fri, 26 May 2006 23:53:05 +0900
> Von: Jon Keating <[EMAIL PROTECTED]>
> An: licq-devel@lists.sourceforge.net
> Betreff: Re: [Licq-devel] some GUI thoughts
>
> 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.
>
This would require a kind of rerendering of the window then of course ...
> I think it should be able to only modify windows after they are
> created. This will help reduce some complexity.
>
I don't think so. It's fairly easy to modify the XML code and then render it
instead of rendering it and then go through the complex structure, change
vboxes and hboxes to insert a button somewhere.
> > 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?
Yes, of course this is very complex. To be honest, I still prefer the way of a
backend for every plugin and, if neccessary, a gtk/qt/html/... part for it. As
Stefan and you said - this is kinda shooting flies with A-bombs. We once spoke
about that and you said that you'd prefer a more generalized way that is
suitable for every environment. Maybe this would really be too much of a good
thing ...
>
> > 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.
The XML code would reside in a seperate file. The creator would do:
AbstractWindow* wnd = parser->LoadFile("mainwnd.xml");
then if neccessary the window would be altered by the plugins and rendered then.
>
> 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
>
However, probably it's the best to drop this idea. As Stefan said, a messenger
as a small program which is always activated, must have performance, usability
and low memory usage ... making an XML interpreter would be quite a contrast to
that ...
Regards
Joachim
--
Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer!
Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
Licq-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/licq-devel
