Russian Qt Forum
Май 21, 2024, 01:29 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: 1 2 3 [4]   Вниз
  Печать  
Автор Тема: Помогите организовать мигание иконки внутри делегата  (Прочитано 33001 раз)
break
Гипер активный житель
*****
Offline Offline

Сообщений: 846


Просмотр профиля
« Ответ #45 : Февраль 09, 2010, 16:44 »

Цитировать
Модель - предоставила данные - АВАРИЯ, как и кто это будет сигнализировать для нее вопрос не интересный.
тоже согласен

Цитировать
лучше весь код иметь в одном классе
не всегда так - пример со слониками выше (не подумайте что он надуман - очень даже актуальный) - как раз доказывает обратное, иногда желание хранить все в 1 месте пораждает перегруженные классы с которыми не понятно как и неудобно работать
Записан
Kolobok
Гость
« Ответ #46 : Февраль 09, 2010, 17:25 »

Кстати о слониках. Представте себе делегата с тяжелым методом paint. Представление будет себя постоянно перерисовывать и на остальное ресурсов может не хватить.
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #47 : Февраль 09, 2010, 17:43 »

Потому что представление каждую секунду принудительно перерисовывается. Этот способ я уже описывал.
В этом варианте мигающие элементы придется хранить и во view(очень плохо). Или по сигналу таймера вызывать repaint().
Как же Вы собираетесь организовать мигание без принудительной перерисовки с интервалом мигания ? Улыбающийся
И зачем хранить "и во view(очень плохо)"? Чем так уж плохо хранить в модели? Ладно, почему-то не хотите, так есть масса разумных вариантов, напр.

- мне здесь нравится множественное наследование
Код:
class MyDataModel : public QAbstractItemModel, public Blinker {
И если надо через dynamic_cast узнаем, может ли таблица мигать.

- также сделать Blinker отдельным классом и модель имеет указатель на него (членство вместо наследования)

- ладно, если уж хочется "общности/универсальности" - делаем вызов какого-то virtual'a в методе модели data()   
и.т.д.  и.т.п.

А вообще "проблема мигания" на мой взгляд не заслуживает обсуждения, сигнал таймера можно получить где угодно. Реально-то обсуждается "как покрасить ячейку" - и здесь ходов раз-два и обчелся. Перекрыть paint (полностью) конечно можно, но это "brute force". Так что ото приспосабливайте модель - и дело с концом.
Записан
Kolobok
Гость
« Ответ #48 : Февраль 09, 2010, 17:57 »

Как же Вы собираетесь организовать мигание без принудительной перерисовки с интервалом мигания ? Улыбающийся
Без принудительной перерисовки - никак. Но модель может заставить представление перерисовывать только мигающие ячейки.

Чем так уж плохо хранить в модели?
Разве я говорил обратное.
Записан
crossly
Гость
« Ответ #49 : Февраль 09, 2010, 18:07 »

а давайте спросим у Тролей.... что они по этому поводу думают... Улыбающийся
Записан
lit-uriy
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 3880


Просмотр профиля WWW
« Ответ #50 : Февраль 09, 2010, 18:45 »

Цитировать
Представте себе делегата с тяжелым методом paint. Представление будет себя постоянно перерисовывать и на остальное ресурсов может не хватить.
А если не делегат то ресурсы откуда-то появятся на рисоваиние?
Цитировать
ИМХО лучше весь код иметь в одном классе.
это устаревший подход под названием "мухи вместе с катлетами". Его подобие реализовано в QTableWidget.
Записан

Юра.
break
Гипер активный житель
*****
Offline Offline

Сообщений: 846


Просмотр профиля
« Ответ #51 : Февраль 09, 2010, 18:57 »

Цитировать
Без принудительной перерисовки - никак. Но модель может заставить представление перерисовывать только мигающие ячейки.
Охренеть а делегат что будет перерисовывать в том числе и невидимые немигающие???
Цитировать
Кстати о слониках. Представте себе делегата с тяжелым методом paint. Представление будет себя постоянно перерисовывать и на остальное ресурсов может не хватить.
Ну да метод paint сильно потяжелел из-за отрисовки 2-х картинок по очереди... А если в модели хранить кучу флажков для каждого варианта представления - то ни у кого не хватит желания потом в этой модели разбираться.

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

Множественное наследование - это зло, а уж множественное наследование для реализации мигания - еще большее зло. В идеале множественное наследование вообще только от интерфейсных (абстрактных) классов должно быть.

Не знаю как автору - но мне не нравится идея хранить в модели признак мигания - модель это данные - когда что-то мигает это уже декорации. Не думаю что перенос дергающегося флажка в модель из делегата это разумный способ оптимизации.
Записан
lit-uriy
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 3880


Просмотр профиля WWW
« Ответ #52 : Февраль 09, 2010, 19:02 »

>>но мне не нравится идея хранить в модели признак мигания
Признак мигания только там и хранить (точнее от туда брать), но признак это всего лишь информация о том, что "нужно мигать", а не о том, "как мигать".
Флажок состояния (светится/потушен) это не признак мигания, а внутренняя реализация конечного автомата.
Записан

Юра.
Kolobok
Гость
« Ответ #53 : Февраль 09, 2010, 19:20 »

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

это устаревший подход под названием "мухи вместе с катлетами". Его подобие реализовано в QTableWidget.
Когда QTableWidget стал устаревшим?

Цитировать
Без принудительной перерисовки - никак. Но модель может заставить представление перерисовывать только мигающие ячейки.
Охренеть а делегат что будет перерисовывать в том числе и невидимые немигающие???
Непонимающий

Ну да метод paint сильно потяжелел из-за отрисовки 2-х картинок по очереди...
В модели могут быть данные, которые генерируются "на лету". Про мигающий столбик вообще речи не было. Его то по-любому перерисовывать надо.
Записан
lit-uriy
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 3880


Просмотр профиля WWW
« Ответ #54 : Февраль 09, 2010, 20:04 »

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

>>Когда QTableWidget стал устаревшим?
Не виджет устаревший, а подход. Читай доку по нему там явно об этом говорится.

Записан

Юра.
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #55 : Февраль 09, 2010, 20:45 »

Пацаны, мне кажется "слишком много теоретизируем"  Улыбающийся Более практично склепать вариант (их уже предложено не один) а потом "по жизни" смотреть где и что жмет, что плохо. Если этот класс постоянно/навязчиво требует внимания - надо перепланировать (ничего смертельного здесь нет). А если делает все что надо - так нечего время терять, др. работы полно
Записан
break
Гипер активный житель
*****
Offline Offline

Сообщений: 846


Просмотр профиля
« Ответ #56 : Февраль 09, 2010, 20:49 »

+1
Записан
Страниц: 1 2 3 [4]   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.051 секунд. Запросов: 23.