boa-constructor-users

Re: [Boa Constr] Installation

[Shane H. <sh...@di...>]

Stanko Petrovic wrote:
> 
> Can I install boa_constructor on Linux_Mandrake7.1 and how ?

It runs great on my Mandrake 7.1.  You'll have to download, compile, and
install wxGTK 2.2.1 and wxPython 2.2.1 first.  See
http://www.wxpython.org .

Shane

[Boa Constr] Installation

[Stanko P. <St...@me...>]

Can I install boa_constructor on Linux_Mandrake7.1 and how ?

[Boa Constr] Re: Big patch

[Riaan B. <riaan@e.co.za>]

Hi Shane,

Big thanks!

Shane Hathaway wrote:
> 
> Sorry this patch is so big, but I ended up doing three things:
> 
> 1) Changing all references to 'model.module' to 'model.getModule()' then
> setting it up so that the module is only loaded when the user needs it.
> 
> 2) Finding and fixing the wxGTK bug that causes a segfault whenever a
> DTML document is opened.  It's a stack overflow.
> HTMLSourceView.OnUpdateUI() calls HTMLStyledTextCtrlMix.OnUpdateUI(),
> which calls window.Refresh(), which generates another call to
> HTMLSourceView.OnUpdateUI().  I commented out the call to Refresh().
> Shouldn't wxStyledTextCtrl be doing the equivalent of the Refresh()
> operation automatically?

The new wxStyledTextCtrl also sorts out the reason I had to refresh.
Previously to match braces that were not on the same line the control
had to refreshed.
I had already found this bug, (I didn't know why it crashed tho)
but didn't apply the check on the HTML view because I don't have a 
Zope on my Linux box, and never tested any of the Zope stuff on Linux,
so I forgot.
There is a flag in PrefsGTK.py, braceHighLight = 0
This turns off refreshing on GTK for Python Source and the Shell.
The usual check is in Views.PySourceView.PythonSourceView.OnUpdateUI.
Bracehighlighting in HTML isn't working so most of 
Views.StyledTextCtrls.HTMLStyledTextCtrlMix.OnUpdateUI can actually go.

> 
> 3) Reformatting some of the code to look better in emacs.
> 
> I wonder if you would consider adding a developer to the project so that
> I can just check in the changes.

You're added, welcome!
The CVS should start working next time SourceForge updates.
Please check the changes in.
This will also give me the chance to test the new CVS update/commit 
features in Boa ;)

-- 
Riaan Booysen
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net

[Boa Constr] Big patch

[Shane H. <sh...@di...>]

Sorry this patch is so big, but I ended up doing three things:

1) Changing all references to 'model.module' to 'model.getModule()' then
setting it up so that the module is only loaded when the user needs it.

2) Finding and fixing the wxGTK bug that causes a segfault whenever a
DTML document is opened.  It's a stack overflow. 
HTMLSourceView.OnUpdateUI() calls HTMLStyledTextCtrlMix.OnUpdateUI(),
which calls window.Refresh(), which generates another call to
HTMLSourceView.OnUpdateUI().  I commented out the call to Refresh(). 
Shouldn't wxStyledTextCtrl be doing the equivalent of the Refresh()
operation automatically?

3) Reformatting some of the code to look better in emacs.

I wonder if you would consider adding a developer to the project so that
I can just check in the changes.

Shane

Re: [Boa Constr] Segfault bugfix and "hello!"

[Shane H. <sh...@di...>]

Riaan Booysen wrote:
> Boa's degugger is based on the IDLE debugger. It runs in the same
> process as Boa.
> I definitely agree that an out of process debugger is better, this is
> planned but so far I've not yet had the time to implement an IPC layer.
> This should solve all the major gripes of the current debugger.

Great, I'm glad we agree.

> > > > Also, we need to find out why the editor is a bit sluggish.  I have
> > > > identified and fixed a bug in Scintilla that makes it so Windows keyboard
> > > > events are skipped,
> > >
> > > Which keys?
> > > I had trouble binding ctrl with certain other keys e.g. '<', '>'
> >
> > If the program spends too much time processing a keystroke, Windows will
> > bunch the keystrokes into a single event.  Scintilla interprets the single
> > event as a single keystorke, ignoring the repeat count.
> 
> Scintilla or wxStyledTextCtrl?
> Please check this problem whenever you get your hands on the new
> sources.

Looking again, this could be a "feature" of win32 wxWindows.  I'm not
sure because the feature does make slow programs behave better.  The
real problem, however, is the speed of Scintilla.

I compiled the latest wxWindows and wxPython from CVS.  (It took me
forever to figure out that the primary repository for wxPython is
available through wxwindows.org, even though there is no mention of
it!)  We are indeed up to Scintilla 1.32 now, but as a result
wxStyledTextCtrl now has a significantly different interface that's not
currently backward compatible.  I wonder what Robin's plan is?

