Re[10]: На чем теперь GUI писать положено?
От: trdm Россия  
Дата: 12.11.09 06:41
Оценка:
Здравствуйте, astral_marine, Вы писали:

>>>(Qt эмулирует контролы, а не использует родные)

T>>Чего? Эмулируют? Да у них свои контролы, на своей системе сообщений и паинтере.
_>Согласен

T>>Это отлично: возможностей больше. А куцые и неудобные виндовые контролы они уже в печенках сидят.

_>Но возможностей меньше, Qt развивается сейчас только в сторону мобилок, разных спецефэктов на них, а не конролов для десктоп приложений.
С чего ты так решил?

T>>Как чего посложнее чем просто дерево нарисовать надо будет типа дерева с колонками, так танцы

T>>с бубном и начинаются, знаю, уже танцевали:
_>В wxWidgets для этого есть wxDataViewCtrl, который делает то же самое, но выглядит при этом как родной
Да уж, фраза "как родной" слезу еще не вышибает?
Какая-то мерялка получается... В Qt 300 лет уже есть нечто подобное wxDataViewCtrl:
QTreeView

_>Вообще, если говорить о возможностях, то в wxWidgets на порядок больше продвинутых контролов. wxAUI, wxGrid и wxPropertyGrid аналогов в Qt до сих пор нет.

ага... это данные из какого века? гридов там хоть попой ешь, хоть с пропертями хоть без.
а о широких возможностях кастомизации и говорить не буду — незачем.
Re[11]: На чем теперь GUI писать положено?
От: astral_marine  
Дата: 12.11.09 12:46
Оценка:
_>>Но возможностей меньше, Qt развивается сейчас только в сторону мобилок, разных спецефэктов на них, а не конролов для десктоп приложений.
T>С чего ты так решил?
Практически все, что делает последнее время Nokia внутри Qt, относится к мобилкам — браузерная поддержка, Touch, движение мобилки в пространстве, 3D.
Кончно, это может быть использовано и в десктопных приложениях, но это лишь говорит о том, что мобильная платформа теперь в Qt первична, десктопная — вторична.

T>Да уж, фраза "как родной" слезу еще не вышибает?

Конструктивная критика уже закончилась?

T>>>Как чего посложнее чем просто дерево нарисовать надо будет типа дерева с колонками, так танцы

T>>>с бубном и начинаются, знаю, уже танцевали:
_>>В wxWidgets для этого есть wxDataViewCtrl, который делает то же самое, но выглядит при этом как родной
T>Какая-то мерялка получается... В Qt 300 лет уже есть нечто подобное wxDataViewCtrl:
Это был мой ответ на то, что в аналог QTreeView — wxDataViewCtrl, я не отрицал наличие QTreeView, просьба повнимательней читать форум.
Неужели 300 лет?

_>>Вообще, если говорить о возможностях, то в wxWidgets на порядок больше продвинутых контролов. wxAUI, wxGrid и wxPropertyGrid аналогов в Qt до сих пор нет.

T>ага... это данные из какого века? гридов там хоть попой ешь, хоть с пропертями хоть без.
T>а о широких возможностях кастомизации и говорить не буду — незачем.
Неужели? А можно получить пруфлинк? Какой контрол является аналогом wxAUI?
Re[15]: На чем теперь GUI писать положено?
От: astral_marine  
Дата: 12.11.09 13:05
Оценка:
_>>Да я сам собирал, wxWebKit — это кроспратформенный контрол.
ТКС>Это хорошо, надо попробовать, а то чето народ в форумах пугал что не собирается.
WebKit собирается под wxWidgets, Qt и GTK+ с использованием GNU окружения (bash, bisin, flex etc), настроить которое не очень просто. Так же очень много зависимостей от внешних библиотек. Видимо были проблемы с настройкой, а не со сборкой самого WebKit.
ТКС>Ну и нафига IE встраивать, если есть варианты получше?

Согласен, wxWebKit и wxWebConnect (Gecko) получше будут, но бывают ситуации, когда нужен именно IE. И только wxWidgets позволяет это сделать, в Qt — это невозможно.

ТКС>Значит еще раз повторить не затруднит? А то я ничего разумного на эту тему не заметил.


Вот, пожалуйста: http://www.rsdn.ru/forum/cpp.applied/3597045.aspx
Автор: astral_marine
Дата: 10.11.09


ТКС>Хочешь сказать, тут [...] каким-то боком умудрились IE заюзать?

ТКС>Ну и такой QA тоже не исключено что не просто так ляпнут:
ТКС>

ТКС>Q: My Windows application (WPF, Win Forms, Java, etc.) uses the Web Browser control. Is there any compatibility issue?
ТКС>A: Everything should work as expected. However, we’ve seen some issues when applications depend directly on a specific browser. In particular, if while using the Web Browser control, you allow the application to open new windows that do not respect the user’s default browser choice, you may see some issues.


