From alex at pressure.to Mon May 1 10:54:12 2006 From: alex at pressure.to (Alex Fenton) Date: Mon, 01 May 2006 15:54:12 +0100 Subject: [Wxruby-users] ListItem patches In-Reply-To: <1146365374.17322.87.camel@localhost.localdomain> References: <4428840D.8030008@pressure.to> <1146365374.17322.87.camel@localhost.localdomain> Message-ID: <44562114.1090206@pressure.to> Hi Kevin I think some of it is still relevant to CVS HEAD: - the patch to RubyConstants.i adds the LIST_*constants for styling ListItem - the patch to ListCtrl.i disambiguates two methods of calling set_item thanks alex Kevin Smith wrote: > Alex, > > I know I added ListItem earlier tonight, but not from these patches. > > Can you let me know if some or all of this should still be applied, or > if it's now stale? > > Thanks/sorry, > > Kevin > > > > On Tue, 2006-03-28 at 01:32 +0100, Alex Fenton wrote: > >> Hi >> >> Attached, patches to implement ListItem. This class, in wxruby 0.6.0, allows styling of individual items in a ListCtrl, via a particularly clunky API. In disambiguating the overloaded ListCtrl#set_item method it introduces one non backwards-compatible change. I've followed the WxPython convention as described in the Wx class ref, renaming set_item(index, col, string, imageid) to set_item_string. >> >> One thing that doesn't work is the constants LIST_FORMAT_LEFT etc. I'm not sure if it's the same problem I'm seeing with some other groups of constants since upgrading to SWIG 1.3.29, but constants declarations like >> >> enum wxListColumnFormat { >> .... >> enum wxSystemColour { >> ... >> >> seem to be broken. >> >> Lastly, would it be possible and desirable to move class-specific constants (like TE_xxx, SYS_xxx, LIST_xxx, NB_xxx etc) from RubyConstants.i to the relevant .i file in swig/classes? Nothing urgent, just a suggestion as RubyConstants.i is getting unwieldy. >> >> alex >> plain text document attachment (RubyConstants.patch) >> Index: wxruby2/swig/RubyConstants.i >> =================================================================== >> RCS file: /var/cvs/wxruby/wxruby2/swig/RubyConstants.i,v >> retrieving revision 1.18 >> diff -b -u -r1.18 RubyConstants.i >> --- wxruby2/swig/RubyConstants.i 29 Nov 2005 00:48:20 -0000 1.18 >> +++ wxruby2/swig/RubyConstants.i 28 Mar 2006 00:20:15 -0000 >> @@ -14,6 +14,7 @@ >> #include >> #include >> #include >> +#include >> >> // >> // All of these exist on only one platform, so in those >> @@ -1480,6 +1481,92 @@ >> >> // for compatibility only >> #define wxLC_USER_TEXT wxLC_VIRTUAL >> +#define wxLIST_MASK_STATE 0x0001 >> +#define wxLIST_MASK_TEXT 0x0002 >> +#define wxLIST_MASK_IMAGE 0x0004 >> +#define wxLIST_MASK_DATA 0x0008 >> +#define wxLIST_SET_ITEM 0x0010 >> +#define wxLIST_MASK_WIDTH 0x0020 >> +#define wxLIST_MASK_FORMAT 0x0040 >> + >> +// State flags for indicating the state of an item >> +#define wxLIST_STATE_DONTCARE 0x0000 >> +#define wxLIST_STATE_DROPHILITED 0x0001 // MSW only >> +#define wxLIST_STATE_FOCUSED 0x0002 >> +#define wxLIST_STATE_SELECTED 0x0004 >> +#define wxLIST_STATE_CUT 0x0008 // MSW only >> +#define wxLIST_STATE_DISABLED 0x0010 // OS2 only >> +#define wxLIST_STATE_FILTERED 0x0020 // OS2 only >> +#define wxLIST_STATE_INUSE 0x0040 // OS2 only >> +#define wxLIST_STATE_PICKED 0x0080 // OS2 only >> +#define wxLIST_STATE_SOURCE 0x0100 // OS2 only >> + >> +// Hit test flags, used in HitTest >> +#define wxLIST_HITTEST_ABOVE 0x0001 // Above the client area. >> +#define wxLIST_HITTEST_BELOW 0x0002 // Below the client area. >> +#define wxLIST_HITTEST_NOWHERE 0x0004 // In the client area but below the last item. >> +#define wxLIST_HITTEST_ONITEMICON 0x0020 // On the bitmap associated with an item. >> +#define wxLIST_HITTEST_ONITEMLABEL 0x0080 // On the label (string) associated with an item. >> +#define wxLIST_HITTEST_ONITEMRIGHT 0x0100 // In the area to the right of an item. >> +#define wxLIST_HITTEST_ONITEMSTATEICON 0x0200 // On the state icon for a tree view item that is in a user-defined state. >> +#define wxLIST_HITTEST_TOLEFT 0x0400 // To the left of the client area. >> +#define wxLIST_HITTEST_TORIGHT 0x0800 // To the right of the client area. >> + >> +#define wxLIST_HITTEST_ONITEM (wxLIST_HITTEST_ONITEMICON | wxLIST_HITTEST_ONITEMLABEL | wxLIST_HITTEST_ONITEMSTATEICON) >> + >> +// Flags for GetNextItem (MSW only except wxLIST_NEXT_ALL) >> +enum >> +{ >> + wxLIST_NEXT_ABOVE, // Searches for an item above the specified item >> + wxLIST_NEXT_ALL, // Searches for subsequent item by index >> + wxLIST_NEXT_BELOW, // Searches for an item below the specified item >> + wxLIST_NEXT_LEFT, // Searches for an item to the left of the specified item >> + wxLIST_NEXT_RIGHT // Searches for an item to the right of the specified item >> +}; >> + >> +// Alignment flags for Arrange (MSW only except wxLIST_ALIGN_LEFT) >> +enum >> +{ >> + wxLIST_ALIGN_DEFAULT, >> + wxLIST_ALIGN_LEFT, >> + wxLIST_ALIGN_TOP, >> + wxLIST_ALIGN_SNAP_TO_GRID >> +}; >> + >> +// Column format (MSW only except wxLIST_FORMAT_LEFT) >> +enum wxListColumnFormat >> +{ >> + wxLIST_FORMAT_LEFT, >> + wxLIST_FORMAT_RIGHT, >> + wxLIST_FORMAT_CENTRE, >> + wxLIST_FORMAT_CENTER = wxLIST_FORMAT_CENTRE >> +}; >> + >> +// Autosize values for SetColumnWidth >> +enum >> +{ >> + wxLIST_AUTOSIZE = -1, >> + wxLIST_AUTOSIZE_USEHEADER = -2 // partly supported by generic version >> +}; >> + >> +// Flag values for GetItemRect >> +enum >> +{ >> + wxLIST_RECT_BOUNDS, >> + wxLIST_RECT_ICON, >> + wxLIST_RECT_LABEL >> +}; >> + >> +// Flag values for FindItem (MSW only) >> +enum >> +{ >> + wxLIST_FIND_UP, >> + wxLIST_FIND_DOWN, >> + wxLIST_FIND_LEFT, >> + wxLIST_FIND_RIGHT >> +}; >> + >> + >> >> //** ---------------------------------------------------------------------------- ** >> // Start constants from wx/button.h >> plain text document attachment (ListCtrl.patch) >> Index: wxruby2/swig/classes/ListCtrl.i >> =================================================================== >> RCS file: /var/cvs/wxruby/wxruby2/swig/classes/ListCtrl.i,v >> retrieving revision 1.6 >> diff -b -u -r1.6 ListCtrl.i >> --- wxruby2/swig/classes/ListCtrl.i 21 Aug 2005 01:55:44 -0000 1.6 >> +++ wxruby2/swig/classes/ListCtrl.i 28 Mar 2006 00:18:27 -0000 >> @@ -3,12 +3,15 @@ >> >> %include "../common.i" >> >> +%module(directors="1") wxListCtrl >> + >> +%rename(SetItemString) wxListCtrl::SetItem(long index, int col, const wxString& label, int imageId = -1); >> + >> %{ >> #include >> #include >> %} >> >> -%module(directors="1") wxListCtrl >> >> %ignore wxListCtrl::wxListCtrl(); >> // >> @@ -21,6 +24,7 @@ >> >> >> >> + >> %import "include/wxObject.h" >> %import "include/wxEvtHandler.h" >> %import "include/wxWindow.h" >> plain text document attachment (ListItem.i) >> # Copyright 2004-2005 by Kevin Smith >> # released under the MIT-style wxruby2 license >> >> %include "../common.i" >> >> %{ >> #include >> #include >> #include >> %} >> >> %module(directors="1") wxListItem >> %ignore wxListItem::GetText; >> >> >> %import "include/wxObject.h" >> >> >> %include "include/wxListItem.h" >> >> _______________________________________________ >> 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 fugalh at gmail.com Sat May 13 10:41:09 2006 From: fugalh at gmail.com (Hans Fugal) Date: Sat, 13 May 2006 08:41:09 -0600 Subject: [Wxruby-users] Status Message-ID: I've been looking in on WxRuby occasionally to see if it's ready foruse, because I like some of the precepts, esp. native widgets.Finally I decided to ask. How close is it to being easily installable on the three majorplatforms? deb or rpm on linux, binary installers on windows and osx.It has to be that easy for people to want to distribute applicationsto end users that use this toolkit. How usable is 0.6.0? As in would you recommend it for "production"use? And/or when will wxruby2 be declared stable? When wxruby2 doesarrive, will code written for 0.6.0 just work for the most part? These are things that I may be able to help with if they're within reach. From wxruby at qualitycode.com Sat May 13 12:17:56 2006 From: wxruby at qualitycode.com (Kevin Smith) Date: Sat, 13 May 2006 12:17:56 -0400 Subject: [Wxruby-users] Status In-Reply-To: References: Message-ID: <1147537077.8435.50.camel@localhost.localdomain> On Sat, 2006-05-13 at 08:41 -0600, Hans Fugal wrote: > How usable is 0.6.0? As in would you recommend it for "production"use? I would not recommend it for production use. It works reasonably well for small personal tools, and for playing around. > And/or when will wxruby2 be declared stable? "Any day now...or maybe not for several months". None of us are paid to work on it, so we go through phases of dedicating lots of time, and phases of doing very little. The predictable result is erratic progress and no ability for us to predict schedules in advance. I wish I could spend more time on it. > When wxruby2 doesarrive, will code written for 0.6.0 just work for the most part? Yes. There will be a few tweaks, but otherwise wxruby 0.6.0 code should work fine under wxruby2. > How close is it to being easily installable on the three major platforms? > deb or rpm on linux, binary installers on windows and osx. > It has to be that easy for people to want to distribute applications > to end users that use this toolkit. That is definitely our goal. First (and hopefully soon), we would have binary zips/tarballs for each of the three platforms. After that, we will probably create gems. Beyond that, we would probably encourage people to create rpms, debs, emerge scripts, and other OS-specific install packages. > These are things that I may be able to help with if they're within reach. That would be great. The structure of wxruby2 is unlikely to change, so if you want to experiment with creating packages for it, please do so. Thanks, Kevin From alex at pressure.to Sat May 13 12:32:33 2006 From: alex at pressure.to (Alex Fenton) Date: Sat, 13 May 2006 17:32:33 +0100 Subject: [Wxruby-users] Status In-Reply-To: References: Message-ID: <44660A21.3020800@pressure.to> Hi Hans Fugal wrote: > I've been looking in on WxRuby occasionally to see if it's ready foruse, because I like some of the precepts, esp. native widgets.Finally I decided to ask. > How close is it to being easily installable on the three majorplatforms? 0.6.0: installer on windows, standard .tar.gz compile on linux/os x wxruby2: no binaries available, but will be available for the upcoming preview release > deb or rpm on linux, binary installers on windows and osx.It has to be that easy for people to want to distribute applicationsto end users that use this toolkit. > You can use rubyscript2exe to bundle the wxruby binary as part of a standalone executable. This works on any platform. > How usable is 0.6.0? As in would you recommend it for "production"use? It doesn't implement the full WxWidgets API, but it's definitely stable enough for production use. Eg. Weft QDA: http://www.pressure.to/qda/ > And/or when will wxruby2 be declared stable? It's some way from stable. An alpha release is coming pretty soon. > When wxruby2 doesarrive, will code written for 0.6.0 just work for the most par > Yes. Code is pretty much completely portable between the two at the moment. > These are things that I may be able to help with if they're within reach. > We're pretty close to an alpha release. Compiling CVS HEAD and trying out a few of the samples is a good way to get started and see some wxruby code. cheers alex > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > From sdate at everestkc.net Sat May 13 13:07:48 2006 From: sdate at everestkc.net (Shashank Date) Date: Sat, 13 May 2006 12:07:48 -0500 Subject: [Wxruby-users] Status In-Reply-To: <44660A21.3020800@pressure.to> References: <44660A21.3020800@pressure.to> Message-ID: <44661264.3030406@everestkc.net> Hi Alex, Alex Fenton wrote: >We're pretty close to an alpha release. Compiling CVS HEAD and trying >out a few of the samples is a good way to get started and see some >wxruby code. > > I would love to try this ... compiling the CVS head on Windows (using MSVC++ 6.0) that is. Are there any special instructions I need to follow? Thanks, -- Shashank From fugalh at gmail.com Sat May 13 17:52:01 2006 From: fugalh at gmail.com (Hans Fugal) Date: Sat, 13 May 2006 15:52:01 -0600 Subject: [Wxruby-users] Status In-Reply-To: <44660A21.3020800@pressure.to> References: <44660A21.3020800@pressure.to> Message-ID: On 5/13/06, Alex Fenton wrote: > > How close is it to being easily installable on the three majorplatforms? > 0.6.0: installer on windows, standard .tar.gz compile on linux/os x> wxruby2: no binaries available, but will be available for the upcoming> preview release Unless something has changed drastically since the last time I triedit on OS X it is far from a standard compile. I never did get itworking. I'm afraid I don't remember the issues I was having indetail. > You can use rubyscript2exe to bundle the wxruby binary as part of a> standalone executable. This works on any platform. I wasn't aware that it worked on linux and osx. That's good to know. Thanks for your answers. -- Hans FugalFugal Computing From empower at smart.net Fri May 26 08:29:59 2006 From: empower at smart.net (Jamal Mazrui) Date: Fri, 26 May 2006 08:29:59 -0400 (EDT) Subject: [Wxruby-users] Advanced text editor developed with WxRuby Message-ID: I just joined this list, have info to share, and some questions. As background, I happen to be a blind person who uses a screen reader utility to operate the computer. I use the keyboard rather than mouse for input and the screen reader, called JAWS, provides output in synthetic speech. This generally works well for standard or common controls of Windows, which WxWidgets wraps (since they are native to the Windows OS). By contrast, other GUI libraries such as TK and FX do not result in accessible user interfaces for blind users because our screen readers do not understand the custom controls. I have developed a text editor, TextPal, with a rich feature set that is optimized for screen reader users. http://www.EmpowermentZone.com/palsetup.exe It should run on computers that do not have a screen reader running, but speech output would not occur, such as commands on the Query menu. The application is being well received by the blind community, since it offers many convenient features not available with other text or code editors. I am grateful for the developers of WxRuby for making the WxWidgets library available to the Ruby community. The sample programs, "Poor Man's Documentation," and Wiki have all helped me in developing TextPal. Questions for now are as follows: I notice that TextPal sometimes crashes fatally for no apparent reason. The cause could be errors in my code, but I wonder if the cause could also be memory management errors in the wrappers of the current stable release of WxRuby, which the ReadMe file acknowledges as being "early beta quality." My code mainly uses the menu system, multi-line edit control, and event methods. Are there general tips that can minimize the chance of a crash? I know that WxRuby2 has been in development for a while. Is there a binary version for Windows that I could now try? Is it now more stable than the previous wrappers? How does its feature set compare? TextPal is free and open source in the normal spirit of the Ruby community. By default, the installer places the source code at C:\Program Files\TextPal\TextPal.rbw Anyone can feel free to look at it for any tips they might get on how I implemented certain features (all described in the documentation). Unfortunately, the code is not visually formatted in a pleasing way at this point. In particular, the code is not indented since this makes programming more difficult rather than easier for me. Perhaps a run through the Ruby beautifier that someone developed would help sighted users. If anyone has tips on how I could improve the code, I would appreciate it. In particular, I am trying to better manage the sizes of the main window and the MDI child windows. Currently, if one maximizes the main TextPal window, it does not occupy the whole desktop. A more bothersome problem is that the cursor gets stuck when down arrowing at the bottom of an edit window. The Ed_Maximize method responds to a Windows sizing event, so perhaps the solution lies in correcting this code. Of course, feel free to ask me any questions. I also welcome feedback and suggestions. Regards, Jamal