boa-constructor-users

Re: [Boa Constr] error starting boa 0.1.5

[Marius T. <ma...@it...>]

Now it breaks again like it does in windows:

Traceback (most recent call last):
  File "Boa.py", line 574, in ?
    main()
  File "Boa.py", line 555, in main
    app = BoaApp()
  File "Boa.py", line 378, in __init__
    wxApp.__init__(self, false)
  File "/usr/lib/python2.2/site-packages/wxPython/wx.py", line 1581, in 
__init__
    _wxStart(self.OnInit)
  File "Boa.py", line 421, in OnInit
    self.main.initPalette(inspector, editor)
  File "/home/marius/boa/boa_0.1.5/boa/Palette.py", line 174, in initPalette
    wxGenBitmapButton)
  File "/home/marius/boa/boa_0.1.5/boa/Palette.py", line 487, in addButton2
    mID = PanelPalettePage.addButton(self, name, Controller, None, 
self.OnClickTrap, None, None, btnType)
  File "/home/marius/boa/boa_0.1.5/boa/Palette.py", line 454, in addButton
    wxSize(width, height))
  File "/usr/lib/python2.2/site-packages/wxPython/lib/buttons.py", line 
323, in __init__
    wxGenButton.__init__(self, parent, ID, "", pos, size, style, 
validator, name)
  File "/usr/lib/python2.2/site-packages/wxPython/lib/buttons.py", line 
78, in __init__
    self.InitColours()
  File "/usr/lib/python2.2/site-packages/wxPython/lib/buttons.py", line 
142, in InitColours
    self.SetBackgroundColour(faceClr)
  File "/usr/lib/python2.2/site-packages/wxPython/lib/buttons.py", line 
154, in SetBackgroundColour
    wxWindow.SetBackgroundColour(self, colour)
TypeError: unbound method SetBackgroundColour() must be called with 
wxWindow instance as first argument (got wxGenBitmapButton instance instead)



Riaan Booysen wrote:

>>Thanks Riaan for so fast fix!
>>
>
>You mean thanks for breaking it again so fast :)
>
:):):)

Thanks again:)

Marius

RE: [Boa Constr] error starting boa 0.1.5

[Riaan B. <ri...@tb...>]

> Thanks Riaan for so fast fix!

You mean thanks for breaking it again so fast :)

> Now I get a different message before crashing on Linux:
> 
> Traceback (most recent call last):
>   File "Boa.py", line 574, in ?
>     main()
>   File "Boa.py", line 555, in main
>     app = BoaApp()
>   File "Boa.py", line 378, in __init__
>     wxApp.__init__(self, false)
>   File "/usr/lib/python2.2/site-packages/wxPython/wx.py", line 1581, in 
> __init__
>     _wxStart(self.OnInit)
>   File "Boa.py", line 407, in OnInit
>     self.main.componentSB, self, self.main)
>   File "/home/marius/boa/boa_0.1.5/boa/Editor.py", line 209, in __init__
>     'Switch to the Inspector frame.')
>   File "/home/marius/boa/boa_0.1.5/boa/Utils.py", line 913, in 
> appendMenuItem
>     if wxPlatform == '__WXGTK__' and wxVersion >= (2,3,3) or \
> NameError: global name 'wxVersion' is not defined

Aargh, well obviously that bit didn't run on windows where I
quickly tested, fixed now (I hope!!!)
Try again please.

Thanks,
Riaan.

Re: [Boa Constr] error starting boa 0.1.5

[Marius T. <ma...@it...>]

Thanks Riaan for so fast fix!

Now I get a different message before crashing on Linux:

Traceback (most recent call last):
  File "Boa.py", line 574, in ?
    main()
  File "Boa.py", line 555, in main
    app = BoaApp()
  File "Boa.py", line 378, in __init__
    wxApp.__init__(self, false)
  File "/usr/lib/python2.2/site-packages/wxPython/wx.py", line 1581, in 
__init__
    _wxStart(self.OnInit)
  File "Boa.py", line 407, in OnInit
    self.main.componentSB, self, self.main)
  File "/home/marius/boa/boa_0.1.5/boa/Editor.py", line 209, in __init__
    'Switch to the Inspector frame.')
  File "/home/marius/boa/boa_0.1.5/boa/Utils.py", line 913, in 
appendMenuItem
    if wxPlatform == '__WXGTK__' and wxVersion >= (2,3,3) or \
NameError: global name 'wxVersion' is not defined

Seems to be from your last fix. I didn't tried on windows yet.

Thanks!

RE: [Boa Constr] error starting boa 0.1.5

[Riaan B. <ri...@tb...>]

Hi Marius,

