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

так и сделаю, но кнопка же готовая вроде есть уже... хотя наверно если в дезайнере ее включить, то в .ui файл такой же вызов button() и прописывается...

а что в наследующем его классе программист напишет, то и должен... от стандартных accept и reject в QDialog толку ровно 0 - они просто окно диалога закрывают, их все равно переопределять надо, аналогично и apply(), и остальные

так это же нестандартная кнопка

я про стандартные

но разумеется, если есть некий набор "стандартных" кнопок, то я бы ожидал, что у приемников для них есть набор стандартных реакций, то есть, у QDialog должен быть слот apply() и несколько других, соответствующих набору стандартных кнопок у QDialogButtonBox, а у этого класса соответствующий набор сигналов, которые подключаются автоматом при использовании "стандартных" кнопок

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

если бы сигнал имел вид QPushButton::clicked(ButtonRole role), а слот QDialog::done(ButtonRole role) все бы замечательно соединялось!


имелось в виду - предупредить, что для этого просто вызывается done()

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


кхе... это несколько неожиданно... могли бы и предупредить  

я подумал сначала, кнопка ОК через промежуточный слот сначала сигнал посылает в accept() потом в done() - в первый, чтобы принять изменения, во второй чтобы закрыть диалог, не совсем понятно, нафига тогда эти accept() и reject(), можно было бы спокойно обойтись одним единственным done(int), не было бы повода для заблуждений

и как-то странно - кнопки Apply и десяток других "стандартных" есть, а у QDialog слотов готовых для них... нет

ну и толку???

это же надо самому разобрать, что нажата именно кнопка Apply и вызывать слот accept()

тогда как правильно было бы сразу соединить сигнал этой кнопки с accept() и ничего разбирать не надо

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

нарисовал бокс с 3-мя Ok, Cancel, Apply (для последней взвел флажок в редакторе бокса в QDesigner), бокс поместил на Qdialog

2 первые кнопки сами соединились со слотами диалога, переопределил их, все хорошо, при нажатии Ok вызывается сначала accept() потом done(), при Cancel сначала reject() потом done()

но кнопка Apply, хоть и стандартная, но никуда не присоединилась, и че-то сразу как-то не видно, как сделать, чтобы при ее нажатии вызывался только accept() как должно быть по ее логике

в дизайнере при редактировании связей от нее нет сигнала, и в описании бокса не видно, как добраться до кнопки по ее номеру или названию

вот же елки-моталки, если бы у Tree Widget был сигнал с единственным параметром типа int, в котором передается номер в дереве сверху, то можно было бы связать его прямо в дизайнере со слотом у Stacked Widget, который выбирает соответствующий субвиджет в стеке! и диалог настроек можно было бы полностью нарисовать в дизайнере... а так придется промежуточные слоты руками писать 

хе, так это же должен быть Stacked Widget! 

делается диалог настроек, слева Tree Widget, в нем заранее известные группы настроек, рисуются в Дизайнере

справа от дерева "страница" настроек, соответствующая листу в дереве, как это обычно принято

вот эту страницу можно заполнить чисто программно, с этим все понятно

а можно ли нарисовать все заранее известные страницы в Дизайнере, и желательно в нем же связать их с ветками дерева? ну или если связать нельзя, то не очень страшно, можно и строку кода дописать для показа нужной страницы

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

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

есть ли способ в дизайнере указать, что ветки дерева должны быть по-умолчанию раскрыты? в Edit Tree Widget сколько ни смотрел, не увидел такого, ни в редакторе всего виджета, ни в редакторе Properties у отдельных Items

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

не знаю, не видел

IM в качестве примера тут только потому, что у Миранды сами диалоги выглядят именно так, как нам нужно

в растущее приложение нужен диалог настроек, с максимумом возможностей, идеально если есть готовый, такой, как у Miranda-IM - слева дерево настроек, справа страницы, причем с поддержкой закладок там, где надо, с разными виджетами, с поддержкой help-а

а хорошо бы, если оно еще и умеет сразу работать с QSettings, чтобы при изменении настроек приложения, они сразу же сохранялись

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

диалог в wwWidgets видел, слабенький, пока возможно воспользуемся, но на будущее нужно бы помощнее

стандартным QPainter, айтемы содержат только текст, никакой графики на сцене нет

уточнил - сейчас пару секунд рисуется сцена с >7000 айтемами, посложнее с >33000 айтемов около 17 секунд (в меньшей сцене все равно есть еще чего делать, поэтому скорость неравномерная)

можно и приделать выдачу сообщения для таких сцен, хотя на самом деле, будет в разы быстрее рисоваться, сейчас неоптимально вычисляются bounding rectangle для случаев вложенных айтемов (которых подавляющее большинство), проверял, если кешировать размеры, то отрисовывается в несколько раз быстрее (где-то в 3-5), но надо сесть и аккуратно прописать необходимость перевычисления при изменении вложенных айтемов

железо - квадропень с ddr3