Какао Архитектура советы для маленькой IDE

Question

Я начал личный проект по разработке простой среды разработки Cocoa для программирования микроконтроллеров на Mac OSX Snow Leopard.Поскольку программирование не является проблемой, у меня есть некоторые трудности при выборе архитектуры для разработки высокоуровневых блоков приложения.Я думал о:

1. Есть возможность установить детали проекта, аналогично тому, что делает XCode, когда пользователь создает новый проект;вероятно, возможность включить дополнительные представления для деталей проекта, которые могут быть сохранены в пользовательских значениях по умолчанию или списках.
2. Иметь возможность сохранить проект в пользовательском, определенном типе файла с определенным расширением, владельцем которого будет приложение (приложение на основе документа).
3. Иметь возможность добавлять новые файлы в проект, в частности заголовки h-файлов, которые будут автоматически включены для компиляции;при выборе нового файла, чтобы иметь возможность выбрать тип файла (аналогично XCode);
4. Имеют простой редактор, основанный на текстовом представлении, например, без окраски синтаксиса, проверки, выделения;однако спроектировать его таким образом, чтобы в будущем можно было раскрасить / проверить синтаксис, например, через NSScanner;
5. Иметь возможность автоматически создавать Makefile для компиляции, основываясь на любом способе сохранения.
6. Иметь возможность записывать детализацию компилятора в представление журнала (текстовое представление?) Либо с помощью stdout, либо с помощью другого лучшего подхода;
7. Использование NSOutlineView с контроллером дерева (например) для просмотра файлов (аналогично файлам проекта XCode на левой панели);
8. Упаковка проекта в файлы проекта в виде папок, например NSFileWrapper (который будет включать файл main.c, дополнительный заголовок, автоматически сгенерированный Makefile и plist для настроек проекта и т. Д.);
9. Наличие постоянства настроек с использованием NSUserDefaults для настроек проекта и предпочтений приложения через синглтон общего доступа к приложениям (например);
10. Использование некоторых классов в компоненте модели для соединения с компилятором микрокода через NSTask и отображения компиляции и загрузки результатов в текстовом представлении журнала;
11. и т. Д.

Если кто-то из вас, обладающий гораздо большим опытом, чем я, приступит к такому проекту, какой выбор архитектурных компонентов вы выберете?То же самое (разделенные представления, текстовые представления, NSTask, обертки файлов, контурные представления с контроллерами дерева, отдельный делегат приложения от документа и общий экземпляр контроллера документов и т. Д.), Или вы выбрали бы другой подход?Намного проще?

Буду признателен за любую подсказку.Спасибо, что нашли время.Если кому-то будет интересно, я буду в курсе событий.

Answer 1

Я бы сказал, начать с пользовательского интерфейса.Подумайте, как пользователь будет использовать вашу IDE.

Будет ли она работать как Xcode 3?Xcode 4?Упрощенная версия либо?Еще одна существующая IDE?Что-то в значительной степени или полностью оригинальное?

Нарисуйте эскизы, будь то на бумаге или в вашем любимом графическом редакторе.Попробуйте разные макеты.Нарисуйте одно и то же разными способами и сравните их.

Подумайте о разных вещах, которые пользователь должен будет сделать.Как они это сделают?Один метод приходит за счет другой задачи?Стоит ли это того?

Как только вы поймете, как будет работать ваш пользовательский интерфейс, вы обнаружите, что из этого будут следовать ваша модель и компоновка вашего контроллера.

---

ЭтоПохоже, вы уже подумали хотя бы об этом, поэтому я расскажу только о нескольких ваших конкретных элементах:

• Есть простой редактор на основе текстового представления,например, без подсветки синтаксиса, проверка, подсветка;однако, чтобы спроектировать его таким образом, чтобы в будущем можно было разработать раскраску / проверку синтаксиса, например, с помощью NSScanner,

Анализ кода C с помощью NSScanner будет мешать.Возможно, уже существует подходящий текстовый просмотр / синтаксис-колорер, который вы можете использовать;Я бы, например, провел бы тщательный поиск, прежде чем сам приступить к такой задаче.Если бы мне пришлось написать что-то подобное с нуля, я бы посмотрел на , что Clang может сделать для меня .

• Упаковка проекта в подобный папке проектфайлы, например, с NSFileWrapper (которые будут включать файл main.c, дополнительный заголовок, автоматически созданный Makefile и plist для настроек проекта и т. д.);

Осторожно: NSFileWrapper используется, чтобы не понимать.svn каталоги.Это была большая жалоба на Интерфейсный Разработчик в 2x днях.Они исправили это в IB несколько лет назад, но я не уверен, что NSFileWrapper когда-либо получал это исправление.