> Hi!
>
> I just checked out latest source. I get an error starting Boa on Linux:
>
>   File "Boa.py", line 574, in ?
>     main()
>   File "Boa.py", line 555, in main
>     app = BoaApp()
>   File "Boa.py", line 378, in __init__
>     wxApp.__init__(self, false)
>   File "/usr/lib/python2.2/site-packages/wxPython/wx.py", line 1581, in
__init__
>     _wxStart(self.OnInit)
>   File "Boa.py", line 407, in OnInit
>     self.main.componentSB, self, self.main)
>   File "/home/marius/boa/boa_0.1.5/boa/Editor.py", line 209, in __init__
>     'Switch to the Inspector frame.')
>   File "/home/marius/boa/boa_0.1.5/boa/Utils.py", line 913, in
appendMenuItem
>     menuItem.SetBitmap(Preferences.IS.load(bmp))
> AttributeError: wxMenuItem instance has no attribute 'SetBitmap'
>
> Indeed wxMenuItem class does not have this attribute on wxPython 2.3.2.

Damn, it does on windows :(

>
> Do I need to run with wxPython 2.3.3?

No, not necessary (unless you want images on your menus ;) I've checked in a
workaround for wxGTK to Utils.py.

Thanks,
Riaan.

[Boa Constr] error starting Boa 0.1.5 on Windows

[Marius T. <ma...@it...>]

I got a different startup error on Windows:

"unbound method SetBackgroundColour() must be called with wxWindow 
instance on fiorst argument (got wxGenBitmapButton instead)"

issued from AddButton from Pallete.py

Thanks,

-- 
Marius Trestioreanu 

[Boa Constr] error starting boa 0.1.5

[Marius T. <ma...@it...>]

Hi!

I just checked out latest source. I get an error starting Boa on Linux:

  File "Boa.py", line 574, in ?
    main()
  File "Boa.py", line 555, in main
    app = BoaApp()
  File "Boa.py", line 378, in __init__
    wxApp.__init__(self, false)
  File "/usr/lib/python2.2/site-packages/wxPython/wx.py", line 1581, in 
__init__
    _wxStart(self.OnInit)
  File "Boa.py", line 407, in OnInit
    self.main.componentSB, self, self.main)
  File "/home/marius/boa/boa_0.1.5/boa/Editor.py", line 209, in __init__
    'Switch to the Inspector frame.')
  File "/home/marius/boa/boa_0.1.5/boa/Utils.py", line 913, in 
appendMenuItem
    menuItem.SetBitmap(Preferences.IS.load(bmp))
AttributeError: wxMenuItem instance has no attribute 'SetBitmap'

Indeed wxMenuItem class does not have this attribute on wxPython 2.3.2.

Do I need to run with wxPython 2.3.3?

Thanks,

-- 
Marius Trestioreanu 

[Boa Constr] Docs checked in

[Riaan B. <ri...@tb...>]

Hi everyone,

I've checked in the Boa application help and tutorial.

Hope this helps some of you,
Riaan.

RE: [Boa Constr] Problem installing zoa object

[Riaan B. <ri...@tb...>]

Hi Laurence,

> Hi,
> 
> I've just installed boa from cvs and am having problems connecting to a 
> zope server. When I click on my zope server in explorer I get a message 
> asking me if I want to install zoa as it is not found at the root of my 
> zope tree. I click yes and get an the following error:
> 
> bci.Unauthorized: bobo exception (File: 
> usr/lib/zope/lib/python/ZPublisher/HTTPResponse.py Line: 533)
> 401 Unauthorized for http://www.su.umist.ac.uk:9673///manage_addFolder
> 
> (Traceback at bottom of post)
> 
> It would seem that it can't authorize with my zope server, but I've 
> checked and double checked the username and password in my 
> Explorer.msw.cfg and it is correct. here is the relevant part (password 
> obscured ;-):

Yes, the Unauthorized exception is the big clue ;)

The passwords are stored in Explorer.*.cfg in a scrambled format,
so the password you added is unscrambled (wrongly in your case)
before being passed to Zope.

If you set your password thru the Inspector (right-click Inspect from the 
Zope Connection) it will be stored correctly.

If you really want to edit the Explorer.*.cfg manually, you can scramble
a password manually like this (on the Boa Shell):

>>> from Explorers import scrm
>>> scrm.scramble('****')
'ALLLL'

PS. Boa overwrites the Explorer.*.cfg on exit so first close Boa before 
editing the file.

> P.S. Boa looks great from the little of it I have seen so far - keep up 
> the good work!

Great, enjoy!

Cheers,
Riaan.

[Boa Constr] Problem installing zoa object

[Laurence R. <lau...@lr...>]

Hi,

I've just installed boa from cvs and am having problems connecting to a 
zope server. When I click on my zope server in explorer I get a message 
asking me if I want to install zoa as it is not found at the root of my 
zope tree. I click yes and get an the following error:

