Вот сделал несколько рисунков окон с описаниями. Это примерные рисунки, всё должно выглядеть более красиво  . Критика приветствуется   

Итак ViewWindow
Основное окно. Таких в программе юзер сможет создать сколько угодно. Назначение: просмотр списков файлов и начало операций над ними


ActionDialog
Диалог на операцию с файлами


ActionWindow
Окно позволяющее наблюдать за процессом файловых операций и управлять ими


Так же планируется два окна: 
1. Окно настроек 
2. Информационное окно (о проекте, участниках и тд…) 
ну с этими окнами чуть позже…

Это сообщение отредактировал(а) Rohoss - 16.6.2010, 00:46

Сложно что-то сказать. Наверное, для начала неплохо бы в разделе "Разработка" указать, что должен уметь проект, и начать с архитектуры движка, интерфейс это уже дело десятое, не с него начинать-то будем.

PS очень прошу, поменяй хостинг имагов на imageshack.us )) Текущий просто безобразный) Неудобен до жути и еще баннер с порно сверху))

не вопрос? xmages.net гугл мне просто первым в списке выдал.


Ну это наверное лучше в разделе "Архитектура" описывать...


При разработке движка придётся учитывать особенности интерфейса, так же как и при разработки интерфейса особенности движка... Лучше хи разрабатывать совместно (движок + часть интерфейса), но в общем по этому поводу идеи изложу в другой теме. И ещё, по моим предположениям, интерфейс будет куда сложнее движка...

Вообще, как я вижу этот процесс, должно быть так:

•  Дизайнеры. Занимаются рисованием интерфейса. Основываются они на том, что должна уметь программа, т.е. фактически на возможностях движка, но из этих возможностей им достаточно знать лишь вид предоставления данных (какие контролы выбирать для работы) и собственно что может этот движок, чтобы лишнего ничего не было. Кстати, по интерфейсу - обилие кнопок Button не есть здорово, интерфейс нужно по возможности минимализировать, а не делать здоровые "лапти" на половину окна)) До крайностей тоже доходить не надо, но по возможности это лучше привести к интерфейсу вида, к примеру, MS Office 2010, либо к чему-то подобному. Имхо.
•  Программисты связующих модулей. Занимаются разработкой связки между интерфейсом и движком (по модели MVC работать ведь будем, надеюсь?). Вот этим людям нужно знать и то, что и в каком виде предоставляет движок, и то, как это должно выглядеть в итоге в самом окне программы (собственно контролы, с которыми работают дизайнеры), чтобы правильно связать их между собой.
•  Программисты движка. Занимаются чисто движком. Их вообще не волнует интерфейс и им абсолютно все равно, как возможности программы будут влиять на отображение внутренних данных. Единственное, что им неплохо бы знать - это в каком виде лучше предоставлять данные (списки, массивы, ну или как-то еще, вариантов много).
•  Координатор проекта (это ты в нашем случае). Вот ему нужно знать абсолютно все аспекты, начиная от интерфейса и заканчивая возможностями движка и видом, в котором он предоставляет данные. На то он координатор)) Полностью составляет план возможностей программы, набрасывает в целом рисунок интерфейса и передает его на усмотрение дизайнеров, помогает скооперироваться всем слоям разработчиков (их у нас три в данном случае).

Вот как-то так, на мой взгляд, это должно происходить. Одновременная разработка, как ты и хотел, но в полной кооперации за твоим неусыпным наблюдением, и наиболее эффективная разработка.

.
Если
Model – это непосредственно файловая система
View – пользовательский интерфейс
Controller – движок приложения
Тогда да   


WPF дизайнеры редкость. Так что я так понимаю нам придётся как-то самим...


Ну у нас то функционал попроще будет   .  В общем, я думаю этот вопрос затронем когда дойдём до этого момента в разработке...


Предположительно, у нас с движком будет связано только окно ActionWindow.


Ну это само собой...

Ну и ещё довольно сложно будет реализовать логику графического интерфеса. Точнее, окна ViewWindow. Отделить логику от интерфеса там будет очень сложным и возможным только частично. В общем, когда к этому дойдём, затронем вопрос по новой   

Ок, но вряд ли можно будет все твои дополнительные окна заставить работать без какой-то фактической основы в движке, как мне кажется. Кста, вынеси последние три мессага в отдельную тему по обсуждению процесса разработки, сюда мешать нарно не стоит (имхо).

PS модель я имел в виду эту, да.

Добавлено через 1 минуту и 9 секунд
Только не файловая система, а собственно работающее приложение.

Model - работающее приложение, взаимодействующее с пользователем непосредственно.
View - связка между приложением и движком, опосредованно работает с пользователем и напрямую работает с движком.
Controller - движок, сам по себе.

Почему не MVVM? Мы в наших проектах используем близкий к нему подход. Очень удобно.

HalkaR, в общем-то, верно, я просто не слышал про этот паттерн. Для WPF он действительно вроде как больше подходит, но это уже на усмотрение ПМ, т.к. моя задача - движок, он с WPF связываться не будет, да и познания в нем у меня, мягко говоря, слабоваты.

Добавлено через 10 секунд
Линк про MVVM: http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

Добавлено через 41 секунду
Поправочка, оно же на русском: http://msdn.microsoft.com/ru-ru/magazine/dd419663.aspx

Кстати какое-то очень сложное описание.

HalkaR, первое, что попалось, найди попроще? Выложи тоже сюда, пригодится мб.