Anyway, patches are coming soon.

Shane

Re: [Boa Constr] Segfault bugfix and "hello!"

[Riaan B. <riaan@e.co.za>]

Hello Shane,

Shane Hathaway wrote:

> I haven't looked at how Boa's debugger works, but IMHO it's always best to
> run a processing being debugged in a different process, especially
> considering that a lot of times what you need to debug is a segfault
> (GPF).

Boa's degugger is based on the IDLE debugger. It runs in the same
process as Boa.
I definitely agree that an out of process debugger is better, this is 
planned but so far I've not yet had the time to implement an IPC layer.
This should solve all the major gripes of the current debugger.

> 
> > I really hope someone with a little more debugger experience than me
> > would look into this.
> 
> I'm getting everything set up to start doing some work on Boa.  I think
> the debugger will be the first thing I'll look into.

I'll book in changes (including debugger updates) soon.
Good news, I'm now able to debug wxPython apps with Boa :)
Another significant drawback of in-process debugging is that modules
are only imported the first time. 

> > > Also, we need to find out why the editor is a bit sluggish.  I have
> > > identified and fixed a bug in Scintilla that makes it so Windows keyboard
> > > events are skipped,
> >
> > Which keys?
> > I had trouble binding ctrl with certain other keys e.g. '<', '>'
> 
> If the program spends too much time processing a keystroke, Windows will
> bunch the keystrokes into a single event.  Scintilla interprets the single
> event as a single keystorke, ignoring the repeat count.

Scintilla or wxStyledTextCtrl?
Please check this problem whenever you get your hands on the new
sources.

-- 
Riaan Booysen
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net

Re: [Boa Constr] Segfault bugfix and "hello!"

[Shane H. <sh...@di...>]

On Sat, 21 Oct 2000, Riaan Booysen wrote:

> Shane Hathaway wrote:
> > This would be primarily for product code.  There is a big need for a GUI
> > debugger that works with Zope.
> 
> I've not developed a Zope Product yet so I know neither the procedure
> nor the pitfalls. 

It's not hard once you get the idea (and there's a decent tutorial
now) but one still longs for a debugger. 

> > I've thought about it a little more, and I think ZEO isn't a necessary
> > detail.  What we really want is to have the ability to start a Zope
> > instance (ZEOfied or not) which is running under the control of Boa.
> 
> The most ironic thing for me is that it would probably be easier to 
> debug Zope than to debug a simple 'Hello world' wxPython app because 
> I've got big problems switching between the mainloop of the GUI 
> application and Boa's mainloop. In Zope there is no mixing between 
> mainloops so it should be simpler.
> 
> Another big problem is that once the program being debugged is running
> Boa is unavailable until a breakpoint or an error is encountered.
> So you have to set these before hand.

I haven't looked at how Boa's debugger works, but IMHO it's always best to
run a processing being debugged in a different process, especially
considering that a lot of times what you need to debug is a segfault
(GPF).

> I really hope someone with a little more debugger experience than me
> would look into this.

I'm getting everything set up to start doing some work on Boa.  I think
the debugger will be the first thing I'll look into.

> > Switching topics, I have made some changes that cause Boa to parse modules
> > "late", i.e. only when the user clicks the "Explore" tab or something else
> > that needs the info.  This makes loading files into the source editor
> > quite a bit snappier.  Interested?
> 
> Great stuff, definitely interested, quite a few features like code
> browsing
> and code completion use the parsed data. I postponed just-in-time 
> parsing because I accessed the model.module attribute all over the 
> code and thought it would be a lot of work fixing it everywhere.

OO encapsulation is designed to overcome this.  I created a new method
named getModule() which creates the module if it hasn't been
created.  I'll submit patches soon. 

> > Also, we need to find out why the editor is a bit sluggish.  I have
> > identified and fixed a bug in Scintilla that makes it so Windows keyboard
> > events are skipped, 
> 
> Which keys?
> I had trouble binding ctrl with certain other keys e.g. '<', '>' 

If the program spends too much time processing a keystroke, Windows will
bunch the keystrokes into a single event.  Scintilla interprets the single
event as a single keystorke, ignoring the repeat count.