bci.Unauthorized: bobo exception (File: 
usr/lib/zope/lib/python/ZPublisher/HTTPResponse.py Line: 533)
401 Unauthorized for http://www.su.umist.ac.uk:9673///manage_addFolder

(Traceback at bottom of post)

It would seem that it can't authorize with my zope server, but I've 
checked and double checked the username and password in my 
Explorer.msw.cfg and it is correct. here is the relevant part (password 
obscured ;-):

zope = {'www.su':
          {'host': 'www.su.umist.ac.uk',
           'httpport': 9673,
           'ftpport': 8021,
           'username': 'admin',
           'passwd': '****',
           'path': '/',
           'name': '',
           'localpath': ''} }

No sign of any folders appearing in the ZMI after this happens.

On the zope server I run:
  Zope Version
(Zope 2.5.1 (source release, python 2.1, linux2), python 2.1.3, linux2)
Python Version
2.1.3 (#1, Sep 7 2002, 15:29:56) [GCC 2.95.4 20011002 (Debian prerelease)]

On my (win2000) machine I run:
python.org installer installed python 2.2.2
CVS (from today) Boa 0.1.5

I've probably missed something obvious, but I'm completely stuck - so 
all help greatfully recieved!

Laurence

P.S. Boa looks great from the little of it I have seen so far - keep up 
the good work!

P.P.S here's the traceback:
17:46:01:     bci.Unauthorized: bobo exception (File: 
/usr/lib/zope/lib/python/ZPublisher/HTTPResponse.py Line: 533)
17:46:01: 401 Unauthorized for 
http://www.su.umist.ac.uk:9673///manage_addFolderTraceback (most recent 
call last):
17:46:01:     bci.Unauthorized: bobo exception (File: 
/usr/lib/zope/lib/python/ZPublisher/HTTPResponse.py Line: 533)
17:46:01: 401 Unauthorized for 
http://www.su.umist.ac.uk:9673///manage_addFolder  File 
"C:\boa\Explorers\Explorer.py", line 689, in OnSelect
17:46:01:     self.selectTreeItem(item) 

17:46:01:       File "C:\boa\Explorers\Explorer.py", line 656, in 
selectTreeItem
17:46:01:     self.list.refreshItems(imgs, data) 

17:46:01:       File "C:\boa\Explorers\Explorer.py", line 500, in 
refreshItems
17:46:01:     try: items = explNode.openList() 

17:46:01:       File "C:\boa\ZopeLib\ZopeExplorer.py", line 208, in 
openList
17:46:01:     os.path.join(Preferences.pyPath, 'ZopeLib', 'zoa', )) 

17:46:01:       File "C:\boa\ZopeLib\ZoaClient.py", line 57, in 
installFromFS
17:46:01:     installZopeFolder(conninfo, name) 

17:46:01:       File "C:\boa\ZopeLib\ZoaClient.py", line 53, in 
installZopeFolder
17:46:01:     z.manage_addFolder(id=name) 

17:46:01:       File "C:\boa\ZopeLib\ZoaClient.py", line 39, in __call__ 

17:46:01:     return apply(self.__request, (self.__name,) + args, 
kwargs)
17:46:01:       File "C:\boa\ZopeLib\ZoaClient.py", line 27, in 
__request
17:46:01:     args, kwargs) 

17:46:01:       File "C:\boa\ZopeLib\Client.py", line 226, in __call__ 

17:46:01:     self.handleError(query, ec, em, headers, response) 

17:46:02:       File "C:\boa\ZopeLib\Client.py", line 241, in 
handleError
17:46:02:     raise t, 
RemoteException(t,v,f,l,self.url,query,ec,em,response)
17:46:02:     bci.Unauthorized: bobo exception (File: 
/usr/lib/zope/lib/python/ZPublisher/HTTPResponse.py Line: 533)
17:46:02: 401 Unauthorized for 
http://www.su.umist.ac.uk:9673///manage_addFolder

RE: [Boa Constr] SSHExplorer

[Riaan B. <ri...@tb...>]

Hi Rasjid,

> A very very belated response to this...

No problem, glad you did in the end.

