Russian Qt Forum

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

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

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

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

Не знаю, чем ты читаешь...

QDialogButtonBox::clicked ( QAbstractButton * button )
QDialogButtonBox::buttonRole ( QAbstractButton * button )
QDialogButtonBox::ApplyRole

ну и толку???

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

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

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

Это не правильно.
И accept и reject закрывают диалог, а для apply этого не требуется.
Посмотри как они описаны в исходниках:

C++ (Qt)
void QDialog::accept()
{
    done(Accepted);
}
 
void QDialog::reject()
{
    done(Rejected);
}
 

Посмотри на:
QPushButton * QDialogButtonBox::button ( StandardButton which ) const

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


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

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

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

Куда уж больше предупреждать:
;)

Попробуй соединить сигнал QPushButton::clicked() со слотом QDialog::done( int ).  ;)

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


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

на то и есть

::)
А какую роль должна передавать кнопка, например, "Установить персональные данные"?

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

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

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

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

возникает.... а что должен делать слот apply() стандартного  диалога ??

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

Нарисуй слот apply() и сделай так


Кнопка Apply в QDialogButtonBox не обязательна. Поэтому, имхо, и слота нет.

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

accept и reject используются не только в качестве слотов.
а раз уж программист всё-равно будет наследоваться и чего-то там писать, на кой нужен пустой публичный слот? правильно, совсем не нужен...

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

Причем здесь таблицы виртуальных методов....
Что это даст? Возможность посильней размазать функционал по GUI? Так это очень плохая практика.

некоторую дополнительную автоматизацию, отсутствие необходимости руками писать лишнюю пару строк, вместо рутины один клик - собственно для этого Дизайнер предназначен, если в ui_*.h посмотреть, то видно, от какой рутины он избавляет

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

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

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

но в приложении вылазит Cancel и Apply почему-то, хотя в остальных местах везде все верно, и локаль стоит разумеется Russian

А ты переводы загружаешь?

это translate() в .ui файле, который включается флажком translatable в дизайнере? да, разумеется это все есть

Имеется ввиду .qm файл с переводом?

а, не, это еще не делалось

но почему тогда в дизайнере берется "системная" надпись, а в приложении нет?

если нет файла перевода, Qt мог бы использовать надписи в соответствии с системной локалью (их же можно получить, если очень захотеть), а если есть, то из него

А дизайнер - молодец, он переводы загружает.  :)

Вот эти надписи и хранятся в этих самых файлах с переводами.

ИМХО - граздо лучше, если бы в дизайнере можно было редактировать надписи на кнопках в редакторе свойств QDialogButtonBox, там где флажки включения кнопок устанавливаются

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

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

А для чего тогда использовать QDialogButtonBox?
Ну и добавь на диалог QPushButton.

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

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

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

А стандартные диалоги ты как переводить будешь?

какие стандартные? не было...  ;D

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

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

Правильно-правильно, работа должна напоминать ад.
Иначе, за что программистам зарплату платят.  :)

я это читал, но в моем случае возможная "локализация" - это перевод на другой язык, отличный от русского  ;)


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

а в других случаях это как по твоему??

а в других случаях, это когда делают сначала на английском...  ;D

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

убей себя, пожалуйста...

да нифига... это все будет сделано потом, и если понадобится, и за перевод текстов будет отдельно платиться переводчику перед выпуском версии 1.0.0, когда все сообщения устаканятся, к тому времени их еще много появится, и количество строк кода вырастет раза в 1.5 а то и 2

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

Посмотри разделы Static Public Members в наследниках QDialog. Или ты уверен, что это тебе никогда не понадобится? И это всё из-за трех строчек в коде?

Гурман
ты вообще читаешь, что тебе пишут? ПИШИ СВОИ СТРОКИ НА РУССКОМ, НО ФАЙЛ ПЕРЕВОДА КУТЕ ЗАГРУЗИ. А не ной что в дизайнере чего-то нет.

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

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

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

В дизайнере есть Promote to...

Повторюсь, не используй тогда QDialogButtonBox, используй обычные кнопки QPushButton. В чем проблема?

человек-катастрофа....

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

это где? у меня оно все по-русски

как выяснилось, очевидно из-за того, что я собрал плагин mingw, никто до последнего момента (http://www.prog.org.ru/topic_13937_0.html) не предупреждал, что для дизайнера в винде его надо собирать в студии

тебе еще раз прочесть лекцию о различии дизайнера и плагина дизайнера к креатору?
кстати что мешает воспользоваться внешним дизайнером, он mingw собран?

А мне нравится больше вручную все прописывать, нудно, но доставляет особые ощущения %)

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

Дизайнер - зло. Я тоже все делаю руками. И особенно сложные формы/лэйауты это имеет больший смысл делать. Если потом что-то надо переделать, то так даже проще.