Thread: [PyCrust] Thoughts...
Brought to you by:
pobrien
Menu
▾
▴
pycrust-users
|
From: Robin D. <ro...@al...> - 2001-08-10 23:55:48
|
1. It would be nice if Shell.__init__ could accept a dict for the locals,
which could then be augmented with the locals you already provide if you
like.
2. Since PyCrust is a Python package, do we really need filenames like
PyCrustShell.py and PyCrustEditor.py? When importing it just looks
redundant: "from PyCrust.PyCrustShell import Shell" Or maybe
PyCrust.__init__.py could just import the major classes into it's namespace
so we just have to use "import PyCrust" and then use "PyCrust.Shell"
3. It would be nice if Shell (or maybe ShellWindow) derived from Editor.
That way it could more easily be used as a wxWindow, moved, given to sizers,
etc. Unfortunatly doing
class ShellWindow(PyCrustShell.Shell, PyCrustEditor.Editor):
...
doesn't quite work because of name clashes between the classes.
That's all for now.
--
Robin Dunn
Software Craftsman
ro...@Al... Java give you jitters?
http://wxPython.org Relax with wxPython!
|
|
From: Kevin A. <al...@se...> - 2001-08-11 00:07:18
|
> [mailto:pyc...@li...]On Behalf Of Robin
> Dunn
> 3. It would be nice if Shell (or maybe ShellWindow) derived from Editor.
> That way it could more easily be used as a wxWindow, moved, given
> to sizers,
> etc. Unfortunatly doing
>
> class ShellWindow(PyCrustShell.Shell, PyCrustEditor.Editor):
> ...
>
> doesn't quite work because of name clashes between the classes.
This may not be directly relevant to what Robin is asking, but this is what
I'm currently doing in debug.py of the PythonCardPrototype package.
class PyCrustFrame(wxMiniFrame):
def __init__(self, parent, ID, title, pos, size, parentApp):
wxMiniFrame.__init__(self, parent, ID, title, pos, size,
style=wxDEFAULT_FRAME_STYLE | wxTINY_CAPTION_HORIZ)
parentApp.shell = Shell(editorParent=self)
# KEA this is temporary until we decide what reference
# we want here
parentApp.shell.interp.locals['pcapp'] = parentApp
self.parentApp = parentApp
EVT_CLOSE(self, self.onCloseMe)
def onCloseMe(self, event):
self.Show(false)
in model.py, the window is invoked with
def showShell( self ) :
if debug.PYCRUST_FOUND and self._showShell :
# KEA see comments in showMessageWatcher about frames
bg = self._iterator.getCurrentBackground()
position = Configuration().getOption('shellPosition')
size = Configuration().getOption('shellSize')
self.shellFrame = debug.PyCrustFrame(None, -1, 'Shell',
position, size,
parentApp=self)
self.shellFrame.Show(true)
ka
|
|
From: Robin D. <ro...@al...> - 2001-08-11 01:08:21
|
> > This may not be directly relevant to what Robin is asking, but this is what > I'm currently doing in debug.py of the PythonCardPrototype package. > Not the same. Yours is a has-a, I think an is-a makes more sense. -- Robin Dunn Software Craftsman ro...@Al... Java give you jitters? http://wxPython.org Relax with wxPython! |
|
From: Patrick K. O'B. <po...@or...> - 2001-08-12 13:17:40
|
I'd like to see more discussion about this. The Shell and Editor are intentionally separate and Shell has no wxPython code. If you want more control over the location of the Editor, you can. It's just a wxSTC derived class. I'm not sure I fully understand what you want to accomplish. --- Patrick K. O'Brien Orbtech "I am, therefore I think." -----Original Message----- From: pyc...@li... [mailto:pyc...@li...]On Behalf Of Robin Dunn Sent: Friday, August 10, 2001 8:08 PM To: pyc...@li... Subject: Re: [PyCrust] Thoughts... > > This may not be directly relevant to what Robin is asking, but this is what > I'm currently doing in debug.py of the PythonCardPrototype package. > Not the same. Yours is a has-a, I think an is-a makes more sense. -- Robin Dunn Software Craftsman ro...@Al... Java give you jitters? http://wxPython.org Relax with wxPython! _______________________________________________ PyCrust-users mailing list PyC...@li... http://lists.sourceforge.net/lists/listinfo/pycrust-users |
|
From: Robin D. <ro...@al...> - 2001-08-13 15:26:03
|
> I'd like to see more discussion about this. The Shell and Editor are > intentionally separate and Shell has no wxPython code. If you want more > control over the location of the Editor, you can. It's just a wxSTC derived > class. I'm not sure I fully understand what you want to accomplish. Basically to have a Shell object that is also a window, so I only have to construct a single object and use it as a window (ie, using all the wxWindow methods, passing to sizer.Add, etc.) without having to know the guts of the class to have the knowledge that to do all that I have to use shellobj.editor to do it. -- Robin Dunn Software Craftsman ro...@Al... Java give you jitters? http://wxPython.org Relax with wxPython! |
|
From: Patrick K. O'B. <po...@or...> - 2001-08-15 14:49:18
|
I'm not sure if this gets you exactly what you want, but here is an example.
I modified the wxPython demo file, PyShellWindow.py, to load PyCrust in the
wxPython Demo application. This loads the PyCrust editor into the demo app
the same exact way as the previous one, inside the sliders and all that.
Does this help? (Note that this uses the PyCrust version 0.5.2 module names
and I had to add a docstring to the shell module to keep Main from hanging
at lead = text[:6])
from PyCrust.shell import Shell
#----------------------------------------------------------------------
def runTest(frame, nb, log):
shell = Shell(nb)
return shell.editor
#----------------------------------------------------------------------
import PyCrust.shell
overview = PyCrust.shell.__doc__
---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."
-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Robin Dunn
Sent: Monday, August 13, 2001 10:26 AM
To: pyc...@li...
Subject: Re: [PyCrust] Thoughts...
> I'd like to see more discussion about this. The Shell and Editor are
> intentionally separate and Shell has no wxPython code. If you want more
> control over the location of the Editor, you can. It's just a wxSTC
derived
> class. I'm not sure I fully understand what you want to accomplish.
Basically to have a Shell object that is also a window, so I only have to
construct a single object and use it as a window (ie, using all the wxWindow
methods, passing to sizer.Add, etc.) without having to know the guts of the
class to have the knowledge that to do all that I have to use
shellobj.editor to do it.
--
Robin Dunn
Software Craftsman
ro...@Al... Java give you jitters?
http://wxPython.org Relax with wxPython!
_______________________________________________
PyCrust-users mailing list
PyC...@li...
http://lists.sourceforge.net/lists/listinfo/pycrust-users
|
|
From: Robin D. <ro...@al...> - 2001-08-15 21:57:25
|
> I'm not sure if this gets you exactly what you want, but here is an
example.
Not quite, I had already done something like that. What I was saying is it
would be nice if there was a class, say ShellWindow, that had wxWindow as an
ancestor and had the same basic __init__ interface (parent, id, pos, size,
style) plus any extra parameters for the Shell such as a locals dict, intro
text, etc. That way you wouldn't have to know that the "window" is really
"shell.editor" and not just "shell", and it could more easily be used as a
control/widget/component like any other in app builders like Boa or
wxDesigner.
What I've got:
> from PyCrust.shell import Shell
>
> #----------------------------------------------------------------------
>
> def runTest(frame, nb, log):
> shell = Shell(nb)
> return shell.editor
>
What I would like:
from PyCrust.shell import ShellWindow # or whatever
def runTest(frame, nb, log):
shell = ShellWindow(nb)
return shell
Creating a ShellWindow class that derives from both Shell and Editor almost
does it, but there are attribute and method name clashes between the two so
it never quite worked right when I tried it.
--
Robin Dunn
Software Craftsman
ro...@Al... Java give you jitters?
http://wxPython.org Relax with wxPython!
|
|
From: Patrick K. O'B. <po...@or...> - 2001-08-15 22:13:08
|
I think we're on the same page now, thanks. The problem is mostly my
ignorance of wxPython, but I'm working on that. I just started doing some
pretty hefty refactoring to get you all this and more. I'll keep you posted.
---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."
-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Robin Dunn
Sent: Wednesday, August 15, 2001 4:57 PM
To: pyc...@li...
Subject: Re: [PyCrust] Thoughts...
> I'm not sure if this gets you exactly what you want, but here is an
example.
Not quite, I had already done something like that. What I was saying is it
would be nice if there was a class, say ShellWindow, that had wxWindow as an
ancestor and had the same basic __init__ interface (parent, id, pos, size,
style) plus any extra parameters for the Shell such as a locals dict, intro
text, etc. That way you wouldn't have to know that the "window" is really
"shell.editor" and not just "shell", and it could more easily be used as a
control/widget/component like any other in app builders like Boa or
wxDesigner.
What I've got:
> from PyCrust.shell import Shell
>
> #----------------------------------------------------------------------
>
> def runTest(frame, nb, log):
> shell = Shell(nb)
> return shell.editor
>
What I would like:
from PyCrust.shell import ShellWindow # or whatever
def runTest(frame, nb, log):
shell = ShellWindow(nb)
return shell
Creating a ShellWindow class that derives from both Shell and Editor almost
does it, but there are attribute and method name clashes between the two so
it never quite worked right when I tried it.
--
Robin Dunn
Software Craftsman
ro...@Al... Java give you jitters?
http://wxPython.org Relax with wxPython!
_______________________________________________
PyCrust-users mailing list
PyC...@li...
http://lists.sourceforge.net/lists/listinfo/pycrust-users
|
|
From: Robin D. <ro...@al...> - 2001-08-15 22:48:01
|
> I think we're on the same page now, thanks. The problem is mostly my > ignorance of wxPython, but I'm working on that. I just started doing some > pretty hefty refactoring to get you all this and more. I'll keep you posted. BTW, I also liked the idea of being able to plug different Editors and Interpreters into Shell, so if your refactoring can preserve that it would be nice. I just think that the common case should be simple and so that is what led me to want a ShellWindow. -- Robin Dunn Software Craftsman ro...@Al... Java give you jitters? http://wxPython.org Relax with wxPython! |
|
From: Patrick K. O'B. <po...@or...> - 2001-08-16 00:43:29
|
Making everything a plugin is priority number one, to me at least. In fact, I plan to refactor the Editor() class into Editor(), wxEditor(Editor) and tkEditor(Editor). Then PyCrust.py will probably become wxPyCrust.py and tkPyCrust.py. I'm hoping to have 80% of the code in common between the wxPython version and the Tkinter version. We'll see. --- Patrick K. O'Brien Orbtech "I am, therefore I think." -----Original Message----- From: pyc...@li... [mailto:pyc...@li...]On Behalf Of Robin Dunn Sent: Wednesday, August 15, 2001 5:47 PM To: pyc...@li... Subject: Re: [PyCrust] Thoughts... > I think we're on the same page now, thanks. The problem is mostly my > ignorance of wxPython, but I'm working on that. I just started doing some > pretty hefty refactoring to get you all this and more. I'll keep you posted. BTW, I also liked the idea of being able to plug different Editors and Interpreters into Shell, so if your refactoring can preserve that it would be nice. I just think that the common case should be simple and so that is what led me to want a ShellWindow. -- Robin Dunn Software Craftsman ro...@Al... Java give you jitters? http://wxPython.org Relax with wxPython! _______________________________________________ PyCrust-users mailing list PyC...@li... http://lists.sourceforge.net/lists/listinfo/pycrust-users |
|
From: Patrick K. O'B. <po...@or...> - 2001-08-16 01:46:07
|
Wow. I don't know what I was thinking. In reality I'd be lucky to get 10% common code in the Editor class. The better approach is to just let the Tkinter version recreate the necessary functionality and supply the required methods. There just isn't enough non-gui code to pull into a base class after all. --- Patrick K. O'Brien Orbtech "I am, therefore I think." -----Original Message----- From: pyc...@li... [mailto:pyc...@li...]On Behalf Of Patrick K. O'Brien Sent: Wednesday, August 15, 2001 7:46 PM To: pyc...@li... Subject: RE: [PyCrust] Thoughts... Making everything a plugin is priority number one, to me at least. In fact, I plan to refactor the Editor() class into Editor(), wxEditor(Editor) and tkEditor(Editor). Then PyCrust.py will probably become wxPyCrust.py and tkPyCrust.py. I'm hoping to have 80% of the code in common between the wxPython version and the Tkinter version. We'll see. --- Patrick K. O'Brien Orbtech "I am, therefore I think." |
|
From: Patrick K. O'B. <po...@or...> - 2001-08-12 13:12:14
|
I made the names verbose in order to avoid name clashes when PythonCard was talking about including the PyCrust files in their directory. I'm not opposed to shortening the names now. I'd rather not make assumptions about which classes to import through the packages' __init__.py file, because of the number of ways PyCrust components can be used. Some users will use it for just its interpreter, others for the editor, others will use all the shell defaults but will provide their own editor, etc. I'll work on more sample apps that illustrate this, but for now there is PyCrustAlaCarte.py. --- Patrick K. O'Brien Orbtech "I am, therefore I think." -----Original Message----- From: pyc...@li... [mailto:pyc...@li...]On Behalf Of Robin Dunn Sent: Friday, August 10, 2001 6:55 PM To: pyc...@li... Subject: [PyCrust] Thoughts... 2. Since PyCrust is a Python package, do we really need filenames like PyCrustShell.py and PyCrustEditor.py? When importing it just looks redundant: "from PyCrust.PyCrustShell import Shell" Or maybe PyCrust.__init__.py could just import the major classes into it's namespace so we just have to use "import PyCrust" and then use "PyCrust.Shell" |
|
From: Patrick K. O'B. <po...@or...> - 2001-08-12 13:40:44
|
That makes sense. I'll add it to the TODO list. --- Patrick K. O'Brien Orbtech "I am, therefore I think." -----Original Message----- From: pyc...@li... [mailto:pyc...@li...]On Behalf Of Robin Dunn Sent: Friday, August 10, 2001 6:55 PM To: pyc...@li... Subject: [PyCrust] Thoughts... 1. It would be nice if Shell.__init__ could accept a dict for the locals, which could then be augmented with the locals you already provide if you like. |
|
From: Patrick K. O'B. <po...@or...> - 2001-08-12 16:24:44
|
This has been checked in to CVS. Here is an example with the new parameter:
locals = {'__app__': 'PyCrust Application'}
self.shell = Shell(editorParent=self, introText=intro, locals=locals)
The implementation inside the Shell class looks like this:
self.locals = {'__name__': 'PyCrust',
'__doc__': 'PyCrust, The Python Shell.',
'__version__': version,
}
# Add the dictionary that was passed in.
if locals:
self.locals.update(locals)
As you can see, there is the potential for the passed in locals to replace
the dictionary values that I am setting in self.locals. Whenever I am faced
with the opportunity to allow a caller to override something, I almost
always allow it. I'm assuming that users of PyCrust want more control, not
less, even if it allows them to shoot themselves in the foot.
I should probably add a check to make sure that locals is a dictionary. I'm
still coming to terms with the right level of type checking in Python.
Anyone feel strongly about this? Is it necessary? Not necessary? Depends?
---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."
-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Patrick K.
O'Brien
Sent: Sunday, August 12, 2001 8:43 AM
To: pyc...@li...
Subject: RE: [PyCrust] Thoughts...
That makes sense. I'll add it to the TODO list.
---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."
-----Original Message-----
From: pyc...@li...
[mailto:pyc...@li...]On Behalf Of Robin Dunn
Sent: Friday, August 10, 2001 6:55 PM
To: pyc...@li...
Subject: [PyCrust] Thoughts...
1. It would be nice if Shell.__init__ could accept a dict for the locals,
which could then be augmented with the locals you already provide if you
like.
_______________________________________________
PyCrust-users mailing list
PyC...@li...
http://lists.sourceforge.net/lists/listinfo/pycrust-users
|
Thanks for helping keep SourceForge clean.
X