> From: Chris Burke <[email protected]>
>
> Oleg Kobchenko wrote:
> > An interesting solution for a simplified IDE is the Xcode Organizer.
> > http://www.macresearch.org/tutorial-introducing-xcode-30-organizer
> >
> http://developer.apple.com/iphone/library/documentation/DeveloperTools/Conceptual/XcodeProjectManagement/140-Using_the_Organizer/using_the_organizer.html
> > It is like a text editor with a "projects" browser in a side bar tree.
> >
> > A project is just a folder with sub-folders and some defined
> > targets (build, clean, run, custom) similar to Java Ant.
> > Many projects can be added to the tree as roots, so there is
> > an active project, and an active target.
>
> Thanks. The Organizer looks like a combination of J's project manager +
> find in files. In the new IDE these should be both together; right now
> they are partly linked, but as separate applications.
Yes, Find In Files is a good candidate, but I am thinking of many other
"browsers" that can be placed into the side-bar, one at a time, switched with
small sticky toolbar icons:
* Workspace -- just like Organizer or Eclipse--a collection of added roots
(projects),
of which one is the Current "project", whose targets are executed.
But these "projects" are just folders, typically roots of particular addons.
A workspace can be saved and another opened, with last opened b default.
Could be either a single tree of mixed folders and files, or a folder
tree and list of selected folder files at the bottom--may be togglable.
Folders can be run-time like addons, or SVN-controlled with check-in/out
operations; possibly with diff/sync between them.
* Folder browser -- direct browsing starting from some root. But this may be
superfluous, since it can be accomplished in the Workspace--with a single
root for casual users or uses
* Globals -- list of global definitions in the current script.
"NB. ===" or "NB. ---" followed by "NB. comment" creates indented sections in
this list like a tree. Double-clicking scrolls to it.
* Locales -- two vertical lists: top is locales, bottom is names in the locales
Double-clicking a name opens its original script and scrolls to the name.
* History -- tree or two-list of scripts grouped by date.
* Unit Test -- hierarchy of folders (starting from a root), test files
and test verbs; so that any level can be re-executed selectively
* Debugger -- current stack and variable values, with breakpoints and
stepping in the text window--using read-only source script if available
or a dummy script if not. A list of all breakpoints can be a sub-tab
with delete and navigate to. Selecting this side bar turns on debugging.
Actually it could make sense to have an API for side bar and other IDE
extensibility so that users could contribute their own side bars;
it could be configurable which are selectable in the toolbar.
To complement the side-bar browsers, there should be navigation from
within the script by Ctrl+clicking the following hot spots:
* required or loaded other scripts
* coinsert classes
* global definitions in current or other scripts
* a J primitive
When Ctrl is pressed, hovering over a hot spot underlines it like a hyperlink.
Holding the mouse longer will reveal details about the hot spot in a tool-tip:
name of defining script, scriptdoc or dictionary definition.
> > One way to promote ProgMan and make it easier to use, is to integrate
> > such Organizer with the edit window. It would act as an "explorer" to
> > browse or open adjacent files and folders, but when a project file is
> > present it will run targets from it.
>
> Yes, PM will be integrated into the edit window.
>
> > Separation of targets and actions. E.g. "compile" is an action of
> > combining one or more J scripts, resolving imports and removing
> > comments; then "compile" action can be used in different targets
> > such as "build" alongside other actions like copy, create folder etc.
> > There may be multiple targets per project. A target may be dependent
> > on other targets in current or other (sub)projects.
>
> This ability to associate various actions with a project is a very nice
> feature. In J, I often switch to another project, do something, then
> switch back. In Organizer I could stay on the one project, but still run
> that something in another project.
Yes, you can have multiple project/folders in one Workspace, but you can
also switch between Workspaces. I don't see why you can't open multiple
Organizers each with its own Workspace. If the side bar can be hidden,
it becomes a regular single script window, which if you choose to open
another script in a new tab becomes a tabbed window. So the side bar and
tabs being optional this behaves like a web browser, so you can mix and
match them to sculpt your browsing or development experience however you like.
Speaking of targets and actions, yes I think they are valuable with the
features: targets are multiple but equal, have dependencies, etc.
On the other hand, some targets/actions do not have to be explicitly
described in a project, they can be derived by convention, e.g.
* all the testing stuff can be represented by tests script identified
by naming convention: see the general/unittest addon.
* instead of listing included files in a project (target), have a "main"
script, which will use the "script_z_ 'script'" so that you can either
run it directly, or "build" it by replacing those entries with the
contents of referred files and saving into the root folder with
some name (could be same a folder name or defined in metadata comment
in the "main" script). But I don't like this specific idea--if you
need a dumb script just to list includes, it is better represented
in a project target among other targets.
So with Workspace side bar, your choice of Run options increase; in
addition to Run Line, Selection, Window you have:
* Run Selected Script
* Run Active Target in Active Project
* Run Active Target in Selected Project
In Workspace for each root it remembers which target is Active, if it is a
project,
or a script if just a folder. So in a project, one target must be marked as
default.
To support multiple nested projects in one addon (root), besides an action
to build project output script, there should be an action to invoke a target
in another project in sub- or sibling- or any folder).
Although project may have multiple targets, there should be only one project
per folder.
To summarize the hierarchy:
+-- Worspace1 (only one workspace per window)
+-- Worspace2 ... -- a logical collection of Roots (many per Workspace)
+-- Root1 ...
+-- Root2 ... -- a physical folder
!-- Project -- only one (or zero) per folder
@-- Target 1
@-- Target 2
o-- Script1
o-- Script2
+-- Sub-Folder1
!-- Project
@-- Target 1
@-- Target 2
o-- Script3
+-- Sub-Folder2
+-- Sub-Folder2.1
Projects and target are not listed in the tree; a project-less vs project
folder can be identified with different icons; active project and target
can be specified in drop-downs or project by making the folder label bold
and target in a pop-up menu.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