Не знал об этом. Но какой именно движок (WebKit, Trident, Gecko, Presto) используется внутри Web Browser control не имеет значения в данном случае. API из Windows позволяет вставлять веб контрол в wxWidgets приложения, а в Qt приложения — нет.
Re[16]: На чем теперь GUI писать положено?
От: Тот кто сидит в пруду Россия  
Дата: 12.11.09 14:07
Оценка:
Здравствуйте, astral_marine, Вы писали:

_>>>Да я сам собирал, wxWebKit — это кроспратформенный контрол.

ТКС>>Это хорошо, надо попробовать, а то чето народ в форумах пугал что не собирается.
_>WebKit собирается под wxWidgets, Qt и GTK+ с использованием GNU окружения (bash, bisin, flex etc), настроить которое не очень просто. Так же очень много зависимостей от внешних библиотек. Видимо были проблемы с настройкой, а не со сборкой самого WebKit.
ТКС>>Ну и нафига IE встраивать, если есть варианты получше?

_>Согласен, wxWebKit и wxWebConnect (Gecko) получше будут, но бывают ситуации, когда нужен именно IE. И только wxWidgets позволяет это сделать, в Qt — это невозможно.


Да вроде тоже без проблем: http://doc.trolltech.com/4.2/activeqt-webbrowser.html

ТКС>>Значит еще раз повторить не затруднит? А то я ничего разумного на эту тему не заметил.


_>Вот, пожалуйста: http://www.rsdn.ru/forum/cpp.applied/3597045.aspx
Автор: astral_marine
Дата: 10.11.09


Ну то есть легаси. Когда пара-тройка древних ActiveX завалялась.

ТКС>>Хочешь сказать, тут [...] каким-то боком умудрились IE заюзать?

ТКС>>Ну и такой QA тоже не исключено что не просто так ляпнут:
ТКС>>

ТКС>>Q: My Windows application (WPF, Win Forms, Java, etc.) uses the Web Browser control. Is there any compatibility issue?
ТКС>>A: Everything should work as expected. However, we’ve seen some issues when applications depend directly on a specific browser. In particular, if while using the Web Browser control, you allow the application to open new windows that do not respect the user’s default browser choice, you may see some issues.


_>Не знал об этом. Но какой именно движок (WebKit, Trident, Gecko, Presto) используется внутри Web Browser control не имеет значения в данном случае. API из Windows позволяет вставлять веб контрол в wxWidgets приложения, а в Qt приложения — нет.


Вот все-таки странное это желание — вставлять ActiveX в ситуации, когда можно обойтись чистыми плюсами...
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[12]: На чем теперь GUI писать положено?
От: trdm Россия  
Дата: 12.11.09 15:01
Оценка: -2 :))
Здравствуйте, astral_marine, Вы писали:

T>>Да уж, фраза "как родной" слезу еще не вышибает?

_>Конструктивная критика уже закончилась?
Не вижу смысла доказывать чета человеку,
который уверен, что wxWidget пуп мироздания.
я выбрал Qt и слава богу что не wx. тчк
Re[18]: На чем теперь GUI писать положено?
От: A13x США  
Дата: 12.11.09 15:12
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>...Тут мы с тобой смотрим на проблему с разных позиций. Я борюсь с причинами — ты со следствиями.

CS>Все эти пляски с бубном вокруг cloneNode() выглядят как тривиальный хак и/или попытка обойти чей-то другой баг. Что всегда чревато.
CS>Если cloneNode() *в WebKit* дорогая операция то *WebKit* должен имплементировать кэш у себя внутри.

я, наверное, не совсем корректно выразил свою мысль.
В общем идея была в том, чтобы избежать явной пессимизации.
Иными словами подразумевается примерно такой алгоритм — если нужно получить новый нод и в кэше нет похожего,
клонируем шаблонный нод такого же класса (в смысле такого же типа, не css) и после клонирования назначаем метод обновления содержимого этого нода.
В противном случае, если в кэше есть подобный нод, просто извлекаем его оттуда.
Нет смысла просто "забывать" о ноде когда он извлекается из DOM дерева, т.к.:
1) операция сохранения в кэше очевидна и очень проста.
2) операция клонирования и поиска в поддереве явно занимают какое-то время, пусть небольшое но все же. В случае поиска элемента по классу aka getElementsByClassName налицо еще использование дополнительных ресурсов — создание и возвращение массива из элементов.
3) за нодами и результатами выборки необходимо следить сборщику мусора. В схеме с кэшем сборщик мусора просто не может никуда "потерять" экземпляры неиспользованных нодов, расход памяти — даже при очень интенсивном использовании — не будет расти.
4) В случае отказа от виртуализации налицо явное дублирование не отображаемых данных, т.к. в дереве будут присутствовать элементы сопоставленные всем элементам источника данных невзирая на то, что они не видимы и не операбельны пользователем. Уверен, что даже HTMLayout вряд ли быстро отобразит миллион элементов, хотя это явно редкий use case. В случае с виртуализацией это будет работать настолько же быстро как со списком из нескольких дестяков элементов.
5) Источник данных с lazy initialization, идеально подходит к списку с виртуализацией, в противном случае мы сводим преимущества отложенной инициализации на нет.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.