> On Wed, 30 Oct 2002 8:30 pm, Riaan Booysen wrote:
> > Personally I don't want to tie Boa to cygwin. Can't your library also
> > use a single ssh.exe/scp.exe setup. (I can mail these exes to you if
> > you don't have them)
>
> I'd rather know the source of these non-putty, non-cygwin
> executables, as the
> putty ones do not work well with PySSH, and I'd like to see if these do.

Not exactly sure about the sources for the exes, inside them is a BSD
copyright notice.

I suspect it's just the OpenSSH sources (of a while back) compiled with
MinGW.

I've mailed you the exes I have.

Cheers,
Riaan.

Re: [Boa Constr] SSHExplorer

[Rasjid W. <ra...@op...>]

A very very belated response to this...

On Wed, 30 Oct 2002 8:30 pm, Riaan Booysen wrote:
> Personally I don't want to tie Boa to cygwin. Can't your library also
> use a single ssh.exe/scp.exe setup. (I can mail these exes to you if
> you don't have them)

I'd rather know the source of these non-putty, non-cygwin executables, as the 
putty ones do not work well with PySSH, and I'd like to see if these do.

Cheers,

Rasjid.

-- 
Rasjid Wilcox
Canberra, Australia (UTC +10 hrs)
http://www.openminddev.net

[Boa Constr] CVS updated - 0.1.5

[Riaan B. <ri...@tb...>]

Hi everyone,

I've updated the repository with the latest changes.

Again, it was quite a big checkin, so please give it
a test if you have the time.

Changes:
* Generated source can now be wrapped over multiple lines.
  Lines are only broken up after commas, inside brackets,
  but this works well enough.
  3 new Preferences added to the General->Code generation
  section. This feature is now on by default.
* I've abandoned the strategy of renaming plug-ins to disable them. 
  This was too unfriendly for things like CVS.
  Also plug-ins can now be ordered.
  Both these changes are implemented with a new file called
  __init__.plug-in.py in your Plug-ins directory which defines the 
  list of disabled and ordered plugin names.
  Ordered plug-ins are executed first (in order!) 
  Everything can be managed thru the GUI under
  Preferences->Plug-ins->Plug-in files.
* Improved Find/Replace dialog.
  Now supports 'Find in files' and seaching in the Explorer.
  Thanks to Roman Yakovenko for the patches!
* Refactored Controller menu/toolbar definitions to use the
  same format that View menu/toolbar definitions uses.
  One visible result of this is that menu items can now display images.
* Improved tab support. The frame designer can now properly generate 
  tab indented code.
  People who care about this, please test as I don't use this.  
* Added ImageEditor.plug-in.py.
  This is an image editor I hacked up ages ago.
  (I needed masked PNG support!)
  I just wrapped up the editor as a Boa View.
  It's rough but it works ;)
  (Hint: When editing images with masks, set the mask again before
         saving, otherwise the previous mask is used)
* Shortcut keys now work better on Linux (Ctrl-S works!!!).
* Composite controls like wxGrid now work properly in the Designer 
  on Linux.
  Unfortunately many other controls still misbehave on Linux :(
* Added wxSpinCtrl
* Zope: Added SiteErrorLog support. 
  Just delete your zoa folder in your Zope root and the new
  zoa will be automatically installed.
* Removed the bundled PyChecker from the repository.
  Boa now tries to use the one installed on your system.

OGL views currently display all their labels twice.
This has been fixed in wxPython 2.4.0.

For me wxAcceleratorTables do not work under Linux.
(This is not the same as shortcuts mentioned above!)
They do for Robin, so I'd like to know if anyone else is having
this problem. To test, use the cursor keys to change the active 
property in the Inspector. Feedback appreciated.

I hoped to check in the Boa core docs back into the repository
for this CVS release, but ran out of time. Hope to get to it tonight.

This (except for bugfixes) will be the 0.2.0 release so send me
feedback asap please.

Cheers,
Riaan.

RE: [Boa Constr] Running Boa

[Riaan B. <ri...@tb...>]

Hi Salim,

> This is my first time running Boa (and also getting in touch with Python)
> and I get the error "Error on startup: 'flags' is an invalid keyword
> argument for this function" when I click on the file boa.py.
> Python 2.2 and the package wxPython 2.3.2 have been properly installed.
> Any hint ?

Are you sure you are running Boa on 2.3.2, because that error only happens
on Boa 0.1.0 with wxPython 2.3.3 and higher.

Do you have other versions of Python/wxPython installed?

Try running Boa from the command-line, e.g.

While in the Boa directory type:

c:\Path\To\Python2.2\python.exe Boa.py

Cheers,
Riaan.

[Boa Constr] Running Boa

[Salim R. S. <ss...@ra...>]

This is my first time running Boa (and also getting in touch with Python)
and I get the error "Error on startup: 'flags' is an invalid keyword
argument for this function" when I click on the file boa.py.
Python 2.2 and the package wxPython 2.3.2 have been properly installed.
Any hint ?

Thanks in advance,

Salim R. Sátiro

[Boa Constr] Re: RFE

[Yuppie <yu...@ze...>]

Riaan Booysen wrote:
>><http://boa-constructor.sourceforge.net/Download.html>
[...]
> Well, the last line of Download.html tells people to get
> CVS if they need to use 2.3.3. This is what you requested.

Didn't know the recommended version for people who don't "need to use 
wxPython 2.3.3" is still Boa Constructor 0.1.0.


Cheers,

Yuppie

RE: [Boa Constr] RFE

[Riaan B. <ri...@tb...>]

> > Just making sure, you know about the Name property you should
> > set in the Inspector? Is this really that bad?
>
> Yes, I know about it. I also know that my app and frame won't be
> named what
> I want them named until I do a "save as..." in the editor (and
> that doesn't
> always work correctly beyond the app and frame files). UGH.

At some stage in the average project's life you will have to do
a "save as".

The Designer maintains the wxPython derived class (e.g. wxFrame1)
The Editor maintains Python modules (e.g. wxFrame1.py).
By default they have the same name because I encourage the
use of the "modulename == main class name" convention for
generated frame modules. But I certainly won't enforce this
convention.
From the application file, the modules are only referenced
by module name and a generic 'create' function.

Frame type modules do not reference the application module.
If you rename (save as) such a module, when the application
module is not open in the IDE, the application file
won't be updated. Maybe this happened to you.

If you have some test case for which save as does not work,
please send it to me.

>
> > > I would prefer this to renaming the
> > > control after I have created it! For those who either don't mind
> > > it or don't
> > > want it, either a suggested default name could be in the dialog
> > name edit
> > > control when the dialog control comes up so that the user can just hit
> > > "enter" or it could be a preferences option. It looks as though
> > > it would be
> > > a simple matter of modifying DesignerView.newControl(), at least
> > > for having
> > > the dialog all the time. No idea of how to make it a user preference.
> >
> > As the current practice is the same as Delphi and other GUI builders,
> > it will stay the default behaviour.
> > We could have a 'dsPromptForNameAtCreate' preference setting.
> > But I'm not convinced yet.
>
> Oh good, every other brain dead GUI builder does it this way, so
> Boa should
> do it this way! I've really noticed how Delphi and "other GUI
> builders" are
> such market leaders. If Delphi where as bad as Boa (which, it's not), then
> it's no wonder that Delphi and Pascal are niche products (which,
> they are!).
> Ending up with a bunch of classes and controls named
> wx<something>1 through
> wx<something>n makes for virtually unmaintainable, undebuggable code.
> Generating code with 200+ character lines doesn't help either!

I repeat, click on the Name property of your controls and change it!!!

If you have test cases that causes Designer crashes they have a much bigger
chance of getting fixed if you send them to me.

Riaan.

RE: [Boa Constr] wxGrid problem

[Riaan B. <ri...@tb...>]

Hi Marius,

> > I am running Boa 0.1.4 on both Linux and Windows. There is a misterious
> > problem with wxGrid on Linux/Mandrake. After adding a wxGrid on a panel,
> > closing the Designer and opening it again, the wxGrid object cannot be
> > selected any more. On Windows there is no problem selecting it again.
>
> The first time it was only selected because it was the active object
> after being created.
>
> This is unfortunately a very tricky problem to fix. A few other controls
> also behave like this.
>
> The problem is that some controls (usually composit controls) don't
> respond to mouse click and motion events. On windows it works ok because
> when such controls are disabled, the events are passed to the parent
> where they can be caught.
>
>
> I think I may have found a fix!
>
> It seems that if I bind the events to the grid's internal sub children
> (GetChildren) I can catch them :)
>
> I will report back later if I can implement this as a generic fix in the
> Designer.

Ok, I implemented this strategy, but it only works well for the wxGrid.

Other controls like wxDynamicSashWindow still don't behave properly,
here (at least on windows) the strategy of disabling the control (so the
parent handles the events) still works better.

I will update the CVS repository this weekend.
That update (0.1.5) will be the pre release for the actual 0.2.0 release
next week. That's the plan, let's hope I make it!

Cheers,
Riaan.

RE: [Boa Constr] RFE

[David L. <wh...@oz...>]

Actually, I too have a lot of respect for Riaan's work. He's done a lot and
maybe that's why I have expectations.

As it happens, I have used the full version of Wing (1.4) - it's poor user
design is frustrating too, and it doesn't have features Boa has!

I have phase.Java.my.through.gone and if I ever feel the need for
senselessly long class names, rapidly changing APIs, ghastly GUIs or want
the paranoid schizophrenic of computer languages, I know where to go ;)

Hopefully, Robin will spend some of the time/money he's getting to improve
wxPython on better doc, but I doubt it will happen. Doc isn't glamorous,
even though it's often the difference between a sucessful product and not.

Yes Riaan, please keep up the good work and please, get the sink in order
before pulling in the rest of the kitchen!

David LeBlanc
Seattle, WA USA

> -----Original Message-----
> From: boa...@li...
> [mailto:boa...@li...]On Behalf Of
> Rasjid Wilcox
> Sent: Monday, December 16, 2002 5:02
> To: boa...@li...
> Subject: Re: [Boa Constr] RFE
>
<snip>
> Personally, I have nothing but admiration for people like Riaan,
> and I only
> hope that I can contribute as much to the open-source community
> as time goes
> by.  Keep up the good work Riaan.
>
> Cheers,
>
> Rasjid.
>
>
> --
> Rasjid Wilcox
> Canberra, Australia (UTC +10 hrs)
> http://www.openminddev.net
>

Re: [Boa Constr] RFE

[Rasjid W. <ra...@op...>]

On Mon, 16 Dec 2002 12:00 pm, David LeBlanc wrote:
<big snip>
> I'm almost sorry about the sarcasm in this mail, but I've just lost all my
> work in Boa _again_ and I feel like sharing the "joy"! Boa has promise -
> what it delivers currently is FRUSTRATION!!!

David,

Boa is a 0.1.4 version release!  It rates itself as ALPHA status software on 
the sourceforge page.  Boa is *going* to have bugs.  It could even delete all 
your files and crash your system.  Alpha software is always run at your own 
risk.  (Actually, this is true of most software, read the EULA's of pretty 
much anything.)  If Boa claimed too be stable (or even late Beta) then your 
comments _might_ be justified.  But under the circumstances I think they are 
very unfair.

Having worked on a few very small projects myself, I know how important 
encouraging feedback from users is.  Constructive critisism is fine - venting 
your frustrations publically just because an alpha producted caused you to 
loose your work does little to help the cause.

As with most open-source projects, if you don't like something, you at least 
have the option of doing something about it and perhaps even fixing it.

Don't like the fact that the wxWindows docs and wxPython docs are out of date, 
incorrect or non-existant?  Well, you could always download all the source 
code, learn it, understand it, and write the docs so that no-one else has to 
go through the sorrow that you have.

Don't like the way that Boa does something.  Change it and submit patches.

Your other options are:
a) Pay someone to make the changes you want, or
b) Use some other software (possibly commercial software).

