[Wxruby-development] Splitting wxRuby2.so into multiple libraries

[Alex Fenton]

Hi Mario

Mario Steele wrote:
> I figured I'd split this off into a seperate discussion, to get an idea of  
> what to look at with this.  Ofcourse, with every first step, there needs  
> to be some kind of outline set forth to split up wxRuby2 into multiple  
> libraries, 
Thanks for this - they're useful notes and I agree with most of what 
you've set out.

>  Also, as a side note, I think the splitting up of wxRuby2  
> into multiple files, to make it modular, will also encourage wrapping of  
> 3rd party controls that have been created for wxWidgets as well.  
That's a good point - I hadn't thought of this. One of wxWidget's 
strengths is the third party controls available.

> The way that  
> it was split across the board, was there was a central file, to store the  
> main stuff needed for wxWidgets to work, you know, Memory Management, main  
> base classes to initialize the Application, so on and so forth.
This corresponds to swig/wx.i + swig/App.i + swig/RubyConstants.i in wxRuby

>  Then each  
> separate control would get it's own file for usage, and then a wrapper  
> type file that basically included all of these files, for thoes that just  
> want it to go, with one include/require.
>   
I'd go for this, or we could bundle groups of related classes into 
compiled groups. The model for the loader wrapper file is lib/wx.rb

One ruby feature that might be potentially very useful is 'autoload'. 
With this users could still only have to require 'wx', but other classes 
would be transparently loaded on demand when they were referenced by code.
>    This will have the main static link of wxWidgets to it, so that the API  
> can be exposed to other loaded modules, which can be dynamically loaded by  
> user request.  Also, in this file, it will contain the main definitions  
> for memory management between Ruby and wxWidgets, as well as the core  
> classes, such as Wx::App, Wx::Events, Wx::Timer, so on and so forth,  
> basically all the classes that do not have a graphical representation.   
>
>   
(and also defining the autoloads for other classes, setting out where 
they are found).

>    A part to keep this from seperating into to many seperate files, Such as  
> one for Wx::Menu, Wx::ToolBar, so on and so forth, it would proabbly be  
> best, to include these classes in Wx::Frame, so as to keep things  
> centralized, and yet still have the modularity.  Seems a bit backwards,  
> but this way, central controls will still remain with the class that they  
> are used primarly for, and ensure no "Split into infinity" occurs.
>   
Agreed. If you've compiled your own wxRuby, it's interesting to look at 
the obj/ directory sorted by size. The biggest is Grid.o, which along 
with the various Grid* events would make a large separate chunk. 
Similarly TextCtrl, TreeCtrl, ListCtrl, HtmlWindow and AuiNotebook, 
which are all heavyweights on that list and have a number of associated 
classes.

The current rework of EvtHandler and the mapping of wx Events to ruby 
objects is one piece of the puzzle that will make it possible to load 
new event-firing classes once an App has started.

> Now, the fun part of this all, is how to get the splitting of the files  
> setup, so that it can work together, and not cause redundancy in the core  
> of wxWidgets be within each seperate library that provides the  
> functionality for said control, and repeating what does not need to be  
> done.  This, I don't have an answer for, cause of two things.  One, I  
> don't know how far down you can break the wxWidgets library to just  
> provide access to these controls, and allow the "Shared Memory Space" of  
> the program, to allow other DLL/SO files to be able to access it.   
>   
Hehe - this is the fun part for me too. I don't know very much at all 
about linkers and linking. I really knew nothing but './configure; make; 
make install' about C++ and compiling before I got involved in wxRuby.

> Secondly, I don't know how SWIG interface works, never worked with it, and  
> I hardly know C/C++ as it is, just enough to get by, and even then it's  
> troublesome at most.  
There's no doubt that SWIG is pretty complex, and learning a little C++ 
has driven me to frustration at times. On the other hand, I'm hoping 
that recent changes have made the build process a bit more standard and 
straightforward.

> One solution that I could think of, is to have  
> wxWidgets as it's own library, then Dynamically link to it, instead of  
> statically linking it into the wxRuby2 SO File.  
>   
I'm not necessarily against this, but I'm very keen that we keep wxRuby 
as a single-step install. Having to install the base GUI library first 
seems to be a source of confusion for new users of Qt and GTK, and not 
having to a perceived strength of wxRuby.

Perhaps we could distribute a wxWidgets monolithic dll/bundle/so with 
the gems that is dynamically linked to?
> With this, I'm just laying out a basic idea of how to split these into  
> seperate parts, and see what people think.  If it's a good idea, if it's a  
> bad idea, what opinions you have, maybe you have a better way.  
As above, I broadly support all that you've suggested. In terms of 
timing, given that we're not 100% sure about the specifics of the 
linking bit in particular, I'm inclined to set this as an objective for 
wxRuby 2.2. I.e. aim to finish what we have now and release as a stable 
2.0, and then break into pieces for the next minor release in a way 
that's compatible (eg using autoload).

cheers
alex