Russian Qt Forum
Ноябрь 22, 2024, 22:51 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: 1 2 [3] 4   Вниз
  Печать  
Автор Тема: Архитектура ..  (Прочитано 20832 раз)
Bepec
Гость
« Ответ #30 : Август 14, 2013, 08:37 »

Я лично пока никак не вижу, склоняюсь к MDI (если правильно понимаю это слово), как в Visual studio.
Записан
Old
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 4350



Просмотр профиля
« Ответ #31 : Август 14, 2013, 08:56 »

Я лично пока никак не вижу, склоняюсь к MDI (если правильно понимаю это слово), как в Visual studio.

Это набросок интерфейсов, что бы модули могли манипулировать GUI. Эти интерфейсы зарегистрирует специальный модуль gui.
Код
C++ (Qt)
class IMainWindow : public Interface
{
public:
   // Добавить/удалить окно в область MDI
   void    addWindow( QWidget * ) = 0;
   void    removeWindow( QWidget * ) = 0;
 
    // Установить/получить активное окно
   void    activateWindow( QWidget * ) = 0;
   QWidget *activeWindow() = 0;
 
   // Получить список всех окон
   QList<QWidget*> windows() = 0;
};
 
class IMainMenu : public Interface
{
public:
   // Добавить/удалить действие в указанный пункт меню
   void    addAction( const QString &menu, QAction *, int index = -1 ) = 0;
   void    removeAction( const QString &menu, QAction * ) = 0;
   void    addSeparator( const QString &menu, int index ) = 0;
};
 
class IToolBar : public Interface
{
public:
   // Добавить/удалить действие в указанный пункт меню
   void    addAction( QAction *, int index = -1 ) = 0;
   void    removeAction( QAction * ) = 0;
   void    addSeparator( int index ) = 0;
};
 

Сейчас нужно продумать зависимости модулей друг от друга с определением правильного порядка их инициализации.
Что бы не получилось, что мы инициализируем модуль, который попытается использовать сервисы другого модуля, который еще не инициализирован.
В том же QtCreator для этого используются специальные файлы, но я думаю с интерфейс плагина лучше добавить еще один метод, который будет возвращать список строк с именами модулей, которыми он пользуется.
Записан
Bepec
Гость
« Ответ #32 : Август 14, 2013, 08:57 »

Извините меня пожалуйста, я не успеваю за вашей скоростью. Не хватает времени на работе всё это попробовать и понять. Грустный
Записан
Old
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 4350



Просмотр профиля
« Ответ #33 : Август 14, 2013, 09:02 »

Извините меня пожалуйста, я не успеваю за вашей скоростью. Не хватает времени на работе всё это попробовать и понять. Грустный
Это ничего. Улыбающийся
Я сейчас основные мысли свои запишу, а потом будем исследовать разные варианты. Плюс может еще кто-то захочет поделиться своими мыслями.
Записан
voral
Гость
« Ответ #34 : Август 14, 2013, 11:15 »

Черт - не понятный треп вылился в интересное обсуждение. Не уловлю вы обсуждаете на примере общих исходников теста. Или "на бумажке" оперируя только интерсными участками?

По поводу MDI/SDI (если я правильно понял тему) - это вообще не важный момент. Он касается только реализации модуля gui. По хорошему надо исходить, что может быть и тот и тот вариант.

Идея со специальным методом сообщающим необходимые модули мне кажется вполне рабочей. Только, имхо, стоит различать модули которые должны быть загружены на момент загрузки данного модуля и модули которые будут необходимы для работы. 
Тоже на уровне сырой идеи.
По первому списку определяется порядок загрузки, по второму списку по окончанию регистрации/загрузки всех модулей принимаем решение, примерно следующая последовательноть:
 идем от последнего загруженного модуля к первому. На каждом модуле (пусть модуль А) выполняем примерно следующее:
- если все нужные модули загружены все ок
- если какого либо модуля (модуль Б) не достает или он неработоспособный:
а. если наличие модуля обязательно - помечаем  модуль А как неработоспособный
б. не обязательно - помечаем как ограничено работоспособный

Если Все модули оказываются неработоспособными работать дальше смысла нет. Если ограниченно - просто сообщения при попытке соответствующиего вызова

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

Модуль протокола он зависит от БД (нам туда писать надо). ок БД загружаем первым. Но ошибки при работе с БД надо отправлять в модуль протокола (напрямую писать не правильно. Может юзер решит, что протокол в базе это лишний мусор и подключит модуль который будет писать в текстовые файлы.



Записан
voral
Гость
« Ответ #35 : Август 14, 2013, 11:18 »

Упс... Как я умудрился два раза прочитав тему пропустить исходное сообщение, с которого началось все интересное не знаю.  Обеспокоенный
Может быть мои идеи черезмерны для данной задачи.....
Записан
Old
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 4350



Просмотр профиля
« Ответ #36 : Август 14, 2013, 14:40 »

По поводу MDI/SDI (если я правильно понял тему) - это вообще не важный момент. Он касается только реализации модуля gui. По хорошему надо исходить, что может быть и тот и тот вариант.
Да, это совершенно не важно для всей системы в целом, но не хочется придумывать сферического коня в вакууме. Поэтому я и предлагаю исследовать этот вопрос на примере реальной задачи.

Идея со специальным методом сообщающим необходимые модули мне кажется вполне рабочей. Только, имхо, стоит различать модули которые должны быть загружены на момент загрузки данного модуля и модули которые будут необходимы для работы. 
Проблема циклических зависимостей может возникнуть только если вы разрабатываете сразу несколько модулей или написали свой модуль и хотите научить других с ним работать. И в первом и во втором случае приходиться модифицировать исходники нескольких модулей.
В этом случае это легко обходиться без дополнительных телодвижений со стороны загрузчика модулей. Для этого можно использовать invokeMethod.

Сейчас продумываю как лучше формировать последовательность инициализации модулей. Мысли и идеи приветствуются. Улыбающийся
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #37 : Август 21, 2013, 10:25 »

Черт - не понятный треп вылился в интересное обсуждение. Не уловлю вы обсуждаете на примере общих исходников теста. Или "на бумажке" оперируя только интерсными участками?
Первоисточник - вот этот многострадальный топик
http://www.prog.org.ru/index.php?topic=25332.msg182126#msg182126
Читать все замахаетесь, кратко - человек пока не умеет создавать классы и лепит все в MainWindow. Вот стало интересно а как же правильно.

По поводу MDI/SDI (если я правильно понял тему) - это вообще не важный момент.
...
Идея со специальным методом сообщающим необходимые модули мне кажется ...
..
Почему, на мой взгляд, это важно:
Одна вещь Вам кажется неважной, другая - важной. Это Ваше право, но точно так же другой может считать наоборот - в результате обсуждать нечего  Улыбающийся

Извините меня пожалуйста, я не успеваю за вашей скоростью. Не хватает времени на работе всё это попробовать и понять. Грустный
Ну хорошо хоть без "ребят" Улыбающийся  А на деле видимо так: глянул - что-то сложновато, надо вникать и вжиться в темплейт (слава богу один). Потом надо приспособить как-то к своей задаче - и хз удастся ли. Та ну его нафиг, тем более не так уж горит. Если в чем-то ошибся - поправьте.

Предложенный Old интерфейс в библии обозначается типа "проекты которые мы знаем как делать" , т.е. техника/шаблон известны, наверняка не раз юзалось, так почему бы не задействовать?  Манечка с возвратом интерфейсов известна давно и часто переоценивается. Когда-то (давно) я написал пару плагинов для Adobe Acrobat - и был удивлен что никаких интерфейсов/классов нет, а просто на С (одна точка входа). Однако пофыркав я обнаружил что это совсем не так уж плохо. Впрочем если модули независимы - проходит любой протокол обмена хост-плагин.

Да, и по-взрослому API плагина должно предоставлять свой кросс-платформенный UI (а не делать предположения о Qt или др фреймврке)  Улыбающийся
Записан
Bepec
Гость
« Ответ #38 : Август 21, 2013, 10:36 »

to Igors:

Это называется дежурство на полигоне без компьютера, интернета и цивилизации Улыбающийся Увы. Дикарём становлюсь.
Записан
_Bers
Бывалый
*****
Offline Offline

Сообщений: 486


Просмотр профиля
« Ответ #39 : Август 25, 2013, 15:39 »

Есть у кого нибудь готовый механизм для анализа строки?

Требования: с++ (без qt)
Требования: удобный, простой для понимания, оптимизирован по скорости (парсить нужно быстро в рантайме)

Например, есть текстовый файл. Формат - любой. Не обязательно xml-подобный.
Нужно очень быстро собрать для него загрузчик.

Другой пример: в рантайме создается динамическая структура данных полная по тьюрингу.
Нужно конвертировать содержимое структуры в sql-подобный синтаксис.

Другой пример: скриптовый движок. Нужно в рантайме парсить исходный текст скрипта, и исполнять его.

В общем, требуется механизм, который позволяет удобно и легко для программиста быстро создавать собственные парсеры под разные задачи.
Записан
m_ax
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2095



Просмотр профиля
« Ответ #40 : Август 25, 2013, 19:32 »

В общем, требуется механизм, который позволяет удобно и легко для программиста быстро создавать собственные парсеры под разные задачи.

boost::spirit   
Записан

Над водой луна двурога. Сяду выпью за Ван Гога. Хорошо, что кот не пьет, Он и так меня поймет..

Arch Linux Plasma 5
_Bers
Бывалый
*****
Offline Offline

Сообщений: 486


Просмотр профиля
« Ответ #41 : Август 25, 2013, 19:52 »

boost::spirit   

Отклонено. Стоит более внимательно относится к собеседнику:

В общем, требуется механизм, который позволяет удобно и легко для программиста быстро создавать собственные парсеры под разные задачи.
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #42 : Август 26, 2013, 09:59 »

В общем, требуется механизм, который позволяет удобно и легко для программиста быстро создавать собственные парсеры под разные задачи.
Ну слышал есть еще Бизон. Написал не один парсер и задумывался об "общности". Довольно трудно. Как правило время на написание парсера - ну 2-3 дня максимум, обычно меньше. Что-то обобщить и продумать не удается. Да, через годик опять возникнет нечто подобное - и опять придется что-то городить, ну это день, переживу. Также не видно какого-то "доминирующего" известного тулза. 
Записан
Old
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 4350



Просмотр профиля
« Ответ #43 : Август 27, 2013, 17:46 »

Реализовал зависимости модулей друг от друга, с защитой от циклических зависимостей.
Добавил еще один модуль gui, который зависит от logger.
Показал, как можно пост-инициализировать logger, что бы он мог настроить свой ui, уже после загрузки модуля gui (логер добавляет окно с логом).
Интерфейс gui пока примитивный для примера.

Основной функционал готов, остается хорошо продумывать интерфейсы и их реализовывать. Улыбающийся
« Последнее редактирование: Август 27, 2013, 20:59 от Old » Записан
voral
Гость
« Ответ #44 : Август 28, 2013, 01:10 »

Просто беглый пуск:
1. make:
Цитировать
[  4%] Generating moc_moduleloader.cxx
[  8%] Generating moc_workspace.cxx
/home/alex/ProjectC/modprog/modprg/core/workspace.h:0: Note: No relevant classes found. No output generated.
2. Если модули не доступны прога вылетает
Код:
$ ./modprg
Available modules: ()
Initialized modules: ()
Registration services:  ()
Ошибка сегментирования
Записан
Страниц: 1 2 [3] 4   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.081 секунд. Запросов: 22.