Google shows Wing IDE, which is only US$35 for the Lite version, or $149-$179 
for the standard version.  Perhaps that is what you need?

For a completely different solution, if you really want a (free) open-source 
IDE and have an interest in Java, then have a look at NetBeans.  Looks very 
mature.  It even has some support for Jython.

As a last resort, you could always ask Riaan for your money back.  I'm sure 
he'd oblidge.

Personally, I have nothing but admiration for people like Riaan, and I only 
hope that I can contribute as much to the open-source community as time goes 
by.  Keep up the good work Riaan.

Cheers,

Rasjid.


-- 
Rasjid Wilcox
Canberra, Australia (UTC +10 hrs)
http://www.openminddev.net

RE: [Boa Constr] RFE

[David L. <wh...@oz...>]

> Hi David,
>
> > I have two requests for feature enhancements:
> >
> > 1. I would like to have a dialog pop up inviting me to give my
> own name to
> > an app or control when it's created. It's a lot easier to figure
> > out what's
> > going on if I can call something nameLstBox instead of wxlstbox3 (or
> > whatever: not a real world example).
>
> Just making sure, you know about the Name property you should
> set in the Inspector? Is this really that bad?

Yes, I know about it. I also know that my app and frame won't be named what
I want them named until I do a "save as..." in the editor (and that doesn't
always work correctly beyond the app and frame files). UGH.

> > I would prefer this to renaming the
> > control after I have created it! For those who either don't mind
> > it or don't
> > want it, either a suggested default name could be in the dialog
> name edit
> > control when the dialog control comes up so that the user can just hit
> > "enter" or it could be a preferences option. It looks as though
> > it would be
> > a simple matter of modifying DesignerView.newControl(), at least
> > for having
> > the dialog all the time. No idea of how to make it a user preference.
>
> As the current practice is the same as Delphi and other GUI builders,
> it will stay the default behaviour.
> We could have a 'dsPromptForNameAtCreate' preference setting.
> But I'm not convinced yet.

Oh good, every other brain dead GUI builder does it this way, so Boa should
do it this way! I've really noticed how Delphi and "other GUI builders" are
such market leaders. If Delphi where as bad as Boa (which, it's not), then
it's no wonder that Delphi and Pascal are niche products (which, they are!).
Ending up with a bunch of classes and controls named wx<something>1 through
wx<something>n makes for virtually unmaintainable, undebuggable code.
Generating code with 200+ character lines doesn't help either!

<snip>

Between the crappy wxWindows doc (available events by control anyone?), the
virtually non-existant wxPython doc, virtually non-existant and/or incorrect
Boa doc, and Boa's MANY bugs and design deficiencies (clue: debug menu items
belong on a debug menu, not on the file and edit menus, tool items belong on
a tools menu, not on the file or edit or view menu etc. etc. ETC.), I'm
terminally frustrated with the whole mess. I've found it easier and FASTER
to just take snippets out of the wxPython demo then use Boa. There are just
too many ways to do something that Boa doesn't like that can't be recovered
from and one ends up losing all one's work.

How about concentrating on the core functionality and less on the bells and
whistles that many people are not likely to use - like SSH, CVS and Zope!

