From alex at pressure.to Tue Aug 1 13:41:41 2006 From: alex at pressure.to (Alex Fenton) Date: Tue, 01 Aug 2006 18:41:41 +0100 Subject: [Wxruby-users] SashWindows Message-ID: <44CF9255.4030905@pressure.to> Hi Please find attached a set of patches to implement Sash Layouts plus a little sample. These are resizable panes that can be used to create an IDE-like application, with sidebars etc. They're quite a lot more powerful than SplitterWindow, for example you can split an MDI client window, and you can have lots of them. Not quite as nice as wxAUI (Advanced User Interface) - a project for later ;) cheers alex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wxSashLayoutWindow.h.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060801/b016c112/attachment-0010.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wxSashWindow.h.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060801/b016c112/attachment-0011.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RubyConstants.i.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060801/b016c112/attachment-0012.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: EvtHandler.i.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060801/b016c112/attachment-0013.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Events.i.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060801/b016c112/attachment-0014.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SashWindow.i Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060801/b016c112/attachment-0015.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SashLayoutWindow.i Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060801/b016c112/attachment-0016.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: LayoutAlgorithm.i Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060801/b016c112/attachment-0017.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SashEvent.i Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060801/b016c112/attachment-0018.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sash.rb Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060801/b016c112/attachment-0019.pl From alex at pressure.to Tue Aug 1 13:55:42 2006 From: alex at pressure.to (Alex Fenton) Date: Tue, 01 Aug 2006 18:55:42 +0100 Subject: [Wxruby-users] GenericDirCtrl Message-ID: <44CF959E.9030105@pressure.to> A little patch to add Wx::GenericDirCtrl. A non-native control (on OS X at least) but maybe useful to someone. I have tested it but think it should just be added to controls.rb sample - will do later when i have fixed some other probs with that. Also, I've started putting class-specifc style constants in the relevant .i file, as discussed previosuly - will submit a patch doing this for existing classes down the line. Lastly have added a page to the wiki showing class support by category - looks a lot better for wxruby2 done this way, shows how much of the core GUI api we support now. http://wxruby.rubyforge.org/wiki/wiki.pl?ClassesSupportedByCategory cheers alex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: GenericDirCtrl.i Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060801/f6af7cdc/attachment.pl From roys at mindspring.com Tue Aug 1 15:59:07 2006 From: roys at mindspring.com (Roy Sutton) Date: Tue, 01 Aug 2006 15:59:07 -0400 Subject: [Wxruby-users] GenericDirCtrl In-Reply-To: <44CF959E.9030105@pressure.to> References: <44CF959E.9030105@pressure.to> Message-ID: <44CFB28B.2090406@mindspring.com> Alex Fenton wrote: > Lastly have added a page to the wiki showing class support by category > - looks a lot better for wxruby2 done this way, shows how much of the > core GUI api we support now. > > http://wxruby.rubyforge.org/wiki/wiki.pl?ClassesSupportedByCategory > Very nice. Good work, Alex. Roy From sean.m.long at gmail.com Tue Aug 1 18:25:50 2006 From: sean.m.long at gmail.com (Sean Long) Date: Tue, 1 Aug 2006 15:25:50 -0700 Subject: [Wxruby-users] GenericDirCtrl In-Reply-To: <44CFB28B.2090406@mindspring.com> References: <44CF959E.9030105@pressure.to> <44CFB28B.2090406@mindspring.com> Message-ID: Good stuff Alex. Now we just need to get one of the admins to add all these changes to the CVS HEAD so we do not step on each others changes. I want to do some more work on wxRuby but am worried that I will change stuff that was changed in an uncommitted patch and any subsequent patches will not work once the HEAD is updated (I had this problem in the past and is a pain to deal with). Kevin, Nick or Curt you guys out there? We need an active maintainer on this project to move it forward and I personally think it should be Alex or Roy at the moment. Sean On 8/1/06, Roy Sutton wrote: > Alex Fenton wrote: > > Lastly have added a page to the wiki showing class support by category > > - looks a lot better for wxruby2 done this way, shows how much of the > > core GUI api we support now. > > > > http://wxruby.rubyforge.org/wiki/wiki.pl?ClassesSupportedByCategory > > > Very nice. Good work, Alex. > > Roy > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > From sean.m.long at gmail.com Tue Aug 1 18:49:58 2006 From: sean.m.long at gmail.com (Sean Long) Date: Tue, 1 Aug 2006 15:49:58 -0700 Subject: [Wxruby-users] GenericDirCtrl In-Reply-To: References: <44CF959E.9030105@pressure.to> <44CFB28B.2090406@mindspring.com> Message-ID: Alex, The wiki page is very well done, nice job! Now we have a good place to look for tasks that need to be done. Sean From sean.m.long at gmail.com Tue Aug 1 19:18:54 2006 From: sean.m.long at gmail.com (Sean Long) Date: Tue, 1 Aug 2006 16:18:54 -0700 Subject: [Wxruby-users] additions to wxKeyEvent Message-ID: Added the public variables like m_KeyCode and m_controlDown, these are needed it you want to create your own EVT_CHAR message to send a widget. I am including the whole .h file instead of a diff since it is small. Sean -------------- next part -------------- // Copyright 2004-2006 by Kevin Smith // released under the MIT-style wxruby2 license #if !defined(_wxKeyEvent_h_) #define _wxKeyEvent_h_ class wxKeyEvent : public wxEvent { public: wxKeyEvent(WXTYPE keyEventType ) ; bool AltDown() const; bool ControlDown() const; int GetKeyCode() const; wxUint32 GetRawKeyCode() const; wxUint32 GetRawKeyFlags() const; long GetX() const; long GetY() const; bool MetaDown() const; wxPoint GetPosition() const; void GetPosition(long * x , long * y ) const; bool HasModifiers() const; bool ShiftDown() const; // override pure virtual methods from base classes virtual wxEvent* Clone() const; wxCoord m_x, m_y; long m_keyCode; bool m_controlDown; bool m_shiftDown; bool m_altDown; bool m_metaDown; bool m_scanCode; #if wxUSE_UNICODE // This contains the full Unicode character // in a character events in Unicode mode wxChar m_uniChar; #endif // these fields contain the platform-specific information about // key that was pressed wxUint32 m_rawCode; wxUint32 m_rawFlags; }; #endif From wxruby at qualitycode.com Tue Aug 1 23:53:32 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Tue, 01 Aug 2006 23:53:32 -0400 Subject: [Wxruby-users] Active maintainer (was: GenericDirCtrl) In-Reply-To: References: <44CF959E.9030105@pressure.to> <44CFB28B.2090406@mindspring.com> Message-ID: <1154490812.6207.10.camel@localhost.localdomain> On Tue, 2006-08-01 at 15:25 -0700, Sean Long wrote: > Good stuff Alex. > > Now we just need to get one of the admins to add all these changes to > the CVS HEAD so we do not step on each others changes. > > I want to do some more work on wxRuby but am worried that I will > change stuff that was changed in an uncommitted patch and any > subsequent patches will not work once the HEAD is updated (I had this > problem in the past and is a pain to deal with). > > Kevin, Nick or Curt you guys out there? > > We need an active maintainer on this project to move it forward and I > personally think it should be Alex or Roy at the moment. I'm here...sort of. I keep hoping to find several hours to devote to wxruby, but it keeps not happening. Recently, I haven't even been keeping up with my email. I would be fine with Alex and/or Roy directly updating CVS at this point. The last thing I want to be is a bottleneck. Hopefully I can become more active again when things quiet down here. Alex and Roy: Do you want CVS rights? Curt and others: Any objections? Everyone: Bzr is still my favorite distributed version control system. If we were using it, it would be much easier for many people to contribute code, and the project would be far less dependent on any one person (like me). Is there any interest yet in moving in that direction? Kevin From sean.m.long at gmail.com Wed Aug 2 02:14:47 2006 From: sean.m.long at gmail.com (Sean Long) Date: Tue, 1 Aug 2006 23:14:47 -0700 Subject: [Wxruby-users] Active maintainer (was: GenericDirCtrl) In-Reply-To: <1154490812.6207.10.camel@localhost.localdomain> References: <44CF959E.9030105@pressure.to> <44CFB28B.2090406@mindspring.com> <1154490812.6207.10.camel@localhost.localdomain> Message-ID: > I'm here...sort of. I keep hoping to find several hours to devote to > wxruby, but it keeps not happening. Recently, I haven't even been > keeping up with my email. In a few weeks my wife is due to have our second child and I will probably vanish off the radar as well. > Everyone: Bzr is still my favorite distributed version control system. > If we were using it, it would be much easier for many people to > contribute code, and the project would be far less dependent on any one > person (like me). Is there any interest yet in moving in that > direction? > I am installing it as I write this and it has gotten a lot farther than Darcs on Intel based Mac's, the ghc compiler still does not work on the x86 Mac. After reading the mini intro to Bazaar I think it sounds pretty slick, the push feature looks nice and is something I would probably do with my branch. The mini intro is here: http://bazaar-vcs.org/QuickHackingWithBzr The bazaar web site is designed well and easy to find info on, bonus points for that. Do you have a test repo setup anywhere that I can play with? Sean From sean.m.long at gmail.com Wed Aug 2 04:01:40 2006 From: sean.m.long at gmail.com (Sean Long) Date: Wed, 2 Aug 2006 01:01:40 -0700 Subject: [Wxruby-users] Active maintainer (was: GenericDirCtrl) In-Reply-To: References: <44CF959E.9030105@pressure.to> <44CFB28B.2090406@mindspring.com> <1154490812.6207.10.camel@localhost.localdomain> Message-ID: While looking into bazaar I found this: http://bazaar-vcs.org/BzrForeignBranches/Subversion?action=show&redirect=BzrSvn Which allows Bazaar to interact with a Subversion repo as if it was a Bazaar branch. So we could just move from CVS to SVN (which is straight forward) and people can pull from SVN for the latest HEAD and us developers could use Bazaar for development work. Sean On 8/1/06, Sean Long wrote: > > I'm here...sort of. I keep hoping to find several hours to devote to > > wxruby, but it keeps not happening. Recently, I haven't even been > > keeping up with my email. > > In a few weeks my wife is due to have our second child and I will > probably vanish off the radar as well. > > > Everyone: Bzr is still my favorite distributed version control system. > > If we were using it, it would be much easier for many people to > > contribute code, and the project would be far less dependent on any one > > person (like me). Is there any interest yet in moving in that > > direction? > > > > I am installing it as I write this and it has gotten a lot farther > than Darcs on Intel based Mac's, the ghc compiler still does not work > on the x86 Mac. > > After reading the mini intro to Bazaar I think it sounds pretty slick, > the push feature looks nice and is something I would probably do with > my branch. The mini intro is here: > http://bazaar-vcs.org/QuickHackingWithBzr > > The bazaar web site is designed well and easy to find info on, bonus > points for that. > > Do you have a test repo setup anywhere that I can play with? > > Sean > From alex at pressure.to Wed Aug 2 13:59:44 2006 From: alex at pressure.to (Alex Fenton) Date: Wed, 02 Aug 2006 18:59:44 +0100 Subject: [Wxruby-users] Active maintainer In-Reply-To: <1154490812.6207.10.camel@localhost.localdomain> References: <44CF959E.9030105@pressure.to> <44CFB28B.2090406@mindspring.com> <1154490812.6207.10.camel@localhost.localdomain> Message-ID: <44D0E810.4070800@pressure.to> Hi all Thanks for bringing this up Sean. > I would be fine with Alex and/or Roy directly updating CVS at this > point. The last thing I want to be is a bottleneck. Hopefully I can > become more active again when things quiet down here. > First up, I think Kevin has been doing a great job as maintainer. People here might remember that he came out of Wx::Retirement to move the project forward. But if his time's limited, perhaps routine tending of the CVS tree isn't the best way to use it. I would rather use his extensive experience and knowledge of wxruby to guide big decisions, and tackle tricky probs and help out on the GTK version where poss. > Alex and Roy: Do you want CVS rights? > > Curt and others: Any objections? > I am not keen to start committing core SWIG stuff to the CVS tree without someone else reviewing. Such interface files as I've submitted have been developed by imitation and doggedness rather than any real understanding of hte C++ type system, memory mgmt or SWIg. Plus I think on principle we should try .i patches on at least two platforms before committing. So, is anyone willing and able to review and commit patches to the SWIG stuff? I have a bit more skill in writing english docs and ruby code and I wonder if I should spend more time on this now. It might be useful to have CVS rights so that I can commit docs and low-risk tweaks to samples. As mentioned before, I'm also up for helping to manage bugs and releases if that seems helpful. I suggest that we throw out a binary release based on the tree pretty much as it is now - I'll put this in a separate email. > Everyone: Bzr is still my favorite distributed version control system. > If we were using it, it would be much easier for many people to > contribute code, and the project would be far less dependent on any one > person (like me). Is there any interest yet in moving in that > direction? > I'm a bit lazy about learning new dev tools eg RCS. But I'm up for learning bzr if it would help - I sometimes have to check out a fresh tree and copy changes to keep my patches clean. But presumably we still have to have one core tree? Also, I think we do benefit from the rubyforge hosting of our RCS system - eg viewcvs, statcvs, SSH. Bear in mind that someone might need to host and maintain this for a bzr repository. Thanks alex From alex at pressure.to Wed Aug 2 15:58:45 2006 From: alex at pressure.to (Alex Fenton) Date: Wed, 02 Aug 2006 20:58:45 +0100 Subject: [Wxruby-users] wxruby2 alpha release goals Message-ID: <44D103F5.3030407@pressure.to> Hi We're all keen to get a release out, for lots of reasons: getting more people testing, showing people the progress we've made, etc. So I suggest that we now look to release an alpha version very soon, based pretty much on the current state of CVS plus pending check-ins. Sure, it has some bugs, some missing features and segfaults occasionally - but my experience on OS X suggests it's not horribly worse than 0.6.0, and is lots better in other ways (i18n, additional classes and methods, GTK2 + OS X support). Particularly, I think it's not the end of the world if we don't support all 0.6.0 classes in a first release, and if memory mgmt is not completely sorted. Looking over blogs, newsgroups, mailing lists etc, the main things that people don't seem to like about wxRuby are: 1) Instability, 2) the docs, or lack of, and 3) the API being very C++ish. So I humbly propose the following goals for an alpha release, and am prepared to work on getting these done. But please do disagree with the goals.. A) Fix the samples B) Fix any big-time, regular crashers C) Add some documentation, if possible D) Add some easy, cheap ruby-ification to the API E) Binary gems A) Quite a few of the samples have got a little bit-rotted. We'll make sure each one runs at least and looks correct, even if not every method works. B) Nail crasher bugs that affect lots of code. But I think it's fine, for things like ItemData, to tell people not to use it, rather than trying to fix the difficult memory management problems in full. C) Zach's work from early 2005 on the docs seemed really promising. He seemed to have developed a way of reading SWIG output and headers to make RDoc-ish output. Does anyone have this somewhere? It would be great to supply some rudimentary RDoc with a package. D) I think we can do some things to make the API a bit more Rubyish without having to hack the interface files. Eg. a few lines that alias set_attr, get_attr and is_attr to more ruby-ish attr=(), attr() and attr?(). We can put in better plumbing later ;) E) This is one where we can use help. Suggest we release as source tarball and gems. I'm happy to bundle binaries into platform gems. OS X: Alex. Sean are you able to check on Mactel? Win32: Roy? Curt? anyone? Linux: Kevin? anyone? Hope this sounds like a reasonable way forward - but please disagree. And shout if your manager has just offered you two months off your normal job to workk on wxruby ;) cheers alex From roys at mindspring.com Wed Aug 2 16:04:38 2006 From: roys at mindspring.com (Roy Sutton) Date: Wed, 02 Aug 2006 16:04:38 -0400 Subject: [Wxruby-users] Active maintainer In-Reply-To: <44D0E810.4070800@pressure.to> References: <44CF959E.9030105@pressure.to> <44CFB28B.2090406@mindspring.com> <1154490812.6207.10.camel@localhost.localdomain> <44D0E810.4070800@pressure.to> Message-ID: <44D10556.9000201@mindspring.com> I'm going to echo Alex's sentiments here. I'm quite up to my eyeballs at the moment, too. I would be happy to pitch in and commit changes. But I'm much happier committing someone else's changes than my own. As long as we have two sets of eyes on each change I think anyone can do the commits. I haven't played with Bzr either but I can do whatever. It's just more bytes on the hard drive as far as I'm concerned. Roy Alex Fenton wrote: > Hi all > > Thanks for bringing this up Sean. > >> I would be fine with Alex and/or Roy directly updating CVS at this >> point. The last thing I want to be is a bottleneck. Hopefully I can >> become more active again when things quiet down here. >> >> > First up, I think Kevin has been doing a great job as maintainer. People > here might remember that he came out of Wx::Retirement to move the > project forward. But if his time's limited, perhaps routine tending of > the CVS tree isn't the best way to use it. I would rather use his > extensive experience and knowledge of wxruby to guide big decisions, and > tackle tricky probs and help out on the GTK version where poss. > >> Alex and Roy: Do you want CVS rights? >> >> Curt and others: Any objections? >> >> > I am not keen to start committing core SWIG stuff to the CVS tree > without someone else reviewing. Such interface files as I've submitted > have been developed by imitation and doggedness rather than any real > understanding of hte C++ type system, memory mgmt or SWIg. Plus I think > on principle we should try .i patches on at least two platforms before > committing. > > So, is anyone willing and able to review and commit patches to the SWIG > stuff? > > I have a bit more skill in writing english docs and ruby code and I > wonder if I should spend more time on this now. It might be useful to > have CVS rights so that I can commit docs and low-risk tweaks to samples. > > As mentioned before, I'm also up for helping to manage bugs and releases > if that seems helpful. I suggest that we throw out a binary release > based on the tree pretty much as it is now - I'll put this in a separate > email. > >> Everyone: Bzr is still my favorite distributed version control system. >> If we were using it, it would be much easier for many people to >> contribute code, and the project would be far less dependent on any one >> person (like me). Is there any interest yet in moving in that >> direction? >> >> > I'm a bit lazy about learning new dev tools eg RCS. But I'm up for > learning bzr if it would help - I sometimes have to check out a fresh > tree and copy changes to keep my patches clean. But presumably we still > have to have one core tree? Also, I think we do benefit from the > rubyforge hosting of our RCS system - eg viewcvs, statcvs, SSH. Bear in > mind that someone might need to host and maintain this for a bzr repository. > > Thanks > alex > > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > From sean.m.long at gmail.com Wed Aug 2 17:21:49 2006 From: sean.m.long at gmail.com (Sean Long) Date: Wed, 2 Aug 2006 14:21:49 -0700 Subject: [Wxruby-users] wxruby2 alpha release goals In-Reply-To: <44D103F5.3030407@pressure.to> References: <44D103F5.3030407@pressure.to> Message-ID: > So I suggest that we now look to release an alpha version very soon, based > pretty much on the current state of CVS plus pending check-ins. Sounds good to me, I am using that code base for a custom in house program that is used nearly every day. > Sure, it has some bugs, some missing features and segfaults occasionally The most annoying bug I have is that pre built dialogs are starting out with a negative x value for the dialog location and are not being shown on screen when show() is called. An example of this is in the caret sample when Wx::message_box() is called for the about box as well as when Wx::get_number_from_user() is called. This problem exists on Mac OS X Intel and PPC. > A) Fix the samples Consistent structure and style across all of them would be nice. > B) Fix any big-time, regular crashers Using Wx::GridCellBoolRender in a Wx::Grid crashes for me, have not bothered to look into it too much. > C) Add some documentation, if possible I am pretty happy just using the standard wxWidgets HTML documentation and knowing the naming rules for wxRuby. - classes like wxDialog become Wx::Dialog - methods like ShowModal() become show_modal() - enums and constants like wxDefaultPosition become Wx::DEFAULT_POSITION - etc. Maybe we should just document the parts that stray from the C++ interface, like the wxWidgets docs do for wxPython and wxPerl. > D) Add some easy, cheap ruby-ification to the API I think for the first version we should leave this out and just try to get a release under our belt. We can add it on later easy enough. > E) Binary gems I can help here by creating one for Mac OS X 10.4 PPC and Intel as long as someone with more experience creates the gem spec. I also have Ubuntu & Windows XP virtualized under Parallels on the Intel Mac so I could help there if I have time. I also think we should rip out all the comment fragments from the include files, they are leftover from long ago the new classes added do not have them. > And shout if your manager has just offered you two months off your > normal job to workk on wxruby ;) I wish :) Sean From empower at smart.net Wed Aug 2 20:09:54 2006 From: empower at smart.net (Jamal Mazrui) Date: Wed, 2 Aug 2006 20:09:54 -0400 (EDT) Subject: [Wxruby-users] Using RichEdit 2 or 3 control Message-ID: WxRuby1 only defines the constant for RichEdit 1.0. From reading MSDN, features of the 2.0 or 3.0 version of this control are superior. I found the constant that enables use of the later version in the style parameter of the constructor: TE_RICH2 = 32768 I think RichEdit2 or 3 is automatically used depending on what is available in the Windows installation. Hope this tip helps others. Jamal From wxruby at qualitycode.com Wed Aug 2 23:50:10 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Wed, 02 Aug 2006 23:50:10 -0400 Subject: [Wxruby-users] wxruby2 alpha release goals In-Reply-To: References: <44D103F5.3030407@pressure.to> Message-ID: <1154577010.10911.53.camel@localhost.localdomain> On Wed, 2006-08-02 at 14:21 -0700, Sean Long wrote: > Alex wrote: > > So I suggest that we now look to release an alpha version very soon, based > > pretty much on the current state of CVS plus pending check-ins. > Sounds good, although we will need to agree on what "pretty much" really means. > > A) Fix the samples > > Consistent structure and style across all of them would be nice. As long as someone is willing to take this on, fine. But I'm not sure if it would be worth delaying an alpha release for better samples. That is, getting something out there with the problems documented might be better than waiting (and waiting, and waiting). See below for related thoughts. > > B) Fix any big-time, regular crashers > > Using Wx::GridCellBoolRender in a Wx::Grid crashes for me, have not > bothered to look into it too much. Again, I would lean toward defining this as something like "if it causes a sample to crash under simple usage, fix it". Otherwise, we run the risk of trying to make it perfect before releasing, instead of following the FLOSS rule of "release early and often". > > C) Add some documentation, if possible > > I am pretty happy just using the standard wxWidgets HTML documentation > and knowing the naming rules for wxRuby. I'm inclined to agree. This initial release should probably only be used by "motivated" developers who are willing to put up with a little pain. > > D) Add some easy, cheap ruby-ification to the API > > I think for the first version we should leave this out and just try to > get a release under our belt. We can add it on later easy enough. I would rather postpone this, partly because I would like to really think it through rather than making a little tweak here and there that might end up being replaced by a better rubification a little later. > > E) Binary gems > > I can help here by creating one for Mac OS X 10.4 PPC and Intel as > long as someone with more experience creates the gem spec. > > I also have Ubuntu & Windows XP virtualized under Parallels on the > Intel Mac so I could help there if I have time. I can certainly create a Ubuntu-compatible Linux tarball. I have never created a gem of any kind, so I would hope to get some guidance on that part. > I also think we should rip out all the comment fragments from the > include files, they are leftover from long ago the new classes added > do not have them. I don't view that as critical, although I think it's a good idea to do eventually. So I guess my take might be "release JUST what we have right now, including pending patches, with known problems documented". I'm just afraid that fixing anything will delay the release by weeks, or months. A looser version would be to freeze the library code right away, and the samples a week later, or some other "reasonable" amount of time. Kevin From wxruby at qualitycode.com Wed Aug 2 23:51:09 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Wed, 02 Aug 2006 23:51:09 -0400 Subject: [Wxruby-users] Active maintainer In-Reply-To: <44D10556.9000201@mindspring.com> References: <44CF959E.9030105@pressure.to> <44CFB28B.2090406@mindspring.com> <1154490812.6207.10.camel@localhost.localdomain> <44D0E810.4070800@pressure.to> <44D10556.9000201@mindspring.com> Message-ID: <1154577069.10911.56.camel@localhost.localdomain> Thanks for all the feedback, guys. Aside from time shortages, we seem to have two big problems: 1. We want to have some kind of code review system before patches end up in the "official" tree 2. We don't want patches to "rot" while awaiting review and integration I don't think we can accomplish those goals with CVS. We might be able to meet these goals with SVN, but I have never used SVN myself, so I'm not sure. I could imagine each contributor having his own branch within the SVN repository. Patches could presumably be pulled and merged between branches. The official maintainer would pull patches into the official branch. As I have said before, I much prefer the philosophy of distributed systems like bzr. In such a system, each contributor would have their own branch(es), and patches could be easily pulled between branches. Hopefully bzr has some nice tools for reviewing patches...but I'm not sure they're any better (or even as good as) those available for CVS or SVN. But here's the twist: I really want to try bzr on a real project. So I would be willing to commit more time to the project if one of the side benefits was learning bzr. I can also offer bzr repo hosting for any developer who doesn't have a suitable server account for publishing their own wxruby branch. (I believe any web hosting account with ssh, sftp, or webdav would work). Some combination of SVN and bzr would be fine with me, if it offers benefits to non-bzr users. I would propose that any switch happen immediately after the proposed "alpha" release. Kevin On Wed, 2006-08-02 at 16:04 -0400, Roy Sutton wrote: > I'm going to echo Alex's sentiments here. I'm quite up to my eyeballs > at the moment, too. I would be happy to pitch in and commit changes. > But I'm much happier committing someone else's changes than my own. As > long as we have two sets of eyes on each change I think anyone can do > the commits. > > I haven't played with Bzr either but I can do whatever. It's just more > bytes on the hard drive as far as I'm concerned. > > Roy > > Alex Fenton wrote: > > Hi all > > > > Thanks for bringing this up Sean. > > > >> I would be fine with Alex and/or Roy directly updating CVS at this > >> point. The last thing I want to be is a bottleneck. Hopefully I can > >> become more active again when things quiet down here. > >> > >> > > First up, I think Kevin has been doing a great job as maintainer. People > > here might remember that he came out of Wx::Retirement to move the > > project forward. But if his time's limited, perhaps routine tending of > > the CVS tree isn't the best way to use it. I would rather use his > > extensive experience and knowledge of wxruby to guide big decisions, and > > tackle tricky probs and help out on the GTK version where poss. > > > >> Alex and Roy: Do you want CVS rights? > >> > >> Curt and others: Any objections? > >> > >> > > I am not keen to start committing core SWIG stuff to the CVS tree > > without someone else reviewing. Such interface files as I've submitted > > have been developed by imitation and doggedness rather than any real > > understanding of hte C++ type system, memory mgmt or SWIg. Plus I think > > on principle we should try .i patches on at least two platforms before > > committing. > > > > So, is anyone willing and able to review and commit patches to the SWIG > > stuff? > > > > I have a bit more skill in writing english docs and ruby code and I > > wonder if I should spend more time on this now. It might be useful to > > have CVS rights so that I can commit docs and low-risk tweaks to samples. > > > > As mentioned before, I'm also up for helping to manage bugs and releases > > if that seems helpful. I suggest that we throw out a binary release > > based on the tree pretty much as it is now - I'll put this in a separate > > email. > > > >> Everyone: Bzr is still my favorite distributed version control system. > >> If we were using it, it would be much easier for many people to > >> contribute code, and the project would be far less dependent on any one > >> person (like me). Is there any interest yet in moving in that > >> direction? > >> > >> > > I'm a bit lazy about learning new dev tools eg RCS. But I'm up for > > learning bzr if it would help - I sometimes have to check out a fresh > > tree and copy changes to keep my patches clean. But presumably we still > > have to have one core tree? Also, I think we do benefit from the > > rubyforge hosting of our RCS system - eg viewcvs, statcvs, SSH. Bear in > > mind that someone might need to host and maintain this for a bzr repository. > > > > Thanks > > alex > > > > > > > > _______________________________________________ > > wxruby-users mailing list > > wxruby-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > > > > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users From alex at pressure.to Thu Aug 3 00:23:11 2006 From: alex at pressure.to (Alex Fenton) Date: Thu, 03 Aug 2006 05:23:11 +0100 Subject: [Wxruby-users] Using RichEdit 2 or 3 control In-Reply-To: References: Message-ID: <44D17A2F.3050807@pressure.to> Hi Jamal Thanks very much for the info. Having TE_RICH2 defined is one of the top five things I've been looking forward to from wxruby2 for use in my own app, which uses TextCtrls a lot. cheers alex > WxRuby1 only defines the constant for RichEdit 1.0. From reading MSDN, > features of the 2.0 or 3.0 version of this control are superior. I found > the constant that enables use of the later version in the style parameter > of the constructor: > TE_RICH2 = 32768 > From alex at pressure.to Thu Aug 3 01:09:21 2006 From: alex at pressure.to (Alex Fenton) Date: Thu, 03 Aug 2006 06:09:21 +0100 Subject: [Wxruby-users] bzr In-Reply-To: <1154577069.10911.56.camel@localhost.localdomain> References: <44CF959E.9030105@pressure.to> <44CFB28B.2090406@mindspring.com> <1154490812.6207.10.camel@localhost.localdomain> <44D0E810.4070800@pressure.to> <44D10556.9000201@mindspring.com> <1154577069.10911.56.camel@localhost.localdomain> Message-ID: <44D18501.9020401@pressure.to> Hi > 1. We want to have some kind of code review system before patches end up > in the "official" tree > I think Roy and I want to have 'core' SWIG patches reviewed before check-in, but are happy for now to do this for one another's and other's patches, coming from other platforms. Is that accurate? That sounds viable. > 2. We don't want patches to "rot" while awaiting review and integration > Given the rate we generate changes, I think we're OK if we can check in changes within 3-4 days. Again, sounds doable? > I don't think we can accomplish those goals with CVS. > I think we can maybe get close. As you say SVN might help with (2) with separate developer branches but I've never used it either. > As I have said before, I much prefer the philosophy of distributed > systems like bzr. I think I like the philosophy better - but it's about philosophy and pragmatism. > Hopefully bzr has some nice tools for reviewing patches...but I'm not > sure they're any better (or even as good as) those available for CVS or > SVN. > This is one concern - there are lots of mature tools for working with CVS & SVN - integration with IDEs, viewers, loggers, GUIs etc. bzr looks promising (there is bzr-mode.el!) but I'm guessing it doesn't have all that yet. > But here's the twist: I really want to try bzr on a real project. So I > would be willing to commit more time to the project if one of the side > benefits was learning bzr. That's a generous offer, thank you. > I can also offer bzr repo hosting for any > developer who doesn't have a suitable server account for publishing > their own wxruby branch. (I believe any web hosting account with ssh, > sftp, or webdav would work). > Erk! Does this mean that you have to publish to a web-server to share changes?? > Some combination of SVN and bzr would be fine with me, if it offers > benefits to non-bzr users. > This is really my biggest concern. One of the things we want to do with an alpha release is attract developers. Because we've all been working on the project for a while, I think we forget the entry barriers are already fairly high for a casual Ruby-centric developer: SWIG (no, not THAT version, THIS version), WxWidgets (no, compiled like THIS, not like THAT). Choosing an esoteric (though promising) RCS system is adding another barrier to potential developers. There doesn't look to be a bog-standard OS X binary dmg available (install Fink first...). And I also think that a mainstream RCS plus rubyforge hosting at the moment gives us a better guarantee of project continuity through developer changes etc. Sorry if this sounds negative. I just we are perhaps better for now (at least until we have a stable wxruby2) to look at human/organisational rather than technical solutions to the problem, as outlined above, rather than having a cutting-edge RCS to contend with/assist us. But I'm happy to give it a whirl if everyone else is keen and thinks it will help - especially if we think we can enable participation via SVN too. cheers alex From sean.m.long at gmail.com Thu Aug 3 03:19:15 2006 From: sean.m.long at gmail.com (Sean Long) Date: Thu, 3 Aug 2006 00:19:15 -0700 Subject: [Wxruby-users] bzr In-Reply-To: <44D18501.9020401@pressure.to> References: <44CF959E.9030105@pressure.to> <44CFB28B.2090406@mindspring.com> <1154490812.6207.10.camel@localhost.localdomain> <44D0E810.4070800@pressure.to> <44D10556.9000201@mindspring.com> <1154577069.10911.56.camel@localhost.localdomain> <44D18501.9020401@pressure.to> Message-ID: > I think Roy and I want to have 'core' SWIG patches reviewed before > check-in, but are happy for now to do this for one another's and other's > patches, coming from other platforms. Is that accurate? That sounds viable. Sounds like a good idea to me, I do 95% of my work on Mac OS X so I only occasionally compile a new wxRuby for Windows. The compile time is the biggest drag for me testing on Windows more often. I have thought about making a rake task called 'make' so you would run: rake make which would create a Makefile and compile from that so then we can use the -j 2 command line parameter for multiple processor machines (which both of my Mac systems are). If Ruby supported hardware threads I could just thread the rake tasks. Anyway this is something to do down the road. > > 2. We don't want patches to "rot" while awaiting review and integration > > > Given the rate we generate changes, I think we're OK if we can check in > changes within 3-4 days. Again, sounds doable? That sounds like a reasonable time frame to me. I would be happy with less than 7 days. > > I don't think we can accomplish those goals with CVS. > > > I think we can maybe get close. As you say SVN might help with (2) with > separate developer branches but I've never used it either. Think of SVN as CVS++, I converted my projects to SVN from CVS and kept on chugging along with minimal changes to the workflow. My experience is only with one man projects so I am not sure how the separate branches would work, it seams to me that it would be similar to how bzr works but only for the privileged few not the masses. > This is one concern - there are lots of mature tools for working with > CVS & SVN - integration with IDEs, viewers, loggers, GUIs etc. bzr looks > promising (there is bzr-mode.el!) but I'm guessing it doesn't have all > that yet. I think we should look at moving to SVN and use bzr on top of that so our investment in bzr will not be a waste if it does not work out because we still have an up-to-date SVN repo. > Erk! Does this mean that you have to publish to a web-server to share > changes?? You can still make patches and send them to someone else to merge with their branch or the official branch (at least that is how Darcs works and bzr seems similar). > This is really my biggest concern. One of the things we want to do with > an alpha release is attract developers. I think this is another good reason to move to SVN, I feel that developers think more highly of projects that use SVN over CVS. KDE last year changed over to SVN from CVS and I have not heard any horror stories about it. You can read about the KDE switch here: http://dot.kde.org/1115285369/ > There doesn't look to be a bog-standard > OS X binary dmg available (install Fink first...) I personally prefer DarwinPorts but we could host pre-compiled versions for the big 3 platforms. Sean From empower at smart.net Thu Aug 3 08:17:32 2006 From: empower at smart.net (Jamal Mazrui) Date: Thu, 3 Aug 2006 08:17:32 -0400 (EDT) Subject: [Wxruby-users] wxruby2 alpha release goals In-Reply-To: <1154577010.10911.53.camel@localhost.localdomain> References: <44D103F5.3030407@pressure.to> <1154577010.10911.53.camel@localhost.localdomain> Message-ID: My two cents on this would be to get an alpha out ASAP that documents known issues. It would be helpful if the naming conventions and parameters are generally the same as WxRuby1, but other, stylistic changes can wait. I found the "Poor Man's Documentation" to WxRuby1, as well as the code samples to be mostly adequate in combination with the general WxWidgets documentation. A later documentation choice might be to annotate the WxWidgets documentation with Ruby differences (that cannot be stated in general terms like naming conventions). I found such documentation for WxPython and WxPerl to be helpful. Essentially, the main WxWidgets documentation had insertions at the beginning of each class description that pointed out what was added, missing, or different in the calling syntax or behavior of the Python or Perl implementation. I would guess that the release of an alpha version will help to create momentum for subsequent iterations of the project, stirring more intrest, feedback, and contributions from the Ruby community. Regards, Jamal From joiey.seeley at gmail.com Thu Aug 3 12:19:22 2006 From: joiey.seeley at gmail.com (Joe Seeley) Date: Thu, 3 Aug 2006 11:19:22 -0500 Subject: [Wxruby-users] evt_scrollwin_thumbtrack/GetPosition? Message-ID: <5d0946540608030919h865c882r21f2b6be7c11978a@mail.gmail.com> I am attempting to create a scrollable panel. This works fine for using the scroll arrows, as I am capturing the event and then incrementing the scroll pos by the desired amount. However, it is not working on thumbtracking. I capture the event successfully, but I am unable to capture the position of the thumb tracker. I have looked at the poor man's doc and have been unable to figure out how this is captured. I have also looked at the wxWidgets documentation and tried using event.get_position (corresponding to wxWidgets GetPosition, and following the format generally used in wxRuby), but this was not successful. Thanks, Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20060803/b38eb01b/attachment.html From alex at pressure.to Thu Aug 3 13:46:56 2006 From: alex at pressure.to (Alex Fenton) Date: Thu, 03 Aug 2006 18:46:56 +0100 Subject: [Wxruby-users] evt_scrollwin_thumbtrack/GetPosition? In-Reply-To: <5d0946540608030919h865c882r21f2b6be7c11978a@mail.gmail.com> References: <5d0946540608030919h865c882r21f2b6be7c11978a@mail.gmail.com> Message-ID: <44D23690.9020702@pressure.to> Hi Joe Firstly, please tell us what version of wxruby you are using, and what platform. > I am attempting to create a scrollable panel. This works fine for > using the scroll arrows, as I am capturing the event and then > incrementing the scroll pos by the desired amount. However, it is not > working on thumbtracking. My guess is that it's because the relevant event class (are you expecting a ScrollWinEvent?) is not yet ported from WxWidgets to wxruby in the version you're using. > I capture the event successfully, but I am unable to capture the > position of the thumb tracker. If the event handler is firing correctly, I'd suggest doing a simple 'p evt' in your event handler method to tell you what sort of event you received. If as I suspect the relevant Event class is missing, it'll say something like: This is a stub generic event, but it won't have any useful methods to find the position of the event etc. > I have also looked at the wxWidgets documentation and tried using > event.get_position (corresponding to wxWidgets GetPosition, and > following the format generally used in wxRuby), but this was not > successful. The method name is right, but it's probably just missing. If you post a little sample code, we can check if it works or not in the current development branch. If it's missing, please feel free to submit a feature request for this. I expect it could be pretty easily added, but no-one among the wxruby developers has yet needed this method. Hope this helps alex From alex at pressure.to Thu Aug 3 14:04:26 2006 From: alex at pressure.to (Alex Fenton) Date: Thu, 03 Aug 2006 19:04:26 +0100 Subject: [Wxruby-users] bzr / Subversion / CVS In-Reply-To: References: <44CF959E.9030105@pressure.to> <44CFB28B.2090406@mindspring.com> <1154490812.6207.10.camel@localhost.localdomain> <44D0E810.4070800@pressure.to> <44D10556.9000201@mindspring.com> <1154577069.10911.56.camel@localhost.localdomain> <44D18501.9020401@pressure.to> Message-ID: <44D23AAA.9040904@pressure.to> Thanks Daniel, Kevin & Sean for helpful info on SVN and bzr. I had a look at the subversion website today and seems nice. Plus like you say, Sean, subversion seems to be cool at the moment making CVS look lame like sensible school shoes ;) I suggest we proceed with the following for the time being: - ask Tom @ Rubyforge to convert our repo from CVS to svn as soon as we release wxruby2 alpha1. - keep a close eye on how commits process etc are working, and try out bzr on top of svn. - plan to have a reviewer for commits to the swig/ and rake/ parts of the tree, or major changes elsewhere. - Roy, me, Kevin (where poss), Curt (where poss) committers to trunk - we continue to use the m.l. to let each other know about major work underway Also, I think Daniel made a good point about not being afraid to commit (!). After all, part of the reason for using a RCS is to enable backing-out of disastrous changes. Hope this sounds like a reasonable way forward. cheers alex From alex at pressure.to Thu Aug 3 14:27:01 2006 From: alex at pressure.to (Alex Fenton) Date: Thu, 03 Aug 2006 19:27:01 +0100 Subject: [Wxruby-users] wxruby2 alpha release goals In-Reply-To: <1154577010.10911.53.camel@localhost.localdomain> References: <44D103F5.3030407@pressure.to> <1154577010.10911.53.camel@localhost.localdomain> Message-ID: <44D23FF5.6090406@pressure.to> hi Basically, I think all Kevin and Sean's preceding suggestions in this thread are excellent. So, for alpha1, in summary: - no new classes/methods, bar pending patches - fix major crashers, only, in samples - a bit of extra docs, on known bugs and how to use the WxW C++ docs - I'm happy to make gems from supplied Linux & Win binaries as well as OS X Kevin Smith wrote: > Sounds good, although we will need to agree on what "pretty much" really > means. > how about, for the sake of alpha release - no new classes and methods. Everyone - yell if there's something that you think MUST be in there that isn't. And, preferably, follow the yell with a patch. >> Consistent structure and style across all of them would be nice. >> > As long as someone is willing to take this on, fine. But I'm not sure if > it would be worth delaying an alpha release for better samples. > I agree > I would lean toward defining this as something like "if it causes > a sample to crash under simple usage, fix it". I agree > I'm inclined to agree. This initial release should probably only be used > by "motivated" developers who are willing to put up with a little pain. > OK. Let's just make sure we add a brief, obvious note on how to use the WxWidgets C++ docs. > I would rather postpone this, partly because I would like to really > think it through rather than making a little tweak here and there that > might end up being replaced by a better rubification a little later. > Yes, I think you and Sean are right. I'll release my pure-ruby syntax sugar extensions shortly after the main alpha release to get some discussion going. > I can certainly create a Ubuntu-compatible Linux tarball. I have never > created a gem of any kind, so I would hope to get some guidance on that > part. > I'm have a working gemspec, and am happy to create binary gems for all platforms, if you supply me with a strip-ped platform .so/.lib/.bundle Also I think we should supply a pre-swigged set of source files, for those that like that sort of thing. As a tarball and source gem? > So I guess my take might be "release JUST what we have right now, > including pending patches, with known problems documented". Let's do it! Roy/Kevin/Curt - are any of you able to review & commit mine and Sean's pending patches some time in the next few days? I can htve a go otherwise. And throw anything back that causes probs, and if there's no quick fix, we can integrate after we release. > A looser version would be to freeze the library code right away, and the > samples a week later, or some other "reasonable" amount of time. > ditto all the best alex From sean.m.long at gmail.com Thu Aug 3 19:01:43 2006 From: sean.m.long at gmail.com (Sean Long) Date: Thu, 3 Aug 2006 16:01:43 -0700 Subject: [Wxruby-users] wxruby2 alpha release goals In-Reply-To: <44D23FF5.6090406@pressure.to> References: <44D103F5.3030407@pressure.to> <1154577010.10911.53.camel@localhost.localdomain> <44D23FF5.6090406@pressure.to> Message-ID: > Also I think we should supply a pre-swigged set of source files, for > those that like that sort of thing. As a tarball and source gem? The problem I see with the pre-swigged source files is that they are specific for each platform. So for example we would need a release like the following: wxRuby2_alpha_1_src wxRuby2_alpha_1_mac_os_x_ppc_gem wxRuby2_alpha_1_mac_os_x_x86_gem wxRuby2_alpha_1_windows_gem wxRuby2_alpha_1_ubuntu_x86_gem wxRuby2_alpha_1_mac_os_x_ppc_swigged_src wxRuby2_alpha_1_mac_os_x_x86_swigged_src #this one probably is the exact same as ppc wxRuby2_alpha_1_windows_swigged_src wxRuby2_alpha_1_ubuntu_x86_swigged_src That is a heck of a lot of files for an alpha release, especially since it can not all be done on one machine by one dev (2 machine minimum - a ppc mac, intel mac and virtualization software) I say we shoot for the raw src and the 4 gem files. SWIG is not too hard to install if someone is curious. > > So I guess my take might be "release JUST what we have right now, > > including pending patches, with known problems documented". > Let's do it! I agree fire up CVS and lets add some patches! Sean From wxruby at qualitycode.com Thu Aug 3 22:20:27 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 03 Aug 2006 22:20:27 -0400 Subject: [Wxruby-users] wxruby2 alpha release goals In-Reply-To: References: <44D103F5.3030407@pressure.to> <1154577010.10911.53.camel@localhost.localdomain> <44D23FF5.6090406@pressure.to> Message-ID: <1154658027.5697.0.camel@localhost.localdomain> On Thu, 2006-08-03 at 16:01 -0700, Sean Long wrote: > The problem I see with the pre-swigged source files is that they are > specific for each platform. > That is a heck of a lot of files for an alpha release, especially > since it can not all be done on one machine by one dev (2 machine > minimum - a ppc mac, intel mac and virtualization software) > > I say we shoot for the raw src and the 4 gem files. SWIG is not too > hard to install if someone is curious. I agree. Kevin From wxruby at qualitycode.com Thu Aug 3 22:22:33 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 03 Aug 2006 22:22:33 -0400 Subject: [Wxruby-users] wxruby2 alpha release goals In-Reply-To: <44D23FF5.6090406@pressure.to> References: <44D103F5.3030407@pressure.to> <1154577010.10911.53.camel@localhost.localdomain> <44D23FF5.6090406@pressure.to> Message-ID: <1154658153.5697.3.camel@localhost.localdomain> On Thu, 2006-08-03 at 19:27 +0100, Alex Fenton wrote: > Let's do it! Roy/Kevin/Curt - are any of you able to review & commit > mine and Sean's pending patches some time in the next few days? I can > htve a go otherwise. And throw anything back that causes probs, and if > there's no quick fix, we can integrate after we release. I don't expect to have any time until the middle of next week, at the earliest. Total chaos here. If things go according to plan, I should start to free up by the 12th. Kevin From wxruby at qualitycode.com Thu Aug 3 22:26:58 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 03 Aug 2006 22:26:58 -0400 Subject: [Wxruby-users] bzr / Subversion / CVS In-Reply-To: <44D23AAA.9040904@pressure.to> References: <44CF959E.9030105@pressure.to> <44CFB28B.2090406@mindspring.com> <1154490812.6207.10.camel@localhost.localdomain> <44D0E810.4070800@pressure.to> <44D10556.9000201@mindspring.com> <1154577069.10911.56.camel@localhost.localdomain> <44D18501.9020401@pressure.to> <44D23AAA.9040904@pressure.to> Message-ID: <1154658419.5697.7.camel@localhost.localdomain> On Thu, 2006-08-03 at 19:04 +0100, Alex Fenton wrote: > I suggest we proceed with the following for the time being: > - ask Tom @ Rubyforge to convert our repo from CVS to svn as soon as we > release wxruby2 alpha1. > - keep a close eye on how commits process etc are working, and try out > bzr on top of svn. > - plan to have a reviewer for commits to the swig/ and rake/ parts of > the tree, or major changes elsewhere. > - Roy, me, Kevin (where poss), Curt (where poss) committers to trunk > - we continue to use the m.l. to let each other know about major work > underway Sounds good. > > Also, I think Daniel made a good point about not being afraid to commit > (!). After all, part of the reason for using a RCS is to enable > backing-out of disastrous changes. With cvs, I don't quite agree. With svn or bzr, I think that's right. The big difference is that cvs thinks in individual files, whereas the other two think in "changesets". With changesets, it's easy to see everything that was checked in as a unit, and to revert an entire checkin. Kevin From wxruby at qualitycode.com Thu Aug 3 23:20:56 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 03 Aug 2006 23:20:56 -0400 Subject: [Wxruby-users] bzr In-Reply-To: <44D18501.9020401@pressure.to> References: <44CF959E.9030105@pressure.to> <44CFB28B.2090406@mindspring.com> <1154490812.6207.10.camel@localhost.localdomain> <44D0E810.4070800@pressure.to> <44D10556.9000201@mindspring.com> <1154577069.10911.56.camel@localhost.localdomain> <44D18501.9020401@pressure.to> Message-ID: <1154661656.5697.35.camel@localhost.localdomain> On Thu, 2006-08-03 at 06:09 +0100, Alex Fenton wrote: > This is one concern - there are lots of mature tools for working with > CVS & SVN - integration with IDEs, viewers, loggers, GUIs etc. bzr looks > promising (there is bzr-mode.el!) but I'm guessing it doesn't have all > that yet. The only cvs-related tool I use for the wxruby project is meld (a diff/merge utility for gnome), and it has bzr support. I would be interested to know what cvs-related tools and capabilities folks on this list actually use now and would hate to give up. Oh, and bzr has much better online source browsing capabilities than cvs. I guess a related question is: What editor/IDE do each of you use to work on wxruby? I use anjuta, which is ok but not great. I'll probably try FreeRIDE again. Hmmm. A bzr plugin would be cool! > Erk! Does this mean that you have to publish to a web-server to share > changes?? No, but it is a common way is to do so. One of the reasons I like bzr is that publishing your own repo doesn't require a shell account, nor any special code on the server. The requirements are quite easy to fulfill, unlike most other distributed RCS systems. Another way, as mentioned, is to circulate patches via email. A third way is for the project to set up a central server that people with permission can push patches to. This mode resembles the cvs/svn model, but "outsiders" can still have full version control on their local computers, and can merge the latest from the central server at any time. > Choosing an esoteric (though promising) RCS system is adding another > barrier to potential developers. There doesn't look to be a bog-standard > OS X binary dmg available (install Fink first...). And I also think that > a mainstream RCS plus rubyforge hosting at the moment gives us a better > guarantee of project continuity through developer changes etc. I remain unconvinced by this argument, but fully accept that I could be wrong. I suspect the ability of people to contribute code without first being "approved" for cvs/svn permissions would offset the difficulty of getting bzr set up. At this point, I expect only motivated developers to really work on wxruby. > Sorry if this sounds negative. I just we are perhaps better for now (at > least until we have a stable wxruby2) to look at human/organisational > rather than technical solutions to the problem, as outlined above, > rather than having a cutting-edge RCS to contend with/assist us. Well, as I said, I consider it a huge human issue that people cannot effectively participate in the process until after they have contributed enough loose patches to earn a spot on the cvs/svn server. > But I'm > happy to give it a whirl if everyone else is keen and thinks it will > help - especially if we think we can enable participation via SVN too. Similarly, I'm not yet willing to push hard on this issue. I believe that at some point, perhaps within a year or two, distributed RCS will be the default and obvious choice for a project like this. At this point, it's still a bit of a risk. Kevin From wxruby at qualitycode.com Thu Aug 3 23:23:28 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 03 Aug 2006 23:23:28 -0400 Subject: [Wxruby-users] Active maintainer In-Reply-To: <200608031507.k73F7hqI016144@gandalf.savarese.org> References: <200608031507.k73F7hqI016144@gandalf.savarese.org> Message-ID: <1154661809.5697.37.camel@localhost.localdomain> On Thu, 2006-08-03 at 11:07 -0400, Daniel F. Savarese wrote: > This is easy to do with Subversion. A major design goal behind Subversion > was to make merging changes between branches easy to do, something CVS > makes difficult. > Also, don't be afraid to work off of the development trunk. It > tends to accelerate development and it's easy to revert changes when > necessary. Good advice. Thanks! Kevin From john_sips_tea at yahoo.com Thu Aug 3 23:28:43 2006 From: john_sips_tea at yahoo.com (John M. Gabriele) Date: Thu, 3 Aug 2006 20:28:43 -0700 (PDT) Subject: [Wxruby-users] bzr / Subversion / CVS In-Reply-To: <44D23AAA.9040904@pressure.to> Message-ID: <20060804032843.94698.qmail@web37205.mail.mud.yahoo.com> --- Alex Fenton wrote: > Thanks Daniel, Kevin & Sean for helpful info on SVN and bzr. I had a > look at the subversion website today and seems nice. Plus like you say, > Sean, subversion seems to be cool at the moment making CVS look lame > like sensible school shoes ;) > > I suggest we proceed with the following for the time being: > - ask Tom @ Rubyforge to convert our repo from CVS to svn as soon as we > release wxruby2 alpha1. > [snip] {lurk mode off} Regarding cvs, svn, and bzr; I had a look around a couple weeks ago as I was considering the same sort of decision with my own projects. I found out a few things: It seems that the "free software" folks tend to often choose cvs (which is GPL'd v2 or later, though it's not an official GNU project) while open source folks often choose Subversion (which is released under an "Apache/BSD-style" license). The svn guys make it explicit that they want to "take over the CVS user base" (see the first item in their faq: "Why does this project exist?"). This rubs some folks in the free software community the wrong way, and I think there's been some backlash lately and even a resurgence of interest in cvs. cvs recently got a new maintainer (a skilled guy who used to write a lot of articles in C/C++ user's journal), and the manual is now hosted by Ximbiot (http://ximbiot.com/) which offers cvs support (among other services I figure). Also, I suspect cvs may have more of a "community project" flavor, while svn seems to have been a concerted effort (at least early on) primarily by the good folks at Tigris. (I haven't looked at who's doing commits though, so I could be off-base here.) Also, cvs seems to be a simpler, more unixy design (i.e. relying on file permissions, last-modified dates, and so forth), whereas svn is larger and more sophisticated (offering binary diffs, atomic commits, versioned symlinks, it's own virtual "versioned filesystem"...). Though I don't know any real details about the internals of either one. Another thing about svn is that its developers seem amply concerned with it being able to run well on MS Windows. svn makes use of a middle-layer library called "apache portable runtime". I checked http://apr.apache.org/ but found no tutorial docs on using APR, which in my book is a red flag to me to stay away. I see that Apache httpd uses APR but not many other projects currently are (http://apr.apache.org/projects.html). Regarding bzr, I think it started originally from TLA (Tom Lord's Arch), but then grew into being it's own from-scratch rewrite in Python. It's GPL'd and has associations with Ubuntu and Canonical. It's lead dev is Martin Pool. (His name looked familiar to me, then I remembered that he wrote PikiPiki -- a nice simple wiki in Python). Incidentally, on Marti's blog (http://sourcefrog.net/weblog), there's mention on the front page about bzr-svn integration, so that functionality might not be too far off... Personally, I like cvs well enough because it's well-worn, familiar (for the basic stuff I currently use it for anyhow), and reliable, but if I was going to switch to something, bzr really seems to have a lot going for it: great web site, great docs, written in a modern HLL (I know, I know: unfortunately not Ruby ;) ), very active community, GPL'd, and I really like the idea of a decentralized version control system (though I can't say that I fully understand the mechanics of it yet). So, in sum, I'd suggest that bzr actually has a frostier cool-factor than svn. :) Just my 2 cents. {re-enable lurk mode} ---John __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From sean.m.long at gmail.com Thu Aug 3 23:51:34 2006 From: sean.m.long at gmail.com (Sean Long) Date: Thu, 3 Aug 2006 20:51:34 -0700 Subject: [Wxruby-users] bzr In-Reply-To: <1154661656.5697.35.camel@localhost.localdomain> References: <44CF959E.9030105@pressure.to> <44CFB28B.2090406@mindspring.com> <1154490812.6207.10.camel@localhost.localdomain> <44D0E810.4070800@pressure.to> <44D10556.9000201@mindspring.com> <1154577069.10911.56.camel@localhost.localdomain> <44D18501.9020401@pressure.to> <1154661656.5697.35.camel@localhost.localdomain> Message-ID: > I would be > interested to know what cvs-related tools and capabilities folks on this > list actually use now and would hate to give up. I only use cvs for wxRuby now so I just use the cvs command line program. On svn I also only use the command line program. I do use the FileMerge visual diff viewer that comes with the Mac OS X dev. tools quite a bit. > I guess a related question is: What editor/IDE do each of you use to > work on wxruby? I use TextMate as my editor, as you can see from the above cvs tools question I like simple tools. > I believe that at some point, perhaps within a year or two, distributed RCS will > be the default and obvious choice for a project like this. You are probably right. Sean From empower at smart.net Fri Aug 4 08:46:35 2006 From: empower at smart.net (Jamal Mazrui) Date: Fri, 4 Aug 2006 08:46:35 -0400 (EDT) Subject: [Wxruby-users] TE_RICH2 RichEdit control Message-ID: One noteworthy aspect of using this style with a multi-line edit is that the problem of incompatible line endings between the edit buffer and the string it returns seems to go away. In other words, under Windows, one can manipulate a string representation of the edit buffer without the index positions being off because of a carriage return/line feed in one case and only a line feed in another. This allows, for example, a substring to be found by using position = edit_control.get_value.index(substring) edit_control.set_insertion_point(position) Jamal From joiey.seeley at gmail.com Fri Aug 4 17:40:10 2006 From: joiey.seeley at gmail.com (Joe Seeley) Date: Fri, 4 Aug 2006 16:40:10 -0500 Subject: [Wxruby-users] evt_scrollwin_thumbtrack/GetPosition? In-Reply-To: <44D23690.9020702@pressure.to> References: <5d0946540608030919h865c882r21f2b6be7c11978a@mail.gmail.com> <44D23690.9020702@pressure.to> Message-ID: <5d0946540608041440ufee7f9cu211b3682edf976cc@mail.gmail.com> Alex, Thanks for your response. Here is the bit of code that is actually affected. # Here is where the thumbtrack event is being captured @panel.evt_scrollwin_thumbtrack(){|event| on_thumbtrack(event)} # Here is the function to update the scroll position based off of the current thumb position def on_thumbtrack(event) @panel.set_scroll_pos(VERTICAL, event.get_position()) end I did check the event type with a p event in the on_thumbtrack function like you suggested. It did return a generic Wx::Event, rather than the desired Wx::ScrollWinEvent. I am currently using the wxRuby 0.6.0 release on Windows. Thanks, Joe On 8/3/06, Alex Fenton wrote: > > Hi Joe > > Firstly, please tell us what version of wxruby you are using, and what > platform. > > I am attempting to create a scrollable panel. This works fine for > > using the scroll arrows, as I am capturing the event and then > > incrementing the scroll pos by the desired amount. However, it is not > > working on thumbtracking. > My guess is that it's because the relevant event class (are you > expecting a ScrollWinEvent?) is not yet ported from WxWidgets to wxruby > in the version you're using. > > I capture the event successfully, but I am unable to capture the > > position of the thumb tracker. > If the event handler is firing correctly, I'd suggest doing a simple 'p > evt' in your event handler method to tell you what sort of event you > received. If as I suspect the relevant Event class is missing, it'll say > something like: > > > > This is a stub generic event, but it won't have any useful methods to > find the position of the event etc. > > I have also looked at the wxWidgets documentation and tried using > > event.get_position (corresponding to wxWidgets GetPosition, and > > following the format generally used in wxRuby), but this was not > > successful. > The method name is right, but it's probably just missing. If you post a > little sample code, we can check if it works or not in the current > development branch. If it's missing, please feel free to submit a > feature request for this. I expect it could be pretty easily added, but > no-one among the wxruby developers has yet needed this method. > > Hope this helps > alex > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20060804/baa91555/attachment.html From sean.m.long at gmail.com Mon Aug 7 01:46:43 2006 From: sean.m.long at gmail.com (Sean Long) Date: Sun, 6 Aug 2006 22:46:43 -0700 Subject: [Wxruby-users] wxWidgets 2.7.0 Message-ID: Just saw that 2.7.0 was released and thought I would post my thoughts on that in regard to our effort. The 2.7.0 release is a 'Development' release on the way to the stable 2.8.0 and so it could have ABI or API changes along the way. I think we should still focus on 2.6.3 for our initial release and keep our eye on the 2.7.x development and once it gets close to 2.8.0 then start working toward using that as the base for wxRuby. Sean From alex at pressure.to Mon Aug 7 18:20:40 2006 From: alex at pressure.to (Alex Fenton) Date: Mon, 07 Aug 2006 23:20:40 +0100 Subject: [Wxruby-users] evt_scrollwin_thumbtrack/GetPosition? In-Reply-To: <5d0946540608041440ufee7f9cu211b3682edf976cc@mail.gmail.com> References: <5d0946540608030919h865c882r21f2b6be7c11978a@mail.gmail.com> <44D23690.9020702@pressure.to> <5d0946540608041440ufee7f9cu211b3682edf976cc@mail.gmail.com> Message-ID: <44D7BCB8.8070504@pressure.to> Hi Joe I'm afraid it looks like you won't be able to do what you want to do with the 0.6.0 version of wxruby, since the event type isn't supported. I tried adding support for ScrollWinEvents to wxruby2 this afternoon and it looks to work well. But - we've got a short-term freeze on adding new stuff to wxruby2 until we've committed outstanding patches to CVS and released an alpha. So I don't think I can add this to wxruby2 straight away. I've not used Wx::ScrolledWindow, so what would be very helpful, if you're able, is a short, self-contained ruby script that demonstrates the use of evt_scrollwin_thumbtrack etc. That would help me confirm that the functions work as they ought to, and get support for the functions you want into the second release of wxruby2. Thanks alex Joe Seeley wrote: > Alex, > > Thanks for your response. Here is the bit of code that is actually > affected. > > # Here is where the thumbtrack event is being captured > @panel.evt_scrollwin_thumbtrack(){|event| on_thumbtrack(event)} > > # Here is the function to update the scroll position based off of the > current thumb position > def on_thumbtrack(event) > @panel.set_scroll_pos(VERTICAL, event.get_position()) > end > > I did check the event type with a p event in the on_thumbtrack > function like you suggested. It did return a generic Wx::Event, > rather than the desired Wx::ScrollWinEvent. > > I am currently using the wxRuby 0.6.0 release on Windows. > From wxruby at qualitycode.com Tue Aug 8 22:56:23 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Tue, 08 Aug 2006 22:56:23 -0400 Subject: [Wxruby-users] wxWidgets 2.7.0 In-Reply-To: References: Message-ID: <1155092183.5466.10.camel@localhost.localdomain> On Sun, 2006-08-06 at 22:46 -0700, Sean Long wrote: > I think we should still focus on 2.6.3 for our initial release and keep our > eye on the 2.7.x development and once it gets close to 2.8.0 then > start working toward using that as the base for wxRuby. Makes sense to me. Kevin From joiey.seeley at gmail.com Wed Aug 9 16:44:27 2006 From: joiey.seeley at gmail.com (Joe Seeley) Date: Wed, 9 Aug 2006 15:44:27 -0500 Subject: [Wxruby-users] evt_scrollwin_thumbtrack/GetPosition? In-Reply-To: <44D7BCB8.8070504@pressure.to> References: <5d0946540608030919h865c882r21f2b6be7c11978a@mail.gmail.com> <44D23690.9020702@pressure.to> <5d0946540608041440ufee7f9cu211b3682edf976cc@mail.gmail.com> <44D7BCB8.8070504@pressure.to> Message-ID: <5d0946540608091344p47ab7a6tad26c540b11124ff@mail.gmail.com> Alex, I whipped up a little script today that should show the different scroll events in action. # BEGIN CODE =begin rdoc ===Author: Joiey Seeley ===Description: This is a test class to demonstrate usage of scroll window events =end require 'wxruby' include Wx class MainFrame < Frame def initialize(title) super(nil, -1, 'Thumb Scrolling Test', Point.new(-1,-1), Size.new(1024, 487), style=SYSTEM_MENU | CAPTION | RESIZE_BORDER | 0 | 0 | MAXIMIZE_BOX | MINIMIZE_BOX | VERTICAL) set_scrollbar(VERTICAL, 0, 2000, 5000) @panel = Panel.new(self, -1) @addSrcButton = Button.new(@panel, -1, 'Add File', Point.new(200,200), Size.new(125, 20)) @addSrcButton.set_background_colour(Colour.new(212, 208, 200)) @addSrcButton.set_foreground_colour(Colour.new(0, 0, 0)) @addSrcButton.set_font(Font.new(8.25, FONTFAMILY_DEFAULT, FONTSTYLE_NORMAL, FONTWEIGHT_NORMAL, FALSE, 'Microsoft Sans Serif')) @addSrcButton.enable(true) # The following two work since they are not dependent on the event being of type Wx::ScrollWinEvent evt_scrollwin_linedown(){|event| on_line(event,20)} evt_scrollwin_lineup(){|event| on_line(event,-20)} # The followin events do not work correctly since they are dependent on the event being of type Wx::ScrollWinEvent evt_scrollwin_thumbtrack(){|event| on_thumb(event)} evt_scrollwin_thumbrelease(){|event| on_thumb(event)} # The following events don't appear to be generated ever evt_scrollwin_pagedown(){|event| on_page(event,1)} evt_scrollwin_pageup(){|event| on_page(event,-1)} evt_scrollwin_top(){|event| on_top(event)} evt_scrollwin_bottom(){|event| on_bottom(event)} end # Should move to the bottom of the window (Assuming this should be triggered when the End key is pressed) def on_bottom(event) set_scroll_pos(VERTICAL, 3000) @panel.move(Point.new(@panel.get_position.x,3000)) end # Should move to the bottom of the window (Assuming this should be triggered when the Home/Begin key is pressed) def on_top(event) set_scroll_pos(VERTICAL, 0) @panel.move(Point.new(@panel.get_position.x,0)) end # Scrolls the window up/down def on_line(event,y_off) set_scroll_pos(VERTICAL, get_scroll_pos(VERTICAL)+y_off) @panel.move(Point.new(@panel.get_position.x,@ panel.get_position.y-y_off)) end # Should scroll the window up/down proportionally to the location of the thumb. def on_thumb(event) y_off = @panel.get_position.y - event.get_position.y set_scroll_pos(VERTICAL, get_scroll_pos(VERTICAL)+y_off) @panel.move(Point.new(@panel.get_position.x,event.get_position.y)) end end #--------------------------------------------------------------------------- class TSTGui < App def on_init frame = MainFrame.new('') frame.show(TRUE) end end app = TSTGui.new app.main_loop # END CODE Thanks, Joe On 8/7/06, Alex Fenton wrote: > > Hi Joe > > I'm afraid it looks like you won't be able to do what you want to do > with the 0.6.0 version of wxruby, since the event type isn't supported. > > I tried adding support for ScrollWinEvents to wxruby2 this afternoon and > it looks to work well. But - we've got a short-term freeze on adding new > stuff to wxruby2 until we've committed outstanding patches to CVS and > released an alpha. So I don't think I can add this to wxruby2 straight > away. > > I've not used Wx::ScrolledWindow, so what would be very helpful, if > you're able, is a short, self-contained ruby script that demonstrates > the use of evt_scrollwin_thumbtrack etc. That would help me confirm that > the functions work as they ought to, and get support for the functions > you want into the second release of wxruby2. > > Thanks > alex > > > > Joe Seeley wrote: > > Alex, > > > > Thanks for your response. Here is the bit of code that is actually > > affected. > > > > # Here is where the thumbtrack event is being captured > > @panel.evt_scrollwin_thumbtrack(){|event| on_thumbtrack(event)} > > > > # Here is the function to update the scroll position based off of the > > current thumb position > > def on_thumbtrack(event) > > @panel.set_scroll_pos(VERTICAL, event.get_position()) > > end > > > > I did check the event type with a p event in the on_thumbtrack > > function like you suggested. It did return a generic Wx::Event, > > rather than the desired Wx::ScrollWinEvent. > > > > I am currently using the wxRuby 0.6.0 release on Windows. > > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20060809/29822b85/attachment.html From alex at pressure.to Thu Aug 10 05:21:56 2006 From: alex at pressure.to (Alex Fenton) Date: Thu, 10 Aug 2006 10:21:56 +0100 Subject: [Wxruby-users] Gem and tarball rake tasks Message-ID: <44DAFAB4.5000700@pressure.to> Hi I created an add-on script (to live in rake/) and a little patch for our main rakefile to automate building release products. The two main targets are 'gem' (create a binary gem for your platform) and 'package' (create a platform-neutral source tarball for SWIGging and compiling). A few small things came up while doing this: - Package name and version number: what is our upcoming release going to be called? I've called it 'wxruby-1.9.0' here, b/c it looked a bit ugly with numbers in the name (wxruby2) and the version. But easy to change, happy to do this. - $dl_ext on Linux: I forgot what the file extension for compiled Ruby extensions on Linux is: '.so' or '.lib'? - Support for Intel OS X: I had a quick google and can't see how binary extensions for Intel OS X are supposed to be distinguished in Rubygems system. There seems to be just Gem::Platform::DARWIN, which makes a xxx-powerpc-darwin.gem. Perhaps Sean or someone else on that platform can let me know what filename rubygems gives their gem? Ta cheers alex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rakepackage.rb Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060810/ed5356de/attachment.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rakefile.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060810/ed5356de/attachment.pl From alex at pressure.to Thu Aug 10 10:04:04 2006 From: alex at pressure.to (Alex Fenton) Date: Thu, 10 Aug 2006 15:04:04 +0100 Subject: [Wxruby-users] ScrollWinEvent In-Reply-To: <5d0946540608091344p47ab7a6tad26c540b11124ff@mail.gmail.com> References: <5d0946540608030919h865c882r21f2b6be7c11978a@mail.gmail.com> <44D23690.9020702@pressure.to> <5d0946540608041440ufee7f9cu211b3682edf976cc@mail.gmail.com> <44D7BCB8.8070504@pressure.to> <5d0946540608091344p47ab7a6tad26c540b11124ff@mail.gmail.com> Message-ID: <44DB3CD4.2050602@pressure.to> Hi Joe Joe Seeley wrote: > I whipped up a little script today that should show the different > scroll events in action. Thank you very much for the test script. It didn't work quite as expected - on my machine it didn't show a scroll bar to test. I'm not sure what this is down to - it could be a few things. My hunch is it's because OS X doesn't allow arbitrary-sized buttons, and probably not arbitrary scrollbars - it is stricter about UI guidelines. Anyway I adapted your sample to the attached scrollwin.rb, which uses the Wx::ScrolledWindow class. Then I used it to test adding ScrollWinEvent to wxruby2. It all seems to work well - though I can't figure out how evt_scrollwin_top is supposed to be generated? The attached patch and .i file adds support for ScrollWinEvent and event handlers to wxruby2. People - sorry for adding to the backlog, but would be nice if we could squeeze this into alpha1. It's a little patch, seems a fairly core class, and ScrolledWindow is already in there. Might need to up your 'fuzz' settings when appying this patch. cheers alex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: scrollwinevent.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060810/88665de3/attachment-0003.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ScrollWinEvent.i Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060810/88665de3/attachment-0004.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: scrollwin.rb Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060810/88665de3/attachment-0005.pl From stephen.ng at planetnutek.com Thu Aug 10 10:39:37 2006 From: stephen.ng at planetnutek.com (Stephen Ng) Date: Thu, 10 Aug 2006 22:39:37 +0800 Subject: [Wxruby-users] error compiling wxruby2 Message-ID: <44DB4529.2090001@planetnutek.com> I'm just starting to try out wxruby. I downloaded the CVS and executed rake. I received the following error - SWIG Version 1.3.24 Copyright (c) 1995-1998 University of Utah and the Regents of the University of California Copyright (c) 1998-2004 University of Chicago Compiled with i386-redhat-linux-g++ [i386-redhat-linux-gnu] Please see http://www.swig.org for reporting bugs and further information Doing slower check for SWIG 1.3.29 ** Invoke default (first_time) ** Invoke link (first_time) ** Invoke lib/wxruby2.so (first_time) ** Invoke obj/App.o (first_time) rake aborted! Don't know how to build task 'src/App.cpp' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1449:in `[]' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/bin/rake:7 /usr/bin/rake:18 I'm running Fedora 5 with swig-1.3.24, wxGTK-2.6.3-2.6.3.2.2.fc5, rake-0.7.1. Any help/suggestions would be appreciated. Thanks. Stephen Ng From alex at pressure.to Thu Aug 10 11:59:12 2006 From: alex at pressure.to (Alex Fenton) Date: Thu, 10 Aug 2006 16:59:12 +0100 Subject: [Wxruby-users] error compiling wxruby2 In-Reply-To: <44DB4529.2090001@planetnutek.com> References: <44DB4529.2090001@planetnutek.com> Message-ID: <44DB57D0.7080209@pressure.to> Hi Stephen Thanks for your message. I don't have Linux available but I see from this post: http://rubyforge.org/pipermail/wxruby-users/2005-August/001454.html that SWIG version 1.3.24 probably won't work with current wxruby2. Can you try downloading latest SWIG (1.3.29) and re-running rake please? Sorry for the inconvenience - SWIG for ruby had a lot of incompatible changes over these versions. I'll see if we can improve the check for a good version in our Rakefile. Thanks alex Stephen Ng wrote: > I'm just starting to try out wxruby. I downloaded the CVS and executed > rake. I received the following error - > SWIG Version 1.3.24 > Copyright (c) 1995-1998 > University of Utah and the Regents of the University of California > Copyright (c) 1998-2004 > University of Chicago > Compiled with i386-redhat-linux-g++ [i386-redhat-linux-gnu] > > Please see http://www.swig.org for reporting bugs and further information > Doing slower check for SWIG 1.3.29 > ** Invoke default (first_time) > ** Invoke link (first_time) > ** Invoke lib/wxruby2.so (first_time) > ** Invoke obj/App.o (first_time) > rake aborted! > Don't know how to build task 'src/App.cpp' > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1449:in `[]' > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in > `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in > `each' > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in > `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in > `invoke' > /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in > `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in > `each' > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in > `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in > `invoke' > /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in > `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in > `each' > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in > `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in > `invoke' > /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in > `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in > `each' > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in > `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in > `invoke' > /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in `run' > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in `run' > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/bin/rake:7 > /usr/bin/rake:18 > > I'm running Fedora 5 with swig-1.3.24, wxGTK-2.6.3-2.6.3.2.2.fc5, > rake-0.7.1. > > Any help/suggestions would be appreciated. > > Thanks. > > Stephen Ng > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > From sean.m.long at gmail.com Thu Aug 10 13:31:36 2006 From: sean.m.long at gmail.com (Sean Long) Date: Thu, 10 Aug 2006 10:31:36 -0700 Subject: [Wxruby-users] Gem and tarball rake tasks In-Reply-To: <44DAFAB4.5000700@pressure.to> References: <44DAFAB4.5000700@pressure.to> Message-ID: Awesome! I tried: rake gem rake package rake gem_osx and they all worked just fine in OS X 10.4 PPC (I will try on my Intel Mac tonight after work) I will also look up what the gem platform name is for x86 Mac OS X. I also like the version naming you have chosen. I am also happy that you did this because I was seriously thinking about giving it a go myself, thanks. Sean On 8/10/06, Alex Fenton wrote: > Hi > > I created an add-on script (to live in rake/) and a little patch for our > main rakefile to automate building release products. From alex at pressure.to Thu Aug 10 14:10:53 2006 From: alex at pressure.to (Alex Fenton) Date: Thu, 10 Aug 2006 19:10:53 +0100 Subject: [Wxruby-users] update on samples Message-ID: <44DB76AD.50901@pressure.to> Hi all Have been taking a look at the samples to see what's broken. Not looking TOO bad overall, but a few problems we should try and tackle before alpha: Firstly, I have a few commits (minimal, dialogs, unicode) - anyone else been working on these or can I go ahead? One general issue is that many of the samples rely on being run from their own directory, but don't enforce this. How do people feel about samples doing: Dir.chdir( File.dirname( __FILE__ ) ) if the sample should be run from the current directory only? Alternately, some can be recoded to load resources relative to the script dir, not the dir that ruby was run from, and fixed in this way. Notes on individual scripts - bigdemo.rb Mostly OK, and a nice script as well. But issues when not run from current dir. Also some items don't quite display right in the little pane (eg Wx::Choice) - calendar.rb OK - caret.rb OK - but arrow keys don't work properly (should they?) - controls.rb Seems OK, except doesn't work if not run from current dir. Probably should add textctrls to this one. - dialogs.rb Problems with DC - seems to cause ObjectPreviouslyDeleted error in an on_paint handler. I have worked round this. MDI, ColourDialog crashes on OS X. - system_settings.rb OK (thanks to Sean's fix for get_text_extent) - images.rb OK - listbook.rb OK, except breaks if not run from own directory. - mdi.rb MDI doesn't work on OS X? - minimal.rb OK - have tidied up and commented a bit more, commit pending - text/textctrl.rb Ok - text/unicode.rb OK - except the signature of Choice.new() has changed to become more strict - the optional argument with a list of choices (default = []) is no longer optional. I think this must be related to using typemaps. I have added a workaround, commit pending - xrc OK, except breaks if not run from own directory. I'm going to have a look at tweaking bigdemo next. cheers alex From alex at pressure.to Thu Aug 10 14:16:03 2006 From: alex at pressure.to (Alex Fenton) Date: Thu, 10 Aug 2006 19:16:03 +0100 Subject: [Wxruby-users] Gem and tarball rake tasks In-Reply-To: References: <44DAFAB4.5000700@pressure.to> Message-ID: <44DB77E3.6090800@pressure.to> Hi > I will also look up what the gem platform name is for x86 Mac OS X. > Glad it worked out nicely. I had a poke around in rubygems code, and it turns out that the default suffix for a binary gem is the value of RUBY_PLATFORM (the standard ruby constant). This seems a bit broken to me, not least because it means you get different gem names from doing :gem_osx and :gem - and, on mac powerpc Gem::Platform::CURRENT != Gem::Platform::DARWIN which seems bizarre. Ah well. We can work round it for now cheers alex From wxruby at roadq.com Thu Aug 10 14:58:07 2006 From: wxruby at roadq.com (Mark Ping) Date: Thu, 10 Aug 2006 11:58:07 -0700 Subject: [Wxruby-users] ProgressDialog on WindowsXP Message-ID: <44DB81BF.20309@roadq.com> Hi all, I've been trying to figure this out on my own, but if the project is headed to alpha, it should probably be resolved before that. Basically, ProgressDialog doesn't show up at all AFAICT. The Gauge control works fine, but in the controls example as well as in a small test app, I can't get the ProgressDialog to appear. --Mark Ping From roys at mindspring.com Thu Aug 10 16:24:43 2006 From: roys at mindspring.com (Roy Sutton) Date: Thu, 10 Aug 2006 16:24:43 -0400 Subject: [Wxruby-users] ProgressDialog on WindowsXP In-Reply-To: <44DB81BF.20309@roadq.com> References: <44DB81BF.20309@roadq.com> Message-ID: <44DB960B.604@mindspring.com> This might be the problem with SWIG that was I trying to chase down before I was broadsided by life. There is a bug in SWIG's director generation that I haven't gotten documented well enough to submit to the SWIG team. I wish I had been able to wrap it up as it is pretty big and gnarly. I'll see what I can pull from my memory and maybe I can post my samples and someone else can help carry it forward. Roy Mark Ping wrote: > Hi all, > > I've been trying to figure this out on my own, but if the project is > headed to alpha, it should probably be resolved before that. > > Basically, ProgressDialog doesn't show up at all AFAICT. The Gauge > control works fine, but in the controls example as well as in a small > test app, I can't get the ProgressDialog to appear. > > --Mark Ping > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > From alex at pressure.to Thu Aug 10 17:11:00 2006 From: alex at pressure.to (Alex Fenton) Date: Thu, 10 Aug 2006 22:11:00 +0100 Subject: [Wxruby-users] ProgressDialog on WindowsXP In-Reply-To: <44DB81BF.20309@roadq.com> References: <44DB81BF.20309@roadq.com> Message-ID: <44DBA0E4.3080206@pressure.to> Mark Ping wrote: > Basically, ProgressDialog doesn't show up at all AFAICT. The Gauge > control works fine, but in the controls example as well as in a small > test app, I can't get the ProgressDialog to appear. > Thanks for the report Mark - I'll add it to the bug tracker. When I tried ProgressDialog earlier on OS X, it mostly works OK, but the cancel function is broken. If you cancel, the dialog doesn't go away. I don't think the dialog is native on OS X though as it is on Win32. alex From sean.m.long at gmail.com Fri Aug 11 00:43:37 2006 From: sean.m.long at gmail.com (Sean Long) Date: Thu, 10 Aug 2006 21:43:37 -0700 Subject: [Wxruby-users] Gem and tarball rake tasks In-Reply-To: <44DB77E3.6090800@pressure.to> References: <44DAFAB4.5000700@pressure.to> <44DB77E3.6090800@pressure.to> Message-ID: On my Intel iMac I get the following gem from the rake gem command: wxruby-1.9.0-i686-darwin8.4.1.gem also Gem::Platform::CURRENT returns "current" Sean On 8/10/06, Alex Fenton wrote: > Hi > > I will also look up what the gem platform name is for x86 Mac OS X. > > > Glad it worked out nicely. I had a poke around in rubygems code, and it > turns out that the default suffix for a binary gem is the value of > RUBY_PLATFORM (the standard ruby constant). > > This seems a bit broken to me, not least because it means you get > different gem names from doing :gem_osx and :gem - and, on mac powerpc > Gem::Platform::CURRENT != Gem::Platform::DARWIN > > which seems bizarre. Ah well. We can work round it for now > > cheers > alex > > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > From wxruby at qualitycode.com Fri Aug 11 00:58:32 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Fri, 11 Aug 2006 00:58:32 -0400 Subject: [Wxruby-users] Gem and tarball rake tasks In-Reply-To: <44DAFAB4.5000700@pressure.to> References: <44DAFAB4.5000700@pressure.to> Message-ID: <1155272312.6713.2.camel@localhost.localdomain> On Thu, 2006-08-10 at 10:21 +0100, Alex Fenton wrote: > I created an add-on script (to live in rake/) and a little patch for our > main rakefile to automate building release products. Sweet! > - Package name and version number: what is our upcoming release going to > be called? I've called it 'wxruby-1.9.0' here, b/c it looked a bit ugly > with numbers in the name (wxruby2) and the version. But easy to change, > happy to do this. I think wxruby2-0.0.x would be the most correct. I think I can live with wxruby-1.9.0, but I would like to think through all the consequences (Rubyforge release listings, Debian package naming, etc). > - $dl_ext on Linux: I forgot what the file extension for compiled Ruby > extensions on Linux is: '.so' or '.lib'? Compiled extensions (the equivalent of Windows .dll) are .so Kevin From wxruby at qualitycode.com Fri Aug 11 01:04:20 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Fri, 11 Aug 2006 01:04:20 -0400 Subject: [Wxruby-users] wxruby2 alpha release goals In-Reply-To: References: <44D103F5.3030407@pressure.to> Message-ID: <1155272660.6713.7.camel@localhost.localdomain> Just FYI: I am going to try really hard to set aside half a day this weekend to catch up on wxruby cvs work. Really, really hard. I'm announcing this as a further incentive to myself, to avoid breaking a public commitment. The good news is that two of the four "real life" pressures that have been taking up my time for the last few months should be mostly finished tomorrow. The other two are weekday activities, so hopefully I will be able to put in some wxruby time each weekend for a while. Kevin From wxruby at qualitycode.com Fri Aug 11 01:24:47 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Fri, 11 Aug 2006 01:24:47 -0400 Subject: [Wxruby-users] bzr / Subversion / CVS In-Reply-To: <1154658419.5697.7.camel@localhost.localdomain> References: <44CF959E.9030105@pressure.to> <44CFB28B.2090406@mindspring.com> <1154490812.6207.10.camel@localhost.localdomain> <44D0E810.4070800@pressure.to> <44D10556.9000201@mindspring.com> <1154577069.10911.56.camel@localhost.localdomain> <44D18501.9020401@pressure.to> <44D23AAA.9040904@pressure.to> <1154658419.5697.7.camel@localhost.localdomain> Message-ID: <1155273887.6713.17.camel@localhost.localdomain> > On Thu, 2006-08-03 at 19:04 +0100, Alex Fenton wrote: > > I suggest we proceed with the following for the time being: > > - ask Tom @ Rubyforge to convert our repo from CVS to svn as soon as we > > release wxruby2 alpha1. > > - keep a close eye on how commits process etc are working, and try out > > bzr on top of svn. Interesting comparison of distributed vcs systems: http://changelog.complete.org/posts/528-Whose-Distributed-VCS-Is-The-Most-Distributed.html I know for sure that the stuff about bzr is inaccurate, so I will assume that the critiques of other systems are also questionable. However, he seems to say that SVN cannot do several things related to branching that I would have thought it could do. Can someone who has used SVN comment? Thanks, Kevin From alex at pressure.to Fri Aug 11 05:17:54 2006 From: alex at pressure.to (Alex Fenton) Date: Fri, 11 Aug 2006 10:17:54 +0100 Subject: [Wxruby-users] Gem and tarball rake tasks In-Reply-To: References: <44DAFAB4.5000700@pressure.to> <44DB77E3.6090800@pressure.to> Message-ID: <44DC4B42.9010301@pressure.to> Sean Long wrote: > On my Intel iMac I get the following gem from the rake gem command: > > wxruby-1.9.0-i686-darwin8.4.1.gem > Thanks - I've just posted a q to the newsgroup to find out whether there are compatibility issues with different versions of XCode (eg 8.4.1, 7.9.0) on the same architecture. Hopefully we can just build powerpc-darwin and i686-darwin - I've added a little hack to the rake script to fix the output filenames. > also Gem::Platform::CURRENT returns "current" > Hehe - not very helpful is it? alex From alex at pressure.to Fri Aug 11 05:27:46 2006 From: alex at pressure.to (Alex Fenton) Date: Fri, 11 Aug 2006 10:27:46 +0100 Subject: [Wxruby-users] Gem and tarball rake tasks In-Reply-To: <1155272312.6713.2.camel@localhost.localdomain> References: <44DAFAB4.5000700@pressure.to> <1155272312.6713.2.camel@localhost.localdomain> Message-ID: <44DC4D92.8050501@pressure.to> >> - Package name and version number: what is our upcoming release going to >> be called? I've called it 'wxruby-1.9.0' here, b/c it looked a bit ugly >> with numbers in the name (wxruby2) and the version. But easy to change, >> happy to do this. >> > > I think wxruby2-0.0.x would be the most correct. I think I can live with > wxruby-1.9.0, but I would like to think through all the consequences > (Rubyforge release listings, Debian package naming, etc). > My thinking here, aside from aesthetics, is that the release we're working on will eventually (soon?!) supplant the wxruby 0.x.x series, which were development releases towards wxruby v1.0. We don't seem to have a situation like sqlite/sqlite3 where there are reasons for long-term maintenance of two distinct stable packages with different features. Our differences lie in internal engineering rather than end-user functionality. re Rubyforge I think that the 'odd minor version equals development' convention is well embedded in Ruby practice generally - eg current core Ruby. >> - $dl_ext on Linux: I forgot what the file extension for compiled Ruby >> extensions on Linux is: '.so' or '.lib'? >> > > Compiled extensions (the equivalent of Windows .dll) are .so > Thanks - will update the rake scripts alex From joiey.seeley at gmail.com Sat Aug 12 01:05:27 2006 From: joiey.seeley at gmail.com (Joe Seeley) Date: Sat, 12 Aug 2006 00:05:27 -0500 Subject: [Wxruby-users] Windows build? Message-ID: <5d0946540608112205h70467c59jfa7db4dda69d89b6@mail.gmail.com> I performed a get on the CVS WxRuby2; I have installed wxWidgets 2.6.3 and SWIG 1.3.29. Additionally I am running Visual Studio on Windows XP. When I run rake to compile I receive the following error. App.cpp c:\wxWidgets-2.6.3/include\wx/platform.h(190) : fatal error C1083: Cannot open include file: 'wx/setup.h': No such file or directory rake aborted! Command failed with status (2): [cl.exe -c -Ic:\wxWidgets-2.6.3/include -D_...] I'm not sure why this is happening. I have looked at my environment variables and don't see any errors there. Thanks, Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20060812/41bdb25c/attachment.html From roys at mindspring.com Sat Aug 12 01:59:56 2006 From: roys at mindspring.com (Roy Sutton) Date: Sat, 12 Aug 2006 01:59:56 -0400 Subject: [Wxruby-users] Windows build? In-Reply-To: <5d0946540608112205h70467c59jfa7db4dda69d89b6@mail.gmail.com> References: <5d0946540608112205h70467c59jfa7db4dda69d89b6@mail.gmail.com> Message-ID: <44DD6E5C.8020003@mindspring.com> Do a 'SET' command and paste me he results into a private e-mail and I'll respond to the list if I have the solution. Roy Joe Seeley wrote: > I performed a get on the CVS WxRuby2; I have installed wxWidgets 2.6.3 > and SWIG 1.3.29. Additionally I am running Visual Studio on Windows > XP. When I run rake to compile I receive the following error. > > App.cpp > c:\wxWidgets- 2.6.3/include\wx/platform.h(190) : fatal error C1083: > Cannot open include file: 'wx/setup.h': No such file or directory > rake aborted! > Command failed with status (2): [cl.exe -c > -Ic:\wxWidgets-2.6.3/include -D_...] > > I'm not sure why this is happening. I have looked at my environment > variables and don't see any errors there. > > Thanks, > Joe > ------------------------------------------------------------------------ > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users From sean.m.long at gmail.com Sat Aug 12 02:30:28 2006 From: sean.m.long at gmail.com (Sean Long) Date: Fri, 11 Aug 2006 23:30:28 -0700 Subject: [Wxruby-users] Windows build? In-Reply-To: <5d0946540608112205h70467c59jfa7db4dda69d89b6@mail.gmail.com> References: <5d0946540608112205h70467c59jfa7db4dda69d89b6@mail.gmail.com> Message-ID: Try the following: - go to (c:\wxWidgets-2.6.3\include\wx\msw) in explorer - make a copy of setup0.h and rename it setup.h I am pretty sure that is what needs to be done. On Windows I build wxWidgets from DialogBlocks and I believe that it creates the copy for me. Sean On 8/11/06, Joe Seeley wrote: > I performed a get on the CVS WxRuby2; I have installed wxWidgets 2.6.3 and > SWIG 1.3.29. Additionally I am running Visual Studio on Windows XP. When I > run rake to compile I receive the following error. > > App.cpp > c:\wxWidgets- 2.6.3/include\wx/platform.h(190) : fatal error C1083: Cannot > open include file: 'wx/setup.h': No such file or directory > rake aborted! > Command failed with status (2): [cl.exe -c -Ic:\wxWidgets-2.6.3/include > -D_...] > > I'm not sure why this is happening. I have looked at my environment > variables and don't see any errors there. > > Thanks, > Joe > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > From sean.m.long at gmail.com Sat Aug 12 03:34:14 2006 From: sean.m.long at gmail.com (Sean Long) Date: Sat, 12 Aug 2006 00:34:14 -0700 Subject: [Wxruby-users] Documentation for wxRuby Message-ID: I have written an addon file for rake that turns the wxWidgets documentation into something much more Ruby like. The code has not been cleaned up or re-factored and needs some extra features added but it does quite a bit already. I have uploaded the generated documentation to my web site so people can view it. http://hailstonesoftware.com/_files/Ruby/wxruby/html/wx_contents.html. I also have a zipped version if anyone wants to download a local copy. http://hailstonesoftware.com/_files/Ruby/wxruby/wxRuby_docs.zip The docs are generated by parsing the LaTeX originals from wxWidgets and outputing a Rubyish version. These LaTeX files are then run thru tex2rtf to create the HTML docs. The attached file shows all the details, just drop it into the rake folder and add require "rake/rakedocs" to the main rakefile and also add create_documentation_tasks under all the other create_*_tasks in the main rakefile. Type rake -T to see the added tasks. All the requirements to run the doc tasks are at the top of the rakedocs.rb file. Feedback is welcome especially on the styling of the method names. I hope this email makes sense, I am half asleep but wanted to get this out for some feedback. Sean -------------- next part -------------- A non-text attachment was scrubbed... Name: rakedocs.rb Type: text/x-ruby-script Size: 12161 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-users/attachments/20060812/70844426/attachment-0001.bin From alex at pressure.to Sat Aug 12 05:44:36 2006 From: alex at pressure.to (Alex Fenton) Date: Sat, 12 Aug 2006 10:44:36 +0100 Subject: [Wxruby-users] Windows build? In-Reply-To: References: <5d0946540608112205h70467c59jfa7db4dda69d89b6@mail.gmail.com> Message-ID: <44DDA304.7000205@pressure.to> Just to add to the other emails (hope not confusing) What does running wx-config --cppflags and wx-config --list return in the command prompt you're about to compile in? I ran into this error the other day when building a wx extension. 'setup.h' is a special header which contains all the settings specific to your build of WxWidgets - what optional features were and weren't included (eg unicode or ANSI). On my Mac at least, it lives in a separate directory from the rest of the headers: The main headers are in /usr/local/include/wx-2.6/wx/ The correct setup.h is in /usr/local/include/wx-2.6/wx/mac-unicode-release-static-2.6/ The same should happen on windows - you should have a configuration-specific location with a modified setup.h that reflects your real build options. But the including (-I) directive should happen automatically in rake. alex http://www.wxwidgets.org/wiki/index.php/MSVC_Setup_Guide#Setup.h Sean Long wrote: > Try the following: > - go to (c:\wxWidgets-2.6.3\include\wx\msw) in explorer > - make a copy of setup0.h and rename it setup.h > > I am pretty sure that is what needs to be done. On Windows I build > wxWidgets from DialogBlocks and I believe that it creates the copy for > me. > > Sean > > On 8/11/06, Joe Seeley wrote: > >> I performed a get on the CVS WxRuby2; I have installed wxWidgets 2.6.3 and >> SWIG 1.3.29. Additionally I am running Visual Studio on Windows XP. When I >> run rake to compile I receive the following error. >> >> App.cpp >> c:\wxWidgets- 2.6.3/include\wx/platform.h(190) : fatal error C1083: Cannot >> open include file: 'wx/setup.h': No such file or directory >> rake aborted! >> Command failed with status (2): [cl.exe -c -Ic:\wxWidgets-2.6.3/include >> -D_...] >> >> I'm not sure why this is happening. I have looked at my environment >> variables and don't see any errors there. >> >> Thanks, >> Joe >> >> _______________________________________________ >> wxruby-users mailing list >> wxruby-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wxruby-users >> >> >> > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > From alex at pressure.to Sat Aug 12 14:33:02 2006 From: alex at pressure.to (Alex Fenton) Date: Sat, 12 Aug 2006 19:33:02 +0100 Subject: [Wxruby-users] Documentation for wxRuby In-Reply-To: References: Message-ID: <44DE1EDE.4080700@pressure.to> Sean Long wrote: > I have written an addon file for rake that turns the wxWidgets > documentation into something much more Ruby like. Very nice indeed, thank you. This is a real boost for wxruby. > The code has not been cleaned up or re-factored and needs some extra > features added but it does quite a bit already. I refactored a little while working through to understand what you did. Hopefully I've made your logic a little clearer. The parsing also happens to be 3-4 times faster, b/c of different uncamelcasing and taking the regex literals out of the loops. It also fixes camelcase edge cases like GetXRCID and Dos2Unix. There's few refinements of the rake tasks - eg you can specify a custom latex macro set with ENV['TEX2RTF_STYLESHEET']. What we could look at next is some easy way to bundle this with our gem and tarball releases. I think it would be better to bundle only a subset of class/method documentation reflecting classes actually ported so far. The other reference docs (overviews etc) can be available on-line. What might also be nice is to have our own CSS stylesheet that gives it a wxRuby look and feel distinct from the WxWidgets style (which after a few years I am really sick of looking at...) Another small point - I wonder if we could have Wx:: prefixed to the class names in our docs? Anyway, once again, nice job. Let me know if you're happy with my changes, and I'll check it into CVS. cheers alex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rakedocs.rb Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060812/5cb1da7e/attachment.pl From sean.m.long at gmail.com Sat Aug 12 17:31:53 2006 From: sean.m.long at gmail.com (Sean Long) Date: Sat, 12 Aug 2006 14:31:53 -0700 Subject: [Wxruby-users] Documentation for wxRuby In-Reply-To: <44DE1EDE.4080700@pressure.to> References: <44DE1EDE.4080700@pressure.to> Message-ID: > I refactored a little while working through to understand what you did. > Hopefully I've made your logic a little clearer. The parsing also > happens to be 3-4 times faster, b/c of different uncamelcasing and > taking the regex literals out of the loops. It also fixes camelcase edge > cases like GetXRCID and Dos2Unix. Great clean up job! It looks 100 times better now and 70 or so lines of code less. I am also glad the you could understand the mess of code, it was really just a quick proof of concept hack. > There's few refinements of the rake tasks - eg you can specify a custom > latex macro set with ENV['TEX2RTF_STYLESHEET']. I like that idea. > What we could look at next is some easy way to bundle this with our gem > and tarball releases. I think it would be better to bundle only a subset > of class/method documentation reflecting classes actually ported so > far. The other reference docs (overviews etc) can be available on-line. I agree with this 100%, I was going to add a list of *.tex files that not should not be processed. > What might also be nice is to have our own CSS stylesheet that gives it > a wxRuby look and feel distinct from the WxWidgets style (which after a > few years I am really sick of looking at...) The wxWidgets look is a bit dated, I may try creating a new stylesheet tonight. > Another small point - I wonder if we could have Wx:: prefixed to the > class names in our docs? I originally had that but it got redundant looking so I removed it. We could add a section at the top of each class file that shows that the class belongs to the Wx module. > Anyway, once again, nice job. Let me know if you're happy with my > changes, and I'll check it into CVS. I am very happy with the changes, check it in. So Kevin did give you CVS commit access? Alright! Sean From alex at pressure.to Sat Aug 12 20:44:49 2006 From: alex at pressure.to (Alex Fenton) Date: Sun, 13 Aug 2006 01:44:49 +0100 Subject: [Wxruby-users] Documentation for wxRuby In-Reply-To: References: <44DE1EDE.4080700@pressure.to> Message-ID: <44DE7601.7090606@pressure.to> Sean Long wrote: >> I think it would be better to bundle only a subset of class/method documentation reflecting classes actually ported so far. >> > > I agree with this 100%, I was going to add a list of *.tex files that > not should not be processed. > Yep - one tricky thing is that the tex2rtf processor doesn't seem to like single files - it relies on directives in the top document (I know nothing about tex). Another prob is the cross-references in the class docs - we don't want dead links. Perhaps in the longer run we want to run this sort of process once to create a base set of class ref docs. These live in our VCS, and we hand-edit them to reflect wxRuby specifics (deleting irrelevant stuff, adding Ruby examples, correcting Ruby-specific method sigs etc). This is similar to what we did with the Wx header files. The question then would be what format we use as our base - what do people think about: - LaTeX? (we have it, but how many of us know LaTeX? And no ri output) - rdoc (doesn't seem well suited for SWIGged C extensions - FXRuby get round it by maintaining a dummy set of rb files with the documentation) - rdtool (is this project still alive? can't find much documentation) - html (easy, but not very semantic) - DocBook (very nice output, verbose to generate & edit, overkill?) None of these seems ideal. Another option would be to co-ordinate with WxWidgets and add notes directly to the base docs, like WxPerl and WxPython. But I think there are a lot of problems with this. > The wxWidgets look is a bit dated, I may try creating a new stylesheet tonight. > Attached my quick stab at it, with the dashed lines that seem obligatory in any CSS based design these days ;). > I originally had that but it got redundant looking so I removed it. We > could add a section at the top of each class file that shows that the > class belongs to the Wx module. > Might be worth adding, thanks. > I am very happy with the changes, check it in. So Kevin did give you > CVS commit access? Alright! Yes, I'm just committing fixes to the samples so Kevin can focus on the SWIG patches. cheers alex From wxruby at qualitycode.com Sat Aug 12 23:20:48 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sat, 12 Aug 2006 23:20:48 -0400 Subject: [Wxruby-users] Documentation for wxRuby In-Reply-To: <44DE7601.7090606@pressure.to> References: <44DE1EDE.4080700@pressure.to> <44DE7601.7090606@pressure.to> Message-ID: <1155439248.5484.7.camel@localhost.localdomain> On Sun, 2006-08-13 at 01:44 +0100, Alex Fenton wrote: > Perhaps in the longer run we want to run this sort of process once to > create a base set of class ref docs. These live in our VCS, and we > hand-edit them to reflect wxRuby specifics (deleting irrelevant stuff, > adding Ruby examples, correcting Ruby-specific method sigs etc). This is > similar to what we did with the Wx header files. The question then would > be what format we use as our base - what do people think about: > > - LaTeX? (we have it, but how many of us know LaTeX? And no ri output) > - rdoc (doesn't seem well suited for SWIGged C extensions - FXRuby get > round it by maintaining a dummy set of rb files with the documentation) > - rdtool (is this project still alive? can't find much documentation) > - html (easy, but not very semantic) > - DocBook (very nice output, verbose to generate & edit, overkill?) Other options would be the lightweight markup languages like markdown, textile, etc... http://en.wikipedia.org/wiki/List_of_lightweight_markup_languages Fewer tools, but FAR easier to maintain and update. To me, they fit the agility of Ruby. Kevin From alex at pressure.to Sun Aug 13 05:21:08 2006 From: alex at pressure.to (Alex Fenton) Date: Sun, 13 Aug 2006 10:21:08 +0100 Subject: [Wxruby-users] Documentation for wxRuby In-Reply-To: <1155439248.5484.7.camel@localhost.localdomain> References: <44DE1EDE.4080700@pressure.to> <44DE7601.7090606@pressure.to> <1155439248.5484.7.camel@localhost.localdomain> Message-ID: <44DEEF04.8010807@pressure.to> > Other options would be the lightweight markup languages like markdown, > textile, etc... I think that's an excellent idea; they seem a better fit than any of the 'formal' doc standards I mentioned. I'd suggest textile as it has both a good ruby implementation (redcloth) and a comprehensive and clear syntax. It includes id'd paras and headings which are very useful for creating cross-refs eg to particular methods. AFAIK markdown/bluecloth doesn't have these. If we wanted to create a PDF format for print, we could always use something like HTMLDoc (free HTML->PDF converter). I don't personally use ri much anyway. I'll perhaps have a shot at adapting Sean's work to output textile. alex From wxruby at qualitycode.com Sun Aug 13 09:09:23 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 13 Aug 2006 09:09:23 -0400 Subject: [Wxruby-users] small patch for wxWindow::GetTextExtent In-Reply-To: References: Message-ID: <1155474564.11659.3.camel@localhost.localdomain> I just (finally) committed these patches into the wxruby2 cvs tree. Woo-hoo! Ideally, when submitting patches: 1. Please bundle related patches in a single email, and split unrelated patches into separate emails. I split this one into two parts. This will be especially important when we move to a changeset-based vcs tool like svn (or bzr). 2. For code style, I prefer "int* x" over "int * x" (both of those are better than "int *x"). Not a huge deal. Thanks, Kevin On Wed, 2006-07-19 at 09:16 -0700, Sean Long wrote: > Here is a cleaner patch with the proper directory name, has been > awhile since I made a patch. :) > > Sean > > On 7/18/06, Sean Long wrote: > > I have not worked on wxRuby2 for awhile and decided to download the > > latest CVS HEAD and saw that it still had a problem with > > wxWindow::GetTextExtent (in my case showing up when editing Grid > > cells). So I copied the method signature from the wxDC::GetTextExtent > > which seems to be working, changed 2 variable names and made the > > typemap the same as used for wxDC. Well in my program editing grid > > cells does not crash anymore. > > > > This patch also has the global function wxGetKeyState added, which > > needed a few typemaps as well. > > > > > > The list has been pretty quiet is anyone else working on anything? > > > > > > Sean > > > > > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users From wxruby at qualitycode.com Sun Aug 13 09:17:49 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 13 Aug 2006 09:17:49 -0400 Subject: [Wxruby-users] small Window.i patch In-Reply-To: <44C52E0D.4030702@pressure.to> References: <44C52E0D.4030702@pressure.to> Message-ID: <1155475070.11659.8.camel@localhost.localdomain> On Mon, 2006-07-24 at 21:31 +0100, Alex Fenton wrote: > Hi > > Attached a small patch to Window.i which prevents it crashing when > find_window_by_name, find_window_by_id or find_window_by_label should > return nil. I'm glad to see this fixed, but I haven't applied this patch because I don't think this is the best way to deal with it. Instead of surrounding every get_ruby_object call with an if(obj), why not just change get_ruby_object to detect a null object and immediately return Qnil? Not only would it be less code, but it would also protect us in the future if anyone forgot to check obj before calling get_ruby_object. Can you submit a new patch taking that approach? Thanks, Kevin Here'a a fragment of the submitted patch, for reference: > { > VALUE returnVal = Qnil; > wxObject* obj = wxWindow::FindWindowById(id,parent); > + if (obj) > + { > returnVal = get_ruby_object(obj); > + } From wxruby at qualitycode.com Sun Aug 13 09:40:13 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 13 Aug 2006 09:40:13 -0400 Subject: [Wxruby-users] MiniFrame.i In-Reply-To: <44C5BDA3.40206@pressure.to> References: <44C54DB3.3090902@pressure.to> <44C5BDA3.40206@pressure.to> Message-ID: <1155476413.11659.15.camel@localhost.localdomain> On Tue, 2006-07-25 at 07:43 +0100, Alex Fenton wrote: > >> Another little patch, adding MiniFrame (a frame with small title bar and > >> buttons which doesn't appear in the desktop taskbar). > >> > >> Also a sample - not very interesting, happy to roll this into something > >> else if that's better. > > > Oops, thanks, revised sample attached. I applied this, after changing the sample About Box to use Wx::message_box instead of just message_box, because the latter crashed for me. I'm not really happy with the sample. First, the miniframe comes up behind the main window for me, so I didn't even notice it at first. Second, and more importantly, there is no clean way to exit. Choosing File/Exit aborts with an error, and hitting the X close box on the main frame leaves the miniframe active, with no way to close it. I put the sample in etc/ and would really appreciate if you could submit a patch to improve it. Thanks, Kevin From wxruby at qualitycode.com Sun Aug 13 09:45:18 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 13 Aug 2006 09:45:18 -0400 Subject: [Wxruby-users] Added class wxNumberEntryDialog In-Reply-To: References: Message-ID: <1155476719.11659.16.camel@localhost.localdomain> On Mon, 2006-07-24 at 23:45 -0700, Sean Long wrote: > While playing around with it I added > wxNumberEntryDialog, which it wraps, to see if the problem is in > wxNumberEntryDialog or get_number_from_user. They both have the same > problem so it is in wxNumberEntryDialog. > > Still have not found the problem but we got a new class out of it. Applied. Thanks. Kevin From wxruby at qualitycode.com Sun Aug 13 10:23:51 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 13 Aug 2006 10:23:51 -0400 Subject: [Wxruby-users] Wizards In-Reply-To: <44C66F5F.6040106@pressure.to> References: <44C66F5F.6040106@pressure.to> Message-ID: <1155479031.11659.20.camel@localhost.localdomain> On Tue, 2006-07-25 at 20:22 +0100, Alex Fenton wrote: > Please find attached a set of patches and swig files to implement > Wizards for wxruby. Also a brief sample. Cool! > Quick q - the C declarations of evt_xxx_xxx methods and their attaching > to Ruby classes seems to be duplicated across Events.i and EvtHandler.i > - is one of these the right place to be adding them? or both? I actually got compile errors because the Wizard stuff was added in too many places. As long as the EVT's are in swig/classes/include/events.rb, you shouldn't have to add them to Events.i. The fixevents.rb post-processor will add them to Events.cpp automatically. After I removed them from Events.i, it compiled and the sample seemed to work fine. I put it in samples/etc/. Thanks, Kevin From wxruby at qualitycode.com Sun Aug 13 10:29:14 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 13 Aug 2006 10:29:14 -0400 Subject: [Wxruby-users] GenericDirCtrl In-Reply-To: <44CF959E.9030105@pressure.to> References: <44CF959E.9030105@pressure.to> Message-ID: <1155479354.11659.24.camel@localhost.localdomain> On Tue, 2006-08-01 at 18:55 +0100, Alex Fenton wrote: > A little patch to add Wx::GenericDirCtrl. A non-native control (on OS X > at least) but maybe useful to someone. I have tested it but think it > should just be added to controls.rb sample - will do later when i have > fixed some other probs with that. Applied, thanks. > Also, I've started putting class-specifc style constants in the relevant > .i file, as discussed previosuly - will submit a patch doing this for > existing classes down the line. Great. > Lastly have added a page to the wiki showing class support by category - > looks a lot better for wxruby2 done this way, shows how much of the core > GUI api we support now. > > http://wxruby.rubyforge.org/wiki/wiki.pl?ClassesSupportedByCategory Very nice! Kevin From stephen.ng at planetnutek.com Sun Aug 13 10:49:09 2006 From: stephen.ng at planetnutek.com (Stephen Ng) Date: Sun, 13 Aug 2006 22:49:09 +0800 Subject: [Wxruby-users] error compiling wxruby2 Message-ID: <44DF3BE5.40500@planetnutek.com> Alex, Thanks for your reply. I tried installing SWIG 1.3.29 from the rpm. It had a dependency on rtld (GNU_HASH). I cannot seem to find the code for rtld anywhere. Stephen Ng From roys at mindspring.com Sun Aug 13 10:59:01 2006 From: roys at mindspring.com (Roy Sutton) Date: Sun, 13 Aug 2006 10:59:01 -0400 Subject: [Wxruby-users] small patch for wxWindow::GetTextExtent In-Reply-To: <1155474564.11659.3.camel@localhost.localdomain> References: <1155474564.11659.3.camel@localhost.localdomain> Message-ID: <44DF3E35.4090105@mindspring.com> Kevin Smith wrote: > 2. For code style, I prefer "int* x" over "int * x" (both of those are > better than "int *x"). Not a huge deal. > > Hmm, not to get into a style war, but I find int* x to be somewhat ambiguous: int* x,y; The type of y isn't int*, which is what int* 'implies'. I'd pick int * x over int* x any day. Though, for clarity, int *x is my choice. Roy From wxruby at qualitycode.com Sun Aug 13 11:10:07 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 13 Aug 2006 11:10:07 -0400 Subject: [Wxruby-users] SashWindows In-Reply-To: <44CF9255.4030905@pressure.to> References: <44CF9255.4030905@pressure.to> Message-ID: <1155481807.11659.36.camel@localhost.localdomain> On Tue, 2006-08-01 at 18:41 +0100, Alex Fenton wrote: > Hi > > Please find attached a set of patches to implement Sash Layouts plus a > little sample. The patches didn't apply cleanly, probably because I have already merged in other changes. I was able to move them around to make them fit. I got compile errors in LayoutAlgorithm, so I had to remove the "const" qualifiers on three of the methods in wxLayoutAlgorithm.h. While I was in there, I fixed the copyright notice and removed the messy comments. Then I was getting runtime errors because we had declared SASH to be MSWindows-only. I changed that (in fixevents.rb), and the sample app could run...but has some problems: 1. The draggable sash borders don't appear 2. Dragging the horizontal sash does nothing 3. Dragging the vertical sash crashes with a runtime error Let me know if you need more details. I'm hoping you can submit fixes to get the sample working, now that the basic code has been merged. New topic: I would like to include some kind of license at the top of every sample file, saying that this code can be used for any purpose, without attribution. Without that, it is not clear to our users that they are free to use code fragments in their own code, without restriction. Any ideas what wording we could use? I'm not sure "public domain" is the right answer, because we are the primary source/author. Thanks, Kevin From wxruby at qualitycode.com Sun Aug 13 11:13:18 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 13 Aug 2006 11:13:18 -0400 Subject: [Wxruby-users] additions to wxKeyEvent In-Reply-To: References: Message-ID: <1155481998.11659.37.camel@localhost.localdomain> On Tue, 2006-08-01 at 16:18 -0700, Sean Long wrote: > Added the public variables like m_KeyCode and m_controlDown, these are > needed it you want to create your own EVT_CHAR message to send a > widget. Applied, thanks. Those names are pretty ugly with the leading m_ stuff. At some point we should provide friendlier aliases. Kevin From wxruby at qualitycode.com Sun Aug 13 11:17:22 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 13 Aug 2006 11:17:22 -0400 Subject: [Wxruby-users] small patch for wxWindow::GetTextExtent In-Reply-To: <44DF3E35.4090105@mindspring.com> References: <1155474564.11659.3.camel@localhost.localdomain> <44DF3E35.4090105@mindspring.com> Message-ID: <1155482242.11659.42.camel@localhost.localdomain> On Sun, 2006-08-13 at 10:59 -0400, Roy Sutton wrote: > Kevin Smith wrote: > > 2. For code style, I prefer "int* x" over "int * x" (both of those are > > better than "int *x"). Not a huge deal. > > > > > Hmm, not to get into a style war, but I find int* x to be somewhat > ambiguous: > > int* x,y; > > The type of y isn't int*, which is what int* 'implies'. I'd pick int * > x over int* x any day. Though, for clarity, int *x is my choice. I see your point, but I strongly feel that you should NEVER declare more than one variable on a line. I consider it to be a bug in the language design. I think of it as "x is an int*", so having the * next to x is just confusing. Perhaps we should go with "int * x" then, as a compromise. Kevin From wxruby at qualitycode.com Sun Aug 13 12:04:45 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 13 Aug 2006 12:04:45 -0400 Subject: [Wxruby-users] ScrollWinEvent In-Reply-To: <44DB3CD4.2050602@pressure.to> References: <5d0946540608030919h865c882r21f2b6be7c11978a@mail.gmail.com> <44D23690.9020702@pressure.to> <5d0946540608041440ufee7f9cu211b3682edf976cc@mail.gmail.com> <44D7BCB8.8070504@pressure.to> <5d0946540608091344p47ab7a6tad26c540b11124ff@mail.gmail.com> <44DB3CD4.2050602@pressure.to> Message-ID: <1155485085.11659.45.camel@localhost.localdomain> On Thu, 2006-08-10 at 15:04 +0100, Alex Fenton wrote: > Anyway I adapted your sample to the attached scrollwin.rb, which uses > the Wx::ScrolledWindow class. Then I used it to test adding > ScrollWinEvent to wxruby2. It all seems to work well - though I can't > figure out how evt_scrollwin_top is supposed to be generated? I added Wx::CLOSE_BOX to the frame constructor so there would be a way to close the app. > People - sorry for adding to the backlog, but would be nice if we could > squeeze this into alpha1. It's a little patch, seems a fairly core > class, and ScrolledWindow is already in there. Might need to up your > 'fuzz' settings when appying this patch. No problems applying it. Since I am in a merging mood, I went ahead and took this patch. Thanks (to both Alex and Joe), Kevin From wxruby at qualitycode.com Sun Aug 13 12:10:29 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 13 Aug 2006 12:10:29 -0400 Subject: [Wxruby-users] error compiling wxruby2 In-Reply-To: <44DB57D0.7080209@pressure.to> References: <44DB4529.2090001@planetnutek.com> <44DB57D0.7080209@pressure.to> Message-ID: <1155485430.11659.49.camel@localhost.localdomain> Very strange. The slower SWIG check should have detected that you were running an older version of SWIG. If anyone still have SWIG 1.3.24, it would be great if they could try running this from the top wxruby2 directory: ruby swig/swigver.rb It should print "SWIG Version 1.3.24". If it doesn't, it would be great if you could debug swigver.rb to find out what is going wrong. Thanks, Kevin On Thu, 2006-08-10 at 16:59 +0100, Alex Fenton wrote: > Hi Stephen > > Thanks for your message. I don't have Linux available but I see from > this post: > > http://rubyforge.org/pipermail/wxruby-users/2005-August/001454.html > > that SWIG version 1.3.24 probably won't work with current wxruby2. > > Can you try downloading latest SWIG (1.3.29) and re-running rake please? > > Sorry for the inconvenience - SWIG for ruby had a lot of incompatible > changes over these versions. I'll see if we can improve the check for a > good version in our Rakefile. > > Thanks > alex > > > Stephen Ng wrote: > > I'm just starting to try out wxruby. I downloaded the CVS and executed > > rake. I received the following error - > > SWIG Version 1.3.24 > > Copyright (c) 1995-1998 > > University of Utah and the Regents of the University of California > > Copyright (c) 1998-2004 > > University of Chicago > > Compiled with i386-redhat-linux-g++ [i386-redhat-linux-gnu] > > > > Please see http://www.swig.org for reporting bugs and further information > > Doing slower check for SWIG 1.3.29 > > ** Invoke default (first_time) > > ** Invoke link (first_time) > > ** Invoke lib/wxruby2.so (first_time) > > ** Invoke obj/App.o (first_time) > > rake aborted! > > Don't know how to build task 'src/App.cpp' > > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1449:in `[]' > > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in > > `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in > > `each' > > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in > > `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in > > `invoke' > > /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' > > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' > > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in > > `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in > > `each' > > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in > > `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in > > `invoke' > > /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' > > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' > > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in > > `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in > > `each' > > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in > > `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in > > `invoke' > > /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' > > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' > > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in > > `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in > > `each' > > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in > > `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in > > `invoke' > > /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' > > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' > > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in `run' > > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in `run' > > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/bin/rake:7 > > /usr/bin/rake:18 > > > > I'm running Fedora 5 with swig-1.3.24, wxGTK-2.6.3-2.6.3.2.2.fc5, > > rake-0.7.1. > > > > Any help/suggestions would be appreciated. > > > > Thanks. > > > > Stephen Ng > > _______________________________________________ > > wxruby-users mailing list > > wxruby-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > > > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users From roys at mindspring.com Sun Aug 13 13:54:09 2006 From: roys at mindspring.com (Roy Sutton) Date: Sun, 13 Aug 2006 13:54:09 -0400 Subject: [Wxruby-users] Ruport Day Message-ID: <44DF6741.9000902@mindspring.com> Here's an idea we might want to look at just after we do the alpha release: http://ruport.infogami.com/RuportDay2006 The basic premise is 24 hours of testing, debugging and coding focused on one app. They announced to the ruby mailing lists and have prizes they arranged (Could we get a sponsor? I don't know.) Personally, I think prize money opens a can of worms. But a public acknowledgment if usually welcome to open source contributors. I'd even suggest we involve the wxWidgets people, perhaps someone there can merge in the Ruby notes to their source tree. I think the alpha release will generate a lot of interest. We can help build on that later as we get close to the first release of the new version with a wxRuby day. Thoughts? Roy From wxruby at qualitycode.com Sun Aug 13 14:01:06 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 13 Aug 2006 14:01:06 -0400 Subject: [Wxruby-users] bzr / Subversion / CVS In-Reply-To: <200608112120.k7BLKXEI011116@gandalf.savarese.org> References: <200608112120.k7BLKXEI011116@gandalf.savarese.org> Message-ID: <1155492066.11659.53.camel@localhost.localdomain> On Fri, 2006-08-11 at 17:20 -0400, Daniel F. Savarese wrote: > Kevin Smith writes > : > >Can someone who has used SVN comment? > > I started reading it and stopped before finishing because the author > is judging Subversion by using it in a way that doesn't make any sense > for Subversion. Fair enough. Can you confirm that merging between branches within an svn repository works well? The article implies that it does not. > Subversion is great for supporting the Apache development model but > sucks for supporting the Linux kernel development model. Sounds about right. I think the Linux kernel model is closer to ideal for most FLOSS projects, including this one. But I think svn is enough of an improvement to be worth moving to it now, realizing that we will probably move again later (to something more distributed). Thanks for the info, Kevin From wxruby at qualitycode.com Sun Aug 13 14:39:11 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 13 Aug 2006 14:39:11 -0400 Subject: [Wxruby-users] update on samples In-Reply-To: <44DB76AD.50901@pressure.to> References: <44DB76AD.50901@pressure.to> Message-ID: <1155494351.11659.88.camel@localhost.localdomain> On Thu, 2006-08-10 at 19:10 +0100, Alex Fenton wrote: > One general issue is that many of the samples rely on being run from > their own directory, but don't enforce this. How do people feel about > samples doing: > > Dir.chdir( File.dirname( __FILE__ ) ) > > if the sample should be run from the current directory only? Hm. I'm not too fond of that approach, but wouldn't fight against it. > Alternately, some can be recoded to load resources relative to the > script dir, not the dir that ruby was run from, and fixed in this way. I think that's probably the best option. The other approach, which I took with one of the samples, is to simply refuse to run if the current directory is wrong. That might be a quick and dirty solution for this alpha release (or shortly after). > Notes on individual scripts Thanks for doing this. I haven't looked at all the samples for a long time, and it's nice to see how many of them do work well. > - bigdemo.rb > Mostly OK, and a nice script as well. But issues when not run from > current dir. Also some items don't quite display right in the little > pane (eg Wx::Choice) I really like bigdemo, but it doesn't seem to work as well for me as it does for you. Platform issues, perhaps? First, it would be great if we could rename Main.rbw to bigdemo.rb(w) to be more consistent with the other samples. Within a couple minutes of starting bigdemo, it always crashes, presumably due to a garbage collection issue. The crash handler then falls into a loop of: addr2line: 'wxruby': No such file And then pops up a dialog offering to terminate the app. The wxGauge demo seems to make it happen right away. I get a segfault when pressing the "MDI demo" button: (wxruby:25518): Gtk-CRITICAL **: gtk_window_realize_icon: assertion `info->icon_pixmap == NULL' failed ./MDIDemo.rbw:21: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] Changing fonts crashes: (wxruby:25723): Gtk-CRITICAL **: gtk_window_set_transient_for: assertion `parent == NULL || GTK_IS_WINDOW (parent)' failed ./wxFontDialog.rbw:80:in `set_label': can't convert nil into String (TypeError) from ./wxFontDialog.rbw:80:in `update_ui' from ./wxFontDialog.rbw:104:in `on_select_font' from ./wxFontDialog.rbw:8:in `initialize' from Main.rbw:551 ./wxFontDialog.rbw:80: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] The text for PopupMenu should say that you have to right-click in the blank area around the text. I tried clicking inside the text and nothing happened, but then I tried outside and it worked fine. wxComboBox pops up an error dialog A problem occurred with the wxComboBox demo: No matching function for overloaded 'wxComboBox_Append' ./wxComboBox.rbw:22:in `append' ./wxComboBox.rbw:22:in `initialize' ./wxComboBox.rbw:52:in `run' Main.rbw:396:in `run_demo' Main.rbw:356:in `on_tree_sel_changed' Main.rbw:287:in `initialize' Main.rbw:551 The scrolling list jumps farther than it should for a mouse wheel movement. It should be 2-3 items but is 6. I'm not sure if that's set in ruby code or is part of wx. wxScrolledWindow fails: ./wxScrolledWindow.rbw:49:in `do_drawing': undefined method `get_text_extent' for # (NoMethodError) from ./wxScrolledWindow.rbw:35:in `on_paint' from ./wxScrolledWindow.rbw:26:in `initialize' from Main.rbw:551 wxStatusBar brings up an error dialog, and then immediately goes to the loop/terminate problem mentioned above. I can't copy the error message, but the short version is that set_status_text hits a "Swig director type mismatch in output value of type 'bool'" wxTextCtrl crashes: ./wxTextCtrl.rbw:11:in `on_kill_focus': undefined method `write' for # (NoMethodError) from ./wxTextCtrl.rbw:31:in `initialize' from Main.rbw:416:in `run_demo' from Main.rbw:356:in `on_tree_sel_changed' from Main.rbw:287:in `initialize' from Main.rbw:551 ./wxTextCtrl.rbw:11: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i486-linux] wxToggleButton gives an error dialog: A problem occurred with the wxToggleButton demo: undefined method `evt_togglebutton' for # ./wxToggleButton.rbw:11:in `initialize' ./wxToggleButton.rbw:9:in `initialize' ./wxToggleButton.rbw:26:in `run' Main.rbw:396:in `run_demo' Main.rbw:356:in `on_tree_sel_changed' Main.rbw:287:in `initialize' Main.rbw:551 wxTreeControl gives an error dialog: A problem occurred with the wxTreeCtrl demo: undefined method `get_icon' for Wxruby2::ArtProvider:Class ./wxTreeCtrl.rbw:57:in `initialize' ./wxTreeCtrl.rbw:160:in `run' Main.rbw:396:in `run_demo' Main.rbw:356:in `on_tree_sel_changed' Main.rbw:287:in `initialize' Main.rbw:551 wxLayoutConstraints doesn't appear to be doing the right thing, but it's hard to tell since I don't know what the right thing is. I have a big purple area, but the upper left square centimeter is green, with the letters "Pa" in it. I tried Help/Find, and when I hit OK I crashed with: Illegal instruction > - caret.rb > OK - but arrow keys don't work properly (should they?) After there is text entered, the arrow keys work fine for me. > - dialogs.rb > Problems with DC - seems to cause ObjectPreviouslyDeleted error in an > on_paint handler. I have worked round this. MDI, ColourDialog crashes on > OS X. I have no trouble with DC or the color dialog. But the Busy Info dialog puts up an ugly gray box (with no border filled with question marks. If you hit Cancel from the Find (or Find/Replace) dialog, the app segfaults and exits immediately, so the only way out is the not-quite-obvious X close button. The text for the modeless dialog should make it more clear which menu you are supposed to use to close the dialog (It's the main menu of the app, not the window menu of the modeless dialog). > - listbook.rb > OK, except breaks if not run from own directory. Brings up a big blank window for me. If this is only available on certain platforms, we should say so. > - mdi.rb > MDI doesn't work on OS X? Segfaults for me before the main frame is shown. > - minimal.rb > OK - have tidied up and commented a bit more, commit pending The title bar of nothing.rb should probably not say "Minimal", since it is quite different from the minimal sample. Kevin From wxruby at qualitycode.com Sun Aug 13 14:47:43 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 13 Aug 2006 14:47:43 -0400 Subject: [Wxruby-users] Gem and tarball rake tasks In-Reply-To: <44DC4D92.8050501@pressure.to> References: <44DAFAB4.5000700@pressure.to> <1155272312.6713.2.camel@localhost.localdomain> <44DC4D92.8050501@pressure.to> Message-ID: <1155494863.11659.94.camel@localhost.localdomain> On Fri, 2006-08-11 at 10:27 +0100, Alex Fenton wrote: > My thinking here, aside from aesthetics, is that the release we're > working on will eventually (soon?!) supplant the wxruby 0.x.x series, > which were development releases towards wxruby v1.0. Ok. > re Rubyforge I think that the 'odd minor version equals development' > convention is well embedded in Ruby practice generally - eg current core > Ruby. I have never liked that convention much. For development tools (like wxruby) it's ok. For end-user apps, no way. Does 1.0 count as even or odd? What about 2.1? Or 1.2.1? But regardless of that, we should be aiming toward 1.0. I just built a gem. Then I installed it, which said it worked, but when I tried to run a wxruby app it couldn't find wxruby. Is there a way to mention at gem-install time where the samples are being placed? Kevin From wxruby at qualitycode.com Sun Aug 13 14:49:14 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 13 Aug 2006 14:49:14 -0400 Subject: [Wxruby-users] Documentation for wxRuby In-Reply-To: References: Message-ID: <1155494954.11659.96.camel@localhost.localdomain> On Sat, 2006-08-12 at 00:34 -0700, Sean Long wrote: > I have uploaded the generated documentation to my web site so people > can view it. > http://hailstonesoftware.com/_files/Ruby/wxruby/html/wx_contents.html. Very impressive! Kevin From wxruby at qualitycode.com Sun Aug 13 14:54:00 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 13 Aug 2006 14:54:00 -0400 Subject: [Wxruby-users] Ruport Day In-Reply-To: <44DF6741.9000902@mindspring.com> References: <44DF6741.9000902@mindspring.com> Message-ID: <1155495241.11659.100.camel@localhost.localdomain> On Sun, 2006-08-13 at 13:54 -0400, Roy Sutton wrote: > Here's an idea we might want to look at just after we do the alpha release: > > http://ruport.infogami.com/RuportDay2006 > > The basic premise is 24 hours of testing, debugging and coding focused > on one app. They announced to the ruby mailing lists and have prizes > they arranged (Could we get a sponsor? I don't know.) Neat idea. I would be inclined to do it a bit later in the cycle. Maybe after a beta. At least after we have the big crashing bugs fixed. > Personally, I > think prize money opens a can of worms. But a public acknowledgment if > usually welcome to open source contributors. I agree. > I'd even suggest we > involve the wxWidgets people, perhaps someone there can merge in the > Ruby notes to their source tree. Maybe. But if we plan to rubify the api, maybe we don't want the docs changed until after that, to avoid churn. > I think the alpha release will generate a lot of interest. We can help > build on that later as we get close to the first release of the new > version with a wxRuby day. I think the alpha release will cause a signficant bump in downloads and mailing list traffic. Brace yourselves. Kevin From wxruby at qualitycode.com Sun Aug 13 15:01:05 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 13 Aug 2006 15:01:05 -0400 Subject: [Wxruby-users] error compiling wxruby2 In-Reply-To: <44DF3BE5.40500@planetnutek.com> References: <44DF3BE5.40500@planetnutek.com> Message-ID: <1155495665.11659.106.camel@localhost.localdomain> On Sun, 2006-08-13 at 22:49 +0800, Stephen Ng wrote: > I tried installing SWIG 1.3.29 from the rpm. It had a dependency on rtld > (GNU_HASH). I cannot seem to find the code for rtld anywhere. Can't help you with the RPM dependency issues (they are why I switched to Debian years ago). I did find this forum post which mentions a fix for the same problem in a different package: http://fedoranews.org/cms/node/1442 Sounds like it is the responsibility of the SWIG RPM packager to fix. Although I really try to stay within my distro package system, SWIG is one that I install straight from the tarball. Kevin From wxruby at qualitycode.com Sun Aug 13 15:07:02 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 13 Aug 2006 15:07:02 -0400 Subject: [Wxruby-users] Backlog is cleared (was: wxruby2 alpha release goals) In-Reply-To: <1155272660.6713.7.camel@localhost.localdomain> References: <44D103F5.3030407@pressure.to> <1155272660.6713.7.camel@localhost.localdomain> Message-ID: <1155496022.11659.112.camel@localhost.localdomain> On Fri, 2006-08-11 at 01:04 -0400, Kevin Smith wrote: > Just FYI: I am going to try really hard to set aside half a day this > weekend to catch up on wxruby cvs work. Really, really hard. I'm > announcing this as a further incentive to myself, to avoid breaking a > public commitment. And fortunately I was able to follow through. All the July/August patches have been merged (except one that I rejected). I still have a bunch of messages from April to go through, but I believe they were all problem reports, technical discussions, etc. If anyone has submitted patches that I have not responded to, please let me know. > The good news is that two of the four "real life" pressures that have > been taking up my time for the last few months should be mostly finished > tomorrow. The other two are weekday activities, so hopefully I will be > able to put in some wxruby time each weekend for a while. I remain optimistic that I will be able to give wxruby at least 4-8 hours a week this month. Hopefully more after that, but it's hard to predict that far in the future. Kevin From wxruby at qualitycode.com Sun Aug 13 15:12:39 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 13 Aug 2006 15:12:39 -0400 Subject: [Wxruby-users] message_box showing up off-screen on Mac (was: wxruby2 alpha release goals) In-Reply-To: References: <44D103F5.3030407@pressure.to> Message-ID: <1155496359.11659.115.camel@localhost.localdomain> On Wed, 2006-08-02 at 14:21 -0700, Sean Long wrote: > The most annoying bug I have is that pre built dialogs are starting > out with a negative x value for the dialog location and are not being > shown on screen when show() is called. An example of this is in the > caret sample when Wx::message_box() is called for the about box as > well as when Wx::get_number_from_user() is called. This problem exists > on Mac OS X Intel and PPC. Strange. The wx api clearly shows default values of -1 for the x and y parameters. Looking at the wxruby code, it would seem that we are indeed passing -1, -1 if those are not passed in from ruby. So it sounds like an upstream bug in the Mac version of wx. Kevin From wxruby at qualitycode.com Sun Aug 13 15:19:17 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 13 Aug 2006 15:19:17 -0400 Subject: [Wxruby-users] wxruby2 alpha status Message-ID: <1155496758.11659.122.camel@localhost.localdomain> Hi all, How soon can we do our alpha (binary gem) release? 1. I would like to get the samples working a bit better, but am ok simply documenting most of the current problems. Do the samples crash every few minutes for other people? Or is it just me? I would like to have a copyright/license comment at the top of every sample file before the alpha release. 2. I would like to receive and merge a patch that causes get_ruby_object to return Qnil when null is passed in. 3. The gem I built didn't seem to work on my system (Ubuntu GNU/Linux Dapper 6.06). I know almost nothing about gems. The spec looked reasonable at a glance (it included both wx.rb and wxruby2.so). I would be happy to debug it if someone who knows gems could guide me. How close are we to having binary gems for our three main platforms? Anything else? Kevin From roys at mindspring.com Sun Aug 13 16:22:57 2006 From: roys at mindspring.com (Roy Sutton) Date: Sun, 13 Aug 2006 16:22:57 -0400 Subject: [Wxruby-users] message_box showing up off-screen on Mac In-Reply-To: <1155496359.11659.115.camel@localhost.localdomain> References: <44D103F5.3030407@pressure.to> <1155496359.11659.115.camel@localhost.localdomain> Message-ID: <44DF8A21.6000809@mindspring.com> This is a SWIG bug, the same as I was mentioning before. Roy Kevin Smith wrote: > On Wed, 2006-08-02 at 14:21 -0700, Sean Long wrote: > >> The most annoying bug I have is that pre built dialogs are starting >> out with a negative x value for the dialog location and are not being >> shown on screen when show() is called. An example of this is in the >> caret sample when Wx::message_box() is called for the about box as >> well as when Wx::get_number_from_user() is called. This problem exists >> on Mac OS X Intel and PPC. >> > > Strange. The wx api clearly shows default values of -1 for the x and y > parameters. Looking at the wxruby code, it would seem that we are indeed > passing -1, -1 if those are not passed in from ruby. So it sounds like > an upstream bug in the Mac version of wx. > > Kevin > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > From wxruby at qualitycode.com Sun Aug 13 17:16:59 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 13 Aug 2006 17:16:59 -0400 Subject: [Wxruby-users] message_box showing up off-screen on Mac In-Reply-To: <44DF8A21.6000809@mindspring.com> References: <44D103F5.3030407@pressure.to> <1155496359.11659.115.camel@localhost.localdomain> <44DF8A21.6000809@mindspring.com> Message-ID: <1155503819.5863.11.camel@localhost.localdomain> There may be a SWIG bug, but that's not what is causing the message box to come up in the wrong place. At least, not from what I am seeing. Unless it's a Mac-specific SWIG bug, which seems unlikely. The C++ wrapper generated by swig appears to correctly default x and y to -1 values. It then calls the wx MessageBox function. At that point, if wx doesn't recognize -1,-1 as being the "default position", that would be a bug in the Mac implementation of wx. Maybe I'm missing something. Kevin On Sun, 2006-08-13 at 16:22 -0400, Roy Sutton wrote: > This is a SWIG bug, the same as I was mentioning before. > > Roy > > Kevin Smith wrote: > > On Wed, 2006-08-02 at 14:21 -0700, Sean Long wrote: > > > >> The most annoying bug I have is that pre built dialogs are starting > >> out with a negative x value for the dialog location and are not being > >> shown on screen when show() is called. An example of this is in the > >> caret sample when Wx::message_box() is called for the about box as > >> well as when Wx::get_number_from_user() is called. This problem exists > >> on Mac OS X Intel and PPC. > >> > > > > Strange. The wx api clearly shows default values of -1 for the x and y > > parameters. Looking at the wxruby code, it would seem that we are indeed > > passing -1, -1 if those are not passed in from ruby. So it sounds like > > an upstream bug in the Mac version of wx. > > > > Kevin > > > > > > _______________________________________________ > > wxruby-users mailing list > > wxruby-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > > > > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users From roys at mindspring.com Sun Aug 13 17:50:55 2006 From: roys at mindspring.com (Roy Sutton) Date: Sun, 13 Aug 2006 17:50:55 -0400 Subject: [Wxruby-users] message_box showing up off-screen on Mac In-Reply-To: <1155503819.5863.11.camel@localhost.localdomain> References: <44D103F5.3030407@pressure.to> <1155496359.11659.115.camel@localhost.localdomain> <44DF8A21.6000809@mindspring.com> <1155503819.5863.11.camel@localhost.localdomain> Message-ID: <44DF9EBF.8070507@mindspring.com> Kevin, What you're missing is that deep down in the bowels of Wx it's calling back to a function wrapped by SWIG. When it gets passed off through the director the return values for where it should go aren't returned to the calling function. At least, that's what I recall. It took me quite a while to discover what was happening. It may be my recollection is off. I know the problem occurs with wrapping GetTextExtent. I think it also affected a couple others. Roy Kevin Smith wrote: > There may be a SWIG bug, but that's not what is causing the message box > to come up in the wrong place. At least, not from what I am seeing. > Unless it's a Mac-specific SWIG bug, which seems unlikely. > > The C++ wrapper generated by swig appears to correctly default x and y > to -1 values. It then calls the wx MessageBox function. At that point, > if wx doesn't recognize -1,-1 as being the "default position", that > would be a bug in the Mac implementation of wx. > > Maybe I'm missing something. > > Kevin > > On Sun, 2006-08-13 at 16:22 -0400, Roy Sutton wrote: > >> This is a SWIG bug, the same as I was mentioning before. >> >> Roy >> >> Kevin Smith wrote: >> >>> On Wed, 2006-08-02 at 14:21 -0700, Sean Long wrote: >>> >>> >>>> The most annoying bug I have is that pre built dialogs are starting >>>> out with a negative x value for the dialog location and are not being >>>> shown on screen when show() is called. An example of this is in the >>>> caret sample when Wx::message_box() is called for the about box as >>>> well as when Wx::get_number_from_user() is called. This problem exists >>>> on Mac OS X Intel and PPC. >>>> >>>> >>> Strange. The wx api clearly shows default values of -1 for the x and y >>> parameters. Looking at the wxruby code, it would seem that we are indeed >>> passing -1, -1 if those are not passed in from ruby. So it sounds like >>> an upstream bug in the Mac version of wx. >>> >>> Kevin >>> >>> >>> _______________________________________________ >>> wxruby-users mailing list >>> wxruby-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wxruby-users >>> >>> >>> >>> >>> >> _______________________________________________ >> wxruby-users mailing list >> wxruby-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wxruby-users >> > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > From ruby at portfolio16.de Sun Aug 13 18:41:39 2006 From: ruby at portfolio16.de (Tobias Gruetzmacher) Date: Mon, 14 Aug 2006 00:41:39 +0200 Subject: [Wxruby-users] bzr / Subversion / CVS In-Reply-To: <1155492066.11659.53.camel@localhost.localdomain> References: <200608112120.k7BLKXEI011116@gandalf.savarese.org> <1155492066.11659.53.camel@localhost.localdomain> Message-ID: <20060813224139.GC24299@portfolio16.de> Hi, On Sun, Aug 13, 2006 at 02:01:06PM -0400, Kevin Smith wrote: > Can you confirm that merging between branches within an svn repository > works well? The article implies that it does not. It does not. SVN does not record ANY meta-information for merges. After the merge the merge-commit is not distinguishable from any other commit. Merging repeatedly from one branch to another is kludgy if you forgot your last "merge-point" (and forgot to note it in your last merge-commit). Even the Subversion book admits[1]: "Ideally, your version control system should prevent the double-application of changes to a branch. It should automatically remember which changes a branch has already received, and be able to list them for you. It should use this information to help automate merges as much as possible. Unfortunately, Subversion is not such a system. Like CVS, Subversion does not yet record any information about merge operations. When you commit local modifications, the repository has no idea whether those changes came from running svn merge, or from just hand-editing the files." I find that unacceptable for my personal work and only use SVN when I'm forced to. SVK adds meta-infos about merges and also has an implementation of tla's star-merge, but for it to work reliable everybody doing merges in the repository must use SVK. Greetings, Tobi [1] http://svnbook.red-bean.com/en/1.2/svn.branchmerge.copychanges.html#svn.branchmerge.copychanges.bestprac -- GPG-Key 0xE2BEA341 - signed/encrypted mail preferred My, oh so small, homepage: http://portfolio16.de/ http://www.fli4l.de/ - ISDN- & DSL-Router on one disk! Registered FLI4L-User #00000003 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://rubyforge.org/pipermail/wxruby-users/attachments/20060814/2e97ef82/attachment.bin From alex at pressure.to Sun Aug 13 19:30:15 2006 From: alex at pressure.to (Alex Fenton) Date: Mon, 14 Aug 2006 00:30:15 +0100 Subject: [Wxruby-users] update on samples In-Reply-To: <1155494351.11659.88.camel@localhost.localdomain> References: <44DB76AD.50901@pressure.to> <1155494351.11659.88.camel@localhost.localdomain> Message-ID: <44DFB607.6080703@pressure.to> >> Dir.chdir( File.dirname( __FILE__ ) ) >> >> if the sample should be run from the current directory only? >> > > Hm. I'm not too fond of that approach, but wouldn't fight against it. > Fair enough. I haven't gone with this approach with any of the samples so far. >> Alternately, some can be recoded to load resources relative to the >> script dir, not the dir that ruby was run from, and fixed in this way. >> > > I think that's probably the best option. > I've checked in changes for this approach for both the samples that use XRC (listbook and xrc) and for the icon in minimal. >> - bigdemo.rb >> Mostly OK, and a nice script as well. But issues when not run from >> current dir. Also some items don't quite display right in the little >> pane (eg Wx::Choice) >> > > I really like bigdemo, but it doesn't seem to work as well for me as it > does for you. Platform issues, perhaps? > Thanks for the detailed info. Will look into the specific issues. The display isn't great on OS X either - some work well, some don't. And I was getting some GC crashers, but think I found a way to ameliorate these - will dig around in an old working tree. Also MDI seems to crash - I wonder how it works on Windows - the only place there is a native control for this. > First, it would be great if we could rename Main.rbw to bigdemo.rb(w) to > be more consistent with the other samples. > Will do. I think I prefer the .rb extension because for Windows users if something goes wrong at least the exception is spewed somewhere visible. Is that too pessimistic? ;) > wxLayoutConstraints doesn't appear to be doing the right thing, but it's > hard to tell since I don't know what the right thing is. I have a big > purple area, but the upper left square centimeter is green, with the > letters "Pa" in it. > Should we drop LayoutConstraints - it is deprecated in Wx? >> - caret.rb >> OK - but arrow keys don't work properly (should they?) >> > > After there is text entered, the arrow keys work fine for me. > Nope, definitely busted on OS X. Each key press advances the cursor one space - as if it's adding a non-printable char. Urgh. The code looks right - cross-platform stuff that Wx should handle. >> - dialogs.rb >> Problems with DC - seems to cause ObjectPreviouslyDeleted error in an >> on_paint handler. I have worked round this. MDI, ColourDialog crashes on >> OS X. >> > > I have no trouble with DC or the color dialog. But the Busy Info dialog > puts up an ugly gray box (with no border filled with question marks. If > you hit Cancel from the Find (or Find/Replace) dialog, the app segfaults > and exits immediately, so the only way out is the not-quite-obvious X > close button. > BusyInfo seems now to crash on OS X. No problems with Cancel on FindDialog. > The text for the modeless dialog should make it more clear which menu > you are supposed to use to close the dialog (It's the main menu of the > app, not the window menu of the modeless dialog). > Agreed, will change and check in. >> - listbook.rb >> OK, except breaks if not run from own directory. >> > > Brings up a big blank window for me. If this is only available on > certain platforms, we should say so. > Could you confirm that this isn't a problem with loading the XRC - I committed a fix to load the XRC from the right place even if the script is run from elsewhere. > The title bar of nothing.rb should probably not say "Minimal", since it > is quite different from the minimal sample. > Didn't look at this one, sorry, will follow-up. cheers alex From sean.m.long at gmail.com Mon Aug 14 03:05:45 2006 From: sean.m.long at gmail.com (Sean Long) Date: Mon, 14 Aug 2006 00:05:45 -0700 Subject: [Wxruby-users] Patch for functions.i Message-ID: Here is a patch that adds five functions that are missing, there is actually quite a few missing but I needed these for some testing. Sean -------------- next part -------------- A non-text attachment was scrubbed... Name: functions_i.patch Type: application/octet-stream Size: 906 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-users/attachments/20060814/22ce0cca/attachment.obj From sean.m.long at gmail.com Mon Aug 14 03:18:54 2006 From: sean.m.long at gmail.com (Sean Long) Date: Mon, 14 Aug 2006 00:18:54 -0700 Subject: [Wxruby-users] Patch for RubyConstants.i Message-ID: - Added wxDefaultCoord - Updated the standard IDs so they match the 2.6.3 headers which adds wxID_NONE. Sean -------------- next part -------------- A non-text attachment was scrubbed... Name: RubyConstants_i.patch Type: application/octet-stream Size: 1829 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-users/attachments/20060814/ee5a7a32/attachment.obj From sean.m.long at gmail.com Mon Aug 14 03:29:54 2006 From: sean.m.long at gmail.com (Sean Long) Date: Mon, 14 Aug 2006 00:29:54 -0700 Subject: [Wxruby-users] Patch for wxWindow.h Message-ID: This patch updates a few existing methods so the signature matches the wxWidgets headers more exactly and also adds a bunch of missing methods. Sorry for the flood of patches but I was waiting for the pending patches to go thru before submitting these. This should be the last one for tonight. Sean -------------- next part -------------- A non-text attachment was scrubbed... Name: wxWindow_h.patch Type: application/octet-stream Size: 3747 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-users/attachments/20060814/96de8164/attachment.obj From sean.m.long at gmail.com Mon Aug 14 14:46:07 2006 From: sean.m.long at gmail.com (Sean Long) Date: Mon, 14 Aug 2006 11:46:07 -0700 Subject: [Wxruby-users] Patches to rake files Message-ID: rakewx.rb: - Added a $debug_build variable so when we do eventually we can also release non debug builds. I did not make this a constant on purpose so in the package tasks we can change it to false if we want to always make non debug builds by default. - Changed wx_config to use the $debug_build variable rakemswin.rb: - Updated the copyright year. - removed the $DEBUG const and make use of $debug_build instead. rakemacosx.rb: - Updated the copyright year. - Removed $wx_version = "2.6.1" because it is set in use_wx_config above. - Removed commented out code, it has not been used in awhile and we can always look in CVS if we need it again. - Updated the framework task values to use 2.0 as the version instead of 0.5, can be changed again to whatever we go with. Also updated the copyright info. Sean -------------- next part -------------- A non-text attachment was scrubbed... Name: rakewx_rb.patch Type: application/octet-stream Size: 781 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-users/attachments/20060814/dd79da63/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: rakemswin_rb.patch Type: application/octet-stream Size: 1051 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-users/attachments/20060814/dd79da63/attachment-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: rakemacosx_rb.patch Type: application/octet-stream Size: 2445 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-users/attachments/20060814/dd79da63/attachment-0002.obj From joiey.seeley at gmail.com Mon Aug 14 16:51:13 2006 From: joiey.seeley at gmail.com (Joe Seeley) Date: Mon, 14 Aug 2006 15:51:13 -0500 Subject: [Wxruby-users] Windows build? In-Reply-To: <200608121759.k7CHxm1n023684@gandalf.savarese.org> References: <5d0946540608112205h70467c59jfa7db4dda69d89b6@mail.gmail.com> <200608121759.k7CHxm1n023684@gandalf.savarese.org> Message-ID: <5d0946540608141351s3c2c28e6p33d63a87e8f7c281@mail.gmail.com> Thanks for the input everyone. It turned out that the problem was with the setup.h file not being copied into the correct location as first mentioned by Sean. I was able to compile then, but there were a lot of linking errors at first due to the Visual studio workspace not building all objects by default. But I have finally gotten everything linked and compiled and am ready to go! Thanks again, Joe On 8/12/06, Daniel F. Savarese wrote: > > > In message <5d0946540608112205h70467c59jfa7db4dda69d89b6 at mail.gmail.com>, > "Joe > Seeley" writes: > >I performed a get on the CVS WxRuby2; I have installed wxWidgets 2.6.3and > >SWIG 1.3.29. Additionally I am running Visual Studio on Windows > XP. When I > >run rake to compile I receive the following error. > > >From my notes from the last time I compiled wxruby2 on Windows, I have > the following: > > I added $DEBUG=false to rake/rakemswin.rb and then from > cygwin (so we pick up swig): > > WXWIN=y:/opt/wxWidgets/wxWidgets \ > /cygdrive/y/opt/ruby/ruby-184-16rc1/bin/rake.bat \ > mswin=true install > > Of course, that's idiosyncratic to where I had things installed at the > time and that I was using swig from cygwin. However, since you're not > finding wx/setup.h you may find you need to point the WXWIN environment > variable (which is referenced in rakemswin.rb) to your wxWidgets > installation. But since you're already finding platform.h, that's > probably not it. > > I also have notes for compiling wxWidgets for Windows where I had to > manually copy setup.h from lib/vc_dll/msw/wx/setup.h to include/wx. > Apparently that was after a command prompt build with nmake and cl, > where I manually copied the build artifacts to my desired installation > location rather than using an install target, so it probably doesn't > apply. At any rate, I hope it's one of the things folks have mentioned. > We all seem to have run into different snags. > > daniel > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20060814/8c5fe931/attachment-0001.html From wxruby at qualitycode.com Mon Aug 14 20:24:17 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Mon, 14 Aug 2006 20:24:17 -0400 Subject: [Wxruby-users] Windows build? In-Reply-To: <5d0946540608141351s3c2c28e6p33d63a87e8f7c281@mail.gmail.com> References: <5d0946540608112205h70467c59jfa7db4dda69d89b6@mail.gmail.com> <200608121759.k7CHxm1n023684@gandalf.savarese.org> <5d0946540608141351s3c2c28e6p33d63a87e8f7c281@mail.gmail.com> Message-ID: <1155601457.5375.40.camel@localhost.localdomain> I'm glad to hear that you got it working. Could you write up a summary of your environment, problem, and solution and either post it here or on the wiki? Thanks, Kevin On Mon, 2006-08-14 at 15:51 -0500, Joe Seeley wrote: > Thanks for the input everyone. It turned out that the problem was > with the setup.h file not being copied into the correct location as > first mentioned by Sean. I was able to compile then, but there were a > lot of linking errors at first due to the Visual studio workspace not > building all objects by default. But I have finally gotten everything > linked and compiled and am ready to go! > > Thanks again, > Joe > On 8/12/06, Daniel F. Savarese wrote: > > In message > <5d0946540608112205h70467c59jfa7db4dda69d89b6 at mail.gmail.com>, > "Joe > Seeley" writes: > >I performed a get on the CVS WxRuby2; I have installed > wxWidgets 2.6.3 and > >SWIG 1.3.29. Additionally I am running Visual Studio on > Windows XP. When I > >run rake to compile I receive the following error. > > >From my notes from the last time I compiled wxruby2 on > Windows, I have > the following: > > I added $DEBUG=false to rake/rakemswin.rb and then from > cygwin (so we pick up swig): > > WXWIN=y:/opt/wxWidgets/wxWidgets \ > /cygdrive/y/opt/ruby/ruby-184-16rc1/bin/rake.bat \ > mswin=true install > > Of course, that's idiosyncratic to where I had things > installed at the > time and that I was using swig from cygwin. However, since > you're not > finding wx/setup.h you may find you need to point the WXWIN > environment > variable (which is referenced in rakemswin.rb) to your > wxWidgets > installation. But since you're already finding platform.h, > that's > probably not it. > > I also have notes for compiling wxWidgets for Windows where I > had to > manually copy setup.h from lib/vc_dll/msw/wx/setup.h to > include/wx. > Apparently that was after a command prompt build with nmake > and cl, > where I manually copied the build artifacts to my desired > installation > location rather than using an install target, so it probably > doesn't > apply. At any rate, I hope it's one of the things folks have > mentioned. > We all seem to have run into different snags. > > daniel > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users From wxruby at qualitycode.com Mon Aug 14 20:42:57 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Mon, 14 Aug 2006 20:42:57 -0400 Subject: [Wxruby-users] Patch for functions.i In-Reply-To: References: Message-ID: <1155602577.7710.0.camel@localhost.localdomain> On Mon, 2006-08-14 at 00:05 -0700, Sean Long wrote: > Here is a patch that adds five functions that are missing, there is > actually quite a few missing but I needed these for some testing. Applied, thanks. Kevin From wxruby at qualitycode.com Mon Aug 14 20:45:45 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Mon, 14 Aug 2006 20:45:45 -0400 Subject: [Wxruby-users] Patch for RubyConstants.i In-Reply-To: References: Message-ID: <1155602746.7710.2.camel@localhost.localdomain> On Mon, 2006-08-14 at 00:18 -0700, Sean Long wrote: > - Added wxDefaultCoord > - Updated the standard IDs so they match the 2.6.3 headers which adds wxID_NONE. Applied, thanks. Kevin From wxruby at qualitycode.com Mon Aug 14 20:49:23 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Mon, 14 Aug 2006 20:49:23 -0400 Subject: [Wxruby-users] Patch for wxWindow.h In-Reply-To: References: Message-ID: <1155602963.7710.4.camel@localhost.localdomain> On Mon, 2006-08-14 at 00:29 -0700, Sean Long wrote: > This patch updates a few existing methods so the signature matches the > wxWidgets headers more exactly and also adds a bunch of missing > methods. Applied, thanks. > Sorry for the flood of patches but I was waiting for the pending > patches to go thru before submitting these. This should be the last > one for tonight. No problem. Kevin From wxruby at qualitycode.com Mon Aug 14 20:54:43 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Mon, 14 Aug 2006 20:54:43 -0400 Subject: [Wxruby-users] Patches to rake files In-Reply-To: References: Message-ID: <1155603283.7710.6.camel@localhost.localdomain> These all looked reasonable to me, so I applied them. I trust other Mac and Windows users will let me (us) know if there were problems with those platforms. Thanks, Kevin On Mon, 2006-08-14 at 11:46 -0700, Sean Long wrote: > rakewx.rb: > - Added a $debug_build variable so when we do eventually we can also > release non debug builds. I did not make this a constant on purpose so > in the package tasks we can change it to false if we want to always > make non debug builds by default. > - Changed wx_config to use the $debug_build variable > > rakemswin.rb: > - Updated the copyright year. > - removed the $DEBUG const and make use of $debug_build instead. > > rakemacosx.rb: > - Updated the copyright year. > - Removed $wx_version = "2.6.1" because it is set in use_wx_config above. > - Removed commented out code, it has not been used in awhile and we > can always look in CVS if we need it again. > - Updated the framework task values to use 2.0 as the version instead > of 0.5, can be changed again to whatever we go with. Also updated the > copyright info. > > > Sean > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users From roys at mindspring.com Tue Aug 15 01:14:13 2006 From: roys at mindspring.com (Roy Sutton) Date: Tue, 15 Aug 2006 01:14:13 -0400 Subject: [Wxruby-users] Problem with directors and Ruby Message-ID: <44E15825.2040002@mindspring.com> I've tried to distill this sample down to its smallest portion. The problem is that the function included in the .i file can take optional arguments, most of which are output only, except the last one, which is input only. My target language is Ruby. When SWIG produces the wrapper for this the input parameter's name and type gets confused with the second parameter's type (relevant lines from sample.cpp): void SwigDirector_wxWindow::GetTextExtent(wxString const &string, int *x, int *y, int *descent, int *externalLeading, wxFont const *font) const { VALUE obj0 = Qnil ; VALUE obj1 = Qnil ; VALUE result; if (swig_get_up()) { wxWindow::GetTextExtent(string,x,y,descent,externalLeading,font); return; } obj0 = SWIG_NewPointerObj(SWIG_as_voidptr(&string), SWIGTYPE_p_wxString, 0 ); obj1 = SWIG_NewPointerObj(SWIG_as_voidptr(x), SWIGTYPE_p_int, 0 ); result = rb_funcall(swig_get_self(), rb_intern("GetTextExtent"), 2,obj0,obj1); obj1 should be font and its type should be SWIGTYPE_p_wxFont. I'm using SWIG 1.3.29 on Windows XP. Attached is the .i file. At the bottom of the message is the command line I use with SWIG. It's entirely possible I just misunderstand something about the way this is supposed to work but I've pored over the help files many times. Interestingly, if you change -ruby to -python then it appears to correctly generate the code for obj1. You may also want to look at my directorout typemap I've included which tries to get the results from the Ruby call so it can pass them back to the returning function if called from C++. I believe I've done that part correctly but I'm always happy to be educated if I've done this the hard/wrong way Roy ---- swig -fvirtual -w401 -w801 -w515 -c++ -ruby -o sample.cpp sample.i -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sample.i Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060815/b0bc6324/attachment.pl From alex at pressure.to Tue Aug 15 04:09:30 2006 From: alex at pressure.to (Alex Fenton) Date: Tue, 15 Aug 2006 09:09:30 +0100 Subject: [Wxruby-users] SashWindows In-Reply-To: <1155481807.11659.36.camel@localhost.localdomain> References: <44CF9255.4030905@pressure.to> <1155481807.11659.36.camel@localhost.localdomain> Message-ID: <44E1813A.7020607@pressure.to> > Then I was getting runtime errors because we had declared SASH to be > MSWindows-only. I changed that (in fixevents.rb) Oops, sorry, I forgot to include fixevents.rb with the patch - thanks > and the sample app > could run...but has some problems: > > 1. The draggable sash borders don't appear > This does work on OS X at the moment. I had these sort of problems when I first ported the classes. It turned out to be down to the values of enum wxSashEdgePosition(SASH_TOP, SASH_RIGHT etc), and the values of enum wxLayoutOrientation(wxLAYOUT_VERTICAL, wxLAYOUT_HORIZONTAL). The values we had in RubyConstants.i and SashWindow.i didn't tally up to the constant values as declared in the main wx headers in /usr/local/include. These are in wx/generic/sashwin.h and wx/generic/laywin.h respectively. I will have a look to see if there is anything inconsistent across platforms, or across the .i files. Any reports on MSWIN on this? > 2. Dragging the horizontal sash does nothing > > 3. Dragging the vertical sash crashes with a runtime error > It looks like the wrong event type is being generated - CommandEvent instead of SashEvent, and it then misses the method get_drag_rect. I think this is because the ordering of the event type mapping in EvtHandler.i has been changed (I guess because the patches didn't apply cleanly). The correct order should be: else if(event.IsKindOf(CLASSINFO(wxSashEvent))) cEvent = cWxSashEvent.klass; else if(event.IsKindOf(CLASSINFO(wxCommandEvent))) cEvent = cWxCommandEvent.klass; Unfortunatley some changes checked in last night have broken the build process for me so I can't test this right now. > Let me know if you need more details. I'm hoping you can submit fixes to > get the sample working, now that the basic code has been merged. > OK, thanks for your help with this. cheers alex From alex at pressure.to Tue Aug 15 04:16:17 2006 From: alex at pressure.to (Alex Fenton) Date: Tue, 15 Aug 2006 09:16:17 +0100 Subject: [Wxruby-users] Documentation for wxRuby In-Reply-To: <44DEEF04.8010807@pressure.to> References: <44DE1EDE.4080700@pressure.to> <44DE7601.7090606@pressure.to> <1155439248.5484.7.camel@localhost.localdomain> <44DEEF04.8010807@pressure.to> Message-ID: <44E182D1.6070001@pressure.to> Alex Fenton wrote: > I'll perhaps have a shot at adapting Sean's work to output textile. > Just a quick update in case anyone else is working on this - I have a pretty complete and correct WxWidgets Latex->Textile parser, I'm just working on refining the output and making build tasks. My working files attached - just for interest and comment, not quite ready for committing yet. The runnable file is 'latex-converter.rb', 'stringhelper.rb' and 'latex-parser.rb' should be in the same directory. Redcloth is needed. I'll try and finish this week. cheers alex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: latex-converter.rb Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060815/498a74a9/attachment-0001.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: latex_parser.rb Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060815/498a74a9/attachment-0002.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: stringhelper.rb Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060815/498a74a9/attachment-0003.pl From joiey.seeley at gmail.com Tue Aug 15 12:54:37 2006 From: joiey.seeley at gmail.com (Joe Seeley) Date: Tue, 15 Aug 2006 11:54:37 -0500 Subject: [Wxruby-users] Segmentation Fault Message-ID: <5d0946540608150954l1fecef09u7f523d41d849b0b8@mail.gmail.com> I was finally able to build wxruby2 yesterday. Today I tried switching an existing app over to wxruby2, but on running it I received a segmentation fault error. I then created a quick minimal script to see if the error still occurred. Here is the minimal script. # *** BEGIN SCRIPT *** require 'wx' include Wx class PPGui < App def on_init Frame.new(nil, -1, "The Bare Minimum").show() end end PPGui.new.main_loop # *** END SCRIPT *** And this is the error that is occurring. This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Our Initialize was called C:/Documents and Settings/seeljo/user/Preprocessor/tmp.rb:10: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [i386-mswin32] Process tmp.rb exited with code 3 I also split the last line into two statements to narrow down where this was occurring. gui = Gui.new <-- works fine gui.main_loop <--- segmentation fault Any ideas? Thanks, Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20060815/4f42edfc/attachment.html From joiey.seeley at gmail.com Tue Aug 15 13:10:58 2006 From: joiey.seeley at gmail.com (Joe Seeley) Date: Tue, 15 Aug 2006 12:10:58 -0500 Subject: [Wxruby-users] Segmentation Fault In-Reply-To: <5d0946540608150954l1fecef09u7f523d41d849b0b8@mail.gmail.com> References: <5d0946540608150954l1fecef09u7f523d41d849b0b8@mail.gmail.com> Message-ID: <5d0946540608151010t423af625nf220794251bf5d84@mail.gmail.com> Nevermind this post. I reran the linker and install and then it worked fine. Not sure what happened earlier... On 8/15/06, Joe Seeley wrote: > > I was finally able to build wxruby2 yesterday. Today I tried switching an > existing app over to wxruby2, but on running it I received a segmentation > fault error. > > I then created a quick minimal script to see if the error still occurred. > Here is the minimal script. > > # *** BEGIN SCRIPT *** > require 'wx' > include Wx > > class PPGui < App > def on_init > Frame.new(nil, -1, "The Bare Minimum").show() > end > end > > PPGui.new.main_loop > # *** END SCRIPT *** > > And this is the error that is occurring. > > This application has requested the Runtime to terminate it in an unusual > way. > Please contact the application's support team for more information. > Our Initialize was called > C:/Documents and Settings/seeljo/user/Preprocessor/tmp.rb:10: [BUG] > Segmentation fault > ruby 1.8.4 (2005-12-24) [i386-mswin32] > > Process tmp.rb exited with code 3 > > I also split the last line into two statements to narrow down where this > was occurring. > > gui = Gui.new <-- works fine > gui.main_loop <--- segmentation fault > > Any ideas? > > Thanks, > Joe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20060815/6a2268a2/attachment.html From joiey.seeley at gmail.com Tue Aug 15 19:05:34 2006 From: joiey.seeley at gmail.com (Joe Seeley) Date: Tue, 15 Aug 2006 18:05:34 -0500 Subject: [Wxruby-users] contributing? Message-ID: <5d0946540608151605h3835975gde0ca11cb9557a4b@mail.gmail.com> What do I need to do to be able to contribute patches? Thanks, Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20060815/34d4a321/attachment.html From alex at pressure.to Tue Aug 15 19:48:32 2006 From: alex at pressure.to (Alex Fenton) Date: Wed, 16 Aug 2006 00:48:32 +0100 Subject: [Wxruby-users] contributing? In-Reply-To: <5d0946540608151605h3835975gde0ca11cb9557a4b@mail.gmail.com> References: <5d0946540608151605h3835975gde0ca11cb9557a4b@mail.gmail.com> Message-ID: <44E25D50.2070301@pressure.to> Hi Joe Seeley wrote: > What do I need to do to be able to contribute patches? Patches are very welcome; please submit them to the mailing list and one of the committers will review and commit them. The standard procedure people generally use to create patches is: /#first login to cvs server //cvs -d :pserver:anonymous at rubyforge.org :/var/cvs/wxruby login/ / //#for convenience set your CVSROOT //#Unix //export CVSROOT=:pserver:anonymous at rubyforge.org :/var/cvs/wxruby// //#Windows //set CVSROOT=:pserver:anonymous at rubyforge.org :/var/cvs/wxruby // # if, for example, the file you changed was swig/common.i //# change directory to the directory above the wxruby2 root directory and do: //cvs diff -r HEAD -b -u wxruby2/swig/common.i > common.i.patch/// # If you've changed multiple files, you can combine them into one patch //cvs diff -r HEAD -b -u wxruby2/first_file wxruby2/second_file > combined.patch // Once you've created the patch, just send it as an attachment to the mailing list. If your change requires adding new files (e.g. a new .i interface file), just add these as attachments and note where they should go, if it's not obvious. Please put a short description of what the patch is intended to achieve in your email, and, if appropriate, please include a test case or sample that tests out the functionality you're adding or fixing. I think it also helps the committers if you collect related changes into a single email, and keep the patches in one email related to a single topic. Thanks - cheers alex [1] http://rubyforge.org/pipermail/wxruby-users/2005-August/001580.html From alex at pressure.to Tue Aug 15 20:07:20 2006 From: alex at pressure.to (Alex Fenton) Date: Wed, 16 Aug 2006 01:07:20 +0100 Subject: [Wxruby-users] Patches to rake files In-Reply-To: References: Message-ID: <44E261B8.1060005@pressure.to> Sean Long wrote: > rakewx.rb: > - Added a $debug_build variable so when we do eventually we can also > release non debug builds. I did not make this a constant on purpose so > in the package tasks we can change it to false if we want to always > make non debug builds by default. > - Changed wx_config to use the $debug_build variable Can I suggest the attached small patch? Without this, 'rake' fails with a slew of non-obvious errors if the person compiling happens not to have built a debug build of wxwidgets. With this patch, developers (in the know) can request a debug build by doing rake DEBUG=1 But casual experimenters need not care about this setting - it will use their Wx configuration if they just do 'rake'. cheers alex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rakewx.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060816/80f413a3/attachment.pl From alex at pressure.to Tue Aug 15 20:29:49 2006 From: alex at pressure.to (Alex Fenton) Date: Wed, 16 Aug 2006 01:29:49 +0100 Subject: [Wxruby-users] MiniFrame.i In-Reply-To: <1155476413.11659.15.camel@localhost.localdomain> References: <44C54DB3.3090902@pressure.to> <44C5BDA3.40206@pressure.to> <1155476413.11659.15.camel@localhost.localdomain> Message-ID: <44E266FD.4030207@pressure.to> Hi > I'm not really happy with the sample. First, the miniframe comes up > behind the main window for me, so I didn't even notice it at first. > I've modified the sample so it should raise the MiniFrame above the main frame, and on OS X (for real) and Windows (according to the docs) keep it above there - I think this is a common option. > Second, and more importantly, there is no clean way to exit. Choosing > File/Exit aborts with an error, and hitting the X close box on the main > frame leaves the miniframe active, with no way to close it. > OK, have fixed the on_quit method. On OS X the miniframe is automatically closed when the main app window is closed, but I've added an explicit call to close the miniframe call in the method. Hopefully this should fix things on other platforms. cheers alex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: miniframe.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060816/de187af6/attachment.pl From alex at pressure.to Tue Aug 15 20:39:52 2006 From: alex at pressure.to (Alex Fenton) Date: Wed, 16 Aug 2006 01:39:52 +0100 Subject: [Wxruby-users] Wizards In-Reply-To: <1155479031.11659.20.camel@localhost.localdomain> References: <44C66F5F.6040106@pressure.to> <1155479031.11659.20.camel@localhost.localdomain> Message-ID: <44E26958.4050100@pressure.to> Kevin Smith wrote: >> Quick q - the C declarations of evt_xxx_xxx methods and their attaching >> to Ruby classes seems to be duplicated across Events.i and EvtHandler.i >> - is one of these the right place to be adding them? or both? >> > > I actually got compile errors because the Wizard stuff was added in too > many places. As long as the EVT's are in swig/classes/include/events.rb, > you shouldn't have to add them to Events.i. The fixevents.rb > post-processor will add them to Events.cpp automatically. OK. I'm still not really clear here, sorry. Does this mean that neither the glue CPP function static VALUE evt_xxx .... nor the declaration of the ruby method rb_define_method(... are required to be added to swig/Events.i if the relevant event appears in swig/classes/include/events.rb? If that is so is a lot of the content of Events.i redundant, in that the events appear in events.rb? thanks for your help alex From alex at pressure.to Tue Aug 15 21:02:39 2006 From: alex at pressure.to (Alex Fenton) Date: Wed, 16 Aug 2006 02:02:39 +0100 Subject: [Wxruby-users] wxruby2 alpha status In-Reply-To: <1155496758.11659.122.camel@localhost.localdomain> References: <1155496758.11659.122.camel@localhost.localdomain> Message-ID: <44E26EAF.2050504@pressure.to> Kevin Smith wrote: > 2. I would like to receive and merge a patch that causes get_ruby_object > to return Qnil when null is passed in. > Does the attached do the trick? IANAC++P but it seems to work. > 3. The gem I built didn't seem to work on my system (Ubuntu GNU/Linux > Dapper 6.06). I know almost nothing about gems. The spec looked > reasonable at a glance (it included both wx.rb and wxruby2.so). I would > be happy to debug it if someone who knows gems could guide me. What happened? - Did it install ok (running 'gem install wxruby')? - If so, what do you get when you run 'ruby -rubygems -e 'require "wxruby"'? > How close > are we to having binary gems for our three main platforms? > Good to go on OS X PPC. Following some advice on clr, I'm guessing it's best we build our OS X gem on 10.3, not 10.4. I assume OS X i686 = 10.4 which I hope Sean will be able to help with. alex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Window.i.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060816/973fd8eb/attachment-0001.pl From wxruby at qualitycode.com Tue Aug 15 23:18:35 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Tue, 15 Aug 2006 23:18:35 -0400 Subject: [Wxruby-users] contributing? In-Reply-To: <44E25D50.2070301@pressure.to> References: <5d0946540608151605h3835975gde0ca11cb9557a4b@mail.gmail.com> <44E25D50.2070301@pressure.to> Message-ID: <1155698315.8694.13.camel@localhost.localdomain> This is an awesome email. Can you put this info in the wiki so we can point folks to it as needed? Having never submitted a patch, I can't vouch for the technical details, but conceptually it all looks right to me. If you are adding a new class, definitely add some tests of it to one of the samples, or create a new sample. If you are fixing something, it really helps me if you can briefly describe how I can see the problem, and then see that the patch fixed it. Thanks! Kevin On Wed, 2006-08-16 at 00:48 +0100, Alex Fenton wrote: > Hi > > Joe Seeley wrote: > > What do I need to do to be able to contribute patches? > Patches are very welcome; please submit them to the mailing list and one > of the committers will review and commit them. > > The standard procedure people generally use to create patches is: > > /#first login to cvs server > //cvs -d :pserver:anonymous at rubyforge.org :/var/cvs/wxruby login/ > / > //#for convenience set your CVSROOT > //#Unix > //export CVSROOT=:pserver:anonymous at rubyforge.org :/var/cvs/wxruby// > //#Windows > //set CVSROOT=:pserver:anonymous at rubyforge.org :/var/cvs/wxruby > // > # if, for example, the file you changed was swig/common.i > //# change directory to the directory above the wxruby2 root directory and do: > //cvs diff -r HEAD -b -u wxruby2/swig/common.i > common.i.patch/// > > # If you've changed multiple files, you can combine them into one patch > //cvs diff -r HEAD -b -u wxruby2/first_file wxruby2/second_file > combined.patch > > // > > Once you've created the patch, just send it as an attachment to the > mailing list. If your change requires adding new files (e.g. a new .i > interface file), just add these as attachments and note where they > should go, if it's not obvious. > > Please put a short description of what the patch is intended to achieve > in your email, and, if appropriate, please include a test case or sample > that tests out the functionality you're adding or fixing. > > I think it also helps the committers if you collect related changes into > a single email, and keep the patches in one email related to a single topic. > > Thanks - > cheers > alex > > [1] http://rubyforge.org/pipermail/wxruby-users/2005-August/001580.html > > > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users From wxruby at qualitycode.com Tue Aug 15 23:21:45 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Tue, 15 Aug 2006 23:21:45 -0400 Subject: [Wxruby-users] Patches to rake files In-Reply-To: <44E261B8.1060005@pressure.to> References: <44E261B8.1060005@pressure.to> Message-ID: <1155698505.8694.17.camel@localhost.localdomain> On Wed, 2006-08-16 at 01:07 +0100, Alex Fenton wrote: > def wx_config(opt) > - debug_mode = '--debug=no' > - if $debug_build > - debug_mode = '--debug=yes' > - end > - > + debug_mode = '--debug=yes' if $debug_build > return `wx-config #{debug_mode} #{opt}`.strip + " " > end I know it's ruby style, but I still look at the "x if y" structure as being a bug inherited from perl. My brain just doesn't work that way. It's like furniture instructions that say "Now cut the item in half. Oh, but before you do that, make sure you glued X to Y or the project will be ruined." Doh! So anyway, I would love it if you could revise the patch to use the old traditional if/x/end structure. Otherwise, looks good. Thanks, Kevin From wxruby at qualitycode.com Tue Aug 15 23:24:20 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Tue, 15 Aug 2006 23:24:20 -0400 Subject: [Wxruby-users] Events.i vs. events.rb (was: Wizards) In-Reply-To: <44E26958.4050100@pressure.to> References: <44C66F5F.6040106@pressure.to> <1155479031.11659.20.camel@localhost.localdomain> <44E26958.4050100@pressure.to> Message-ID: <1155698660.8694.20.camel@localhost.localdomain> On Wed, 2006-08-16 at 01:39 +0100, Alex Fenton wrote: > OK. I'm still not really clear here, sorry. Does this mean that neither > the glue CPP function > > static VALUE evt_xxx .... > > nor the declaration of the ruby method > > rb_define_method(... > > are required to be added to swig/Events.i if the relevant event appears > in swig/classes/include/events.rb? I believe that is true, but have not yet tested it myself. It would be great if someone could try ripping them all out and see if they still get generated in src/Event.cpp. > If that is so is a lot of the content of Events.i redundant, in that the > events appear in events.rb? True. Kevin From sean.m.long at gmail.com Wed Aug 16 00:15:47 2006 From: sean.m.long at gmail.com (Sean Long) Date: Tue, 15 Aug 2006 21:15:47 -0700 Subject: [Wxruby-users] wxruby2 alpha status In-Reply-To: <44E26EAF.2050504@pressure.to> References: <1155496758.11659.122.camel@localhost.localdomain> <44E26EAF.2050504@pressure.to> Message-ID: > Good to go on OS X PPC. Following some advice on clr, I'm guessing it's > best we build our OS X gem on 10.3, not 10.4. I assume OS X i686 = 10.4 > which I hope Sean will be able to help with. I'll do my best, it all depends when the release happens and when my wife gives birth :) The birth should be sometime in the next 2 weeks not sure about the alpha release. Sean From sean.m.long at gmail.com Wed Aug 16 00:23:29 2006 From: sean.m.long at gmail.com (Sean Long) Date: Tue, 15 Aug 2006 21:23:29 -0700 Subject: [Wxruby-users] Patches to rake files In-Reply-To: <44E261B8.1060005@pressure.to> References: <44E261B8.1060005@pressure.to> Message-ID: > Can I suggest the attached small patch? Without this, 'rake' fails with > a slew of non-obvious errors if the person compiling happens not to have > built a debug build of wxwidgets. Good catch, thanks. It would be a lot easier if wxMSW just had wx-config. > I know it's ruby style, but I still look at the "x if y" structure as > being a bug inherited from perl. My brain just doesn't work that way. > It's like furniture instructions that say "Now cut the item in half. Oh, > but before you do that, make sure you glued X to Y or the project will > be ruined." Doh! That is a great analogy. As a long time c\c++ guy I am used to the if/x/end style. Sean From sean.m.long at gmail.com Wed Aug 16 02:44:29 2006 From: sean.m.long at gmail.com (Sean Long) Date: Tue, 15 Aug 2006 23:44:29 -0700 Subject: [Wxruby-users] contributing? In-Reply-To: <1155698315.8694.13.camel@localhost.localdomain> References: <5d0946540608151605h3835975gde0ca11cb9557a4b@mail.gmail.com> <44E25D50.2070301@pressure.to> <1155698315.8694.13.camel@localhost.localdomain> Message-ID: I put it up on the Wiki: http://wxruby.rubyforge.org/wiki/wiki.pl?How_To_Create_And_Submit_Patches Sean On 8/15/06, Kevin Smith wrote: > This is an awesome email. Can you put this info in the wiki so we can > point folks to it as needed? > > Having never submitted a patch, I can't vouch for the technical details, > but conceptually it all looks right to me. > > If you are adding a new class, definitely add some tests of it to one of > the samples, or create a new sample. If you are fixing something, it > really helps me if you can briefly describe how I can see the problem, > and then see that the patch fixed it. > > Thanks! > > Kevin > > > On Wed, 2006-08-16 at 00:48 +0100, Alex Fenton wrote: > > Hi > > > > Joe Seeley wrote: > > > What do I need to do to be able to contribute patches? > > Patches are very welcome; please submit them to the mailing list and one > > of the committers will review and commit them. > > > > The standard procedure people generally use to create patches is: > > > > /#first login to cvs server > > //cvs -d :pserver:anonymous at rubyforge.org :/var/cvs/wxruby login/ > > / > > //#for convenience set your CVSROOT > > //#Unix > > //export CVSROOT=:pserver:anonymous at rubyforge.org :/var/cvs/wxruby// > > //#Windows > > //set CVSROOT=:pserver:anonymous at rubyforge.org :/var/cvs/wxruby > > // > > # if, for example, the file you changed was swig/common.i > > //# change directory to the directory above the wxruby2 root directory and do: > > //cvs diff -r HEAD -b -u wxruby2/swig/common.i > common.i.patch/// > > > > # If you've changed multiple files, you can combine them into one patch > > //cvs diff -r HEAD -b -u wxruby2/first_file wxruby2/second_file > combined.patch > > > > // > > > > Once you've created the patch, just send it as an attachment to the > > mailing list. If your change requires adding new files (e.g. a new .i > > interface file), just add these as attachments and note where they > > should go, if it's not obvious. > > > > Please put a short description of what the patch is intended to achieve > > in your email, and, if appropriate, please include a test case or sample > > that tests out the functionality you're adding or fixing. > > > > I think it also helps the committers if you collect related changes into > > a single email, and keep the patches in one email related to a single topic. > > > > Thanks - > > cheers > > alex > > > > [1] http://rubyforge.org/pipermail/wxruby-users/2005-August/001580.html > > > > > > > > > > _______________________________________________ > > wxruby-users mailing list > > wxruby-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wxruby-users > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > From alex at pressure.to Wed Aug 16 03:36:54 2006 From: alex at pressure.to (Alex Fenton) Date: Wed, 16 Aug 2006 08:36:54 +0100 Subject: [Wxruby-users] Patches to rake files In-Reply-To: <1155698505.8694.17.camel@localhost.localdomain> References: <44E261B8.1060005@pressure.to> <1155698505.8694.17.camel@localhost.localdomain> Message-ID: <44E2CB16.6070804@pressure.to> > I know it's ruby style, but I still look at the "x if y" structure as > being a bug inherited from perl. hehe. that's where I've picked up the habit. > My brain just doesn't work that way. > It's like furniture instructions that say "Now cut the item in half. Oh, > but before you do that, make sure you glued X to Y or the project will > be ruined." Doh! > LOL! > So anyway, I would love it if you could revise the patch to use the old > traditional if/x/end structure. > no probs. attached alex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rakewx.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060816/1fe12f1f/attachment.pl From joiey.seeley at gmail.com Wed Aug 16 09:10:58 2006 From: joiey.seeley at gmail.com (Joe Seeley) Date: Wed, 16 Aug 2006 08:10:58 -0500 Subject: [Wxruby-users] contributing? In-Reply-To: <44E25D50.2070301@pressure.to> References: <5d0946540608151605h3835975gde0ca11cb9557a4b@mail.gmail.com> <44E25D50.2070301@pressure.to> Message-ID: <5d0946540608160610g4545838sb188bc90f89adef9@mail.gmail.com> Alex, Thanks for the info! Joe On 8/15/06, Alex Fenton wrote: > > Hi > > Joe Seeley wrote: > > What do I need to do to be able to contribute patches? > Patches are very welcome; please submit them to the mailing list and one > of the committers will review and commit them. > > The standard procedure people generally use to create patches is: > > /#first login to cvs server > //cvs -d :pserver:anonymous at rubyforge.org < > http://rubyforge.org/mailman/listinfo/wxruby-users>:/var/cvs/wxruby login/ > / > //#for convenience set your CVSROOT > //#Unix > //export CVSROOT=:pserver:anonymous at rubyforge.org < > http://rubyforge.org/mailman/listinfo/wxruby-users>:/var/cvs/wxruby// > //#Windows > //set CVSROOT=:pserver:anonymous at rubyforge.org < > http://rubyforge.org/mailman/listinfo/wxruby-users>:/var/cvs/wxruby > // > # if, for example, the file you changed was swig/common.i > //# change directory to the directory above the wxruby2 root directory and > do: > //cvs diff -r HEAD -b -u wxruby2/swig/common.i > common.i.patch/// > > # If you've changed multiple files, you can combine them into one patch > //cvs diff -r HEAD -b -u wxruby2/first_file wxruby2/second_file > > combined.patch > > // > > Once you've created the patch, just send it as an attachment to the > mailing list. If your change requires adding new files (e.g. a new .i > interface file), just add these as attachments and note where they > should go, if it's not obvious. > > Please put a short description of what the patch is intended to achieve > in your email, and, if appropriate, please include a test case or sample > that tests out the functionality you're adding or fixing. > > I think it also helps the committers if you collect related changes into > a single email, and keep the patches in one email related to a single > topic. > > Thanks - > cheers > alex > > [1] http://rubyforge.org/pipermail/wxruby-users/2005-August/001580.html > > > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20060816/4b0e9a54/attachment.html From alex at pressure.to Wed Aug 16 18:11:05 2006 From: alex at pressure.to (Alex Fenton) Date: Wed, 16 Aug 2006 23:11:05 +0100 Subject: [Wxruby-users] all I wanted was a class reference... Message-ID: <44E397F9.5080706@pressure.to> And I got this lousy LatexParser. Ah well... A new cut of the automatic WxRuby documentation is now viewable online at http://www.pressure.to/wxruby/. There's also a pdf version http://www.pressure.to/wxruby/wxruby.pdf [3MB, 751 pages!] and a tarball http://www.pressure.to/wxruby/wxruby2.tar.gz [1.3MB] In terms of output, it's no advance on what Sean has already done. What's slightly interesting is that it's produced by parsing the Latex WxWidgets docs to Textile before rendering to HTML using RedCloth. Textile is a lightweight markup language, and seems maybe a good fit for storing and editing our docs in our VCS. There's a link to the Textile source of each page at the bottom. I don't think the time is quite right to commit the docs in yet - we probably want to tweak the automated output and stabilise the API first. But, soon, maybe. I'd like to commit the Latex parsing and Textile outputting code to CVS, but not sure where to put it. It's rather too large to put in the rake files (400+ LOC) - I'd rather keep the rake files fairly clean and focussed on the actual build tasks. Suggestions... maybe a /utils directory? Or /lib - but don't include this with the gem bundle? Suggestions for improvements very welcome cheers alex From wxruby at qualitycode.com Wed Aug 16 20:54:19 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Wed, 16 Aug 2006 20:54:19 -0400 Subject: [Wxruby-users] all I wanted was a class reference... In-Reply-To: <44E397F9.5080706@pressure.to> References: <44E397F9.5080706@pressure.to> Message-ID: <1155776060.5401.15.camel@localhost.localdomain> On Wed, 2006-08-16 at 23:11 +0100, Alex Fenton wrote: > A new cut of the automatic WxRuby documentation is now viewable online at > http://www.pressure.to/wxruby/. Cool. This seems like a good direction for us. A few minor suggestions/comments: Red on white is probably hard for some folks to read. And on my system, it is hard to see the difference between visited and unvisited links. I assume at some point it will be possible to hyperlink the return value classes. So in Window#get_position, you could click on Point to get to the Point class. It will be interesting to see how much we have to censor out, such as the discussion of compilers in TextCtrl. > I'd like to commit the Latex parsing and Textile outputting code to CVS, > but not sure where to put it. It's rather too large to put in the rake > files (400+ LOC) - I'd rather keep the rake files fairly clean and > focussed on the actual build tasks. Suggestions... maybe a /utils > directory? Or /lib - but don't include this with the gem bundle? Perhaps we should create a doc/ directory? Kevin From roys at mindspring.com Wed Aug 16 21:04:17 2006 From: roys at mindspring.com (Roy Sutton) Date: Wed, 16 Aug 2006 21:04:17 -0400 Subject: [Wxruby-users] all I wanted was a class reference... In-Reply-To: <1155776060.5401.15.camel@localhost.localdomain> References: <44E397F9.5080706@pressure.to> <1155776060.5401.15.camel@localhost.localdomain> Message-ID: <44E3C091.3010501@mindspring.com> Kevin Smith wrote: > On Wed, 2006-08-16 at 23:11 +0100, Alex Fenton wrote: > >> A new cut of the automatic WxRuby documentation is now viewable online at >> http://www.pressure.to/wxruby/. >> > > I assume at some point it will be possible to hyperlink the return value > classes. So in Window#get_position, you could click on Point to get to > the Point class. > Not to mention that most everything is untyped in Ruby so the function parameters may need to be removed or changed somehow. Not sure. Also, we need to remove the 'Bogus' class from the list. Roy From wxruby at qualitycode.com Thu Aug 17 01:28:28 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 17 Aug 2006 01:28:28 -0400 Subject: [Wxruby-users] all I wanted was a class reference... In-Reply-To: <44E3C091.3010501@mindspring.com> References: <44E397F9.5080706@pressure.to> <1155776060.5401.15.camel@localhost.localdomain> <44E3C091.3010501@mindspring.com> Message-ID: <1155792509.5401.19.camel@localhost.localdomain> On Wed, 2006-08-16 at 21:04 -0400, Roy Sutton wrote: > Not to mention that most everything is untyped in Ruby so the function > parameters may need to be removed or changed somehow. Not sure. I thought that, but looking at it, I think I like the way it is. You need to know what types get passed and returned. Maybe they just need to be italics, smaller, fainter, or otherwise flagged as being metadata about the parameters. > Also, we need to remove the 'Bogus' class from the list. Yup. Kevin From wxruby at qualitycode.com Thu Aug 17 19:36:26 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 17 Aug 2006 19:36:26 -0400 Subject: [Wxruby-users] App#on_assert, wxDEBUG Message-ID: <1155857786.24318.3.camel@localhost.localdomain> Hi all, I just checked in support for overriding App#on_assert. Mainly because I was really tired of the "looping crash" I have mentioned before, which happens on my system whenever an assert is caught by the default handler built into wx. Separate topic: wxRuby does some cool diagnostics when wxDEBUG is defined. I'm not sure we want to ship with wxDEBUG enabled, but I sure would like to have it turned on whenever I'm developing and debugging. Any thoughts on how best to let me run with it, but not to impose that on everyone else via cvs? Maybe we could have an optional config file that is in .cvsignore so each developer can do what they want? Kevin From wxruby at qualitycode.com Thu Aug 17 19:39:12 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 17 Aug 2006 19:39:12 -0400 Subject: [Wxruby-users] MiniFrame.i In-Reply-To: <44E266FD.4030207@pressure.to> References: <44C54DB3.3090902@pressure.to> <44C5BDA3.40206@pressure.to> <1155476413.11659.15.camel@localhost.localdomain> <44E266FD.4030207@pressure.to> Message-ID: <1155857952.24318.5.camel@localhost.localdomain> On Wed, 2006-08-16 at 01:29 +0100, Alex Fenton wrote: > I've modified the sample so it should raise the MiniFrame above the main > frame, and on OS X (for real) and Windows (according to the docs) keep > it above there - I think this is a common option. Works great on Linux. > OK, have fixed the on_quit method. On OS X the miniframe is > automatically closed when the main app window is closed, but I've added > an explicit call to close the miniframe call in the method. Hopefully > this should fix things on other platforms. Perfect. Thanks! Kevin From wxruby at qualitycode.com Thu Aug 17 19:48:27 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 17 Aug 2006 19:48:27 -0400 Subject: [Wxruby-users] get_ruby_object patch (was: wxruby2 alpha status) In-Reply-To: <44E26EAF.2050504@pressure.to> References: <1155496758.11659.122.camel@localhost.localdomain> <44E26EAF.2050504@pressure.to> Message-ID: <1155858507.24318.12.camel@localhost.localdomain> On Wed, 2006-08-16 at 02:02 +0100, Alex Fenton wrote: > Kevin Smith wrote: > > 2. I would like to receive and merge a patch that causes get_ruby_object > > to return Qnil when null is passed in. > > > Does the attached do the trick? IANAC++P but it seems to work. Looks good to me. I didn't have a test case so I don't know for sure if it actually works. I committed it. Thanks, Kevin From alex at pressure.to Thu Aug 17 19:55:37 2006 From: alex at pressure.to (Alex Fenton) Date: Fri, 18 Aug 2006 00:55:37 +0100 Subject: [Wxruby-users] all I wanted was a class reference... In-Reply-To: <1155776060.5401.15.camel@localhost.localdomain> References: <44E397F9.5080706@pressure.to> <1155776060.5401.15.camel@localhost.localdomain> Message-ID: <44E501F9.7060103@pressure.to> Kevin Smith wrote: > Red on white is probably hard for some folks to read. And on my system, > it is hard to see the difference between visited and unvisited links. > OK. Is red on white a known accessibility issue? Or do we just need to darken the shade a little bit? This is all in the CSS, so easily tweaked. > I assume at some point it will be possible to hyperlink the return value > classes. So in Window#get_position, you could click on Point to get to > the Point class. > Have added this. > It will be interesting to see how much we have to censor out, such as > the discussion of compilers in TextCtrl. > Some of the incline C++ code also plays havoc with Textile's formatter, so no bad thing ... > Perhaps we should create a doc/ directory? > Sounds good. Will commit shortly. [Following Roy's post] > Not to mention that most everything is untyped in Ruby so the function > parameters may need to be removed or changed somehow. Not sure. I agree in theory - but practically, as Kevin says,WxRuby functions expect particular types (as in classes) of arguments and will choke on other stuff. The typemaps seem to make the API more strictly typed than we want, but we can come back to that. I've gone with putting the type 'hints' in a fainter colour. as a side note, much as I like ruby, having seen CPP type handling via WxRuby there are things I like. Whether types are defined in terms of classes (boring old-fashioned) or in terms of capabilities/methods (fashionable 'duck-typing'), methods still need to be coded to do something useful with particular types of arguments. Overloading seems, superficially at least, to be quite a neat way of doing this. cheers alex From wxruby at qualitycode.com Thu Aug 17 19:55:03 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 17 Aug 2006 19:55:03 -0400 Subject: [Wxruby-users] wxruby gem not working (was: wxruby2 alpha status) In-Reply-To: <44E26EAF.2050504@pressure.to> References: <1155496758.11659.122.camel@localhost.localdomain> <44E26EAF.2050504@pressure.to> Message-ID: <1155858903.24318.17.camel@localhost.localdomain> On Wed, 2006-08-16 at 02:02 +0100, Alex Fenton wrote: > Kevin Smith wrote: > > 3. The gem I built didn't seem to work on my system (Ubuntu GNU/Linux > > Dapper 6.06). I know almost nothing about gems. The spec looked > > reasonable at a glance (it included both wx.rb and wxruby2.so). I would > > be happy to debug it if someone who knows gems could guide me. > What happened? > - Did it install ok (running 'gem install wxruby')? kevins at aria:~/work/wxruby2$ rake gem (in /home/kevins/work/wxruby2) Successfully built RubyGem Name: wxruby Version: 1.9.0 File: wxruby-1.9.0-i486-linux.gem kevins at aria:~/work/wxruby2$ sudo gem install wxruby-1.9.0-i486-linux.gem Attempting local installation of 'wxruby-1.9.0-i486-linux.gem' Successfully installed wxruby, version 1.9.0 kevins at aria:~/work/wxruby2$ ruby samples/minimal/minimal.rb Unable to load wxruby. Searched: /usr/local/lib/site_ruby/1.8 /usr/local/lib/site_ruby/1.8/i486-linux /usr/local/lib/site_ruby/1.8/i386-linux /usr/local/lib/site_ruby /usr/lib/ruby/1.8 /usr/lib/ruby/1.8/i486-linux /usr/lib/ruby/1.8/i386-linux . The problem seems to be with $LOAD_PATH on my end: kevins at aria:~/work/wxruby2$ irb irb(main):001:0> puts $LOAD_PATH /usr/local/lib/site_ruby/1.8 /usr/local/lib/site_ruby/1.8/i486-linux /usr/local/lib/site_ruby/1.8/i386-linux /usr/local/lib/site_ruby /usr/lib/ruby/1.8 /usr/lib/ruby/1.8/i486-linux /usr/lib/ruby/1.8/i386-linux . Shouldn't those duplicates have /lib/ on the end of the second one in each case? > - If so, what do you get when you run 'ruby -rubygems -e 'require "wxruby"'? kevins at aria:~/work/wxruby2$ ruby -rubygems -e 'require "wxruby"' /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:18:in `require__': no such file to load -- wxruby (LoadError) from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:18:in `require' from -e:1 -------------------------------- Hm. It put stuff here: kevins at aria:~/work/wxruby2$ dir /usr/lib/ruby/gems/1.8/gems/wxruby-1.9.0-i486-linux/lib/ wx.rb wxruby2.so Kevin From wxruby at qualitycode.com Thu Aug 17 20:01:48 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 17 Aug 2006 20:01:48 -0400 Subject: [Wxruby-users] Patches to rake files In-Reply-To: <44E2CB16.6070804@pressure.to> References: <44E261B8.1060005@pressure.to> <1155698505.8694.17.camel@localhost.localdomain> <44E2CB16.6070804@pressure.to> Message-ID: <1155859308.24318.18.camel@localhost.localdomain> On Wed, 2006-08-16 at 08:36 +0100, Alex Fenton wrote: > > So anyway, I would love it if you could revise the patch to use the old > > traditional if/x/end structure. > > > no probs. attached Applied, thanks. Kevin From alex at pressure.to Thu Aug 17 20:04:35 2006 From: alex at pressure.to (Alex Fenton) Date: Fri, 18 Aug 2006 01:04:35 +0100 Subject: [Wxruby-users] wxruby gem not working In-Reply-To: <1155858903.24318.17.camel@localhost.localdomain> References: <1155496758.11659.122.camel@localhost.localdomain> <44E26EAF.2050504@pressure.to> <1155858903.24318.17.camel@localhost.localdomain> Message-ID: <44E50413.7000605@pressure.to> Kevin Smith wrote: > kevins at aria:~/work/wxruby2$ rake gem > (in /home/kevins/work/wxruby2) > Successfully built RubyGem > Name: wxruby > Version: 1.9.0 > File: wxruby-1.9.0-i486-linux.gem > looks good > kevins at aria:~/work/wxruby2$ sudo gem install wxruby-1.9.0-i486-linux.gem > Attempting local installation of 'wxruby-1.9.0-i486-linux.gem' > Successfully installed wxruby, version 1.9.0 > looks good > kevins at aria:~/work/wxruby2$ ruby samples/minimal/minimal.rb > As you surmised, looks like you need to tell ruby to try requiring from gems directories as well as the usual LOAD_PATH. try ruby -rubygems samples/minimal/minimal.rb or, alternatively, export RUBYOPT=rubygems to affect all subsequent invocations of ruby. This option is typically added to default environment variables automatically by the windows installer for example, so transparent to them. >> - If so, what do you get when you run 'ruby -rubygems -e 'require "wxruby"'? >> > > kevins at aria:~/work/wxruby2$ ruby -rubygems -e 'require "wxruby"' > Sorry, my bad should be ruby -rubygems -e 'require "wx"' > kevins at aria:~/work/wxruby2$ > dir /usr/lib/ruby/gems/1.8/gems/wxruby-1.9.0-i486-linux/lib/ > wx.rb wxruby2.so looks correct cheers alex From wxruby at qualitycode.com Thu Aug 17 20:12:15 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 17 Aug 2006 20:12:15 -0400 Subject: [Wxruby-users] all I wanted was a class reference... In-Reply-To: <44E501F9.7060103@pressure.to> References: <44E397F9.5080706@pressure.to> <1155776060.5401.15.camel@localhost.localdomain> <44E501F9.7060103@pressure.to> Message-ID: <1155859936.24318.24.camel@localhost.localdomain> On Fri, 2006-08-18 at 00:55 +0100, Alex Fenton wrote: > Kevin Smith wrote: > > Red on white is probably hard for some folks to read. And on my system, > > it is hard to see the difference between visited and unvisited links. > > > OK. Is red on white a known accessibility issue? Or do we just need to > darken the shade a little bit? As with anything, opinions vary. Supposedly one study showed 10% of people had trouble reading red on white. A different site I saw recommended it as a good choice for color-blind folks. Personally, I find it usable but a bit straining. A darker red would definitely help, so that might be the first thing to try. > > I assume at some point it will be possible to hyperlink the return value > > classes. So in Window#get_position, you could click on Point to get to > > the Point class. > > > Have added this. Sweet. > > Perhaps we should create a doc/ directory? > > > Sounds good. Will commit shortly. I just noticed that the gem chapter of the pickaxe book recommends creating a docs/ directory (as opposed to doc/). If that's really a gem standard, we should obey. Otherwise, doc/ seems to be slightly more common. Kevin From wxruby at qualitycode.com Thu Aug 17 20:31:39 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 17 Aug 2006 20:31:39 -0400 Subject: [Wxruby-users] wxruby gem not working In-Reply-To: <44E50413.7000605@pressure.to> References: <1155496758.11659.122.camel@localhost.localdomain> <44E26EAF.2050504@pressure.to> <1155858903.24318.17.camel@localhost.localdomain> <44E50413.7000605@pressure.to> Message-ID: <1155861099.24318.28.camel@localhost.localdomain> On Fri, 2006-08-18 at 01:04 +0100, Alex Fenton wrote: > As you surmised, looks like you need to tell ruby to try requiring from > gems directories as well as the usual LOAD_PATH. try > > ruby -rubygems samples/minimal/minimal.rb > > or, alternatively, > > export RUBYOPT=rubygems Thanks for your quick reply. Here are those results: kevins at aria:~/work/wxruby2$ ruby -rubygems samples/minimal/minimal.rb /usr/local/lib/site_ruby/1.8/wx.rb:20: uninitialized constant Wxruby2 (NameError) from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:18:in `require' from samples/minimal/minimal.rb:1 kevins at aria:~/work/wxruby2$ export RUBYOPT=rubygems kevins at aria:~/work/wxruby2$ ruby samples/minimal/minimal.rb /usr/local/lib/site_ruby/1.8/wx.rb:20: uninitialized constant Wxruby2 (NameError) from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:18:in `require' from samples/minimal/minimal.rb:1 I just updated gem, in case that was a problem. No change. More data, in case it helps: kevins at aria:~/work/wxruby2$ ruby --version ruby 1.8.4 (2005-12-24) [i486-linux] kevins at aria:~/work/wxruby2$ irb -rubygems irb(main):001:0> puts $LOAD_PATH /usr/local/lib/site_ruby/1.8 /usr/local/lib/site_ruby/1.8/i486-linux /usr/local/lib/site_ruby/1.8/i386-linux /usr/local/lib/site_ruby /usr/lib/ruby/1.8 /usr/lib/ruby/1.8/i486-linux /usr/lib/ruby/1.8/i386-linux . => nil Kevin From wxruby at qualitycode.com Thu Aug 17 23:07:52 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 17 Aug 2006 23:07:52 -0400 Subject: [Wxruby-users] wxruby gem not working [FIXED!] In-Reply-To: <1155861099.24318.28.camel@localhost.localdomain> References: <1155496758.11659.122.camel@localhost.localdomain> <44E26EAF.2050504@pressure.to> <1155858903.24318.17.camel@localhost.localdomain> <44E50413.7000605@pressure.to> <1155861099.24318.28.camel@localhost.localdomain> Message-ID: <1155870473.30640.3.camel@localhost.localdomain> I just fixed my gem problem. Sorry for the noise on this list. It seems that half of my gem stuff was in /usr/lib and the other half was in /usr/local/lib. I ended up blowing away everything gem, then reinstalling gem 0.9.0. After re-fixing my $RUBYOPT (which was not the problem before), it now works. HOORAY! So I installed the wx gem, and was able to run the minimal app. Sweet. Should rake install build and install the gem, by default? Is it possible to tell gem to install over an existing gem, even if the version is the same? Kevin From wxruby at qualitycode.com Thu Aug 17 23:19:00 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 17 Aug 2006 23:19:00 -0400 Subject: [Wxruby-users] wxruby2 alpha status In-Reply-To: <1155496758.11659.122.camel@localhost.localdomain> References: <1155496758.11659.122.camel@localhost.localdomain> Message-ID: <1155871140.30640.9.camel@localhost.localdomain> On Sun, 2006-08-13 at 15:19 -0400, Kevin Smith wrote: > Hi all, > > How soon can we do our alpha (binary gem) release? How about this weekend? > 1. I would like to get the samples working a bit better, but am ok > simply documenting most of the current problems. Do the samples crash > every few minutes for other people? Or is it just me? I would like to > have a copyright/license comment at the top of every sample file before > the alpha release. I can add license comments to all the samples. For the known bugs, and problems running samples, perhaps we could mention the most serious problems in README, but also include a link to a page on the wiki. That way we could update the problem list even after the release. We don't expect this release to have a long life, so I think something quick and dirty is sufficient. I plan to be very clear in the README that this is a very early release, so people don't expect too much from it. That same message needs to come through clearly in all release announcements. > 2. I would like to receive and merge a patch that causes get_ruby_object > to return Qnil when null is passed in. This was done. > 3. The gem I built didn't seem to work on my system (Ubuntu GNU/Linux > Dapper 6.06). I know almost nothing about gems. The spec looked > reasonable at a glance (it included both wx.rb and wxruby2.so). I would > be happy to debug it if someone who knows gems could guide me. How close > are we to having binary gems for our three main platforms? My gem problem has been solved. Any other issues with the gem? > Anything else? It would be cool to include the API docs, but could we just point to an online copy for now? Anything else else? Kevin From roys at mindspring.com Thu Aug 17 23:37:15 2006 From: roys at mindspring.com (Roy Sutton) Date: Thu, 17 Aug 2006 23:37:15 -0400 Subject: [Wxruby-users] Compiling problem on Windows Message-ID: <44E535EB.70106@mindspring.com> Something recent has caused a change in the Windows compilation. I'm now getting: C:\RubyDev\wxWidgets-2.6.3/include\wx/platform.h(190) : fatal error C1083: Cannot open include file: 'wx/setup.h': No such file or directory I didn't get this before I pulled the latest files. I don't see anything obvious that would have changed this and I'm certain I didn't delete the setup.h file. I'll poke into it some more to see if I can figure out what happened. Roy From roys at mindspring.com Fri Aug 18 00:25:33 2006 From: roys at mindspring.com (Roy Sutton) Date: Fri, 18 Aug 2006 00:25:33 -0400 Subject: [Wxruby-users] Compiling problem on Windows In-Reply-To: <44E535EB.70106@mindspring.com> References: <44E535EB.70106@mindspring.com> Message-ID: <44E5413D.10109@mindspring.com> The issue was the change to $DEBUG. Setting my environment variable DEBUG to true allows it to build. I was trying to compare the old compiler command line with the new one and somehow missed copying from the screen for the old one. So I was comparing the copy of the new one against itself and it was identical (obviously). The big question is why the include files are correct for debug builds but wrong for non-debug builds? Possibly because I haven't compiled non-debug versions of wxWindows yet. Roy Roy Sutton wrote: > Something recent has caused a change in the Windows compilation. I'm > now getting: > > C:\RubyDev\wxWidgets-2.6.3/include\wx/platform.h(190) : fatal error > C1083: Cannot open include file: 'wx/setup.h': No such file or directory > > I didn't get this before I pulled the latest files. I don't see > anything obvious that would have changed this and I'm certain I didn't > delete the setup.h file. I'll poke into it some more to see if I can > figure out what happened. > > Roy > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > From alex at pressure.to Fri Aug 18 00:48:12 2006 From: alex at pressure.to (Alex Fenton) Date: Fri, 18 Aug 2006 05:48:12 +0100 Subject: [Wxruby-users] wxruby gem not working [FIXED!] In-Reply-To: <1155870473.30640.3.camel@localhost.localdomain> References: <1155496758.11659.122.camel@localhost.localdomain> <44E26EAF.2050504@pressure.to> <1155858903.24318.17.camel@localhost.localdomain> <44E50413.7000605@pressure.to> <1155861099.24318.28.camel@localhost.localdomain> <1155870473.30640.3.camel@localhost.localdomain> Message-ID: <44E5468C.5070702@pressure.to> Kevin Smith wrote: > I ended up blowing away everything gem, then reinstalling gem 0.9.0. > After re-fixing my $RUBYOPT (which was not the problem before), it now > works. > Nice one! Thanks for your patience. > Should rake install build and install the gem, by default? Maybe not? - when testing new features etc I usually do ruby -Ilib samples/foo/bar.rb To run the code against my changes - but also keep a 'stable' reference version installed in gems. > Is it possible to tell gem to install over an existing gem, even if the > version is the same? It seems to me to do this by default, if you say 'sudo gem install wxruby'. See below. Maybe the --force option but I don't think it's intended for this. cheers alex SCIPIUS alex$ ls -al /usr/local/lib/ruby/gems/1.8/gems/wxruby-1.9.0-powerpc-darwin7.9.0/lib total 27984 drwxr-xr-x 4 root wheel 136 18 Aug 05:37 . drwxr-xr-x 4 root wheel 136 18 Aug 05:37 .. -rw-r--r-- 1 root wheel 512 18 Aug 05:42 wx.rb -rw-r--r-- 1 root wheel 14321420 18 Aug 05:42 wxruby2.bundle SCIPIUS alex$ mv lib/wxruby2.bundle lib/wxruby2.bundle_real SCIPIUS alex$ touch lib/wxruby2.bundle SCIPIUS alex$ rake gem (in /Users/alex/code/wxruby2) Successfully built RubyGem Name: wxruby Version: 1.9.0 File: wxruby-1.9.0-powerpc-darwin7.9.0.gem mv wxruby-1.9.0-powerpc-darwin7.9.0.gem wxruby-1.9.0-powerpc-darwin.gem SCIPIUS alex$ sudo gem install wxruby Attempting local installation of 'wxruby' Successfully installed wxruby, version 1.9.0 SCIPIUS alex$ ls -al /usr/local/lib/ruby/gems/1.8/gems/wxruby-1.9.0-powerpc-darwin7.9.0/lib total 8 drwxr-xr-x 4 root wheel 136 18 Aug 05:37 . drwxr-xr-x 4 root wheel 136 18 Aug 05:37 .. -rw-r--r-- 1 root wheel 512 18 Aug 05:44 wx.rb -rw-r--r-- 1 root wheel 0 18 Aug 05:44 wxruby2.bundle From sean.m.long at gmail.com Fri Aug 18 00:54:57 2006 From: sean.m.long at gmail.com (Sean Long) Date: Thu, 17 Aug 2006 21:54:57 -0700 Subject: [Wxruby-users] wxruby2 alpha status In-Reply-To: <1155871140.30640.9.camel@localhost.localdomain> References: <1155496758.11659.122.camel@localhost.localdomain> <1155871140.30640.9.camel@localhost.localdomain> Message-ID: > > How soon can we do our alpha (binary gem) release? > > How about this weekend? I am working on TreeCtrl and hope to have a better version ready to upload later tonight or tomorrow. Besides that all the patches I have made have been committed. Sean From alex at pressure.to Fri Aug 18 01:03:02 2006 From: alex at pressure.to (Alex Fenton) Date: Fri, 18 Aug 2006 06:03:02 +0100 Subject: [Wxruby-users] SashWindows In-Reply-To: <1155481807.11659.36.camel@localhost.localdomain> References: <44CF9255.4030905@pressure.to> <1155481807.11659.36.camel@localhost.localdomain> Message-ID: <44E54A06.1050204@pressure.to> Kevin Smith wrote: > 3. Dragging the vertical sash crashes with a runtime error > Could you try the attached patch, please? > New topic: I would like to include some kind of license at the top of > every sample file, saying that this code can be used for any purpose, > without attribution. Without that, it is not clear to our users that > they are free to use code fragments in their own code, without > restriction. Any ideas what wording we could use? I'm not sure "public > domain" is the right answer, because we are the primary source/author. > As I understand it, 'public domain' doesn't disclaim authorship, but does allow unrestricted use. I'm happy with this licence - I use it for Weft QDA. cheers alex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: EvtHandler.i.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060818/d1a05496/attachment.ksh From alex at pressure.to Fri Aug 18 01:12:48 2006 From: alex at pressure.to (Alex Fenton) Date: Fri, 18 Aug 2006 06:12:48 +0100 Subject: [Wxruby-users] all I wanted was a class reference... In-Reply-To: <1155859936.24318.24.camel@localhost.localdomain> References: <44E397F9.5080706@pressure.to> <1155776060.5401.15.camel@localhost.localdomain> <44E501F9.7060103@pressure.to> <1155859936.24318.24.camel@localhost.localdomain> Message-ID: <44E54C50.6080300@pressure.to> > I just noticed that the gem chapter of the pickaxe book recommends > creating a docs/ directory (as opposed to doc/). If that's really a gem > standard, we should obey. Otherwise, doc/ seems to be slightly more > common. > I agree. As far as I can tell RubyGems doesn't provide any doc except to rdoc. But I will check the relevant bit of the pickaxe when I get back to London this evening. Suggest I hold off doing a commit until after alpha. Am happy to host the interim docs online for the time being, if that's useful. Will update the index page with a rider that they're autogenerated and so methods may be missing or have different signatures. alex From alex at pressure.to Fri Aug 18 01:43:08 2006 From: alex at pressure.to (Alex Fenton) Date: Fri, 18 Aug 2006 06:43:08 +0100 Subject: [Wxruby-users] wxruby2 alpha status In-Reply-To: <1155871140.30640.9.camel@localhost.localdomain> References: <1155496758.11659.122.camel@localhost.localdomain> <1155871140.30640.9.camel@localhost.localdomain> Message-ID: <44E5536C.8010403@pressure.to> Kevin Smith wrote: > On Sun, 2006-08-13 at 15:19 -0400, Kevin Smith wrote: > >> Hi all, >> >> How soon can we do our alpha (binary gem) release? >> > > How about this weekend? > I'm available to do a build. The things I'm working on are all incremental and not worth delaying for. > I plan to be very clear in the README that this is a very early release, > so people don't expect too much from it. That same message needs to come > through clearly in all release announcements. > Yep. We don't want to over-promise and disappoint. Equally, I think we should mention what is exciting and new about this release, from an end-user perspective. Otherwise, people might be like 'They spent years re-engineering and 18 months since last release - for what?' - Looks much better on Linux (I hear) b/c of GTK-2 support - Vastly improved support for OS X - Lots of new classes and methods - UTF-8 support by default - Binary packages for all major platforms - Better future development potential via SWIG. > It would be cool to include the API docs, but could we just point to an > online copy for now? > Yep. > Anything else else? Not that I can think of think of ;) alex From sean.m.long at gmail.com Fri Aug 18 03:54:26 2006 From: sean.m.long at gmail.com (Sean Long) Date: Fri, 18 Aug 2006 00:54:26 -0700 Subject: [Wxruby-users] TreeCtrl update Message-ID: The previous TreeCtrl.i was very messy and just plain wrong, for instance it had GetFirstChild as depreciated when in fact only 1 version of it was depreciated not both. I changed GetFirstChild and GetNextChild to return an array of values to match the wxPython and wxPerl usage. I also noticed that wxTreeCtrl is inherited from wxControl on Windows and wxScrolledWindow on everything else so I #if defined the .i and .h file accordingly. I also added a .i and .h file for the class wxTreeItemId. The TreeCtrl files were changed so much that I am just uploading the whole files instead of the diffs. traverse_tree(tree_ctrl,tree_ctrl.get_root_item) do |node_id,cookie| puts "Name: #{tree_ctrl.get_item_text(node_id)}\t\tCookie: #{cookie}" end def traverse_tree(tree_ctrl,root_node,cookie=0,&block) if cookie == 0 ret = tree_ctrl.get_first_child(root_node) else ret = tree_ctrl.get_next_child(root_node,cookie) end if ret[0].is_ok if block_given? yield(ret[0],ret[1]) end traverse_tree(tree_ctrl,ret[0],0,&block) end ret_sib = tree_ctrl.get_next_sibling(root_node) if ret_sib.is_ok if block_given? yield(ret_sib,cookie) end traverse_tree(tree_ctrl,ret_sib,0,&block) end end Sean -------------- next part -------------- A non-text attachment was scrubbed... Name: TreeCtrl.i Type: application/octet-stream Size: 1530 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-users/attachments/20060818/1e16393f/attachment-0004.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: TreeItemId.i Type: application/octet-stream Size: 215 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-users/attachments/20060818/1e16393f/attachment-0005.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: wxTreeCtrl.h Type: application/octet-stream Size: 15372 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-users/attachments/20060818/1e16393f/attachment-0006.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: wxTreeItemId.h Type: application/octet-stream Size: 1242 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-users/attachments/20060818/1e16393f/attachment-0007.obj From wxruby at qualitycode.com Fri Aug 18 10:14:09 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Fri, 18 Aug 2006 10:14:09 -0400 Subject: [Wxruby-users] Where to host the docs, and wxruby.org (was: all I wanted was a class reference...) In-Reply-To: <44E54C50.6080300@pressure.to> References: <44E397F9.5080706@pressure.to> <1155776060.5401.15.camel@localhost.localdomain> <44E501F9.7060103@pressure.to> <1155859936.24318.24.camel@localhost.localdomain> <44E54C50.6080300@pressure.to> Message-ID: <1155910450.12672.8.camel@localhost.localdomain> On Fri, 2006-08-18 at 06:12 +0100, Alex Fenton wrote: > Suggest I hold off doing a commit until after alpha. Am happy to host > the interim docs online for the time being, if that's useful. Will update > the index page with a rider that they're autogenerated and so methods > may be missing or have different signatures. That sounds good. But since we will be publishing the URL, I would prefer that it be a relatively permanent location. Should we push it to our rubyforge web space? I was going to ask about grabbing wxruby.org/com and having the docs there. Then I realized that I should just grab the domains myself before someone else does. So we now have wxruby.com and wxruby.org that point to our project page (which points to the wiki). So, can you add a link to your new API docs on the wiki front page? Kevin From sean.m.long at gmail.com Fri Aug 18 11:04:03 2006 From: sean.m.long at gmail.com (Sean Long) Date: Fri, 18 Aug 2006 08:04:03 -0700 Subject: [Wxruby-users] Where to host the docs, and wxruby.org (was: all I wanted was a class reference...) In-Reply-To: <1155910450.12672.8.camel@localhost.localdomain> References: <44E397F9.5080706@pressure.to> <1155776060.5401.15.camel@localhost.localdomain> <44E501F9.7060103@pressure.to> <1155859936.24318.24.camel@localhost.localdomain> <44E54C50.6080300@pressure.to> <1155910450.12672.8.camel@localhost.localdomain> Message-ID: > I was going to ask about grabbing wxruby.org/com and having the docs > there. Then I realized that I should just grab the domains myself before > someone else does. So we now have wxruby.com and wxruby.org that point > to our project page (which points to the wiki). Good idea, I thought about that other day but forgot to bring it up. I think that simple act just bumped up the status of the project, well at least in some potential users minds it might have. Sean From alex at pressure.to Fri Aug 18 12:35:58 2006 From: alex at pressure.to (Alex Fenton) Date: Fri, 18 Aug 2006 17:35:58 +0100 Subject: [Wxruby-users] Where to host the docs, and wxruby.org In-Reply-To: <1155910450.12672.8.camel@localhost.localdomain> References: <44E397F9.5080706@pressure.to> <1155776060.5401.15.camel@localhost.localdomain> <44E501F9.7060103@pressure.to> <1155859936.24318.24.camel@localhost.localdomain> <44E54C50.6080300@pressure.to> <1155910450.12672.8.camel@localhost.localdomain> Message-ID: <44E5EC6E.8050608@pressure.to> Kevin Smith wrote: > That sounds good. But since we will be publishing the URL, I would > prefer that it be a relatively permanent location. Should we push it to > our rubyforge web space? > Yes, sounds like a good idea. I've just tested publishing to the website and it works fine. Will do a publish once I've cleaned up the doc index page. > So we now have wxruby.com and wxruby.org that point > to our project page (which points to the wiki). > Neat. > So, can you add a link to your new API docs on the wiki front page? > Yep, will update wiki once the stuff is uploaded. cheers alex From joiey.seeley at gmail.com Fri Aug 18 17:18:21 2006 From: joiey.seeley at gmail.com (Joe Seeley) Date: Fri, 18 Aug 2006 16:18:21 -0500 Subject: [Wxruby-users] irc ? Message-ID: <5d0946540608181418r5e773fd2r257bc630cc6faa77@mail.gmail.com> Is there an irc channel for WxRuby development? If not, would anyone be interested in having me set one up? Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20060818/3da21ee4/attachment.html From sean.m.long at gmail.com Sat Aug 19 01:39:44 2006 From: sean.m.long at gmail.com (Sean Long) Date: Fri, 18 Aug 2006 22:39:44 -0700 Subject: [Wxruby-users] all I wanted was a class reference... In-Reply-To: <44E54C50.6080300@pressure.to> References: <44E397F9.5080706@pressure.to> <1155776060.5401.15.camel@localhost.localdomain> <44E501F9.7060103@pressure.to> <1155859936.24318.24.camel@localhost.localdomain> <44E54C50.6080300@pressure.to> Message-ID: I finally got around to checking out the docs and I think they look good. The HTML generated is much cleaner than what is produced with tex2rtf. I did notice that on CommandEvent (http://www.pressure.to/wxruby/commandevent.html) a few of the event handlers did not get renamed. I also like how the wxPython/wxPerl remarks are removed, this makes it look more customized to the wxRuby project. Nice work Sean On 8/17/06, Alex Fenton wrote: > > > I just noticed that the gem chapter of the pickaxe book recommends > > creating a docs/ directory (as opposed to doc/). If that's really a gem > > standard, we should obey. Otherwise, doc/ seems to be slightly more > > common. > > > I agree. As far as I can tell RubyGems doesn't provide any doc > except to rdoc. But I will check the relevant bit of the pickaxe when > I get back to London this evening. > > Suggest I hold off doing a commit until after alpha. Am happy to host > the interim docs online for the time being, if that's useful. Will update > the index page with a rider that they're autogenerated and so methods > may be missing or have different signatures. > > alex > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > From gg at maravan.in Sat Aug 19 07:37:12 2006 From: gg at maravan.in (Ganesh Gunasegaran) Date: Sat, 19 Aug 2006 17:07:12 +0530 Subject: [Wxruby-users] Compiling WxRuby2 on Ubuntu 6.06 Message-ID: <1155987432.18371.14.camel@imayam> Hi All, I am trying to compile WxRuby on Ubuntu 6.06. I checked out the latest source code from CVS and ran 'rake' under the wxruby2 directory. I am getting the following error. root at imayam:/work/wxruby/wxruby2# rake (in /work/wxruby/wxruby2) rake aborted! Don't know how to build task 'src/App.cpp' (See full trace by running task with --trace) I am totally new to SWIG and have absolutely no idea what is going wrong. The following is my environmental setup 1. Ruby root at imayam:/work/wxruby/wxruby2# ruby -v ruby 1.8.4 (2005-12-24) [i686-linux] 2. Rake root at imayam:/work/wxruby/wxruby2# rake --version rake, version 0.7.1 2. GCC root at imayam:/work/wxruby/wxruby2# gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c ++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --with-tune=pentium4 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5) 3. SWIG root at imayam:/work/wxruby/wxruby2# swig -version SWIG Version 1.3.27 Copyright (c) 1995-1998 University of Utah and the Regents of the University of California Copyright (c) 1998-2005 University of Chicagoor Compiled with g++ [i686-pc-linux-gnu] Please see http://www.swig.org for reporting bugs and further information 4. GTK root at imayam:/work/wxruby/wxruby2# pkg-config --modversion gtk+-2.0 2.8.20 5. WxWidgets root at imayam:/work/wxruby/wxruby2# wx-config --version 2.6.1 Please let me know if I am missing something or if I need to install any other prerequisites. I am seriously considering WxRuby for my inhouse projects and eventually write a self published book. Cheers, Ganesh Gunasegaran. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20060819/d9dfc238/attachment.html From wxruby at qualitycode.com Sat Aug 19 10:10:15 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sat, 19 Aug 2006 10:10:15 -0400 Subject: [Wxruby-users] Compiling WxRuby2 on Ubuntu 6.06 In-Reply-To: <1155987432.18371.14.camel@imayam> References: <1155987432.18371.14.camel@imayam> Message-ID: <1155996615.5405.19.camel@localhost.localdomain> On Sat, 2006-08-19 at 17:07 +0530, Ganesh Gunasegaran wrote: > Hi All, Hi, and thanks for trying wxRuby. > I am trying to compile WxRuby on Ubuntu 6.06. I checked out the latest > source code from CVS and ran 'rake' under the wxruby2 directory. I am > getting the following error. > > root at imayam:/work/wxruby/wxruby2# rake > (in /work/wxruby/wxruby2) > rake aborted! > Don't know how to build task 'src/App.cpp' Very strange. I also use Ubuntu 6.06. Actually, I have it on my desktop (where I do wxruby development) and my laptop, where I have not done any wx development. So I tried to compile wxruby2 on my laptop, and here are my notes: - Used cvs to checkout the wxruby2 module from rubyforge - I already had rake 0.6.2 installed, so I used it - Downloaded swig 1.3.29, ran ./configure; make; sudo make install - Obtained libwxgtk2.6-dev package using Synaptic (apt) - Obtained ruby1.8-dev package using Syaptic (apt) At that point, rake successfully started to build wxruby2, going well past App.cpp. I upgraded rake to 0.7.1 (gem update rake), and it still seemed to work. (I got a compile error in RubyConstants.cpp because of wxID_NONE, which I will look into now. Might be a wx 2.6.1 vs. 2.6.3 thing). > (See full trace by running task with --trace) It would probably help if you could run rake --trace to get more details. > 3. SWIG > root at imayam:/work/wxruby/wxruby2# swig -version > > SWIG Version 1.3.27 Unfortunately, we require SWIG 1.3.29, as it has some very substantial improvements over 1.3.27. I don't think this should cause the particular error you are seeing, however. > 5. WxWidgets > root at imayam:/work/wxruby/wxruby2# wx-config --version > 2.6.1 I normally use 2.6.3, but 2.6.1 may work. Even if not, this should not cause the rake error you are seeing. > Please let me know if I am missing something or if I need to install > any other prerequisites. I am seriously considering WxRuby for my > inhouse projects and eventually write a self published book. Great. I believe we will be able to get it working for you. Kevin From wxruby at qualitycode.com Sat Aug 19 10:24:45 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sat, 19 Aug 2006 10:24:45 -0400 Subject: [Wxruby-users] irc ? In-Reply-To: <5d0946540608181418r5e773fd2r257bc630cc6faa77@mail.gmail.com> References: <5d0946540608181418r5e773fd2r257bc630cc6faa77@mail.gmail.com> Message-ID: <1155997485.5405.22.camel@localhost.localdomain> On Fri, 2006-08-18 at 16:18 -0500, Joe Seeley wrote: > Is there an irc channel for WxRuby development? If not, would anyone > be interested in having me set one up? There is no irc channel at this point. I almost never use irc myself, so even if there were a channel, I probably wouldn't participate. However, if other wxruby folk would use it, I think it would be great to have available as a resource. Kevin From wxruby at qualitycode.com Sat Aug 19 11:03:18 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sat, 19 Aug 2006 11:03:18 -0400 Subject: [Wxruby-users] wxNONE and wx 2.6.1 (was: Compiling WxRuby2 on Ubuntu 6.06) In-Reply-To: <1155996615.5405.19.camel@localhost.localdomain> References: <1155987432.18371.14.camel@imayam> <1155996615.5405.19.camel@localhost.localdomain> Message-ID: <1155999798.5405.36.camel@localhost.localdomain> On Sat, 2006-08-19 at 10:10 -0400, Kevin Smith wrote: > (I got a compile error in RubyConstants.cpp because of > wxID_NONE, which I will look into now. Might be a wx 2.6.1 vs. 2.6.3 > thing). It is. wxID_NONE was added in 2.6.2. I would really like to support wx 2.6.1 since it is in Ubuntu 6.06. I see four options: 1. Remove support for wxID_NONE. Great for 2.6.1 users, but bad for 2.6.3 users. 2. Only support wxID_NONE when compiled against wx 2.6.3. This would mean that wxRuby apps couldn't rely on having it available. 3. Define wxID_NONE ourselves if it is not available. However, certain API calls that have defined behavior for wxID_NONE would not work when running on wx 2.6.1. So it would appear to be available, but wouldn't really work. 4. Require wx 2.6.3. 5. Link wx statically into wxruby. Obviously this would make the gem larger. And in the past, when I have attempted static linking, I have struggled. So I'm not sure how long it would take to get it working. It looks like gentoo, Fedora FC-4, and Debian[1] all have wx 2.6.2. So it's just Ubuntu that is a problem.Bummer. I will look into option #5 today. If that doesn't work out, I'm not sure which option I would favor. Kevin From alex at pressure.to Sat Aug 19 11:08:43 2006 From: alex at pressure.to (Alex Fenton) Date: Sat, 19 Aug 2006 16:08:43 +0100 Subject: [Wxruby-users] strip Message-ID: <44E7297B.2060909@pressure.to> Hi Anyone know the correct argument I should give to strip on OS X to remove only unneeded stuff from the bundle. Nick told me once, but I can't find the message in the ml archives. Unfortunately the man page for strip assumes a lot of knowledge... Also - have uploaded the class reference docs to http://wxruby.rubyforge.org/doc/ Plan to carry on improving these once we've shipped an alpha. cheers alex From alex at pressure.to Sat Aug 19 11:19:10 2006 From: alex at pressure.to (Alex Fenton) Date: Sat, 19 Aug 2006 16:19:10 +0100 Subject: [Wxruby-users] wxNONE and wx 2.6.1 In-Reply-To: <1155999798.5405.36.camel@localhost.localdomain> References: <1155987432.18371.14.camel@imayam> <1155996615.5405.19.camel@localhost.localdomain> <1155999798.5405.36.camel@localhost.localdomain> Message-ID: <44E72BEE.1030000@pressure.to> > It is. wxID_NONE was added in 2.6.2. I would really like to support wx > 2.6.1 since it is in Ubuntu 6.06. I see four options: > > 5. Link wx statically into wxruby. Obviously this would make the gem > larger. And in the past, when I have attempted static linking, I have > struggled. So I'm not sure how long it would take to get it working. > I agree this would be preferable. I am pretty sure that when I build wxruby it includes statically linked wx. It actually ran into problems unless wx was built with --enable-static --disable-shared but the unstripped binary is ~12MB... alex From dharple at generalconsumption.org Sat Aug 19 11:21:26 2006 From: dharple at generalconsumption.org (Daniel Harple) Date: Sat, 19 Aug 2006 11:21:26 -0400 Subject: [Wxruby-users] strip In-Reply-To: <44E7297B.2060909@pressure.to> References: <44E7297B.2060909@pressure.to> Message-ID: <332C9994-4794-4AEC-8661-611B01E08327@generalconsumption.org> On Aug 19, 2006, at 11:08 AM, Alex Fenton wrote: > Anyone know the correct argument I should give to strip on OS X to > remove only unneeded stuff from the bundle. Nick told me once, but I > can't find the message in the ml archives. Unfortunately the man page > for strip assumes a lot of knowledge... > > Also - have uploaded the class reference docs to > http://wxruby.rubyforge.org/doc/ > > Plan to carry on improving these once we've shipped an alpha. You mean [dead code stripping][1]? That only works with static linking, and I don't know if it will cause any problems, so make sure you test it thoroughly. [1]: http://developer.apple.com/documentation/DeveloperTools/ Conceptual/XcodeUserGuide/Contents/Resources/en.lproj/ 05_08_bs_linking/chapter_35_section_9.html -- Daniel From wxruby at qualitycode.com Sat Aug 19 23:01:52 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sat, 19 Aug 2006 23:01:52 -0400 Subject: [Wxruby-users] Pre-release wxruby gem available for Linux (was: wxNONE and wx 2.6.1) In-Reply-To: <44E72BEE.1030000@pressure.to> References: <1155987432.18371.14.camel@imayam> <1155996615.5405.19.camel@localhost.localdomain> <1155999798.5405.36.camel@localhost.localdomain> <44E72BEE.1030000@pressure.to> Message-ID: <1156042912.6075.11.camel@localhost.localdomain> On Sat, 2006-08-19 at 16:19 +0100, Alex Fenton wrote: > > 5. Link wx statically into wxruby. Obviously this would make the gem > > larger. And in the past, when I have attempted static linking, I have > > struggled. So I'm not sure how long it would take to get it working. I believe I have succeeded in building a Linux gem with wx 2.6.3 built in statically, so it will work on systems like Ubuntu that have older wx libraries, or no wx at all. I have tried it on one other computer, but would love to have a couple other users test it privately before publishing the gem more widely. So, if you have a Linux box, and would be willing to try downloading the gem (25 megs), installing it, and doing a bit of testing, please let me know. The ideal tester for this is someone who has NOT yet built wxruby from source, but at this point I'll take any testers I can get. Email me off-list ( wxruby at qualitycode.com ), briefly describe your OS environment, and I'll send you the link. Thanks! Kevin From wxruby at qualitycode.com Sun Aug 20 02:11:01 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 20 Aug 2006 02:11:01 -0400 Subject: [Wxruby-users] Should we require 'rubygems' in our samples? Message-ID: <1156054261.9399.6.camel@localhost.localdomain> Twice now, I have had some frustration trying to get my gem path recognized without having to manually specify -rubygems on the command line. It's under-documented in Ubuntu[1]. I'm thinking that we should definitely mention this issue in the README. Shouldn't we also require 'rubygems' in all our samples, to make it as easy as possible for folks to play around with wxruby? If so, I can do it at the same time I insert copyright/license notices. My assumption at this point is that the primary distribution format will be as a gem. And also that basically every ruby system these days will (or should) have rubygems installed. Does that sound right? The upcoming alpha release will consist of: - source tarball - binary gems for MSWin, OS X, and Linux Right? Kevin [1] The best place to configure RUBYOPT=-rubygems is /etc/environment because other locations are only used for interactive shells, or are NOT used for interactive shells. But /etc/environment is only read at user login, so after you change it there is no effect until you log out. I was only able to piece that together by reading several forum threads. From stephen.ng at planetnutek.com Sun Aug 20 07:40:24 2006 From: stephen.ng at planetnutek.com (Stephen Ng) Date: Sun, 20 Aug 2006 19:40:24 +0800 Subject: [Wxruby-users] Compiling WxRuby2 on Ubuntu 6.06 Message-ID: <44E84A28.8020401@planetnutek.com> Kevin, I also have the same problem, but on FC5. I get the following output when running rake - I checked out the CVS and typed rake and got the following (with --trace) - (in .....) SWIG Version 1.3.24 Copyright (c) 1995-1998 University of Utah and the Regents of the University of California Copyright (c) 1998-2004 University of Chicago Compiled with i386-redhat-linux-g++ [i386-redhat-linux-gnu] Please see http://www.swig.org for reporting bugs and further information Doing slower check for SWIG 1.3.29 ** Invoke default (first_time) ** Invoke link (first_time) ** Invoke lib/wxruby2.so (first_time) ** Invoke obj/App.o (first_time) rake aborted! Don't know how to build task 'src/App.cpp' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1449:in `[]' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in `invoke_prerequisites'/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/bin/rake:7 /usr/bin/rake:18 I am running FC5, with wxWidgets-2.6.3 installed from source. Regards. Stephen Ng From wxruby at qualitycode.com Sun Aug 20 09:12:15 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 20 Aug 2006 09:12:15 -0400 Subject: [Wxruby-users] Compiling WxRuby2 on Ubuntu 6.06 In-Reply-To: <44E84A28.8020401@planetnutek.com> References: <44E84A28.8020401@planetnutek.com> Message-ID: <1156079535.2953.6.camel@localhost.localdomain> On Sun, 2006-08-20 at 19:40 +0800, Stephen Ng wrote: > I also have the same problem, but on FC5. I get the following output > when running rake - > > I checked out the CVS and typed rake and got the following (with --trace) - > > (in .....) > > SWIG Version 1.3.24 > Copyright (c) 1995-1998 > University of Utah and the Regents of the University of California > Copyright (c) 1998-2004 > University of Chicago > Compiled with i386-redhat-linux-g++ [i386-redhat-linux-gnu] > > Please see http://www.swig.org for reporting bugs and further information > Doing slower check for SWIG 1.3.29 > ** Invoke default (first_time) > ** Invoke link (first_time) > ** Invoke lib/wxruby2.so (first_time) > ** Invoke obj/App.o (first_time) > rake aborted! > Don't know how to build task 'src/App.cpp' Ok, so that's the problem. If you have a too-old SWIG, for some reason rake fails to output useful information. Even with --trace enabled, the output is really poor. Could you (or someone) enter a rubyforge bug for that. Hopefully then someone can fix it easily, since it is pure ruby code in the rakefile. No knowledge of C++ or SWIG or even wxruby is required. I don't think this is a showstopper for the alpha release, since the alpha release is primarily about the binary gems, not the source tarball. Thanks, Kevin From gg at maravan.in Sun Aug 20 10:01:41 2006 From: gg at maravan.in (Ganesh Gunasegaran) Date: Sun, 20 Aug 2006 19:31:41 +0530 Subject: [Wxruby-users] Compiling WxRuby2 on Ubuntu 6.06 In-Reply-To: <1155996615.5405.19.camel@localhost.localdomain> References: <1155987432.18371.14.camel@imayam> <1155996615.5405.19.camel@localhost.localdomain> Message-ID: <1156082501.8078.4.camel@imayam> Hi Kevin, Thanks for the reply. The problem seems to be in the SWIG version I had. I happened to have SWIG 1.3.27 installed thro' Synaptic Package Manager. I downloaded and compiled SWIG 1.3.29 from source and then ran rake. WxRuby compilation went thro' just fine. Cheers, Ganesh Gunasegaran. On Sat, 2006-08-19 at 10:10 -0400, Kevin Smith wrote: > On Sat, 2006-08-19 at 17:07 +0530, Ganesh Gunasegaran wrote: > > Hi All, > > Hi, and thanks for trying wxRuby. > > > I am trying to compile WxRuby on Ubuntu 6.06. I checked out the latest > > source code from CVS and ran 'rake' under the wxruby2 directory. I am > > getting the following error. > > > > root at imayam:/work/wxruby/wxruby2# rake > > (in /work/wxruby/wxruby2) > > rake aborted! > > Don't know how to build task 'src/App.cpp' > > Very strange. I also use Ubuntu 6.06. Actually, I have it on my desktop > (where I do wxruby development) and my laptop, where I have not done any > wx development. So I tried to compile wxruby2 on my laptop, and here are > my notes: > > - Used cvs to checkout the wxruby2 module from rubyforge > - I already had rake 0.6.2 installed, so I used it > - Downloaded swig 1.3.29, ran ./configure; make; sudo make install > - Obtained libwxgtk2.6-dev package using Synaptic (apt) > - Obtained ruby1.8-dev package using Syaptic (apt) > > At that point, rake successfully started to build wxruby2, going well > past App.cpp. I upgraded rake to 0.7.1 (gem update rake), and it still > seemed to work. (I got a compile error in RubyConstants.cpp because of > wxID_NONE, which I will look into now. Might be a wx 2.6.1 vs. 2.6.3 > thing). > > > (See full trace by running task with --trace) > > It would probably help if you could run rake --trace to get more > details. > > > 3. SWIG > > root at imayam:/work/wxruby/wxruby2# swig -version > > > > SWIG Version 1.3.27 > > Unfortunately, we require SWIG 1.3.29, as it has some very substantial > improvements over 1.3.27. I don't think this should cause the particular > error you are seeing, however. > > > 5. WxWidgets > > root at imayam:/work/wxruby/wxruby2# wx-config --version > > 2.6.1 > > I normally use 2.6.3, but 2.6.1 may work. Even if not, this should not > cause the rake error you are seeing. > > > Please let me know if I am missing something or if I need to install > > any other prerequisites. I am seriously considering WxRuby for my > > inhouse projects and eventually write a self published book. > > Great. I believe we will be able to get it working for you. > > Kevin > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users From gg at maravan.in Sun Aug 20 10:28:51 2006 From: gg at maravan.in (Ganesh Gunasegaran) Date: Sun, 20 Aug 2006 19:58:51 +0530 Subject: [Wxruby-users] Compiling WxRuby2 on Ubuntu 6.06 In-Reply-To: <1156082501.8078.4.camel@imayam> References: <1155987432.18371.14.camel@imayam> <1155996615.5405.19.camel@localhost.localdomain> <1156082501.8078.4.camel@imayam> Message-ID: <1156084132.8078.13.camel@imayam> Hi All, Now ruby is not able to load wxruby2 library :( root at imayam:/work/wxruby/wxruby2/samples# irb irb(main):001:0> require 'wx' Unable to load wxruby. Searched /usr/lib/ruby/site_ruby/1.8 /usr/lib/ruby/site_ruby/1.8/i686-linux /usr/lib/ruby/site_ruby /usr/lib/ruby/1.8 /usr/lib/ruby/1.8/i686-linux I have checked that the wxruby2 libraries are indeed present in the search path. root at imayam:/usr/lib/ruby/site_ruby/1.8/i686-linux# ls wx* wx.rb wxruby2.so I then tried to load wxruby2 directly and got this irb(main):002:0> require 'wxruby2' LoadError: libwx_gtk2_xrc-2.6.so.0: cannot open shared object file: No such file or directory - /usr/lib/ruby/site_ruby/1.8/i686-linux/wxruby2.so from /usr/lib/ruby/site_ruby/1.8/i686-linux/wxruby2.so from (irb):2 So it looks like there is something wrong with my WxGTK installation? I compiled WxWidgets 2.6.3 from source. root at imayam:/work/wxruby/wxruby2/samples# wx-config --version 2.6.3 If I am not able to resolve this issue, Kevin do you mind sending me the link to static linked gem you were mentioning? I would be happy to test it out. Cheers, Ganesh Gunasegaran. On Sun, 2006-08-20 at 19:31 +0530, Ganesh Gunasegaran wrote: > Hi Kevin, > > Thanks for the reply. The problem seems to be in the SWIG version I had. > I happened to have SWIG 1.3.27 installed thro' Synaptic Package > Manager. > > I downloaded and compiled SWIG 1.3.29 from source and then ran rake. > WxRuby compilation went thro' just fine. > > Cheers, > Ganesh Gunasegaran. > > On Sat, 2006-08-19 at 10:10 -0400, Kevin Smith wrote: > > On Sat, 2006-08-19 at 17:07 +0530, Ganesh Gunasegaran wrote: > > > Hi All, > > > > Hi, and thanks for trying wxRuby. > > > > > I am trying to compile WxRuby on Ubuntu 6.06. I checked out the latest > > > source code from CVS and ran 'rake' under the wxruby2 directory. I am > > > getting the following error. > > > > > > root at imayam:/work/wxruby/wxruby2# rake > > > (in /work/wxruby/wxruby2) > > > rake aborted! > > > Don't know how to build task 'src/App.cpp' > > > > Very strange. I also use Ubuntu 6.06. Actually, I have it on my desktop > > (where I do wxruby development) and my laptop, where I have not done any > > wx development. So I tried to compile wxruby2 on my laptop, and here are > > my notes: > > > > - Used cvs to checkout the wxruby2 module from rubyforge > > - I already had rake 0.6.2 installed, so I used it > > - Downloaded swig 1.3.29, ran ./configure; make; sudo make install > > - Obtained libwxgtk2.6-dev package using Synaptic (apt) > > - Obtained ruby1.8-dev package using Syaptic (apt) > > > > At that point, rake successfully started to build wxruby2, going well > > past App.cpp. I upgraded rake to 0.7.1 (gem update rake), and it still > > seemed to work. (I got a compile error in RubyConstants.cpp because of > > wxID_NONE, which I will look into now. Might be a wx 2.6.1 vs. 2.6.3 > > thing). > > > > > (See full trace by running task with --trace) > > > > It would probably help if you could run rake --trace to get more > > details. > > > > > 3. SWIG > > > root at imayam:/work/wxruby/wxruby2# swig -version > > > > > > SWIG Version 1.3.27 > > > > Unfortunately, we require SWIG 1.3.29, as it has some very substantial > > improvements over 1.3.27. I don't think this should cause the particular > > error you are seeing, however. > > > > > 5. WxWidgets > > > root at imayam:/work/wxruby/wxruby2# wx-config --version > > > 2.6.1 > > > > I normally use 2.6.3, but 2.6.1 may work. Even if not, this should not > > cause the rake error you are seeing. > > > > > Please let me know if I am missing something or if I need to install > > > any other prerequisites. I am seriously considering WxRuby for my > > > inhouse projects and eventually write a self published book. > > > > Great. I believe we will be able to get it working for you. > > > > Kevin > > > > > > _______________________________________________ > > wxruby-users mailing list > > wxruby-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wxruby-users > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20060820/a15fad4a/attachment-0001.html From gg at maravan.in Sun Aug 20 10:34:13 2006 From: gg at maravan.in (Ganesh Gunasegaran) Date: Sun, 20 Aug 2006 20:04:13 +0530 Subject: [Wxruby-users] Compiling WxRuby2 on Ubuntu 6.06 In-Reply-To: <1156084132.8078.13.camel@imayam> References: <1155987432.18371.14.camel@imayam> <1155996615.5405.19.camel@localhost.localdomain> <1156082501.8078.4.camel@imayam> <1156084132.8078.13.camel@imayam> Message-ID: <1156084453.8078.18.camel@imayam> Never mind. WxWidgets seems to be installed in /usr/local/lib, which was not included in the LD_LIBRARY_PATH for my root login. After including /usr/local/lib in LD_LIBRARY_PATH samples work fine. Sorry guys, my bad!! I will hopefully give wxruby2 a good spin. Thanks for the great work. Cheers, Ganesh Gunasegaran. On Sun, 2006-08-20 at 19:58 +0530, Ganesh Gunasegaran wrote: > Hi All, > > Now ruby is not able to load wxruby2 library :( > > root at imayam:/work/wxruby/wxruby2/samples# irb > irb(main):001:0> require 'wx' > Unable to load wxruby. Searched > /usr/lib/ruby/site_ruby/1.8 > /usr/lib/ruby/site_ruby/1.8/i686-linux > /usr/lib/ruby/site_ruby > /usr/lib/ruby/1.8 > /usr/lib/ruby/1.8/i686-linux > > I have checked that the wxruby2 libraries are indeed present in the > search path. > > root at imayam:/usr/lib/ruby/site_ruby/1.8/i686-linux# ls wx* > wx.rb wxruby2.so > > I then tried to load wxruby2 directly and got this > > irb(main):002:0> require 'wxruby2' > LoadError: libwx_gtk2_xrc-2.6.so.0: cannot open shared object file: No > such file or directory > - /usr/lib/ruby/site_ruby/1.8/i686-linux/wxruby2.so > from /usr/lib/ruby/site_ruby/1.8/i686-linux/wxruby2.so > from (irb):2 > > So it looks like there is something wrong with my WxGTK installation? > I compiled WxWidgets 2.6.3 from source. > > root at imayam:/work/wxruby/wxruby2/samples# wx-config --version > 2.6.3 > > If I am not able to resolve this issue, Kevin do you mind sending me > the link to static linked gem you were mentioning? I would be happy to > test it out. > > Cheers, > Ganesh Gunasegaran. > > On Sun, 2006-08-20 at 19:31 +0530, Ganesh Gunasegaran wrote: > > Hi Kevin, > > > > Thanks for the reply. The problem seems to be in the SWIG version I had. > > I happened to have SWIG 1.3.27 installed thro' Synaptic Package > > Manager. > > > > I downloaded and compiled SWIG 1.3.29 from source and then ran rake. > > WxRuby compilation went thro' just fine. > > > > Cheers, > > Ganesh Gunasegaran. > > > > On Sat, 2006-08-19 at 10:10 -0400, Kevin Smith wrote: > > > On Sat, 2006-08-19 at 17:07 +0530, Ganesh Gunasegaran wrote: > > > > Hi All, > > > > > > Hi, and thanks for trying wxRuby. > > > > > > > I am trying to compile WxRuby on Ubuntu 6.06. I checked out the latest > > > > source code from CVS and ran 'rake' under the wxruby2 directory. I am > > > > getting the following error. > > > > > > > > root at imayam:/work/wxruby/wxruby2# rake > > > > (in /work/wxruby/wxruby2) > > > > rake aborted! > > > > Don't know how to build task 'src/App.cpp' > > > > > > Very strange. I also use Ubuntu 6.06. Actually, I have it on my desktop > > > (where I do wxruby development) and my laptop, where I have not done any > > > wx development. So I tried to compile wxruby2 on my laptop, and here are > > > my notes: > > > > > > - Used cvs to checkout the wxruby2 module from rubyforge > > > - I already had rake 0.6.2 installed, so I used it > > > - Downloaded swig 1.3.29, ran ./configure; make; sudo make install > > > - Obtained libwxgtk2.6-dev package using Synaptic (apt) > > > - Obtained ruby1.8-dev package using Syaptic (apt) > > > > > > At that point, rake successfully started to build wxruby2, going well > > > past App.cpp. I upgraded rake to 0.7.1 (gem update rake), and it still > > > seemed to work. (I got a compile error in RubyConstants.cpp because of > > > wxID_NONE, which I will look into now. Might be a wx 2.6.1 vs. 2.6.3 > > > thing). > > > > > > > (See full trace by running task with --trace) > > > > > > It would probably help if you could run rake --trace to get more > > > details. > > > > > > > 3. SWIG > > > > root at imayam:/work/wxruby/wxruby2# swig -version > > > > > > > > SWIG Version 1.3.27 > > > > > > Unfortunately, we require SWIG 1.3.29, as it has some very substantial > > > improvements over 1.3.27. I don't think this should cause the particular > > > error you are seeing, however. > > > > > > > 5. WxWidgets > > > > root at imayam:/work/wxruby/wxruby2# wx-config --version > > > > 2.6.1 > > > > > > I normally use 2.6.3, but 2.6.1 may work. Even if not, this should not > > > cause the rake error you are seeing. > > > > > > > Please let me know if I am missing something or if I need to install > > > > any other prerequisites. I am seriously considering WxRuby for my > > > > inhouse projects and eventually write a self published book. > > > > > > Great. I believe we will be able to get it working for you. > > > > > > Kevin > > > > > > > > > _______________________________________________ > > > wxruby-users mailing list > > > wxruby-users at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > _______________________________________________ > > wxruby-users mailing list > > wxruby-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wxruby-users > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users From gg at maravan.in Sun Aug 20 11:30:08 2006 From: gg at maravan.in (Ganesh Gunasegaran) Date: Sun, 20 Aug 2006 21:00:08 +0530 Subject: [Wxruby-users] Booklet on WxRuby2 Message-ID: <1156087808.8078.28.camel@imayam> Hi there, I am planning to write a small booklet on WxRuby2. The approach will be to "Document while you learn". I will be adding contents as and when I explore WxRuby2. I have just added a content skeleton. Please take a look at http://wiki.sagework.com/BooksWxRuby and let me know if you have any suggestions. I will keep the list updated about the progress. Cheers, Ganesh Gunasegaran. From alang.yl at gmail.com Sun Aug 20 12:32:21 2006 From: alang.yl at gmail.com (Crest) Date: Mon, 21 Aug 2006 00:32:21 +0800 Subject: [Wxruby-users] Booklet on WxRuby2 In-Reply-To: <1156087808.8078.28.camel@imayam> References: <1156087808.8078.28.camel@imayam> Message-ID: <7fed9b030608200932o45cb4d7ld6d91f266b90bef0@mail.gmail.com> Great! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20060821/d5c9bf34/attachment.html From alex at pressure.to Sun Aug 20 16:08:16 2006 From: alex at pressure.to (Alex Fenton) Date: Sun, 20 Aug 2006 21:08:16 +0100 Subject: [Wxruby-users] Compiling WxRuby2 on Ubuntu 6.06 In-Reply-To: <1156079535.2953.6.camel@localhost.localdomain> References: <44E84A28.8020401@planetnutek.com> <1156079535.2953.6.camel@localhost.localdomain> Message-ID: <44E8C130.7030502@pressure.to> > Could you (or someone) enter a rubyforge bug for that. Hopefully then > someone can fix it easily, since it is pure ruby code in the rakefile. > No knowledge of C++ or SWIG or even wxruby is required. > Have filed a bug for this, will have a shot at submitting a patch later this week. cheers alex From alex at pressure.to Sun Aug 20 16:38:55 2006 From: alex at pressure.to (Alex Fenton) Date: Sun, 20 Aug 2006 21:38:55 +0100 Subject: [Wxruby-users] Should we require 'rubygems' in our samples? In-Reply-To: <1156054261.9399.6.camel@localhost.localdomain> References: <1156054261.9399.6.camel@localhost.localdomain> Message-ID: <44E8C85F.40806@pressure.to> Kevin Smith wrote: > Twice now, I have had some frustration trying to get my gem path > recognized without having to manually specify -rubygems on the command > line. > This aspect of rubygems is a common frustration; it comes up pretty frequently on the general ruby mailing lists too. > I'm thinking that we should definitely mention this issue in the README. > Definitely. > Shouldn't we also require 'rubygems' in all our samples, to make it as > easy as possible for folks to play around with wxruby? > I would suggest probably not. My impression is that other ruby libs don't do this. It's a one-time issue for ruby generally, and hopefully the large majority of people will have either never had the problem (Windows) or have solved it for some previous use. I prefer it to the alternative of making rubygems a prerequisite, by adding 'require rubygems'. Or wrap it in a begin...rescue, but it starts getting a bit messy. Some people have reasons for not wanting to install rubygems. > My assumption at this point is that the primary distribution format will > be as a gem. And also that basically every ruby system these days will > (or should) have rubygems installed. Does that sound right? > Well, it widely used, but not everywhere. It's not part of the standard library. > The upcoming alpha release will consist of: > - source tarball > - binary gems for MSWin, OS X, and Linux > Yup. Let me know when you create the release and I'll upload an OS X gem. cheers alex From alex at pressure.to Sun Aug 20 16:43:30 2006 From: alex at pressure.to (Alex Fenton) Date: Sun, 20 Aug 2006 21:43:30 +0100 Subject: [Wxruby-users] Pre-release wxruby gem available for OS X In-Reply-To: <1156042912.6075.11.camel@localhost.localdomain> References: <1155987432.18371.14.camel@imayam> <1155996615.5405.19.camel@localhost.localdomain> <1155999798.5405.36.camel@localhost.localdomain> <44E72BEE.1030000@pressure.to> <1156042912.6075.11.camel@localhost.localdomain> Message-ID: <44E8C972.20507@pressure.to> Kevin Smith wrote: > On Sat, 2006-08-19 at 16:19 +0100, Alex Fenton wrote: > >>> 5. Link wx statically into wxruby. Obviously this would make the gem >>> larger. And in the past, when I have attempted static linking, I have >>> struggled. So I'm not sure how long it would take to get it working. >>> Great, well done. Did you have to change anything in our build system, or just change the options that WxWidgets is built with? If anyone has an OS X PPC system, it would be great if you could try out a pre-release gem to check it has everything. Drop me a line off-list (alex AT pressure DOT to) cheers alex From wxruby at qualitycode.com Sun Aug 20 21:07:27 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 20 Aug 2006 21:07:27 -0400 Subject: [Wxruby-users] SashWindows In-Reply-To: <44E54A06.1050204@pressure.to> References: <44CF9255.4030905@pressure.to> <1155481807.11659.36.camel@localhost.localdomain> <44E54A06.1050204@pressure.to> Message-ID: <1156122447.2953.7.camel@localhost.localdomain> On Fri, 2006-08-18 at 06:03 +0100, Alex Fenton wrote: > Kevin Smith wrote: > > 3. Dragging the vertical sash crashes with a runtime error > > > Could you try the attached patch, please? Yup, that fixed the crash. The sash boundaries are still invisible until I start to drag them, but the dragging does work. Thanks, Kevin From wxruby at qualitycode.com Sun Aug 20 21:14:07 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 20 Aug 2006 21:14:07 -0400 Subject: [Wxruby-users] update on samples In-Reply-To: <44DFB607.6080703@pressure.to> References: <44DB76AD.50901@pressure.to> <1155494351.11659.88.camel@localhost.localdomain> <44DFB607.6080703@pressure.to> Message-ID: <1156122847.2953.11.camel@localhost.localdomain> On Mon, 2006-08-14 at 00:30 +0100, Alex Fenton wrote: > Should we drop LayoutConstraints - it is deprecated in Wx? Yes, we should. But it is used in bigdemo LayoutConstraints and also ScrolledMessageDialog, so we need to remove both of those before deleting the .i file. > >> - listbook.rb > >> OK, except breaks if not run from own directory. > >> > > > > Brings up a big blank window for me. If this is only available on > > certain platforms, we should say so. > > > Could you confirm that this isn't a problem with loading the XRC - I > committed a fix to load the XRC from the right place even if the script > is run from elsewhere. Definitely still blank when run from the listbook directory. There are a couple GTK warnings that imply that it is at least attempting to load the XRC file. Thanks, Kevin From wxruby at qualitycode.com Sun Aug 20 22:09:07 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 20 Aug 2006 22:09:07 -0400 Subject: [Wxruby-users] wxruby2 alpha status In-Reply-To: <44E5536C.8010403@pressure.to> References: <1155496758.11659.122.camel@localhost.localdomain> <1155871140.30640.9.camel@localhost.localdomain> <44E5536C.8010403@pressure.to> Message-ID: <1156126147.2953.18.camel@localhost.localdomain> On Fri, 2006-08-18 at 06:43 +0100, Alex Fenton wrote: > Kevin Smith wrote: > >> How soon can we do our alpha (binary gem) release? > >> > > How about this weekend? As "this weekend" comes to an end, it's clear the release won't happen quite that soon. I am optimistic that we may have a release ready before the end of this coming week. I am waiting to hear from a couple Linux gem testers. The samples still need license notices. The README (or some file) should describe "known problems" in some detail, including cases where the samples don't work as expected, and also general library problems. Those are the only tasks I can think of that are holding up the release. > Equally, I think we should mention what is exciting and new about this > release, from an end-user perspective. Otherwise, people might be like > 'They spent years re-engineering and 18 months since last release - for > what?' Very true. I just overhauled the README file, and included a lengthy FAQ section that addresses this issue. I have pasted that section below, and would appreciate any feedback, or suggestions for additional questions to include. (Apologies for the formatting here due to email wrapping at 65 characters). Kevin ------------------------FAQ--------------------------- - Why would I choose wxruby over FXRuby, Ruby/GTK, or one of the other GUI toolkits? Isn't wxruby arriving "too late"? There are several great GUI toolkits available for Ruby, but we like wxruby better because it has a combination of features that no other toolkit has: - Cross-platform (MSWindows, Mac OS X, Linux) - Native widgets when possible - Provides a wide selection of widgets - Mature foundation (wxWidgets has been around for over 10 years) - Simple license that is compatible with proprietary and Free Software The really big feature is native widgets. The only other cross-platform toolkits that use native widgets are either limited (Tk) or expensive if you want to develop proprietary software (Qt). We are not saying that those toolkits are bad! Just that wxruby offers a unique set of features. - Why are native widgets important or helpful? For one thing, it means that end-users do not have to adjust to a "foreign" interface. It also ensures maximum compatibility with "assistive technology" such as screen readers for blind users. It also allows apps to respect any themes the user may have chosen through their operating system. No matter how hard a toolkit may try to emulate a particular UI, there will always be differences in the look or behavior. - How does wxruby2 relate to wxruby (and the wxruby 0.6.0 release)? wxruby2 is the "next generation" of wxruby. It is being developed by the same wxruby team, and is intended to replace the older code base. wxruby2 is built using SWIG, a powerful tool that makes it much easier to create and maintain wrappers around C/C++ libraries. - Why should I use wxruby2 instead of wxruby? First, because development on the original wxruby codebase has stopped. Everyone is working on wxruby2, so it will continue to improve. Beyond that, wxruby2 has these advantages over wxruby 0.6.0: - Available as binary gems for MSWindows, OS X, and Linux (GTK) - Support for more classes, and more methods within classes - Unicode support - Vastly improved support for OS X - Looks much better under Linux because it uses GTK+2 - Simpler and more permissive license - Wraps wxWidgets 2.6.3 instead of the older 2.4 series - Is wxruby2 ready for "production" use? No. We are still working on memory handling, so the current wxruby2 code has memory leaks, double-free crashes, and other problems. Thanks to the power of SWIG, wxruby2 will soon be more stable and reliable than wxruby 0.6.0 (which also was never really stable enough for heavy-duty "production" use). - Does wxruby2 support the Xxx class? See the "Documentation" section of the README file, or check the wxruby web site: http://wxruby.org - How are the wxruby 0.6.0 and wxruby2 licenses different? wxruby 0.6.0 was released under the wxWindows license, which is a modified LGPL. It is a good, fair license, allowing use in both Free Software and proprietary applications. However, it is long and complex, and is more appropriate for compiled code. wxruby2 is available under a *very* simple MIT-style license, which allows just about any use with very few restrictions. - The API doesn't seem very Ruby-like The current API is basically a straight port of the wxWidgets C++ interface. Well, actually it has several of the same adjustments that wxPython also had to adopt due to language constraints. This interface is a bit clumsy in spots, thanks to its long history. Over time, we plan to create a Ruby-specific layer on top of the basic wx API, similar to what FXRuby has done for FOX. This enhanced API will be simpler to use, and will be oriented toward the Ruby Way. - I am getting an error trying to compile wxruby2 Please double-check the requirements. You may be using the wrong version of SWIG or some other tool. - I am getting an error trying to run any wxruby2 application, such as the samples that are included in the gem. If you are using Linux, be sure you have configured your system to have RUBYOPT=-rubygems. This can be done in .bashrc or /etc/environment, depending on your distribution and preferences. [More details to follow]. - Why aren't the wx network, file, date, and other non-GUI classes supported? Because Ruby has its own versions of each of them. We assume you are writing your application in Ruby, so it makes sense to keep as much code as possible in Ruby. We have only wrapped the wx classes that are necessary to write GUI code. - Why has it taken so long for wxruby2 to be released? Nobody is getting paid to develop wxruby, so each of the wxruby developers are limited in the amount of time they can dedicate to the project. We are always looking for more volunteers to help code, test, document, manage the bug list, handle publicity, or do other necessary chores. From wxruby at qualitycode.com Sun Aug 20 22:11:42 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 20 Aug 2006 22:11:42 -0400 Subject: [Wxruby-users] wxruby gem not working [FIXED!] In-Reply-To: <44E5468C.5070702@pressure.to> References: <1155496758.11659.122.camel@localhost.localdomain> <44E26EAF.2050504@pressure.to> <1155858903.24318.17.camel@localhost.localdomain> <44E50413.7000605@pressure.to> <1155861099.24318.28.camel@localhost.localdomain> <1155870473.30640.3.camel@localhost.localdomain> <44E5468C.5070702@pressure.to> Message-ID: <1156126303.2953.21.camel@localhost.localdomain> On Fri, 2006-08-18 at 05:48 +0100, Alex Fenton wrote: > Kevin Smith wrote: > > Should rake install build and install the gem, by default? > Maybe not? - when testing new features etc I usually do > > ruby -Ilib samples/foo/bar.rb > > To run the code against my changes - but also keep a 'stable' reference > version installed in gems. That probably makes sense. For the last few months I have been doing much more patch merging than actual coding, so I haven't bothered to keep a stable copy around. I have been doing 'rake install' whenever I have wanted to test a new build. I will probably create some kind of alias that includes -Ilib. > > Is it possible to tell gem to install over an existing gem, even if the > > version is the same? > It seems to me to do this by default, if you say 'sudo gem install > wxruby'. See below. Maybe the --force option but I don't think it's > intended for this. It does indeed seem to work. Cool. Kevin From wxruby at qualitycode.com Sun Aug 20 22:22:16 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 20 Aug 2006 22:22:16 -0400 Subject: [Wxruby-users] gem version numbering Message-ID: <1156126936.2953.28.camel@localhost.localdomain> Hi all, I am concerned about the version number for our gem. Currently, we have it set to 1.9, indicating that it is "before the upcoming 2.0 release". However, there is nothing in the version number that indicates this is a "preview" "alpha" "buggy" release. The gem version numbering scheme does not allow things like 2.0-pre. It also requires each public release of a gem to have a different version number. I now believe that we should call this wxruby 0.9.0. It is newer than wxruby 0.6.0 (which was never released as a gem, and probably never will be). It is not yet "1.0" quality. We can cycle through the 0.9.0 versions until we actually hit wxruby 1.0 (which will of course be based on the wxruby2 code base). Thoughts? Kevin From sean.m.long at gmail.com Sun Aug 20 22:26:13 2006 From: sean.m.long at gmail.com (Sean Long) Date: Sun, 20 Aug 2006 19:26:13 -0700 Subject: [Wxruby-users] TreeCtrl update In-Reply-To: References: Message-ID: Has anyone had a chance to look at these changes I made? I think it would be nice to get it in before an alpha release. Sean On 8/18/06, Sean Long wrote: > The previous TreeCtrl.i was very messy and just plain wrong, for > instance it had GetFirstChild as depreciated when in fact only 1 > version of it was depreciated not both. > > I changed GetFirstChild and GetNextChild to return an array of values > to match the wxPython and wxPerl usage. > > I also noticed that wxTreeCtrl is inherited from wxControl on Windows > and wxScrolledWindow on everything else so I #if defined the .i and .h > file accordingly. > > I also added a .i and .h file for the class wxTreeItemId. > > The TreeCtrl files were changed so much that I am just uploading the > whole files instead of the diffs. > > traverse_tree(tree_ctrl,tree_ctrl.get_root_item) do |node_id,cookie| > puts "Name: #{tree_ctrl.get_item_text(node_id)}\t\tCookie: > #{cookie}" > end > > def traverse_tree(tree_ctrl,root_node,cookie=0,&block) > if cookie == 0 > ret = tree_ctrl.get_first_child(root_node) > else > ret = tree_ctrl.get_next_child(root_node,cookie) > end > > if ret[0].is_ok > if block_given? > yield(ret[0],ret[1]) > end > > traverse_tree(tree_ctrl,ret[0],0,&block) > end > > ret_sib = tree_ctrl.get_next_sibling(root_node) > if ret_sib.is_ok > if block_given? > yield(ret_sib,cookie) > end > traverse_tree(tree_ctrl,ret_sib,0,&block) > end > > end > > > Sean > > > From roys at mindspring.com Sun Aug 20 22:27:42 2006 From: roys at mindspring.com (Roy Sutton) Date: Sun, 20 Aug 2006 22:27:42 -0400 Subject: [Wxruby-users] gem version numbering In-Reply-To: <1156126936.2953.28.camel@localhost.localdomain> References: <1156126936.2953.28.camel@localhost.localdomain> Message-ID: <44E91A1E.2050406@mindspring.com> Kevin Smith wrote: > I now believe that we should call this wxruby 0.9.0. It is newer than > wxruby 0.6.0 (which was never released as a gem, and probably never will > be). It is not yet "1.0" quality. We can cycle through the 0.9.0 > versions until we actually hit wxruby 1.0 (which will of course be based > on the wxruby2 code base). > > I have no problem with that. Roy From wxruby at qualitycode.com Sun Aug 20 22:27:33 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 20 Aug 2006 22:27:33 -0400 Subject: [Wxruby-users] Pre-release wxruby gem available for OS X In-Reply-To: <44E8C972.20507@pressure.to> References: <1155987432.18371.14.camel@imayam> <1155996615.5405.19.camel@localhost.localdomain> <1155999798.5405.36.camel@localhost.localdomain> <44E72BEE.1030000@pressure.to> <1156042912.6075.11.camel@localhost.localdomain> <44E8C972.20507@pressure.to> Message-ID: <1156127253.2953.32.camel@localhost.localdomain> On Sun, 2006-08-20 at 21:43 +0100, Alex Fenton wrote: > Kevin Smith wrote: > > On Sat, 2006-08-19 at 16:19 +0100, Alex Fenton wrote: > > > >>> 5. Link wx statically into wxruby. Obviously this would make the gem > >>> larger. And in the past, when I have attempted static linking, I have > >>> struggled. So I'm not sure how long it would take to get it working. > >>> > Great, well done. Did you have to change anything in our build system, > or just change the options that WxWidgets is built with? I created a new wxWidgets configuration, built it, selected it with wx-config, and un-commented the rakelinux.rb code that (apparently) had worked for me before. I did a bunch of searching the web to try to figure out the secret of having multiple wx builds on my system. The answer was in the INSTALL file that ships with wx, but nothing on the web pointed me there. I finally found it when I abandoned the web and looked at the wx README. Even there, it's not documented as well as I would like. But it worked. Kevin From wxruby at qualitycode.com Sun Aug 20 22:29:23 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 20 Aug 2006 22:29:23 -0400 Subject: [Wxruby-users] Should we require 'rubygems' in our samples? In-Reply-To: <44E8C85F.40806@pressure.to> References: <1156054261.9399.6.camel@localhost.localdomain> <44E8C85F.40806@pressure.to> Message-ID: <1156127363.2953.35.camel@localhost.localdomain> On Sun, 2006-08-20 at 21:38 +0100, Alex Fenton wrote: > Kevin Smith wrote: > > Shouldn't we also require 'rubygems' in all our samples, to make it as > > easy as possible for folks to play around with wxruby? > > > I would suggest probably not. My impression is that other ruby libs > don't do this. It's a one-time issue for ruby generally, and hopefully > the large majority of people will have either never had the problem > (Windows) or have solved it for some previous use. I now agree with you. > Yup. Let me know when you create the release and I'll upload an OS X gem. Excellent. I'm sure I should know this already, but who volunteered to do our MSWindows build this time? Kevin From wxruby at qualitycode.com Sun Aug 20 22:37:54 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 20 Aug 2006 22:37:54 -0400 Subject: [Wxruby-users] TreeCtrl update In-Reply-To: References: Message-ID: <1156127874.2953.37.camel@localhost.localdomain> They are in. Thanks, Kevin On Sun, 2006-08-20 at 19:26 -0700, Sean Long wrote: > Has anyone had a chance to look at these changes I made? I think it > would be nice to get it in before an alpha release. > > Sean > > On 8/18/06, Sean Long wrote: > > The previous TreeCtrl.i was very messy and just plain wrong, for > > instance it had GetFirstChild as depreciated when in fact only 1 > > version of it was depreciated not both. > > > > I changed GetFirstChild and GetNextChild to return an array of values > > to match the wxPython and wxPerl usage. > > > > I also noticed that wxTreeCtrl is inherited from wxControl on Windows > > and wxScrolledWindow on everything else so I #if defined the .i and .h > > file accordingly. > > > > I also added a .i and .h file for the class wxTreeItemId. > > > > The TreeCtrl files were changed so much that I am just uploading the > > whole files instead of the diffs. > > > > traverse_tree(tree_ctrl,tree_ctrl.get_root_item) do |node_id,cookie| > > puts "Name: #{tree_ctrl.get_item_text(node_id)}\t\tCookie: > > #{cookie}" > > end > > > > def traverse_tree(tree_ctrl,root_node,cookie=0,&block) > > if cookie == 0 > > ret = tree_ctrl.get_first_child(root_node) > > else > > ret = tree_ctrl.get_next_child(root_node,cookie) > > end > > > > if ret[0].is_ok > > if block_given? > > yield(ret[0],ret[1]) > > end > > > > traverse_tree(tree_ctrl,ret[0],0,&block) > > end > > > > ret_sib = tree_ctrl.get_next_sibling(root_node) > > if ret_sib.is_ok > > if block_given? > > yield(ret_sib,cookie) > > end > > traverse_tree(tree_ctrl,ret_sib,0,&block) > > end > > > > end > > > > > > Sean > > > > > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users From roys at mindspring.com Sun Aug 20 23:03:17 2006 From: roys at mindspring.com (Roy Sutton) Date: Sun, 20 Aug 2006 23:03:17 -0400 Subject: [Wxruby-users] Should we require 'rubygems' in our samples? In-Reply-To: <1156127363.2953.35.camel@localhost.localdomain> References: <1156054261.9399.6.camel@localhost.localdomain> <44E8C85F.40806@pressure.to> <1156127363.2953.35.camel@localhost.localdomain> Message-ID: <44E92275.5010703@mindspring.com> Kevin Smith wrote: > On Sun, 2006-08-20 at 21:38 +0100, Alex Fenton wrote: > >> Kevin Smith wrote: >> >>> Shouldn't we also require 'rubygems' in all our samples, to make it as >>> easy as possible for folks to play around with wxruby? >>> >>> >> I would suggest probably not. My impression is that other ruby libs >> don't do this. It's a one-time issue for ruby generally, and hopefully >> the large majority of people will have either never had the problem >> (Windows) or have solved it for some previous use. >> > > I now agree with you. > Hmm, I think we should. If we're going to distribute as a gem then we should probably do a 'require'. On my Windows system I /don't/ have rubygems in my RUBYOPT environment variable. I used the installer so I'm guessing most people will likely fail on that. > Excellent. I'm sure I should know this already, but who volunteered to > do our MSWindows build this time? > > I can do it if no one else volunteers. I just built a gem and am trying it out now. Roy From roys at mindspring.com Sun Aug 20 23:11:29 2006 From: roys at mindspring.com (Roy Sutton) Date: Sun, 20 Aug 2006 23:11:29 -0400 Subject: [Wxruby-users] Monkeys in Space... In-Reply-To: <1156126147.2953.18.camel@localhost.localdomain> References: <1155496758.11659.122.camel@localhost.localdomain> <1155871140.30640.9.camel@localhost.localdomain> <44E5536C.8010403@pressure.to> <1156126147.2953.18.camel@localhost.localdomain> Message-ID: <44E92461.9050204@mindspring.com> In other news, I got farther running SpaceMonkey than I think I have gotten in a long, long while. I didn't manage to crash it for a good 35-45 seconds. Of course, since I have no clue what I'm doing, I think I could improve my times. :) Roy From roys at mindspring.com Sun Aug 20 23:28:03 2006 From: roys at mindspring.com (Roy Sutton) Date: Sun, 20 Aug 2006 23:28:03 -0400 Subject: [Wxruby-users] Patch to rakemswin.rb Message-ID: <44E92843.1000406@mindspring.com> This patch file removes a bad include path in the windows build. I'm not sure it ever served a purpose but it produced: "-I::TOPDIR". It was -supposed- to produce "-IC:\ruby" (for my system) but there's no point in adding that to the include path. Since wxRuby compiles fine without it, I took it out. I also took out the -I.. line since it, too, was unneeded. Roy -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rakemswin.rb.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060820/c2c9d2d0/attachment.pl From roys at mindspring.com Sun Aug 20 23:31:04 2006 From: roys at mindspring.com (Roy Sutton) Date: Sun, 20 Aug 2006 23:31:04 -0400 Subject: [Wxruby-users] TreeCtrl update In-Reply-To: <1156127874.2953.37.camel@localhost.localdomain> References: <1156127874.2953.37.camel@localhost.localdomain> Message-ID: <44E928F8.5060106@mindspring.com> On Sun, 2006-08-20 at 19:26 -0700, Sean Long wrote: >> Has anyone had a chance to look at these changes I made? I think it >> would be nice to get it in before an alpha release. >> >> Sean >> Unfortunately, these don't work with MSWindows. Many of the functions are only available for the generic version. I'll see what I can do to whip up a patch file. Roy From wxruby at qualitycode.com Mon Aug 21 00:12:15 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Mon, 21 Aug 2006 00:12:15 -0400 Subject: [Wxruby-users] Monkeys in Space... In-Reply-To: <44E92461.9050204@mindspring.com> References: <1155496758.11659.122.camel@localhost.localdomain> <1155871140.30640.9.camel@localhost.localdomain> <44E5536C.8010403@pressure.to> <1156126147.2953.18.camel@localhost.localdomain> <44E92461.9050204@mindspring.com> Message-ID: <1156133536.6413.12.camel@localhost.localdomain> On Sun, 2006-08-20 at 23:11 -0400, Roy Sutton wrote: > In other news, I got farther running SpaceMonkey than I think I have > gotten in a long, long while. I didn't manage to crash it for a good > 35-45 seconds. Of course, since I have no clue what I'm doing, I think > I could improve my times. :) Wow. That's great. I actually tried running it myself yesterday, but hit an error pretty quickly with Sizer#add. Have you modified the source code, and if so could you email me some patches or a tarball? I would love to have monkeys working soon after the alpha release, as yet another example of wxruby code. Thanks, Kevin From wxruby at qualitycode.com Mon Aug 21 00:15:25 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Mon, 21 Aug 2006 00:15:25 -0400 Subject: [Wxruby-users] TreeCtrl update In-Reply-To: <44E928F8.5060106@mindspring.com> References: <1156127874.2953.37.camel@localhost.localdomain> <44E928F8.5060106@mindspring.com> Message-ID: <1156133725.6413.15.camel@localhost.localdomain> On Sun, 2006-08-20 at 23:31 -0400, Roy Sutton wrote: > On Sun, 2006-08-20 at 19:26 -0700, Sean Long wrote: > >> Has anyone had a chance to look at these changes I made? I think it > >> would be nice to get it in before an alpha release. > >> > >> Sean > >> > Unfortunately, these don't work with MSWindows. Many of the functions > are only available for the generic version. I'll see what I can do to > whip up a patch file. Doh! I sure wish there was an easy and automatic way to filter those out. Maybe I can set up a cross-compiler on my system so I can at least attempt an MS Windows build which would detect that. Hm. Has anyone else tried that? We can revert the change if necessary. Hopefully it won't be. Thanks, Kevin From wxruby at qualitycode.com Mon Aug 21 00:24:01 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Mon, 21 Aug 2006 00:24:01 -0400 Subject: [Wxruby-users] Should we require 'rubygems' in our samples? In-Reply-To: <44E92275.5010703@mindspring.com> References: <1156054261.9399.6.camel@localhost.localdomain> <44E8C85F.40806@pressure.to> <1156127363.2953.35.camel@localhost.localdomain> <44E92275.5010703@mindspring.com> Message-ID: <1156134242.6413.23.camel@localhost.localdomain> On Sun, 2006-08-20 at 23:03 -0400, Roy Sutton wrote: > Hmm, I think we should. If we're going to distribute as a gem then we > should probably do a 'require'. On my Windows system I /don't/ have > rubygems in my RUBYOPT environment variable. I used the installer so > I'm guessing most people will likely fail on that. That is troubling. I would like to know how other projects handle this...FXRuby, for example. > > Excellent. I'm sure I should know this already, but who volunteered to > > do our MSWindows build this time? > > > I can do it if no one else volunteers. I just built a gem and am trying > it out now. Ok, thanks! Kevin From sean.m.long at gmail.com Mon Aug 21 01:32:53 2006 From: sean.m.long at gmail.com (Sean Long) Date: Sun, 20 Aug 2006 22:32:53 -0700 Subject: [Wxruby-users] TreeCtrl update In-Reply-To: <1156133725.6413.15.camel@localhost.localdomain> References: <1156127874.2953.37.camel@localhost.localdomain> <44E928F8.5060106@mindspring.com> <1156133725.6413.15.camel@localhost.localdomain> Message-ID: Here is a patch to make it work on windows. Sean On 8/20/06, Kevin Smith wrote: > On Sun, 2006-08-20 at 23:31 -0400, Roy Sutton wrote: > > On Sun, 2006-08-20 at 19:26 -0700, Sean Long wrote: > > >> Has anyone had a chance to look at these changes I made? I think it > > >> would be nice to get it in before an alpha release. > > >> > > >> Sean > > >> > > Unfortunately, these don't work with MSWindows. Many of the functions > > are only available for the generic version. I'll see what I can do to > > whip up a patch file. > > Doh! I sure wish there was an easy and automatic way to filter those > out. Maybe I can set up a cross-compiler on my system so I can at least > attempt an MS Windows build which would detect that. Hm. Has anyone else > tried that? > > We can revert the change if necessary. Hopefully it won't be. > > Thanks, > > Kevin > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: wxTreeCtrl_h.patch Type: application/octet-stream Size: 4689 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-users/attachments/20060820/7d9e338b/attachment.obj From sean.m.long at gmail.com Mon Aug 21 02:04:32 2006 From: sean.m.long at gmail.com (Sean Long) Date: Sun, 20 Aug 2006 23:04:32 -0700 Subject: [Wxruby-users] Patch to Calendar sample Message-ID: This patch cleans up the calendar sample to follow the Ruby coding style. It also uses ID_ABOUT and ID_EXIT for the About and Quit menu item ID's these allow wxWidgets to put the About and Quit menu in the correct location on Mac OS X. We should probably do this with all the samples. Sean -------------- next part -------------- A non-text attachment was scrubbed... Name: calendar_sample.patch Type: application/octet-stream Size: 11468 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-users/attachments/20060820/e895f385/attachment-0001.obj From sean.m.long at gmail.com Mon Aug 21 02:07:03 2006 From: sean.m.long at gmail.com (Sean Long) Date: Sun, 20 Aug 2006 23:07:03 -0700 Subject: [Wxruby-users] Patch to Calendar sample In-Reply-To: References: Message-ID: > It also uses ID_ABOUT and ID_EXIT for the About and Quit menu > item ID's these ... We should also use ID_PREFERENCES for preference/settings menu item when they are needed. Sean From sean.m.long at gmail.com Mon Aug 21 02:42:43 2006 From: sean.m.long at gmail.com (Sean Long) Date: Sun, 20 Aug 2006 23:42:43 -0700 Subject: [Wxruby-users] Patch for caret sample Message-ID: Cleaned up so it follows Ruby coding style and uses ID_EXIT, ID_ABOUT. Sean -------------- next part -------------- A non-text attachment was scrubbed... Name: caret_sample.patch Type: application/octet-stream Size: 11310 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-users/attachments/20060820/021b909a/attachment.obj From sean.m.long at gmail.com Mon Aug 21 02:50:42 2006 From: sean.m.long at gmail.com (Sean Long) Date: Sun, 20 Aug 2006 23:50:42 -0700 Subject: [Wxruby-users] Patch for listbook sample Message-ID: I made it use ID_EXIT so it follows my previous suggestion to use this predefined constant. Sean -------------- next part -------------- A non-text attachment was scrubbed... Name: listbook_sample.patch Type: application/octet-stream Size: 651 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-users/attachments/20060820/ba1081d9/attachment.obj From alex at pressure.to Mon Aug 21 15:07:41 2006 From: alex at pressure.to (Alex Fenton) Date: Mon, 21 Aug 2006 20:07:41 +0100 Subject: [Wxruby-users] gem version numbering In-Reply-To: <1156126936.2953.28.camel@localhost.localdomain> References: <1156126936.2953.28.camel@localhost.localdomain> Message-ID: <44EA047D.9080303@pressure.to> Kevin Smith wrote: > Hi all, > > However, there is nothing in the version number that indicates this is a > "preview" "alpha" "buggy" release. > Well, the "9" in the middle is meant to indicate that it's a development release, not a stable release. And the release notes and FAQ shout this. > The gem version numbering scheme does not allow things like 2.0-pre. > I totally agree that the limitations imposed by rubygems (and also rubyforge?) are unhelpful and that an -alpha or -pre suffix would be much better. > I now believe that we should call this wxruby 0.9.0. It is newer than > wxruby 0.6.0 My concern about using 0.9.0 is that it suggests it's an upgrade path from 0.6.0, which it isn't yet. It's not (yet) a superset of the functionality in that release - it's something different. It's not as stable yet. It handles strings differently etc. For people that list wxruby as a dependency to other projects (inc me), I think it's clearer to end users that they should use the same major version. Personally, if I read docs specifying a dependency, I usually assume that a newer release in the same major version series is as good or better. > It is not yet "1.0" quality. Nope - but nor are ruby-1.9 and perl 5.9 cheers alex From alex at pressure.to Mon Aug 21 15:12:21 2006 From: alex at pressure.to (Alex Fenton) Date: Mon, 21 Aug 2006 20:12:21 +0100 Subject: [Wxruby-users] Patch for caret sample In-Reply-To: References: Message-ID: <44EA0595.1050004@pressure.to> Committed, thanks. Also fixed a small bug with method name in set_blink_speed. The arrow keys still don't work for me - the key codes when I press arrow keys don't match up with the values in Wx::K_LEFT etc. I think this may be because I am using a unicode build, and we need to support Wx::KeyEvent#get_unicode_key. Are you testing on a unicode or ANSI build please? Thanks alex Sean Long wrote: > Cleaned up so it follows Ruby coding style and uses ID_EXIT, ID_ABOUT. > > Sean > ------------------------------------------------------------------------ > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users From alex at pressure.to Mon Aug 21 15:16:14 2006 From: alex at pressure.to (Alex Fenton) Date: Mon, 21 Aug 2006 20:16:14 +0100 Subject: [Wxruby-users] Patch for listbook sample In-Reply-To: References: Message-ID: <44EA067E.7090302@pressure.to> Committed, thanks. Also added a note on current Linux problems alex Sean Long wrote: > I made it use ID_EXIT so it follows my previous suggestion to use this > predefined constant. > > Sean > ------------------------------------------------------------------------ > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users From alex at pressure.to Mon Aug 21 15:20:22 2006 From: alex at pressure.to (Alex Fenton) Date: Mon, 21 Aug 2006 20:20:22 +0100 Subject: [Wxruby-users] Patch to Calendar sample In-Reply-To: References: Message-ID: <44EA0776.6030502@pressure.to> committed, thanks Sean Long wrote: > This patch cleans up the calendar sample to follow the Ruby coding > style. It also uses ID_ABOUT and ID_EXIT for the About and Quit menu > item ID's these allow wxWidgets to put the About and Quit menu in the > correct location on Mac OS X. We should probably do this with all the > samples. > > Sean > ------------------------------------------------------------------------ > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users From alex at pressure.to Mon Aug 21 15:25:33 2006 From: alex at pressure.to (Alex Fenton) Date: Mon, 21 Aug 2006 20:25:33 +0100 Subject: [Wxruby-users] wxruby2 alpha status In-Reply-To: <1156126147.2953.18.camel@localhost.localdomain> References: <1155496758.11659.122.camel@localhost.localdomain> <1155871140.30640.9.camel@localhost.localdomain> <44E5536C.8010403@pressure.to> <1156126147.2953.18.camel@localhost.localdomain> Message-ID: <44EA08AD.3070609@pressure.to> > Very true. I just overhauled the README file, and included a lengthy FAQ > section that addresses this issue. I have pasted that section below, and > would appreciate any feedback, or suggestions for additional questions > to include. Kevin - I think this FAQ is superb; haven't got anything to add at the moment. Will copy up to the Wiki when we release. alex From sean.m.long at gmail.com Mon Aug 21 15:31:44 2006 From: sean.m.long at gmail.com (Sean Long) Date: Mon, 21 Aug 2006 12:31:44 -0700 Subject: [Wxruby-users] Patch for caret sample In-Reply-To: <44EA0595.1050004@pressure.to> References: <44EA0595.1050004@pressure.to> Message-ID: > I think this may be because I am using a unicode build, and we need to > support Wx::KeyEvent#get_unicode_key. Are you testing on a unicode or > ANSI build please? I am using an ANSI build and the keys work fine on it. I did notice that if I hit the page down key it will crash the app, I think it was somtehing about the key number being out of character range. Sean From wxruby at qualitycode.com Tue Aug 22 00:10:20 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Tue, 22 Aug 2006 00:10:20 -0400 Subject: [Wxruby-users] Patch for caret sample In-Reply-To: References: <44EA0595.1050004@pressure.to> Message-ID: <1156219820.25876.45.camel@localhost.localdomain> On Mon, 2006-08-21 at 12:31 -0700, Sean Long wrote: > > I think this may be because I am using a unicode build, and we need to > > support Wx::KeyEvent#get_unicode_key. Are you testing on a unicode or > > ANSI build please? > > I am using an ANSI build and the keys work fine on it. I did notice > that if I hit the page down key it will crash the app, I think it was > somtehing about the key number being out of character range. I'm not sure if you guys are talking specifically about OS X or not. On my Linux unicode build, the arrow keys work, and PgUp does not crash. Kevin From roys at mindspring.com Tue Aug 22 00:31:36 2006 From: roys at mindspring.com (Roy Sutton) Date: Tue, 22 Aug 2006 00:31:36 -0400 Subject: [Wxruby-users] Intriguing developments Message-ID: <44EA88A8.70009@mindspring.com> Non-debug build of wxRuby allows the tip of the day to be visible on Windows. Also, I get the caret example crashes with page-up on Windows with the ANSI build of wxWindows. I may try the unicode build to see how that works. I've been up to my eyeballs working on a release of my company's software. Once that's out the door I can hopefully put a few more cycles into the release. Roy From roys at mindspring.com Tue Aug 22 01:15:00 2006 From: roys at mindspring.com (Roy Sutton) Date: Tue, 22 Aug 2006 01:15:00 -0400 Subject: [Wxruby-users] Patch for caret.rb Message-ID: <44EA92D4.3040801@mindspring.com> I removed all the ()'s and patched things so it won't crash on bad keystrokes. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: caret.rb.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060822/ac6d6cc3/attachment.ksh From sean.m.long at gmail.com Tue Aug 22 02:13:55 2006 From: sean.m.long at gmail.com (Sean Long) Date: Mon, 21 Aug 2006 23:13:55 -0700 Subject: [Wxruby-users] Patch for caret sample In-Reply-To: <1156219820.25876.45.camel@localhost.localdomain> References: <44EA0595.1050004@pressure.to> <1156219820.25876.45.camel@localhost.localdomain> Message-ID: I am talking about OS X specifically. Sean On 8/21/06, Kevin Smith wrote: > On Mon, 2006-08-21 at 12:31 -0700, Sean Long wrote: > > > I think this may be because I am using a unicode build, and we need to > > > support Wx::KeyEvent#get_unicode_key. Are you testing on a unicode or > > > ANSI build please? > > > > I am using an ANSI build and the keys work fine on it. I did notice > > that if I hit the page down key it will crash the app, I think it was > > somtehing about the key number being out of character range. > > I'm not sure if you guys are talking specifically about OS X or not. On > my Linux unicode build, the arrow keys work, and PgUp does not crash. > > Kevin > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > From sean.m.long at gmail.com Tue Aug 22 02:23:17 2006 From: sean.m.long at gmail.com (Sean Long) Date: Mon, 21 Aug 2006 23:23:17 -0700 Subject: [Wxruby-users] TreeCtrl update In-Reply-To: References: <1156127874.2953.37.camel@localhost.localdomain> <44E928F8.5060106@mindspring.com> <1156133725.6413.15.camel@localhost.localdomain> Message-ID: Roy can you confirm that the patch I posted yesterday works and hopefully Kevin or Alex can commit it. I am going to have less and less time to devote to wxRuby and want to make sure I have the loose ends I am involved with tied up. Thanks Sean On 8/20/06, Sean Long wrote: > Here is a patch to make it work on windows. > > Sean From wxruby at roadq.com Tue Aug 22 12:43:54 2006 From: wxruby at roadq.com (Mark Ping) Date: Tue, 22 Aug 2006 09:43:54 -0700 Subject: [Wxruby-users] TreeCtrl update In-Reply-To: References: <1156127874.2953.37.camel@localhost.localdomain> <44E928F8.5060106@mindspring.com> <1156133725.6413.15.camel@localhost.localdomain> Message-ID: <44EB344A.9020806@roadq.com> Sean Long wrote: > Roy can you confirm that the patch I posted yesterday works and > hopefully Kevin or Alex can commit it. I am going to have less and > less time to devote to wxRuby and want to make sure I have the loose > ends I am involved with tied up. I'm not Roy, but I can confirm that it compiles. The BigDemo wxTreeCtrl fails though. The error message is: A problem occurred with the wxTreeCtrl demo: undefined method `get_icon' for Wxruby2::ArtProvider:Class ./wxTreeCtrl.rbw:57:in `initialize' ./wxTreeCtrl.rbw:160:in `run' C:/dev/wxruby2/samples/bigdemo/Main.rbw:396:in `run_demo' C:/dev/wxruby2/samples/bigdemo/Main.rbw:356:in `on_tree_sel_changed' C:/dev/wxruby2/samples/bigdemo/Main.rbw:287:in `initialize' C:/dev/wxruby2/samples/bigdemo/Main.rbw:551 --Mark Ping From sean.m.long at gmail.com Tue Aug 22 13:59:37 2006 From: sean.m.long at gmail.com (Sean Long) Date: Tue, 22 Aug 2006 10:59:37 -0700 Subject: [Wxruby-users] TreeCtrl update In-Reply-To: <44EB344A.9020806@roadq.com> References: <1156127874.2953.37.camel@localhost.localdomain> <44E928F8.5060106@mindspring.com> <1156133725.6413.15.camel@localhost.localdomain> <44EB344A.9020806@roadq.com> Message-ID: Mark, Thanks for the info, I mostly just wanted to know if it compiled on Windows (it did for me). I don't know if I will have time to fix that crashing error but thank you for posting it, it should help someone down the line. Sean On 8/22/06, Mark Ping wrote: > Sean Long wrote: > > Roy can you confirm that the patch I posted yesterday works and > > hopefully Kevin or Alex can commit it. I am going to have less and > > less time to devote to wxRuby and want to make sure I have the loose > > ends I am involved with tied up. > I'm not Roy, but I can confirm that it compiles. The BigDemo wxTreeCtrl > fails though. The error message is: > > > A problem occurred with the wxTreeCtrl demo: > undefined method `get_icon' for Wxruby2::ArtProvider:Class > ./wxTreeCtrl.rbw:57:in `initialize' > ./wxTreeCtrl.rbw:160:in `run' > C:/dev/wxruby2/samples/bigdemo/Main.rbw:396:in `run_demo' > C:/dev/wxruby2/samples/bigdemo/Main.rbw:356:in `on_tree_sel_changed' > C:/dev/wxruby2/samples/bigdemo/Main.rbw:287:in `initialize' > C:/dev/wxruby2/samples/bigdemo/Main.rbw:551 > > --Mark Ping > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > From alex at pressure.to Tue Aug 22 15:27:21 2006 From: alex at pressure.to (Alex Fenton) Date: Tue, 22 Aug 2006 20:27:21 +0100 Subject: [Wxruby-users] TreeCtrl update In-Reply-To: <44EB344A.9020806@roadq.com> References: <1156127874.2953.37.camel@localhost.localdomain> <44E928F8.5060106@mindspring.com> <1156133725.6413.15.camel@localhost.localdomain> <44EB344A.9020806@roadq.com> Message-ID: <44EB5A99.1050705@pressure.to> Thank you Mark, Sean It looks to me very much as if the problem with ArtProvider is unrelated to the TreeCtrl changes. I am not sure if get_icon is meant to be a class or instance method, but either way the method is currently %ignored in ArtProvider.i, with a note that the method is not compatible with SWIG 1.3.29. I guess the correct way to fix this for the time being is to comment out the offending lines in wxTreeCtrl.rb in the bigdemo. Sean - I will go ahead and commit your recent Windows-fix patch once I have tried it out here. cheers alex Mark Ping wrote: > Sean Long wrote: > >> Roy can you confirm that the patch I posted yesterday works and >> hopefully Kevin or Alex can commit it. I am going to have less and >> less time to devote to wxRuby and want to make sure I have the loose >> ends I am involved with tied up. >> > I'm not Roy, but I can confirm that it compiles. The BigDemo wxTreeCtrl > fails though. The error message is: > > > A problem occurred with the wxTreeCtrl demo: > undefined method `get_icon' for Wxruby2::ArtProvider:Class > ./wxTreeCtrl.rbw:57:in `initialize' > ./wxTreeCtrl.rbw:160:in `run' > C:/dev/wxruby2/samples/bigdemo/Main.rbw:396:in `run_demo' > C:/dev/wxruby2/samples/bigdemo/Main.rbw:356:in `on_tree_sel_changed' > C:/dev/wxruby2/samples/bigdemo/Main.rbw:287:in `initialize' > C:/dev/wxruby2/samples/bigdemo/Main.rbw:551 > > --Mark Ping > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > From alex at pressure.to Tue Aug 22 15:39:52 2006 From: alex at pressure.to (Alex Fenton) Date: Tue, 22 Aug 2006 20:39:52 +0100 Subject: [Wxruby-users] doc generator now in CVS Message-ID: <44EB5D88.4080207@pressure.to> Hi Just a quick note to let you know that the Textile doc generation stuff is now in CVS. There is a moderate amount of documentation in rake/rakedoc.rb in case you feel like generating your own local copy. The only prerequisite is the Ruby 'redcloth' library. There's also some info in doc/lib which might be some help if you want to tweak the output. cheers alex From wxruby at qualitycode.com Tue Aug 22 16:22:30 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Tue, 22 Aug 2006 16:22:30 -0400 Subject: [Wxruby-users] gem version numbering In-Reply-To: <44EA047D.9080303@pressure.to> References: <1156126936.2953.28.camel@localhost.localdomain> <44EA047D.9080303@pressure.to> Message-ID: <1156278150.5712.36.camel@localhost.localdomain> On Mon, 2006-08-21 at 20:07 +0100, Alex Fenton wrote: > Kevin Smith wrote: > > I now believe that we should call this wxruby 0.9.0. It is newer than > > wxruby 0.6.0 > My concern about using 0.9.0 is that it suggests it's an upgrade path > from 0.6.0, which it isn't yet. It's not (yet) a superset of the > functionality in that release - it's something different. It's not as > stable yet. It handles strings differently etc. I would love to hear other opinions. Here are the options I have seen suggested or can think of: wxruby 0.0.33 Pros: Makes it clear that it's early alpha Cons: Looks older/worse than wxruby 0.6.0 wxruby 0.9.0 Pros: Clearly immature Cons: Looks newer/better than wxruby 0.6.0 wxruby 1.9.0 Pros: Implies that it is "before 2.0" Cons: Looks very mature and newer/better than wxruby 0.6.0 wxruby2 0.0.33 Pros: Very accurate Cons: People might get confused by wxruby2 vs. wxruby, especially later when we either have wxruby2 1.0 or switch to wxruby 2.0 One debatable point is whether to use the even/odd stable/unstable numbering system. Personally, I strongly dislike it, and it is certainly not used industry-wide. However, it is used by both Ruby and wx. I would be more comfortable with it after we have our first stable release out. Another point of concern for me is just how unstable this release will be. For the larger samples, I am lucky to go 30 seconds before getting a segfault and crashing out. My SpaceMonkeys game always crashes within about 3 seconds. Perhaps it's worse on Linux than other platforms, but calling that "1.9" seems very misleading to me. Thoughts? Opinions? Other suggestions? Kevin From alex at pressure.to Tue Aug 22 16:56:31 2006 From: alex at pressure.to (Alex Fenton) Date: Tue, 22 Aug 2006 21:56:31 +0100 Subject: [Wxruby-users] TreeCtrl update In-Reply-To: References: <1156127874.2953.37.camel@localhost.localdomain> <44E928F8.5060106@mindspring.com> <1156133725.6413.15.camel@localhost.localdomain> Message-ID: <44EB6F7F.9090100@pressure.to> Sean Long wrote: > Here is a patch to make it work on windows. Committed, thank you. Also, have commented out currently unsupported ArtProvider calls in the bigdemo/wxTreeCtrl.rb, and related calls to set images. This at least allows it to display, though currently crashes when editing tree item labels b/c TreeEvent#get_label is not supported. alex From alex at pressure.to Tue Aug 22 18:01:05 2006 From: alex at pressure.to (Alex Fenton) Date: Tue, 22 Aug 2006 23:01:05 +0100 Subject: [Wxruby-users] TreeEvent patch Message-ID: <44EB7EA1.50909@pressure.to> Hi Patches to TreeEvent.i and wxTreeEvent.h to implement missing methods (and fix a crasher in bigdemo along the way) Two of the missing methods appeared just to be down to errors in the header file. The other (get_label) works fine - perh a bug in previous versions of SWIG? Methods tested and return correct values on OS X. I could offer a test addition to bigedemo, but this doesn't feel to me like the right place to add class-specific trial code. I will look to add a treectrl sample, perh just port the old 0.6.0 one. bigdemo is much the most problematic sample - maybe we are trying to run before we can walk? cheers alex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: TreeEvent.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060822/80a41395/attachment.pl From wxruby at roadq.com Tue Aug 22 18:20:47 2006 From: wxruby at roadq.com (Mark Ping) Date: Tue, 22 Aug 2006 15:20:47 -0700 Subject: [Wxruby-users] TreeEvent patch In-Reply-To: <44EB7EA1.50909@pressure.to> References: <44EB7EA1.50909@pressure.to> Message-ID: <44EB833F.7070801@roadq.com> Alex Fenton wrote: > Hi > > Patches to TreeEvent.i and wxTreeEvent.h to implement missing methods > (and fix a crasher in bigdemo along the way) This looks great on Windows to me. The bigdemo crash is in fact gone. The only reason I used that to test the TreeCtrl is because it was the only sample I found with a wxTreeCtrl in it. -Mark Ping From sean.m.long at gmail.com Wed Aug 23 01:32:23 2006 From: sean.m.long at gmail.com (Sean Long) Date: Tue, 22 Aug 2006 22:32:23 -0700 Subject: [Wxruby-users] gem version numbering In-Reply-To: <1156278150.5712.36.camel@localhost.localdomain> References: <1156126936.2953.28.camel@localhost.localdomain> <44EA047D.9080303@pressure.to> <1156278150.5712.36.camel@localhost.localdomain> Message-ID: > wxruby 0.9.0 > Pros: Clearly immature > Cons: Looks newer/better than wxruby 0.6.0 I like this one because for me the current wxRuby is much better than 0.6.0 every was, maybe it is because I mostly use OS X. I think we should work toward 1.0.0 during alpha/beta stage and then start calling it: wxRuby 2.6.3.0, wxRuby 2.6.3.1 etc. This is what wxPython does. The first three numbers represent the wxWidgets release number and the fourth is the wxPython release number targeting that wxWidgets release. pros: Easy to see what version of wxWidgets is being used, seems to work fine for wxPython. cons: Messy up until the first initial release. Sean From roys at mindspring.com Wed Aug 23 09:38:02 2006 From: roys at mindspring.com (Roy Sutton) Date: Wed, 23 Aug 2006 09:38:02 -0400 Subject: [Wxruby-users] Monkeys in Space... In-Reply-To: <1156133536.6413.12.camel@localhost.localdomain> References: <1155496758.11659.122.camel@localhost.localdomain> <1155871140.30640.9.camel@localhost.localdomain> <44E5536C.8010403@pressure.to> <1156126147.2953.18.camel@localhost.localdomain> <44E92461.9050204@mindspring.com> <1156133536.6413.12.camel@localhost.localdomain> Message-ID: <44EC5A3A.1070008@mindspring.com> I didn't modify the source. Once I figured out a little better what I was supposed to be doing I could make it crash a little faster. It wouldn't be bad to start testing with it to locate bugs once we fix all the demos. Roy Kevin Smith wrote: > On Sun, 2006-08-20 at 23:11 -0400, Roy Sutton wrote: > >> In other news, I got farther running SpaceMonkey than I think I have >> gotten in a long, long while. I didn't manage to crash it for a good >> 35-45 seconds. Of course, since I have no clue what I'm doing, I think >> I could improve my times. :) >> > > Wow. That's great. I actually tried running it myself yesterday, but hit > an error pretty quickly with Sizer#add. Have you modified the source > code, and if so could you email me some patches or a tarball? > > I would love to have monkeys working soon after the alpha release, as > yet another example of wxruby code. > > Thanks, > > Kevin > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > From wxruby at qualitycode.com Wed Aug 23 10:14:59 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Wed, 23 Aug 2006 10:14:59 -0400 Subject: [Wxruby-users] gem version numbering In-Reply-To: References: <1156126936.2953.28.camel@localhost.localdomain> <44EA047D.9080303@pressure.to> <1156278150.5712.36.camel@localhost.localdomain> Message-ID: <1156342499.5809.1.camel@localhost.localdomain> On Tue, 2006-08-22 at 22:32 -0700, Sean Long wrote: > > wxruby 0.9.0 > > Pros: Clearly immature > > Cons: Looks newer/better than wxruby 0.6.0 > > I like this one because for me the current wxRuby is much better than > 0.6.0 every was, maybe it is because I mostly use OS X. Thanks for your input. > I think we should work toward 1.0.0 during alpha/beta stage and then > start calling it: > wxRuby 2.6.3.0, wxRuby 2.6.3.1 etc. This is what wxPython does. The > first three numbers represent the wxWidgets release number and the > fourth is the wxPython release number targeting that wxWidgets > release. > > pros: Easy to see what version of wxWidgets is being used, seems to > work fine for wxPython. > cons: Messy up until the first initial release. Another con is that gem ONLY allows x.y.z version numbers. So we would not be able to use that scheme within gem. At least, that's my understanding. Kevin From wxruby at qualitycode.com Wed Aug 23 10:18:54 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Wed, 23 Aug 2006 10:18:54 -0400 Subject: [Wxruby-users] Monkeys in Space... In-Reply-To: <44EC5A3A.1070008@mindspring.com> References: <1155496758.11659.122.camel@localhost.localdomain> <1155871140.30640.9.camel@localhost.localdomain> <44E5536C.8010403@pressure.to> <1156126147.2953.18.camel@localhost.localdomain> <44E92461.9050204@mindspring.com> <1156133536.6413.12.camel@localhost.localdomain> <44EC5A3A.1070008@mindspring.com> Message-ID: <1156342734.5809.5.camel@localhost.localdomain> I had to remove parameters from 3 or 4 calls to Sizer#add. Very curious that you did not. So now the main screen comes up. As soon as I move the mouse in the playing area, it crashes immediately. Typically your first moves in the game would be to start building a ship, but as soon as I click on a build button once or twice, it crashes. I agree it would make kind of a cool testing platform. Especially if other folks started adding more of the game features that are described in the rules but not yet implemented. Thanks, Kevin On Wed, 2006-08-23 at 09:38 -0400, Roy Sutton wrote: > I didn't modify the source. Once I figured out a little better what I > was supposed to be doing I could make it crash a little faster. It > wouldn't be bad to start testing with it to locate bugs once we fix all > the demos. > > Roy > > Kevin Smith wrote: > > On Sun, 2006-08-20 at 23:11 -0400, Roy Sutton wrote: > > > >> In other news, I got farther running SpaceMonkey than I think I have > >> gotten in a long, long while. I didn't manage to crash it for a good > >> 35-45 seconds. Of course, since I have no clue what I'm doing, I think > >> I could improve my times. :) > >> > > > > Wow. That's great. I actually tried running it myself yesterday, but hit > > an error pretty quickly with Sizer#add. Have you modified the source > > code, and if so could you email me some patches or a tarball? > > > > I would love to have monkeys working soon after the alpha release, as > > yet another example of wxruby code. > > > > Thanks, > > > > Kevin > > > > > > _______________________________________________ > > wxruby-users mailing list > > wxruby-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > > > > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users From roys at mindspring.com Wed Aug 23 14:01:04 2006 From: roys at mindspring.com (Roy Sutton) Date: Wed, 23 Aug 2006 14:01:04 -0400 Subject: [Wxruby-users] Monkeys in Space... In-Reply-To: <1156342734.5809.5.camel@localhost.localdomain> References: <1155496758.11659.122.camel@localhost.localdomain> <1155871140.30640.9.camel@localhost.localdomain> <44E5536C.8010403@pressure.to> <1156126147.2953.18.camel@localhost.localdomain> <44E92461.9050204@mindspring.com> <1156133536.6413.12.camel@localhost.localdomain> <44EC5A3A.1070008@mindspring.com> <1156342734.5809.5.camel@localhost.localdomain> Message-ID: <44EC97E0.6030605@mindspring.com> On Windows, I can build several turns but as soon as a ship would be ready it crashes. Other functions crash it, such as resizing the window past a certain point. I think some problems will be fixed when we get SWIG behaving properly. Sadly, the SWIG people have not responded at all to my call for help. I'll go stick it in their bug tracker later and maybe write a followup e-mail. I suspect some people may be on vacation so I don't want to rock things too much. Roy Kevin Smith wrote: > I had to remove parameters from 3 or 4 calls to Sizer#add. Very curious > that you did not. > > So now the main screen comes up. As soon as I move the mouse in the > playing area, it crashes immediately. Typically your first moves in the > game would be to start building a ship, but as soon as I click on a > build button once or twice, it crashes. > > I agree it would make kind of a cool testing platform. Especially if > other folks started adding more of the game features that are described > in the rules but not yet implemented. > > Thanks, > > Kevin > > > On Wed, 2006-08-23 at 09:38 -0400, Roy Sutton wrote: > >> I didn't modify the source. Once I figured out a little better what I >> was supposed to be doing I could make it crash a little faster. It >> wouldn't be bad to start testing with it to locate bugs once we fix all >> the demos. >> >> Roy >> >> Kevin Smith wrote: >> >>> On Sun, 2006-08-20 at 23:11 -0400, Roy Sutton wrote: >>> >>> >>>> In other news, I got farther running SpaceMonkey than I think I have >>>> gotten in a long, long while. I didn't manage to crash it for a good >>>> 35-45 seconds. Of course, since I have no clue what I'm doing, I think >>>> I could improve my times. :) >>>> >>>> >>> Wow. That's great. I actually tried running it myself yesterday, but hit >>> an error pretty quickly with Sizer#add. Have you modified the source >>> code, and if so could you email me some patches or a tarball? >>> >>> I would love to have monkeys working soon after the alpha release, as >>> yet another example of wxruby code. >>> >>> Thanks, >>> >>> Kevin >>> >>> >>> _______________________________________________ >>> wxruby-users mailing list >>> wxruby-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wxruby-users >>> >>> >>> >>> >>> >> _______________________________________________ >> wxruby-users mailing list >> wxruby-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wxruby-users >> > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > From kees.jongenburger at gmail.com Wed Aug 23 16:01:44 2006 From: kees.jongenburger at gmail.com (Kees Jongenburger) Date: Wed, 23 Aug 2006 22:01:44 +0200 Subject: [Wxruby-users] building wxruby2 from cvs (gentoo) Message-ID: Hello, I am a newbie to wx and wxruby, I just built wxruby2 on my gentoo box. At first it did not work. So I post a little message,it might help others. At first a cryptic message was shown SWIG Version 1.3.21 Copyright (c) 1995-1998 University of Utah and the Regents of the University of California Copyright (c) 1998-2003 University of Chicago Compiled with i686-pc-linux-gnu-g++ [i686-pc-linux-gnu] Please see http://www.swig.org for reporting bugs and further information Doing slower check for SWIG 1.3.29 rake aborted! Don't know how to build task 'src/App.cpp' (See full trace by running task with --trace) - It turns out the by default swig on gentoo is not compiled with ruby support and the default version is older then the recommended one so I installed a new swig version with ruby support #edited /etc/portage/package.keyword #and added dev-lang/swig #edit /etc/portage/package.use #added dev-lang/swig ruby The second point where it failed was here src/App.cpp:1622:21: wx/init.h: No such file or directory src/App.cpp: In member function `bool wxRubyApp::Initialize(int&, wxChar**)': src/App.cpp:1742: error: no matching function for call to `wxRubyApp::Initialize (int&, wxChar**&)' /usr/include/wx/gtk/app.h:57: note: candidates are: static bool wxApp::Initializ e() rake aborted! Command failed with status (1): [c++ -c -I/usr/lib/wx/include/gtk2-2.4 -DG...] (See full trace by running task with --trace) my gentoo has two versions of wx installed (2.4.2 and 2.6.2) (2.4 is the default), so the wx-config points to the 2.4 configuration while the wx-config-2.6 to the new version. I changed wx-config for wx-config-2.6 in rake/rakewx.rb at line 41 perhaps the developers can add a check to see if wx-config-2.6 is in the path? anyway now it all works and I can start playing around Thanks Kees Jongenburger From wxruby at qualitycode.com Wed Aug 23 16:08:31 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Wed, 23 Aug 2006 16:08:31 -0400 Subject: [Wxruby-users] Patch for caret.rb In-Reply-To: <44EA92D4.3040801@mindspring.com> References: <44EA92D4.3040801@mindspring.com> Message-ID: <1156363711.1950.4.camel@localhost.localdomain> On Tue, 2006-08-22 at 01:15 -0400, Roy Sutton wrote: > I removed all the ()'s and patched things so it won't crash on bad > keystrokes. Applied, thanks. I would preferred two separate patches in cases like this...one to fix the crash, and another to adjust the coding style. It makes review easier, and gives me the chance to accept one but reject the other, if necessary. Kevin From wxruby at qualitycode.com Wed Aug 23 16:19:06 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Wed, 23 Aug 2006 16:19:06 -0400 Subject: [Wxruby-users] doc generator now in CVS In-Reply-To: <44EB5D88.4080207@pressure.to> References: <44EB5D88.4080207@pressure.to> Message-ID: <1156364346.1950.7.camel@localhost.localdomain> On Tue, 2006-08-22 at 20:39 +0100, Alex Fenton wrote: > Just a quick note to let you know that the Textile doc generation stuff > is now in CVS. There is a moderate amount of documentation in > rake/rakedoc.rb in case you feel like generating your own local copy. > The only prerequisite is the Ruby 'redcloth' library. I'm getting an error when I run rake: kevins at aria:~/work/wxruby2$ rake --trace (in /home/kevins/work/wxruby2) rake aborted! no such file to load -- wxlatex_parser /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' ./rake/rakedocs.rb:21 /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' /home/kevins/work/wxruby2/rakefile:7 /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1828:in `load_rakefile' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1900:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/bin/rake:7 /usr/bin/rake:18 kevins at aria:~/work/wxruby2$ Did you forget to check in wxlatex_parser? Or is it just not being found? I have commented out the require 'rakedocs' for now, so I can keep working. Kevin From wxruby at qualitycode.com Wed Aug 23 16:58:13 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Wed, 23 Aug 2006 16:58:13 -0400 Subject: [Wxruby-users] TreeEvent patch In-Reply-To: <44EB7EA1.50909@pressure.to> References: <44EB7EA1.50909@pressure.to> Message-ID: <1156366693.1950.10.camel@localhost.localdomain> On Tue, 2006-08-22 at 23:01 +0100, Alex Fenton wrote: > Patches to TreeEvent.i and wxTreeEvent.h to implement missing methods > (and fix a crasher in bigdemo along the way) Applied, thanks. > Methods tested and return correct values on OS X. I could offer a test > addition to bigedemo, but this doesn't feel to me like the right place > to add class-specific trial code. I will look to add a treectrl sample, > perh just port the old 0.6.0 one. bigdemo is much the most problematic > sample - maybe we are trying to run before we can walk? I think bigdemo provides a nice snapshot of how we are doing. More of it works than not, at least for me. An additional treectrl sample would be nice to have also. Kevin From wxruby at qualitycode.com Wed Aug 23 17:22:36 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Wed, 23 Aug 2006 17:22:36 -0400 Subject: [Wxruby-users] Monkeys in Space... In-Reply-To: <44EC97E0.6030605@mindspring.com> References: <1155496758.11659.122.camel@localhost.localdomain> <1155871140.30640.9.camel@localhost.localdomain> <44E5536C.8010403@pressure.to> <1156126147.2953.18.camel@localhost.localdomain> <44E92461.9050204@mindspring.com> <1156133536.6413.12.camel@localhost.localdomain> <44EC5A3A.1070008@mindspring.com> <1156342734.5809.5.camel@localhost.localdomain> <44EC97E0.6030605@mindspring.com> Message-ID: <1156368156.1950.28.camel@localhost.localdomain> On Wed, 2006-08-23 at 14:01 -0400, Roy Sutton wrote: > Sadly, the SWIG people have not responded at all to my call for help. > I'll go stick it in their bug tracker later and maybe write a followup > e-mail. I suspect some people may be on vacation so I don't want to > rock things too much. You might try contacting the Ruby SWIG developer(s) directly, since this is clearly ruby-specific. That would be Charlie Savage (who I do not know) and Lyle Johnson (who has been very helpful in the past). While I would love to have those problems fixed, I don't believe they are the cause of most of our crashes. Object ownership and garbage collection are causing most of my problems, in my opinion. I have done some reading, and I have at least one small interesting test case[1], so I hope to research this over the next few days. Kevin [1] Run samples/minimal/minimal.rb. If I bring up the About box at any time, then I get a segfault upon exit. If I avoid the About box, it exits cleanly. So far, my gdb sessions to try to figure this out have not revealed any easy answers. From sean.m.long at gmail.com Wed Aug 23 17:20:26 2006 From: sean.m.long at gmail.com (Sean Long) Date: Wed, 23 Aug 2006 14:20:26 -0700 Subject: [Wxruby-users] doc generator now in CVS In-Reply-To: <1156364346.1950.7.camel@localhost.localdomain> References: <44EB5D88.4080207@pressure.to> <1156364346.1950.7.camel@localhost.localdomain> Message-ID: I tried to generate the textile docs then HTML last night and it worked fine for me. Machine used is Mac OS X Intel. Sean On 8/23/06, Kevin Smith wrote: > On Tue, 2006-08-22 at 20:39 +0100, Alex Fenton wrote: > > Just a quick note to let you know that the Textile doc generation stuff > > is now in CVS. There is a moderate amount of documentation in > > rake/rakedoc.rb in case you feel like generating your own local copy. > > The only prerequisite is the Ruby 'redcloth' library. > > I'm getting an error when I run rake: > > kevins at aria:~/work/wxruby2$ rake --trace > (in /home/kevins/work/wxruby2) > rake aborted! > no such file to load -- wxlatex_parser > /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in > `gem_original_require' > /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' > ./rake/rakedocs.rb:21 > /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' > /home/kevins/work/wxruby2/rakefile:7 > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1828:in > `load_rakefile' > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1900:in `run' > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/bin/rake:7 > /usr/bin/rake:18 > kevins at aria:~/work/wxruby2$ > > > Did you forget to check in wxlatex_parser? Or is it just not being > found? > > I have commented out the require 'rakedocs' for now, so I can keep > working. > > Kevin > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > From wxruby at qualitycode.com Wed Aug 23 17:13:39 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Wed, 23 Aug 2006 17:13:39 -0400 Subject: [Wxruby-users] Looking for volunteers (no C++ knowledge needed!) Message-ID: <1156367619.1950.20.camel@localhost.localdomain> I just posted a follow-up to our bug that old SWIG versions are not properly detected, leading to unclear failure messages: --- Actually, this just got a lot simpler. We used to support both 1.3.25+ and 1.3.24-, so we had to do both kinds of detection. Now, we REQUIRE 1.3.29, and therefore any SWIG that can't give us its version number the new way is automatically too old. We can get rid of swigver.rb entirely. --- As with wx version detection, this can be done by someone who knows only ruby--no C++ or SWIG knowledge is required. Step right up, folks! You too can contribute to the wxruby project! Thanks, Kevin From wxruby at qualitycode.com Wed Aug 23 17:08:51 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Wed, 23 Aug 2006 17:08:51 -0400 Subject: [Wxruby-users] building wxruby2 from cvs (gentoo) In-Reply-To: References: Message-ID: <1156367331.1950.16.camel@localhost.localdomain> On Wed, 2006-08-23 at 22:01 +0200, Kees Jongenburger wrote: > I am a newbie to wx and wxruby, I just built wxruby2 on my gentoo box. > At first it did not work. So I post a little message,it might help others. Hello, welcome, and thanks for contributing! > At first a cryptic message was shown > > SWIG Version 1.3.21 Yes, we have a bug in our tracker noting that older versions of SWIG are not properly detected. This could be fixed by someone who knows nothing about C++, SWIG, or even wxRuby. It would be great if someone could volunteer to take care of it. > my gentoo has two versions of wx installed > (2.4.2 and 2.6.2) (2.4 is the default), so the wx-config points to the > 2.4 configuration while the wx-config-2.6 to the new version. > I changed wx-config for wx-config-2.6 in rake/rakewx.rb at line 41 > perhaps the developers can add a check to see if wx-config-2.6 is in the path? Interesting. I just added a bug to the tracker requesting a wx version check in the rakefile. For Linux, it's very easy. I seem to recall that MSWin doesn't have wx-config available, so I'm not sure how the version would be detectable on that platform. > anyway now it all works and I can start playing around Excellent. Please report your findings, good or bad. Kevin From alex at pressure.to Wed Aug 23 18:54:00 2006 From: alex at pressure.to (Alex Fenton) Date: Wed, 23 Aug 2006 23:54:00 +0100 Subject: [Wxruby-users] doc generator now in CVS In-Reply-To: <1156364346.1950.7.camel@localhost.localdomain> References: <44EB5D88.4080207@pressure.to> <1156364346.1950.7.camel@localhost.localdomain> Message-ID: <44ECDC88.1040109@pressure.to> Hi Kevin > I'm getting an error when I run rake: > > kevins at aria:~/work/wxruby2$ rake --trace > (in /home/kevins/work/wxruby2) > rake aborted! > no such file to load -- wxlatex_parser Just to check - you have the new directory doc/lib pulled from CVS (ie cvs -d). And the top of rake/rakedocs.rb adds this directory to LOAD_PATH? a From wxruby at qualitycode.com Wed Aug 23 17:02:25 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Wed, 23 Aug 2006 17:02:25 -0400 Subject: [Wxruby-users] Patch to rakemswin.rb In-Reply-To: <44E92843.1000406@mindspring.com> References: <44E92843.1000406@mindspring.com> Message-ID: <1156366945.1950.12.camel@localhost.localdomain> On Sun, 2006-08-20 at 23:28 -0400, Roy Sutton wrote: > This patch file removes a bad include path in the windows build. > I also took out the -I.. line since it, too, was unneeded. Applied, thanks. Kevin From wxruby at qualitycode.com Wed Aug 23 19:51:07 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Wed, 23 Aug 2006 19:51:07 -0400 Subject: [Wxruby-users] doc generator now in CVS In-Reply-To: References: <44EB5D88.4080207@pressure.to> <1156364346.1950.7.camel@localhost.localdomain> Message-ID: <1156377067.5902.0.camel@localhost.localdomain> What and where is wxlatex_parser? Kevin On Wed, 2006-08-23 at 14:20 -0700, Sean Long wrote: > I tried to generate the textile docs then HTML last night and it > worked fine for me. Machine used is Mac OS X Intel. > > Sean > > On 8/23/06, Kevin Smith wrote: > > On Tue, 2006-08-22 at 20:39 +0100, Alex Fenton wrote: > > > Just a quick note to let you know that the Textile doc generation stuff > > > is now in CVS. There is a moderate amount of documentation in > > > rake/rakedoc.rb in case you feel like generating your own local copy. > > > The only prerequisite is the Ruby 'redcloth' library. > > > > I'm getting an error when I run rake: > > > > kevins at aria:~/work/wxruby2$ rake --trace > > (in /home/kevins/work/wxruby2) > > rake aborted! > > no such file to load -- wxlatex_parser > > /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in > > `gem_original_require' > > /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' > > ./rake/rakedocs.rb:21 > > /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' > > /home/kevins/work/wxruby2/rakefile:7 > > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1828:in > > `load_rakefile' > > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1900:in `run' > > /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/bin/rake:7 > > /usr/bin/rake:18 > > kevins at aria:~/work/wxruby2$ > > > > > > Did you forget to check in wxlatex_parser? Or is it just not being > > found? > > > > I have commented out the require 'rakedocs' for now, so I can keep > > working. > > > > Kevin > > > > > > _______________________________________________ > > wxruby-users mailing list > > wxruby-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wxruby-users > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users From alex at pressure.to Wed Aug 23 20:02:14 2006 From: alex at pressure.to (Alex Fenton) Date: Thu, 24 Aug 2006 01:02:14 +0100 Subject: [Wxruby-users] doc generator now in CVS In-Reply-To: <1156377067.5902.0.camel@localhost.localdomain> References: <44EB5D88.4080207@pressure.to> <1156364346.1950.7.camel@localhost.localdomain> <1156377067.5902.0.camel@localhost.localdomain> Message-ID: <44ECEC86.4000403@pressure.to> Kevin Smith wrote: > What and where is wxlatex_parser? > Should be in doc/lib. Is a specialised latex parser to turn the format used by WxWidgets docs into our Textile format. a From wxruby at qualitycode.com Thu Aug 24 00:38:36 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 24 Aug 2006 00:38:36 -0400 Subject: [Wxruby-users] doc generator now in CVS In-Reply-To: <44ECDC88.1040109@pressure.to> References: <44EB5D88.4080207@pressure.to> <1156364346.1950.7.camel@localhost.localdomain> <44ECDC88.1040109@pressure.to> Message-ID: <1156394316.15521.2.camel@localhost.localdomain> On Wed, 2006-08-23 at 23:54 +0100, Alex Fenton wrote: > Just to check - you have the new directory doc/lib pulled from CVS (ie > cvs -d). And the top of rake/rakedocs.rb adds this directory to LOAD_PATH? Doh! I hate CVS. I was thinking that cvs update was enough...I hadn't added the -d switch. I have uncommented the doc stuff in rakefile, as I am now able to run rake. I haven't actually tried building any doc stuff. I am not thrilled that we now require the redcloth gem to be installed before we can build wxruby2 at all. It seems like it should only be required if you actually want to work with the docs. Not a showstopper, but "would be nice". Thanks, Kevin From roys at mindspring.com Thu Aug 24 00:42:07 2006 From: roys at mindspring.com (Roy Sutton) Date: Thu, 24 Aug 2006 00:42:07 -0400 Subject: [Wxruby-users] SWIG Message-ID: <44ED2E1F.2050108@mindspring.com> I decided to try my hand at hacking SWIG and successfully produced a patch that fixes the error I demonstrated. I'm not -positive- it's correct for all cases but I'll re-run my version of SWIG over the library and see how things turn out. Roy From wxruby at roadq.com Thu Aug 24 00:44:33 2006 From: wxruby at roadq.com (Mark Ping) Date: Wed, 23 Aug 2006 21:44:33 -0700 Subject: [Wxruby-users] TreeCtrl background? Message-ID: <44ED2EB1.5000202@roadq.com> On my windows build, I just noticed that the background of my TextCtrl's is grey by default, and when I try to set the default style I get the error: TestTextCtrl.rb:15:in `set_default_style': undefined method `' for # (NoMethodError) from TestTextCtrl.rb:15:in `initialize' from TestTextCtrl.rb:24:in `on_init' from TestTextCtrl.rb:30 Using the following (probably overly verbose) program: require 'wx' include Wx class MyFrame < Frame def initialize(title) super(nil, -1, title) @top_sizer = BoxSizer.new( Wx::VERTICAL ) @panel = Panel.new(self) @panel.set_auto_layout(true) @panel.set_sizer(@top_sizer) @test_text_ctrl = TextCtrl.new(@panel, -1, "") style = @test_text_ctrl.get_default_style() style.set_background_colour(WHITE) @test_text_ctrl.set_default_style(style) @top_sizer.add(@test_text_ctrl, 0, Wx::EXPAND | Wx::RIGHT, 20) end end class MyApp < App def on_init() frame = MyFrame.new("TextCtrl Test") frame.show(TRUE) end end $g_app = MyApp.new $g_app.main_loop() This is in spite of the fact that "set_default_style" appears to be correctly generated when I run rake. Any ideas on what might be causing this and/or how to fix it? --Mark Ping From roys at mindspring.com Thu Aug 24 00:58:44 2006 From: roys at mindspring.com (Roy Sutton) Date: Thu, 24 Aug 2006 00:58:44 -0400 Subject: [Wxruby-users] doc generator now in CVS In-Reply-To: <1156394316.15521.2.camel@localhost.localdomain> References: <44EB5D88.4080207@pressure.to> <1156364346.1950.7.camel@localhost.localdomain> <44ECDC88.1040109@pressure.to> <1156394316.15521.2.camel@localhost.localdomain> Message-ID: <44ED3204.6010903@mindspring.com> Kevin Smith wrote: > I am not thrilled that we now require the redcloth gem to be installed > before we can build wxruby2 at all. It seems like it should only be > required if you actually want to work with the docs. Not a showstopper, > but "would be nice". > > I second this. I planned not to install redcloth. 'rake docs' to produce the docs seems the best idea. Roy From kees.jongenburger at gmail.com Thu Aug 24 01:41:57 2006 From: kees.jongenburger at gmail.com (Kees Jongenburger) Date: Thu, 24 Aug 2006 07:41:57 +0200 Subject: [Wxruby-users] building wxruby2 from cvs (gentoo) In-Reply-To: <1156367331.1950.16.camel@localhost.localdomain> References: <1156367331.1950.16.camel@localhost.localdomain> Message-ID: On 8/23/06, Kevin Smith wrote: > On Wed, 2006-08-23 at 22:01 +0200, Kees Jongenburger wrote: > > I am a newbie to wx and wxruby, I just built wxruby2 on my gentoo box. > > At first it did not work. So I post a little message,it might help others. > > Hello, welcome, and thanks for contributing! Thanks, I am playing with the maemo platform. This was the first run on the sdk. You might not enjoy it as much as I did but here is it http://www.keesj.dds.nl/n770/ruby/wxruby/textctrl_23_08_2006.mpeg I just can't wait untill I can develop my gui's in ruby on this little toy greetings From sean.m.long at gmail.com Thu Aug 24 01:44:53 2006 From: sean.m.long at gmail.com (Sean Long) Date: Wed, 23 Aug 2006 22:44:53 -0700 Subject: [Wxruby-users] SWIG In-Reply-To: <44ED2E1F.2050108@mindspring.com> References: <44ED2E1F.2050108@mindspring.com> Message-ID: Nice! Is that the error that causes certain dialogs on OS X not to show-up on screen? If so thank you, that one really bugs me. Sean On 8/23/06, Roy Sutton wrote: > I decided to try my hand at hacking SWIG and successfully produced a > patch that fixes the error I demonstrated. I'm not -positive- it's > correct for all cases but I'll re-run my version of SWIG over the > library and see how things turn out. > > Roy > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > From sean.m.long at gmail.com Thu Aug 24 02:11:13 2006 From: sean.m.long at gmail.com (Sean Long) Date: Wed, 23 Aug 2006 23:11:13 -0700 Subject: [Wxruby-users] TextCtrl background? (was TreeCtrl background?) Message-ID: You had me looking in TreeCtrl at first with the previous subject line :) I too got an error and do not see an obvious reason, Kevin or Roy may have a better idea as they are better with SWIG than I am. You may want to put some printf's in the generated TextCtrl.cpp file within the SetDefaultStyle method and find where it is crashing. The error in Mac OS X is: test.rb:15:in `set_default_style': undefined method `' for # (NoMethodError) from test.rb:15:in `initialize' from test.rb:24:in `on_init' from test.rb:30 Sean On 8/23/06, Mark Ping wrote: > On my windows build, I just noticed that the background of my TextCtrl's > is grey by default, and when I try to set the default style I get the error: > > TestTextCtrl.rb:15:in `set_default_style': undefined method `' for > # (NoMethodError) > from TestTextCtrl.rb:15:in `initialize' > from TestTextCtrl.rb:24:in `on_init' > from TestTextCtrl.rb:30 > > > Using the following (probably overly verbose) program: > > require 'wx' > include Wx > > class MyFrame < Frame > def initialize(title) > super(nil, -1, title) > @top_sizer = BoxSizer.new( Wx::VERTICAL ) > @panel = Panel.new(self) > @panel.set_auto_layout(true) > @panel.set_sizer(@top_sizer) > @test_text_ctrl = TextCtrl.new(@panel, -1, "") > > style = @test_text_ctrl.get_default_style() > style.set_background_colour(WHITE) > @test_text_ctrl.set_default_style(style) > > > @top_sizer.add(@test_text_ctrl, 0, Wx::EXPAND | Wx::RIGHT, 20) > end > end > > class MyApp < App > def on_init() > frame = MyFrame.new("TextCtrl Test") > frame.show(TRUE) > end > end > > $g_app = MyApp.new > $g_app.main_loop() > > This is in spite of the fact that "set_default_style" appears to be > correctly generated when I run rake. > > Any ideas on what might be causing this and/or how to fix it? > > --Mark Ping > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > From sean.m.long at gmail.com Thu Aug 24 02:21:42 2006 From: sean.m.long at gmail.com (Sean Long) Date: Wed, 23 Aug 2006 23:21:42 -0700 Subject: [Wxruby-users] New wxTextAttr.h Message-ID: When I was trying to find the problem Mark Ping was having with set_default_style in TextCtrl I thought the problem might have been with wxTextAttr, it was not but I updated the .h file in the process. Because the file has changed so much from the last version I am uploading the whole file. Note that the change is not just the removal of comments some of the method signatures have changed with wx 2.6.x. Sean -------------- next part -------------- A non-text attachment was scrubbed... Name: wxTextAttr.h Type: application/octet-stream Size: 2021 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-users/attachments/20060823/82783f1a/attachment.obj From sean.m.long at gmail.com Thu Aug 24 02:40:17 2006 From: sean.m.long at gmail.com (Sean Long) Date: Wed, 23 Aug 2006 23:40:17 -0700 Subject: [Wxruby-users] Patch to RubyConstants.i Message-ID: While investigating the 'TextCtrl background?' message from Mark I noticed some Constants related to TextCtrl were missing. Sean -------------- next part -------------- A non-text attachment was scrubbed... Name: RubyConstants_i.patch Type: application/octet-stream Size: 2461 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-users/attachments/20060823/dcec116a/attachment-0001.obj From alex at pressure.to Thu Aug 24 03:57:57 2006 From: alex at pressure.to (Alex Fenton) Date: Thu, 24 Aug 2006 08:57:57 +0100 Subject: [Wxruby-users] doc generator now in CVS In-Reply-To: <1156394316.15521.2.camel@localhost.localdomain> References: <44EB5D88.4080207@pressure.to> <1156364346.1950.7.camel@localhost.localdomain> <44ECDC88.1040109@pressure.to> <1156394316.15521.2.camel@localhost.localdomain> Message-ID: <44ED5C05.1040608@pressure.to> > I am not thrilled that we now require the redcloth gem to be installed > before we can build wxruby2 at all. It seems like it should only be > required if you actually want to work with the docs. Not a showstopper, > but "would be nice". Sorry, my mistake. I had wrapped the relevant bit in a rescue clause, but forgot to commit. Now fixed. cheers alex From robin at nibor.org Thu Aug 24 09:23:43 2006 From: robin at nibor.org (Robin Stocker) Date: Thu, 24 Aug 2006 15:23:43 +0200 Subject: [Wxruby-users] Looking for volunteers (no C++ knowledge needed!) In-Reply-To: <1156367619.1950.20.camel@localhost.localdomain> References: <1156367619.1950.20.camel@localhost.localdomain> Message-ID: <44EDA85F.7020307@nibor.org> Kevin Smith wrote: > As with wx version detection, this can be done by someone who knows only > ruby--no C++ or SWIG knowledge is required. Step right up, folks! You > too can contribute to the wxruby project! Hi, Thanks for the chance to contribute, even if it's such a small thing :) Find attached the patch for rake/rakewx.rb. The file swig/swigver.rb isn't needed anymore and it can be removed from CVS. I wasn't sure whether to indent with tabs or spaces because there were both in rakewx.rb, so I just stuck with the standard Ruby style of using two spaces. I also took the liberty of changing the error message and simplifying some things. Hope you like it, Robin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: swig-version-check.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060824/3a3f01ca/attachment.pl From wxruby at qualitycode.com Thu Aug 24 09:45:36 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 24 Aug 2006 09:45:36 -0400 Subject: [Wxruby-users] wxRuby and maemo (was: building wxruby2 from cvs (gentoo)) In-Reply-To: References: <1156367331.1950.16.camel@localhost.localdomain> Message-ID: <1156427136.6260.1.camel@localhost.localdomain> On Thu, 2006-08-24 at 07:41 +0200, Kees Jongenburger wrote: > I am playing with the maemo platform. This was the first run on the sdk. > You might not enjoy it as much as I did but here is it > http://www.keesj.dds.nl/n770/ruby/wxruby/textctrl_23_08_2006.mpeg > > I just can't wait untill I can develop my gui's in ruby on this little toy I had not heard of maemo. I assume you mean this: http://www.maemo.org/about.html So you hope to be able to write apps in wxRuby that will run on this mobile Nokia tablet device? Interesting. Kevin From wxruby at qualitycode.com Thu Aug 24 10:09:31 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 24 Aug 2006 10:09:31 -0400 Subject: [Wxruby-users] gem version numbering In-Reply-To: <1156342499.5809.1.camel@localhost.localdomain> References: <1156126936.2953.28.camel@localhost.localdomain> <44EA047D.9080303@pressure.to> <1156278150.5712.36.camel@localhost.localdomain> <1156342499.5809.1.camel@localhost.localdomain> Message-ID: <1156428571.6260.10.camel@localhost.localdomain> New proposal for our gem name/version: wxruby2-preview-0.1.0 As long as we are in alpha/preview mode (where the system crashes every few seconds), let's be up-front and honest about it. Later, when we are near the true release, we can change the gem name from wxruby2-preview to wxruby. At that point, 0.9 or 1.9 could work. The name (wxruby2-preview) clearly distinguishes it from the earlier wxruby 0.6.0. The version number (0.1.0) makes it clear that this is not for production use. Kevin From alex at pressure.to Thu Aug 24 10:25:48 2006 From: alex at pressure.to (Alex Fenton) Date: Thu, 24 Aug 2006 15:25:48 +0100 Subject: [Wxruby-users] gem version numbering In-Reply-To: <1156428571.6260.10.camel@localhost.localdomain> References: <1156126936.2953.28.camel@localhost.localdomain> <44EA047D.9080303@pressure.to> <1156278150.5712.36.camel@localhost.localdomain> <1156342499.5809.1.camel@localhost.localdomain> <1156428571.6260.10.camel@localhost.localdomain> Message-ID: <44EDB6EC.1060207@pressure.to> Kevin Smith wrote: > New proposal for our gem name/version: > > wxruby2-preview-0.1.0 > Sounds good to me. Completeness vis-a-vis 0.6.0 can then be one of our criteria for moving to [01].9 alex From roys at mindspring.com Thu Aug 24 14:15:19 2006 From: roys at mindspring.com (Roy Sutton) Date: Thu, 24 Aug 2006 14:15:19 -0400 Subject: [Wxruby-users] SWIG In-Reply-To: References: <44ED2E1F.2050108@mindspring.com> Message-ID: <44EDECB7.7060107@mindspring.com> I haven't gotten to that one yet, I don't think. But it does correct the crash when you click (double click?) on the grid cell with text in it. Roy Sean Long wrote: > Nice! > > Is that the error that causes certain dialogs on OS X not to show-up > on screen? If so thank you, that one really bugs me. > > Sean > > On 8/23/06, Roy Sutton wrote: > >> I decided to try my hand at hacking SWIG and successfully produced a >> patch that fixes the error I demonstrated. I'm not -positive- it's >> correct for all cases but I'll re-run my version of SWIG over the >> library and see how things turn out. >> >> Roy >> _______________________________________________ >> wxruby-users mailing list >> wxruby-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wxruby-users >> >> > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > From roys at mindspring.com Thu Aug 24 14:17:16 2006 From: roys at mindspring.com (Roy Sutton) Date: Thu, 24 Aug 2006 14:17:16 -0400 Subject: [Wxruby-users] gem version numbering In-Reply-To: <1156428571.6260.10.camel@localhost.localdomain> References: <1156126936.2953.28.camel@localhost.localdomain> <44EA047D.9080303@pressure.to> <1156278150.5712.36.camel@localhost.localdomain> <1156342499.5809.1.camel@localhost.localdomain> <1156428571.6260.10.camel@localhost.localdomain> Message-ID: <44EDED2C.1040103@mindspring.com> Fine with me. As long as when we update the gem it doesn't leave the old one hanging around so people accidentally get the wrong one. Roy Kevin Smith wrote: > New proposal for our gem name/version: > > wxruby2-preview-0.1.0 > > As long as we are in alpha/preview mode (where the system crashes every > few seconds), let's be up-front and honest about it. Later, when we are > near the true release, we can change the gem name from wxruby2-preview > to wxruby. At that point, 0.9 or 1.9 could work. > > The name (wxruby2-preview) clearly distinguishes it from the earlier > wxruby 0.6.0. > > The version number (0.1.0) makes it clear that this is not for > production use. > > Kevin > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > From roys at mindspring.com Thu Aug 24 15:20:16 2006 From: roys at mindspring.com (Roy Sutton) Date: Thu, 24 Aug 2006 15:20:16 -0400 Subject: [Wxruby-users] TreeCtrl background? In-Reply-To: <44ED2EB1.5000202@roadq.com> References: <44ED2EB1.5000202@roadq.com> Message-ID: <44EDFBF0.90906@mindspring.com> This appears to be another SWIG bug. SWIG is somehow generating calls to empty names, as evidenced from SetStyle in TextCtrl.cpp: result = rb_funcall(swig_get_self(), rb_intern(""), 3,obj0,obj1,obj2); This is happening a good bit. I'll see if I can find out why. Roy Mark Ping wrote: > On my windows build, I just noticed that the background of my TextCtrl's > is grey by default, and when I try to set the default style I get the error: > > TestTextCtrl.rb:15:in `set_default_style': undefined method `' for > # (NoMethodError) > from TestTextCtrl.rb:15:in `initialize' > from TestTextCtrl.rb:24:in `on_init' > from TestTextCtrl.rb:30 > > > Using the following (probably overly verbose) program: > > require 'wx' > include Wx > > class MyFrame < Frame > def initialize(title) > super(nil, -1, title) > @top_sizer = BoxSizer.new( Wx::VERTICAL ) > @panel = Panel.new(self) > @panel.set_auto_layout(true) > @panel.set_sizer(@top_sizer) > @test_text_ctrl = TextCtrl.new(@panel, -1, "") > > style = @test_text_ctrl.get_default_style() > style.set_background_colour(WHITE) > @test_text_ctrl.set_default_style(style) > > > @top_sizer.add(@test_text_ctrl, 0, Wx::EXPAND | Wx::RIGHT, 20) > end > end > > class MyApp < App > def on_init() > frame = MyFrame.new("TextCtrl Test") > frame.show(TRUE) > end > end > > $g_app = MyApp.new > $g_app.main_loop() > > This is in spite of the fact that "set_default_style" appears to be > correctly generated when I run rake. > > Any ideas on what might be causing this and/or how to fix it? > > --Mark Ping > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > From roys at mindspring.com Thu Aug 24 15:52:44 2006 From: roys at mindspring.com (Roy Sutton) Date: Thu, 24 Aug 2006 15:52:44 -0400 Subject: [Wxruby-users] TreeCtrl background? In-Reply-To: <44EDFBF0.90906@mindspring.com> References: <44ED2EB1.5000202@roadq.com> <44EDFBF0.90906@mindspring.com> Message-ID: <44EE038C.3070800@mindspring.com> This is a bug in SWIG, but also a bug in our header files. SWIG does warn us that we have multiple definitions of the same function. I will produce some patch files for the affected headers. The bottom line is that SetStyle is defined twice in wxTextCtrl.h. So are HitTest and SetMaxLength. Roy Roy Sutton wrote: > This appears to be another SWIG bug. SWIG is somehow generating calls > to empty names, as evidenced from SetStyle in TextCtrl.cpp: > > result = rb_funcall(swig_get_self(), rb_intern(""), 3,obj0,obj1,obj2); > > This is happening a good bit. I'll see if I can find out why. > > Roy > > Mark Ping wrote: > >> On my windows build, I just noticed that the background of my TextCtrl's >> is grey by default, and when I try to set the default style I get the error: >> >> TestTextCtrl.rb:15:in `set_default_style': undefined method `' for >> # (NoMethodError) >> from TestTextCtrl.rb:15:in `initialize' >> from TestTextCtrl.rb:24:in `on_init' >> from TestTextCtrl.rb:30 >> >> >> Using the following (probably overly verbose) program: >> >> require 'wx' >> include Wx >> >> class MyFrame < Frame >> def initialize(title) >> super(nil, -1, title) >> @top_sizer = BoxSizer.new( Wx::VERTICAL ) >> @panel = Panel.new(self) >> @panel.set_auto_layout(true) >> @panel.set_sizer(@top_sizer) >> @test_text_ctrl = TextCtrl.new(@panel, -1, "") >> >> style = @test_text_ctrl.get_default_style() >> style.set_background_colour(WHITE) >> @test_text_ctrl.set_default_style(style) >> >> >> @top_sizer.add(@test_text_ctrl, 0, Wx::EXPAND | Wx::RIGHT, 20) >> end >> end >> >> class MyApp < App >> def on_init() >> frame = MyFrame.new("TextCtrl Test") >> frame.show(TRUE) >> end >> end >> >> $g_app = MyApp.new >> $g_app.main_loop() >> >> This is in spite of the fact that "set_default_style" appears to be >> correctly generated when I run rake. >> >> Any ideas on what might be causing this and/or how to fix it? >> >> --Mark Ping >> >> _______________________________________________ >> wxruby-users mailing list >> wxruby-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wxruby-users >> >> >> >> >> > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > From wxruby at qualitycode.com Thu Aug 24 16:19:37 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 24 Aug 2006 16:19:37 -0400 Subject: [Wxruby-users] New wxTextAttr.h In-Reply-To: References: Message-ID: <1156450777.5356.3.camel@localhost.localdomain> On Wed, 2006-08-23 at 23:21 -0700, Sean Long wrote: > When I was trying to find the problem Mark Ping was having with > set_default_style in TextCtrl I thought the problem might have been > with wxTextAttr, it was not but I updated the .h file in the process. > Because the file has changed so much from the last version I am > uploading the whole file. Applied, thanks. Hopefully it will work on all platforms. I tested our demos with it, and found (and fixed) an unrelated bug in bigdemo/wxTextCtrl which I fixed. It was aborting due to calling a method by the wrong name. Kevin From kees.jongenburger at gmail.com Thu Aug 24 16:22:17 2006 From: kees.jongenburger at gmail.com (Kees Jongenburger) Date: Thu, 24 Aug 2006 22:22:17 +0200 Subject: [Wxruby-users] wxRuby and maemo (was: building wxruby2 from cvs (gentoo)) In-Reply-To: <1156427136.6260.1.camel@localhost.localdomain> References: <1156367331.1950.16.camel@localhost.localdomain> <1156427136.6260.1.camel@localhost.localdomain> Message-ID: On 8/24/06, Kevin Smith wrote: > On Thu, 2006-08-24 at 07:41 +0200, Kees Jongenburger wrote: > > I just can't wait untill I can develop my gui's in ruby on this little toy > > I had not heard of maemo. I assume you mean this: > > http://www.maemo.org/about.html Yes, it is the platform that runs on the Nokia 770 http://europe.nokia.com/770 > > So you hope to be able to write apps in wxRuby that will run on this > mobile Nokia tablet device? Interesting. Yes, I even hope to write apps "on" that same Nokia(using a real keyboard of course) Today I actually managed to get wxruby running on the real device. I did not want to install rake/gem on the device since it might become to much So I tried creating a debian package for wxruby (failed because i don't know how I am supposed to install a ruby package without rake). I ended up just copying wx.rb and wxruby2.so to the device and it worked. I must note that before I was able to do this I had to run strip on the wxruby2.so (it was 41MB !!!) and back to a few MB after the strip. The startup time of the textctrl app was really slow about 10 seconds or so.One running the performace seamed ok. I don't know what the slowest component it It might be interresting to start ruby , load the libs and try to run multiple apps in the interpreter. it that possible? That would greatly reduce startup time. The bigest problem right now is that wx ins't ported to the maemo platform. It runs the gtk code , but I there are issues :) The other problem Is that I have 2 week holidays starting tomorrow :) Thanks for the interest From wxruby at qualitycode.com Thu Aug 24 16:24:35 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 24 Aug 2006 16:24:35 -0400 Subject: [Wxruby-users] Patch to RubyConstants.i In-Reply-To: References: Message-ID: <1156451075.5356.7.camel@localhost.localdomain> On Wed, 2006-08-23 at 23:40 -0700, Sean Long wrote: > While investigating the 'TextCtrl background?' message from Mark I > noticed some Constants related to TextCtrl were missing. Committed, thanks. Eventually, it would be great if we could find a way to tell SWIG that the constants exist, but to inherit the specific values from wx itself, instead of re-defining them. For example: #define wxTEXT_ATTR_TEXT_COLOUR 0x0001 If the wx value changes, our code will be wrong, and it would be hard to figure out the problem. Or, more likely, if the value is different on different platforms, or if we just accidentally copy it wrong or type over it without noticing. Anyway, that's for the future wish list. Kevin From wxruby at qualitycode.com Thu Aug 24 17:00:58 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 24 Aug 2006 17:00:58 -0400 Subject: [Wxruby-users] Swig version detection improvements (was: Looking for volunteers) In-Reply-To: <44EDA85F.7020307@nibor.org> References: <1156367619.1950.20.camel@localhost.localdomain> <44EDA85F.7020307@nibor.org> Message-ID: <1156453258.5356.24.camel@localhost.localdomain> On Thu, 2006-08-24 at 15:23 +0200, Robin Stocker wrote: > Thanks for the chance to contribute, even if it's such a small thing :) Small things can be really important. And every small thing I don't have to do frees me up to do more of the "big stuff". So thanks! > Find attached the patch for rake/rakewx.rb. The file swig/swigver.rb > isn't needed anymore and it can be removed from CVS. The patch doesn't apply cleanly for me. It seems to have been generated from the wrong directory level. I worked around that, but have a couple other concerns about it. Can you double-check the "how to submit a patch" material on the wiki and recently posted to this list? > + unless version > + return false > + end I'm not a big fan of the "unless" keyword (again, I view it as a wart inherited from perl). Could this be if !version instead? > + ENV['SWIGVER'] = version I know this was in the existing code, but it raised a yellow flag for me. A bit of research shows that the only places it is used are swig/fixmodule.rb and fixmainmodule.rb. In both of those, there is a test for == 1.3.29, which seems wrong. It should be >= 1.3.29...except that now we ONLY support 1.3.29, so it looks like those if's should be removed, and the code inside should always be executed. The comment should remain...and we probably should have an end comment to indicate that the comment applies to that whole series of transformations. If we take those out, then we really don't need to set SWIGVER at all. If we really want to know the SWIG version, we can just look at the #define SWIGVERSION in each generated .cpp file. So, if it's not too much to ask, could you fix those too, and re-submit this patch (also changing the "unless" and generating it from the correct directory level)? Thanks again, Kevin From roys at mindspring.com Thu Aug 24 17:11:08 2006 From: roys at mindspring.com (Roy Sutton) Date: Thu, 24 Aug 2006 17:11:08 -0400 Subject: [Wxruby-users] Swig version detection improvements In-Reply-To: <1156453258.5356.24.camel@localhost.localdomain> References: <1156367619.1950.20.camel@localhost.localdomain> <44EDA85F.7020307@nibor.org> <1156453258.5356.24.camel@localhost.localdomain> Message-ID: <44EE15EC.6070508@mindspring.com> Kevin Smith wrote: > In both of those, there is a test for == 1.3.29, which seems wrong. It > should be >= 1.3.29...except that now we ONLY support 1.3.29, so it > looks like those if's should be removed, and the code inside should > always be executed. The comment should remain...and we probably should > have an end comment to indicate that the comment applies to that whole > series of transformations. > > This is on purpose to work around a bug in 1.3.29 that should be fixed in 1.3.30. In fact, I've compiled 1.3.30 so I can double-check the bug is fixed. Roy From wxruby at qualitycode.com Thu Aug 24 17:24:59 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 24 Aug 2006 17:24:59 -0400 Subject: [Wxruby-users] TreeCtrl background? In-Reply-To: <44EE038C.3070800@mindspring.com> References: <44ED2EB1.5000202@roadq.com> <44EDFBF0.90906@mindspring.com> <44EE038C.3070800@mindspring.com> Message-ID: <1156454699.5356.42.camel@localhost.localdomain> On Thu, 2006-08-24 at 15:52 -0400, Roy Sutton wrote: > This is a bug in SWIG, but also a bug in our header files. SWIG does > warn us that we have multiple definitions of the same function. I will > produce some patch files for the affected headers. The bottom line is > that SetStyle is defined twice in wxTextCtrl.h. So are HitTest and > SetMaxLength. True. We should fix this. > > This appears to be another SWIG bug. SWIG is somehow generating calls > > to empty names, as evidenced from SetStyle in TextCtrl.cpp: > > > > result = rb_funcall(swig_get_self(), rb_intern(""), 3,obj0,obj1,obj2); > > > > This is happening a good bit. I'll see if I can find out why. Also true, although not for set_default_style. In fact, it kind of looks like it is happening for the methods that were mentioned twice in the .h file. > >> On my windows build, I just noticed that the background of my TextCtrl's > >> is grey by default, and when I try to set the default style I get the error: > >> > >> TestTextCtrl.rb:15:in `set_default_style': undefined method `' for > >> # (NoMethodError) > >> from TestTextCtrl.rb:15:in `initialize' > >> from TestTextCtrl.rb:24:in `on_init' > >> from TestTextCtrl.rb:30 For me, with the code now in CVS (which has this afternoon's patches), the posted sample runs without errors. And the text background is white. But when I change the code to try to set the color to RED, the background remains white. I can call TextCtrl#set_background_colour and it works. Kevin From wxruby at qualitycode.com Thu Aug 24 17:25:46 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 24 Aug 2006 17:25:46 -0400 Subject: [Wxruby-users] SWIG In-Reply-To: <44ED2E1F.2050108@mindspring.com> References: <44ED2E1F.2050108@mindspring.com> Message-ID: <1156454746.5356.44.camel@localhost.localdomain> On Thu, 2006-08-24 at 00:42 -0400, Roy Sutton wrote: > I decided to try my hand at hacking SWIG and successfully produced a > patch that fixes the error I demonstrated. I'm not -positive- it's > correct for all cases but I'll re-run my version of SWIG over the > library and see how things turn out. I eagerly await your results. Also, if the patch is not too large, please post it here so we can all look at it, test it, etc. Thanks! Kevin From wxruby at qualitycode.com Thu Aug 24 17:28:09 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 24 Aug 2006 17:28:09 -0400 Subject: [Wxruby-users] Swig version detection improvements In-Reply-To: <44EE15EC.6070508@mindspring.com> References: <1156367619.1950.20.camel@localhost.localdomain> <44EDA85F.7020307@nibor.org> <1156453258.5356.24.camel@localhost.localdomain> <44EE15EC.6070508@mindspring.com> Message-ID: <1156454890.5356.48.camel@localhost.localdomain> On Thu, 2006-08-24 at 17:11 -0400, Roy Sutton wrote: > This is on purpose to work around a bug in 1.3.29 that should be fixed > in 1.3.30. In fact, I've compiled 1.3.30 so I can double-check the bug > is fixed. Ah. I didn't realize 1.3.30 was done enough to be testable like that. I would still prefer that the test be done against the SWIGVER found in the .cpp file itself, rather than using an ENV variable to communicate which SWIG version we found. I can try to do it if you don't have time, but I do consider it somewhat important. After the preview release would be fine, I suppose. So for the swigver redo, we should, for now, continue to set SWIGVER, and we should not modify fixmodule and fixmainmodule. Thanks, Kevin From wxruby at qualitycode.com Thu Aug 24 17:30:17 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 24 Aug 2006 17:30:17 -0400 Subject: [Wxruby-users] wxruby2 alpha status In-Reply-To: <1156126147.2953.18.camel@localhost.localdomain> References: <1155496758.11659.122.camel@localhost.localdomain> <1155871140.30640.9.camel@localhost.localdomain> <44E5536C.8010403@pressure.to> <1156126147.2953.18.camel@localhost.localdomain> Message-ID: <1156455017.5356.50.camel@localhost.localdomain> As discussed previously, I just checked in a change that renames bigdemo/Main.rbw to bigdemo/bigdemo.rb, for consistency with the other samples. Kevin P.S. For some reason, when I tried to post this as a non-reply, rubyforge rejected my message (twice) because it supposedly had Chinese encoding. Odd. From roys at mindspring.com Thu Aug 24 17:46:07 2006 From: roys at mindspring.com (Roy Sutton) Date: Thu, 24 Aug 2006 17:46:07 -0400 Subject: [Wxruby-users] SWIG In-Reply-To: <1156454746.5356.44.camel@localhost.localdomain> References: <44ED2E1F.2050108@mindspring.com> <1156454746.5356.44.camel@localhost.localdomain> Message-ID: <44EE1E1F.7070608@mindspring.com> I have actually had to make two patches to SWIG. One to fix a bug in SWIG where it produces directors for functions marked %ignore. Both patches to SWIG are attached. You'll need to grab the latests SWIG from the CVS. Roy Kevin Smith wrote: > On Thu, 2006-08-24 at 00:42 -0400, Roy Sutton wrote: > >> I decided to try my hand at hacking SWIG and successfully produced a >> patch that fixes the error I demonstrated. I'm not -positive- it's >> correct for all cases but I'll re-run my version of SWIG over the >> library and see how things turn out. >> > > I eagerly await your results. Also, if the patch is not too large, > please post it here so we can all look at it, test it, etc. > > Thanks! > > Kevin > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ruby.cxx.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060824/49c43ec7/attachment.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lang.cxx.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060824/49c43ec7/attachment-0001.pl From roys at mindspring.com Thu Aug 24 17:51:52 2006 From: roys at mindspring.com (Roy Sutton) Date: Thu, 24 Aug 2006 17:51:52 -0400 Subject: [Wxruby-users] typemap.i patch Message-ID: <44EE1F78.3070703@mindspring.com> This patch adds %directorout typemaps for the GetTextExtent functions -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: typemap.i.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060824/641bc43a/attachment.pl From roys at mindspring.com Thu Aug 24 17:55:21 2006 From: roys at mindspring.com (Roy Sutton) Date: Thu, 24 Aug 2006 17:55:21 -0400 Subject: [Wxruby-users] Patch to wxTextCtrl.h Message-ID: <44EE2049.1010501@mindspring.com> This removes duplicately defined functions. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wxTextCtrl.h.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060824/0247ee99/attachment-0001.pl From roys at mindspring.com Thu Aug 24 17:55:51 2006 From: roys at mindspring.com (Roy Sutton) Date: Thu, 24 Aug 2006 17:55:51 -0400 Subject: [Wxruby-users] Patch to wxListCtrl.h Message-ID: <44EE2067.8000102@mindspring.com> This removes a duplicately defined function. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wxListCtrl.h.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060824/f8f0e10c/attachment.pl From roys at mindspring.com Thu Aug 24 17:56:39 2006 From: roys at mindspring.com (Roy Sutton) Date: Thu, 24 Aug 2006 17:56:39 -0400 Subject: [Wxruby-users] Patch to wxImage.h Message-ID: <44EE2097.10502@mindspring.com> This patch fixes the name of FindHandlerMime. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wxImage.h.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060824/c7dfe8b9/attachment.pl From robin at nibor.org Thu Aug 24 18:06:34 2006 From: robin at nibor.org (Robin Stocker) Date: Fri, 25 Aug 2006 00:06:34 +0200 Subject: [Wxruby-users] Swig version detection improvements In-Reply-To: <1156453258.5356.24.camel@localhost.localdomain> References: <1156367619.1950.20.camel@localhost.localdomain> <44EDA85F.7020307@nibor.org> <1156453258.5356.24.camel@localhost.localdomain> Message-ID: <44EE22EA.10606@nibor.org> Kevin Smith wrote: > On Thu, 2006-08-24 at 15:23 +0200, Robin Stocker wrote: > The patch doesn't apply cleanly for me. It seems to have been generated > from the wrong directory level. I worked around that, but have a couple > other concerns about it. Can you double-check the "how to submit a > patch" material on the wiki and recently posted to this list? I'm sorry, I didn't realise that I wasn't in the top directory. I read the "how to" and saw that you use the diff -b option, so I changed the indenting to 4 spaces this time, to be a bit more consistent with the rest of the file. > I'm not a big fan of the "unless" keyword (again, I view it as a wart > inherited from perl). Could this be if !version instead? Well, I like it, although I sometimes use "if not" and sometimes "unless", depending on the probability of the condition being true :). Now I changed it to "if not", I hope this is also ok for you. > In both of those, there is a test for == 1.3.29, which seems wrong. It > should be >= 1.3.29...except that now we ONLY support 1.3.29, so it > looks like those if's should be removed, and the code inside should > always be executed. The comment should remain...and we probably should > have an end comment to indicate that the comment applies to that whole > series of transformations. I saw the reply from Roy and you, so this isn't included in the new patch. Regards, Robin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: swig-version-check-2.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060825/3d7ba806/attachment.pl From wxruby at qualitycode.com Thu Aug 24 18:24:23 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 24 Aug 2006 18:24:23 -0400 Subject: [Wxruby-users] gem version numbering In-Reply-To: <44EDED2C.1040103@mindspring.com> References: <1156126936.2953.28.camel@localhost.localdomain> <44EA047D.9080303@pressure.to> <1156278150.5712.36.camel@localhost.localdomain> <1156342499.5809.1.camel@localhost.localdomain> <1156428571.6260.10.camel@localhost.localdomain> <44EDED2C.1040103@mindspring.com> Message-ID: <1156458263.5356.59.camel@localhost.localdomain> Hmmmm. It appears that we could remove the wxruby2-preview gem from rubyforge, and it would no longer be available. But I'm not sure how to handle users who already had it on their system. First, if the tried to upgrade their wxruby2-preview gem, maybe we could replace it with a dummy gem that somehow told them they need to switch to the wxruby gem series? Second, if someone just tried to install wxruby when they already had wxruby2 installed, what would happen? Would gem detect the conflict? What error message would it give? Without a clear migration path, this proposal might not be practical. Kevin On Thu, 2006-08-24 at 14:17 -0400, Roy Sutton wrote: > Fine with me. As long as when we update the gem it doesn't leave the > old one hanging around so people accidentally get the wrong one. > > Roy > > Kevin Smith wrote: > > New proposal for our gem name/version: > > > > wxruby2-preview-0.1.0 > > > > As long as we are in alpha/preview mode (where the system crashes every > > few seconds), let's be up-front and honest about it. Later, when we are > > near the true release, we can change the gem name from wxruby2-preview > > to wxruby. At that point, 0.9 or 1.9 could work. > > > > The name (wxruby2-preview) clearly distinguishes it from the earlier > > wxruby 0.6.0. > > > > The version number (0.1.0) makes it clear that this is not for > > production use. > > > > Kevin > > > > > > _______________________________________________ > > wxruby-users mailing list > > wxruby-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > > > > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users From wxruby at qualitycode.com Thu Aug 24 23:47:44 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 24 Aug 2006 23:47:44 -0400 Subject: [Wxruby-users] Swig version detection improvements In-Reply-To: <44EE22EA.10606@nibor.org> References: <1156367619.1950.20.camel@localhost.localdomain> <44EDA85F.7020307@nibor.org> <1156453258.5356.24.camel@localhost.localdomain> <44EE22EA.10606@nibor.org> Message-ID: <1156477664.18080.2.camel@localhost.localdomain> This patch looked great and has been committed. Thanks! Kevin On Fri, 2006-08-25 at 00:06 +0200, Robin Stocker wrote: > Kevin Smith wrote: > > On Thu, 2006-08-24 at 15:23 +0200, Robin Stocker wrote: > > > The patch doesn't apply cleanly for me. It seems to have been generated > > from the wrong directory level. I worked around that, but have a couple > > other concerns about it. Can you double-check the "how to submit a > > patch" material on the wiki and recently posted to this list? > > I'm sorry, I didn't realise that I wasn't in the top directory. I read > the "how to" and saw that you use the diff -b option, so I changed the > indenting to 4 spaces this time, to be a bit more consistent with the > rest of the file. > > > I'm not a big fan of the "unless" keyword (again, I view it as a wart > > inherited from perl). Could this be if !version instead? > > Well, I like it, although I sometimes use "if not" and sometimes > "unless", depending on the probability of the condition being true :). > Now I changed it to "if not", I hope this is also ok for you. > > > In both of those, there is a test for == 1.3.29, which seems wrong. It > > should be >= 1.3.29...except that now we ONLY support 1.3.29, so it > > looks like those if's should be removed, and the code inside should > > always be executed. The comment should remain...and we probably should > > have an end comment to indicate that the comment applies to that whole > > series of transformations. > > I saw the reply from Roy and you, so this isn't included in the new patch. > > Regards, > Robin From wxruby at qualitycode.com Fri Aug 25 00:16:07 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Fri, 25 Aug 2006 00:16:07 -0400 Subject: [Wxruby-users] typemap.i patch In-Reply-To: <44EE1F78.3070703@mindspring.com> References: <44EE1F78.3070703@mindspring.com> Message-ID: <1156479367.18080.13.camel@localhost.localdomain> On Thu, 2006-08-24 at 17:51 -0400, Roy Sutton wrote: > This patch adds %directorout typemaps for the GetTextExtent functions Applied, thanks. I also uncommented the %ignore for DC#get_text_extent. That allows bigdemo's wxScrolledWindow page to get a bit farther, but now it chokes because the first parameter to draw_lines is an array which needs to get mapped to a wxList* in typemaps.i. A couple questions/comments: > +%typemap(directorargout) ( int * x , int * y , int * descent, int * externalLeading ) { > + if((TYPE(result) == T_ARRAY) && (RARRAY(result)->len >= 2)) What if an array is not returned, or if the returned array length is less than 2? Should we handle the case, by throwing or returning NULL or something? > + { > + *$1 = ($*1_ltype)NUM2INT(rb_ary_entry(result,0)); I don't remember seeing $*1_ltype before. It's a bit jarring seeing it on the same line as *$1. I don't know enough to suggest anything, but if you can think of a way to make those lines easier to understand, that would be great. > + *$2 = ($*2_ltype)NUM2INT(rb_ary_entry(result,1)); > + if(($3 != NULL) && RARRAY(result)->len >= 3) > + *$3 = ($*3_ltype)NUM2INT(rb_ary_entry(result,2)); > + if(($4 != NULL) && RARRAY(result)->len >= 4) > + *$4 = ($*4_ltype)NUM2INT(rb_ary_entry(result,3)); > + } > +} Kevin From wxruby at qualitycode.com Fri Aug 25 00:20:37 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Fri, 25 Aug 2006 00:20:37 -0400 Subject: [Wxruby-users] Patch to wxListCtrl.h In-Reply-To: <44EE2067.8000102@mindspring.com> References: <44EE2067.8000102@mindspring.com> Message-ID: <1156479638.18080.15.camel@localhost.localdomain> On Thu, 2006-08-24 at 17:55 -0400, Roy Sutton wrote: > This removes a duplicately defined function. These two similar patches (wxListCtrl and wxTextCtrl) have been applied. Thanks, Kevin From wxruby at qualitycode.com Fri Aug 25 00:23:51 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Fri, 25 Aug 2006 00:23:51 -0400 Subject: [Wxruby-users] Patch to wxImage.h In-Reply-To: <44EE2097.10502@mindspring.com> References: <44EE2097.10502@mindspring.com> Message-ID: <1156479831.18080.17.camel@localhost.localdomain> On Thu, 2006-08-24 at 17:56 -0400, Roy Sutton wrote: > This patch fixes the name of FindHandlerMime. Nice catch. Applied. Thanks. Kevin From roys at mindspring.com Fri Aug 25 00:29:23 2006 From: roys at mindspring.com (Roy Sutton) Date: Fri, 25 Aug 2006 00:29:23 -0400 Subject: [Wxruby-users] typemap.i patch In-Reply-To: <1156479367.18080.13.camel@localhost.localdomain> References: <44EE1F78.3070703@mindspring.com> <1156479367.18080.13.camel@localhost.localdomain> Message-ID: <44EE7CA3.5070902@mindspring.com> Kevin Smith wrote: > I also uncommented the %ignore for DC#get_text_extent. That allows > bigdemo's wxScrolledWindow page to get a bit farther, but now it chokes > because the first parameter to draw_lines is an array which needs to get > mapped to a wxList* in typemaps.i. > Excellent! I didn't even see that was missing. >> +%typemap(directorargout) ( int * x , int * y , int * descent, int * externalLeading ) { >> + if((TYPE(result) == T_ARRAY) && (RARRAY(result)->len >= 2)) >> > > What if an array is not returned, or if the returned array length is > less than 2? Should we handle the case, by throwing or returning NULL or > something? > Well, it really -has- to return at least two items in an array or it's not correct. 99.999% of the time no one will -ever- override this function so it's really academic. I don't have a good suggestion for what to do. Any value you pull out of thin air will be wrong. Throwing is probably the correct thing to do. I decided to just leave the old values untouched. >> + { >> + *$1 = ($*1_ltype)NUM2INT(rb_ary_entry(result,0)); >> > > I don't remember seeing $*1_ltype before. It's a bit jarring seeing it > on the same line as *$1. I don't know enough to suggest anything, but if > you can think of a way to make those lines easier to understand, that > would be great. > If there was something to make typemaps easier to read I'd be all over it. Typemaps just drive me nuts. I feel like they're just black magic sometimes. I feel like a really hacker when I work on them. I got this from looking through the docs and included files. If you think a comment would be helpful I think that's the only thing that would make these better. Roy From roys at mindspring.com Fri Aug 25 00:47:26 2006 From: roys at mindspring.com (Roy Sutton) Date: Fri, 25 Aug 2006 00:47:26 -0400 Subject: [Wxruby-users] Monkeys in Space... In-Reply-To: <1156368156.1950.28.camel@localhost.localdomain> References: <1155496758.11659.122.camel@localhost.localdomain> <1155871140.30640.9.camel@localhost.localdomain> <44E5536C.8010403@pressure.to> <1156126147.2953.18.camel@localhost.localdomain> <44E92461.9050204@mindspring.com> <1156133536.6413.12.camel@localhost.localdomain> <44EC5A3A.1070008@mindspring.com> <1156342734.5809.5.camel@localhost.localdomain> <44EC97E0.6030605@mindspring.com> <1156368156.1950.28.camel@localhost.localdomain> Message-ID: <44EE80DE.30402@mindspring.com> Kevin Smith wrote: > [1] Run samples/minimal/minimal.rb. If I bring up the About box at any > time, then I get a segfault upon exit. If I avoid the About box, it > exits cleanly. So far, my gdb sessions to try to figure this out have > not revealed any easy answers. > > (Un)fortunately this doesn't crash on Windows with the non-debug build. I may recompile debug to see what happens. I think I was able to get the debugger working once and I didn't write down what I did so it's lost to me again. If anyone has any clues for debugging with VC++ they should really post them somewhere. Roy From wxruby at qualitycode.com Fri Aug 25 01:26:33 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Fri, 25 Aug 2006 01:26:33 -0400 Subject: [Wxruby-users] Minimal.rb crashes on exit (was: Monkeys in Space...) In-Reply-To: <44EE80DE.30402@mindspring.com> References: <1155496758.11659.122.camel@localhost.localdomain> <1155871140.30640.9.camel@localhost.localdomain> <44E5536C.8010403@pressure.to> <1156126147.2953.18.camel@localhost.localdomain> <44E92461.9050204@mindspring.com> <1156133536.6413.12.camel@localhost.localdomain> <44EC5A3A.1070008@mindspring.com> <1156342734.5809.5.camel@localhost.localdomain> <44EC97E0.6030605@mindspring.com> <1156368156.1950.28.camel@localhost.localdomain> <44EE80DE.30402@mindspring.com> Message-ID: <1156483593.6260.41.camel@localhost.localdomain> On Fri, 2006-08-25 at 00:47 -0400, Roy Sutton wrote: > Kevin Smith wrote: > > [1] Run samples/minimal/minimal.rb. If I bring up the About box at any > > time, then I get a segfault upon exit. If I avoid the About box, it > > exits cleanly. So far, my gdb sessions to try to figure this out have > > not revealed any easy answers. > > > > > (Un)fortunately this doesn't crash on Windows with the non-debug build. > I may recompile debug to see what happens. Just in case you (or someone else) tries to debug this, here is what I found (at least what I can remember of it): During the main frame destructor, every bit of data I could find looked correct. However, a call to a virtual method crashed because it was calling to a bad (non-code) address. It seemed like the vtable of virtual method pointers had been trashed somehow. Based on the extensive debug output (I had wxDEBUG defined), it sure didn't look like a double-free problem. If anyone knows how to view the vtable of an object in gdb, please let me know. Kevin From wxruby at qualitycode.com Fri Aug 25 10:00:29 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Fri, 25 Aug 2006 10:00:29 -0400 Subject: [Wxruby-users] SWIG detection, revisited Message-ID: <1156514429.7474.3.camel@localhost.localdomain> I did some testing this morning, and wasn't happy with the error messages presented to the user if they didn't have the right SWIG version. I realized that the detection was happening at the wrong place in the code. We were detecting the swig version while *creating* the swig tasks, rather than while *executing* a swig task. This led to misleading output from rake. So I moved the code around a bit this morning. I think it's a lot better now. Kevin P.S. It wasn't anything wrong with Robin's recent changes. This problem had been there for months if not years. From wxruby at qualitycode.com Fri Aug 25 10:05:06 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Fri, 25 Aug 2006 10:05:06 -0400 Subject: [Wxruby-users] Simplifying swig typemaps (was: typemap.i patch) In-Reply-To: <44EE7CA3.5070902@mindspring.com> References: <44EE1F78.3070703@mindspring.com> <1156479367.18080.13.camel@localhost.localdomain> <44EE7CA3.5070902@mindspring.com> Message-ID: <1156514706.7474.8.camel@localhost.localdomain> On Fri, 2006-08-25 at 00:29 -0400, Roy Sutton wrote: > If there was something to make typemaps easier to read I'd be all over > it. Typemaps just drive me nuts. I feel like they're just black magic > sometimes. I feel like a really hacker when I work on them. I got this > from looking through the docs and included files. If you think a > comment would be helpful I think that's the only thing that would make > these better. The whole API for typemaps is horribly flawed. I wonder if we could hide at least some of it by auto-generating our typemap.i from ruby code. If we could declaratively say something like "wxList is the same as a Ruby Array", and "wxString is the same as a Ruby String", it could build all the necessary typemaps automatically. It could automatically handle all the const, reference&, and other cases. That would be another cool little pure ruby task for someone. If anyone wants to volunteer, let us know and we can probably write up a little spec. To start with, we would want to have a mix of automated typemaps and hand-coded. Over time, hopefully the hand-coded portion would approach, if not reach, emptyness. Kevin From alex at pressure.to Fri Aug 25 11:12:24 2006 From: alex at pressure.to (Alex Fenton) Date: Fri, 25 Aug 2006 16:12:24 +0100 Subject: [Wxruby-users] SWIG detection, revisited In-Reply-To: <1156514429.7474.3.camel@localhost.localdomain> References: <1156514429.7474.3.camel@localhost.localdomain> Message-ID: <44EF1358.7080409@pressure.to> Cool. I just added descriptions to the main rake tasks for SWIGging, compiling, installing and packaging. This means someone unfamiliar with the package can do rake --tasks to get a list of useful build targets & tasks for the project. Doesn't affect the tasks materially at all. cheers alex Kevin Smith wrote: > I did some testing this morning, and wasn't happy with the error > messages presented to the user if they didn't have the right SWIG > version. I realized that the detection was happening at the wrong place > in the code. > > We were detecting the swig version while *creating* the swig tasks, > rather than while *executing* a swig task. This led to misleading output > from rake. > > So I moved the code around a bit this morning. I think it's a lot better > now. > > Kevin > > P.S. It wasn't anything wrong with Robin's recent changes. This problem > had been there for months if not years. > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > From sean.m.long at gmail.com Fri Aug 25 11:59:37 2006 From: sean.m.long at gmail.com (Sean Long) Date: Fri, 25 Aug 2006 08:59:37 -0700 Subject: [Wxruby-users] Simplifying swig typemaps (was: typemap.i patch) In-Reply-To: <1156514706.7474.8.camel@localhost.localdomain> References: <44EE1F78.3070703@mindspring.com> <1156479367.18080.13.camel@localhost.localdomain> <44EE7CA3.5070902@mindspring.com> <1156514706.7474.8.camel@localhost.localdomain> Message-ID: That is a very good idea! I have always hatted the typemap voodoo, it is too easy to mess it up with one or two changes of a single character. I hope someone has the time to pursue this task, I would if I had the time. Sean On 8/25/06, Kevin Smith wrote: > On Fri, 2006-08-25 at 00:29 -0400, Roy Sutton wrote: > > If there was something to make typemaps easier to read I'd be all over > > it. Typemaps just drive me nuts. I feel like they're just black magic > > sometimes. I feel like a really hacker when I work on them. I got this > > from looking through the docs and included files. If you think a > > comment would be helpful I think that's the only thing that would make > > these better. > > The whole API for typemaps is horribly flawed. I wonder if we could hide > at least some of it by auto-generating our typemap.i from ruby code. If > we could declaratively say something like "wxList is the same as a Ruby > Array", and "wxString is the same as a Ruby String", it could build all > the necessary typemaps automatically. It could automatically handle all > the const, reference&, and other cases. > > That would be another cool little pure ruby task for someone. If anyone > wants to volunteer, let us know and we can probably write up a little > spec. > > To start with, we would want to have a mix of automated typemaps and > hand-coded. Over time, hopefully the hand-coded portion would approach, > if not reach, emptyness. > > Kevin > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > From alex at pressure.to Fri Aug 25 12:07:16 2006 From: alex at pressure.to (Alex Fenton) Date: Fri, 25 Aug 2006 17:07:16 +0100 Subject: [Wxruby-users] Intriguing developments In-Reply-To: <44EA88A8.70009@mindspring.com> References: <44EA88A8.70009@mindspring.com> Message-ID: <44EF2034.5040501@pressure.to> Roy Sutton wrote: > Non-debug build of wxRuby allows the tip of the day to be visible on > Windows. Interesting - this and other threads got me to try building a debug WxWidgets and compiling wxRuby against it. Turns out that doing so causes quite a lot of stuff to hang and not display, including tips, password and font dialogs. Weird. Definitely need to ensure we ship gems from release builds. a From alex at pressure.to Fri Aug 25 12:15:39 2006 From: alex at pressure.to (Alex Fenton) Date: Fri, 25 Aug 2006 17:15:39 +0100 Subject: [Wxruby-users] Intriguing developments In-Reply-To: <44EF2034.5040501@pressure.to> References: <44EA88A8.70009@mindspring.com> <44EF2034.5040501@pressure.to> Message-ID: <44EF222B.3040300@pressure.to> Alex Fenton wrote: > Definitely need to ensure we ship gems > from release builds. > Meant to submit the attached patch, to enable forcing use of a release build via rake, via rake RELEASE=1 Otherwise, I don't think there is a way to tell our compile system to build against a release wxWidgets, if the default wx-config happens to point to a debug one. alex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rakewx_rb.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060825/4145982c/attachment.pl From roys at mindspring.com Fri Aug 25 14:29:29 2006 From: roys at mindspring.com (Roy Sutton) Date: Fri, 25 Aug 2006 14:29:29 -0400 Subject: [Wxruby-users] wxCheckListBox.rbw patch file Message-ID: <44EF4189.5020504@mindspring.com> This fixes truncated text on the CheckListBox sample in bigdemo. Roy -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wxCheckListBox.rbw.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060825/2b6cc616/attachment.pl From wxruby at qualitycode.com Fri Aug 25 14:45:32 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Fri, 25 Aug 2006 14:45:32 -0400 Subject: [Wxruby-users] rakefile DEBUG changes Message-ID: <1156531533.7474.14.camel@localhost.localdomain> We use an environment variable to control whether or not to enable a debug build of wxRuby. This was called simply DEBUG but I have renamed it to WXRUBY_DEBUG. I also added a second environment variable, WXRUBY_VERBOSE, which turns on extensive console output that can help debug memory problems. It prints a message any time an object is created, destroyed, etc. This used to only be an option in rakelinux.rb, but I have moved it to rakewx.rb. It is possible that my changes will cause errors on other platforms, notably VC++ on MSWin. If you build on other platforms, please let me know whether it still works, or if you have problems. Kevin From alex at pressure.to Fri Aug 25 15:29:38 2006 From: alex at pressure.to (Alex Fenton) Date: Fri, 25 Aug 2006 20:29:38 +0100 Subject: [Wxruby-users] rakefile DEBUG changes In-Reply-To: <1156531533.7474.14.camel@localhost.localdomain> References: <1156531533.7474.14.camel@localhost.localdomain> Message-ID: <44EF4FA2.7010502@pressure.to> Kevin Smith wrote: > I also added a second environment variable, WXRUBY_VERBOSE, which turns > on extensive console output that can help debug memory problems. It > prints a message any time an object is created, destroyed, etc. This > used to only be an option in rakelinux.rb, but I have moved it to > rakewx.rb. Great, will give it a whirl. Does WXRUBY_VERBOSE require a debug build of WxWidgets? Also I think we still need to have an option to force a release build as I can't see how to build one otherwise, and debug is buggy on OS X at least. Also, since we mentioned ruby style of conditional statements, can I suggest not using redundant parens in simple conditionals like: 'if($verbose_debug)'? A space seems nicer to separate the keyword. Similarly with puts. Otherwise, that combined with avoiding 'unless' turns 'unless $foo' into a punctuation car-crash: 'if(!$foo)' which looks painfully C-ish/Perl-ish to me. :) alex From roys at mindspring.com Fri Aug 25 18:22:39 2006 From: roys at mindspring.com (Roy Sutton) Date: Fri, 25 Aug 2006 18:22:39 -0400 Subject: [Wxruby-users] Patches to ComboBox and ControlWithItems Message-ID: <44EF782F.9030904@mindspring.com> This patch fixes Append and Insert so they work with the void * argument. The typemap for this was fixed a long time ago, I guess these changes either never got uploaded by me or I hadn't gotten to these. Roy -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wxControlWithItems.h.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060825/6b263d81/attachment-0002.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wxComboBox.h.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060825/6b263d81/attachment-0003.pl From roys at mindspring.com Fri Aug 25 18:23:02 2006 From: roys at mindspring.com (Roy Sutton) Date: Fri, 25 Aug 2006 18:23:02 -0400 Subject: [Wxruby-users] Patch to wxComboBox.rbw Message-ID: <44EF7846.3080400@mindspring.com> This patch fixes the sample so it works correctly. You'll need to patches in the previous e-mail. Roy -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wxComboBox.rbw.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060825/f3c5f913/attachment.pl From roys at mindspring.com Fri Aug 25 18:41:49 2006 From: roys at mindspring.com (Roy Sutton) Date: Fri, 25 Aug 2006 18:41:49 -0400 Subject: [Wxruby-users] Patch to wxTextCtrl.rbw Message-ID: <44EF7CAD.4000300@mindspring.com> This patch enables the char event and changes the set and kill focus events to be attached to the correct items From alex at pressure.to Fri Aug 25 19:19:23 2006 From: alex at pressure.to (Alex Fenton) Date: Sat, 26 Aug 2006 00:19:23 +0100 Subject: [Wxruby-users] wxCheckListBox.rbw patch file In-Reply-To: <44EF4189.5020504@mindspring.com> References: <44EF4189.5020504@mindspring.com> Message-ID: <44EF857B.2030208@pressure.to> Committed, thanks Alex Roy Sutton wrote: > This fixes truncated text on the CheckListBox sample in bigdemo. > > Roy > ------------------------------------------------------------------------ > > > C:\RubyDev>cvs -d :pserver:anonymous at rubyforge.org:/var/cvs/wxruby login > Logging in to :pserver:anonymous at rubyforge.org:2401:/var/cvs/wxruby > > C:\RubyDev>cvs -d :pserver:anonymous at rubyforge.org:/var/cvs/wxruby diff -b -u wxruby2/samples/bigdemo/wxCheckListBox.rbw > Index: wxruby2/samples/bigdemo/wxCheckListBox.rbw > =================================================================== > RCS file: /var/cvs/wxruby/wxruby2/samples/bigdemo/wxCheckListBox.rbw,v > retrieving revision 1.3 > diff -b -u -r1.3 wxCheckListBox.rbw > --- wxruby2/samples/bigdemo/wxCheckListBox.rbw 6 Sep 2005 14:14:04 -0000 1.3 > +++ wxruby2/samples/bigdemo/wxCheckListBox.rbw 25 Aug 2006 17:47:26 -0000 > @@ -7,7 +7,7 @@ > > sampleList = %w(one two three four five six seven eight nine ten eleven twelve thirteen fourteen) > > - Wx::StaticText.new(self, -1, "This example uses the wxCheckListBox control.", Wx::DEFAULT_POSITION, Wx::Size.new(45,15)) > + Wx::StaticText.new(self, -1, "This example uses the wxCheckListBox control.", Wx::DEFAULT_POSITION, Wx::DEFAULT_SIZE) > > lb = Wx::CheckListBox.new(self, 60, Wx::Point.new(80,50), Wx::Size.new(80,120), sampleList) > evt_listbox(60) {|event| on_evt_listbox(event)} > > ------------------------------------------------------------------------ > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users From alex at pressure.to Fri Aug 25 19:22:38 2006 From: alex at pressure.to (Alex Fenton) Date: Sat, 26 Aug 2006 00:22:38 +0100 Subject: [Wxruby-users] Patch to wxTextCtrl.rbw In-Reply-To: <44EF7CAD.4000300@mindspring.com> References: <44EF7CAD.4000300@mindspring.com> Message-ID: <44EF863D.40503@pressure.to> Hi Roy Sorry, didn't see an attachment? thanks alex Roy Sutton wrote: > This patch enables the char event and changes the set and kill focus > events to be attached to the correct items > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > From roys at mindspring.com Fri Aug 25 19:27:22 2006 From: roys at mindspring.com (Roy Sutton) Date: Fri, 25 Aug 2006 19:27:22 -0400 Subject: [Wxruby-users] wxPython/wxRuby Message-ID: <44EF875A.7060307@mindspring.com> I've downloaded wxPython and the demos and am trying to update our bigdemo. I can see some big differences in how wxRuby and wxPython interact on Windows. Our layout seems wrong. For example, I never knew the textctrl sample had more than two controls on it! I only ever saw the two. In the python version, the controls lay out close together. Secondly, on the ComboBox sample the drop-down box is the correct size (about 5-6 items). For me with wxRuby I only see one item at a time. I've been meaning to track that down but just haven't had time yet. I tried debugging the crash you consistently get with the MDI sample but I gave up after I traced it to a Windows function. Sadly, MDI -used- to work. Hopefully it's an easy fix. Roy P.S. It told me I had chinese characters the first time I sent this! From roys at mindspring.com Fri Aug 25 19:28:56 2006 From: roys at mindspring.com (Roy Sutton) Date: Fri, 25 Aug 2006 19:28:56 -0400 Subject: [Wxruby-users] Patch to wxTextCtrl.rbw In-Reply-To: <44EF863D.40503@pressure.to> References: <44EF7CAD.4000300@mindspring.com> <44EF863D.40503@pressure.to> Message-ID: <44EF87B8.6030506@mindspring.com> Oops? Alex Fenton wrote: > Hi Roy > > Sorry, didn't see an attachment? > > thanks > alex > > Roy Sutton wrote: > >> This patch enables the char event and changes the set and kill focus >> events to be attached to the correct items >> _______________________________________________ >> wxruby-users mailing list >> wxruby-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wxruby-users >> >> >> >> > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wxTextCtrl.rb.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060825/90457e38/attachment.pl From wxruby at qualitycode.com Fri Aug 25 19:36:03 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Fri, 25 Aug 2006 19:36:03 -0400 Subject: [Wxruby-users] Minimal.rb crashes on exit In-Reply-To: <1156483593.6260.41.camel@localhost.localdomain> References: <1155496758.11659.122.camel@localhost.localdomain> <1155871140.30640.9.camel@localhost.localdomain> <44E5536C.8010403@pressure.to> <1156126147.2953.18.camel@localhost.localdomain> <44E92461.9050204@mindspring.com> <1156133536.6413.12.camel@localhost.localdomain> <44EC5A3A.1070008@mindspring.com> <1156342734.5809.5.camel@localhost.localdomain> <44EC97E0.6030605@mindspring.com> <1156368156.1950.28.camel@localhost.localdomain> <44EE80DE.30402@mindspring.com> <1156483593.6260.41.camel@localhost.localdomain> Message-ID: <1156548963.7474.23.camel@localhost.localdomain> On Fri, 2006-08-25 at 01:26 -0400, Kevin Smith wrote: > During the main frame destructor, every bit of data I could find looked > correct. However, a call to a virtual method crashed because it was > calling to a bad (non-code) address. It seemed like the vtable of > virtual method pointers had been trashed somehow. Based on the extensive > debug output (I had wxDEBUG defined), it sure didn't look like a > double-free problem. Turns out the problem is simpler...and more complex...than this. If anyone here is really familiar with C++ wxWidgets, please speak up! For Help/About, we create a MessageDialog, and call show_modal on it. When that dialog is closed (with the OK button), the underlying GTK widget is automatically destroyed, and the m_widget member of the dialog is set to NULL. But the dialog itself is not deleted. Ok. When the app terminates, the main window is deleted. Fine. But *after that*, the MessageDialog object is deleted. At one point, the code checks m_parent->GetDefaultItem(). But m_parent is still the main Frame object, which has been deleted, leading to a segfault. So I tried forcing the MessageDialog to be deleted right away. I tried calling destroy() and close(), but both of them fail by throwing an assert (in a DEBUG build) because you can't call destroy() or close() if m_widget is null. Which it is. So at this point, I can't see a solution. At least this particular crash is not a ruby garbage collection problem. It's not a double-free. It's a sequence problem, and I can't see how to solve it. The puzzling thing is that the docs for C++ wxWidgets repeatedly say you are supposed to call Destroy after ShowModal on a dialog. That's the equivalent of what I'm doing in wxRuby, and it's not working. Elsewhere on the wxWidgets site they say to favor Close over Destroy in that case, but that doesn't work for me either. I guess I'll have to write a C++ sample to try to figure out why the wxRuby case is different. At the moment, it looks like a couple bad asserts in wxWidgets. Kevin From alex at pressure.to Fri Aug 25 19:44:51 2006 From: alex at pressure.to (Alex Fenton) Date: Sat, 26 Aug 2006 00:44:51 +0100 Subject: [Wxruby-users] Patch to wxComboBox.rbw In-Reply-To: <44EF7846.3080400@mindspring.com> References: <44EF7846.3080400@mindspring.com> Message-ID: <44EF8B73.9070001@pressure.to> Committed, thank you, along with header file patches in prev email. Should I be seeing kill_focus and set_focus events when I run the ComboBox part fo the bigdemo? Alex Roy Sutton wrote: > This patch fixes the sample so it works correctly. You'll need to > patches in the previous e-mail. > > Roy > ------------------------------------------------------------------------ > > > C:\RubyDev>cvs -d :pserver:anonymous at rubyforge.org:/var/cvs/wxruby login > Logging in to :pserver:anonymous at rubyforge.org:2401:/var/cvs/wxruby > > C:\RubyDev>cvs -d :pserver:anonymous at rubyforge.org:/var/cvs/wxruby diff -b -u wxruby2/samples/bigdemo/wxComboBox.rbw > Index: wxruby2/samples/bigdemo/wxComboBox.rbw > =================================================================== > RCS file: /var/cvs/wxruby/wxruby2/samples/bigdemo/wxComboBox.rbw,v > retrieving revision 1.2 > diff -b -u -r1.2 wxComboBox.rbw > --- wxruby2/samples/bigdemo/wxComboBox.rbw 6 Sep 2005 14:14:04 -0000 1.2 > +++ wxruby2/samples/bigdemo/wxComboBox.rbw 25 Aug 2006 22:19:01 -0000 > @@ -9,15 +9,15 @@ > > Wx::StaticText.new(self, -1, "This example uses the wxComboBox control.", Wx::Point.new(8,10)) > > - Wx::StaticText.new(self, -1, "Select one:", Wx::Point.new(15,50), Wx::Size.new(75,18)) > - cb = Wx::ComboBox.new(self, 500, "default value", Wx::Point.new(90,50), Wx::Size.new(95,-1), > + Wx::StaticText.new(self, -1, "Select one:", Wx::Point.new(15,50)) > + cb = Wx::ComboBox.new(self, 500, "default value", Wx::Point.new(90,50), Wx::DEFAULT_SIZE, > sampleList, Wx::CB_DROPDOWN) > > evt_combobox(cb.get_id()) {|event| on_combobox(event)} > evt_text(cb.get_id()) {|event| on_evt_text(event)} > evt_text_enter(cb.get_id()) {|event| on_evt_text_enter(event)} > - #evt_set_focus(cb.get_id()) {|event| on_set_focus(event)} > - #evt_kill_focus(cb.get_id()) {|event| on_kill_focus(event)} > + cb.evt_set_focus {|event| on_set_focus(event)} > + cb.evt_kill_focus {|event| on_kill_focus(event)} > > cb.append("foo", "This is some client data for this item") > > @@ -33,16 +33,16 @@ > end > > def on_evt_text_enter(event) > - @log.write_text("evt_text_enter: does this work?") > + @log.write_text("evt_text_enter: " + event.get_string()) > end > > def on_set_focus(evt) > - log.write("OnSetFocus") > + @log.write_text("OnSetFocus") > evt.skip() > end > > def on_kill_focus(evt) > - log.write("OnKillFocus") > + @log.write_text("OnKillFocus") > evt.skip() > end > end > > ------------------------------------------------------------------------ > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users From alex at pressure.to Fri Aug 25 19:53:23 2006 From: alex at pressure.to (Alex Fenton) Date: Sat, 26 Aug 2006 00:53:23 +0100 Subject: [Wxruby-users] Patch to wxTextCtrl.rbw In-Reply-To: <44EF87B8.6030506@mindspring.com> References: <44EF7CAD.4000300@mindspring.com> <44EF863D.40503@pressure.to> <44EF87B8.6030506@mindspring.com> Message-ID: <44EF8D73.9020106@pressure.to> Applied, thanks. Alex Roy Sutton wrote: > Oops? > > Alex Fenton wrote: >> Hi Roy >> >> Sorry, didn't see an attachment? >> >> thanks >> alex >> >> Roy Sutton wrote: >> >>> This patch enables the char event and changes the set and kill focus >>> events to be attached to the correct items >>> _______________________________________________ >>> wxruby-users mailing list >>> wxruby-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wxruby-users >>> From wxruby at qualitycode.com Fri Aug 25 19:59:15 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Fri, 25 Aug 2006 19:59:15 -0400 Subject: [Wxruby-users] rakefile DEBUG changes In-Reply-To: <44EF4FA2.7010502@pressure.to> References: <1156531533.7474.14.camel@localhost.localdomain> <44EF4FA2.7010502@pressure.to> Message-ID: <1156550356.7474.32.camel@localhost.localdomain> On Fri, 2006-08-25 at 20:29 +0100, Alex Fenton wrote: > Kevin Smith wrote: > Great, will give it a whirl. Does WXRUBY_VERBOSE require a debug build > of WxWidgets? > Also I think we still need to have an option to force a > release build as I can't see how to build one otherwise, and debug is > buggy on OS X at least. I agree. But I believe the DEBUG version is behaving properly, and the release build is merely glossing over lots of errors. > Also, since we mentioned ruby style of conditional statements, can I > suggest not using redundant parens in simple conditionals like: > 'if($verbose_debug)'? A space seems nicer to separate the keyword. > Similarly with puts. > > Otherwise, that combined with avoiding 'unless' turns 'unless $foo' into > a punctuation car-crash: 'if(!$foo)' which looks painfully > C-ish/Perl-ish to me. Oddly, I hate perl but don't mind C++ that much. So my style tends to look a lot like C/C++/Java code. There is one somewhat compelling argument for putting parens in everywhere: Ruby sometimes gets confused without them. I forget what that case is, and instead of trying to remember it, I find it easier (and less ambiguous) to just always include parens if there are parameters. So my proposal would be that our coding standard call for parens everywhere except the empty case (). But I can be flexible if you or others really feel strongly about it. In the case you cite, would using "not" help you feel better about it? if(not $foo) Thanks, Kevin From wxruby at qualitycode.com Fri Aug 25 20:09:04 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Fri, 25 Aug 2006 20:09:04 -0400 Subject: [Wxruby-users] Intriguing developments In-Reply-To: <44EF222B.3040300@pressure.to> References: <44EA88A8.70009@mindspring.com> <44EF2034.5040501@pressure.to> <44EF222B.3040300@pressure.to> Message-ID: <1156550944.7474.34.camel@localhost.localdomain> On Fri, 2006-08-25 at 17:15 +0100, Alex Fenton wrote: > Alex Fenton wrote: > > Definitely need to ensure we ship gems > > from release builds. I have mixed feelings about that, because it is really just hiding actual problems. But for now, it's ok. > Meant to submit the attached patch, to enable forcing use of a release > build via rake, via > > rake RELEASE=1 I see you changed this to WXRUBY_RELEASE, which is good. I like the idea, but your patch wouldn't actually force a RELEASE build if DEBUG was the default (as it is on my system). So I made a few further changes and checked it in. Thanks, Kevin From roys at mindspring.com Fri Aug 25 20:28:50 2006 From: roys at mindspring.com (Roy Sutton) Date: Fri, 25 Aug 2006 20:28:50 -0400 Subject: [Wxruby-users] Patch to wxComboBox.rbw In-Reply-To: <44EF8B73.9070001@pressure.to> References: <44EF7846.3080400@mindspring.com> <44EF8B73.9070001@pressure.to> Message-ID: <44EF95C2.203@mindspring.com> Alex Fenton wrote: > Should I be seeing kill_focus and set_focus events when I run the > ComboBox part fo the bigdemo? > > You should when you click in it and click outside it. From wxruby at qualitycode.com Fri Aug 25 22:52:33 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Fri, 25 Aug 2006 22:52:33 -0400 Subject: [Wxruby-users] Minimal.rb crashes on exit [SOLVED] In-Reply-To: <1156548963.7474.23.camel@localhost.localdomain> References: <1155496758.11659.122.camel@localhost.localdomain> <1155871140.30640.9.camel@localhost.localdomain> <44E5536C.8010403@pressure.to> <1156126147.2953.18.camel@localhost.localdomain> <44E92461.9050204@mindspring.com> <1156133536.6413.12.camel@localhost.localdomain> <44EC5A3A.1070008@mindspring.com> <1156342734.5809.5.camel@localhost.localdomain> <44EC97E0.6030605@mindspring.com> <1156368156.1950.28.camel@localhost.localdomain> <44EE80DE.30402@mindspring.com> <1156483593.6260.41.camel@localhost.localdomain> <1156548963.7474.23.camel@localhost.localdomain> Message-ID: <1156560753.19081.8.camel@localhost.localdomain> On Fri, 2006-08-25 at 19:36 -0400, Kevin Smith wrote: > For Help/About, we create a MessageDialog, and call show_modal on it. > When that dialog is closed (with the OK button), the underlying GTK > widget is automatically destroyed, and the m_widget member of the dialog > is set to NULL. But the dialog itself is not deleted. Ok. Great news! I fixed the bug. Turns out the fix was relatively simple, although it does have some significant effects (see the ***NOTE*** items below). We had declared Dialog to have a superclass of Window, but at least on my platform, it actually extends TopLevelWindow. Because we had it wrong, calls to Dialog#destroy were being routed incorrectly, leading to the asserts I was puzzled by. After fixing the inheritance, I also had to fix the minimal.rb sample to clean up its MessageDialog right away. After coming back from show_modal, you must call MessageDialog#destroy. Otherwise, the dialog may remain in memory until after the main frame has been deleted, and you will get a segfault on app exit. ***NOTE*** This means that ALL the samples need to be updated to call destroy on any dialogs that get created. ***NOTE*** My fix may not work on all platforms. I believe it will, but there is a chance you might get a compile error. If so, we'll have to figure out how to work around it. ***NOTE*** On my platform (and I believe on the others as well), Dialog actually extends DialogBase, which extends TopLevelWindow. There don't seem to be any virtual methods in DialogBase, so for now we don't have to expose it. However, I believe in the long run it would be safer to do so. It's frustrating that it took me so long to diagnose a relatively simple problem. I have been hit by this before, so for all future bugs one of the first things I will look at is the full inheritance chain. Kevin From wxruby at qualitycode.com Fri Aug 25 23:47:01 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Fri, 25 Aug 2006 23:47:01 -0400 Subject: [Wxruby-users] Progress on crashing Message-ID: <1156564021.19081.17.camel@localhost.localdomain> I'm using my SpaceMonkeys game as a testbed to try to get rid of crashing problems. Earlier today, it would crash for me almost immediately, every time. Now, I was able to get about 50 turns into the game! I mentioned the first big change in a different email. The new change I just checked in was to add the DISOWN flag to Window#set_sizer. This is the first time (that I know of) that we are really taking advantage of the new SWIG 1.3.29 memory handling features. When a sizer is created in ruby, SWIG assumes that ruby owns it and will eventually delete it. But when you pass it to Window#set_sizer, wx now assumes IT has ownership, and it will in fact delete it. Later, when ruby collects its garbage, SWIG attempts to delete the sizer that was already deleted...crash! The DISOWN flag tells SWIG that wx is now responsible for deleting the object. Whether the ruby object is garbage collected first, or the wx object is deleted first, neither will cause problems for the other. There are a LOT of methods that will have to be decorated with ownership annotations. But now that I see how it works, and I am starting to better understand the debugging output, I hope progress can be pretty rapid. For those of you who have been helping write and update .i files, please take a look at swig/classes/include/wxWindow.h and see what I did around SetSizer. I tried to find a way to do that in the .i file instead of the .h file, but nothing I tried worked. If any of you can find a way to do it in the .i file, that would be great! You can tell it had an effect by looking in the generated src/Window.cpp and seeing the SWIG_POINTER_DISOWN flag in the _wrap_wxWindow_SetSizer function. I'm feeling better about the upcoming release. Cheers, Kevin From wxruby at qualitycode.com Fri Aug 25 23:56:18 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Fri, 25 Aug 2006 23:56:18 -0400 Subject: [Wxruby-users] Progress on crashing In-Reply-To: <1156564021.19081.17.camel@localhost.localdomain> References: <1156564021.19081.17.camel@localhost.localdomain> Message-ID: <1156564578.19081.22.camel@localhost.localdomain> On Fri, 2006-08-25 at 23:47 -0400, Kevin Smith wrote: > I mentioned the first big change in a different email. The new change I > just checked in was to add the DISOWN flag to Window#set_sizer. This is > the first time (that I know of) that we are really taking advantage of > the new SWIG 1.3.29 memory handling features. Of course, Roy already added DISOWN for menubars back in April! Ok, so I'm only a few months behind! His implementation was in the .i file, as I had wanted, so I have changed Window to be the same way. It happens that for all the Window methods that accept wxSizer's as parameters, those sizers become owned by the Window. So it works great. We may not always be so lucky. Thanks Roy! Kevin From roys at mindspring.com Sat Aug 26 00:42:43 2006 From: roys at mindspring.com (Roy Sutton) Date: Sat, 26 Aug 2006 00:42:43 -0400 Subject: [Wxruby-users] Progress on crashing In-Reply-To: <1156564578.19081.22.camel@localhost.localdomain> References: <1156564021.19081.17.camel@localhost.localdomain> <1156564578.19081.22.camel@localhost.localdomain> Message-ID: <44EFD143.1060906@mindspring.com> Kevin, Great work! That was next on my list of things to do. I'm cleaning up problems in the inheritance chain in wxDialog. I'm trying to fix bigdemo as best I can. Roy Kevin Smith wrote: > On Fri, 2006-08-25 at 23:47 -0400, Kevin Smith wrote: > >> I mentioned the first big change in a different email. The new change I >> just checked in was to add the DISOWN flag to Window#set_sizer. This is >> the first time (that I know of) that we are really taking advantage of >> the new SWIG 1.3.29 memory handling features. >> > > Of course, Roy already added DISOWN for menubars back in April! Ok, so > I'm only a few months behind! > > His implementation was in the .i file, as I had wanted, so I have > changed Window to be the same way. It happens that for all the Window > methods that accept wxSizer's as parameters, those sizers become owned > by the Window. So it works great. We may not always be so lucky. > > Thanks Roy! > > Kevin > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > From roys at mindspring.com Sat Aug 26 00:49:30 2006 From: roys at mindspring.com (Roy Sutton) Date: Sat, 26 Aug 2006 00:49:30 -0400 Subject: [Wxruby-users] Typemap simplification Message-ID: <44EFD2DA.90100@mindspring.com> One way we might simplify our lives is to modify the .h files so they're SWIG friendly. I think I mentioned this before but I'll bring it up again. Take the following for example: void MyFunc( int *x, int *y ) const You can't tell looking at this function whether x and y are inputs, outputs or both (Well, you might can assume they're not input only). If we slightly modify the header files: void MyFunc( int *INOUTx, int *INOUTy ) const Then it's really obvious -and- we can make a typemap that sucks those up easily. The real bear for us is when two functions in a header file treat the pointers differently: void MyFunc( int * x, int * y ) const // In/Out void MyFunc2( int *x, int *y ) const // Out only These two would be about impossible to wrap using our current SWIG knowledge. The other alternative is to put SWIG directives directly into the .h files. Thoughts? Roy From alex at pressure.to Sat Aug 26 03:20:02 2006 From: alex at pressure.to (Alex Fenton) Date: Sat, 26 Aug 2006 08:20:02 +0100 Subject: [Wxruby-users] Patch to wxComboBox.rbw In-Reply-To: <44EF95C2.203@mindspring.com> References: <44EF7846.3080400@mindspring.com> <44EF8B73.9070001@pressure.to> <44EF95C2.203@mindspring.com> Message-ID: <44EFF622.9010700@pressure.to> Roy Sutton wrote: >> Should I be seeing kill_focus and set_focus events when I run the >> ComboBox part fo the bigdemo? >> > You should when you click in it and click outside it > OK, have looked again, doesn't seem to be working for ComboBox but FocusEvents fire correctly from other classes (TextCtrl, Panel) etc. Have logged as an OS X bug. alex From alex at pressure.to Sat Aug 26 03:53:31 2006 From: alex at pressure.to (Alex Fenton) Date: Sat, 26 Aug 2006 08:53:31 +0100 Subject: [Wxruby-users] Events.i vs. events.rb In-Reply-To: <1155698660.8694.20.camel@localhost.localdomain> References: <44C66F5F.6040106@pressure.to> <1155479031.11659.20.camel@localhost.localdomain> <44E26958.4050100@pressure.to> <1155698660.8694.20.camel@localhost.localdomain> Message-ID: <44EFFDFB.9080706@pressure.to> Kevin Smith wrote: > I believe that is true, but have not yet tested it myself. It would be > great if someone could try ripping them all out and see if they still > get generated in src/Event.cpp. > Tested removing the duplicate evt handler C++ methods and ruby method declarations from Events.i; the SWIG output in Events.cpp and Event.cpp is unchanged. So here's a patch to remove the unneeded material. cheers alex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Events_i.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060826/f8e12818/attachment-0001.ksh From alex at pressure.to Sat Aug 26 08:22:31 2006 From: alex at pressure.to (Alex Fenton) Date: Sat, 26 Aug 2006 13:22:31 +0100 Subject: [Wxruby-users] Progress on crashing In-Reply-To: <1156564021.19081.17.camel@localhost.localdomain> References: <1156564021.19081.17.camel@localhost.localdomain> Message-ID: <44F03D07.5000507@pressure.to> Kevin Smith wrote: > I'm using my SpaceMonkeys game as a testbed to try to get rid of > crashing problems. Earlier today, it would crash for me almost > immediately, every time. Now, I was able to get about 50 turns into the > game! > sounds like and Roy are making real progress with SWIG. I agree the typemaps API is horrible. If stability is a lot better on Linux, maybe a good time to go for a release? Looking better on OS X, generally, mostly crashes on specific methods. cheers alex From roys at mindspring.com Sat Aug 26 15:56:50 2006 From: roys at mindspring.com (Roy Sutton) Date: Sat, 26 Aug 2006 15:56:50 -0400 Subject: [Wxruby-users] TextCtrl Background (was: TreeCtrl background?) In-Reply-To: <44ED2EB1.5000202@roadq.com> References: <44ED2EB1.5000202@roadq.com> Message-ID: <44F0A782.1040302@mindspring.com> Mark Ping wrote: > On my windows build, I just noticed that the background of my TextCtrl's > is grey by default, and when I try to set the default style I get the error: > > You know, I just noticed that they were grey as well. They should be the system default and I think it's been a recent change that caused this. Furthermore, the Dialog demo shows another error besides the grey background. The tab stops aren't working correctly. Labels shouldn't be tab stops. Roy From roys at mindspring.com Sat Aug 26 16:04:15 2006 From: roys at mindspring.com (Roy Sutton) Date: Sat, 26 Aug 2006 16:04:15 -0400 Subject: [Wxruby-users] TextCtrl Background In-Reply-To: <44F0A782.1040302@mindspring.com> References: <44ED2EB1.5000202@roadq.com> <44F0A782.1040302@mindspring.com> Message-ID: <44F0A93F.3090600@mindspring.com> I can confirm that the tab stops and the background color used to work on previous builds. I had an old .so file sitting around and I tried it out. Roy Roy Sutton wrote: > Mark Ping wrote: > >> On my windows build, I just noticed that the background of my TextCtrl's >> is grey by default, and when I try to set the default style I get the error: >> >> >> > You know, I just noticed that they were grey as well. They should be > the system default and I think it's been a recent change that caused this. > > Furthermore, the Dialog demo shows another error besides the grey > background. The tab stops aren't working correctly. Labels shouldn't > be tab stops. > > Roy > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > From wxruby at qualitycode.com Sat Aug 26 21:06:42 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sat, 26 Aug 2006 21:06:42 -0400 Subject: [Wxruby-users] wxPython/wxRuby In-Reply-To: <44EF875A.7060307@mindspring.com> References: <44EF875A.7060307@mindspring.com> Message-ID: <1156640802.17206.50.camel@localhost.localdomain> On Fri, 2006-08-25 at 19:27 -0400, Roy Sutton wrote: > I've downloaded wxPython and the demos and am trying to update our > bigdemo. I can see some big differences in how wxRuby and wxPython > interact on Windows. Our layout seems wrong. For example, I never > knew the textctrl sample had more than two controls on it! I only ever > saw the two. Wow. Same here. Look at all those other controls! > In the python version, the controls lay out close > together. Secondly, on the ComboBox sample the drop-down box is the > correct size (about 5-6 items). For me with wxRuby I only see one item > at a time. I've been meaning to track that down but just haven't had > time yet. It looks like our controls are each given equal height, rather than each only taking the height they require. At a minimum, we could put the whole thing in a scrolling pane. > P.S. It told me I had chinese characters the first time I sent this! You too, eh? And like when it happened to me, there didn't seem to be any characters even remotely non-ascii. Very weird. Kevin From wxruby at qualitycode.com Sat Aug 26 21:11:15 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sat, 26 Aug 2006 21:11:15 -0400 Subject: [Wxruby-users] Typemap simplification In-Reply-To: <44EFD2DA.90100@mindspring.com> References: <44EFD2DA.90100@mindspring.com> Message-ID: <1156641075.17206.55.camel@localhost.localdomain> On Sat, 2006-08-26 at 00:49 -0400, Roy Sutton wrote: > void MyFunc( int *INOUTx, int *INOUTy ) const > > Then it's really obvious -and- we can make a typemap that sucks those up > easily. True. Ugly but clear. Of course, we don't actually care about (int*) parameters, but your point is valid for all kinds of objects. > The real bear for us is when two functions in a header file treat the > pointers differently: > > void MyFunc( int * x, int * y ) const // In/Out > void MyFunc2( int *x, int *y ) const // Out only > > These two would be about impossible to wrap using our current SWIG > knowledge. You didn't actually say it, but I believe what you are saying is that if we did the renaming you propose above, then we could handle those cases easily. > The other alternative is to put SWIG directives directly > into the .h files. I had hoped to keep the .h files "pure", but I have to keep in mind my motivations for doing so: To make them reusable by other wx wrapping projects who use swig. By that logic, if we put all the non-language-specific swig stuff in the .h files, it would make it easier for other projects. I guess I would like to try a non-trivial .h file or two, using a couple different approaches to see which feels better. Kevin From wxruby at qualitycode.com Sat Aug 26 21:13:42 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sat, 26 Aug 2006 21:13:42 -0400 Subject: [Wxruby-users] Progress on crashing In-Reply-To: <44F03D07.5000507@pressure.to> References: <1156564021.19081.17.camel@localhost.localdomain> <44F03D07.5000507@pressure.to> Message-ID: <1156641222.17206.59.camel@localhost.localdomain> On Sat, 2006-08-26 at 13:22 +0100, Alex Fenton wrote: > If stability is a lot better on Linux, maybe a > good time to go for a release? Looking better on OS X, generally, mostly > crashes on specific methods. If we can decide on a gem version number, I'm ok to do a release quickly. I'm also ok waiting a few more days as patches continue to flow in. Either way, there are a couple "showstoppers" before release, which are sample copyrights (which I can do), and documenting as many specific known problems as possible. Kevin From wxruby at qualitycode.com Sat Aug 26 22:23:22 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sat, 26 Aug 2006 22:23:22 -0400 Subject: [Wxruby-users] Events.i vs. events.rb In-Reply-To: <44EFFDFB.9080706@pressure.to> References: <44C66F5F.6040106@pressure.to> <1155479031.11659.20.camel@localhost.localdomain> <44E26958.4050100@pressure.to> <1155698660.8694.20.camel@localhost.localdomain> <44EFFDFB.9080706@pressure.to> Message-ID: <1156645402.17206.76.camel@localhost.localdomain> On Sat, 2006-08-26 at 08:53 +0100, Alex Fenton wrote: > Kevin Smith wrote: > Tested removing the duplicate evt handler C++ methods and ruby method > declarations from Events.i; the SWIG output in Events.cpp and Event.cpp > is unchanged. So here's a patch to remove the unneeded material. Awesome. Instead of just #if'ing the code out, I deleted it. That's what version control software is for :-) Thanks! Kevin From wxruby at qualitycode.com Sat Aug 26 22:46:33 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sat, 26 Aug 2006 22:46:33 -0400 Subject: [Wxruby-users] Licensing issues Message-ID: <1156646793.17206.85.camel@localhost.localdomain> I was trying to figure out a license for the samples, and stumbled across a couple other issues that affect how we should be building wxWidgets for inclusion into our gem. If possible, we should NOT build in TIFF nor JPEG support, as both have special attribution requirements. Other wx modules do as well, but we don't use them anyway (ODBC, wxXML, and wx 2.4 regex). For those of you who will be building our gems on Mac and MS Windows, please check to see if you can build without built-in TIFF and JPEG support. If you need to build those in, we need to mention that in our README file. Let me know. Now, for the sample license: Public domain really isn't appropriate, partly because it is not valid in many countries. Here is my proposal: -------------------------- wxRuby2 Sample Code Copyright (c) 2004-2006 Kevin B. Smith Permission is hereby granted, free of charge, to any person obtaining a copy of this software, to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of any portion of this Software, and to permit persons to whom the Software is furnished to do so. This copyright notice need not be retained in any derived work. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -------------------------- Kevin From roys at mindspring.com Sat Aug 26 23:56:50 2006 From: roys at mindspring.com (Roy Sutton) Date: Sat, 26 Aug 2006 23:56:50 -0400 Subject: [Wxruby-users] wxWindow.h Message-ID: <44F11802.3040706@mindspring.com> I have basically spent a full day's worth of time I could have spent working on something productive trying to figure out which function signature I changed that is causing wxRuby to crash. It just takes so long to recompile this from scratch and without dependencies you kind of have to when you change wxWindow.h. I updated a lot of signatures to match the wxWindows header file. So frustrated.... From alex at pressure.to Sun Aug 27 08:16:18 2006 From: alex at pressure.to (Alex Fenton) Date: Sun, 27 Aug 2006 13:16:18 +0100 Subject: [Wxruby-users] Progress on crashing In-Reply-To: <1156641222.17206.59.camel@localhost.localdomain> References: <1156564021.19081.17.camel@localhost.localdomain> <44F03D07.5000507@pressure.to> <1156641222.17206.59.camel@localhost.localdomain> Message-ID: <44F18D12.3080201@pressure.to> Kevin Smith wrote: > If we can decide on a gem version number, I'm ok to do a release > quickly. I'm also ok waiting a few more days as patches continue to flow > in. > I like your suggestion of wxruby2-preview-0.x.x for an alpha series, then bumping to 0.9.0 or 1.9.0 when we get to beta quality and (for 0.9.0 at least) wxruby 0.6.0 backwards compatibility. The pseudo-gem thing should work if needed to force people to move onto a new series. We can use the 'extensions' option to run an executable when the gem installs, which would warn about the need to upgrade and how to do it (and perhaps to uninstall the old preview gem or gems - looking at the way Rubygems searches for libs to load this might be required - but again should be a single command). > Either way, there are a couple "showstoppers" before release, which are > sample copyrights (which I can do), and documenting as many specific > known problems as possible. Sounds good - where to document the known problems that aren't going to be fixed for this release? alex From alex at pressure.to Sun Aug 27 08:19:29 2006 From: alex at pressure.to (Alex Fenton) Date: Sun, 27 Aug 2006 13:19:29 +0100 Subject: [Wxruby-users] Licensing issues In-Reply-To: <1156646793.17206.85.camel@localhost.localdomain> References: <1156646793.17206.85.camel@localhost.localdomain> Message-ID: <44F18DD1.9060507@pressure.to> Kevin Smith wrote: > I was trying to figure out a license for the samples, and stumbled > across a couple other issues that affect how we should be building > wxWidgets for inclusion into our gem. > Thanks for investigating this. > If possible, we should NOT build in TIFF nor JPEG support, as both have > special attribution requirements. I would be very sad to lose JPEG support - I am using this feature already, and I can see it being something others would want (eg to make a photo browser). Looking at the relevant docs we only have to add an attribution line somewhere in our docs; there is no need to modify our licence terms. We don't redistribute any of their source (I don't think our include/wxBitmap.h nor just defining BITMAP_TYPE_JPEG are derivative works) so the short attribution could be used, as required for redist in binary form. TIFF is a less widespread format but again I would rather not lose it - so far as I can tell a slightly longer attribution is all that's required. > Other wx modules do as well, but we > don't use them anyway (ODBC, wxXML, and wx 2.4 regex). > wxXML is a dependency for using XRC Resoures, I think - if you try configuring WxWidgets --without-expat it warns that XRC will be disabled. I don't use XRC but seems like a feature we don't want to lose (eg for use with GUI designers). My reading of the MIT licence (http://en.wikipedia.org/wiki/MIT_License) covering expat is that only an attribution is required. > For those of you who will be building our gems on Mac and MS Windows, > please check to see if you can build without built-in TIFF and JPEG > support. If you need to build those in, we need to mention that in our > README file. Let me know. > Can do, but see above. > Now, for the sample license: Public domain really isn't appropriate, > partly because it is not valid in many countries. Here is my proposal: > Looks good, thanks again for your work on this. Alex From alex at pressure.to Sun Aug 27 09:44:30 2006 From: alex at pressure.to (Alex Fenton) Date: Sun, 27 Aug 2006 14:44:30 +0100 Subject: [Wxruby-users] gem version numbering In-Reply-To: <1156458263.5356.59.camel@localhost.localdomain> References: <1156126936.2953.28.camel@localhost.localdomain> <44EA047D.9080303@pressure.to> <1156278150.5712.36.camel@localhost.localdomain> <1156342499.5809.1.camel@localhost.localdomain> <1156428571.6260.10.camel@localhost.localdomain> <44EDED2C.1040103@mindspring.com> <1156458263.5356.59.camel@localhost.localdomain> Message-ID: <44F1A1BE.9040907@pressure.to> Kevin Smith wrote: > First, if the tried to upgrade their wxruby2-preview gem, maybe we could > replace it with a dummy gem that somehow told them they need to switch > to the wxruby gem series? > Yes, this would work. > Second, if someone just tried to install wxruby when they already had > wxruby2 installed, what would happen? Would gem detect the conflict? > What error message would it give? Just tested out creating a gem that checks for conflicting previously installed gem versions. It checks, warns with instructions on how to uninstall, and aborts. Looks like it will work for us if we want to pursue this path - we just add something along the lines of the script below to gemspec.extensions. It will be easier if we can have a constant defined that gives the version of the library eg Wx::WXRUBY_VERSION, and perhaps Wx::WXRUBY2 (just defined or not) or Wx::WXRUBY_PREVIEW_VERSION to distinguish the alpha series from the newer ones that will replace it. a ------ require 'rubygems' begin require 'wx' # test if the currently installed version is from preview series # if Wx::WXRUBY2 warn "************************************************" warn "Cannot install because an old version is present" warn "Please uninstall first using the command:" warn "# gem uninstall wxruby2-preview" warn "************************************************" # abort installation raise "Cannot install" rescue LoadError # nothingn previously installed, fine to continue with installation end From roys at mindspring.com Sun Aug 27 11:56:54 2006 From: roys at mindspring.com (Roy Sutton) Date: Sun, 27 Aug 2006 11:56:54 -0400 Subject: [Wxruby-users] MDI fixed Message-ID: <44F1C0C6.9040601@mindspring.com> In diagnosing the wxWindow.h problem I discovered that the problem is related to directors wrapping returned pointers. I went in to wxMDIParentFrame and removed 'virtual' from a couple of the functions and the MDI windows work again. I will investigate a fix for this later, since there are a lot of functions that return pointers. However, the MDI crash was a big one that was driving me nuts. If I can't fix the underlying problem with a typemap I will just upload the modified .h file. Roy From wxruby at qualitycode.com Sun Aug 27 21:00:27 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 27 Aug 2006 21:00:27 -0400 Subject: [Wxruby-users] Progress on crashing In-Reply-To: <44F18D12.3080201@pressure.to> References: <1156564021.19081.17.camel@localhost.localdomain> <44F03D07.5000507@pressure.to> <1156641222.17206.59.camel@localhost.localdomain> <44F18D12.3080201@pressure.to> Message-ID: <1156726827.8693.95.camel@localhost.localdomain> On Sun, 2006-08-27 at 13:16 +0100, Alex Fenton wrote: > I like your suggestion of wxruby2-preview-0.x.x for an alpha series, > then bumping to 0.9.0 or 1.9.0 when we get to beta quality and (for > 0.9.0 at least) wxruby 0.6.0 backwards compatibility. We won't ever have full 0.6.0 compatibility, but 0.9.0 (or maybe 0.7.0 to give us more breathing room) should be a superset of 0.6.0 functionality, as much as possible. The differences would include things like require 'wx' vs. 'wxruby', a few documented subtle changes to the api (like returning nil vs. false), perhaps a few API changes to make us more like wxPython, etc. We are also intentionally dropping a few classes that were supported in 0.6.0 but which we now want to encourage using the standard Ruby equivalents. > Sounds good - where to document the known problems that aren't going to > be fixed for this release? Maybe the README could point to another text file that would list the problems. KNOWN-PROBLEMS.txt maybe, or TODO? I don't have strong feelings about it. Kevin From wxruby at qualitycode.com Sun Aug 27 21:03:40 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 27 Aug 2006 21:03:40 -0400 Subject: [Wxruby-users] gem version numbering In-Reply-To: <44F1A1BE.9040907@pressure.to> References: <1156126936.2953.28.camel@localhost.localdomain> <44EA047D.9080303@pressure.to> <1156278150.5712.36.camel@localhost.localdomain> <1156342499.5809.1.camel@localhost.localdomain> <1156428571.6260.10.camel@localhost.localdomain> <44EDED2C.1040103@mindspring.com> <1156458263.5356.59.camel@localhost.localdomain> <44F1A1BE.9040907@pressure.to> Message-ID: <1156727021.8693.100.camel@localhost.localdomain> On Sun, 2006-08-27 at 14:44 +0100, Alex Fenton wrote: > Just tested out creating a gem that checks for conflicting previously > installed gem versions. It checks, warns with instructions on how to > uninstall, and aborts. Looks like it will work for us if we want to > pursue this path - we just add something along the lines of the script > below to gemspec.extensions. > > It will be easier if we can have a constant defined that gives the > version of the library eg Wx::WXRUBY_VERSION, and perhaps Wx::WXRUBY2 > (just defined or not) or Wx::WXRUBY_PREVIEW_VERSION to distinguish the > alpha series from the newer ones that will replace it. Sweet! Thanks for taking this on. With this, I think we have decided to name the gem wxruby-preview, and have an initial version of something like 0.0.34 (depending on exactly when the release happens). Yes, let's have Wx::WXRUBY_VERSION. I don't think we'll need either of the other two, since wxruby 0.6.0 was never a gem, and the preview version will be detectable by a very low version number. Can you submit an actual patch to implement this? Ideally at build time we would pull the latest version number from the README file, but I'll settle for hard-coding it for now. Kevin From wxruby at qualitycode.com Sun Aug 27 21:10:01 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 27 Aug 2006 21:10:01 -0400 Subject: [Wxruby-users] wxWindow.h In-Reply-To: <44F11802.3040706@mindspring.com> References: <44F11802.3040706@mindspring.com> Message-ID: <1156727401.8693.105.camel@localhost.localdomain> On Sat, 2006-08-26 at 23:56 -0400, Roy Sutton wrote: > I have basically spent a full day's worth of time I could have spent > working on something productive trying to figure out which function > signature I changed that is causing wxRuby to crash. It just takes so > long to recompile this from scratch and without dependencies you kind of > have to when you change wxWindow.h. I updated a lot of signatures to > match the wxWindows header file. So frustrated.... I feel your pain. Did you mean to attach a patch? One way we could speed up compilation is to avoid launching the various swig post-processors as command-line apps. Low on my todo list is to make them all embeddable ruby, which could be require'd by rakewx.rb. We would probably save at least a minute per recompile if we did this. And, it's another PURE RUBY project which could be taken on by a volunteer who doesn't know C++ or SWIG. If you're interested, contact me for a more detailed spec of what we need. I wonder if there is some automated way we could take care of this. One approach that would at least help would be if someone could run the actual wx headers through something like doxygen. It would need to be done for each of our 3 platforms, since there may be variations. Just having that available would save us a ton of time. After that's done, an enhancement would be to parse the doxygen output, and our .h files, comparing them to see where we have discrepancies. Another cool pure-ruby task. Kevin From wxruby at qualitycode.com Sun Aug 27 21:11:06 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 27 Aug 2006 21:11:06 -0400 Subject: [Wxruby-users] MDI fixed In-Reply-To: <44F1C0C6.9040601@mindspring.com> References: <44F1C0C6.9040601@mindspring.com> Message-ID: <1156727466.8693.107.camel@localhost.localdomain> On Sun, 2006-08-27 at 11:56 -0400, Roy Sutton wrote: > In diagnosing the wxWindow.h problem I discovered that the problem is > related to directors wrapping returned pointers. I went in to > wxMDIParentFrame and removed 'virtual' from a couple of the functions > and the MDI windows work again. Interesting. Hopefully a simple typemap will solve that. I eagerly await your results. Thanks, Kevin From wxruby at qualitycode.com Sun Aug 27 21:14:23 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sun, 27 Aug 2006 21:14:23 -0400 Subject: [Wxruby-users] Licensing issues In-Reply-To: <44F18DD1.9060507@pressure.to> References: <1156646793.17206.85.camel@localhost.localdomain> <44F18DD1.9060507@pressure.to> Message-ID: <1156727664.8693.112.camel@localhost.localdomain> On Sun, 2006-08-27 at 13:19 +0100, Alex Fenton wrote: > > If possible, we should NOT build in TIFF nor JPEG support, as both have > > special attribution requirements. > I would be very sad to lose JPEG support - I am using this feature > already, and I can see it being something others would want (eg to make > a photo browser). I agree. Under Linux, I have the option to build JPEG support into the wx library, or to leave it out so it dynamically loads it from the system. I suppose that's not an option under MS Windows. > Looking at the relevant docs we only have to add an > attribution line somewhere in our docs; there is no need to modify our > licence terms. We don't redistribute any of their source (I don't think > our include/wxBitmap.h nor just defining BITMAP_TYPE_JPEG are derivative > works) so the short attribution could be used, as required for redist in > binary form. True. Sounds simple enough. Do you think we would add a CREDITS file, or just have a CREDITS section in our README? Or something else? > TIFF is a less widespread format but again I would rather not lose it - Agreed. > wxXML is a dependency for using XRC Resoures, I think - if you try > configuring WxWidgets --without-expat it warns that XRC will be > disabled. I don't use XRC but seems like a feature we don't want to lose > (eg for use with GUI designers). Oh, then I guess we need that as well. Again, with Linux we can leave that stuff out and assume it is provided by the OS. But if you are going to include it one platform, we might as well be consistent. > > Now, for the sample license: Public domain really isn't appropriate, > > partly because it is not valid in many countries. Here is my proposal: > > > Looks good, thanks again for your work on this. Cool. Thanks. Kevin From roys at mindspring.com Sun Aug 27 23:03:37 2006 From: roys at mindspring.com (Roy Sutton) Date: Sun, 27 Aug 2006 23:03:37 -0400 Subject: [Wxruby-users] Header files Message-ID: <44F25D09.2030908@mindspring.com> I will probably be sending patches for about 30 header files. I have put some TODO: notices in some of the header files where I've had to temporarily remove some things. How do you guys want these? A .zip of all the changed files? A .zip of all the patches? Individual e-mails? All attached to one? Roy From wxruby at qualitycode.com Mon Aug 28 00:14:41 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Mon, 28 Aug 2006 00:14:41 -0400 Subject: [Wxruby-users] Header files In-Reply-To: <44F25D09.2030908@mindspring.com> References: <44F25D09.2030908@mindspring.com> Message-ID: <1156738481.8693.144.camel@localhost.localdomain> On Sun, 2006-08-27 at 23:03 -0400, Roy Sutton wrote: > I will probably be sending patches for about 30 header files. I have > put some TODO: notices in some of the header files where I've had to > temporarily remove some things. How do you guys want these? A .zip of > all the changed files? A .zip of all the patches? Individual e-mails? > All attached to one? Probably a zip of changed files would be most convenient. I can review them with my diff utility (meld). If they were in distinct groups according to intent, that would be slightly helpful, but I'm guessing that would be difficult. I'm thinking "Fix inheritance chains" vs. "Add missing methods" vs. "Fixes to match actual API" or whatever. I should mention that the next few days will be somewhat challenging for me. I'm facing some serious work deadlines; my primary computer has died, and it was a laptop, so now I can only work from my desk; and we might possibly get a direct hit from a hurricane on Wednesday, so I may have to scramble to prepare for that. I'm in the Tampa Bay area, so if I'm offline later this week, you can watch the news to see if it's due to the storm. (Our house is strong, secure, and 70 feet above sea level, so the chances of actual personal damage or injury are very minimal.) Kevin From nochoice at xs4all.nl Mon Aug 28 13:20:48 2006 From: nochoice at xs4all.nl (Jonathan Maasland) Date: Mon, 28 Aug 2006 17:20:48 +0000 Subject: [Wxruby-users] Gem testing Message-ID: <44F325F0.3020408@xs4all.nl> Hi all, First off sorry for the lengthy email but I typed it as I went along. I just tried to start a bit of testing of the binary Linux gem (Kevin sent me a link) and I quickly ran into a problem: ----- jonathan at weatherlight ~/ruby-dev/wxruby/cvs_current/wxruby2/samples $ ruby test.rb /usr/lib/ruby/gems/1.8/gems/wxruby-1.9.0-i486-linux/lib/wx.rb:22: uninitialized constant Wxruby2 (NameError) from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:182:in `activate' from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:181:in `activate' from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:26:in `require' from test.rb:4 ----- I downloaded the gem a week ago. Testing on a Gentoo-sytem compiled with gcc 3.4.6. I have wxGTK 2.6.3.2 installed compiled with unicode and debug on but that shouldn't be an issue considering that wxWidgets is contained within the gem. After gem-testing I tried to grab the latest cvs and ran into a small issue I already fixed once. Just thought you might like to know about. I have both Wx-2.4 and Wx-2.6 installed, however wx-config is linked to 2.4 After changing `wx-config` ...' to `wx-config-2.6 ...` everything worked fine, up until the linking which failed: -- ld: cannot find -lwx_gtk2ud_xrc-2.6 -- If I list the libs for wx with wx-config-2.6 --libs, it of course lists the above library. And the library-file exists in /usr/lib. Any ideas? 'Cause I really don't have a clue. I thought I might try to recompile wx. Thank you all (Kevin, Roy, Sean and Alex) very very much for all the hard work and free time you spent on this project. I can't say nothing more than: You guys ROCK! With friendly greetings, Jonathan From alex at pressure.to Tue Aug 29 14:29:02 2006 From: alex at pressure.to (Alex Fenton) Date: Tue, 29 Aug 2006 19:29:02 +0100 Subject: [Wxruby-users] Licensing issues In-Reply-To: <1156727664.8693.112.camel@localhost.localdomain> References: <1156646793.17206.85.camel@localhost.localdomain> <44F18DD1.9060507@pressure.to> <1156727664.8693.112.camel@localhost.localdomain> Message-ID: <44F4876E.7010809@pressure.to> Kevin Smith wrote: > Under Linux, I have the option to build JPEG support into the > wx library, or to leave it out so it dynamically loads it from the > system. I suppose that's not an option under MS Windows. > On OS X it defaults to using built-in; other apps I have installled (HTMLDoc, GRASS) bundle it rather than install it to /usr/local/lib. > True. Sounds simple enough. Do you think we would add a CREDITS file, or > just have a CREDITS section in our README? Or something else? > Just a credits section in the README, or possibly appended to the LICEN[CS]E file would be enough I think. If you could post a standard header that should go in all the samples, I am happy to go through them, update and commit. Thanks alex From alex at pressure.to Tue Aug 29 14:34:26 2006 From: alex at pressure.to (Alex Fenton) Date: Tue, 29 Aug 2006 19:34:26 +0100 Subject: [Wxruby-users] Progress on crashing In-Reply-To: <1156726827.8693.95.camel@localhost.localdomain> References: <1156564021.19081.17.camel@localhost.localdomain> <44F03D07.5000507@pressure.to> <1156641222.17206.59.camel@localhost.localdomain> <44F18D12.3080201@pressure.to> <1156726827.8693.95.camel@localhost.localdomain> Message-ID: <44F488B2.6010500@pressure.to> Kevin Smith wrote: > We won't ever have full 0.6.0 compatibility, but 0.9.0 (or maybe 0.7.0 > to give us more breathing room) should be a superset of 0.6.0 > functionality, as much as possible. > Agreed, also re dropped classes. Could be an argument for 1.9 as beta, but I don't feel strongly about it - let's decide that later. > Maybe the README could point to another text file that would list the > problems. KNOWN-PROBLEMS.txt maybe, or TODO? TODO sounds right and fairly standard to me, with, as you suggest, a note in README that says 'there are known issues... please see TODO' cheers alex From alex at pressure.to Tue Aug 29 14:36:07 2006 From: alex at pressure.to (Alex Fenton) Date: Tue, 29 Aug 2006 19:36:07 +0100 Subject: [Wxruby-users] Header files In-Reply-To: <44F25D09.2030908@mindspring.com> References: <44F25D09.2030908@mindspring.com> Message-ID: <44F48917.9000606@pressure.to> Roy Sutton wrote: > I will probably be sending patches for about 30 header files. Very happy to help commit these. It's great you're able to tackle the murky SWIG etc problems. > How do you guys want these? A .zip of > all the changed files? A .zip of all the patches? Individual e-mails? > All attached to one? > I don't really mind. A few batches of patches or new files is ideal, but basically whatever suits you best. Since this will affect a lot of files, maybe we could consider making a release first? things can be a bit unpredictable across platform, and it would be nice to have a reference version to test against. We might not want to publicise this release beyond this list for now - but it might help us catch bugs with the gem packaging now. I'm willing to do the bits to push out a release (see other email) thanks alex From alex at pressure.to Tue Aug 29 14:56:06 2006 From: alex at pressure.to (Alex Fenton) Date: Tue, 29 Aug 2006 19:56:06 +0100 Subject: [Wxruby-users] gem version numbering In-Reply-To: <1156727021.8693.100.camel@localhost.localdomain> References: <1156126936.2953.28.camel@localhost.localdomain> <44EA047D.9080303@pressure.to> <1156278150.5712.36.camel@localhost.localdomain> <1156342499.5809.1.camel@localhost.localdomain> <1156428571.6260.10.camel@localhost.localdomain> <44EDED2C.1040103@mindspring.com> <1156458263.5356.59.camel@localhost.localdomain> <44F1A1BE.9040907@pressure.to> <1156727021.8693.100.camel@localhost.localdomain> Message-ID: <44F48DC6.7080908@pressure.to> Kevin Smith wrote: > Yes, let's have Wx::WXRUBY_VERSION. ... > Can you submit an actual patch to implement this? See attached, adding WXRUBY_VERSION (and also WXWIDGETS_VERSION, if you like). This also updates the packager to use the agreed gem version name and number, and adds a quick test in minimal.rb sample's About dialog. > Ideally at build time > we would pull the latest version number from the README file, but I'll > settle for hard-coding it for now. Yes, I would love to find a neat way to do this for other Ruby projects too. Anyone know a sane way? alex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wx_rb.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060829/049fdefc/attachment.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: minimal_rb.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060829/049fdefc/attachment-0001.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rakepackage_rb.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060829/049fdefc/attachment-0002.pl From alex at pressure.to Tue Aug 29 16:22:36 2006 From: alex at pressure.to (Alex Fenton) Date: Tue, 29 Aug 2006 21:22:36 +0100 Subject: [Wxruby-users] treectrl sample Message-ID: <44F4A20C.4010401@pressure.to> Hi all just added a treectrl sample, adapted and restyled from the old wx one. A few things are missing (eg ImageLists aren't working properly, so no icons) but what's there works well on OS X. Hope this helps someone. you'll need to run cvs update -d alex From alex at pressure.to Tue Aug 29 17:46:38 2006 From: alex at pressure.to (Alex Fenton) Date: Tue, 29 Aug 2006 22:46:38 +0100 Subject: [Wxruby-users] ActivateEvent Message-ID: <44F4B5BE.2030602@pressure.to> Hi Just a patch, an i.file plus sample to add support for ActivateEvent. These are fired when frames become active or inactive (usually by the user clicking on it) and also when a whole app starts or stops being the currently active desktop app. Not an urgent patch. cheers alex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: EvtHandler_i_activeevent.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060829/86a3ecde/attachment.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ActivateEvent.i Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060829/86a3ecde/attachment-0001.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: activation.rb Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060829/86a3ecde/attachment-0002.pl From roys at mindspring.com Tue Aug 29 22:54:46 2006 From: roys at mindspring.com (Roy Sutton) Date: Tue, 29 Aug 2006 22:54:46 -0400 Subject: [Wxruby-users] include.zip Message-ID: <44F4FDF6.309@mindspring.com> These are the files from the swig/classes/include directory. I hope the line endings don't end up wrong. -------------- next part -------------- A non-text attachment was scrubbed... Name: include.zip Type: application/x-zip-compressed Size: 35208 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-users/attachments/20060829/77617444/attachment-0001.bin From roys at mindspring.com Tue Aug 29 23:01:00 2006 From: roys at mindspring.com (Roy Sutton) Date: Tue, 29 Aug 2006 23:01:00 -0400 Subject: [Wxruby-users] classes.zip Message-ID: <44F4FF6C.7020607@mindspring.com> Files for swig/classes. Apologies for the TODOs. I'm sure anyone can make sure they're correct. I just don't have the time to address them right now and figured it'd be best to document them. -------------- next part -------------- A non-text attachment was scrubbed... Name: classes.zip Type: application/x-zip-compressed Size: 3187 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-users/attachments/20060829/5d030086/attachment.bin From wxruby at qualitycode.com Wed Aug 30 12:58:00 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Wed, 30 Aug 2006 12:58:00 -0400 Subject: [Wxruby-users] Header files In-Reply-To: <44F48917.9000606@pressure.to> References: <44F25D09.2030908@mindspring.com> <44F48917.9000606@pressure.to> Message-ID: <1156957080.12834.175.camel@localhost.localdomain> On Tue, 2006-08-29 at 19:36 +0100, Alex Fenton wrote: > Since this will affect a lot of files, maybe we could consider making a > release first? things can be a bit unpredictable across platform, and it > would be nice to have a reference version to test against. We should definitely do a CVS tag. Not sure a release is required. > We might not want to publicise this release beyond this list for now - > but it might help us catch bugs with the gem packaging now. I'm willing > to do the bits to push out a release (see other email) Interesting idea. I have thought something similar at times over the last couple weeks. Kind of a stealth release. A release-candidate of the preview alpha release. To get any big bugs out (including process errors) before inviting a flood of downloads. I would slightly lean toward doing it after checking in Roy's stuff, but could be persuaded otherwise. I hope to do some merging tonight, so if anyone has objections, speak now. Since we will have a tag, we could always do our preview-of-the-preview release from that. Kevin From alex at pressure.to Wed Aug 30 13:38:39 2006 From: alex at pressure.to (Alex Fenton) Date: Wed, 30 Aug 2006 18:38:39 +0100 Subject: [Wxruby-users] Header files In-Reply-To: <1156957080.12834.175.camel@localhost.localdomain> References: <44F25D09.2030908@mindspring.com> <44F48917.9000606@pressure.to> <1156957080.12834.175.camel@localhost.localdomain> Message-ID: <44F5CD1F.5040508@pressure.to> Kevin Smith wrote: > A release-candidate of the > preview alpha release. To get any big bugs out (including process > errors) before inviting a flood of downloads. > Yup - it will be hot download of the day as soon as we announce it on the main ruby mailing list. It will look better for us if we have ironed out any killer bugs with the install. > I would slightly lean toward doing it after checking in Roy's stuff, but > could be persuaded otherwise. I hope to do some merging tonight, so if > anyone has objections, speak now. > Great, if you have time to do the merge, please go ahead - I am moving house (for the third time in as many months) so not able to help with more complex stuff until the weekend. Shall we aim to release after this merge, and licence update to samples? (sorry to keep prodding on this) > Since we will have a tag, we could always do our preview-of-the-preview > release from that. Yes - let's see how it looks after the merge (better, I hope and expect) and we can make a call about which tag to release from. cheers alex From wxruby at qualitycode.com Wed Aug 30 21:29:18 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Wed, 30 Aug 2006 21:29:18 -0400 Subject: [Wxruby-users] gem version numbering In-Reply-To: <44F48DC6.7080908@pressure.to> References: <1156126936.2953.28.camel@localhost.localdomain> <44EA047D.9080303@pressure.to> <1156278150.5712.36.camel@localhost.localdomain> <1156342499.5809.1.camel@localhost.localdomain> <1156428571.6260.10.camel@localhost.localdomain> <44EDED2C.1040103@mindspring.com> <1156458263.5356.59.camel@localhost.localdomain> <44F1A1BE.9040907@pressure.to> <1156727021.8693.100.camel@localhost.localdomain> <44F48DC6.7080908@pressure.to> Message-ID: <1156987758.9073.35.camel@localhost.localdomain> On Tue, 2006-08-29 at 19:56 +0100, Alex Fenton wrote: > See attached, adding WXRUBY_VERSION (and also WXWIDGETS_VERSION, if you > like). > > This also updates the packager to use the agreed gem version name and > number, and adds a quick test in minimal.rb sample's About dialog. Nice. Applied, thanks. > > Ideally at build time > > we would pull the latest version number from the README file, but I'll > > settle for hard-coding it for now. > Yes, I would love to find a neat way to do this for other Ruby projects > too. Anyone know a sane way? I think eventually it should be hooked into our VCS tool. I would also like to see the README version numbers include a build date as well. For now, we already have a mess with the version number appearing in about five places. Hopefully over time we can improve the situation, but as I said, I think getting our VCS in place first makes sense. I have tagged 0.0.34, including these VERSION patches, and also the gemspec changes. It does not include your ActivateEvent patch (which I haven't looked at yet), nor Roy's big zipfile patches. Kevin From wxruby at qualitycode.com Wed Aug 30 21:45:48 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Wed, 30 Aug 2006 21:45:48 -0400 Subject: [Wxruby-users] ActivateEvent In-Reply-To: <44F4B5BE.2030602@pressure.to> References: <44F4B5BE.2030602@pressure.to> Message-ID: <1156988749.9073.38.camel@localhost.localdomain> On Tue, 2006-08-29 at 22:46 +0100, Alex Fenton wrote: > Just a patch, an i.file plus sample to add support for ActivateEvent. Applied, thanks. Kevin From wxruby at qualitycode.com Wed Aug 30 21:47:46 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Wed, 30 Aug 2006 21:47:46 -0400 Subject: [Wxruby-users] treectrl sample In-Reply-To: <44F4A20C.4010401@pressure.to> References: <44F4A20C.4010401@pressure.to> Message-ID: <1156988867.9073.40.camel@localhost.localdomain> On Tue, 2006-08-29 at 21:22 +0100, Alex Fenton wrote: > just added a treectrl sample, adapted and restyled from the old wx one. > A few things are missing (eg ImageLists aren't working properly, so no > icons) but what's there works well on OS X. When I run this under Linux, I get: ASSERT: ../src/generic/treectlg.cpp 1044 wxAssertFailure invalid tree item and the app aborts before bringing up the main window. I didn't research it further, but certainly can at some point if necessary. Kevin From wxruby at qualitycode.com Wed Aug 30 22:44:51 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Wed, 30 Aug 2006 22:44:51 -0400 Subject: [Wxruby-users] include.zip (and classes.zip) In-Reply-To: <44F4FDF6.309@mindspring.com> References: <44F4FDF6.309@mindspring.com> Message-ID: <1156992291.9073.68.camel@localhost.localdomain> On Tue, 2006-08-29 at 22:54 -0400, Roy Sutton wrote: > These are the files from the swig/classes/include directory. I hope the > line endings don't end up wrong. I'm replying to both sets of patches at once. There are enough areas of concern that I can't take the patches as-is. I can either apply parts of it (on a file-by-file basis), or have you resubmit separate patches for the different categories. Your choice. Most of my concerns are related to methods that appear to really be virtual, but which you have un-virtual'd. It's not clear to me why you are making that change, nor whether the change should be temporary or permanent. Perhaps really clear comments would help me to understand. I would be happy with a patch for the Event classes, removing Clone. I would also be happy with a patch for the ControlWithItems classes, especially with a clearer comment about which methods should be removed (like have a comment ending the to-be-removed section). Frame doesn't look right, though. You took away the virtual from Create/OnCreateStatus/ToolBar, and clearly those methods are virtual. If the OnXxx methods aren't virtual, there is no point in exposing them. I assume you un-virtual'd them because they are actually defined in the BaseFrame class which we are not yet wrapping. I would like to see a comment to that effect, rather than just taking out the virtual keyword without explanation. In Grid, all the methods that you de-virtualized appear to be virtual to me. Same with GridCellBoolRenderer. I didn't check the rest of the grid classes, guessing they have the same problem. The un-virtual'd methods in Sizer and TextCtrl don't look right. You removed several methods from TextValidator for no apparent reason. All the changes in Window looked good, aside from some //TODO was virtual comments that are not near any changes. In App.i, let's remove CreateLogTarget since it is deprecated. And GetTopWindow looks virtual to me. Kevin From wxruby at qualitycode.com Wed Aug 30 22:55:20 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Wed, 30 Aug 2006 22:55:20 -0400 Subject: [Wxruby-users] Header files In-Reply-To: <44F5CD1F.5040508@pressure.to> References: <44F25D09.2030908@mindspring.com> <44F48917.9000606@pressure.to> <1156957080.12834.175.camel@localhost.localdomain> <44F5CD1F.5040508@pressure.to> Message-ID: <1156992920.9073.77.camel@localhost.localdomain> On Wed, 2006-08-30 at 18:38 +0100, Alex Fenton wrote: > Great, if you have time to do the merge, please go ahead - I am moving > house (for the third time in as many months) Lucky you! Until I learned the knack of living light, every time I moved I SWORE I was never moving again. Moving 1000+ miles every year for three years straight kind of forces one to discard all but the essentials. > Shall we aim to release after this merge, and licence update to samples? Sure. Looks like it will be 0.0.35. I have not integrated Roy's work yet, so I could see doing an internal release before it, or after. I also have to look into some problems reported against the Linux gem. I'm about done for the night. If you could insert the comment header below at the top of each of the .rb samples EXCEPT in the bigdemo directory, that would be great. If not, I'll try to do it myself in the next couple days. If anyone knows how to get a hold of Robert Carlin, I would love to get his permission to (re-)license bigdemo. Kevin # wxRuby2 Sample Code # Copyright (c) 2004-2006 Kevin B. Smith # # Permission is hereby granted, free of charge, to any person obtaining # a copy of this software, to deal in the Software without restriction, # including without limitation the rights to use, copy, modify, merge, # publish, distribute, sublicense, and/or sell copies of any portion of # this Software, and to permit persons to whom the Software is furnished # to do so. This copyright notice need not be retained in any derived # work. # # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS # OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF # MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. # IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY # CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, # TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE # SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. From alex at pressure.to Thu Aug 31 01:01:03 2006 From: alex at pressure.to (Alex Fenton) Date: Thu, 31 Aug 2006 06:01:03 +0100 Subject: [Wxruby-users] Header files In-Reply-To: <1156992920.9073.77.camel@localhost.localdomain> References: <44F25D09.2030908@mindspring.com> <44F48917.9000606@pressure.to> <1156957080.12834.175.camel@localhost.localdomain> <44F5CD1F.5040508@pressure.to> <1156992920.9073.77.camel@localhost.localdomain> Message-ID: <44F66D0F.6030408@pressure.to> > I have not integrated Roy's work yet, so I could see doing an internal > release before it, or after. I also have to look into some problems > reported against the Linux gem. > Backwards and forwards compatibility across different versions of OS X build tools and os is still untested too, so would be nice to catch any probs with that too. > I'm about done for the night. If you could insert the comment header > below at the top of each of the .rb samples EXCEPT in the bigdemo > directory, that would be great. If not, I'll try to do it myself in the > next couple days. Sure, happy to do this, prob tomorrow. Could we use a shorter text that references the full licence instead of reproducing it verbatim in each sample? Something like # wxRuby2 Sample Code # Copyright (c) 2004-2006 Kevin B. Smith # # This code is subject by the terms of the wxRuby sample code # licence. Please see LICENSE.TXT distributed with this package. I copied the full text into a few samples, and it just seemed a little intrusive - i need to scroll down to see the magical incantation "require 'wx'" in them. I took a quick look at rubycocoa, FxRuby (don't have any licence on their samples), and WxWidgets (specifies the licence and copyright holder in each, but doesn't reproduce the former in full). cheers alex From wxruby at qualitycode.com Thu Aug 31 09:06:21 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 31 Aug 2006 09:06:21 -0400 Subject: [Wxruby-users] License for sample code (was: Header files) In-Reply-To: <44F66D0F.6030408@pressure.to> References: <44F25D09.2030908@mindspring.com> <44F48917.9000606@pressure.to> <1156957080.12834.175.camel@localhost.localdomain> <44F5CD1F.5040508@pressure.to> <1156992920.9073.77.camel@localhost.localdomain> <44F66D0F.6030408@pressure.to> Message-ID: <1157029581.2720.39.camel@localhost.localdomain> On Thu, 2006-08-31 at 06:01 +0100, Alex Fenton wrote: > Could we use a shorter text that > references the full licence instead of reproducing it verbatim in each > sample? Something like > > # wxRuby2 Sample Code > # Copyright (c) 2004-2006 Kevin B. Smith > # > # This code is subject by the terms of the wxRuby sample code > # licence. Please see LICENSE.TXT distributed with this package. Sure, that makes sense, except it should say "Please see SAMPLES-LICENSE.TXT to distinguish it from the main license. And I suppose SAMPLES-LICENSE.TXT should go in the samples/ directory (and we need to be sure it ends up in the gems). > I took a quick look at rubycocoa, FxRuby (don't have any licence on > their samples), That's really sad. Technically it means that nobody can grab snippets of code out of the samples to use in their own applications, regardless of whether those apps are open or closed source. Did you know that most web articles that contain sample code are under very restrictive copyrights that also prevent you from using any of that sample code in your apps? Very frustrating. Obviously you would be allowed to grab a line or two, since fragments that small are non-copyrightable. But if you wanted to grab a 10-line on_paint method, you couldn't legally. That's why I feel so strongly about it. Anyway, thanks for taking care of the actual paste+commit work! Kevin From wxruby at qualitycode.com Thu Aug 31 09:12:10 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 31 Aug 2006 09:12:10 -0400 Subject: [Wxruby-users] License for sample code (was: Header files) In-Reply-To: <1157029581.2720.39.camel@localhost.localdomain> References: <44F25D09.2030908@mindspring.com> <44F48917.9000606@pressure.to> <1156957080.12834.175.camel@localhost.localdomain> <44F5CD1F.5040508@pressure.to> <1156992920.9073.77.camel@localhost.localdomain> <44F66D0F.6030408@pressure.to> <1157029581.2720.39.camel@localhost.localdomain> Message-ID: <1157029931.2720.42.camel@localhost.localdomain> On Thu, 2006-08-31 at 09:06 -0400, Kevin Smith wrote: > > # wxRuby2 Sample Code > > # Copyright (c) 2004-2006 Kevin B. Smith > > # > > # This code is subject by the terms of the wxRuby sample code > > # licence. Please see LICENSE.TXT distributed with this package. Actually, this would be even less intrusive: # wxRuby2 Sample Code Copyright 2004-2006 Kevin B. Smith # Freely reusable code--see SAMPLES-LICENSE.TXT for details. Kevin From roys at mindspring.com Thu Aug 31 10:13:11 2006 From: roys at mindspring.com (Roy Sutton) Date: Thu, 31 Aug 2006 10:13:11 -0400 Subject: [Wxruby-users] include.zip (and classes.zip) In-Reply-To: <1156992291.9073.68.camel@localhost.localdomain> References: <44F4FDF6.309@mindspring.com> <1156992291.9073.68.camel@localhost.localdomain> Message-ID: <44F6EE77.3060709@mindspring.com> Kevin Smith wrote: > I'm replying to both sets of patches at once. > > There are enough areas of concern that I can't take the patches as-is. I > can either apply parts of it (on a file-by-file basis), or have you > resubmit separate patches for the different categories. Your choice. > I'll try to break them up better by functional area > Most of my concerns are related to methods that appear to really be > virtual, but which you have un-virtual'd. It's not clear to me why you > are making that change, nor whether the change should be temporary or > permanent. Perhaps really clear comments would help me to understand. > I thought I had explained this in an e-mail but I guess I didn't. The virtual functions which return a pointer generate a SWIG warning and those functions, when used, often cause wxRuby to crash. In many cases, the functions really wouldn't be overridden by Ruby-derived classes. My intention was to remove them until we could decide if there was a safe way to expose them. The changes -should- only be temporary if a solution can be found. > I would be happy with a patch for the Event classes, removing Clone. I > would also be happy with a patch for the ControlWithItems classes, > especially with a clearer comment about which methods should be removed > (like have a comment ending the to-be-removed section). > I can resubmit the Event classes as separate files. ControlWithItems patches: if I have to document them that well I might as well just make the change. It could be a couple days. > Frame doesn't look right, though. You took away the virtual from > Create/OnCreateStatus/ToolBar, and clearly those methods are virtual. If > the OnXxx methods aren't virtual, there is no point in exposing them. > Mostly I removed them for the reason above. However, the comment reflects the fact that most of those OnXxxx functions in wxWidgets are protected, internal functions. I see now from the docs they're not so the 'should we expose this' comment should go away at least. > I assume you un-virtual'd them because they are actually defined in the > BaseFrame class which we are not yet wrapping. I would like to see a > comment to that effect, rather than just taking out the virtual keyword > without explanation. > > In Grid, all the methods that you de-virtualized appear to be virtual to > me. Same with GridCellBoolRenderer. I didn't check the rest of the grid > classes, guessing they have the same problem. The un-virtual'd methods > in Sizer and TextCtrl don't look right. You removed several methods from > TextValidator for no apparent reason. > re TextValidator and other validator classes: Those methods were defined on the parent classes. > All the changes in Window looked good, aside from some //TODO was > virtual comments that are not near any changes. > Ah, well, those methods -should- be virtual, but aren't. Obviously we had crash bugs associated with those functions when they were virtual. Ideally we'd make them virtual if we figure out how to fix the problem with directors. > In App.i, let's remove CreateLogTarget since it is deprecated. And > GetTopWindow looks virtual to me. > I'm OK with that. > Kevin > I'll see about grouping and resubmitting patches. As I said, it was a large number of patches. They're all themed around making the header files match the structure of wxWidgets better or addressing the shortcomings of SWIG wrapping virtual functions that return pointers. Roy From alex at pressure.to Thu Aug 31 13:44:28 2006 From: alex at pressure.to (Alex Fenton) Date: Thu, 31 Aug 2006 18:44:28 +0100 Subject: [Wxruby-users] License for sample code In-Reply-To: <1157029581.2720.39.camel@localhost.localdomain> References: <44F25D09.2030908@mindspring.com> <44F48917.9000606@pressure.to> <1156957080.12834.175.camel@localhost.localdomain> <44F5CD1F.5040508@pressure.to> <1156992920.9073.77.camel@localhost.localdomain> <44F66D0F.6030408@pressure.to> <1157029581.2720.39.camel@localhost.localdomain> Message-ID: <44F71FFC.9090205@pressure.to> Kevin Smith wrote: > Sure, that makes sense, except it should say "Please see > SAMPLES-LICENSE.TXT to distinguish it from the main license. OK, the short headers are in there. > And I > suppose SAMPLES-LICENSE.TXT should go in the samples/ directory (and we > need to be sure it ends up in the gems). > Added; I've just checked and it gets picked up automatically by our current gem spec. > That's really sad. Technically it means that nobody can grab snippets of > code out of the samples to use in their own applications, regardless of > whether those apps are open or closed source. > I agree it's important to get this right, and glad we've gone for a liberal licence. Thanks again for looking into it. cheers alex From wxruby at qualitycode.com Thu Aug 31 16:08:41 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Thu, 31 Aug 2006 16:08:41 -0400 Subject: [Wxruby-users] include.zip (and classes.zip) In-Reply-To: <44F6EE77.3060709@mindspring.com> References: <44F4FDF6.309@mindspring.com> <1156992291.9073.68.camel@localhost.localdomain> <44F6EE77.3060709@mindspring.com> Message-ID: <44F741C9.5030005@qualitycode.com> Roy Sutton wrote: > I thought I had explained this in an e-mail but I guess I didn't. The > virtual functions which return a pointer generate a SWIG warning and > those functions, when used, often cause wxRuby to crash. In many cases, > the functions really wouldn't be overridden by Ruby-derived classes. My > intention was to remove them until we could decide if there was a safe > way to expose them. The changes -should- only be temporary if a > solution can be found. The problem is that if a function really is virtual in wx, but we claim that it is not, we can also get into problems. Possibly even crashes, although I'm not certain. So I'm not sure it's worth temporarily making things less correct unless there is a very clear net benefit. > I can resubmit the Event classes as separate files. ControlWithItems > patches: if I have to document them that well I might as well just make > the change. It could be a couple days. No need for an extensive comment. I'll take the ControlWithItems as is if necessary, although a single line like // End ControlWithItems at the bottom of the group of methods would be great. Not required. >> Frame doesn't look right, though. You took away the virtual from >> Create/OnCreateStatus/ToolBar, and clearly those methods are virtual. If >> the OnXxx methods aren't virtual, there is no point in exposing them. >> > Mostly I removed them for the reason above. However, the comment > reflects the fact that most of those OnXxxx functions in wxWidgets are > protected, internal functions. I see now from the docs they're not so > the 'should we expose this' comment should go away at least. I can't imagine any OnXxx method being protected or internal. > re TextValidator and other validator classes: Those methods were > defined on the parent classes. Still, if they are virtual in a wx class, I think we need to declare them so in our headers. Otherwise we get into weird troubles. >> All the changes in Window looked good, aside from some //TODO was >> virtual comments that are not near any changes. >> > Ah, well, those methods -should- be virtual, but aren't. Obviously we > had crash bugs associated with those functions when they were virtual. > Ideally we'd make them virtual if we figure out how to fix the problem > with directors. I guess I would rather %ignore them than declare them incorrectly. > I'll see about grouping and resubmitting patches. As I said, it was a > large number of patches. They're all themed around making the header > files match the structure of wxWidgets better or addressing the > shortcomings of SWIG wrapping virtual functions that return pointers. Thanks! I hope this email clarifies what I would like. To summarize: Event patch great, ControlWithItems patch fine (bonus points for slightly better comments). Declaring things non-virtual that are virtual in wx seems bad. Using %ignore to work around virtual problems would be fine. Kevin From roys at mindspring.com Thu Aug 31 16:31:03 2006 From: roys at mindspring.com (Roy Sutton) Date: Thu, 31 Aug 2006 16:31:03 -0400 Subject: [Wxruby-users] include.zip (and classes.zip) In-Reply-To: <44F741C9.5030005@qualitycode.com> References: <44F4FDF6.309@mindspring.com> <1156992291.9073.68.camel@localhost.localdomain> <44F6EE77.3060709@mindspring.com> <44F741C9.5030005@qualitycode.com> Message-ID: <44F74707.5020806@mindspring.com> Kevin Smith wrote: > The problem is that if a function really is virtual in wx, but we claim > that it is not, we can also get into problems. Possibly even crashes, > although I'm not certain. > The only difference to us declaring it virtual or not is that SWIG will either generate a director wrapper or not. Even using %ignore will (with the current released SWIG) cause problems since it incorrectly wraps %ignored functions. You can still call the function directly from Ruby, you just can't override the function in a derived class. I maintain that in almost every case we won't have any issue whatsoever. Does it rub me the wrong way that these functions are misdeclared? Yes, it does. > Still, if they are virtual in a wx class, I think we need to declare > them so in our headers. Otherwise we get into weird troubles. > I don't /believe/ this is the case, as has been proven by the fact we've had the virtual/non virtual headers wrong for a long time. I /suppose/ it could cause an issue for calling from Ruby. It won't hurt wx's internal calls at all since they are already compiled correctly. AFAIK there is no need to declare a method virtual more than once in its parent's hierarchy. SWIG will generate a wrapper at each level for any virtual function. It only has to be declared virtual once. If anyone knows better than that please let me know. Roy From john at junqbox.com Thu Aug 31 17:35:24 2006 From: john at junqbox.com (John Purrier (JunqBox)) Date: Thu, 31 Aug 2006 14:35:24 -0700 Subject: [Wxruby-users] Help with URL drop Message-ID: <5582C2250AE6184B9723289FDFD92C38285B@mail.johnpur.com> Hello, I am trying to implement a drag from the browser address bar (favicon) and drop onto a wxRuby app. I cannot for the life of me figure out how to set the drop target to accept the URL data type? Any help or pointers appreciated... I implemented file drop with no issues but the url thing has me stumped. John Purrier email: john at junqbox.com web: www.junqbox.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20060831/cc493305/attachment.html