I know it''s been a few weeks since Nick asked me to work on new wxRuby document output from the xml file in the wxruby-swig source tree. So I''m updating the list so you know that it is underway. A new wxRuby API is coming!! I have the parsing complete, and I am trying to make this be most-beneficial to the wxRuby community. Perhaps someone reading this may have an opinion, idea or insight that will help. Here''s the direction I have/am moving in... - Extract the classes from the xml file into individual class text files in a generic format - Read in cpp files for all rb_define* statements and create a map of ruby methods to c++ methods. This will be intelligent, because methods are named with the convention "_wrap_className_methodName". (If this convention isn''t universal Nick, could you give me a heads up) - Generate Html files. While generating files, filtering the c++ methods, and putting in ruby method/class names. (There will be references to the c++ class/method names, and I am planning on linking to the online wxWindows documentation for easy reference if needed) - Generate index files for frame-based navigation As of now I am planning on the navigation to be similar to the output of the Java API (or any javadoc output for that matter) Some areas I''m looking for more input: - Possibly writing dummy ruby source files and inserting the wxruby documentation from the api where necessary to generate proper rdoc output. Then writing a rdoc generator to alter the appearance to be more or a javadoc like output. - Writing my own html files and output format in order to get the docs out quicker, still javadoc-like output Any input is greatly appreciated. Thanks! Zach
> I know it''s been a few weeks since Nick asked me to work on new wxRuby> document output from the xml file in the wxruby-swig source tree. So I''m > updating the list so you know that it is underway. A new wxRuby API is > coming!! Thats great news Zach. > - Read in cpp files for all rb_define* statements and create a map of > ruby methods to c++ methods. This will be intelligent, because methods > are named with the convention "_wrap_className_methodName". (If this > convention isn''t universal Nick, could you give me a heads up) > That''s swig''s convention as far as I know. I''m glad you''re doing that step, as there are a number of methods that don''t translate well. > - Possibly writing dummy ruby source files and inserting the wxruby > documentation from the api where necessary to generate proper rdoc > output. Then writing a rdoc generator to alter the appearance to be more > or a javadoc like output. I always thought that was a good approach, despite my hatred of rubydoc. It sounds like you''ve made a lot of progress. Good work. Nick Zach Dennis wrote:> I know it''s been a few weeks since Nick asked me to work on new wxRuby > document output from the xml file in the wxruby-swig source tree. So I''m > updating the list so you know that it is underway. A new wxRuby API is > coming!! > > I have the parsing complete, and I am trying to make this be > most-beneficial to the wxRuby community. Perhaps someone reading this > may have an opinion, idea or insight that will help. Here''s the > direction I have/am moving in... > > - Extract the classes from the xml file into individual class text files > in a generic format > > - Read in cpp files for all rb_define* statements and create a map of > ruby methods to c++ methods. This will be intelligent, because methods > are named with the convention "_wrap_className_methodName". (If this > convention isn''t universal Nick, could you give me a heads up) > > - Generate Html files. While generating files, filtering the c++ > methods, and putting in ruby method/class names. (There will be > references to the c++ class/method names, and I am planning on linking > to the online wxWindows documentation for easy reference if needed) > > - Generate index files for frame-based navigation > > As of now I am planning on the navigation to be similar to the output of > the Java API (or any javadoc output for that matter) > > Some areas I''m looking for more input: > > - Possibly writing dummy ruby source files and inserting the wxruby > documentation from the api where necessary to generate proper rdoc > output. Then writing a rdoc generator to alter the appearance to be more > or a javadoc like output. > > - Writing my own html files and output format in order to get the docs > out quicker, still javadoc-like output > > Any input is greatly appreciated. Thanks! > > Zach > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > >
Ok another update. Work has been fluxing...so bare with me. - Parsing xml doc into individual class files is complete - Parsing wx windows source for ruby classes, modules, instance methods, singleton methods, module methods, etc.. is complete - recreating ruby source files based on the parsed xml doc and the parsed wx windows source is about 50% Once recreating ruby source files with documentation from the parsed xml doc is complete I will first (test of course) and then create the new rdoc template. If any questions, comments or concerns please feel free to let me know. Also Nick if it would be helpful, I can setup Trac software tracking system on a server. http://www.edgewall.com/trac/ Zach
Zach Dennis wrote:> Ok another update. Work has been fluxing...so bare with me. > > - Parsing xml doc into individual class files is complete > - Parsing wx windows source for ruby classes, modules, instance > methods, singleton methods, module methods, etc.. is complete > - recreating ruby source files based on the parsed xml doc and the > parsed wx windows source is about 50% > > Once recreating ruby source files with documentation from the parsed xml > doc is complete I will first (test of course) and then create the new > rdoc template.Great news, Zach!> If any questions, comments or concerns please feel free to let me know. > Also Nick if it would be helpful, I can setup Trac software tracking > system on a server. http://www.edgewall.com/trac/Rubyforge provides simple tracking, so for now I think we can stick to that. If you think there are some features this has, then I won''t stop you. :-D Nick