Russian Qt Forum

Добрый день

Есть много объектов каждый из которых имеет много десятков параметров. Они разделены по категориям, в UI это обычно табки с обычными текстовыми полями, иногда попапками или чекбоксами. Когда юзер создает достаточно много объектов управлять ими становится затруднительно. Просто открыть "UI каждого" и там изменить уже нереально. Есть возможность изменить значение параметра сразу для всех выбранных объектов, это необходимо но не решает всех проблем. Выбор сам по себе уже непрост если объектов хотя бы сотни.

В общем надо развивать "зависимости". Упрощенно это выглядит так: есть master-объект к нему подключается любое кол-во slave объектов. Указывается какие параметры slave должен использовать от мастера, остальные рулит сам. Тогда меняя мастера юзер сразу получает множественные изменения. Ну это конечно случай простейший, наворотов здесь может быть масса - ну хотя бы "смешивать" значения, неск мастеров и.т.д  и.т.п.

Сейчас реализовано только замещение и только для одного типа объекта. Работает неплохо, но вылезает куча проблем, которые по существу сводятся к одной: неинтуитивность для пользователя, отсутствие визуального  feedback'а. Вот есть какое-то значение, юзер его меняет, но.. ничего не происходит :'(. Ах, оказывается оно копируется от мастера! А откуда это видно, где тот мастер, как на него соскочить? Ничего этого сейчас нет.

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

Спасибо

На ум приходит древовидная модель. Рисуете дерево, узлы это ваши master-объекты, дочерние узлы - slave-объекты. Если меняется свойство мастера, можно подсвечивать все slave объекты, у которых поменялось это свойство. Само свойство можно так же подсвечивать как то. Я бы наверное сделал так. Если конечно у вас не дерево а граф, то лучше задействовать графическую сцену и рисовать на ней объекты со связями. Лично я делал подсветку изменения свойства элемента на сцене его промигиванием определенным цветом в течении определенного времени.

В некоторых CAD системах присутствует статус окно. Туда выводится результат действия. Можно воспользоваться таким.
(http://i11.pixs.ru/storage/9/2/3/Bezimyanni_3126398_17523923.png)

По поводу "подсветки/подмигивания объекта" - они могут быть скрыты др объектами или вообще выключены или просто закрыты окна где они отображаются. Если добавление этой фичи все равно ничего принципиально не решает - зачем ее добавлять?

Насчет рисования деревьев - много такого видел, часто называется типа "Node Editor". Также склоняюсь к мысли что по-видимому он неизбежен. Но это отдельное (развесистое) окно, как связать его с текущими диалогами/UI?

Ну как-то при беглом взгляде неясно что к чему. Конечно кто этим занимается там все ясно, но все же у меня упор на связки/зависимости, типа "что зависит от чего" и "как это изменить" - этого я на скриншоте не увидел

QDockWidget? См. скриншот выше. Там есть такое ("explorer")

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

[off]
Ой :) Предел мечтаний :)
[/off]

Проблема в том, как визуально прикрутить дерево модели (построения)?

Ну вот, сразу чего-то крутить :) В первую очередь мне надо решить более прозаическую задачу

А что касается "дерево модели" - то "дерево" здесь совершенно ни при чем. Напр Object1,Param1 зависит от Object2.Param1 - но ведь никаких связей парент-чайлд из этого не следует. Напр Object2,Param2 с успехом может зависеть от Object1,Param2 - не было бы циклической зависимости, все остальное можно.

Как-то Вы "узковато" подходите, я бы сказал "не  концептуально"  :)

Вы бы нарисовали хотя бы приблизительно то что хотите, на словах ничего не понятно...

Ах как удобно включать "песню непонимания" :) Замечу что Ваши концептуальные вопросы были никак не яснее - и Вы ничего не рисовали. Ну да ладно, в какой-то визуализации всегда есть смысл (ну как бы включаются др органы чувств), попробуем

См аттач. Пусть Param1 - сам по себе, что юзер ввел - то и получил.  Param2 зависимый, а вот как - хз. Возможно полностью - что ни вводи пофиг. Но возможно и частично. А Param3 наоборот, кому-то "диктует" - но опять-таки насколько - хз. Как это визуализировать - причем лаконично, обязательно в общем виде, таких параметров сотни, что-то делать "для каждого" обречено

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

Вот мы поменяли в первом поле ввода данные. Они я так понимаю влияют на второе поле? Ну в процессе ввода, второе поле можно как то подсвечивать определенным цветом например. Или рядом или в toolTip выводить название изменённого свойства. Или расположить рядом кнопку, при нажатии на которую выводится окно со списком объектов, которые изменились.

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

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

