Здравствуйте, Sheridan, Вы писали:
C>>Больше ли? Кто-нибудь сравнивал сколько в памяти занимают все библиотеки QT и HTMLayout?
S>Ну давай попробуем. Вот 3 стандартных кутэ4 приложения: assistant, designer и linguist
Вообще все framework построенные как обертки над HWND (MFC, wxWidgets, QT) заведомо
тяжелее для rendering чем windowless конструкции типа htmlayout, fltk, Harmonia и пр.
QT вообще самая прожорливая, там бувально на каждый чих, например label создается отдельное
окно. VB6 UI и тот более толково построен — label и картинки всякие это lightweight windowless конструкции.
В QT они например умудрились toolbar buttons сделать как отдельные окна. Детский сад, младшая группа короче.
Здравствуйте, c-smile, Вы писали:
CS>Вот просто цифры: количество оффициально купленных или установленных бесплатно продуктов использующих htmlayout на сегдняшний день: 3,200,000. CS>В день покупают или устанавливают таких продуктов 43,000.
По сути вопроса, могу сказать, следующее — ИМХО ты путаешь использование HTMLayout с Web-Like UI. У меня, например, в одной из программ HTMLayout используется только в диалоге прогресса операции (там куча информации выводится, оказалось проще сверстать HTML, очень компактно вышло) и в About Box. Это же не значит, что у меня там Web-Like UI, не так ли?
Здравствуйте, c-smile, Вы писали:
CS>Вот просто цифры: количество оффициально купленных или установленных бесплатно продуктов использующих htmlayout на сегдняшний день: 3,200,000. CS>В день покупают или устанавливают таких продуктов 43,000.
Для бесплатных это видимо количество закачек, так? Нужно заметить, что не каждая закачка устанавливается, и тем более, не каждая установленная — используется (это и для платных верно).
Вот просто цифры: количество оффициально купленных или установленных бесплатно продуктов использующих htmlayout на сегдняшний день: 3,200,000.
В день покупают или устанавливают таких продуктов 43,000.
Это конечно больше говорит о нужности базовых функций самих продуктов (а не только их UI), но тем не менее.
CS>>Это конечно больше говорит о нужности базовых функций самих продуктов (а не только их UI), но тем не менее.
S>Это говорит о лени программистов. Ясен пень проще на хтмл нарисовать интерфейс. А то, что оно потребляет больше ресурсов — всем плевать.
1. Програмисты ленивы по определению. Если бы это было не так, то до сих пор все писали на ассемблере и даже Qt никогда в жизни не появилось бы (потому что Qt упрощает жизнь, а не усложняет).
2. У c-smile'а есть, например, очень быстрый парсер/токенайзер HTML/XML, способный разбирать до 40MB XML в секунду. Подумай над этой цифрой и подумай, сколько ГУИ для HTMLayout'a можно засунуть в 40 МБ. Поэтому "тормоза из-за парсинга HTML" — это плод больного воображения.
3. HTMLayout — это windowless движок. Ни один элемент не обладает HWND, то есть не является окном. Это позволяет намного эффективнее использовать память для хотя бы той же отрисовки этих элементов. Не говоря о, собственно, памяти, необходимой для каждого из этих HWND
Здравствуйте, Sheridan, Вы писали: S>>>Любой элемент интерфейса — окно вообщето. S>>Это, мягко говоря, преувеличение. Не стоит бравировать своим невежеством. Идея "один элемент управления — один hwnd" опорочила себя уж лет десять как. S>о0 S>И как сейчас?
Когда как. Вот, к примеру, уже в далеком 1997 году в VCL для экономии ресурсов часть элементов управления не создавала отдельных окон, а рендерилась прямо на DC контейнера. Пакость с отдельными окнами, в частности, в том, что нельзя послать один WM_PAINT — каждое окно должно самостоятельно обработать это событие. Так что если хочется потрендеть на тему оптимальности GUI — то велком в реальный мир.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 8bit, Вы писали:
8>Здравствуйте, Mamut, Вы писали:
КЛ>>>>лучше приведи кол-во продуктов, а не копий CS>>>мне известны 42 продукта. M>>Имхо, надо тут указать _что_ это за продукты
8>Имхо, большую часть кол-ва делают продукты symantec
Сейчас и Motorolla много добавляет. И еще будет.
У них рынок большой и который мы не видим — промышленные wince based девайсы. Например всякого рода складские штуки.
Также (но не Моторола) вот выходит офисная телефонная станция в которой терминалы-телефоны имеют sciter on board.
Каждый такой телефон имеет 640*480 screen и wince. Центральный сервер станции имеет http сервер. Прикольно.
M>>2. У c-smile'а есть, например, очень быстрый парсер/токенайзер HTML/XML
F>Ой, если несложно — можно выложить куда? А то я на codeproject уж года два как логин посеял...
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, c-smile, Вы писали:
CS>>Это конечно больше говорит о нужности базовых функций самих продуктов (а не только их UI), но тем не менее.
S>Это говорит о лени программистов. Ясен пень проще на хтмл нарисовать интерфейс. А то, что оно потребляет больше ресурсов — всем плевать.
Ты глубоко ошибаешься. И про лень, про то что где проще и про ресурсы.
Я могу сказать что затраты на UI не уменьшились. Я с ними два года уже как варюсь — знаю.
Значительно увеличились возможности и качество при новом подходе — это да.
Им потрбовался HTML по другим причинам. Это возможность "склеивать" единый UI из разных источников. Каждый источник
это отдельная команда сидящая буквально на другой стороне шарика. Им потребовалось единая система
управления стилями из-за например требований Accessibility. В HighContrast mode NIS например выглядит как обычное win приложение.
Это сделано сугубо сменой CSS.
2. "оно потребляет больше ресурсов"
C точностью до наоборот. UI cтал *значительно* меньше ресурсов потреблять и работает быстрее.
html DOM элемент меньше чем структура окна (HWND) и отрисовывается *значительно* меньшей кровью.
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, c-smile, Вы писали:
CS>>Вот просто цифры: количество оффициально купленных или установленных бесплатно продуктов использующих htmlayout на сегдняшний день: 3,200,000. CS>>В день покупают или устанавливают таких продуктов 43,000.
CS>>Это конечно больше говорит о нужности базовых функций самих продуктов (а не только их UI), но тем не менее.
CS>>Вот
CS>>Цифры достоверные — не с потолка.
КЛ>лучше приведи кол-во продуктов, а не копий
Тут надо ширше брать. Людям нужен UI, который что в вебе, что на десктопе одинаковый. Этот набор ограничивается набором HTML 4.0 + Tree + Menu. И требуется одинаковость поведения всего этого.
Здравствуйте, wildwind, Вы писали:
W>Для бесплатных это видимо количество закачек, так? Нужно заметить, что не каждая закачка устанавливается, и тем более, не каждая установленная — используется (это и для платных верно).
Достоверно знаю что как минимум *продаж* это 36тыс экземпляров в день. Данные от сами знаете кого.
W>Тем не менее к поздравлениям присоединяюсь.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Во-первых, я сказал "в принципе, может быть метафорой...".
Ну если в принципе то все может быть метафорой всего чего угодно.
В том числе и педаль undo может быть метфорой go back.
Тем не менее go back и undo стараются не мешать.
ЗХ>Во-вторых, я не говорил о конкретных способах и проблемах реализации. Речь шла о том, что "осмысленна ли в принципе метафора back/forward в десктопном интерфейсе". ЗХ>В-третьих, ты говоришь о проблеме конкретного IE — а она не является концептуальной (моя Опера прекрасно возвращает меня по кнопке Back — возвращая в том числе все набранные тексты, состояние элементов страницы и т.п.)
Я больше здесь говорил про "метфору" UpdatePanel и то что называют Ajax стилем.
UpdatePanel позволяет обновлять страницу (или фрагмент) без попадания этого измениня в back/fore stack.
Какой нибудь Ajax drag-n-drop тоже не backable и не undoable.
Internet Application Client (не Intetnet Reader типа Opera) должен иметь journaling механизм — автор страницы должен иметь возможность 1) помешать туда "принципиальные действа" 2) давать пользователю четкую индикацию того что произойдет по back или undo.
Здравствуйте, Sheridan, Вы писали: S>Вот-вот. Программисты уже теряются. S>Любой элемент интерфейса — окно вообщето.
Это, мягко говоря, преувеличение. Не стоит бравировать своим невежеством. Идея "один элемент управления — один hwnd" опорочила себя уж лет десять как.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, c-smile, Вы писали:
CS>>В QT они например умудрились toolbar buttons сделать как отдельные окна. Детский сад, младшая группа короче.
S>Вот-вот. Программисты уже теряются.
Доктор, я вашу мысль теряю.
S>Любой элемент интерфейса — окно вообщето.
S>>И как сейчас? S>Когда как. Вот, к примеру, уже в далеком 1997 году в VCL для экономии ресурсов часть элементов управления не создавала отдельных окон, а рендерилась прямо на DC контейнера.
Как говорится, +1
Например, TLabel, насколько я знаю, никогда не было окном. Как и, если не ошибаюсь, TImage и кнопки в тулбарах (помнится, Spy++ их не цеплял). Они напрямую рисовались.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
A>Ну для начала, конечно, поздравляю!
A>По сути вопроса, могу сказать, следующее — ИМХО ты путаешь использование HTMLayout с Web-Like UI. У меня, например, в одной из программ HTMLayout используется только в диалоге прогресса операции (там куча информации выводится, оказалось проще сверстать HTML, очень компактно вышло) и в About Box. Это же не значит, что у меня там Web-Like UI, не так ли?
Нет не путаю.
Эти цифры пришли от компаний которые используют htmlayout именно для всего UI приложения.
Т.е. сюда не входят приложения типа твоего. Я кстати про него ничего не знаю — соответственно в цифири оно не входит.
Эти цифры учитывают только оффициальные данные от компаний которые мне их предоставили.
Я кстати предлагал всем кто пользует разместить ссылки у себя на customers page. худо-бедно но какая-то доп. реклама.
Здравствуйте, Mamut, Вы писали:
M>Тут надо ширше брать. Людям нужен UI, который что в вебе, что на десктопе одинаковый. Этот набор ограничивается набором HTML 4.0 + Tree + Menu. И требуется одинаковость поведения всего этого.
M>>Тут надо ширше брать. Людям нужен UI, который что в вебе, что на десктопе одинаковый. Этот набор ограничивается набором HTML 4.0 + Tree + Menu. И требуется одинаковость поведения всего этого.
CS>Твоя мысль ускользает от меня. Поясни, а?
Я о том, что сейчас десктоп и web предлагаеют абсолютно разные интерфесы — как визуально, так и по поведению. Но веба становится все больше и больше. Хочется, чтобы программы в вебе вели себя также, как программы на десктопе и наоборот.
То есть народу нужен не только и не столько Web alike UI, сколько унифицированный UI. HTMLayout им это предлагает.
Здравствуйте, Mamut, Вы писали:
M>Я о том, что сейчас десктоп и web предлагаеют абсолютно разные интерфесы — как визуально, так и по поведению. Но веба становится все больше и больше. Хочется, чтобы программы в вебе вели себя также, как программы на десктопе и наоборот.
Про наоборот это ты ИМХО погорячился. какие-то вещи проще сделать в HTML, но чтобы прям кнопки Back и Forward были... сомневаюсь я.
M>>Я о том, что сейчас десктоп и web предлагаеют абсолютно разные интерфесы — как визуально, так и по поведению. Но веба становится все больше и больше. Хочется, чтобы программы в вебе вели себя также, как программы на десктопе и наоборот.
A>Про наоборот это ты ИМХО погорячился. какие-то вещи проще сделать в HTML, но чтобы прям кнопки Back и Forward были... сомневаюсь я.
Не, про back/forward я не говорю, хотя иногда хочется
Здравствуйте, adontz, Вы писали:
M>>Не, про back/forward я не говорю, хотя иногда хочется
A>Back/Forward очень даже хорошо, когда ты что-то нелинейное просматриваешь, типа MSDN. А так, не очень понятно иногда что они в принципе могу означать.
Очень даже. back == "Вернуться к тому, что я видел только что". Если изображение на экране изменилось без изменения пользовательских данных (т.е. изменилось представление данных) — то действие Back очевидно. Если при этом и пользовательские данные были изменены — back, в принципе, может быть метафорой универсального Undo.
Здравствуйте, Mamut, Вы писали:
M>>>Тут надо ширше брать. Людям нужен UI, который что в вебе, что на десктопе одинаковый. Этот набор ограничивается набором HTML 4.0 + Tree + Menu. И требуется одинаковость поведения всего этого.
CS>>Твоя мысль ускользает от меня. Поясни, а?
M>Я о том, что сейчас десктоп и web предлагаеют абсолютно разные интерфесы — как визуально, так и по поведению. Но веба становится все больше и больше. Хочется, чтобы программы в вебе вели себя также, как программы на десктопе и наоборот.
Вот это как-то спорно. Connected и disconnected это разные метафоры.
Ну и потом разница между Inductive и Deductive UI обсуждалась ужо не раз.
M>То есть народу нужен не только и не столько Web alike UI, сколько унифицированный UI. HTMLayout им это предлагает.
A>>Back/Forward очень даже хорошо, когда ты что-то нелинейное просматриваешь, типа MSDN. А так, не очень понятно иногда что они в принципе могу означать.
ЗХ>Очень даже. back == "Вернуться к тому, что я видел только что". Если изображение на экране изменилось без изменения пользовательских данных (т.е. изменилось представление данных) — то действие Back очевидно. Если при этом и пользовательские данные были изменены — back, в принципе, может быть метафорой универсального Undo.
Такой универсальный Undo работает в единственном случаю — у юзера есть конкретное представление/ знание о том что произойдет в данном случае.
И потом Back/Forward это небезопасная операция. Скажем в IE она разрушает текущее состояние JavaScript VM и объектов DOM. Т.е. если пользователь ожидает что пара Back, Forward вернет его состоянию где он был то это не так. Т.е. делать что-то c client state (типичный случай в Web Application) в этом броузере, да собственно как в любом другом "Internet Reader" я не рекомендую.
Для "универсальный Undo/Redo" нужен более совершеный механизм по сравнению с тем что предлагает стандартный "Internet Reader".
А так первый же залетевший дятел в виде ASP.NET и его UpdatePanel разрушает совершенную картину мира.
Здравствуйте, c-smile, Вы писали:
A>>>Back/Forward очень даже хорошо, когда ты что-то нелинейное просматриваешь, типа MSDN. А так, не очень понятно иногда что они в принципе могу означать.
ЗХ>>Очень даже. back == "Вернуться к тому, что я видел только что". Если изображение на экране изменилось без изменения пользовательских данных (т.е. изменилось представление данных) — то действие Back очевидно. Если при этом и пользовательские данные были изменены — back, в принципе, может быть метафорой универсального Undo.
CS>Такой универсальный Undo работает в единственном случаю — у юзера есть конкретное представление/ знание о том что произойдет в данном случае.
CS>И потом Back/Forward это небезопасная операция. Скажем в IE она разрушает текущее состояние JavaScript VM и объектов DOM. Т.е. если пользователь ожидает что пара Back, Forward вернет его состоянию где он был то это не так. Т.е. делать что-то c client state (типичный случай в Web Application) в этом броузере, да собственно как в любом другом "Internet Reader" я не рекомендую.
Во-первых, я сказал "в принципе, может быть метафорой...".
Во-вторых, я не говорил о конкретных способах и проблемах реализации. Речь шла о том, что "осмысленна ли в принципе метафора back/forward в десктопном интерфейсе".
В-третьих, ты говоришь о проблеме конкретного IE — а она не является концептуальной (моя Опера прекрасно возвращает меня по кнопке Back — возвращая в том числе все набранные тексты, состояние элементов страницы и т.п.)
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, Mamut, Вы писали:
M>>Тут надо ширше брать. Людям нужен UI, который что в вебе, что на десктопе одинаковый. Этот набор ограничивается набором HTML 4.0 + Tree + Menu. И требуется одинаковость поведения всего этого.
CS>Твоя мысль ускользает от меня. Поясни, а?
Смотри MS CRM 3.0. Он для для веба, что в outlook desktop edition одинаковый.
Забегая вперед — однаковость достигается использованием только asp.net и на desktop ставится iss+msde.
Более того — там используются те же самые формы.
Павел
Re[3]: Нужен ли web alike UI людям.
От:
Аноним
Дата:
14.11.06 11:57
Оценка:
Здравствуйте, c-smile, Вы писали:
CS>Достоверно знаю что как минимум *продаж* это 36тыс экземпляров в день. Данные от сами знаете кого.
Это N*36000$ ежедневного дохода? Тоже поздравляю!
Re[4]: Нужен ли web alike UI людям.
От:
Аноним
Дата:
14.11.06 12:03
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Это N*36000$ ежедневного дохода? Тоже поздравляю!
Или продаж всяких разных продуктов, авторы которых бесплатно юзают вашу библиотеку?
Здравствуйте, c-smile, Вы писали:
CS>Достоверно знаю что как минимум *продаж* это 36тыс экземпляров в день. Данные от сами знаете кого.
Сами-знаете-кто раньше на MFC GUI делал вроде, и продажи наверно тоже шли неплохо.
А вообще UI, основанный на разметке, а не всяких там обработчиках событий навешанных на конторолы imho на порядок гибче и удобнее для программиста.
W>>Тем не менее к поздравлениям присоединяюсь.
Да я тоже присоединяюсь . Ох уж и много сейчас развелось всяких xml markup-based либ и фреймворков, при этом htmlayout- одна из лучших imho, и вроде одна из первых открытых.
Здравствуйте, c-smile, Вы писали:
CS>Вот просто цифры: количество оффициально купленных или установленных бесплатно продуктов использующих htmlayout на сегдняшний день: 3,200,000. CS>В день покупают или устанавливают таких продуктов 43,000.
CS>Это конечно больше говорит о нужности базовых функций самих продуктов (а не только их UI), но тем не менее.
CS>Вот
CS>Цифры достоверные — не с потолка.
Здравствуйте, Mamut, Вы писали:
КЛ>>>лучше приведи кол-во продуктов, а не копий CS>>мне известны 42 продукта. M>Имхо, надо тут указать _что_ это за продукты
Имхо, большую часть кол-ва делают продукты symantec
Здравствуйте, Sheridan, Вы писали:
CS>>Это конечно больше говорит о нужности базовых функций самих продуктов (а не только их UI), но тем не менее. S>Это говорит о лени программистов. Ясен пень проще на хтмл нарисовать интерфейс. А то, что оно потребляет больше ресурсов — всем плевать.
Больше ли? Кто-нибудь сравнивал сколько в памяти занимают все библиотеки QT и HTMLayout?
CS>Вот скриншоты предыдущих версий: CS>http://www.winplanet.com/screenshots/11601.htm CS>А вот скриншот текущей версии CS>http://en.wikipedia.org/wiki/Norton_Internet_Security
Кроме того что красивше стало — ничего нового не вижу.
CS>Я могу сказать что затраты на UI не уменьшились. Я с ними два года уже как варюсь — знаю.
Ясное дело не уменьшились Только увеличиваются.
Или ты какие затраты имееш ввиду?
CS>Значительно увеличились возможности и качество при новом подходе — это да. CS>Им потрбовался HTML по другим причинам. Это возможность "склеивать" единый UI из разных источников. Каждый источник CS>это отдельная команда сидящая буквально на другой стороне шарика. Им потребовалось единая система CS>управления стилями из-за например требований Accessibility. В HighContrast mode NIS например выглядит как обычное win приложение. CS>Это сделано сугубо сменой CSS.
QT поддерживает css имхо более правильно.
CS>C точностью до наоборот. UI cтал *значительно* меньше ресурсов потреблять и работает быстрее. CS>html DOM элемент меньше чем структура окна (HWND) и отрисовывается *значительно* меньшей кровью.
Значительно меньше — это ты имееш ввиду наверное что текста меньше. Не забывай что хтмл текст парсится при исполнении, а HWND при сборке.
Насчет отрисовки тоже можно поспорить...
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, c-smile, Вы писали:
CS>>Вот скриншоты предыдущих версий: CS>>http://www.winplanet.com/screenshots/11601.htm CS>>А вот скриншот текущей версии CS>>http://en.wikipedia.org/wiki/Norton_Internet_Security S>Кроме того что красивше стало — ничего нового не вижу.
CS>>Значительно увеличились возможности и качество при новом подходе — это да. CS>>Им потрбовался HTML по другим причинам. Это возможность "склеивать" единый UI из разных источников. Каждый источник CS>>это отдельная команда сидящая буквально на другой стороне шарика. Им потребовалось единая система CS>>управления стилями из-за например требований Accessibility. В HighContrast mode NIS например выглядит как обычное win приложение. CS>>Это сделано сугубо сменой CSS. S>QT поддерживает css имхо более правильно.
Более правильно чем что?
CS>>C точностью до наоборот. UI cтал *значительно* меньше ресурсов потреблять и работает быстрее. CS>>html DOM элемент меньше чем структура окна (HWND) и отрисовывается *значительно* меньшей кровью. S>Значительно меньше — это ты имееш ввиду наверное что текста меньше. Не забывай что хтмл текст парсится при исполнении, а HWND при сборке.
Брр... чего когда там парсится-то?
S>Насчет отрисовки тоже можно поспорить...
Давай!
Я не знаю чем эти кадры из TT думали но в Windows например количество handles (HWND, HMENU, HICON, HBITMAP, etc.) per process
is a number between 200 and 18,000.
отсюда. При этом 10,000 окон уже шевелится не будет.
Здравствуйте, Sinclair, Вы писали:
S>>Любой элемент интерфейса — окно вообщето. S>Это, мягко говоря, преувеличение. Не стоит бравировать своим невежеством. Идея "один элемент управления — один hwnd" опорочила себя уж лет десять как.
о0
И как сейчас?
Не поленитесь, покажите хотябы потребление памяти софтом, хоть немного схожим с тем что я показал. Естественно, написаным с HTMLayout или подобным ui
Для незнающих:
assistant — справка, чтото типа винхелпа
designer — дизайнер форм. Многооконный, чтото типа дизайнера как в делфи.
linguist — софтина для создания файлов перевода. Интерфейс сложнее чем в ассистенте, но намного проще, чем в дизайнере.
Здравствуйте, Sheridan, Вы писали:
S>Не поленитесь, покажите хотябы потребление памяти софтом, хоть немного схожим с тем что я показал. Естественно, написаным с HTMLayout или подобным ui S>Для незнающих: S>assistant — справка, чтото типа винхелпа S>designer — дизайнер форм. Многооконный, чтото типа дизайнера как в делфи. S>linguist — софтина для создания файлов перевода. Интерфейс сложнее чем в ассистенте, но намного проще, чем в дизайнере.
Если замеры средней температуры по больнице имеют вообще смысл то вот:
Тоже поздравляю!
