Версия для печати темы

Автор: trdm 10.2.2008, 23:53

Планирую сделать множество разных "документов" в смысле управляемых QWorkspace дочерних окон,
в которых будет разнородное содержимое: текст, формы разных типов, таблицы.
Каждый из типов документов имеет свои уникальные действия.
У некоторых документов есть даже свои менюшки 1-го уровня и панели инструментов. В смысле не одна а несколько.
как мне правильно архитектурно скомпоновать их в интерфейс?
есть ли примеры, которые можно посмотреть?
зарезервировать в главном меню максимальное количество возможных меню и при смене активного чилда перестраивать менюшку?
Как быть со стандартными акциями типа "ЗАписать", "Вырезать", "вставить", "Поиск" и т.п.
Сделать абстрактный класс МидиЧилд, добавить в него политики, типа
// политика доступности определенных действий для документов
// т.е. действие доступно: Всегда, Никогда, Запрос на доступность.
typedef enum _docActionPolicy {
actPolisyAlways
, actPolisyNever
, actPolisyAsk
} docActionPolicy;
в базовом заглушить их, а в наследнике разрешать только доступные/реализованные?
Вобщем кучка вопросов, на которых непонятно как правильно ответить (
Поможете?

Автор: trdm 11.2.2008, 0:17

Или ввести в базовый виртуальную функцию типа: bool MdiChild::docPolicyHelper(docPolicyEnumerator searchPolicy),
Которая сама должна ответить на вопрос о стандартных акциях, доступно ли?

Автор: trdm 11.2.2008, 1:11

так с политиками управления "стандартными акциями" для разных документов разобрался через "docPolicyHelper".
Удобно получилось и интерфейс живой и настраивается легко и прехватить есть где.
А вот как быть с дополнительными панелями инструментов и менюшками, зависимыми от типов документов пока не вкурю как сделать (((
ПС. вообще нравится мне QT, очень легко программируется, и свободно как-то не то что в MFC.

Автор: Litkevich Yuriy 11.2.2008, 8:07

У тебя нет книжки "Патерны объектно-ориентированного проектирования" Э.Гамма и др.?
Там рассматривается пример создания тектового редактора Lexi, может быть это то что тебе нужно, я чесно говоря мельком посмотрел.

Автор: ViGOur 11.2.2008, 10:53

Создаешь класс, общий для всех меню, от него делаешь производными дополнительные классы, а потом на лету меняешь менюшки. Тоже самое для панелей инструментов.

Главное создавать меню и панели инструментов не в QDesigner, а динамически, во время выполнения, примерно так: http://www.forum.crossplatform.ru/index.php?showtopic=62

Автор: trdm 11.2.2008, 12:52

Не совсем то, что надо. Опишу поподробнее.
Есть главное окно, экземпляр QMainWindow, "внутри" QWorkspace.
У производный от QMainWindow есть свое главное меню: 1-й уровень: Файл, ...., Сервис, Окна, Справка.
Так вот нужно при активации определенного вида документа добавлять в гл. меню QMainWindow специальные менюшки "вида активного документа" в место "...,". То же самое и с панелями. Как это правильно архитектурно сделать?
Создавать панели и меню на лету, тут проблем нет.

Автор: ViGOur 11.2.2008, 13:49

Как вариант можно заморочиться с http://www.crossplatform.ru/documentation/qtdoc4.3/qmainwindow.php#setMenuBar, а именно устанавливать свое меню при активизации документа и возвращать назад при уничтожении...

Автор: trdm 11.2.2008, 14:12

В смысле? А как с фиксированными менюшками, которые доступны при любом активном документе или без них?
Мне их в каждый документ лепить?
Короче не выход.
Да тут еще один момент, нет смысла создавать в каждом экземпляре документа меню, зато есть смысл хранить аскции и меню в самом экземпляре QMainWindow.

Автор: ViGOur 11.2.2008, 14:18

Угу, но из одной общей для всех функции члена.

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

Автор: trdm 11.2.2008, 14:43

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

Автор: ViGOur 11.2.2008, 14:45

Почему же?

Автор: trdm 11.2.2008, 15:07

Сам попробуй. прикинь количество кода и управляемость.

Автор: ViGOur 11.2.2008, 15:32

Как раз я прикинул, почему и привел как вариант.
Например:

class CMainMenu
{
   void createDefaultMenu()
   {
      // здесь создаются основные пункты меню и все связанное с ними
   }

public slots:
   createAdditionalMenu( QMenu *pMenu);
   deleteAdditionalMenu( QMenu *pMenu);

signals:
   createMenu( QMenu *pMenu);
   deleteMenu( QMenu *pMenu);
   // ...    
};

Далее тебя при появлении документа нужно только отправить сигнал: emit createMenu( new QMenu());

И где неуправляемость?

Автор: trdm 11.2.2008, 16:23

И куда мне этот класс пристроить? Как член QMainWindow?
Опять масло-маслянное получается.
Откуда этот класс "CMainMenu" будет знать какие "AdditionalMenu" мне нужны?
Ты кстати решал подобные задачи вообще?

Автор: Litkevich Yuriy 11.2.2008, 16:30

Если я правильно понял ViGOur'а, то этому классу и не нужно знать, он получит указатель на подменю, и его задача встроить это подменю в главное меню, и заниматся его учетом, т.е. чтобы потом удалить только то подменю которое нужно.

Автор: ViGOur 11.2.2008, 16:44

Угу

В плоть до того, что делал даже динамически генерируемые окна с меню, наподобии 1C. Правда на MFC.

Автор: trdm 11.2.2008, 17:47

да. чтото логики сцепления/агрегации не улавливаю.

Автор: AD22 11.2.2008, 17:50

Сцепление происходит за счет сигналов/слотов, функция connect!

Автор: trdm 11.2.2008, 18:37

Это понятно.
А можно глянуть на пример такой работы с разными видами документов?
ПС. Багира, спасибо за время редактирования!!! Вау!

Автор: trdm 12.2.2008, 16:31

Блин, а примерчик всетаки хотелось бы видеть...

Автор: ViGOur 12.2.2008, 16:49

Времени пока нет, я начал делать, но пока не закончил...

Автор: trdm 14.2.2008, 22:31

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

Автор: trdm 13.3.2008, 13:17

Спасибо за намек на букварь. Раз прочитал, иду на 2-й круг для закрепления
Следующими букварями пойдут:
М.Фаулер Архитектура корпоративных программных приложений
М.Фаулер - Основы UML
М.Фаулер - Рефакторинг. Улучшение существующего кода
Правда не знаю в какой последовательности....

Автор: Litkevich Yuriy 13.3.2008, 13:37

я б про него тожеб почитал, только ни книжки ни времени нету

Автор: trdm 13.3.2008, 14:25

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

Автор: Litkevich Yuriy 13.3.2008, 14:39

нашел наhttp://www.ozon.ru/context/detail/id/2260613/, надо будет купить, ты ее чита? мне надо чтоб с нуля, я вообще неимею представления, если на стрелки и квадратики смотеть еще куда нишло, а вот когда подписи на стрелках такие: 1...*, то вообще не понимаю что это значит

Автор: trdm 26.3.2008, 16:37

http://www.kde-apps.org/content/show.php/qmdilib?content=40721
qmdilib
Description:
This is a simple MDI library for Qt 4. The goal of this project,
is to provide an easy way to modifying menus and toolbars of windows
on demand. This can be used to present different menus and toolbars to
widgets inside a QTabWidget, hiding or showing a different set of menus
on demand or even enabling a small plugin system.

The library is fully documented, and contains some demonstrations. It should compile
flawlessly (no warnings) with a single "qmake; make" on the root directory of the
project. It is known to work on Windows and Linux, and there is no reason why it
should not work on other platforms supported by Qt4. Currently only gcc is tested,
but other compilers should be able to compile this library
----------------------------------------------------------------------------------------------
Не совсем то что надо, однако существенный шаг в эту сторону...