TGTGInsighttelegram intelligenceLIVE / telegram public index
← Python Заметки

TGINSIGHT SIMILAR POSTS

Најди сличен содржај

Изворен канал @pythonotes · Post #381 · 23 окт.

Установить свойства виджета в PySide можно не только через соответствующие методы и конструктор класса. Можно их изменять с помощью метода setProperty по имени. btn = QPushButton("Click Me") btn.setProperty("flat", True) Это аналогично вызову btn.setFlat(True) Если указать несуществующее свойство, то оно просто создается btn.setProperty("btnType", "super") Получить его значение можно методом .property(name) btn_type = btn.property("btnType") Когда это может быть полезно? ▫️Можно просто хранить какие то данные в виджете и потом их доставать обратно widget = QWidget() widget.setProperty('my_data', 123) print(widget.property('my_data')) ▫️ Назначая эти свойства разным виджетам можно потом отличить виджеты во время итераци по ним. Например, найти все кнопки со свойством my_data="superbtn". Но ведь вместо кастомного свойства можно использовать objectName, будет тот же результат. Да, но y ObjectName есть ограничение - только строки. ▫️ Если нам потребуется не просто поиск а, например, сортировка по числу, то свойства позволяют нам это сделать. Поддерживается любой тип данных widget.setProperty('my_data', {'Key': 'value'}) widget.setProperty('order', 1) all_widgets.sort(key=w: w.property('order')) Но ведь Python позволяет всё вышеперечисленное сделать простым созданием атрибута у объекта widget.order = 1 widget.my_data = 123 Да, но я думаю что не надо объяснять почему не стоит так делать. К тому же, если у виджета нет свойства то метод .property(name) вернет None, а отсутствующий атрибут выбросит исключение. ▫️ Действительно полезное применение кастомным свойствам - контроль стилей. Здесь атрибутами не обойтись, нужны именно свойства. Дело в том, что в селекторах стилей можно указывать конкретные свойства виджетов на которые следует назначать стиль. Просто запустите этот код from PySide2.QtWidgets import * if __name__ == "__main__": app = QApplication([]) widget = QWidget(minimumWidth=300) layout = QVBoxLayout(widget) btn1 = QPushButton("Action 1") btn2 = QPushButton("Action 2") btn3 = QPushButton("Action 3", flat=True) layout.addWidget(btn1) layout.addWidget(btn2) layout.addWidget(btn3) # добавим кастомное свойство одной кнопке btn1.setProperty("btnType", "super") # добавляем стили widget.setStyleSheet( """ QPushButton[btnType="super"] { background-color: yellow; color: red; } QPushButton[flat="true"] { color: yellow; } """ ) widget.show() app.exec_() С помощью селектора мы избирательно назначили стили на конкретные кнопки. Как получить список всех кастомный свойств? Функция получения списка кастомных свойств отличается от получения дефолтных. def print_widget_dyn_properties(widget): for prop_name in widget.dynamicPropertyNames(): property_name = prop_name.data().decode() property_value = widget.property(property_name) print(f"{property_name}: {property_value}") #tricks#qt

Hashtags

Резултати

Пронајдени 4 слични објави

Пребарај: #hilt

当前筛选 #hilt清除筛选
Android Broadcast

@android_broadcast · Post #9806 · 18.01.2026 г., 12:22

🤯Dagger Hilt блокирует переход на AGP 9.0 UPD. 21 января вышел Dagger 2.59 с поддержкой AGP Android Gradle Plugin 9.0 официально зафиксировал новый стабильный конфигурационный API (вышла стабильная версия с релизом AS Otter FD 3) — это одно из самых значимых изменений в инфраструктуре Android и Kotlin Multiplatform за последние годы. Цели понятны и правильные лучше работа с кэшем и общая скорость сборок. Подробнее про все изменения я писал в отдельном посте Google несколько релизов подряд аккуратно готовил экосистему к этому переходу, заранее добавив новый API и дав время авторам плагинов адаптироваться. Но на практике всё упирается в плагины. Я столкнулся с тем, что Gradle-плагин Dagger Hilt до сих пор использует старую модель конфигурации и несовместим с новым DSL из AGP 9.0. В результате проект нельзя перевести на новую версию без отключения Hilt или включения режим совместимости. Иронично, что именно официальный инструмент от Google сейчас становится блокером для обновления. Да, в AGP оставили compatibility-флаги, позволяющие продолжать сборку по старым правилам. Это спасает проекты от немедленного падения, но полностью отключает все ключевые преимущества AGP 9.0 — configuration cache, ускоренную конфигурацию и новую модель плагинов. 💬 Вы уже пробовали миграцию на AGP 9.0? Что блокирует? Делитесь в комментариях мнением. UPD. По заявлениям подписчиков также есть проблемы в работе KAPT и KSP #Android#AndroidDev#Gradle#Dagger#Hilt

Android Broadcast

@android_broadcast · Post #9550 · 08.10.2025 г., 11:50

🤖 Если вы искали альтернативу Dagger/Hilt, но с поддержкой Kotlin Multiplatform, то как раз вышла свежая версия Koin Annotations, которая значительно упрощает миграцию! #dagger#hilt#koin

Android Broadcast

@android_broadcast · Post #8901 · 05.04.2025 г., 10:43

🤖Альтернативный способ обработке one-off событий из ViewModel (EN, 10м) В статье рассказывается в чем сложность с обработкой одноразовых событий, которые надо передать из ViewModel в UI. Автор рассматривает способ через callback интерфейс в конструкторе ViewModel @HiltViewModel class MyViewModel @Inject constructor( // inject the interface private val toastMessages: ToastMessages, ) : ViewModel() { fun doSomething() { viewModelScope.launch { try { // execute async operation here } catch (e: CustomException) { // initiate a one-off event toastMessages.showToast(e.localizedMessage) } } } } 🔗 Альтернативная ссылка на статью #android#viewmodel#dagger#hilt

Android Broadcast

@android_broadcast · Post #9569 · 17.10.2025 г., 07:58

‼️Не тяните зависимости из графа сразу! Одна из частых ошибок при использовании DI — получать все зависимости из графа сразу (например, в конструкторе класса). Так делать не стоит 😬 Получение зависимости из графа — это каскадный процесс, и он должен выполняться только в момент использования. Поэтому я всегда рекомендую инжектить зависимости для Dagger/Hilt через Lazy (не путайте с kotlin.Lazy) или Provider. class ViewModel @Inject constructor( // Зависимость получается из графа сразу при создании private val useCase: DataUseCase, // Получаем зависимость из графа каждый раз при обращении Provider.get() private val useCaseFactory: Provider<DataUseCase>, // Получаем зависимость из графа при первом обращении // и затем она кэшируется в Lazy объекте private val useCaseLazy: Lazy<DataUseCase>, ) 💡 Чтобы перейти на Lazy без боли в существующем коде — можно использовать делегаты свойств в Kotlin: // Вариант использования без Lazy class ViewModel @Inject constructor( private val useCase: DataUseCase ) // Миграция на Lazy без потери API совместимости class ViewModel @Inject constructor( useCaseFactory: Lazy<DataUseCase>, ) { private val useCase: DataUseCase by useCaseFactory } И небольшой хелпер, чтобы это работало красиво 👇 // Функция расширения для использования property делегата operator fun <T> Lazy<T>.getValue(thisRef: T, property: KProperty<*>): T = get() Таким образом, вы снижаете нагрузку на DI граф, откладываете инициализацию и избегаете ненужных каскадов при старте компонентов. #di#dagger#hilt#лучшиепрактики