- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
def add_row_table(mal):
win.ui.tableMAL.setRowCount(win.ui.tableMAL.rowCount()+1)
q_db = QtGui.QPushButton('add', win.ui.tableMAL)
q_db.setProperty("row", str(mal))
win.ui.connect(q_db, QtCore.SIGNAL("clicked()"), add_Click)
win.ui.tableMAL.setCellWidget(win.ui.tableMAL.rowCount()-1, 0, q_db)
def add_Click():
print win.ui.tableMAL.sender()
В последнее время в среде лам появилась мода писать код на PyQt/PySide в процедурном стиле. Вот один из этих шедевров.
http://python.su/forum/topic/28373/
http://sourceforge.net/projects/pywin32/
Прокачанных тибетских монахов?
http://lurkmore.to/%D0%9B%D0%B0%D0%BC%D0%B5%D1%80
Почитай про ООП, научись пользоваться классами и только после этого пробуй заниматься гуем. Рано тебе ещё про таблицы спрашивать.
Никто тебя не гонит. Но и тратить время в пустую и что-то объяснять челу который даже классами не умеет пользоваться тоже никто не будет. На киберфоруме к такому относятся более лояльно, по этому я и посоветовал туда обратиться.
У ОПа ООП головного мозга. Хм, думал эта порода повымерла в конце 00х.
Научись сначала диагноз правильно ставить. Речь идёт о GUI который без ООП не пишется.
Да ну. Писал GUI без ООП, когда это ещё было мейнстримом.
Другое дело, что там ООП в какой-то форме само собой зарождаться начинает, когда задумываешься о реюзабельности виджетов. Даже если язык не умеет в классы и вся прога полностью процедурная. Завёл структуру, чтобы хранить контекст - получилась инкапсуляция. Передал указатель на функцию для обработки событий - получился полиморфизм. Вызвал из этой функции функцию от более простого виджета - получилось наследование.
А потом, когда уже примерно понял как всё будет выглядеть и работать - начать проектировать нормальную архитектуру.
Фанатизм - не есть вещь хорошая. ООП - лишь инструмент.
http://habrahabr.ru/post/153225/
А можно аргументы?
Я просто писал ГУЙ на свингах, а до этого имел печальный опыт MFC и скажу что ничего хорошего с концентрированным ООП не получается.
А вот допустим есть ангуляр, и в нём вполне замечательно гуй пишется, без всяких там ООП.
> А вот допустим есть ангуляр, и в нём вполне замечательно гуй пишется, без всяких там ООП.
Вот ссылка на питоновскую библиотеку в которой тоже GUI как-бы "без всяких там ООП" пишется. Но это не значит что его там нет, просто ты с ним не сталкиваешься.
https://pythonhosted.org/guiqwt/examples.html
Про PyQT ничего не скажу, а вот на Tkinter писал немало. И в ООП-стиле, и в процедурном. В результате сформировалось твердое убеждение - если нужен многоразовый виджет, создавай класс и штампуй экземпляры. Если совокупность виджетов гарантированно используется один-единственный раз - в задницу ООП, код от него становится лишь нечитабельней и тяжелей.
Вот тебе, к примеру, интерфейс:
http://lxr.free-electrons.com/source/include/linux/fs.h#L1613
И одна из тысяч его реализаций:
http://lxr.free-electrons.com/source/drivers/hid/hid-sensor-custom.c#L722
Дык заводить структуры было принято еще в структурно-процедурном программировании.
>Передал указатель на функцию для обработки событий - получился полиморфизм.
Это не полиморфизм. Это ФП. Когда в js колобки передают это тоже называется ООП?
Полиморфизмом труЪ оопёбы обычно заменяют оператор свищ.
Единственное что в ООП оригинального — наследование, и то considered harmful.
Полиморфизм, это если указатели на обработчик сохранять в структуре.
> def add_row_table(mal, name, russian, ep, rating, DB)
> японская буква А в подписи
Да он же анимешник!
Что за блядство - писать код в строке?
P.S. Это не код, кстати. Это имя сигнала/слота и типы его параметров.