In doing my testing I''m wondering if maintaining backwards compatability for existing applications is important. The question boils down to this: Are there sufficient applications that are using wxRuby (pre swig) that we should expect to have to support all/most without changes or should we expect that most applications will need to learn the ''new'' ways things work in wxruby2? Already, existing applications will have to change the require line. Roy
Roy Sutton wrote:> In doing my testing I''m wondering if maintaining backwards compatability > for existing applications is important.I believe a few incompatibilities will be inevitable. I would prefer to keep them to a minimum, and hope to document them well. Have you spotted any glaring incompatibilities so far? The README already lists a handful of relatively minor tweaks. For existing wxruby 0.6 apps, the require ''wx'' thing could be worked around by having a wxruby.rb file that requires ''wx''. However, that wouldn''t fix any incompatibilities, so I don''t really recommend it. It might only be helpful in cases where you *can''t* modify the app source code for some reason. Kevin
Caveat: I haven''t done wxruby related stuff for a while.> > In doing my testing I''m wondering if maintaining backwards compatability > > for existing applications is important. > > I believe a few incompatibilities will be inevitable. I would prefer to > keep them to a minimum, and hope to document them well. Have you spotted > any glaring incompatibilities so far? The README already lists a handful > of relatively minor tweaks.Actually, if you''re going from 0.x to 2.0, it''s better to break as many things as necessary. It''ll be a lot easier now (with an obvious major change) rather than discovering more changes later. Just my two cents. Cheers, Assaph
I''ve made it through about half the old samples (the ones from wxruby). The following samples work just fine (as far as I can tell) on Windows/latest tarball without modifying anything other than the require line: CARET\CARET (Already in wxruby2 samples) ETC\TEST6 ETC\TEST7 ETC\TEST9 ETC\TEST11 ETC\TEST12 ETC\TEST13 ETC\TEST14 ETC\TEST15 ETC\EVENTS ETC\MINIMAL Roy Kevin Smith wrote:> Roy Sutton wrote: > >> In doing my testing I''m wondering if maintaining backwards >> compatability for existing applications is important. > > > I believe a few incompatibilities will be inevitable. I would prefer > to keep them to a minimum, and hope to document them well. Have you > spotted any glaring incompatibilities so far? The README already lists > a handful of relatively minor tweaks. > > For existing wxruby 0.6 apps, the require ''wx'' thing could be worked > around by having a wxruby.rb file that requires ''wx''. However, that > wouldn''t fix any incompatibilities, so I don''t really recommend it. It > might only be helpful in cases where you *can''t* modify the app source > code for some reason. > > Kevin > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > >
Assaph Mehr wrote:> > Actually, if you''re going from 0.x to 2.0, it''s better to break as > many things as necessary. It''ll be a lot easier now (with an obvious > major change) rather than discovering more changes later. > Just my two cents.True. But since this is just a wrapper library, theoretically we shouldn''t need to break much now, or later. We are taking advantage of this shift to jump from wx 2.4 to wx 2.6, and also to rename the shared library files. We''ll also probably drop a few classes that were wrapped in wxRuby 0.6 but have better alternatives available in the ruby standard library. Cheers, Kevin