Hey guys, It''s been awhile, but I''ve put up a new tutorial page on Wx::Frame. It''s the first half of the tutorial on Frame, the rest will come a little later. Let me know what you guys think. Any comments or criticisms are welcome. Let me know what was good and what could have been better, so that future tutorials will be able to incorporate those improvements. Robert Carlin _________________________________________________________________ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1/go/onm00200362ave/direct/01/
Robert Carlin wrote:> > It''s been awhile, but I''ve put up a new tutorial page on Wx::Frame. It''s > the first half of the tutorial on Frame, the rest will come a > little later. > > Let me know what you guys think. Any comments or criticisms are > welcome. > Let me know what was good and what could have been better, so that future > tutorials will be able to incorporate those improvements.I don''t currently have time to go through it in detail (I skimmed through it), so I''ll leave the criticisms up to others. :-) I liked what I saw very much! This is exactly the kind of thing that we need and I really appreciate your taking the time to do this. Tutorials like these will be a significant factor in the success of wxRuby. Curt
Are there any plans to replace the setter/getter methods with Ruby attribute
accessors?
e.g. "tree.set_font font" becomes "tree.font = font"
Also, is there any plan to have the event methods accept a symbol representing
the method to call?
e.g. "evt_button { |event| on_button(event) }" becomes
"evt_button :on_button"
Bill
Robert Carlin wrote:> It''s been awhile, but I''ve put up a new tutorial page on Wx::Frame. > It''s the first half of the tutorial on Frame, the rest will come a > little later.Great stuff. I really appreciate your work on this. It lets me focus on the code itself :-)> Let me know what you guys think. Any comments or criticisms are > welcome. Let me know what was good and what could have been better, so > that future tutorials will be able to incorporate those improvements.My general comment is that I would prefer to see simpler code, especially at the top of each tutorial page. In this case, a simple Frame that sets a single icon might be a gentler introduction. Then, a second version could show the fancy stuff. In the past, I have sometimes been freaked out by GUI frameworks that look too complicated. I don''t want that to happen with wxRuby. Especially with the first few lessons, I think the less we tell people, the better. I would also split the Frame tutorial--probably just shift event handling to a new page. But maybe put styles on its own page as well. Many people work well with small doses of information. Keep up the good work! Kevin
On 2004 May 12, at 23:05, Kevin Smith wrote:> Many people work well with small doses of information.Well-named pages on a topic of interest also play nice with Google. The higher-up the heading, the more relevant the page for searches on that topic. -- Ryan "John" Platte Custom services, NIKA Consulting http://nikaconsulting.com/
>My general comment is that I would prefer to see simpler code, especially >at the top of each tutorial page. In this case, a simple Frame that sets a >single icon might be a gentler introduction. Then, a second version could >show the fancy stuff.Sound good :)>In the past, I have sometimes been freaked out by GUI frameworks that look >too complicated. I don''t want that to happen with wxRuby. Especially with >the first few lessons, I think the less we tell people, the better. > >I would also split the Frame tutorial--probably just shift event handling >to a new page. But maybe put styles on its own page as well. Many people >work well with small doses of information. >You make a good point. This also will work out better for me, because I can focus on smaller chunks as well - it''s a lot harder to try to write a big section like I just did. And that way I can increase the frequency of tutorial sections being added, which will make us look all the more active :) Unless anybody has any objections to splitting the frames tutorial, I will divy the three "main" sections into separate tutorial pages (Icons, Styles and Events). Thanks for the feedback Kevin. Robert _________________________________________________________________ Express yourself with the new version of MSN Messenger! Download today - it''s FREE! http://messenger.msn.com/go/onm00200471ave/direct/01/
Bill Atkins wrote:> Are there any plans to replace the setter/getter methods with Ruby attribute > accessors? > > e.g. "tree.set_font font" becomes "tree.font = font"No specific plans, although we have discussed it. There is some question about whether they should be aliases for the "normal" C++ style, or if they should replace the current approach.> Also, is there any plan to have the event methods accept a symbol representing > the method to call? > > e.g. "evt_button { |event| on_button(event) }" becomes "evt_button :on_button"Hmmm. I don''t personally like that style, although I can see some benefit. My preference would be to keep just the one existing style, but I could be persuaded by an angry mob of users with pitchforks demanding support for both :-) Kevin
On 2004 May 13, at 22:01, Kevin Smith wrote:>> e.g. "evt_button { |event| on_button(event) }" becomes "evt_button >> :on_button" > > Hmmm. I don''t personally like that style, although I can see some > benefit. My preference would be to keep just the one existing style, > but I could be persuaded by an angry mob of users with pitchforks > demanding support for both :-)I''d like to voice a strong second on this idea. Ruby lets us get rid of repetitive template code. That''s one reason we love it so. This kind of shortening cuts out a whole unnecessary branch of thinking while you''re reading the code -- evt_button maps to on_button, move along. You''ve been arguing for simpler code in the tutorials; here''s a way to increase the amount of code that can be dead simple. Whenever there''s something obvious like this, please throw it in. Ruby''s standard library is full of convenient alternate signatures. One more point: if you don''t implement this, merciless refactorers will in their client code, and have that much more overhead to maintain. -- Ryan "John" Platte Custom services, NIKA Consulting http://nikaconsulting.com/
John Platte wrote:> On 2004 May 13, at 22:01, Kevin Smith wrote: > >>> e.g. "evt_button { |event| on_button(event) }" becomes "evt_button >>> :on_button" >> >> >> Hmmm. I don''t personally like that style, although I can see some >> benefit. My preference would be to keep just the one existing style, >> but I could be persuaded by an angry mob of users with pitchforks >> demanding support for both :-) > > You''ve been arguing for simpler code in the tutorials; here''s a > way to increase the amount of code that can be dead simple.Oh, sure. Use my own words against me! :-) Ok. I have added this to the TODO list for the wxruby-swig version. It won''t happen really soon, but it''s on the list. It''s a feature that someone else could probably implement after the wxruby-swig source code becomes our official release. Kevin