Найти - Пользователи
Полная версия: PyQt4: поворот и drag-and-drop картинок
Начало » GUI » PyQt4: поворот и drag-and-drop картинок
1 2 3 4 5 6 7
ZZZ
poltergeist
ZZZ я бы всё же посоветовал не хакать по-питонски (mime.Element = self) и усложнять жизнь разработчику… можно ведь обойтись “правильным” способом переноса данных (mime.setData(mtype, data)) драг&дропом, который уже будет в себе иметь понятный интерфейс (mtype). Такой подход будет универсальным, т.е. можно будет передавать данные не только в пределах одного приложения… Этот человек пишет пример, в том числе и для того чтобы других учить, а твой пример я считаю не хорошим в этом плане:(
void QMimeData::setData ( const QString & mimeType, const QByteArray & data )
Т.е. мы можем передавать только QByteArray.
The gray Cardinal
Картинку таким способом передать вроде можно, а вот как передать сам перетаскиваемый элемент, я не понял.
Есть такой принцип: KISS.
В данном случае просто не нужно передавать ничего другим приложениям. А если будет нужно, то уж точно не сам объект-елемент и тогда никто не мешает заполнить QMimeData ещё и нужными данными.

По-хорошему, нужно оформить это так:
class ElementMimeData(QMimeData):
def setElement(self, Element):
self.__Element = Element
def element(self):
return self.__Element
Тогда всё будет в Qt'шном стиле.

The gray Cardinal
Не понял. Вопрос в том, что я не пойму, что именно там за виджет сидит, в моём случае. Это не мой элемент-наследник QGraphicsPixmapItem, это не сцена, это не её QGraphicsView, и это не главное окно. Что это тогда? У меня больше никаких объектов-то нет .
А ты попробуй на нём что-нить нарисовать. :-)

The gray Cardinal
Кажется, осилил.
Мнэээ… Не очень хорошо.
Всё-таки я согласен с Полтергейстом, что злоупотреблять этим совсем не стоит. Передать то, что нельзя нормально передавать через data, ещё ладно, а вот разтого рода x, y и прочие буквы из высшей математики, ИМХО, уже перебор. И уж тем более, рассказывать новичкам про то, что setData такой непонятный – лучше разберись с ним.

