#10889: XRC handler for wxAuiNotebook
wxTrac
#10889: XRC handler for wxAuiNotebook
-------------------------------+--------------------------------------------
Reporter: steve_lamerton | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: XRC | Version: 2.9-svn
Keywords: wxAuinoteBook xrc | Blockedby:
Patch: 1 | Blocking:
-------------------------------+--------------------------------------------
This patch adds an xrc handler for wxAuiNotebook, it is against the trunk.
I hope the files were added to the build system correctly, I have not
tried to change it before, it seemed to work for me though!
--
Ticket URL: <http://trac.wxwidgets.org/ticket/10889>
wxTrac
#10889: XRC handler for wxAuiNotebook
-----------------------------+----------------------------------------------
Reporter: steve_lamerton | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: XRC | Version: 2.9-svn
Resolution: | Keywords: wxAuinoteBook xrc
Blockedby: | Patch: 1
Blocking: |
-----------------------------+----------------------------------------------
Comment(by steve_lamerton):
After rebuilding my copy of the library I now get a linker error when
using it in an application that I did not get before,
{{{
libwxmsw29u_xrc.a(xrclib_xmlrsall.o):xmlrsall.cpp:(.text+0x24b):
undefined reference to
`wxAuiNotebookXmlHandler::wxAuiNotebookXmlHandler()'
}}}
Any ideas as to why this is would be appreciated, I cannot see any
differences between this and the other handlers, but I expect it is
something obvious.
--
Ticket URL: <http://trac.wxwidgets.org/ticket/10889#comment:1>
wxTrac
#10889: XRC handler for wxAuiNotebook
-----------------------------+----------------------------------------------
Reporter: steve_lamerton | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: XRC | Version: 2.9-svn
Resolution: | Keywords: wxAuinoteBook xrc
Blockedby: | Patch: 1
Blocking: |
-----------------------------+----------------------------------------------
Comment(by vadz):
I don't know if it's the same problem or not but in any case we have a
problem with this patch because xrc library now depends on aui one -- so
you can't use xrc without aui any more which is not good. We already had
the same problem with wxRichTextCtrl but we never found any good solution
for it, we need to do this now.
--
Ticket URL: <http://trac.wxwidgets.org/ticket/10889#comment:2>
wxTrac
#10889: XRC handler for wxAuiNotebook
-----------------------------+----------------------------------------------
Reporter: steve_lamerton | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: XRC | Version: 2.9-svn
Resolution: | Keywords: wxAuinoteBook xrc
Blockedby: | Patch: 1
Blocking: |
-----------------------------+----------------------------------------------
Comment(by steve_lamerton):
Yes, as it is a linker error is probably is the same issue, looking back
through #10384 it seems like a possible solution would be to inline the
class, not quite sure what you mean but if you explain it I am quite
willing to try and write it!
--
Ticket URL: <http://trac.wxwidgets.org/ticket/10889#comment:3>
Stefa...@t-online.de
> problem with this patch because xrc library now depends on aui one -- so
> you can't use xrc without aui any more which is not good. We already had
> the same problem with wxRichTextCtrl but we never found any good solution
> for it, we need to do this now.
I think it's an ugly hack (which is why I didn't mention it last time), but
I still don't have any better idea, so here it is anyway:
Wwhy not put the object files that depend on more than one DLL in a static
library (a single one for all such modules!)? That way, the linker would be
able to link in exactly those objects that provide stuff that is actually used
by the program and thus only the DLLs that are really needed would be required.
As long as this happens for only a few classes, it shouldn't be (much of) a
problem with respect to executable sizes - or, putting it the other way round:
when it becomes a problem, something is wrong with the way the code is divided
into DLLs...
Regards,
Stefan
Vaclav Slavik
> I think it's an ugly hack (which is why I didn't mention it last time), but
> I still don't have any better idea, so here it is anyway:
> Wwhy not put the object files that depend on more than one DLL in a static
> library (a single one for all such modules!)? That way, the linker would be
> able to link in exactly those objects that provide stuff that is actually used
> by the program and thus only the DLLs that are really needed would be required.
Another solution would be to move XRC handlers into the same DLL that
contains the controls. XRC handlers themselves are each relatively
small, non-trivial loading code is mostly in xmlres.cpp and wxXml.
In order to do this, the dependency of handlers on wxXRC library would
have to be removed, by changing wxXmlResourceHandler base class into a
lightweight proxy (inline or in wxCore) that would be configured at
runtime to forward all calls to wxXmlResourceHandlerImpl (in wxXRC).
Likewise, wxXmlNode would have to be made pure virtual.
This would make all GUI libs a bit larger even for people who don't use
wxXRC, but OTOH, it would remove wxXRC's dependency on wxHTML and wxAdv
(in addition to fixing the wxAUI problem).
Vaclav
Vadim Zeitlin
> Wwhy not put the object files that depend on more than one DLL in a static
> library (a single one for all such modules!)? That way, the linker would be
> able to link in exactly those objects that provide stuff that is actually used
> by the program and thus only the DLLs that are really needed would be required.
Sorry, I don't really understand how exactly is this supposed to work,
maybe an example would help. I.e. what will these static libraries contain
and what will the user program link with and, especially, how is this
supposed to work for Linux/Unix packages which typically contain shared
libraries only for ease of updating?
Regards,
VZ
Vadim Zeitlin
VS> Another solution would be to move XRC handlers into the same DLL that
VS> contains the controls. XRC handlers themselves are each relatively
VS> small, non-trivial loading code is mostly in xmlres.cpp and wxXml.
I think this is the only solution we have. Unless you count putting them
fully inline as a solution.
VS> In order to do this, the dependency of handlers on wxXRC library would
VS> have to be removed, by changing wxXmlResourceHandler base class into a
VS> lightweight proxy (inline or in wxCore) that would be configured at
VS> runtime to forward all calls to wxXmlResourceHandlerImpl (in wxXRC).
VS> Likewise, wxXmlNode would have to be made pure virtual.
Yes. IOW it's a lot of work :-( But again the only not unbearably ugly
alternative is to fold xrc into core entirely and this would probably have
a serious effect on the size of applications not using XRC.
VS> This would make all GUI libs a bit larger even for people who don't use
VS> wxXRC
The only way to avoid this that I see is to have xrc_common, xrc_core,
xrc_adv, xrc_html, ... libraries which seems a bit ridiculous as it's going
to almost double the number of libraries we have.
Regards,
VZ
Stefa...@t-online.de
> > Wwhy not put the object files that depend on more than one DLL in a static
> > library (a single one for all such modules!)? That way, the linker would be
> > able to link in exactly those objects that provide stuff that is actually used
> > by the program and thus only the DLLs that are really needed would be required.
>
> Sorry, I don't really understand how exactly is this supposed to work,
> maybe an example would help.
Basically, it boils down to the same thing as making that stuff fully inline,
just without the drawbacks of inlining (like increased compile time and having
multiple instances of potentially "large" portions of code if the compiler
decides not to inline something).
> I.e. what will these static libraries contain and what will the user program
> link with
I'd create e.g. a libxrc_handlers.a containing xrc_richtext.o and xrc_aui.o
(hopefully it's clear by the name of the .o-files what I want them to contain).
Then the user program would be link with libxrc_handlers.a and the shared
objects that are wanted. (I.e. if the user code uses XRC handler for richtext,
xrc_richtext.o is linked in and both richtext and xrc shared objects are
required, if the used code doesn't use that handler, the linker drops
xrc_richtext.o and the shared objects are not required).
> and, especially, how is this supposed to work for Linux/Unix packages which
> typically contain shared libraries only for ease of updating?
By making an "untypical" package (putting a static library in a -devel package
shouldn't be to bad, IMVHO)? I.e. I don't really have a good answer for that
one - it's surely going to look somewhat strange ... :-(
Regards,
Stefan
Vadim Zeitlin
> I'd create e.g. a libxrc_handlers.a containing xrc_richtext.o and xrc_aui.o
> (hopefully it's clear by the name of the .o-files what I want them to contain).
> Then the user program would be link with libxrc_handlers.a and the shared
> objects that are wanted. (I.e. if the user code uses XRC handler for richtext,
> xrc_richtext.o is linked in and both richtext and xrc shared objects are
> required, if the used code doesn't use that handler, the linker drops
> xrc_richtext.o and the shared objects are not required).
This relies on linker being smart enough to realized that it doesn't need
the symbols referenced by the static library. I am not sure if all of them
do this.
Also, this solution doesn't take care of xrc/adv or html dependencies
unless we extract their handlers into this static blob too but this is not
a good idea as it would require everybody changing their project files
under Windows (where there is no wx-config). And if we want to go this
route I'd probably prefer to use extra xrc_adv, xrc_html, xrc_aui &c
libraries. But to be honest I am not prepared to do either...
Regards,
VZ
Vaclav Slavik
> This relies on linker being smart enough to realized that it doesn't need
> the symbols referenced by the static library. I am not sure if all of them
> do this.
Other disadvantages of this approach aside, *all* linkers in common use
are smart enough to do this correctly. I'm not aware of any linker that
wouldn't pull only referenced object files from a static library and
ignore the rest of its content.
Vaclav
Steve Lamerton
>
> VS> Another solution would be to move XRC handlers into the same DLL that
> VS> contains the controls. XRC handlers themselves are each relatively
> VS> small, non-trivial loading code is mostly in xmlres.cpp and wxXml.
>
> I think this is the only solution we have. Unless you count putting them
> fully inline as a solution.
separate libraries preferable, such as:
xrc_common
xrc_core
xrc_adv
xrc_html
xrc_richtext
I finally have some time to work on this patch again, so whatever is
decided I am quite happy to try and write a patch for it. I personally
prefer the separate libraries, but only because I think it would be
easier to write ;)
Vadim Zeitlin
SL>
SL> On Jun 14, 2:56 pm, Vadim Zeitlin <va...@wxwidgets.org> wrote:
SL> > On Sun, 14 Jun 2009 11:22:43 +0200 Vaclav Slavik <vsla...@fastmail.fm> wrote:
SL> >
SL> > VS> Another solution would be to move XRC handlers into the same DLL that
SL> > VS> contains the controls. XRC handlers themselves are each relatively
SL> > VS> small, non-trivial loading code is mostly in xmlres.cpp and wxXml.
SL> >
SL> > I think this is the only solution we have. Unless you count putting them
SL> > fully inline as a solution.
SL>
SL> So is this the preferred solution for everyone, or are a set of
SL> separate libraries preferable, such as:
SL>
SL> xrc_common
SL> xrc_core
SL> xrc_adv
SL> xrc_html
SL> xrc_richtext
I don't think this is going to be maintenable so Vaclav's solution is
still the least of all evils.
SL> I finally have some time to work on this patch again, so whatever is
SL> decided I am quite happy to try and write a patch for it. I personally
SL> prefer the separate libraries, but only because I think it would be
SL> easier to write ;)
You're probably right but it's going to be more difficult to maintain in
the future...
Regards,
VZ
Steve Lamerton
how best to create the proxy class that is needed, are there any other
examples in the wx source?
Thanks
Steve
On Jun 27, 10:36 pm, Vadim Zeitlin <va...@wxwidgets.org> wrote:
> < 1KViewDownload
Vadim Zeitlin
SL> Ok, I am going to try and give this a go, I guess my only question is
SL> how best to create the proxy class that is needed, are there any other
SL> examples in the wx source?
Unfortunately I don't think so, this would be the first time we're trying
to do anything like this.
Good luck and please don't hesitate to post here if you have questions!
VZ
Steve Lamerton
all of the handlers around and I was wondering why we can't just move
the xml stuff into core and only compile it when USE_XRC is defined?
That way the dependencies wouldn't be a problem as all of the GUI
libraries rely on core, and it means we won't need the proxy class.
Also if it is only compiled when USE_XRC is defined then surely core
wouldn't be any larger for people who don't use it. I suspect there
is a really obvious reason why not though ;)
Thanks in advance
Steve
On Jun 30, 2:59 pm, Vadim Zeitlin <va...@wxwidgets.org> wrote:
>
> SL> Ok, I am going to try and give this a go, I guess my only question is
> SL> how best to create the proxy class that is needed, are there any other
> SL> examples in the wx source?
>
> Unfortunately I don't think so, this would be the first time we're trying
> to do anything like this.
>
> Good luck and please don't hesitate to post here if you have questions!
> VZ
>
> < 1KViewDownload
Vadim Zeitlin
SL> So I have been thinking about this for a little while whilst shuffling
SL> all of the handlers around and I was wondering why we can't just move
SL> the xml stuff into core and only compile it when USE_XRC is defined?
We'd really like to avoid having multiple builds of the library. And the
one and true official build will surely have wxUSE_XRC=1 so basically this
means that we'd just move XRC entirely into the core.
This is definitely the simplest solution but the last time we discussed it
we still thought that allowing to avoid the XRC overhead for people who
don't use it was nice.
Regards,
VZ
Steve Lamerton
haven't ever written anything like this I am afraid, but I would love
to learn! So at the moment the files are organised like this:
XRC:
[All of the handlers]
xmlres.cpp (Which implements xmlresource and xmlresourcehandler)
After the reorganisation I think it should be something like this:
CORE:
[The handlers for core widgets]
xmlres.cpp (xmlresourcehandler, a proxy to xmlresourcehandlerimpl)
ADV/RICHTEXT/AUI:
[The respective handlers]
XRC:
xmlresimpl.cpp (xmlresourcehandlerimpl and xmlresource)
My question really is what should live in the xmlres in core and what
should live in xmlresimpl in xrc. All of the handlers will rely on the
new proxy class in xmlres in core. However I can't really see how to
link this with the implementation in xrc. I guess in xmlres I need to
implement all of the same methods as before and just pass them to the
implementation with a pointer? But for the pointer to compile it will
need to know what it is pointing to, so surely then core would rely on
xrc? A pointer (no pun intended) to what I need to do would be hugely
appreciated!
Thanks in advance
Steve
Vadim Zeitlin
SL> I hope I don't seem annoying here, but I have another question, I
SL> haven't ever written anything like this I am afraid,
I think nobody did...
SL> XRC:
SL> [All of the handlers]
SL> xmlres.cpp (Which implements xmlresource and xmlresourcehandler)
SL>
SL> After the reorganisation I think it should be something like this:
SL>
SL> CORE:
SL> [The handlers for core widgets]
SL> xmlres.cpp (xmlresourcehandler, a proxy to xmlresourcehandlerimpl)
SL>
SL> ADV/RICHTEXT/AUI:
SL> [The respective handlers]
SL>
SL> XRC:
SL> xmlresimpl.cpp (xmlresourcehandlerimpl and xmlresource)
No, the handlers for the core widgets should remain in XRC library, there
is no point in putting them in core (as we do all this to keep as much of
XRC as possible outside it!).
SL> My question really is what should live in the xmlres in core and what
SL> should live in xmlresimpl in xrc.
There should be almost nothing in core, it should just defined an abstract
interface for wxXmlResource and a function to return a pointer to [an
object implementing] it. If xrc library is not linked in, this function
would return NULL indicating that no XRC support is available. If xrc is
used then it should return a pointer to the real wxXmlResource object.
SL> But for the pointer to compile it will need to know what it is pointing
SL> to, so surely then core would rely on xrc?
No, we could still work with pointers to wxXmlResource (which would become
an ABC) without defining wxXmlResourceImpl (which the current wxXmlResource
will be renamed to) in core itself.
Regards,
VZ