[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CodeEditor 0.4.3 is released

From: Yen-Ju Chen
Subject: Re: CodeEditor 0.4.3 is released
Date: Sun, 05 Oct 2003 00:55:08 -0400


From: Stefan Urbanek <address@hidden>
To: Yen-Ju Chen <address@hidden>
CC: address@hidden
Subject: Re: CodeEditor 0.4.3 is released
Date: Sun, 05 Oct 2003 01:57:49 +0200

Would it be possible to strip all type info and leave just selector? Instead of -(void)setObject:(id)anObject forKey:(NSString *)key there will be just setObject:forKey:. Another things are: it should be resizable and when I select a method I would prefer to scroll text view so the method is at the top.

 I'll try to do that. The scrolling is more complicated.
 It uses some existing method in NSTextView for that,
 and there is some small problems in the language bundle.
 But they should be easy to fix.

CodeEditor is a text editor so that I won't address much on code parsing.
But the parsing mechanism might be suitable for other projects.

Would not it be better to leave "general purpose text editor path" in the favor of the application name: CodeEditor which will really understand the code developer is writing there?

 That problem is that CodeEditor deal one file at a time,
 not header and implementation together.
 But it's the matter of choice. See below.

Features in very distant future: find implementation of given selector.

If you want some features for CodeEditor, especially on the text view,
please let me know so that I can start "thinking" of it. :)

The tabbed editing is confusing and I would suggest removing it in the fawor of more intelligent code organising and browsing.

I would prefer some very simple scrollabe window with similar functionality like the Windows menu. Functionality: browser with last path component of a filename; when single-clicked window is taken into focus. There should be optional buttons/Popup button menu: Hide others (will hide all other windows except selected), Minimise selected windows (multiple selection), Close selected windows.

Btw. if your codeeditor understands ObjC code, you can have class names in that window instead of filenames, and by pointing on a class, corresponding window with its implementation/interface is opened.

What do you think?

 That's the choice of where CodeEditor should go.
Originally, I'm thinking it is a non-rich text editor with some code handling functions. Therefore, it handles on the file content only, not extends to other related files. I think working among related files is the function of project manager, aka ProjectCenter.
 In this case, CodeEditor won't be able to handle header and implementation
 because at most of the time, they are in different files.
I do think to take off the tab view and use a browser for fast file switching.
 But it seems to be a function of project manager so I didn't do that.

Now, the non-rich text editor and code handling functions are mixed together,
 limit each other, and makes implementation a little big harder.
I'm thinking to seperate the non-rich text view and code handling into different bundle/library. In the non-rich text view, you can only use one font, can change color, etc,
 which will make rendering much faster than NSTextView,
 which handle too much functions like attachment, different fonts, etc.
 In code handling functions, it may just be some classes.
 Then I will have a non-rich text editor, which use non-rich text view;
and an code editor, which use code handling functions and display the result
 in the non-rich text view.
 The code editor can have any functions people want,
 but it will be very similiar to ProjectCenter, which make me think whether
ProjectCenter should support these functions rather than a seperated code editor. By doing these, I probably need a framework rather than a lot of bundles/libraries,
 which give the rise of the question whether we need a unified framework
 for ProjectCenter, Gorm and CodeEditor.

 In short, the design of CodeEditor need some big changes now.
I probably will take the non-rich text view out of it and make it independent.
 The goal is to have a fast rendering text view assuming
 only one font, no attachement, etc (non-rich text).
 Then the question is where the rest go ?
 It could be just a library for ProjectCenter and Gorm in code parsing.
 Or it could be an independent code editor
 but has some overlapping functions with ProjectCenter.
I'm open mind in this question and prefer the first choice (just a library for PC and Gorm) to reduce the work to maintain a full application because if everything goes well, I probably will not be able to maintain codeeditor less than one year later.

 Sorry for the lenghy reply. That's just something in my mind
 and would like to hear some suggestions and comments.


Best regards,


First they ignore you, then they laugh at you, then they fight you, then you win.
- Mahatma Gandhi

Get MSN 8 Dial-up Internet Service FREE for one month. Limited time offer-- sign up now! http://join.msn.com/?page=dept/dialup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]