Опять же, есть такой замечательный класс – QPoint, про который лучше не забывать.
...
mime.Pos = event.pos() # Если уж так делать.
...
...
item.setPos(event.scenePos() - mime.Pos)
...
The gray Cardinal
ZZZ
А ты попробуй на нём что-нить нарисовать. :-)
Не понял, в каком смысле и как “нарисовать”? Да и “нарисование” только для выяснения, что это за виджет, смешно как-то :).
Как в коде быстро определить, что это за виджет? Сколько я его не сравнивал с другими объектами, результат всегда False. Когда выводишь объект на печать (просто командой print), для объекта показывается его адрес в памяти, так? Этот адрес тоже вроде отличается от всех других объектов в моём же скрипте. Вот я и не понял, что это за объект…
ZZZ
Всё-таки я согласен с Полтергейстом, что злоупотреблять этим совсем не стоит. Передать то, что нельзя нормально передавать через data, ещё ладно, а вот разтого рода x, y…
Ага, я тебя понял, спасибо, учту на будущее. То, что для QPoint поддерживаются арифметические операции, тоже интересно. Но, вобщем, именно в данном контексте, мне всё это кажется не очень существенным. А делать своего наследника от QMimeData только для того, чтобы определить поле, которое Python вставляет полностью автоматически, как-то, мне кажется, не рационально, что ли. Имхо, только загромождать код будет. Ты же сам писал, что “люди, изучающие PyQt, забывают, что пишут на питоне” ;).
ZZZ
И уж тем более, рассказывать новичкам про то, что setData такой непонятный – лучше разберись с ним.
Здесь ты меня понял с точностью до наоборот :). Я не рассказываю, что setData “непонятный”. Кавычки я там употребил только потому, что “понятность” - свойство слишком уж субъективное. Я ведь указал, что в случае “передавать данные не только в пределах одного приложения” setData может оказаться как раз желательнее.
poltergeist
ZZZ
В QByteArray можно запихнуть что душе угодно, даже запиклить класс и передать таким образом - не вопрос. Просто это будет уже каким-то протоколом взаимодействия компонентов приложения/приложений. Тут я бы просто передавал в QMimeData строку с линком на ресурс (изображение в QPixmapCache, в ресурсах приложения ну или на диске) - это считаю самый кошерный вариант. Monkey patching тут излишество. А пример будет учить именно этому… :( поэтому я не понимаю нужность “этого” кукбука, если его наполнением занимаются лишь бы для наполнения, а не от огромного опыта и интересных наработок в этой области, которыми хотелось поделиться и обсудить…

З.Ы.
ZZZ
По-хорошему, нужно оформить это так:
Про инициализацию класса забыли:) сори, просто придираюсь уже по ходу…
The gray Cardinal
poltergeist
А пример будет учить именно этому… поэтому я не понимаю нужность “этого” кукбука, если его наполнением занимаются лишь бы для наполнения, а не от огромного опыта и интересных наработок в этой области, которыми хотелось поделиться и обсудить…
Да не будет учить пример “именно этому”! Пример лишь показывает, как можно сделать drag-and-drop в контексте Graphics View, ни больше, ни меньше. И вообще, интерпретация опубликованного - это личное дело каждого читателя. Так можно дойти до того, что лишнюю запятую бояться в комментариях поставить, а то вдруг кто-то чему-то плохому научится. Вместе с PyQt4 идёт единственный несчастный пример с роботом, который совершенно не полон (там элементы перетаскиваются только друг на друга, причём сами при этом не перемещаются), именно поэтому я так и мучился в этой теме. А теперь, с моим примером, уже мучиться не надо. Вот тебе и обоснование нужности этого кукбука, если уж это обоснование тебе так необходимо :).
А “лишь бы для наполнения” - это ты со зла :(. Это неправда.
poltergeist
Monkey patching тут излишество.
Не факт. Зачем писать длиннее, если можно написать короче?

Кстати. Никто не запрещает подлючиться к процессу, и вставить свой комментарий и свой вариант решения в тот же кукбук.
poltergeist
The gray Cardinal
Кстати. Никто не запрещает подлючиться к процессу, и вставить свой комментарий и свой вариант решения в тот же кукбук.
Не, спасибо, я уж лучше как минимум буду тут на форуме отвечать, а если будет тяга к написанию чего-то возвышенного, то напишу пост в своём блоге…
The gray Cardinal
poltergeist
В общем, пойми меня правильно: кукбук - это собрание коротких примеров, основное требование к которым состоит в том, что они работают так, как заявлено, и показывают, как можно решить ту или иную проблему. Вылизывать код и делать “правильнее”, “красивее” и т.д. можно почти до бесконечности. Кроме того, мнения о “правильности” и “красоте” решений могут сильно разойтись у всех читателей и писателей. Делать из короткого примера на 50 строк супер-пупер туториал с охватом всех проблем и обучением тонким правилам хорошего тона в программировании, имхо, совсем не обязательно, да и просто нереально, скорее всего. Для меня лично это стопудей нереально, по многим причинам. Поэтому я бы и был не против, если к этому делу подключился бы кто-то ещё.
The gray Cardinal
gmorgunov
А вот вариант решения на PyGTK.
Спасибо, добавил.
The gray Cardinal
Подумал и поправил немного, в соответствии с замечаниями ZZZ о QPoint :).
Кстати, мой изначальный метод со специальным полем в классе сцены для временного хранения перетаскиваемого элемента, получается, был не так уж и плох ;).
ZZZ
poltergeist
В QByteArray можно запихнуть что душе угодно, даже запиклить класс и передать таким образом - не вопрос.
Ты представляешь объем кода, для решения этого вопроса? :-)))
Надеюсь, что ты не собираешься пиклить классы Qt… Мне кажется, что это ещё более страшный хак.

poltergeist
Тут я бы просто передавал в QMimeData строку с линком на ресурс
Я бы, кстати, тоже. Просто не знал, как это коротко написать. Но здесь есть одна проблема – придётся переделать много кода, как мне кажется.

poltergeist
Про инициализацию класса забыли сори, просто придираюсь уже по ходу…
Не забыли. Мне нечего дополнить к QMimeData.__init__. Но когда писал сначала руки сами набили `def __init__`… :-)

The gray Cardinal
А делать своего наследника от QMimeData только для того, чтобы определить поле, которое Python вставляет полностью автоматически, как-то, мне кажется, не рационально, что ли.
В этом-то и минус Qt. А если точнее PyQt. Для того, чтобы код был понятен и не был сильно разнородным, нужно оформлять классы по-qt'шному, что не очень-то согласуется с питоньим стилем и совершенно не влазиет в PEP-8. Некоторое время назад, я показал (на pydev.ru), как это можно совместить стили, но в тоже время сейчас я понимаю, что это не очень хорошо. Эволюция однако.
ZZZ
>>> mime.z == mime.Element.zValue()
True
>>> import this
The Zen of Python, by Tim Peters
# вырезано девятнадцать строк
Namespaces are one honking great idea -- let's do more of those!
Это я к тому, что mime.z здесь явно лишний.

Если честно, у тебя здесь явно страдает архитекрурное решение.
Лучше было бы создать глобальный объект-контейнер с картами, передавать в QMimeData.data просто имя-идентификатор элемента, а перерисовывать при переносе с помощью Element.setPoint к уже имеющемуся объекту, не создавая новый.

P.S. Кстати, я когда-то писал логику карт… Но это был Qt3… И занимался я больше логикой, а не отрисовкой.
P.P.S. Серый Кардинал, у тебя есть вся колода? Можешь где-нить выложить?
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB