wxruby users - Jan 2004 - Wx::ListCtrl#get_item method

Hi guys!

I have a question (or a request?) on Wx::ListCtrl#get_item method.
As you can see in the wxWindows reference, wxListCtrl::GetItem method of
C++ is different from that of wxPython.

C++
  return value: boolean
  argument: wxListItem& info
wxPython
  return value: wxListItem
  arguments:  int ID, int column (optional)

How about wxruby?
>From the wxruby source code, wxruby looks similar to C++. However
I''m
not sure of that due to lack of my C++ skills.

Anyway, I think wxPython-like method is better for wxruby. How do you
think?

-- 
Nobuaki Arima <narima1109@hotmail.com>

Nobuaki Arima wrote:
> I have a question (or a request?) on Wx::ListCtrl#get_item method.
> Anyway, I think wxPython-like method is better for wxruby. How do you
> think?
I agree with you that it seems wxRuby currently uses an interface like 
the C++ api. (I didn''t write that code). And I also agree that the 
wxPython (and wxPerl) approach would be cleaner and easier to use.

For backward compatibility, we should probably support either signature, 
although that is a pain. Perhaps we could detect attempts to use the C++ 
style and raise an exception, at least.

I am not sure this can get in to the upcoming 0.2 release, but if 
someone sends me a tested patch it might.

Thanks,

Kevin

On Jan 15, 2004, at 12:21, Kevin Smith wrote:
> Nobuaki Arima wrote:
>> I have a question (or a request?) on Wx::ListCtrl#get_item method.
>
>> Anyway, I think wxPython-like method is better for wxruby. How do you
>> think?
>
> I agree with you that it seems wxRuby currently uses an interface like 
> the C++ api. (I didn''t write that code). And I also agree that the
> wxPython (and wxPerl) approach would be cleaner and easier to use.
>
> For backward compatibility, we should probably support either 
> signature, although that is a pain. Perhaps we could detect attempts 
> to use the C++ style and raise an exception, at least.
My personal opinion is that worrying about backwards compatibility is a 
distraction until a project reaches 1.0. The API for wxRuby is going to 
need to change and evolve as it grows in to a mature binding, and that 
maturing process can happen a lot faster if the developers aren''t 
having to worry about breaking backwards compatibility. I personally 
expect and even welcome API changes in projects that are in 
development, because I like to know that things are improving.

I guess, as a wxRuby consumer, I don''t want development slowed down at 
this point by backwards compatibility concerns. I want those working on 
it to be able to "Code like the wind". :-)

Just my $0.02,


Nathaniel

