Thread: [Pyobjc-dev] PyShellView?
Brought to you by:
ronaldoussoren
Menu
▾
▴
pyobjc-dev
|
From: Michael H. <mw...@py...> - 2003-07-01 17:38:02
|
I seem to have written this on the train on the way back from
EuroPython:
For a PyObjC application I want to write, I really really want to have
a Python shell view, i.e. an area I can type Python commands into and
have them executed interactively. I should have few problems with the
Python side -- I seem to do things like this all the time -- but the
Cocoa side is considerably more mysterious to me.
Also I want to donate this to the PyObjC project, as it would be an
essential component of any PyObjC-based IDE, and I would like to do a
really good job and produce a widget that is maintainable by others.
I imagine this would involve writing a subclass of NSTextView.
Override keyDown:? I'm not sure where to hook into to modify
behaviour at this level.
In dreamland, I would like to be able to drag a PyShellView from the
palette in IB, select which module it should run in from the Info
window -- default "__main__" -- and have things Just Work(tm).
I don't really have any time to work on this, but probably will find
some anyway.
Comments?
Cheers,
M.
--
Two things I learned for sure during a particularly intense acid
trip in my own lost youth: (1) everything is a trivial special case
of something else; and, (2) death is a bunch of blue spheres.
-- Tim Peters, 1 May 1998
|
|
From: Dinu G. <gh...@da...> - 2003-07-02 06:49:42
|
Michael Hudson:
> For a PyObjC application I want to write, I really really want to have
> a Python shell view, i.e. an area I can type Python commands into and
> have them executed interactively. I should have few problems with the
> Python side -- I seem to do things like this all the time -- but the
> Cocoa side is considerably more mysterious to me.
Sounds good to me! You may want to sniff into the following maybe:
http://developer.apple.com/samplecode/Sample_Code/Cocoa/
TextViewDelegate.htm
Have fun,
Dinu
--
Dinu C. Gherman
......................................................................
"The pure and simple truth is rarely pure and never simple."
(Oscar Wilde)
|
|
From: Dinu G. <gh...@da...> - 2003-07-02 08:31:05
|
I wrote: > Sounds good to me! You may want to sniff into the following maybe: > > > http://developer.apple.com/samplecode/Sample_Code/Cocoa/ > TextViewDelegate.htm > > Have fun, Big fun, indeed!! The following conversion to PyObjC using an outlet named 'committedLength' of type id in IB just crashes: #------------------------------------------------------------------ # # MyAppDelegate.py # PyTextViewDelegate # from objc import YES, NO from Foundation import NSObject from AppKit import NSColor, NSApplicationDelegate from PyObjCTools import NibClassBuilder # create ObjC classes as defined in MainMenu.nib NibClassBuilder.extractClasses("MainMenu") class MyAppDelegate(NibClassBuilder.AutoBaseClass, NSApplicationDelegate): def awakeFromNib(self): "Set our committedLength outlet to the right start value." self.committedLength = 0 def textView_shouldChangeTextInRange_replacementString_(self, textView, charRange, replString): "Allow editing only after the previously committed text." return charRange[0] >= self.committedLength #------------------------------------------------------------------ But after using an instance variable 'cl' locally defined in awakeFromNib everything works fine and I get the following code working as the ObjC-counterpart: #------------------------------------------------------------------ # # MyAppDelegate.py # PyTextViewDelegate # from objc import YES, NO from Foundation import NSObject from AppKit import NSColor, NSApplicationDelegate from PyObjCTools import NibClassBuilder # create ObjC classes as defined in MainMenu.nib NibClassBuilder.extractClasses("MainMenu") class MyAppDelegate(NibClassBuilder.AutoBaseClass, NSApplicationDelegate): def awakeFromNib(self): "Set our committedLength outlet to the right start value." # self.committedLength = 0 self.cl = 0 def textView_shouldChangeTextInRange_replacementString_(self, textView, charRange, replString): "Allow editing only after the previously committed text." return charRange[0] >= self.cl def textView_doCommandBySelector_(self, textView, commandSelector): "When return is entered, record and color the newly committed text." retval = NO if commandSelector == "insertNewline:": textLength = len(textView.string()) if textLength > self.cl: textView.setSelectedRange_((textLength, 0)) textView.insertText_("\n") col = NSColor.redColor() r = (self.cl, textLength - self.cl) textView.setTextColor_range_(col, r) textLength += 1 self.cl = textLength retval = YES return retval #------------------------------------------------------------------ Nothing to do with using the NSTextViewDelegate - tried it, makes no difference! Pretty strange to me... Dinu -- Dinu C. Gherman ...................................................................... "We're concerned about AIDS inside our White House - make no mistake about it." (George W. Bush, 7 Feb. 2001) |
|
From: Ronald O. <ous...@ci...> - 2003-07-02 10:15:40
Attachments:
buildapp.py
main.py
|
On Wednesday, Jul 2, 2003, at 10:32 Europe/Amsterdam, Dinu Gherman wrote: > I wrote: > >> Sounds good to me! You may want to sniff into the following maybe: >> >> >> http://developer.apple.com/samplecode/Sample_Code/Cocoa/ >> TextViewDelegate.htm >> >> Have fun, > > Big fun, indeed!! The following conversion to PyObjC using an outlet > named 'committedLength' of type id in IB just crashes: I cannot reproduce this here using the attached files and 'English.lproj' from the example. the main.py is your crashing code with an added call to NSApplication main, and adapted for the name of the nib inside the example. Could you post a complete, crashing, example. <later> Now that I look at your message again I see what's wrong: don't use outlets to store the committedLength. If you store anything in outlets you must make sure that that object stays alive by other means (e.g. store a reference in a regular instance variable or even call 'retain'). That doesn't help for "plain python" value though, therefore you shouldn't store plain-python values in outlets. I'm going to add something about this issue to the documentation. Basic guideline: Only use outlets if you're going to set them from Interface Builder, otherwise use "regular" instance variables. Ronald |
|
From: Michael H. <mw...@py...> - 2003-10-17 10:58:57
|
From a while's back: I've now got around to trying to implement the PyShellView, and as usual with Cocoa it seems to be laughably easy. With appropriate swiping of code from IDLE, I expect to be able to get colorization, completion and history all going fairly easily. One problem, though: Dinu Gherman <gh...@da...> writes: > I wrote: > >> Sounds good to me! You may want to sniff into the following maybe: >> >> http://developer.apple.com/samplecode/Sample_Code/Cocoa/ >> TextViewDelegate.htm >> >> Have fun, > > Big fun, indeed!! The following conversion to PyObjC using an outlet > named 'committedLength' of type id in IB just crashes: > > #------------------------------------------------------------------ > # > # MyAppDelegate.py > # PyTextViewDelegate > # > > from objc import YES, NO > from Foundation import NSObject > from AppKit import NSColor, NSApplicationDelegate > from PyObjCTools import NibClassBuilder > > # create ObjC classes as defined in MainMenu.nib > NibClassBuilder.extractClasses("MainMenu") > > > class MyAppDelegate(NibClassBuilder.AutoBaseClass, > NSApplicationDelegate): > > def awakeFromNib(self): > "Set our committedLength outlet to the right start value." > > self.committedLength = 0 > > > def textView_shouldChangeTextInRange_replacementString_(self, > textView, charRange, replString): > "Allow editing only after the previously committed text." > > return charRange[0] >= self.committedLength If I implement this delgate method and press "backspace" in the text view, I get a core dump deep in Scary Internals Land. I've not got the latest PyObjC on my laptop, and my laptop is at home so I can't update, but does this sound familiar to anyone? Might it be cured by a new libffi (for example)? Cheers, mwh -- If you're talking "useful", I'm not your bot. -- Tim Peters, 08 Nov 2001 |
|
From: Dinu G. <gh...@da...> - 2003-10-18 07:36:05
|
Michael Hudson: > If I implement this delgate method and press "backspace" in the text > view, I get a core dump deep in Scary Internals Land. I've not got > the latest PyObjC on my laptop, and my laptop is at home so I can't > update, but does this sound familiar to anyone? Might it be cured by > a new libffi (for example)? Have you read Ronald's follow-up message to mine you're citing? Ronald Oussoren wrote: > Now that I look at your message again I see what's wrong: don't use > outlets to store the committedLength. If you store anything in outlets > you must make sure that that object stays alive by other means (e.g. > store a reference in a regular instance variable or even call > 'retain'). That doesn't help for "plain python" value though, > therefore you shouldn't store plain-python values in outlets. I'm > going to add something about this issue to the documentation. > > Basic guideline: Only use outlets if you're going to set them from > Interface Builder, otherwise use "regular" instance variables. Does that help? Dinu -- Dinu C. Gherman - http://python.net/~gherman ...................................................................... "The whole point of brainwashing, is that those being brainwashed don't know it." (Graham Haley) |
|
From: Michael H. <mw...@py...> - 2003-10-20 10:32:58
|
Dinu Gherman <gh...@da...> writes:
> Michael Hudson:
>
>> If I implement this delgate method and press "backspace" in the text
>> view, I get a core dump deep in Scary Internals Land. I've not got
>> the latest PyObjC on my laptop, and my laptop is at home so I can't
>> update, but does this sound familiar to anyone? Might it be cured by
>> a new libffi (for example)?
>
> Have you read Ronald's follow-up message to mine you're citing?
Yes.
> Ronald Oussoren wrote:
>
>> Now that I look at your message again I see what's wrong: don't use
>> outlets to store the committedLength. If you store anything in
>> outlets you must make sure that that object stays alive by other
>> means (e.g. store a reference in a regular instance variable or even
>> call 'retain'). That doesn't help for "plain python" value though,
>> therefore you shouldn't store plain-python values in outlets. I'm
>> going to add something about this issue to the documentation.
>>
>> Basic guideline: Only use outlets if you're going to set them from
>> Interface Builder, otherwise use "regular" instance variables.
>
> Does that help?
No :-)
Cheers,
mwh
--
If you're talking "useful", I'm not your bot.
-- Tim Peters, 08 Nov 2001
|
|
From: Michael H. <mw...@py...> - 2003-10-22 17:01:52
|
Michael Hudson <mw...@py...> writes:
>> def textView_shouldChangeTextInRange_replacementString_(self,
>> textView, charRange, replString):
>> "Allow editing only after the previously committed text."
>>
>> return charRange[0] >= self.committedLength
>
> If I implement this delgate method and press "backspace" in the text
> view, I get a core dump deep in Scary Internals Land. I've not got
> the latest PyObjC on my laptop, and my laptop is at home so I can't
> update, but does this sound familiar to anyone? Might it be cured by
> a new libffi (for example)?
Well, I updated to pyobjc 1.0 and the new libffi and it now works, so
I'm not going to worry about this any more.
Cheers,
mwh
--
The only problem with Microsoft is they just have no taste.
-- Steve Jobs, (From _Triumph of the Nerds_ PBS special)
and quoted by Aahz Maruch on comp.lang.python
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X