I'm almost sorry about the sarcasm in this mail, but I've just lost all my
work in Boa _again_ and I feel like sharing the "joy"! Boa has promise -
what it delivers currently is FRUSTRATION!!!

David LeBlanc
Seattle, WA USA

RE: [Boa Constr] Latest CVS Boa and Linux.

[Riaan B. <ri...@tb...>]

Hi Mike,

> Hi, Boa fans,
>
>    currently I have big troubles with running CVS Boa on Linux
> (Python 2.2.2, wxWindows 2.3.3.1). After splash screen and
> importing lot of things:
>
> ...
> importing Explorers.DAVExplorer
> importing Explorers.SSHExplorer
> attaching wxPython doc strings
> showing main frames
>
> there is a momentary flash of some windows and Boa dies with:
>
> Gdk-ERROR **: BadWindow (invalid Window parameter)
>   serial 12256 error_code 3 request_code 2 minor_code 0
> Gdk-ERROR **: BadWindow (invalid Window parameter)
>   serial 12257 error_code 3 request_code 2 minor_code 0
>
>   Last time I run Boa successfully it was with old 0.1.alpha and
> older wxWindows, but I want to see
> the new improvements :-)  There is something weird, maybe, on our
> server, but I cannot figure what...
>
>   Someone have seen something similar?

Does this happen every time?

Run Boa with flag -T and see the file Boa.trace for the execution log.
Can you see where it stops?

This may be similar to a previously reported problem, but I cannot reproduce
it yet.

Thanks,
Riaan.

RE: [Boa Constr] Re: RFE

[Riaan B. <ri...@tb...>]

> Riaan Booysen wrote:
> > Updated. (And fixed another SSHExplorer bug ;)
> 
> ???
> Couldn't find any updates. Not of
> <http://boa-constructor.sourceforge.net/Download.html>
> and not of SSHExplorer :-(

Well, the last line of Download.html tells people to get
CVS if they need to use 2.3.3. This is what you requested.

I've not updated SSHExplorer in CVS yet.

Cheers,
Riaan.

RE: [Boa Constr] wxGrid problem

[Riaan B. <ri...@tb...>]

Hi Marius,

(Did you know Marius is also a common South African name ? ;)

> Hi!
>
> I am using Boa to develop a medical management GUI and it's a great
> tool, big thanks Riaan and all other guys that developed it! I am hoping
> for a beta version:)

Thanks.

> Just to share experience, I am using sizers to encapsulate controls. As
> I understand there is no plan to add sizers to Boa, but I could add all
> controls to sizers in a separate method which I call on
>  wxFrame.__init__  right after _init_ctrls(). There is no conflict with
> the code generated by Boa.

Glad it works, that's the way I recommend to used sizers with Boa.

For the record, there is a plan to add sizers to Boa at some stage.
It's just a big undertaking as Boa is fundamentally coordinate based and
the current code generation cannot handle the parallel hierarchy
of Sizers (they are not windows).

> I am running Boa 0.1.4 on both Linux and Windows. There is a misterious
> problem with wxGrid on Linux/Mandrake. After adding a wxGrid on a panel,
> closing the Designer and opening it again, the wxGrid object cannot be
> selected any more. On Windows there is no problem selecting it again.

The first time it was only selected because it was the active object
after being created.

This is unfortunately a very tricky problem to fix. A few other controls
also behave like this.

The problem is that some controls (usually composit controls) don't
respond to mouse click and motion events. On windows it works ok because
when such controls are disabled, the events are passed to the parent
where they can be caught.


I think I may have found a fix!

It seems that if I bind the events to the grid's internal sub children
(GetChildren) I can catch them :)

I will report back later if I can implement this as a generic fix in the
Designer.

Cheers,
Riaan.

RE: Re[2]: [Boa Constr] Db>

[Riaan B. <ri...@tb...>]

Hi Paolo,

> 
> Hello Riaan,
> 
> Thursday, December 12, 2002, 2:20:43 AM, you wrote:
> 
> RB> Basically no, as you might guess it's eval'ed on the 
> DebuggerServer side
> RB> so statements aren't allowed, only expressions.
> 
> RB> I'd like to improve this at at some stage. It's a todo.
> 
> Thanks for the reply! Tomorrow morning I've given a **fast** look to
> IsolatedDebugger...
> 
> What's the problem with that diff? It seems quite painless at a first
> look...

Thanks, but I'd prefer not to have the special '!' meaning.

Below is a minimal 'shell prompt' implementation.

I prefer the output of pformat, but oh well.
I've turned on line wrapping in the shell, should help.

Cheers,
Riaan.

--

