Since this has yet to be commented on.....
Let me be the first to say, that this would defiantly be a good thing to
do. This would defiantly make code a lot cleaner, and easier to read
and understand, plus make it easier for the programmer to write stuff
for. If this is defiantly a go for, I will be happy to include this in
the wxSocket code when I''m done. I have finally gotten all the
information I need to make it work. It won''t be as conventional as
what
is being implemented in the C++ side, as it is, shall we say, difficult
to follow the C++ side, within the Ruby side of the code. Therefore,
I''m making a few compromises, and utilizing what is available in wxRuby
to create fully Asynchronous Sockets, that will not block the GUI, which
also includes the ability to do Asynchronous Connects to servers. I
will be leaving UDP, AKA Connect-less connections out of the wxSocket
code that I write for now, till I get a better handle on first dealing
with the Socket connection side, and getting that into the wxRuby code.
I just got the 1.9.1 code, and am excited to see the StyledTextCtrl
available now, and working properly on Windows XP. Good work Alex, and
all those that helped out in getting it together. This is indeed a good
time for wxRuby, which will help to ensure that everything will come
together as we hope for.
Mario Steele
Alex Fenton wrote:> Hi
>
> Given the warm response to the syntax additions in 1.9.1 I''m
considering
> moving one or two more syntax extensions into core, and would like your
> thoughts. Last ones, I promise. Realise we don''t want much more
API
> change now, but also we''ll probably also have to live with
whatever we
> settle on for 2.0 for a little while, so...
>
> 1) Setting up event handlers
>
> In most real apps, I think the most normal way to set up event handlers
> is for the event to be dealt with by a corresponding method. At the
> moment this has to be done using a block:
>
> evt_button(AN_ID) { on_button_click }
> evt_button(my_button.get_id) do | event |
> on_button_click(event)
> end
> evt_size { | event | on_size(event) }
>
> This is a sensible way to organise classes but it seems to have
> redundancy in it. The bigger one is having to create a block, with
> param, just to call a method; the smaller one is having to call a method
> to get a window id. So I''d like to suggest as alternatives:
>
> evt_button(AN_ID, :on_button_click)
> evt_button my_button, :on_button_click
> evt_size :on_size
>
> If a symbol is passed instead of a block, it''s assumed the event
handler
> should call that method in self. Whether or not to pass the event
> handling method an Event argument can be determined by looking at the
> method''s event signature.
>
> If an event handler requires a wx window id to identify which
widget''s
> events are being listened for (as with CommandEvents like evt_button),
> it''s assumed that if a Wx::Window is passed, we want its id.
>
> Code that does this is already in wxSugar - event_connector, but I think
> it would be better to build on the existing evt_xxx syntax than
> introduce a new syntax. This doesn''t break backward compatibility,
and
> isn''t "magic".
>
> 2) ''each'' for list-like classes
>
> This one I''m less bothered about, but I fairly often want to loop
over a
> control with multiple items (eg Choice, ListCtrl, ListBox) to find or
> alter a particular item. So for those classes I wonder if we should add
> an ''each'' method that passes in turn each valid index
into the widget:
>
> listbox.each { | i | set_item_text(i, item_text(i).upcase) }
>
> Or even:
>
> listbox.each { | i | self.item_text[i] = item_text[i].upcase }
>
> Anyway, shout if you love this or hate these...
>
> cheers
> alex
>
>
>
> _______________________________________________
> wxruby-development mailing list
> wxruby-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-development
>
>