С чего Вы взяли ???
Param1 "сам по себе", т.е. не участвует ни в каких зависимостях, А вот Param2 и Param3 участвуют. Также никто не обещал что зависимый/зависящий вообще находятся в зоне видимости открытого UI - это как правило совсем другой объект, может даже др типа.

Опять-таки давайте вернемся к моему "неясному объяснению"
Ну как-то снабжать каждый QLineEdit кнопкой..  :)

Это нельзя считать лаконичным, рабочих окон десятки, пристегивать к каждому что-то типа стекового виджета только для достижения частной/локальной цели - явно "не то"

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

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

offtop: Просто показалось забавным, на мой взгляд подходит.

Тип энергетического вампира: Беспомощная личность.
Человек, который ведёт игру «Почему бы вам не?…» — «Да, но…». В чем она заключается? Беспомощная личность рассказывает о своей проблеме и советчики (доноры) изо всех сил стараются её решить. Но сколько бы ни было советчиков, и какими бы умными они ни были - на каждое их предложение у него есть возражение. Когда круг замыкается, и вариантов решения больше нет, начинается новое развлечение «Разве это не ужасно?» В результате, проблема так и не решилась, доноры испытывают сильное эмоциональное и физическое истощение, а вампир доволен, он получил то, что ему было надо и идет искать, кому бы ещё пожаловаться.

А как Вы сами оцениваете количество и качество "всех попыток"? :) И злиться не надо, я Вам ничего плохого не сказал.

Ладно, пока с затеей "показать факт зависимости прямо в диалогах UI" ничего разумного не видно. И то что я предложил (зависимый синий, диктующий красный) тоже плохо - слишком "попугаисто". Ну что ж, может это я слишком много хочу, тогда почему не так:

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

Копнем в др сторону, что то за окно зависимостей. Набираем "Qt Node Editor" - ссылок море. Напр вот (http://nukengine.com/blog/category/all/qt-node-editor/), исходники имеются. Смотрим картинки

Ну это (http://nukengine.com/wp-content/uploads/2011/10/qtnodeeditor1.png) еще как-то вменяемо
А тут (http://nukengine.com/wp-content/uploads/2011/10/qtnodeeditor3_flower.png) вообще какие-то тараканы...

Ну конечно встает вопрос - а насколько этому можно верить? Посмотрев неск таких я заметил что все они были созданы где-то в 2011-2012 (хз может тогда была мода?). А потом что - все заглохло? Вроде автор обещал update, но я его не нашел. Как-то это беспокоит..

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

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

Попробую сформулировать. Задача: сделать редактор зависимостей, часто называемый "Node Editor". См аттач - от приведен просто просто для пояснения "как это работает", реально дизайн и содержимое будут совсем другими. Но в любом случае есть "ноды" (пр-ки) имеющие вход (слева) и выход (справа), пользователь может связывать выходы со входами и разрывать эти связи. Что происходит по факту связи/разрыва - редактор не волнует, он только уведомляет об этом приложение. То же и с др стороны - приложение может создать/удалить зависимости и сообщает об этом редактору для перерисовки. Один выход может быть соединен с любым числом входов, но один вход - только с одним выходом. Более сложные зависимости решаются введением специального нода "миксера".

За исключением специальных все остальные ноды - объекты приложения. Объект имеет уникальный ID, имя и идентификатор типа. Входы и выходы назовем параметрами. Параметр принадлежит объекту и имеет уникальный (в пределах объекта) ID, имя и идентификатор типа. Параметры каждого объекта организованы в виде дерева, родителями могут быть только параметры имеющие тип "контейнер" (или родитель - сам объект). В большинстве случаев параметр одновременно и вход и выход. Параметры-контейнеры могут связываться как и остальные, это означает автоматычную связь всех их чайлдов.

Разрешается задействовать любые open-source но не привлекать др либы кроме Qt. std и (ладно уж) boost. Задача не так проста как (возможно) кажется на первый взгляд. Многочисленные примеры в гугле не дают ответа на вопрос: а что делать если связок "много"? Пример: от 1 до 12 параметров-контейнеров одного объекта связаны со входами 10 других (или 20 или 100). Очевидно с прямолинейным рисованием мы быстро получим "темный лес". Др сложность: а что собственно показывать? Число объектов принципиально не ограничено, несколько тысяч - случай рядовой. Тупо вывалив все - получаем огромную простыню с нулевой информативностью.

Вот эти все многочисленные заботы я с удовольствием спихну на контрактора :)  А если мне все это надо самому разрывать - тогда нет смысла кого-то нанимать, большая часть работы уже будет сделана, само "рисование" не так уж сложно.

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