[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 |
Hi,
From: Stefan Urbanek <urbanek@host.sk>
To: Yen-Ju Chen <yjchenx@hotmail.com>
CC: discuss-gnustep@gnu.org
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.
Yen-Ju
Best regards,
Stefan
--
http://urbanek.host.sk
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