Советы по архитектуре Cocoa для небольшой IDE

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

  1. Have the possibility to set project details, similar to what XCode does when user creates a new project; probably the possibility to include accessory views for project details that might be stored in user defaults or plists.
  2. Have the possibility to save the project in a custom, specific filetype, with a specific extension that the app will be owner of (document-based app).
  3. Have the possibility to add new files to the project, in particular h-file headers that will be automatically included for compilation; when choosing new file, to have the possibility to choose the type of file (similar to XCode);
  4. Have a simple editor, text-view-based, for example, without syntax coloring, check, highlighting; however to design it in such a way to allow future development of syntax coloring/ check, via a NSScanner, for example;
  5. Have the possibility to auto generate a Makefile for compilation, based on any persistence method at choice.
  6. Have the possibility to log compiler verbosity into a logging view (text view?) either via stdout or other better approach;
  7. Using an NSOutlineView with a tree controller (for example) for file browsing (similar to the XCode's project files on left pane);
  8. Having the project packaged into folder-like project files, with NSFileWrapper for example (that will include the main.c file, additional header, the autogenerated Makefile and a plist for project settings etc);
  9. Having settings persistence using NSUserDefaults for project settings and application preferences via application-shared singleton (for example);
  10. Using some classes in the model component to connect with microcode compiler via NSTask and display compilation and upload results in the logging text view;
  11. etc

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

Я был бы признателен за любой возможный намек на это. Спасибо, что уделили время. Если кому интересно, буду держать в курсе о ходе.


person Tom    schedule 20.06.2011    source источник
comment
Звучит как интересный проект, но SO не совсем подходящий форум для обсуждения дизайна вашей программы. Если вы сможете выделить несколько фактических конкретных вопросов (на которые будут фактические подробные ответы), вы, вероятно, получите лучший ответ.   -  person walkytalky    schedule 20.06.2011
comment
Привет, Эймантас. Спасибо за ваш комментарий. Вы, наверное, правы, объем текста немалый. Но если задать простой вопрос, например, как бы вы подошли к архитектуре IDE на основе какао, в лучшем случае можно было бы встретить такие вопросы, как «предоставьте более подробную информацию». Так что прошу вашего снисхождения на этот счет.   -  person Tom    schedule 20.06.2011


Ответы (1)


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

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

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

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

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


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

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

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

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

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

person Peter Hosey    schedule 20.06.2011
comment
Дорогой Питер, Спасибо за ваш ответ. Цените потраченное на это время. Я рассматривал аналогичные шаги, которые нужно предпринять в отношении интерфейса (эскизы и т. д.), однако моя самая большая проблема сейчас состоит в том, чтобы понять, существует ли принятый шаблон проектирования или передовая практика (хотя, вероятно, неправильные термины), которые могли бы направлять общее создание. IDE, со спецификой классов fw какао, так как я действительно не хочу изобретать велосипед. Например (простой), рекомендуется ли использовать разделенные представления или отдельные представления для панелеобразного внешнего вида IDE? и т.д. Еще раз спасибо. - person Tom; 20.06.2011
comment
@Tom: разделенное представление не избавляет вас от создания отдельных представлений; это уточняет разделение между ними и позволяет пользователю регулировать их пропорции. Я рекомендую использовать разделенный вид для любого основного/подробного макета. - person Peter Hosey; 20.06.2011
comment
Спасибо, Питер. Я буду нырять глубже. С наилучшими пожеланиями, Том - person Tom; 20.06.2011
comment
Питер, проект находится на верном пути. В очередной раз благодарим за помощь. Том - person Tom; 08.07.2011