<:((><

I agree, really.  I don''t think anyone expects 
backwards compatibility from a 0.1 to a 0.2 release...

H

On Thu, 2004-01-15 at 17:56, Nathaniel Talbott wrote:
> My personal opinion is that worrying about backwards compatibility is a 
> distraction until a project reaches 1.0. The API for wxRuby is going to 
> need to change and evolve as it grows in to a mature binding, and that 
> maturing process can happen a lot faster if the developers aren''t 
> having to worry about breaking backwards compatibility. I personally 
> expect and even welcome API changes in projects that are in 
> development, because I like to know that things are improving.
> 
> I guess, as a wxRuby consumer, I don''t want development slowed
down at
> this point by backwards compatibility concerns. I want those working on 
> it to be able to "Code like the wind". :-)
> 
> Just my $0.02,
> 
> 
> Nathaniel
>

Nobuaki Arima wrote:
> I tentatively revised Wx::ListCtrl#get_item method to use the
> wxPython-type API. 
Thanks for submitting this code. I have checked in changes to wxRuby 
that implement ListCtrl#get_item to match the wxPython way.

I ended up not using the actual C++ code you submitted, but it was 
helpful as a guideline. And it really helped that you created a 
corresponding ruby sample that I could run to make sure it works.

In this case, the memory handling was tricky, so I ended up creating a 
wxRuby ListItem to hold the information, rather than trying to do it 
with a native C++ object. That is the main difference between your code 
and mine.

If the internal get_item fails (returns false), I just return a nil 
object. I think that''s easier than raising an exception, but it would
be
interesting to know what wxPython does in that case.

The sample behaves a little oddly, because apparently the column 1 items 
do not have explicit colors or fonts set. I don''t know for sure that 
wxWindows itself behaves that way, but I can''t see anything that wxRuby
is doing wrong. ListCtrl is always confusing for me.

Let me know if you find any problems with this, and thanks again for 
your contribution.

Kevin

I know you are going away soon, do you still want to do a 0.2 Release before
then? If so, you should probably label the CVS repository and I should do
another windows build to include this change.

Curt


Kevin Smith wrote:
> Sent: Monday, January 26, 2004 11:48 PM
> To: Nobuaki Arima; Wxruby developers'' list
> Subject: Re: [Wxruby-users] Wx::ListCtrl#get_item method
>
>
> Nobuaki Arima wrote:
> > I tentatively revised Wx::ListCtrl#get_item method to use the
> > wxPython-type API.
>
> Thanks for submitting this code. I have checked in changes to wxRuby
> that implement ListCtrl#get_item to match the wxPython way.
>
> I ended up not using the actual C++ code you submitted, but it was
> helpful as a guideline. And it really helped that you created a
> corresponding ruby sample that I could run to make sure it works.
>
> In this case, the memory handling was tricky, so I ended up creating a
> wxRuby ListItem to hold the information, rather than trying to do it
> with a native C++ object. That is the main difference between your code
> and mine.
>
> If the internal get_item fails (returns false), I just return a nil
> object. I think that''s easier than raising an exception, but it
would be
> interesting to know what wxPython does in that case.
>
> The sample behaves a little oddly, because apparently the column 1 items
> do not have explicit colors or fonts set. I don''t know for sure
that
> wxWindows itself behaves that way, but I can''t see anything that
wxRuby
> is doing wrong. ListCtrl is always confusing for me.
>
> Let me know if you find any problems with this, and thanks again for
> your contribution.
>
> Kevin
> _______________________________________________
> wxruby-users mailing list
> wxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.566 / Virus Database: 357 - Release Date: 1/22/2004
>

Curt Hibbs wrote:
> I know you are going away soon, do you still want to do a 0.2 Release
before
> then? If so, you should probably label the CVS repository and I should do
> another windows build to include this change.
Yes, I do still want to do the 0.2 release before I go. Unfortunately, 
now I am a bit sick.

I was originally thinking that I would need to put together a Linux 
binary, and then freeze the source code, and then we would do
"official"
binary builds for the three platforms (Linux, Windwos, OS X).

Now, however, I can see value in having a 0.2 release that doesn''t have
Linux binaries. The most important binary platform is Windows, and the 
next most important is OS X. I could always contribute the corresponding 
Linux binary package after I get back (in March).

So: Nick: If you have a patch you want included, please send it right 
away. After that, I won''t make any more code changes before the
release.
Should we check the binaries in to CVS?

This is all very interesting to me, since I have never coordinated a 
distributed cross-platform release before.

Thanks,

Kevin

Kevin Smith wrote:
>
> Now, however, I can see value in having a 0.2 release that doesn''t
have
> Linux binaries. The most important binary platform is Windows, and the
> next most important is OS X. I could always contribute the corresponding
> Linux binary package after I get back (in March).
>
> So: Nick: If you have a patch you want included, please send it right
> away. After that, I won''t make any more code changes before the
release.
Let me know when you labeled the cvs repo for the 0.2 release, and then I
will do a final windows build.
> Should we check the binaries in to CVS?
No, the packed releases should simply upload it to the files section on
RubyForge.

Curt

I''ll test today, and send you a patch tonight.

Nick

Kevin Smith wrote:
> Curt Hibbs wrote:
>
>> I know you are going away soon, do you still want to do a 0.2 Release 
>> before
>> then? If so, you should probably label the CVS repository and I 
>> should do
>> another windows build to include this change.
>
>
> Yes, I do still want to do the 0.2 release before I go. Unfortunately, 
> now I am a bit sick.
>
> I was originally thinking that I would need to put together a Linux 
> binary, and then freeze the source code, and then we would do 
> "official" binary builds for the three platforms (Linux, Windwos,
OS X).
>
> Now, however, I can see value in having a 0.2 release that doesn''t
> have Linux binaries. The most important binary platform is Windows, 
> and the next most important is OS X. I could always contribute the 
> corresponding Linux binary package after I get back (in March).
>
> So: Nick: If you have a patch you want included, please send it right 
> away. After that, I won''t make any more code changes before the 
> release. Should we check the binaries in to CVS?
>
> This is all very interesting to me, since I have never coordinated a 
> distributed cross-platform release before.
>
> Thanks,
>
> Kevin
> _______________________________________________
> wxruby-users mailing list
> wxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>

Curt Hibbs wrote:
> Let me know when you labeled the cvs repo for the 0.2 release, and then I
> will do a final windows build.
Well, I have good news and bad news.

The bad news is that I''m waiting to hear from Nick to make sure the Mac
stuff is ok before tagging the tree. The other bad news is that I have 
not yet prepared to do a linux binary release with 0.2.

But the good news is that we can still do the release, because I got my 
laptop configured to be able to do cvs and building. So I can work on it 
while I''m on vacation. And, as I mentioned, I consider the Linux binary
to be optional for the moment.

I''ll be traveling all day Tuesday, so assuming everything
doesn''t fall
in to place tomorrow, I''ll plan to work on the release later this week.

Sorry about the delays. I think I''m making progress toward having more 
time to work on wxruby in the future, though.

Kevin

> The bad news is that I''m waiting to hear from Nick to make sure
the
> Mac stuff is ok before tagging the tree.
<blush> Oh, oops.... sorry about that </blush>

It''s now just a matter of wrapping it in an installer and putting a bow
on top. I''ll put up a binary as soon as I can.

Nick



Kevin Smith wrote:
> Curt Hibbs wrote:
>
>> Let me know when you labeled the cvs repo for the 0.2 release, and 
>> then I
>> will do a final windows build.
>
>
> Well, I have good news and bad news.
>
> The bad news is that I''m waiting to hear from Nick to make sure
the
> Mac stuff is ok before tagging the tree. The other bad news is that I 
> have not yet prepared to do a linux binary release with 0.2.
>
> But the good news is that we can still do the release, because I got 
> my laptop configured to be able to do cvs and building. So I can work 
> on it while I''m on vacation. And, as I mentioned, I consider the
Linux
> binary to be optional for the moment.
>
> I''ll be traveling all day Tuesday, so assuming everything
doesn''t fall
> in to place tomorrow, I''ll plan to work on the release later this
week.
>
> Sorry about the delays. I think I''m making progress toward having
more
> time to work on wxruby in the future, though.
>
> Kevin
> _______________________________________________
> wxruby-users mailing list
> wxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>