Index: IsolatedDebugger.py
===================================================================
RCS file: /cvsroot/boa-constructor/boa/Debugger/IsolatedDebugger.py,v
retrieving revision 1.22
diff -u -r1.22 IsolatedDebugger.py
--- IsolatedDebugger.py	26 Apr 2002 16:11:26 -0000	1.22
+++ IsolatedDebugger.py	14 Dec 2002 18:33:46 -0000
@@ -1083,6 +1083,16 @@
         except: clss_items = []
         return inst_items + clss_items
 
+    def pythonShell(self, code, globalsDict, localsDict, name='<debug>'):
+        from StringIO import StringIO
+
+        _ts, sys.stdout = sys.stdout, StringIO('')
+        try:
+            exec compile(code, name, 'single') in globalsDict, localsDict
+            return sys.stdout.getvalue()
+        finally:
+            sys.stdout = _ts
+
     def pprintVarValue(self, expr, frameno):
         frame = self.getFrameByNumber(frameno)
         if frame is None:
@@ -1090,8 +1100,9 @@
         else:
             try:
                 globalsDict, localsDict = self.getFrameNamespaces(frame)
-                v = eval(expr, globalsDict, localsDict)
-                return pprint.pformat(v)
+                #v = eval(expr, globalsDict, localsDict)
+                #return pprint.pformat(v)
+                return self.pythonShell(expr, globalsDict, localsDict)
             except:
                 t, v = sys.exc_info()[:2]
                 import traceback

RE: [Boa Constr] Re: Zope Support

[Riaan B. <ri...@tb...>]

Hello Yuppie,

> Hi Riaan!
>
>
> Riaan Booysen wrote:
> > From my investigations into this it looks like CMF objects can
> be wrapped
> > just like all the other Zope objects currently supported.
>
> There's on thing that could cause trouble:
> Some meta types (e.g. 'Document') have a different text format ('html',
> 'structured-text' or 'plain') depending on their text_format attribute.
> How would I implement different editing views for one Node class
> depending on an attribute? Or how would I get different Node classes for
> instances of one meta type?

Ouch, this could be painful.

I suggest a workaround like this:
Let zoa/metatype return Document:html, Document:structured-text or
Document:plain.
Then can have 3 Node classes for the different types (with a common base
class to capture shared behaviour)

This is not ideal, do many CMF objects work like this?

> >>The Zope plug-ins are very different to the other plug-ins.
> Looks like a
> >>unified plug-in interface would be very helpful for updating the
> >>ZopeExplorer to Zope 2.6 or writing a CMF plug-in.
> >
> > No. Those comments aren't that accurate anymore.
> > It has already been unified in the sense that
> > Editor.openOrGotoModule('zope://Connection/<meta>/path/obj')
> > works correctly and that Zope items can be bookmarked.
>
> One thing that confused me was this:
>
> Views are defined
> - for Zope in the node as defaultViews / additionalViews
> - for the rest in the controller as DefaultViews / AdditionalViews

Yes that's the way it is (part history, part necessity), don't worry about
it,
all the Zope support works like this.

It's better this way because there is currently just one Zope Controller
class. If the view definitions moved to Controllers I'd have to
mirror all the Node classes.

> > Nevermind the differences between Zope transports and the simple
> > transports, just use the current Zope support as examples,
> > they all follow basically the same model.
>
> Maybe you could give me some hints. I quote ZopePTHTMLView because I
> have some questions about it.

ZopePTHTMLView is a bit non standard.

>
> class ZopePTHTMLView(ZopeViews.ZopeHTMLView):
>      viewName = 'Source.html'
>      def generatePage(self):
>          props = self.model.zopeObj.properties
>          url = 'http://%s:%s@%s:%d/%s/source.html'%(props['username'],
>                props['passwd'], props['host'], props['httpport'],
>                self.model.zopeObj.whole_name())
>          import urllib
>          f = urllib.urlopen(url)
>          return f.read()
>
> Q1) zopeObj doesn't work. Should be 'self.model.transport'. Right?

Right, thanks!

> Q2) generatePage() is used by additional read only views. For editable
> data I have to use load() / save(). Right?

Close. generatePage is only used in HTMLView derived classes to
provide the html to render.

Model classes usually handle IDE loading and saving (by calling the
transport's load() / save().
This saves/loads the data for views's that maintain model.data.

Zope Views like Undo or Security also "load"/"save" because
they call xmlrpc methods on the server.

> Q3) urllib.urlopen() is a workaround. I should better use getResource()
> if possible. Right?

Yes, it's a workaround. It's the only way I could get it to work.
Try accessing source.html with xmlrpc ;)

So yes, use getResource if possible, otherwise use a ZopeConnection
(based on Zope's client.py), otherwise use whatever works.

> > Please go ahead and implement CMF support!
> > Even just a (working!) prototype would be great.
> >
> > If I ever refactor the Zope support further, I promise to also update
> > the CMF support if its there ;)
>
> Thanks. I'll see what I can do.

Great!

Cheers,
Riaan.