Hi all Just a quick update on recent SVN activity: * added Sound and CollapsiblePane classes * added the XRC tool to wxSugar * fixed some XRC bugs in Window * added syntax sugar for event handlers and list-like controls * added some missing methods in Sizer Sean - I''m away for about 10 days from this weekend, and I''m thinking of doing a 1.9.2 release in the next day or two. Let me know what you think - if so, I''ll look to tag and do the release on thursday, and we can trickle the builds on over the weekend. But not a problem to leave it I think as there aren''t any critical bug fixes. Alex
2007/9/26, Alex Fenton <alex at pressure.to>:> Hi all > > Just a quick update on recent SVN activity: > > * added Sound and CollapsiblePane classes > * added the XRC tool to wxSugarWill such a tool generate wxRuby code from an XRC file ? If this is the case, this is absolutely great. But why put it in wxSugar ? I thought that wxSugar is for syntatic sugar addition.> * added syntax sugar for event handlers and list-like controlsMost (all ?) parts of wxSugar is now integrated in wxRuby (each, improved event handling). If I just want to use this XRC tool : - do I have to require wxSugar ? - will there be incompatibilities with deprecated wxSugar additions and my code that uses wxRuby new additions (each on ControlWithItems ...) ? Cheers. Chauk-Mean. PS : I don''t forget to do my documentation contribution.
Chauk-Mean P wrote:> 2007/9/26, Alex Fenton <alex at pressure.to>: >> >> * added the XRC tool to wxSugar >> > > Will such a tool generate wxRuby code from an XRC file ? >Yes, it''s a command-line tool that parses XRC and generates ruby classes with the initialisation code and accessor methods for the controls contained within the Frame/Dialog/Panel, possibly extending those with ruby Modules. Event handling can then be implemented in classes inheriting from these auto-generated classes. I''m finding it works really nicely and speeds development - I never used to use XRC but am now a convert.> But why put it in wxSugar ? > I thought that wxSugar is for syntatic sugar addition. >WxSugar is a testing place for extensions of various sorts. If the XRC tool is liked and stable, we can look at shipping it with core instead. The reason for not putting it in core wxRuby in the first place is that there''s a reasonable guarantee that things added there will stay stable between releases. The tool needs a bit of testing and feedback before we know that. In practice, ideas first tried out in wxSugar (eg the event handling stuff) have been tweaked in the light of experience before being put in core.> Most (all ?) parts of wxSugar is now integrated in wxRuby (each, > improved event handling). If I just want to use this XRC tool : > - do I have to require wxSugar ? >No. The code generated is vanilla wxRuby, and doesn''t depend on wxSugar. For the time being, you''ll just need to install wxSugar to install the command-line tool (''xrcise''). Here''s an example (from Weft QDA) of the generated code: http://weft-qda.rubyforge.org/svn/trunk/weft-qda/lib/weft/wxgui/base.rb And an event-implementing class http://weft-qda.rubyforge.org/svn/trunk/weft-qda/lib/weft/wxgui/inspectors/search.rb> - will there be incompatibilities with deprecated wxSugar additions > and my code that uses wxRuby new additions (each on ControlWithItems > ...) ? >We''ll try to minimise it by gradually deprecating bits of wxSugar that are now in core, but it shouldn''t be a problem, for the reasons above. cheers alex
2007/9/26, Alex Fenton <alex at pressure.to>:> Chauk-Mean P wrote: > > 2007/9/26, Alex Fenton <alex at pressure.to>: > >> > >> * added the XRC tool to wxSugar > >> > > > > Will such a tool generate wxRuby code from an XRC file ? > > > Yes, it''s a command-line tool that parses XRC and generates ruby classes > with the initialisation code and accessor methods for the controls > contained within the Frame/Dialog/Panel, possibly extending those with > ruby Modules. Event handling can then be implemented in classes > inheriting from these auto-generated classes. I''m finding it works > really nicely and speeds development - I never used to use XRC but am > now a convert.> Here''s an example (from Weft QDA) of the > generated code: > http://weft-qda.rubyforge.org/svn/trunk/weft-qda/lib/weft/wxgui/base.rb > And an event-implementing class > http://weft-qda.rubyforge.org/svn/trunk/weft-qda/lib/weft/wxgui/inspectors/search.rbI see. What I expected was the "real" wxRuby code corresponding to the XRC file and not only the initialization code for using the XRC file. I''m using wxFormBuilder which can produce both XRC and C++ code. The generated C++ code is the "real" C++ code corresponding to the GUI elements of the XRC file. I find it very useful to see the resulting C++ file but I really prefer seeing the wxRuby code. I also felt the need to ease the use of XRC file. But I was considering a more dynamic approach without code generation. Cheers. Chauk-Mean.
> Sean - I''m away for about 10 days from this weekend, and I''m thinking of > doing a 1.9.2 release in the next day or two. Let me know what you think > - if so, I''ll look to tag and do the release on thursday, and we can > trickle the builds on over the weekend. But not a problem to leave it I > think as there aren''t any critical bug fixes.I''m fine with doing a release soon. Lately I have not had a chance to test any of the new features you have added, I hope to have a chance tomorrow. On a somewhat related note do you have a todo list you are working off of or are these fixes related to bugs/missing items you have come across? If you do have a list of some type can you throw it up on the wiki? Having a list might get me in gear to fix a few things. Thanks Sean
Chauk-Mean P wrote:> I see. > > What I expected was the "real" wxRuby code corresponding to the XRC > file and not only the initialization code for using the XRC file. > I''m using wxFormBuilder which can produce both XRC and C++ code. > The generated C++ code is the "real" C++ code corresponding to the GUI > elements of the XRC file. I find it very useful to see the resulting > C++ file but I really prefer seeing the wxRuby code. > > I also felt the need to ease the use of XRC file. But I was > considering a more dynamic approach without code generation. > > Cheers. > > Chauk-Mean. >Hello Chauk-Mean, The reason why the xrcise tool will only write a wrapper around the xrc file, is cause it''s meant to do just that, write a wrapper, not generate the actual ruby code for the GUI being represented in the xrc file. That is actually better left to a IDE to generate the code. Which is what I''m going to be working on, once I get wxSocket impelemented. Creating a full fledged IDE, that will have Editor, and GUI Builder, for wxRuby. It''ll be mainly geared towards wxRuby, but will allow you to write any Ruby code you want. Hopefully soon, I''ll have something out for wxSocket, so that I can start work on wxRIDE, which will be in no way associated with FreeRIDE. L8ers, Mario Steele
Sean Long wrote:> I''m fine with doing a release soon. Lately I have not had a chance to > test any of the new features you have added, I hope to have a chance > tomorrow. >Thanks. I got swamped with work so haven''t had time to do any pre-release testing esp on MSW. If it''s OK with you, let''s look to do a release week after next (c 8 Oct) when I''m back.> On a somewhat related note do you have a todo list you are working off > of or are these fixes related to bugs/missing items you have come > across? If you do have a list of some type can you throw it up on the > wiki?I''ve been a bit haphazard, sorry - it''s mainly been stuff thrown up by doing my own development on Weft (eg probs with XRC and Window methods), and by integrating the syntax additions (eg Menu#insert return values). If I''ve spotted odd useful GUI classes that are easy to add, I''ve tried to do those too. Happily, I don''t think we have masses left to do for a reasonable 2.0. Roughly speaking: * The bug list. Erk. The most serious I think are crashes on exit in the activation sample, which seems to be down to Wx posting events to dead windows. * Tidy up some of the messier samples, provide more "new" syntax examples, and include some classes that aren''t there at the mo * Need to look into GC marking client_data in ruby (not C++) subclasses of Wx::CommandEvent * At the moment, there are lots of virtual methods in Window which generate a lot of seemingly useless director methods in all subclasses (eg GetScrollThumb). I want to see if we can reduce bloat by nodirector-ing these. * It''d be good to experiment with taking %trackobjects off Point and Size and treating them as throwaway objects (eg creating a new memory management strategy GC_MANAGE_AS_FUNGIBLE_OBJECT). I think this might improve performance slightly both on object creation and at GC phase. * I have an new rakefile which does more accurate dependency handling (eg of swig/shared files), but need to ensure it works on Windows and OS X as well before I check it in. That''s about it ... plus anything else you''d like to see tweaked or fixed ... will probably not be looking at emails much for the next week or so. cheers alex
Chauk-Mean P wrote:> What I expected was the "real" wxRuby code corresponding to the XRC > file and not only the initialization code for using the XRC file.I agree this is nicer, and quite do-able - just a bit more tricky to implement. However it should be possible to use the class-ctor information in lib/wx/keywords_defs.rb to figure out the correct way to initialize anything that''s in an XRC file. It would be a step towards fuller IDE integration, but at the level we''re at, "real" ruby code probably isn''t any more practically useful than writing the boilerplate XRC-loading code... cheers alex