> > but then I discovered that wxStyledTextCtrl needs some
> > significant updates if it is to be compatible with the latest Scintilla
> > (it's using 1.25, Scintilla is up to 1.32.)
> 
> Robin Dunn recently announced a newly wrapped wxStyledTextCtrl. This
> one seems much faster (on windows have not yet seen wxGTK version) 
> and goes up to 1.32. We should see it in 2.2.2. Or grab it from CVS.
> There are interface changes which I have already corrected for in Boa, 
> but not booked into CVS yet.

That's great news!

> > And I can't figure out why the editor is faster in the wxPython demo.
> > For some reason the paint operation takes much longer in Boa.  
> 
> One of the reasons seemed to be that each wxStyledTextCtrl ate a few
> idle CPU cycles, with a few modules open everything got slower.
> This is addressed by the new wxSTC.

Excellent.

> > Does Boa
> > hook any events that might occur during a paint operation?
> 
> No, but I do have some code that has to run on every key press. Things
> like the bracket matching, smart indent / delete, tab etc.

Yes, I saw that.  There must still be something that's slowing the paint
operations, though.

> > Keep up the good work!
> 
> I will, thanks for climbing in and helping out.

I can't commit myself too much, but I'm pretty excited about what you've
done so far.  I'll help as much as I can.

Shane

Re: [Boa Constr] Segfault bugfix and "hello!"

[Riaan B. <riaan@e.co.za>]

Hi Shane,

Shane Hathaway wrote:

> > I don't exactly understand how the ZEO fits in with this.
> > Would the debugger be some sort of ZEO shared object?
> > Are we debugging Product code or Zope code?
> 
> This would be primarily for product code.  There is a big need for a GUI
> debugger that works with Zope.
> 

I've not developed a Zope Product yet so I know neither the procedure
nor the pitfalls. 

> > I'm very interested in extending Boa's Zope support as far as possible.
> > Zope debugging sounds very cool.
> 
> I've thought about it a little more, and I think ZEO isn't a necessary
> detail.  What we really want is to have the ability to start a Zope
> instance (ZEOfied or not) which is running under the control of Boa.

The most ironic thing for me is that it would probably be easier to 
debug Zope than to debug a simple 'Hello world' wxPython app because 
I've got big problems switching between the mainloop of the GUI 
application and Boa's mainloop. In Zope there is no mixing between 
mainloops so it should be simpler.

Another big problem is that once the program being debugged is running
Boa is unavailable until a breakpoint or an error is encountered.
So you have to set these before hand.

I really hope someone with a little more debugger experience than me
would look into this.

> 
> Switching topics, I have made some changes that cause Boa to parse modules
> "late", i.e. only when the user clicks the "Explore" tab or something else
> that needs the info.  This makes loading files into the source editor
> quite a bit snappier.  Interested?

Great stuff, definitely interested, quite a few features like code
browsing
and code completion use the parsed data. I postponed just-in-time 
parsing because I accessed the model.module attribute all over the 
code and thought it would be a lot of work fixing it everywhere.

> 
> Also, we need to find out why the editor is a bit sluggish.  I have
> identified and fixed a bug in Scintilla that makes it so Windows keyboard
> events are skipped, 

Which keys?
I had trouble binding ctrl with certain other keys e.g. '<', '>' 

> but then I discovered that wxStyledTextCtrl needs some
> significant updates if it is to be compatible with the latest Scintilla
> (it's using 1.25, Scintilla is up to 1.32.)

Robin Dunn recently announced a newly wrapped wxStyledTextCtrl. This
one seems much faster (on windows have not yet seen wxGTK version) 
and goes up to 1.32. We should see it in 2.2.2. Or grab it from CVS.
There are interface changes which I have already corrected for in Boa, 
but not booked into CVS yet.

> 
> And I can't figure out why the editor is faster in the wxPython demo.
> For some reason the paint operation takes much longer in Boa.  

One of the reasons seemed to be that each wxStyledTextCtrl ate a few
idle CPU cycles, with a few modules open everything got slower.
This is addressed by the new wxSTC.

> Does Boa
> hook any events that might occur during a paint operation?

No, but I do have some code that has to run on every key press. Things
like the bracket matching, smart indent / delete, tab etc.

> 
> Keep up the good work!

I will, thanks for climbing in and helping out.

-- 
Riaan Booysen
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net

Re: [Boa Constr] Segfault bugfix and "hello!"

[Shane H. <sh...@di...>]

On Fri, 20 Oct 2000, Riaan Booysen wrote:

> There is no noticeable difference on Windows (which is a good thing ;)
> but if this fixes some wxGTK issues, fantastic, I've updated the source.

Yep, I forgot to mention that.  It worked all along on Windows but crashed
in GTK.

> > Now, I wonder what people would think of the following direction: make
> > it possible for Boa to connect to a ZEO server and manipulate objects
> > directly.  This would provide an *ideal* environment for developing Zope
> > products, since it would let you use the debugger on what looks like a
> > live Zope instance.
> 
> Are you using the current version from CVS?
> This version allows the standard Zope management operations 
> (cut/copy/paste/import/export) as well as object creation from the 
> Palette and property editing with the Inspector 
> (adding/editing/removing). 
> Right click in the explorer for menus.

Wow, I haven't seen all that.  I'll have to take another look!

> I don't exactly understand how the ZEO fits in with this.
> Would the debugger be some sort of ZEO shared object?
> Are we debugging Product code or Zope code?

This would be primarily for product code.  There is a big need for a GUI
debugger that works with Zope.

> I'm very interested in extending Boa's Zope support as far as possible.
> Zope debugging sounds very cool.

I've thought about it a little more, and I think ZEO isn't a necessary
detail.  What we really want is to have the ability to start a Zope
instance (ZEOfied or not) which is running under the control of Boa.

Switching topics, I have made some changes that cause Boa to parse modules
"late", i.e. only when the user clicks the "Explore" tab or something else
that needs the info.  This makes loading files into the source editor
quite a bit snappier.  Interested?

Also, we need to find out why the editor is a bit sluggish.  I have
identified and fixed a bug in Scintilla that makes it so Windows keyboard
events are skipped, but then I discovered that wxStyledTextCtrl needs some
significant updates if it is to be compatible with the latest Scintilla
(it's using 1.25, Scintilla is up to 1.32.)

And I can't figure out why the editor is faster in the wxPython demo.  
For some reason the paint operation takes much longer in Boa.  Does Boa
hook any events that might occur during a paint operation?

Keep up the good work!

Shane Hathaway
Digital Creations, Inc.
http://www.digicool.com
http://www.zope.org

Re: [Boa Constr] Segfault bugfix and "hello!"

[Riaan B. <riaan@e.co.za>]

Hello Shane,

Shane Hathaway wrote:
> 
> Boa looks like a great project.  I'm very impressed with it.  Especially
> the fact that it connects to Zope!
> 
Thanks!

> That said, Editor.py didn't work well on my Linux box until I applied
> the following change.  modulePage.destroy() needs to occur only when
> there is *nothing* else that might access modulePage.
> 
> @@ -620,9 +652,9 @@
>                  if Utils.yesNoDialog(self, 'Close module', 'There are
> changes, do you want to save?'):
>                      self.saveOrSaveAs()
>                      name = modulePage.model.filename
> -            modulePage.destroy()
>              self.tabs.RemovePage(idx)
>              del self.modules[name]
> +            modulePage.destroy()
>              # notify pages for idx adjustments
>              for modPge in self.modules.values():
>                  modPge.removedPage(idx)

There is no noticeable difference on Windows (which is a good thing ;)
but if this fixes some wxGTK issues, fantastic, I've updated the source.

> 
> Now, I wonder what people would think of the following direction: make
> it possible for Boa to connect to a ZEO server and manipulate objects
> directly.  This would provide an *ideal* environment for developing Zope
> products, since it would let you use the debugger on what looks like a
> live Zope instance.

Are you using the current version from CVS?
This version allows the standard Zope management operations 
(cut/copy/paste/import/export) as well as object creation from the 
Palette and property editing with the Inspector 
(adding/editing/removing). 
Right click in the explorer for menus.

I don't exactly understand how the ZEO fits in with this.
Would the debugger be some sort of ZEO shared object?
Are we debugging Product code or Zope code?

I'm very interested in extending Boa's Zope support as far as possible.
Zope debugging sounds very cool.

-- 
Riaan                     >>> a='a=%s;a%%`a`';a%`a`
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net

[Boa Constr] Segfault bugfix and "hello!"

[Shane H. <sh...@di...>]

Boa looks like a great project.  I'm very impressed with it.  Especially
the fact that it connects to Zope!

That said, Editor.py didn't work well on my Linux box until I applied
the following change.  modulePage.destroy() needs to occur only when
there is *nothing* else that might access modulePage.

@@ -620,9 +652,9 @@
                 if Utils.yesNoDialog(self, 'Close module', 'There are
changes, do you want to save?'):
                     self.saveOrSaveAs()
                     name = modulePage.model.filename
-            modulePage.destroy()
             self.tabs.RemovePage(idx)
             del self.modules[name]
+            modulePage.destroy()
             # notify pages for idx adjustments
             for modPge in self.modules.values():
                 modPge.removedPage(idx)

Now, I wonder what people would think of the following direction: make
it possible for Boa to connect to a ZEO server and manipulate objects
directly.  This would provide an *ideal* environment for developing Zope
products, since it would let you use the debugger on what looks like a
live Zope instance.

Shane

RE: [Boa Constr] boa crashes in linux

[Charlie D. <ch...@we...>]

~
~
~ Charlie Derr wrote:
~ <snipped>
~

Riian answered:

~ I don't have Zope installed on my Linux partition, so I cannot test
~ Zope stuff on Linux.
~ I would appreciate it if you could have a look at where the crash
~ happens. If you've got the time/inclination, start off in
~ Editor.py line 547.

Well, I started.  Suffice it to say i'll need to spend a little more time
poking about to figure out a useful response to the code at line 547, but
i'll give it a shot

~
~ Does adding from the palette, cut&paste, property inspection work?

The palette does work for adding files/methods/etc...

In the explorer, if I right click on a file, the inspection button works,
but none of the others (cut, copy, paste, import, export, rename, delete) do
anything (though they don't crash boa)

When i try to view any file (within the Zope folder), boa crashes.

~
~ If you want to run under 1.6 and 2.0bx you have to install the
~ appropriate version of wxPython as well.

I noticed (and did) that.  It didn't help.

~



thx once again,
		~c

~ --
~ Riaan                     >>> a='a=%s;a%%`a`';a%`a`
~ ___________________________________________________
~ Boa Constructor - RAD GUI building IDE for wxPython
~      http://boa-constructor.sourceforge.net
~ _______________________________________________
~ Boa-constructor-users mailing list
~ Boa...@li...
~ http://lists.sourceforge.net/mailman/listinfo/boa-constructor-users

Re: [Boa Constr] boa crashes in linux

[Riaan B. <riaan@e.co.za>]

Charlie Derr wrote:
> 
> Hi again,
> 
>         I've just grabbed the latest from cvs (0.4.5) and it's great.  Under
> windows everything works.  When i use it in linux i get the same crashing
> behavior as i used to with 0.4 when trying to access a file on my zope site
> at localhost (or anywhere else).  The file structure is perfectly visible,
> the login works, but when i click on one of my dtml methods to edit it,
> there is a slight pause, and then all of boa crashes.  The following is the
> output in my console.  I'm on a redhat 6.1 box and i have gtk+-1.2.5-2 and
> wxGTK-2.2.2-0 and python 1.5.2  (i've tried with python 2.0b2, but i had no
> luck -- boa would start and then freeze up with an error message (on NT) --
> i had to uninstall and restore python 1.5.2).
> 
> thanx much in advance,
>         ~c

I don't have Zope installed on my Linux partition, so I cannot test
Zope stuff on Linux.
I would appreciate it if you could have a look at where the crash
happens. If you've got the time/inclination, start off in
Editor.py line 547. 

Does adding from the palette, cut&paste, property inspection work?

If you want to run under 1.6 and 2.0bx you have to install the 
appropriate version of wxPython as well.

-- 
Riaan                     >>> a='a=%s;a%%`a`';a%`a`
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net

[Boa Constr] boa crashes in linux

[Charlie D. <ch...@we...>]

Hi again,

	I've just grabbed the latest from cvs (0.4.5) and it's great.  Under
windows everything works.  When i use it in linux i get the same crashing
behavior as i used to with 0.4 when trying to access a file on my zope site
at localhost (or anywhere else).  The file structure is perfectly visible,
the login works, but when i click on one of my dtml methods to edit it,
there is a slight pause, and then all of boa crashes.  The following is the
output in my console.  I'm on a redhat 6.1 box and i have gtk+-1.2.5-2 and
wxGTK-2.2.2-0 and python 1.5.2  (i've tried with python 2.0b2, but i had no
luck -- boa would start and then freeze up with an error message (on NT) --
i had to uninstall and restore python 1.5.2).

thanx much in advance,
	~c
importing wxPython...
imported Prefs
imported PaletteMapping
imported Editor
imported Inspector
imported Palette
imported Editor

Gdk-CRITICAL **: file gdkgc.c: line 456 (gdk_gc_set_foreground): assertion
`gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 469 (gdk_gc_set_background): assertion
`gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 562 (gdk_gc_set_fill): assertion `gc !=
NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 456 (gdk_gc_set_foreground): assertion
`gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 469 (gdk_gc_set_background): assertion
`gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 766 (gdk_gc_set_line_attributes):
assertion `gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 456 (gdk_gc_set_foreground): assertion
`gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 469 (gdk_gc_set_background): assertion
`gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 562 (gdk_gc_set_fill): assertion `gc !=
NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 469 (gdk_gc_set_background): assertion
`gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 456 (gdk_gc_set_foreground): assertion
`gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 562 (gdk_gc_set_fill): assertion `gc !=
NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 502 (gdk_gc_set_function): assertion `gc
!= NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 502 (gdk_gc_set_function): assertion `gc
!= NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 502 (gdk_gc_set_function): assertion `gc
!= NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 689 (gdk_gc_set_clip_rectangle):
assertion `gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 689 (gdk_gc_set_clip_rectangle):
assertion `gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 689 (gdk_gc_set_clip_rectangle):
assertion `gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 689 (gdk_gc_set_clip_rectangle):
assertion `gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 713 (gdk_gc_set_clip_region): assertion
`gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 713 (gdk_gc_set_clip_region): assertion
`gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 713 (gdk_gc_set_clip_region): assertion
`gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 713 (gdk_gc_set_clip_region): assertion
`gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 456 (gdk_gc_set_foreground): assertion
`gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 469 (gdk_gc_set_background): assertion
`gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 562 (gdk_gc_set_fill): assertion `gc !=
NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 456 (gdk_gc_set_foreground): assertion
`gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 469 (gdk_gc_set_background): assertion
`gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 766 (gdk_gc_set_line_attributes):
assertion `gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 456 (gdk_gc_set_foreground): assertion
`gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 469 (gdk_gc_set_background): assertion
`gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 562 (gdk_gc_set_fill): assertion `gc !=
NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 469 (gdk_gc_set_background): assertion
`gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 456 (gdk_gc_set_foreground): assertion
`gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 562 (gdk_gc_set_fill): assertion `gc !=
NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 502 (gdk_gc_set_function): assertion `gc
!= NULL' failed.

...

[clipped for relevance --  this is just a small fraction of the actual
output]

[Boa Constr] RE: i'm set

[Charlie D. <ch...@we...>]

I would have sent this immediately, but when it worked, it began the CVS
checkout, and i wasn't able to access my wincvs preferences until the
checkout completed.

You were right about CVSROOT -- it should be set to
ano...@cv...:/cvsroot/Boa-Constructor

also important is the "Authentication" field below that one

it worked for me set at "passwd file on the cvs server"


Then i just chose CvsAdmin | Login  and hit return without entering a
password to the dialog, and i was able to log in.

At that point I was able to checkout the module boa.

	Thanx again for all your help,
		~c


~ -----Original Message-----
~ From: Riaan Booysen [mailto:riaan@e.co.za]
~ Sent: Friday, September 29, 2000 2:25 PM
~ To: Charlie Derr
~ Subject: Re: i'm set
~
~
~
~
~ Charlie Derr wrote:
~ >
~ > dLing from cvs now
~ >
~ > thanx for all your help
~ >
~ >     ~c
~
~ So what is the final working configuration?
~
~ --
~ Riaan                     >>> a='a=%s;a%%`a`';a%`a`
~ ___________________________________________________
~ Boa Constructor - RAD GUI building IDE for wxPython
~      http://boa-constructor.sourceforge.net

RE: [Boa Constr] CVS Update (re-send) CVS Settings

[Charlie D. <ch...@we...>]

Thanx Riaan,

~ Charlie Derr wrote:
~ >
~ > Thanx, it looks great.
~ >
~ > I'm probably not seeing something obvious somewhere, but i
~ can't figure out
~ > what modulename i'm supposed to use when i checkout.  I logged in to cvs
~ > okay, and tried everything i can think of, but none of the
~ following worked:
~ > boa, Boa-Constructor, devel, main, current, working
~
~ I went thru the same pain when I started with CVS, hang in there ;)
~
~ Assuming you you use WinCVS,

yes

~ I think the important settings for anonymous cvs checkouts are:
~
~ Cvs Admin -> Preferences -> CVSROOT:
~ ano...@cv...:/cvsroot/Boa-Constructor
~
~ Cvs Admin -> Checkout module... -> Module name and path on server:
~ boa
~
~ Does this work for you?


It's closer.

I log in with the command line given on the sourceforge boa website and
here's what happens:

cvs -d:pserver:ano...@cv...:/cvsroot/Boa-Co
nstructo... login
\n
\n (in directory C:\usr\incoming\boa)
(Logging in to ano...@cv...)

*****CVS exited normally with code 0*****

cvs checkout -P boa (in directory C:\usr\incoming\boa)
cvs [checkout aborted]: CVSROOT
ano...@cv...:/cvsroot/Boa-Constructor must
be an absolute pathname

*****CVS exited normally with code 1*****




I'm confused.

	~c


~
~ --
~ Riaan                     >>> a='a=%s;a%%`a`';a%`a`
~ ___________________________________________________
~ Boa Constructor - RAD GUI building IDE for wxPython
~      http://boa-constructor.sourceforge.net

Re: [Boa Constr] CVS Update (re-send) CVS Settings

[Riaan B. <riaan@e.co.za>]

Charlie Derr wrote:
> 
> Thanx, it looks great.
> 
> I'm probably not seeing something obvious somewhere, but i can't figure out
> what modulename i'm supposed to use when i checkout.  I logged in to cvs
> okay, and tried everything i can think of, but none of the following worked:
> boa, Boa-Constructor, devel, main, current, working

I went thru the same pain when I started with CVS, hang in there ;)

Assuming you you use WinCVS,
I think the important settings for anonymous cvs checkouts are:

Cvs Admin -> Preferences -> CVSROOT:
ano...@cv...:/cvsroot/Boa-Constructor

Cvs Admin -> Checkout module... -> Module name and path on server:
boa

Does this work for you?

-- 
Riaan                     >>> a='a=%s;a%%`a`';a%`a`
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net

Re: [Boa Constr] CVS Updated

[Riaan B. <riaan@e.co.za>]

Hi Antoni,

"Aloy, Antoni" wrote:
> 
> Hi!
> 
> I have to major problems with the new version:
> 
> a) Zope mxDate not found error. I have downloaded the module from its site
> and added to the Zope folder. This corrects the error. It seems its not in
> the CVS directory.
> 
> b) Module Debugger doen't exist. Again it seems this module is not in the
> CVS repository.
> 

I've checked and the CVS definitely has the Debugger and DateTime
packages.
See:
http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/boa/?cvsroot=Boa-Constructor

Maybe you should do a checkout to get the new directories.
I dunno, I'm relatively new to CVS myself.

Btw as far as I know this is not mxDateTime but Digital Creations' own
date package.

> For all of us that can't figure what's the Zope module for, would you mind
> to write few lines about that? I know what's Zope but I can't "seen" how Boa
> and Zope work together.

Boa is a Python IDE and sets out to support as many Python 
technologies that as possible.

Once you have set up your Explorer.*.cfg file for your Zope site,
you can explore the Zope directory structure like the web interface.
Documents (and other Zope objects) can be created from the Palette by
selecting the item on the Zope palette entry an clicking in the Zope
folder (the list not the tree) where you want it created.
If you right click on a Zope item in the list part of the explorer
there are options to cut/copy/paste/delete/export and import.
Also from the popup menu you can Inspect a Zope item which brings
up it's properties in the object inspector. Here you can also add 
and delete properties.
Double click to open a Zope document as a syntax highlighted source 
file in the IDE.

I think Zope fits very naturally in the Boa IDE framework. It by no 
means replaces the web interface as there are many things only
accessible thru the web.

Does this answer your question?

-- 
Riaan                     >>> a='a=%s;a%%`a`';a%`a`
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net

RE: [Boa Constr] CVS Update (re-send)

[Charlie D. <ch...@we...>]

Thanx, it looks great.

I'm probably not seeing something obvious somewhere, but i can't figure out
what modulename i'm supposed to use when i checkout.  I logged in to cvs
okay, and tried everything i can think of, but none of the following worked:
boa, Boa-Constructor, devel, main, current, working


	tmia,
		~c

~ -----Original Message-----
~ From: boa...@li...
~ [mailto:boa...@li...]On Behalf Of
~ Riaan Booysen
~ Sent: Thursday, September 28, 2000 7:02 PM
~ To: Boa list
~ Subject: [Boa Constr] CVS Update (re-send)
~
~
~ Hi everyone,
~
~ I have posted this a few times already but it does not seem to be
~ getting thru. Here it goes again...
~
~ The cvs has been updated with a lot of work in progress.
~ For NT users there is a workaround for the file dialog / cursor keys
~ problem. Boa optionally has it's own file dialog now.
~ Other highlights:
~ * More Zope support:
~   * Standard object creation (Documents, methods, folders etc)
~   * Management functions (cut/copy/paste/delete/export/import)
~   * Zope property maintenance in the object inspector
~ * Designer features:
~   * Multiple selection (in progress)
~   * Cut / Copy / Paste (collections not supported yet)
~ --
~ Riaan                     >>> a='a=%s;a%%`a`';a%`a`
~ ___________________________________________________
~ Boa Constructor - RAD GUI building IDE for wxPython
~      http://boa-constructor.sourceforge.net
~ _______________________________________________
~ Boa-constructor-users mailing list
~ Boa...@li...
~ http://lists.sourceforge.net/mailman/listinfo/boa-constructor-users

[Boa Constr] CVS Update (re-send)

[Riaan B. <riaan@e.co.za>]

Hi everyone,

I have posted this a few times already but it does not seem to be 
getting thru. Here it goes again...

The cvs has been updated with a lot of work in progress.
For NT users there is a workaround for the file dialog / cursor keys 
problem. Boa optionally has it's own file dialog now.
Other highlights:
* More Zope support:
  * Standard object creation (Documents, methods, folders etc)
  * Management functions (cut/copy/paste/delete/export/import)
  * Zope property maintenance in the object inspector
* Designer features:
  * Multiple selection (in progress)
  * Cut / Copy / Paste (collections not supported yet)
-- 
Riaan                     >>> a='a=%s;a%%`a`';a%`a`
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net

[Boa Constr] CVS Updated

[Riaan B. <riaan@e.co.za>]

Hi everyone,

I'm posting this again as the first time seems not so have made it to
the mailing list :(

The cvs has been updated with a lot of work in progress.
For NT users there is a workaround for the file dialog / cursor keys 
problem. Boa optionally has it's own file dialog now.
Other highlights:
* More Zope support:
  * Standard object creation (Documents, methods, folders etc)
  * Management functions (cut/copy/paste/delete/export/import)
  * Zope property maintenance in the object inspector
* Designer features:
  * Multiple selection (in progress)
  * Cut / Copy / Paste (collections not supported yet)
-- 
Riaan                     >>> a='a=%s;a%%`a`';a%`a`
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net

[Boa Constr] CVS Updated

[Riaan B. <riaan@e.co.za>]

Hi everyone,

I'm posting this again as the first time seems not so have made it ot
the mailing list :(

The cvs has been updated with a lot of work in progress.
For NT users there is a workaround for the file dialog / cursor keys 
problem. Boa optionally has it's own file dialog now.
Other highlights:
* More Zope support:
  * Standard object creation (Documents, methods, folders etc)
  * Management functions (cut/copy/paste/delete/export/import)
  * Zope property maintenance in the object inspector
* Designer features:
  * Multiple selection (in progress)
  * Cut / Copy / Paste (collections not supported yet)


-- 
Riaan                     >>> a='a=%s;a%%`a`';a%`a`
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net

[Boa Constr] CVS Updated

[Riaan B. <riaan@e.co.za>]

Hi everyone,

The cvs has been updated with a lot of work in progress.
For NT users there is a workaround for the file dialog / cursor keys 
problem. Boa optionally has it's own file dialog now.
Other highlights:
* More Zope support:
  * Standard object creation (Documents, methods, folders etc)
  * Management functions (cut/copy/paste/delete/export/import)
  * Zope property maintenance in the object inspector
* Designer features:
  * Multiple selection (in progress)
  * Cut / Copy / Paste (collections not supported yet)

-- 
Riaan                     >>> a='a=%s;a%%`a`';a%`a`
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net

Re: [Boa Constr] problems adding constraints

[Riaan B. <riaan@e.co.za>]

Hi Wayne,

"Boras, Wayne" wrote:
> 
> Hello,
> 
> First of all I would just like to say that I think Boa is fantastic! I cannot, however, successfully add layout constraints using Boa. Here are the problems I am having:
> 
> 1. When new Constraints are added using the Collection Editor, the only available constraints are Left, Right, Top, Bottom. There is no way to add any other types of constraints, e.g. Width or Height.
> 
> 2. When defining the individual Constraint, the OtherWindow cell doesn't do anything. I think this is where I should be able to specify the object that I want this constraint to be relative to, but I
> am not sure.
> 
> 3. If I fully constrain an object using Left, Right, Top and Bottom constraints, and edit the code to include the OtherWindow specification, the constraint still does not seem to work.
> 
> If anyone could please send me an example of sucessfully implemented constraints or tell me what I'm doing wrong, I would be very appreciative.

Constraints are tricky (well, for me anyway).
Things to remember:
Set AutoLayout of the container to true
There has to be 4 valid constraints, if they don't make sense together
the control usually disappears :(

If you really want to use them first read up on wxLayoutConstraint 
and wxIndividualLayoutConstraint.

The fact that you can't change the OtherWindow property is a bug.
On line 783 in Views\Designer.py change
    def getAllObjects(self, theClass):
to
    def getAllObjects(self):
to fix this.

There is currently a bug in wxPython where
wxIndividualLayoutConstraint.Set()
does not work for the relationship parameters wxSameAs and wxPercentOf 
(the most useful ones :( )

If this didn't discourage you nothing will ;)

I've attached an example to show that it is actually possible to use
layout constraints.

I'm personally hoping for nice integration of sizers into Boa.

-- 
Riaan                     >>> a='a=%s;a%%`a`';a%`a`
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net

Re: [Boa Constr] Bug with static text

[Riaan B. <riaan@e.co.za>]

Dirk-Ulrich Heise wrote:
> 
> > Hi,
> >
> > I cannot reproduce this problem :(
> > Can you consistently reproduce it?
> >
> 
> Ooh - wrong description by me:
> When i change the "label" entry (which i suppose
> should be the text appearing), it doesn't crash.
> But when i change the "Name" entry (i confused the
> two at the beginning), it crashes. Sorry.
> 
> > With the "Hook" button do you mean the Post button (blue tick)?
> 
> Yes.

I have tried again and still cannot reproduce a crash.

One problem I did pickup (thanks!) was that I do not verify that the 
new name is a valid Python identifier.
I saw in the log of the original message that you renamed the control
from 'staticText1' to 'Dirks FileFinder' this is illegal and should 
be checked for.

What you are doing in effect is saying:

self.Dirks Filefinder = wxStaticText(...

which is not valid Python.

I will put this check on the TODO list.

Does it work for valid renames? ;)

-- 
Riaan                     >>> a='a=%s;a%%`a`';a%`a`
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net