Re[8]: Best GUI for Windows C++ application - C/C++. Прикладные вопросы

Здравствуйте, Anpek, Вы писали:

A>Здравствуйте, Mazay, Вы писали:

M>>А нативными должны быть только стандартные диалоги. Остальной UI должен быть просто удобным. Кнопка она и в африке кнопка.

A>А можно посмотреть примеры GUI, которые делает такой продвинутый чувак из 21 века? Я без издевки спрашиваю. Просто все тобой описанное — это как бы теория и конечному пользователю на неё наплевать как бы. Покажи примеры.

Ээээ. Конечный пользователь это кто? Если пользователь программы, то да, ему плевать на всё кроме конечного удобства. А если разработчик, то тут уж — попробовав сладкого не захочешь горького. Мне например кажется очень удобным представление гуя в виде документа, мне нравится что у меня есть DSL для управления гуем (типа javascript). Зачем мне нужен указатель (в Qt ещё и голый) на какую-то внутреннюю структуру GUI библиотеки? Хочу декларативный стиль.

Примеры нормального ненативного UI: Касперский, web-приложения гугла и др., с-smile здесь где-то скрины нортоновских приложений выкладывал.

Вообще-то если бы нативный гуи был нормальный так никактх вопросов — конечно лучше дать пользователю знакомое окружение. Но мне вот нифига не нравится нынешний нативный гуи. MS кажется что-то делает в этом направлении, но только для .NET и то как-то вяло.

Здравствуйте, Mazay, Вы писали:

M>Хотя бы. Меня пару раз спасала возможность подебажится сквозь кишки библиотеки. Ну а вообще если баг есть, то почему бы не поправить.

Почему ты не можешь это сделать с Qt?

Здравствуйте, Mazay, Вы писали:

M>Здравствуйте, Anpek, Вы писали:

A>>Здравствуйте, Mazay, Вы писали:

M>>>А нативными должны быть только стандартные диалоги. Остальной UI должен быть просто удобным. Кнопка она и в африке кнопка.

A>>А можно посмотреть примеры GUI, которые делает такой продвинутый чувак из 21 века? Я без издевки спрашиваю. Просто все тобой описанное — это как бы теория и конечному пользователю на неё наплевать как бы. Покажи примеры.

M>Ээээ. Конечный пользователь это кто? Если пользователь программы, то да, ему плевать на всё кроме конечного удобства. А если разработчик, то тут уж — попробовав сладкого не захочешь горького. Мне например кажется очень удобным представление гуя в виде документа, мне нравится что у меня есть DSL для управления гуем (типа javascript). Зачем мне нужен указатель (в Qt ещё и голый) на какую-то внутреннюю структуру GUI библиотеки? Хочу декларативный стиль.

M>Примеры нормального ненативного UI: Касперский, web-приложения гугла и др., с-smile здесь где-то скрины нортоновских приложений выкладывал.

M>Вообще-то если бы нативный гуи был нормальный так никактх вопросов — конечно лучше дать пользователю знакомое окружение. Но мне вот нифига не нравится нынешний нативный гуи. MS кажется что-то делает в этом направлении, но только для .NET и то как-то вяло.

Я правильно понял, что показать нечего?

Здравствуйте, Mazay, Вы писали:

M>Здравствуйте, Ytz, Вы писали:

Ytz>>Аргументы? Чем это лучше, например Qt? Мощное комьюнити, отличная документация, отсутствие багов, нативный вид и поведение приложения?

M>Для начала сравниваем только с QML, ибо в XXI веке для UI нужно DOM-представление, DSL (типа javascript) и CSS (или что-то подобное).
M>QML молод и тянет наследие допотопного Qt с велосипедами, левым препроцессором и совместимостью с допотопными компиляторами.

Подожди, подожди, не будем пока CSS с QML сравнивать, а попробуем по существу ответить на заданный вопрос. Сможешь?

Здравствуйте, Аноним, Вы писали:

А>Нужно написать приложение с интенсивным использованием GUI: нестандартные формочки, к примеру, как у Java SWT (Eclipse), а также генерированием графиков (нормальное распределение, etc.)

А>Что серъезное посоветуете: Qt, MFC, etc.?

wxWidget и полегче, и что то между QT и MFC

Здравствуйте, Mazay, Вы писали:

Ytz>>Аргументы? Чем это лучше, например Qt? Мощное комьюнити, отличная документация, отсутствие багов, нативный вид и поведение приложения?

M>Для начала сравниваем только с QML, ибо в XXI веке для UI нужно DOM-представление, DSL (типа javascript) и CSS (или что-то подобное).
M>QML молод и тянет наследие допотопного Qt с велосипедами, левым препроцессором и совместимостью с допотопными компиляторами.

То-то гугл аж GWT написал, лишь бы с таким говном, как javascript, поменьше связываться. Вот уж все DSL'ям DSL...

Здравствуйте, Аноним, Вы писали:

А>>Нужно написать приложение с интенсивным использованием GUI: нестандартные формочки, к примеру, как у Java SWT (Eclipse), а также генерированием графиков (нормальное распределение, etc.)

А>>Что серъезное посоветуете: Qt, MFC, etc.?

А>wxWidget и полегче, и что то между QT и MFC

Вообще-то wxWidget довольно противный. Т.е., лучше, конечно чем MFC, за счет хотя бы тех же сайзеров, но местами глюковат, сыроват и на фичи бедноват.

ТКС>Вообще-то wxWidget довольно противный. Т.е., лучше, конечно чем MFC, за счет хотя бы тех же сайзеров, но местами глюковат, сыроват и на фичи бедноват.

Ну я не знаю, мы используем уже лет 7, счастливы безмерно.
Примеры UI

Здравствуйте, Аноним, Вы писали:

А>Нужно написать приложение с интенсивным использованием GUI: нестандартные формочки, к примеру, как у Java SWT (Eclipse), а также генерированием графиков (нормальное распределение, etc.)

А>Что серъезное посоветуете: Qt, MFC, etc.?

Это вот Sciter UI (html/css/scripting + native logic code behind):

Еще screenshots:
http://www.softpedia.com/progScreenshots/Norton-Internet-Security-Screenshot-8667.html

Это вот HTMLayout UI (html/css + native logic code behind):
http://www.softpedia.com/progScreenshots/Avast-Home-Edition-Screenshot-6474.html

Здравствуйте, t_rex, Вы писали:

ТКС>>Вообще-то wxWidget довольно противный. Т.е., лучше, конечно чем MFC, за счет хотя бы тех же сайзеров, но местами глюковат, сыроват и на фичи бедноват.

_>Ну я не знаю, мы используем уже лет 7, счастливы безмерно.
_>Примеры UI

А мы 9, и уже признацца подзадолбало оно

Здравствуйте, c-smile, Вы писали:

CS>Это вот Sciter UI (html/css/scripting + native logic code behind):
CS>http://upload.wikimedia.org/wikipedia/en/e/e1/Norton_Internet_Security_2011.jpg

Ой блин, какой ужас. Ну вот зачем оно такое вырвиглазное (как и все кастомные гуи)? Как это сочетается с цветовыми и шрифтовыми настройками пользователя? Как оно ведёт себя в High Contrast схемах? Что с этим будет делать screen reader? При нажатии Alt появляются акселераторы на всех псевдолинкокнопках, которые пользователь мог бы хотеть нажать, или всё приходится мышкой тыкать?

Здравствуйте, Centaur, Вы писали:

C>Ой блин, какой ужас. Ну вот зачем оно такое вырвиглазное (как и все кастомные гуи)? Как это сочетается с цветовыми и шрифтовыми настройками пользователя? Как оно ведёт себя в High Contrast схемах? Что с этим будет делать screen reader? При нажатии Alt появляются акселераторы на всех псевдолинкокнопках, которые пользователь мог бы хотеть нажать, или всё приходится мышкой тыкать?

А ты попробуй

Для справки: при High Contrast настройках активируется специальный CSS использующий системные цвета и шрифты.
Это так сказать beauty of CSS — один и тот же DOM можно стилировать по всякому. С переключением в runtime.
А screen reader это будет читать. Ибо DOM поддерживает IAccessible. И вообще поддержка section 508 для Симантека это серьёзно. Ибо в принципе подсудное дело в этой части мира. Во всяком случае на моей памяти пришлось давать показания и принимать меры

И по поводу "Ой блин, какой ужас."
Мне в принципе самому не сильно нравятся многие дизайнерские решения там. Но когда например заходишь в ближайший BestBuy и видишь как люди покупают твой код (в т.ч. твой) то как-то по другому всё воспринимаешь. Типа может оно так и надо и мы, программеры, что-то не понимаем в принципе?

Здравствуйте, Аноним, Вы писали:

А>Нужно написать приложение с интенсивным использованием GUI: нестандартные формочки, к примеру, как у Java SWT (Eclipse), а также генерированием графиков (нормальное распределение, etc.)

А>Что серъезное посоветуете: Qt, MFC, etc.?

Вопрос ко всем ответившим — кто-нть юзал адобовскую Adam/Eve?

Здравствуйте, Centaur, Вы писали:

C>Здравствуйте, c-smile, Вы писали:

CS>>Это вот Sciter UI (html/css/scripting + native logic code behind):
CS>>http://upload.wikimedia.org/wikipedia/en/e/e1/Norton_Internet_Security_2011.jpg

C>Ой блин, какой ужас. Ну вот зачем оно такое вырвиглазное (как и все кастомные гуи)? Как это сочетается с цветовыми и шрифтовыми настройками пользователя? Как оно ведёт себя в High Contrast схемах? Что с этим будет делать screen reader? При нажатии Alt появляются акселераторы на всех псевдолинкокнопках, которые пользователь мог бы хотеть нажать, или всё приходится мышкой тыкать?

Для Мака разработчики следуют эппловским гайдлайнам, через это единый вид приложений, простота освоения пользователем и в впечатление от системы как о продуманной и цельной. Под винду же каждый разаработчик считает своим долгом сделать нестандартное окошо, кастомный внешний вид и т.д., в результате чего система выглядит как дикий восточный базар. Лично меня как юзера дико бесит эта пестрота и то, что я не могу используя одни и те же приемы работать в разных приложениях.

Здравствуйте, jazzer, Вы писали:

J>Вопрос ко всем ответившим — кто-нть юзал адобовскую Adam/Eve?

Я посматривал время от времени в свое время но не использовал. Похоже что проект не пошел в массы.

Понятно что декларативность в UI это хорошо. Много вещей можно в принципе задекларировать.
Например базовую струкуру UI + dynamic fragment templates + систему стилей рписывающих рюшечки и layout constraints (это то что делает Eve).
C Адамом все в принципе сложнее. Это попытка декларативно описать зависимости UI элементов. Возможно конечно но далеко не все.
В h-smile core за функциональность Adam'а отвечает CSSS! — мое процедурное расширение CSS.

Простейший случай зависимых UI элементов:

<input type=text #search />
<button #do-search>Search!<button>

когда input пустой нужно дизаблить кнопку search. Описывается такая зависимость в CSS[S!] так:

input#search 
{
  value-changed!: $1(button#do-search):disabled = self:empty;  
}

Но это простые случаи. Для более менее сложных (т.е. боевых) условий приходится использовать скрипт как следующий уровень декларативности.

В принципе Adam и Eve это достаточно малая часть того что реально нужно в UI. Поэтому наверное и не пошло ибо это не [законченное] решение.
Нужно уметь собственно рисовать например. Нужно уметь обрабатывать RTL/LTR специфику и до чертиков всяко разных деталей.
Вот такие мои мысли.

Здравствуйте, Ytz, Вы писали:

Ytz>Для Мака разработчики следуют эппловским гайдлайнам, через это единый вид приложений, простота освоения пользователем и в впечатление от системы как о продуманной и цельной. Под винду же каждый разаработчик считает своим долгом сделать нестандартное окошо, кастомный внешний вид и т.д., в результате чего система выглядит как дикий восточный базар. Лично меня как юзера дико бесит эта пестрота и то, что я не могу используя одни и те же приемы работать в разных приложениях.

По идее ты должен испытывать идиосинкразию к Web? Там каждый сайт (суть приложение) выпендривается по-своему. Не беспокоит, нет?
Представь что все сайты в Web используют Apple guidelines и стиль. Скажем вот в таком вот ключе. Тоскливо.

И вообще. Есть разные приложения. Скажем вот свой blocknote я сознательно делал на WTL т.е. с использованием сугубо системного UI:

Просто потому что он есть редактор — productive tool на каждый день. Хотел бы я чтобы Visual Studio была бы в таком ключе сделана. Вот в этой тулзе как раз веселые картинки напрягают конкретно.

А есть приложения которые я называю "большая красная кнопка". Их UI используется крайне редко. UI должен быть максимально пиктографичен. Просто дико представить скажем юзера которому потребутся чтение мануала для того чтобы что-то сделать в Нортон Internet Security. Это будет наверное первый и последний юзер приложения.

И вообще protector должен просто тихо себе жужжать в background и не отсвечивать. Но когда уж он показывает свой UI то он этот самый UI должен выглядеть как пульт управления — типа все под контролем — вот даже есть регулятор скорости дворников.

Кстати та карта что показывает threats в реальном времени ... я когда ея скриптовал перед глазами стояла "карта спутниковой обстановки" командного пункта — кто видел тот меня поймет.

Т.е. создание UI это тонкий процесс учитывающий психологию и цвет волос юзера.

c-smile wrote:

> (в т.ч. твой) то как-то по другому всё воспринимаешь. Типа может оно так
> и надо и мы, программеры, что-то не понимаем в принципе?

Нет, это все остальные не понимают чего-то в принципе.
А программеры понимают всё правильно.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, MasterZiv, Вы писали:

MZ>Нет, это все остальные не понимают чего-то в принципе.
MZ>А программеры понимают всё правильно.

Ну да. Жаль еще что з/п и жену себе запрограммировать низзя. Если бы можно было бы то нафиг бы нам все остальные тогда приснились?

Здравствуйте, c-smile, Вы писали:

CS>По идее ты должен испытывать идиосинкразию к Web? Там каждый сайт (суть приложение) выпендривается по-своему. Не беспокоит, нет?

Нет, не беспокоит. Сайт может являться приложением с точки зрения его разработчика, для меня — простого потребителя, это текст с картинками.

CS>Представь что все сайты в Web используют Apple guidelines и стиль. Скажем вот в таком вот ключе. Тоскливо.

Нет, лучше ты представь сайт с непривычной системой навигации, ну например где ссылки выглядят как текст. Удобно?

CS>И вообще. Есть разные приложения. Скажем вот свой blocknote я сознательно делал на WTL т.е. с использованием сугубо системного UI:
CS>Просто потому что он есть редактор — productive tool на каждый день. Хотел бы я чтобы Visual Studio была бы в таком ключе сделана. Вот в этой тулзе как раз веселые картинки напрягают конкретно.

Где в студии веселые картинки?

CS>А есть приложения которые я называю "большая красная кнопка". Их UI используется крайне редко. UI должен быть максимально пиктографичен. Просто дико представить скажем юзера которому потребутся чтение мануала для того чтобы что-то сделать в Нортон Internet Security. Это будет наверное первый и последний юзер приложения.

Опять понятия подменяем. Удобная и понятная программа != кастомный гуй, стандартный вид и поведение != сложная и неудобная программа.

Здравствуйте, c-smile, Вы писали:

c> По идее ты должен испытывать идиосинкразию к Web? Там каждый сайт (суть приложение) выпендривается по-своему. Не беспокоит, нет?

Не беспокоит. Веб это веб, его разношерстность, она природная. Приложения ОС должны использовать системный гуй (с допущением минимальных девиаций). Вообще, веб-приложения всеми силами пытаются мимикрировать под десктоп-стайл, чтобы быть ближе юзеру, так что плохой пример.

c> Представь что все сайты в Web используют Apple guidelines и стиль. Скажем вот в таком вот ключе. Тоскливо.

Незачем это представлять.

c> А есть приложения которые я называю "большая красная кнопка". Их UI используется крайне редко. UI должен быть максимально пиктографичен. Просто дико представить скажем юзера которому потребутся чтение мануала для того чтобы что-то сделать в Нортон Internet Security. Это будет наверное первый и последний юзер приложения.

Не могу ничего сказать про этот Нортон (кроме того, что из-за гуя я бы его не выбрал ни в жизть), не использовал, но вот когда у Каспера гуй стал весь из себя скинованный... Ну жопа же полная с юзабилити. Смотриться красиво местами, да, но пользоваться неудобно, блин. И противоположный пример, Dr.Web, все стандартно, просто и функционально.

c> И вообще protector должен просто тихо себе жужжать в background и не отсвечивать. Но когда уж он показывает свой UI то он этот самый UI должен выглядеть как пульт управления — типа все под контролем — вот даже есть регулятор скорости дворников.

Блин, а настройки делать? Ладно, это в антивирусах не часто делать приходится, но сегодня и файрволы пугают своей внешностью. Все разукрашенные по самое небалуйся, как этим пользоваться вообще не понятно. Создается впечатление, что их основная ценность и заключается в их пестрости.

avalon 1.0rc3 rev 363, zlib 1.2.3.3

Здравствуйте, Ytz, Вы писали:

Ytz>Здравствуйте, c-smile, Вы писали:

CS>>По идее ты должен испытывать идиосинкразию к Web? Там каждый сайт (суть приложение) выпендривается по-своему. Не беспокоит, нет?

Ytz>Нет, не беспокоит. Сайт может являться приложением с точки зрения его разработчика, для меня — простого потребителя, это текст с картинками.

Я не понял смысл этой фразы.

CS>>Представь что все сайты в Web используют Apple guidelines и стиль. Скажем вот в таком вот ключе. Тоскливо.

Ytz>Нет, лучше ты представь сайт с непривычной системой навигации, ну например где ссылки выглядят как текст. Удобно?

Ты видел такие сайты? Ими много людей пользуется?

CS>>И вообще. Есть разные приложения. Скажем вот свой blocknote я сознательно делал на WTL т.е. с использованием сугубо системного UI:
CS>>Просто потому что он есть редактор — productive tool на каждый день. Хотел бы я чтобы Visual Studio была бы в таком ключе сделана. Вот в этой тулзе как раз веселые картинки напрягают конкретно.

Ytz>Где в студии веселые картинки?

Все версии Visual Studio после 6 версии используют custom GUI (и стили и элементы). VS2010 вообще далеко от system look and feel.
Qt Creator далек от productive tool. MS Office еще дальше. Photoshop тоже. Это те приложения которыми народ пользуется.
Причем пользователей например MS Office в разы больше чем пользователей всей платформы Mac.

Мы конечно можем говорить до бесконечности об эстетических предпочтениях пользователей по всему миру vs. мнение отдельно взятого тов. Ytz.
Результат в общем-то предсказуем я думаю — сколько людей — столько мнений. Твое мнение как и мое о какой-то отдельной тулзовине лишь одно из них.

CS>>А есть приложения которые я называю "большая красная кнопка". Их UI используется крайне редко. UI должен быть максимально пиктографичен. Просто дико представить скажем юзера которому потребутся чтение мануала для того чтобы что-то сделать в Нортон Internet Security. Это будет наверное первый и последний юзер приложения.

Ytz>Опять понятия подменяем. Удобная и понятная программа != кастомный гуй, стандартный вид и поведение != сложная и неудобная программа.

Что значит "опять"?

Ты не понял идею которую я пытался донести. В приложениях "большой красной кнопки" понятия "неудобно" нет. Есть просто размер этой самой красной кнопки на которую нужно нажать один раз в месяц или типа того. Причем визуально эта кнопка должна выделяться чтобы ты её не искал каждый раз.

Я тебе описал идею которой пользуется команды дизайнеров такого типа приложений. Команды разные — выводы примерно одинаковые.
Например у Симантека когда вышла первая версия с htmlayout GUI (2007 год) я помню было 40тыс инсталляций в день. Мне говорили что такого в их истории никогда не было. Это факты из жизни. Если можешь подтвердить свою концепцию популярного унифицированного военного приложения — пример в студию. Чтобы было о чем предметно говорить.

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, c-smile, Вы писали:

c>> По идее ты должен испытывать идиосинкразию к Web? Там каждый сайт (суть приложение) выпендривается по-своему. Не беспокоит, нет?

H>Не беспокоит. Веб это веб, его разношерстность, она природная. Приложения ОС должны использовать системный гуй (с допущением минимальных девиаций). Вообще, веб-приложения всеми силами пытаются мимикрировать под десктоп-стайл, чтобы быть ближе юзеру, так что плохой пример.

"Приложения ОС должны использовать системный гуй".

Кому должны? Тебе лично? Тебя лично кто-то ограничивает в выборе?

c>> А есть приложения которые я называю "большая красная кнопка". Их UI используется крайне редко. UI должен быть максимально пиктографичен. Просто дико представить скажем юзера которому потребутся чтение мануала для того чтобы что-то сделать в Нортон Internet Security. Это будет наверное первый и последний юзер приложения.

c>> И вообще protector должен просто тихо себе жужжать в background и не отсвечивать. Но когда уж он показывает свой UI то он этот самый UI должен выглядеть как пульт управления — типа все под контролем — вот даже есть регулятор скорости дворников.

H>Блин, а настройки делать? Ладно, это в антивирусах не часто делать приходится, но сегодня и файрволы пугают своей внешностью. Все разукрашенные по самое небалуйся, как этим пользоваться вообще не понятно. Создается впечатление, что их основная ценность и заключается в их пестрости.

Вот про "не часто делать приходится" я имею ввиду когда говорю про "большую красную кнопку".

Меня лично мой файервол своей внешностью не пугает. Он у меня аппаратный и UI у него опять же browser based.
Нормальный такой self-descriptive web interface. Не слишком выдающийся но и не г-унылое.

Здравствуйте, c-smile, Вы писали:

CS>>>По идее ты должен испытывать идиосинкразию к Web? Там каждый сайт (суть приложение) выпендривается по-своему. Не беспокоит, нет?

Ytz>>Нет, не беспокоит. Сайт может являться приложением с точки зрения его разработчика, для меня — простого потребителя, это текст с картинками.

CS>Я не понял смысл этой фразы.

Поясню. Есть инструмент которым пользуешься, например текстовой редактор — это приложение. Есть просто средство получения информации — книга, телевизор, веб-сайт. Для меня, как пользователя, приложение — это браузер, а веб-сайт отображаемый в нем — текст с картинками, вроде страницы журнала.

CS>>>Представь что все сайты в Web используют Apple guidelines и стиль. Скажем вот в таком вот ключе. Тоскливо.

Ytz>>Нет, лучше ты представь сайт с непривычной системой навигации, ну например где ссылки выглядят как текст. Удобно?

CS>Ты видел такие сайты? Ими много людей пользуется?

Видел к сожалению, как видел и приложения с кастомным гуем. Доступно?

Ytz>>Где в студии веселые картинки?

CS>Все версии Visual Studio после 6 версии используют custom GUI (и стили и элементы). VS2010 вообще далеко от system look and feel.

Согласен. Есть отличия, не вырви глаз от Симантек конечно, но все же. Я об этом и говорил, что к сожалению нет под Винду жестких стандартов.

CS>Qt Creator далек от productive tool. MS Office еще дальше. Photoshop тоже. Это те приложения которыми народ пользуется.
CS>Причем пользователей например MS Office в разы больше чем пользователей всей платформы Mac.

Не уловил смысл. Что такое "productive tool"?

CS>Мы конечно можем говорить до бесконечности об эстетических предпочтениях пользователей по всему миру vs. мнение отдельно взятого тов. Ytz.

Ловко перешел, молодец.

CS>>>А есть приложения которые я называю "большая красная кнопка". Их UI используется крайне редко. UI должен быть максимально пиктографичен. Просто дико представить скажем юзера которому потребутся чтение мануала для того чтобы что-то сделать в Нортон Internet Security. Это будет наверное первый и последний юзер приложения.

Ytz>>Опять понятия подменяем. Удобная и понятная программа != кастомный гуй, стандартный вид и поведение != сложная и неудобная программа.

CS>Что значит "опять"?

CS>Ты не понял идею которую я пытался донести. В приложениях "большой красной кнопки" понятия "неудобно" нет. Есть просто размер этой самой красной кнопки на которую нужно нажать один раз в месяц или типа того. Причем визуально эта кнопка должна выделяться чтобы ты её не искал каждый раз.

На кону мочало, начинай сначала. Сделай усилие, прочти еще раз внимательно: "Удобная и понятная программа != кастомный гуй, стандартный вид и поведение != сложная и неудобная программа."

CS>Я тебе описал идею которой пользуется команды дизайнеров такого типа приложений. Команды разные — выводы примерно одинаковые.
CS>Например у Симантека когда вышла первая версия с htmlayout GUI (2007 год) я помню было 40тыс инсталляций в день. Мне говорили что такого в их истории никогда не было. Это факты из жизни.

Вот в чем секрет счастья — переход на htmlayout. Инсталяций у хоум юзеров? Исследования проводились, что хоум юзеры покупали только из-за внешнего вида?

CS>Если можешь подтвердить свою концепцию популярного унифицированного военного приложения — пример в студию. Чтобы было о чем предметно говорить.

Не понял почему военного? Или это твой новый прием демагогии? Пример унифицированного приводил — продукция Эппл, достаточно?

Здравствуйте, c-smile, Вы писали:

c> H>Не беспокоит. Веб это веб, его разношерстность, она природная. Приложения ОС должны использовать системный гуй (с допущением минимальных девиаций). Вообще, веб-приложения всеми силами пытаются мимикрировать под десктоп-стайл, чтобы быть ближе юзеру, так что плохой пример.

c> "Приложения ОС должны использовать системный гуй".

c> Кому должны? Тебе лично? Тебя лично кто-то ограничивает в выборе?

По гидлайнам должны. Нет, в выборе меня никто не ограничивает, разумеется, я говорю о тренде который мне не нравится.

c> c>> А есть приложения которые я называю "большая красная кнопка". Их UI используется крайне редко. UI должен быть максимально пиктографичен. Просто дико представить скажем юзера которому потребутся чтение мануала для того чтобы что-то сделать в Нортон Internet Security. Это будет наверное первый и последний юзер приложения.

c> c>> И вообще protector должен просто тихо себе жужжать в background и не отсвечивать. Но когда уж он показывает свой UI то он этот самый UI должен выглядеть как пульт управления — типа все под контролем — вот даже есть регулятор скорости дворников.

c> H>Блин, а настройки делать? Ладно, это в антивирусах не часто делать приходится, но сегодня и файрволы пугают своей внешностью. Все разукрашенные по самое небалуйся, как этим пользоваться вообще не понятно. Создается впечатление, что их основная ценность и заключается в их пестрости.

c> Вот про "не часто делать приходится" я имею ввиду когда говорю про "большую красную кнопку".

А сейчас антивирусы, файрволы, проактивки вообще объединяют в один пак и унифицируют гуй. Так вот, ни файрвол, ни проактивку назвать "большой красной кнопкой" нельзя.

c> Меня лично мой файервол своей внешностью не пугает. Он у меня аппаратный и UI у него опять же browser based.
c> Нормальный такой self-descriptive web interface. Не слишком выдающийся но и не г-унылое.

У меня тоже нормальный файрвол, но тренд имеет место быть.

avalon 1.0rc3 rev 363, zlib 1.2.3

Здравствуйте, Ytz, Вы писали:

Ytz>Здравствуйте, c-smile, Вы писали:

CS>>>>По идее ты должен испытывать идиосинкразию к Web? Там каждый сайт (суть приложение) выпендривается по-своему. Не беспокоит, нет?

Ytz>>>Нет, не беспокоит. Сайт может являться приложением с точки зрения его разработчика, для меня — простого потребителя, это текст с картинками.

CS>>Я не понял смысл этой фразы.

Ytz>Поясню. Есть инструмент которым пользуешься, например текстовой редактор — это приложение. Есть просто средство получения информации — книга, телевизор, веб-сайт. Для меня, как пользователя, приложение — это браузер, а веб-сайт отображаемый в нем — текст с картинками, вроде страницы журнала.

Т.е. ты различаешь браузер как приложение и доокументы котрые в него грузятся.

При этом ты говоришь что браузеры должны использовать только UI системы (кстати каким UA ты пользуешься сам и почему?).
Но разрешаешь многобразие в загружаемых внутрь документах.

Чем это коцептуально отличается от OS desktop как программы в которую грузятся приложения-документы?
Я пытаюсь нащупать границу — понять "три яблока это куча или нет".

CS>>Ты видел такие сайты? Ими много людей пользуется?

Ytz>Видел к сожалению, как видел и приложения с кастомным гуем. Доступно?

Ты ими пользуешься? Как ты думаешь ими много людей пользуются?
Я тому что есть объектвные законы UI строения которые от нашего с тобой личного мнения не сильно зависят. К счастью или к сожалению.

Ytz>>>Где в студии веселые картинки?

CS>>Все версии Visual Studio после 6 версии используют custom GUI (и стили и элементы). VS2010 вообще далеко от system look and feel.

Ytz>Согласен. Есть отличия, не вырви глаз от Симантек конечно, но все же. Я об этом и говорил, что к сожалению нет под Винду жестких стандартов.

"под Винду" есть достаточно "жестких стандартов" и UI guidelines. Уж не меньше чем в MacOS.
Но если звёзды зажигают значит это кому-нибудь нужно я так думаю.

CS>>Qt Creator далек от productive tool. MS Office еще дальше. Photoshop тоже. Это те приложения которыми народ пользуется.
CS>>Причем пользователей например MS Office в разы больше чем пользователей всей платформы Mac.

Ytz>Не уловил смысл. Что такое "productive tool"?

productive tool это программа как правило ежедневного пользования используемая как средство производства.

CS>>Мы конечно можем говорить до бесконечности об эстетических предпочтениях пользователей по всему миру vs. мнение отдельно взятого тов. Ytz.

Ytz>Ловко перешел, молодец.

Я не понял. Куда "перешел"?

CS>>Я тебе описал идею которой пользуется команды дизайнеров такого типа приложений. Команды разные — выводы примерно одинаковые.
CS>>Например у Симантека когда вышла первая версия с htmlayout GUI (2007 год) я помню было 40тыс инсталляций в день. Мне говорили что такого в их истории никогда не было. Это факты из жизни.

Ytz>Вот в чем секрет счастья — переход на htmlayout. Инсталяций у хоум юзеров? Исследования проводились, что хоум юзеры покупали только из-за внешнего вида?

Ну нет конечно. htmlayout это embeddable HTML/CSS engine. Сам он тебе дизайн не сделает.
Так же как наличие у пользователя браузера не гарантирует того что он найдет полезным и полюбит твой сайт.
Но наличие современного и быстрого броузера у юзера может помочь тебе сделать expressive сайт для него.

CS>>Если можешь подтвердить свою концепцию популярного унифицированного военного приложения — пример в студию. Чтобы было о чем предметно говорить.

Ytz>Не понял почему военного? Или это твой новый прием демагогии? Пример унифицированного приводил — продукция Эппл, достаточно?

Продукция Эппл это firmware компьютеров фирмы Apple которой пользуется достаточно ограниченное число (в сравнении) пользователей.
Кому-то нравится. Кому-то нет и они выбирают Windows например с его многообразием. Последних явно больше.

По всей видимости тебе повезло и ты можешь себе позволить писать программы использующие только стандартные элементы OS.
К сожалению не все находятся в такой выигрышной позиции — требуется делать что-то яркое и необычное чтобы пробиться.

Здравствуйте, hattab, Вы писали:

H>А сейчас антивирусы, файрволы, проактивки вообще объединяют в один пак и унифицируют гуй. Так вот, ни файрвол, ни проактивку назвать "большой красной кнопкой" нельзя.

c>> Меня лично мой файервол своей внешностью не пугает. Он у меня аппаратный и UI у него опять же browser based.
c>> Нормальный такой self-descriptive web interface. Не слишком выдающийся но и не г-унылое.

H>У меня тоже нормальный файрвол, но тренд имеет место быть.

Вот и о том — хорошо когда есть свобода выбора, а не только строем ходить.

Кстати по поводу стилей в UI. В HTMLayout/Sciter можно легко создавать приложения используещее две системы стилей — OS theme и нечто fancy.
Т.е. в принципе можно делать продукты котрые будут нравиться и программерам и блондинкам. Проблема в том что программеры приложения не покупают но это действительно отдельная история.

Здравствуйте, Аноним, Вы писали:

А>Нужно написать приложение с интенсивным использованием GUI: нестандартные формочки, к примеру, как у Java SWT (Eclipse), а также генерированием графиков (нормальное распределение, etc.)

А>Что серъезное посоветуете: Qt, MFC, etc.?
Qt, wxWidget, Juice, FoxToolkit, FLTK, Ultimate++, Win32++

On 09.10.2010 18:14, hattab wrote:

> Не могу ничего сказать про этот Нортон (кроме того, что из-за гуя я бы его не
> выбрал ни в жизть), не использовал, но вот когда у Каспера гуй стал весь из себя
> скинованный... Ну жопа же полная с юзабилити. Смотриться красиво местами, да, но
> пользоваться неудобно, блин. И противоположный пример, Dr.Web, все стандартно,
> просто и функционально.

Да +100 !
У нас стоит корпоративно ESET NOD32 -- ну точно та же проблема. Понаворотили,
посмотриш -- красота ! А куда на кнопку жать -- не понятно. Это при том, что
сама-то программа вообще в бэкграунде должна тихо сидеть себе и с пользователем
не взаимодействовать.

Ещё пример, на убой -- CyberLink MediaShow. Интерфейс понавороченный ... ---
а делать нихрена не может. В общем долго распинаться о этом лениво, но
итог один — чем более навороченный и нестандартный GUI у программы, тем меньше в
ней пользы. Это почти однозначное правило, работающее на 95%. Есть конечно
исключения, типа WinAmp-а, но редко.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, MasterZiv, Вы писали:

MZ>Да +100 !
MZ>У нас стоит корпоративно ESET NOD32 -- ну точно та же проблема. Понаворотили,
MZ>посмотриш -- красота ! А куда на кнопку жать -- не понятно. Это при том, что
MZ>сама-то программа вообще в бэкграунде должна тихо сидеть себе и с пользователем
MZ>не взаимодействовать.

MZ>Ещё пример, на убой -- CyberLink MediaShow. Интерфейс понавороченный ... ---
MZ>а делать нихрена не может. В общем долго распинаться о этом лениво, но
MZ>итог один — чем более навороченный и нестандартный GUI у программы, тем меньше в
MZ>ней пользы. Это почти однозначное правило, работающее на 95%. Есть конечно
MZ>исключения, типа WinAmp-а, но редко.

Как бы это все не касается напрямую проблемы system/custom GUI.
Я думаю примеры сугубо system UI в котором нифига невозможно найти тоже достаточно известны.

Как правило когда программеры начинают заниматься разработкой UI тут то и наступает полный праздник духа.
В качестве примера Code::Blocks который весь из себя такой системный UI (ибо wxWidgets):
http://www.softpedia.com/progScreenshots/Code-Blocks-Screenshot-80246.html
В этих настройках найти что-то ...

Здравствуйте, c-smile, Вы писали:

CS>Понятно что декларативность в UI это хорошо. Много вещей можно в принципе задекларировать.
CS>Например базовую струкуру UI + dynamic fragment templates + систему стилей рписывающих рюшечки и layout constraints (это то что делает Eve).
CS>C Адамом все в принципе сложнее. Это попытка декларативно описать зависимости UI элементов. Возможно конечно но далеко не все.

а с tcl/tk работал?
какие впечатления?

Здравствуйте, night beast, Вы писали:

NB>а с tcl/tk работал?
NB>какие впечатления?
я работал, отстой.
годится для разве что совсем уж примитивных вещей, все остальное — застрелишься, кода сложность гуя превысит некий очень маленький порог.

Здравствуйте, jazzer, Вы писали:

NB>>а с tcl/tk работал?
NB>>какие впечатления?
J>я работал, отстой.
J>годится для разве что совсем уж примитивных вещей, все остальное — застрелишься, кода сложность гуя превысит некий очень маленький порог.

хм. у меня таких проблем не возникало.
можно пример, когда возникали сложности?

Здравствуйте, night beast, Вы писали:

NB>Здравствуйте, jazzer, Вы писали:

NB>>>а с tcl/tk работал?
NB>>>какие впечатления?
J>>я работал, отстой.
J>>годится для разве что совсем уж примитивных вещей, все остальное — застрелишься, кода сложность гуя превысит некий очень маленький порог.

NB>хм. у меня таких проблем не возникало.
NB>можно пример, когда возникали сложности?

ну в tcl же нет нормальной модульности, инкапсуляции, контроля имен и прочего.
По крайней мере, не было в середине 90-х, когда я на нем писал гуй (промышленно).
Так что все в результате живет в глобальной области видимости, и черт ногу сломит, где что.
Отладка — это вообще пипец, проклянешь все на свете, пока найдешь, что же откуда сломалось, особенно когда начинаешь код передавать как строчку (а это, похоже, единственный вменяемый способ на тикле писать).

Здравствуйте, jazzer, Вы писали:

J>>>я работал, отстой.
J>>>годится для разве что совсем уж примитивных вещей, все остальное — застрелишься, кода сложность гуя превысит некий очень маленький порог.

NB>>хм. у меня таких проблем не возникало.
NB>>можно пример, когда возникали сложности?

J>ну в tcl же нет нормальной модульности, инкапсуляции, контроля имен и прочего.
J>По крайней мере, не было в середине 90-х, когда я на нем писал гуй (промышленно).

к сожалению не слежу за судьбой языка, может какие сдвиги и случились...

J>Так что все в результате живет в глобальной области видимости, и черт ногу сломит, где что.

не совсем так. в функциях переменные локальные.
ну а переменные, важные для ГУЯ, в словаре хранить можно. тогда все становится проще.

J>Отладка — это вообще пипец, проклянешь все на свете, пока найдешь, что же откуда сломалось, особенно когда начинаешь код передавать как строчку (а это, похоже, единственный вменяемый способ на тикле писать).

а чего отлаживать? логика на сях пишется.

Здравствуйте, night beast, Вы писали:

NB>не совсем так. в функциях переменные локальные.
NB>ну а переменные, важные для ГУЯ, в словаре хранить можно. тогда все становится проще.
без инкапсуляции и контроля имен — только до определенного предела.

NB>а чего отлаживать? логика на сях пишется.
ну так гуй и отлаживать, на сях пишется логика приложения, а не гуя.

В общем-то, у Питона те же проблемы, но сам язык побольше возможностей имеет.
Плюс буст.питоновские обертки проверяют типы, что уже хорошо.

Здравствуйте, jazzer, Вы писали:

NB>>не совсем так. в функциях переменные локальные.
NB>>ну а переменные, важные для ГУЯ, в словаре хранить можно. тогда все становится проще.
J>без инкапсуляции и контроля имен — только до определенного предела.

NB>>а чего отлаживать? логика на сях пишется.
J>ну так гуй и отлаживать, на сях пишется логика приложения, а не гуя.

как говорится, у каждого свой опыт.
просто хотел сказать, что

застрелишься, кода сложность гуя превысит некий очень маленький порог.

не совсем соответствует действительности.

J>В общем-то, у Питона те же проблемы, но сам язык побольше возможностей имеет.
J>Плюс буст.питоновские обертки проверяют типы, что уже хорошо.

для тикля c++tk есть.

Здравствуйте, c-smile, Вы писали:

CS>Т.е. ты различаешь браузер как приложение и доокументы котрые в него грузятся.

Конечно. А ты не различаешь например вордовый документ от ворда?

CS>При этом ты говоришь что браузеры должны использовать только UI системы (кстати каким UA ты пользуешься сам и почему?).

Что такое UA?

CS>Но разрешаешь многобразие в загружаемых внутрь документах.

Точно, почему выше читай.

CS>Чем это коцептуально отличается от OS desktop как программы в которую грузятся приложения-документы?

Десктоп — рабочий стол, на котором лежат бумаги, книги, ручки, калькулятор и т.д. — инструменты. Для пользователя десктоп должен быть не центром всего, так как работает он с инструментами которые на нем, а не с ним самим. Работая с инструментами я хочу чтобы инструмент ручка вел себя как ручка и выглядел соответственно. Информация в книгах может быть разной и представлена по разному, опять таки стандарты важны!!! Обращал внимание, что научная литература оформляется по определенным стандартам? Сама же книга должна выглядеть как книга. Ты извини, что совсем уж разжевывать приходится.

CS>Я пытаюсь нащупать границу — понять "три яблока это куча или нет".

Не понимаю, что ты хотел сказать.

CS>>>Ты видел такие сайты? Ими много людей пользуется?

Ytz>>Видел к сожалению, как видел и приложения с кастомным гуем. Доступно?

CS>Ты ими пользуешься? Как ты думаешь ими много людей пользуются?

Не пользуюсь я продукцией симантек, в том числе и из-за мега дизайна.

CS>Я тому что есть объектвные законы UI строения которые от нашего с тобой личного мнения не сильно зависят. К счастью или к сожалению.

Есть. А ты на них плюешь.

Ytz>>>>Где в студии веселые картинки?

CS>>>Все версии Visual Studio после 6 версии используют custom GUI (и стили и элементы). VS2010 вообще далеко от system look and feel.

Ytz>>Согласен. Есть отличия, не вырви глаз от Симантек конечно, но все же. Я об этом и говорил, что к сожалению нет под Винду жестких стандартов.

CS>"под Винду" есть достаточно "жестких стандартов" и UI guidelines. Уж не меньше чем в MacOS.
CS>Но если звёзды зажигают значит это кому-нибудь нужно я так думаю.

Есть. Но не сильно соблюдаются, к сожалению.

CS>>>Qt Creator далек от productive tool. MS Office еще дальше. Photoshop тоже. Это те приложения которыми народ пользуется.
CS>>>Причем пользователей например MS Office в разы больше чем пользователей всей платформы Mac.

Ytz>>Не уловил смысл. Что такое "productive tool"?

CS>productive tool это программа как правило ежедневного пользования используемая как средство производства.

Почему тогда Qt Creator, MS Office и Photoshop не productive tool?

CS>>>Мы конечно можем говорить до бесконечности об эстетических предпочтениях пользователей по всему миру vs. мнение отдельно взятого тов. Ytz.

Ytz>>Ловко перешел, молодец.

CS>Я не понял. Куда "перешел"?

На мою скромную персону.

CS>>>Я тебе описал идею которой пользуется команды дизайнеров такого типа приложений. Команды разные — выводы примерно одинаковые.
CS>>>Например у Симантека когда вышла первая версия с htmlayout GUI (2007 год) я помню было 40тыс инсталляций в день. Мне говорили что такого в их истории никогда не было. Это факты из жизни.

Ytz>>Вот в чем секрет счастья — переход на htmlayout. Инсталяций у хоум юзеров? Исследования проводились, что хоум юзеры покупали только из-за внешнего вида?

CS>Ну нет конечно. htmlayout это embeddable HTML/CSS engine. Сам он тебе дизайн не сделает.
CS>Так же как наличие у пользователя браузера не гарантирует того что он найдет полезным и полюбит твой сайт.
CS>Но наличие современного и быстрого броузера у юзера может помочь тебе сделать expressive сайт для него.

CS>>>Если можешь подтвердить свою концепцию популярного унифицированного военного приложения — пример в студию. Чтобы было о чем предметно говорить.

Ytz>>Не понял почему военного? Или это твой новый прием демагогии? Пример унифицированного приводил — продукция Эппл, достаточно?

CS>Продукция Эппл это firmware компьютеров фирмы Apple которой пользуется достаточно ограниченное число (в сравнении) пользователей.
CS>Кому-то нравится. Кому-то нет и они выбирают Windows например с его многообразием. Последних явно больше.

Выбирают винду по другим причинам. У пользователей винды увидевших МакОС реакция после цветастых поделок одна — вау, какая красивая и продуманная система!

CS>По всей видимости тебе повезло и ты можешь себе позволить писать программы использующие только стандартные элементы OS.
CS>К сожалению не все находятся в такой выигрышной позиции — требуется делать что-то яркое и необычное чтобы пробиться.

Лучше бы ваш продукт хорошо со своей задачей справлялся, а не пытался бы всех затмить красотой, результат был бы лучше.

Здравствуйте, LaptevVV, Вы писали:

А>>Что серъезное посоветуете: Qt, MFC, etc.?
LVV>Qt,

Жи-и-ирный. Не дружит с приложениями, читающими из окон приложения (а-ля Lingvo).

LVV> wxWidget,

Богат на странности.

LVV> Juice,

Этого не щупал.

LVV> FoxToolkit,

То, что мне довелось потрогать, было глючновато. То окна создает где-то мимо экрана, то крэшится.
Поддержки юникода в нем на тот момент не было (смутно вспоминается, что сейчас вроде что-то есть).
Да и неудобен он: пока все колбэки для окна в табличку пропишешь — повесишься.

LVV> FLTK,

Убог и не поддерживает юникод.

LVV> Ultimate++,

Этот, кажется, написан в стиле "присваивание передает объект, а не копирует его".
Придется привыкать и огребать глюки в процессе.

LVV> Win32++

"Мы как MFC, только лучше".

On 10.10.2010 0:37, c-smile wrote:

> "Приложения ОС должны использовать системный гуй".
>
> Кому должны? Тебе лично? Тебя лично кто-то ограничивает в выборе?

Пользователю. Неужели не ясно ?

Posted via RSDN NNTP Server 2.1 beta

On 10.10.2010 2:09, c-smile wrote:

> Вот и о том — хорошо когда есть свобода выбора, а не только строем ходить.

Свобода выбора -- это когда ты ОС выбираешь. Или продукт по его способности
что-то ДЕЛАТЬ, а не по красивым шашечкам.

Posted via RSDN NNTP Server 2.1 beta

On 11.10.2010 7:01, c-smile wrote:

> Как бы это все не касается напрямую проблемы system/custom GUI.
> Я думаю примеры сугубо system UI в котором нифига невозможно найти тоже
> достаточно известны.

Давай не мешать холодное с мягким. Если GUI используется стандартный,
и не понятно, то это -- просто плохой GUI. И всё. А если это ещё
и нестандартный GUI, то проблема уже в том, что он нестандартный.

Posted via RSDN NNTP Server 2.1 beta

On 11.10.2010 9:16, jazzer wrote:

> NB>а с tcl/tk работал?
> NB>какие впечатления?
> я работал, отстой.
> годится для разве что совсем уж примитивных вещей, все остальное — застрелишься,
> кода сложность гуя превысит некий очень маленький порог.

TK -- мощное и гибкое решение. Чем оно тебе не угодило -- не понятно.

Posted via RSDN NNTP Server 2.1 beta

On 11.10.2010 10:18, jazzer wrote:

> ну в tcl же нет нормальной модульности, инкапсуляции, контроля имен и прочего.
> По крайней мере, не было в середине 90-х, когда я на нем писал гуй (промышленно).

Ты это, язык с библиотекой не путай. Язык -- одно, библиотека GUI для неё --
другое. На ней вообще-то можно на разных языках писать. C/C++, Python, ruby,
CL, perl. Думаю есть ещё.

Posted via RSDN NNTP Server 2.1 beta

On 11.10.2010 12:51, Аноним 775 wrote:
Не дружит с приложениями, читающими из окон приложения (а-ля Lingvo).

Это как ? можно подробнее ? А то не понятно.

> Убог и не поддерживает юникод.

На счёт юникода. Подозреваю, что тебе зачем-то нужен UTF-16. Современные
тенденции -- уход от UTF-16 в сторону UTF-8. Его многий софт поддерживает.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, MasterZiv, Вы писали:

MZ>On 11.10.2010 9:16, jazzer wrote:

>> NB>а с tcl/tk работал?
>> NB>какие впечатления?
>> я работал, отстой.
>> годится для разве что совсем уж примитивных вещей, все остальное — застрелишься,
>> кода сложность гуя превысит некий очень маленький порог.

MZ>TK -- мощное и гибкое решение. Чем оно тебе не угодило -- не понятно.
Ну, что ж я могу поделать.
Я на нем (tcl/tk) год писал, и не знаю, сколько мне должны заплатить денег, чтоб я опять добровольно согласился на нем писать.
Плюс tcl/tk — это дикое тормозилово.

За исключением того, что я регулярно подтачиваю TkDiff/TkCVS (это тоже tcl/tk), правда, мейнтейнеры там сонные, по несколько лет патчи принять не могут.

Здравствуйте, MasterZiv, Вы писали:

MZ>On 11.10.2010 10:18, jazzer wrote:

>> ну в tcl же нет нормальной модульности, инкапсуляции, контроля имен и прочего.
>> По крайней мере, не было в середине 90-х, когда я на нем писал гуй (промышленно).

MZ>Ты это, язык с библиотекой не путай. Язык -- одно, библиотека GUI для неё --
MZ>другое. На ней вообще-то можно на разных языках писать. C/C++, Python, ruby,
MZ>CL, perl. Думаю есть ещё.

Был вопрос про tcl/tk, я про это и отвечал, а не про все остальное, что ты здесь перечислил.

Здравствуйте, c-smile, Вы писали:

CS>А screen reader это будет читать. Ибо DOM поддерживает IAccessible. И вообще поддержка section 508 для Симантека это серьёзно. Ибо в принципе подсудное дело в этой части мира. Во всяком случае на моей памяти пришлось давать показания и принимать меры

а можно поподробнее что не так с section 508?

On 11.10.2010 14:13, jazzer wrote:

> Был вопрос про tcl/tk, я про это и отвечал, а не про все остальное, что ты здесь
> перечислил.

Вообще-то вопрос был про GUI: "Best GUI for Windows C++ application"

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, MasterZiv, Вы писали:

MZ>On 11.10.2010 14:13, jazzer wrote:

>> Был вопрос про tcl/tk, я про это и отвечал, а не про все остальное, что ты здесь
>> перечислил.

MZ>Вообще-то вопрос был про GUI: "Best GUI for Windows C++ application"

Посмотри, пожалуйста, внимательно выше по ветке, на какое именно сообщение я отвечал, когда писал про tcl/tk.

>> Убог и не поддерживает юникод.
MZ>На счёт юникода. Подозреваю, что тебе зачем-то нужен UTF-16. Современные
MZ>тенденции -- уход от UTF-16 в сторону UTF-8. Его многий софт поддерживает.
Ну ладно бы поддерживать UTF-8 для внешних носителей (например файлы или сеть), но в чем вкусность работы с переменной шириной символа? Откуда такие тенденции и где?

On 12.10.2010 12:06, std.denis wrote:

> Ну ладно бы поддерживать UTF-8 для внешних носителей (например файлы или сеть),

А в чём проблема ?

> но в чем вкусность работы с переменной шириной символа? Откуда такие тенденции и
> где?

В UTF-16 символ тоже переменной ширины. Да только минимум занимает 2 байта, 1
байт лишний по сравнению с UTF-8.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, MasterZiv, Вы писали:

MZ> On 12.10.2010 12:06, std.denis wrote:

MZ> В UTF-16 символ тоже переменной ширины. Да только минимум занимает 2 байта, 1
MZ> байт лишний по сравнению с UTF-8.

Чтоб в UTF-16 символ занимал 4 байта нужно вылезти за BMP, а это довольно редкая ситуация. А, скажем, для кирилицы, что UTF-8, что UTF-16 все одно — 2 байта, только с UTF-16 работать удобнее

avalon 1.0rc3 rev 363, zlib 1.2.3

Здравствуйте, hattab, Вы писали:

Вдогонку

В UTF-8 только ASCII однобайтовые, все остальное больше.

avalon 1.0rc3 rev 363, zlib 1.2.3

Здравствуйте, MasterZiv, Вы писали:

MZ>Давай не мешать холодное с мягким. Если GUI используется стандартный,
MZ>и не понятно, то это -- просто плохой GUI. И всё. А если это ещё
MZ>и нестандартный GUI, то проблема уже в том, что он нестандартный.

Стандартный UI это CUA от IBM.
Все остальное — это custom решения отдельных фирм: MS, Apple, Gnome Foundation, Nokia.

Т.е. с точки зрения Apple — Gnome это плохой GUI. Был бы хороший — они бы взяли.

О чем вообще речь? Каждая ОСь это свой GUI. Каждая программа это тоже свой GUI по определению.
У кого-то хуже у кого-то лучше и опять же для кого-то.

Или народ хочет поспорить про вкусы? Субъективно это дело есмъ.
Объективным мерилом является объемы продаж и количество пользователей.
У скажем Windows или всего из себя нестандартного даже для Windows пакета Office их (пользователей) много.

Здравствуйте, Ytz, Вы писали:

CS>>При этом ты говоришь что браузеры должны использовать только UI системы (кстати каким UA ты пользуешься сам и почему?).

Ytz>Что такое UA?

UA это User Agent — так в GUI кругах называется программы доступа в сеть: Browser (термин MS), Navigator (термин NS) и т.д.

Т.е. вопрос состоит в том: чем ты лично "смотришь" Интернет? Например под Windows последний UA который использовал стандртный GUI OS был IE6. После него UA-строители поняли что это путь в никуда.

Кстати про UI. Maxthon v.3:

использует htmlayout UI. Кстати Maxthon (бывший MyIE) был первым UA который имел tabs. У них вообще очень грамотная GUI команда.

Здравствуйте, c-smile, Вы писали:

c> О чем вообще речь? Каждая ОСь это свой GUI. Каждая программа это тоже свой GUI по определению.

Опа. А гайдлайны для кого тогда?

c> У кого-то хуже у кого-то лучше и опять же для кого-то.

c> Или народ хочет поспорить про вкусы? Субъективно это дело есмъ.

Это не спор о вкусе, тут дело в принципе. Приложения ОС, должны следовать правилам которые устанавливает ОС, в том числе и по части гуя.

c> Объективным мерилом является объемы продаж и количество пользователей.
c> У скажем Windows или всего из себя нестандартного даже для Windows пакета Office их (пользователей) много.

Не является. К тому же нельзя сравнивать офис с его нестандартной цветовой схемой (диалоги, контролы более менее стандартно выглядят) более гладко вписывающей его в окружающую среду (я сейчас говорю о 2003 офисе, без этого чудо-юдо риббона) и гуй Нортона (предположим) не похожий вообще ни на что (ну кроме веба

avalon 1.0rc3 rev 363, zlib 1.2.3

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, c-smile, Вы писали:

c>> О чем вообще речь? Каждая ОСь это свой GUI. Каждая программа это тоже свой GUI по определению.

H>Опа. А гайдлайны для кого тогда?

Guideline это рекомендация:

By definition, following a guideline is never mandatory (protocol would be a better term for a mandatory procedure).

В Windows Phone 7 например уже отказываются от guidelines — даже HTC например свой desktop manager не может туда воткнуть — только в отдельном HUB.
Mobile GUI на самом деле это отдельная песня — но тем не менее.

c>> У кого-то хуже у кого-то лучше и опять же для кого-то.

c>> Или народ хочет поспорить про вкусы? Субъективно это дело есмъ.

H>Это не спор о вкусе, тут дело в принципе. Приложения ОС, должны следовать правилам которые устанавливает ОС, в том числе и по части гуя.

Ах ну да! Это принципиальный спор про вкусы

c>> Объективным мерилом является объемы продаж и количество пользователей.
c>> У скажем Windows или всего из себя нестандартного даже для Windows пакета Office их (пользователей) много.

H>Не является. К тому же нельзя сравнивать офис с его нестандартной цветовой схемой (диалоги, контролы более менее стандартно выглядят) более гладко вписывающей его в окружающую среду (я сейчас говорю о 2003 офисе, без этого чудо-юдо риббона) и гуй Нортона (предположим) не похожий вообще ни на что (ну кроме веба

).

У Нортона свои очень хорошие резоны иметь именно такой GUI. Во всяком случае меня их идеологи убедили.
Security настройки дело вельми скучное. В качестве одной из мотиваций хоум юзера следить за этим делом и есть те самые веселые картинки. Помимо всего прочего.

Здравствуйте, c-smile, Вы писали:

CS> Кстати Maxthon (бывший MyIE) был первым UA который имел tabs.

А разве не Opera?

Здравствуйте, c-smile, Вы писали:

c> H>Опа. А гайдлайны для кого тогда?

c> Guideline это рекомендация:
c>

c> By definition, following a guideline is never mandatory (protocol would be a better term for a mandatory procedure).

Ну дык понятно, что за несоответствие не покарают, но и значка заветного (кому важно) не дадут. А если бы у МС был свой аппстор (ну его нах, вообще-то), да с фейс-контролем...

c> В Windows Phone 7 например уже отказываются от guidelines — даже HTC например свой desktop manager не может туда воткнуть — только в отдельном HUB.
c> Mobile GUI на самом деле это отдельная песня — но тем не менее.

Тут, мне кажется, пример не совсем корректен, в то-то и дело, что у HTC свой десктоп. Понятное дело, что при столкновении двух разных идеологий одной из них придется уступить.

c> H>Это не спор о вкусе, тут дело в принципе. Приложения ОС, должны следовать правилам которые устанавливает ОС, в том числе и по части гуя.

c> Ах ну да! Это принципиальный спор про вкусы

Не-не, вы все не так понимаете

c> H>Не является. К тому же нельзя сравнивать офис с его нестандартной цветовой схемой (диалоги, контролы более менее стандартно выглядят) более гладко вписывающей его в окружающую среду (я сейчас говорю о 2003 офисе, без этого чудо-юдо риббона) и гуй Нортона (предположим) не похожий вообще ни на что (ну кроме веба

).

c> У Нортона свои очень хорошие резоны иметь именно такой GUI. Во всяком случае меня их идеологи убедили.
c> Security настройки дело вельми скучное. В качестве одной из мотиваций хоум юзера следить за этим делом и есть те самые веселые картинки. Помимо всего прочего.

Все может быть, и быть может подобные исключения таки оправданы, но общее правило оно всяко противоречит тезису "Каждая программа это тоже свой GUI по определению".

avalon 1.0rc3 rev 363, zlib 1.2.3

попробуй JUCE

http://www.rawmaterialsoftware.com

с исходниками и билдером проекта под Visual C++

все основано на векторной графике.
потрясная вещь.

Здравствуйте, c-smile, Вы писали:

CS>Здравствуйте, Ytz, Вы писали:

CS>>>При этом ты говоришь что браузеры должны использовать только UI системы (кстати каким UA ты пользуешься сам и почему?).

Ytz>>Что такое UA?

CS>UA это User Agent — так в GUI кругах называется программы доступа в сеть: Browser (термин MS), Navigator (термин NS) и т.д.

CS>Т.е. вопрос состоит в том: чем ты лично "смотришь" Интернет? Например под Windows последний UA который использовал стандртный GUI OS был IE6. После него UA-строители поняли что это путь в никуда.

Опять голословные утверждения.

CS>Кстати про UI. Maxthon v.3:
CS>

CS>использует htmlayout UI. Кстати Maxthon (бывший MyIE) был первым UA который имел tabs. У них вообще очень грамотная GUI команда.

Опять жуть, ну и вкус у тебя

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

P.S. Использую я Firefox 3.5 который ведет себя вполне адекватно: привычное меню, использование клавиши Alt и т.д.

Здравствуйте, c-smile, Вы писали:

CS>О чем вообще речь? Каждая ОСь это свой GUI. Каждая программа это тоже свой GUI по определению.

Откуда такое определение? Купил ты книгу почитать, а там последовательность страниц от конца к началу, оглавление посередине и буквы красные, потому как идеологи издательства решили, что это выделит их продукт. Доступно?

Здравствуйте, c-smile, Вы писали:

Ytz>>Что такое UA?

CS>UA это User Agent — так в GUI кругах называется программы доступа в сеть: Browser (термин MS), Navigator (термин NS) и т.д.

Сдается мне, что это либо ваш местечковый жаргон, либо ты опять врешь и выкручиваешься. Читал то хоть сам свою ссылку? Цитирую: "A user agent is a client application implementing a network protocol used in communications within a client–server distributed computing system.", где там про браузер? И в догонку:
1. Сайт Apple: "What is Safari? It’s a browser."
2. Сайт Mozilla: "Firefox web browser"
3. И даже http://browser.netscape.com/history, что уже само по себе намекает: "Netscape browser"

Здравствуйте, hattab, Вы писали:

MZ>> В UTF-16 символ тоже переменной ширины. Да только минимум занимает 2 байта, 1
MZ>> байт лишний по сравнению с UTF-8.

H>Чтоб в UTF-16 символ занимал 4 байта нужно вылезти за BMP, а это довольно редкая ситуация.

Что только усугубляет проблему, скрывая баги.

Здравствуйте, Ytz, Вы писали:

Ytz>Здравствуйте, c-smile, Вы писали:

Ytz>>>Что такое UA?

CS>>UA это User Agent — так в GUI кругах называется программы доступа в сеть: Browser (термин MS), Navigator (термин NS) и т.д.

Ytz>Сдается мне, что это либо ваш местечковый жаргон, либо ты опять врешь и выкручиваешься. Читал то хоть сам свою ссылку? Цитирую: "A user agent is a client application implementing a network protocol used in communications within a client–server distributed computing system.", где там про браузер? И в догонку:

Хоспидя... "врешь и выкручиваешься". Ну покажи какие-нибудь свои собственные проекты или хотя бы дай знать на кого работаешь чтобы у меня хотя бы намеки на мотивацию были это делать?

Ты так и не ответил каким browser ты лично пользуешься чтобы понять насколько ты честен в своем стремлении видеть сугубо стандартный UI.

В местечковый жаргоне спецификаций W3C принято употреблять термин User Agent: http://www.w3.org/TR/UAAG20/#def-user-agent

A user agent is any software that retrieves, renders and facilitates end user interaction with Web content.

Т.к. ваш покроный слуга является Invited Expert в W3C HTML5 Working Group то стараюсь использовать определения которые наиболее точно отображают суть процесса.

В конце концов все browsers (graphical user agents with user facing UIs) идентифицируют себя с пом. User-Agent поля в http запросах.

Здравствуйте, Тот кто сидит в пруду, Вы писали:

Т> MZ>> В UTF-16 символ тоже переменной ширины. Да только минимум занимает 2 байта, 1
Т> MZ>> байт лишний по сравнению с UTF-8.

Т> H>Чтоб в UTF-16 символ занимал 4 байта нужно вылезти за BMP, а это довольно редкая ситуация.

Т> Что только усугубляет проблему, скрывая баги.

Это вряд ли. Кто-то вообще не запаривается поддержкой UTF-16, довольствуясь UCS-2. Зато контролировать корректность строки в UTF-16 сильно проще нежели в UTF-8. В первом случае только корректность суррогата проверить, а во втором несколько вариантов последовательностей, плюс контроль непосредственно последовательности. Я к тому, что для обмена (да и то не всякого), UTF-8 хороша, но для внутренней работы либо UTF-16 (разумный компромисс), либо UTF-32 (значительный оверхед).

avalon 1.0rc3 rev 363, zlib 1.2.3

Здравствуйте, hattab, Вы писали:

H>Все может быть, и быть может подобные исключения таки оправданы, но общее правило оно всяко противоречит тезису "Каждая программа это тоже свой GUI по определению".

Ты сам программы писал? GUI у них делал? Или тырил чей-то готовый?

Если же делал сам то и GUI у них твой личный и ничей другой.

Я же привел пример своей собственной программулины по имени www.blocknote.net (в top 300 freeware на всякий случай) — самый что ни на есть стандарный GUI (причем intentionally) — печати негде ставить.
Но тем не менее и там нашлось место htmlayout. Ибо с ним "юзабильнее" получилось. Т.е. не квадратно-гнездовым методом, а там где именно надо.

Здравствуйте, c-smile, Вы писали:

c> H>Все может быть, и быть может подобные исключения таки оправданы, но общее правило оно всяко противоречит тезису "Каждая программа это тоже свой GUI по определению".

c> Ты сам программы писал? GUI у них делал? Или тырил чей-то готовый?

c> Если же делал сам то и GUI у них твой личный и ничей другой.

Гуй максимально по гайдлайнам

Понятное дело, что это гуй мой, спасибо кэп.

c> Я же привел пример своей собственной программулины по имени www.blocknote.net (в top 300 freeware на всякий случай) — самый что ни на есть стандарный GUI (причем intentionally) — печати негде ставить.
c> Но тем не менее и там нашлось место htmlayout. Ибо с ним "юзабильнее" получилось. Т.е. не квадратно-гнездовым методом, а там где именно надо.

Ты наверное думаешь, что критика нестандартного гуя это критика htmlayout? Это не так.

avalon 1.0rc3 rev 363, zlib 1.2.3

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, c-smile, Вы писали:

c>> H>Все может быть, и быть может подобные исключения таки оправданы, но общее правило оно всяко противоречит тезису "Каждая программа это тоже свой GUI по определению".

c>> Ты сам программы писал? GUI у них делал? Или тырил чей-то готовый?

c>> Если же делал сам то и GUI у них твой личный и ничей другой.

H>Гуй максимально по гайдлайнам

Понятное дело, что это гуй мой, спасибо кэп.

"Максимально" и есть ключевое слово. Т.е. что-то будет сделано не по инструкции, а именно по тому вот эта конкретная финтифлюшка здесь конкретно
удобнее и понятнее чем стандартное решение.

Скажем вот left side bar здесь: http://blocknote.net/images/screenshot.jpg это htmlayout с гиперлинками и folder view.
Ну нет никаких guidelines под это дело. Поэтому оно заведомо нестандартно. Далее tabs view документов. Ну нет guidelines на это дело хоть тресни.
Но есть три/четыре опять же нестандартных приложения (т.е. те что были первые) которые все остальные используют как образцы.
Кстати Norton UI используется как прототип всеми другими AV системами для дома. Во всяком случае на уровне структуры UI.
Я сам лично предпочел бы режим с переключением типа — for blondy/for geek — технически это легко сделать.
Но опять же я лично рублем за антивирусы не голосую поэтому мое мнение им до фени.

c>> Я же привел пример своей собственной программулины по имени www.blocknote.net (в top 300 freeware на всякий случай) — самый что ни на есть стандарный GUI (причем intentionally) — печати негде ставить.
c>> Но тем не менее и там нашлось место htmlayout. Ибо с ним "юзабильнее" получилось. Т.е. не квадратно-гнездовым методом, а там где именно надо.

H>Ты наверное думаешь, что критика нестандартного гуя это критика htmlayout? Это не так.

Да нет конечно ничего я такого не думаю. Есть куча всяко разных средств делать custom UI.

Также как и следуя этим самым guidelines можно наворотить такого что мало не покажется.

Есть приложения которым нужно выглядеть "конфеткой" и есть те котрым нужно выглядеть "стандартно". По тем или иным причинам.
Это все до одури очевидно поэтому я не понимаю откуда весь этот праведный гнев.

Здравствуйте, hattab, Вы писали:

Т>> H>Чтоб в UTF-16 символ занимал 4 байта нужно вылезти за BMP, а это довольно редкая ситуация.

Т>> Что только усугубляет проблему, скрывая баги.

H>Это вряд ли. Кто-то вообще не запаривается поддержкой UTF-16, довольствуясь UCS-2. Зато контролировать корректность строки в UTF-16 сильно проще нежели в UTF-8. В первом случае только корректность суррогата проверить, а во втором несколько вариантов последовательностей, плюс контроль непосредственно последовательности. Я к тому, что для обмена (да и то не всякого), UTF-8 хороша, но для внутренней работы либо UTF-16 (разумный компромисс), либо UTF-32 (значительный оверхед).

Скажем если говорить про Windows то UTF-16 это единственный способ там работать с unicode strings. Плохо или хорошо это уже до лампочки.
Важно что
1) он есть.
2) и если ты видишь сигнатуру функции то ты знаешь что от нее ожидать.

Скажем:

HANDLE WINAPI FindFirstFileW(
  __in   LPCWSTR lpFileName,
  __out  LPWIN32_FIND_DATA_W lpFindFileData
);

ясно что принимает unicode.

А вот скажем

DIR *opendir(const char *dirname);

она чего такое хочет в dirname ? UTF-8 или что?

Здравствуйте, roman313, Вы писали:

R>попробуй JUCE

R>http://www.rawmaterialsoftware.com

R>с исходниками и билдером проекта под Visual C++

R>все основано на векторной графике.
R>потрясная вещь.

Да, Juce написана хорошо. Единственная проблема со шрифтами — ClearType (и все остальные шрифтовые настройки пользователя) он игнорирует как класс.
Причем на всех платформах. По вполне понятным причинам.

Здравствуйте, artem_korneev, Вы писали:

_>Здравствуйте, c-smile, Вы писали:

CS>> Кстати Maxthon (бывший MyIE) был первым UA который имел tabs.

_>А разве не Opera?

Jeff Chen (CTO Maxthon) мне сказал что MyIE2 был первым c "настоящими" tabs. Что он при этом имел ввиду —

— за что купил — за то и продаю.

Во всяком случае не Opera это точно.

The tabbed interface approach was then followed by the Internet Explorer shell NetCaptor in 1997. These were followed by a number of others like IBrowse in 1999, and Opera in 2000 (with the release of version 4 — although a MDI interface was supported before then),

Отсюда: http://en.wikipedia.org/wiki/Tab_(GUI)

Вот история Opera: http://en.wikipedia.org/wiki/History_of_the_Opera_web_browser если кому интересно копаться.

Здравствуйте, c-smile, Вы писали:

CS>Хоспидя... "врешь и выкручиваешься". Ну покажи какие-нибудь свои собственные проекты или хотя бы дай знать на кого работаешь чтобы у меня хотя бы намеки на мотивацию были это делать?

А я все ждал, ждал

Я делал UI для Acronis True Image Echo, тоже надо сказать кастомную поделку на Fox Toolkit, поэтому о нестандартных интерфейсах знаю не понаслышке. Есть свой скромный проект на Qt здесь. Критикуй

CS>Ты так и не ответил каким browser ты лично пользуешься чтобы понять насколько ты честен в своем стремлении видеть сугубо стандартный UI.

Читать плохо умеешь или опять врешь? здесь

CS>В местечковый жаргоне спецификаций W3C принято употреблять термин User Agent: http://www.w3.org/TR/UAAG20/#def-user-agent
CS>

CS>A user agent is any software that retrieves, renders and facilitates end user interaction with Web content.

CS>Т.к. ваш покроный слуга является Invited Expert в W3C HTML5 Working Group то стараюсь использовать определения которые наиболее точно отображают суть процесса.

Я и говорю — жаргон местечковый, то что вы там в своих спецификациях пишете большинству людей дела нет. То что ты имеешь отношение к W3C помогло понять твою жаркую любовь к HTML в целом и HTML подобному UI в частности.

CS>В конце концов все browsers (graphical user agents with user facing UIs) идентифицируют себя с пом. User-Agent поля в http запросах.

Веб-роботы тоже себя идентифицируют с помощью User-Agent поля в http запросах, они тоже браузеры?

Здравствуйте, c-smile, Вы писали:

c> c>> Если же делал сам то и GUI у них твой личный и ничей другой.

c> H>Гуй максимально по гайдлайнам

Понятное дело, что это гуй мой, спасибо кэп.

c> "Максимально" и есть ключевое слово. Т.е. что-то будет сделано не по инструкции, а именно по тому вот эта конкретная финтифлюшка здесь конкретно
c> удобнее и понятнее чем стандартное решение.

В том-то и дело, если гайдлайн не описывает конкретную "финтифлюшку", тогда изобретаем свою. Но даже это делать нужно с оглядкой на рекомендации ОС, дабы не выбиваться из общего ряда стандартных контролов.

c> Скажем вот left side bar здесь: http://blocknote.net/images/screenshot.jpg это htmlayout с гиперлинками и folder view.
c> Ну нет никаких guidelines под это дело. Поэтому оно заведомо нестандартно. Далее tabs view документов. Ну нет guidelines на это дело хоть тресни.

Табы вполне себе стандартный элемент, то, что над ним издеваются в ситуациях, когда требуется переключение документов еще ничего не значит. Но опять же, я в самом начале говорил о допустимых девиациях, т.е. понятно, что то или иное решение принимается исходя из конкретной ситуации.

c> Есть приложения которым нужно выглядеть "конфеткой" и есть те котрым нужно выглядеть "стандартно". По тем или иным причинам.
c> Это все до одури очевидно поэтому я не понимаю откуда весь этот праведный гнев.

Праведный гнев от того, что приложениями обеспечивающими безопасность, в частности, становится невозможно пользоваться. Мне как то пришлось знакомым настраивать лицензионный Avast (кажется), так я проклял всех гуй-дизайнеров на свете. Пока настроишь режим работы монитора, обновлений, оповещений с ума сойти можно, от вырвиглазия лезущего из каждой щели. Это мне напомнило "умом нужно выделяться"

avalon 1.0rc3 rev 363, zlib 1.2.3

Здравствуйте, Аноним, Вы писали:

А>Нужно написать приложение с интенсивным использованием GUI: нестандартные формочки, к примеру, как у Java SWT (Eclipse), а также генерированием графиков (нормальное распределение, etc.)
А>Что серъезное посоветуете: Qt, MFC, etc.?

http://ultimatepp.org/ -- просто и сердито.

Здравствуйте, Ytz, Вы писали:

Ytz>Здравствуйте, c-smile, Вы писали:

CS>>О чем вообще речь? Каждая ОСь это свой GUI. Каждая программа это тоже свой GUI по определению.

Ytz>Откуда такое определение? Купил ты книгу почитать, а там последовательность страниц от конца к началу, оглавление посередине и буквы красные, потому как идеологи издательства решили, что это выделит их продукт. Доступно?
Ну пусть выделяют, я просто не куплю их книгу

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, MasterZiv, Вы писали:

>> Не дружит с приложениями, читающими из окон приложения (а-ля Lingvo).

MZ>Это как ? можно подробнее ? А то не понятно.

Lingvo может переводить при тычке мышью в любой элемент интерфейса, в котором есть текст (если держать хоткей типа Alt, но не суть).
Так вот, поскольку в Qt виджеты рисуются без привлечения виндовых контролов, Lingvo не может получить текст из кутишных виджетов (подозреваю, что там используется что-то типа FindWindowFromPoint/GetWindowText).

>> Убог и не поддерживает юникод.

MZ>На счёт юникода. Подозреваю, что тебе зачем-то нужен UTF-16. Современные
MZ>тенденции -- уход от UTF-16 в сторону UTF-8. Его многий софт поддерживает.

UTF-8 — сомнительная радость. Да, он позволяет работать с юникодом как с обычными строчками, но все равно придется модифицировать программу, чтобы она заработала с юникодом корректно:

— Разбить UTF-8 строку в любом месте нельзя: если разбить ее посреди многобайтового символа, получится лажа.

— Придется очень-очень постараться, чтобы корректно посчитать число реальных символов в строке (скажем, чтобы текст выравнивать по ширине страницы). Если считать тупо байты, то русский текст будет в два раза уже, чем английский.

— Мы-то знаем, что в строке UTF-8, а вот операционная система и рантайм-библиотека — не в курсе. А это значит, что придется дополнительно перекодировать из UTF-8 в UCS-2 и обратно при обращении к операционной системе. Заметим, что можно перекодировать и в cтроку char'ов в локальной кодировке, но тогда неизбежна путаница и труднооборимые глюки.

Посему считаю очень правильным подход, примененный в Qt и wxWidgets: вся работа со строками ведется только с юникодом (безо всяких UTF), а уже когда понадобится char* — перекодируем из юникода осознанно.

Здравствуйте, Аноним, Вы писали:

А>UTF-8 — сомнительная радость. Да, он позволяет работать с юникодом как с обычными строчками, но все равно придется модифицировать программу, чтобы она заработала с юникодом корректно:
А>- Разбить UTF-8 строку в любом месте нельзя: если разбить ее посреди многобайтового символа, получится лажа.
А зачем это делать? Разбиение по всяким стандартным разделителям (' ', ',', ';'...) работает нормально.

А>- Придется очень-очень постараться, чтобы корректно посчитать число реальных символов в строке (скажем, чтобы текст выравнивать по ширине страницы). Если считать тупо байты, то русский текст будет в два раза уже, чем английский.
А вот за такой "рассчёт размера" (т.е. "ширина страницы / размер символа") я бы избивал железной трубой. Для правильного выравнивания текста подсчёт длины UTF-8 строки будет такой мизерной частью кода, что просто смешно.

А>- Мы-то знаем, что в строке UTF-8, а вот операционная система и рантайм-библиотека — не в курсе.
А нафиг им это знать?

А>А это значит, что придется дополнительно перекодировать из UTF-8 в UCS-2 и обратно при обращении к операционной системе. Заметим, что можно перекодировать и в cтроку char'ов в локальной кодировке, но тогда неизбежна путаница и труднооборимые глюки.
Зачем?

А>Посему считаю очень правильным подход, примененный в Qt и wxWidgets: вся работа со строками ведется только с юникодом (безо всяких UTF), а уже когда понадобится char* — перекодируем из юникода осознанно.
С каким "юникодом"? UCS-4?

Лучший С++ GUI под винду — это моя libSWL. Полностью windowless framework на который можно навешивать "разметочные" DSL. Стили контролов описываются отдельно от кода на s-expr.

Может когда-нибудь руки дойдут сделаю ее опен-сорс.

Вот причмерчик того что я на ней делаю (еще сырой вариант):

Здравствуйте, Cyberax, Вы писали:

А>>- Разбить UTF-8 строку в любом месте нельзя: если разбить ее посреди многобайтового символа, получится лажа.
C>А зачем это делать? Разбиение по всяким стандартным разделителям (' ', ',', ';'...) работает нормально.

Не согласен, т.к. это зависит от задачи.
Если задача стоит порезать строку на куски определенного размера (простейший пример — для какого-нибудь текст-ориентированного протокола), то резьба по разделителям не нужна и даже вредна.

А>>- Придется очень-очень постараться, чтобы корректно посчитать число реальных символов в строке (скажем, чтобы текст выравнивать по ширине страницы). Если считать тупо байты, то русский текст будет в два раза уже, чем английский.
C>А вот за такой "рассчёт размера" (т.е. "ширина страницы / размер символа") я бы избивал железной трубой.

Это твои личные переживания или есть какое-то обоснование?

C>Для правильного выравнивания текста подсчёт длины UTF-8 строки будет такой мизерной частью кода, что просто смешно.

Зависит от.
Если не стоит задача нарисовать свой ворд, разбивка строки на кусочки нужного размера — это 90% всех задач по форматированию текста.

К примеру, багзилла старых версий выводила русский текст в комментариях к багу весьма по-уродски именно потому, что обрабатывала UTF-8 как обычный ASCII.

А>>- Мы-то знаем, что в строке UTF-8, а вот операционная система и рантайм-библиотека — не в курсе.
C>А нафиг им это знать?

Затем, чтобы использовать ту же кириллицу
Скорми русское имя файла в UTF-8 под виндой функции CreateFileA() (или fopen(), или классу std::ofstream ) и удивись.

А>>А это значит, что придется дополнительно перекодировать из UTF-8 в UCS-2 и обратно при обращении к операционной системе. Заметим, что можно перекодировать и в cтроку char'ов в локальной кодировке, но тогда неизбежна путаница и труднооборимые глюки.
C>Зачем?

Затем, чтобы не появлялось удивительных ошибок, когда файл вроде бы есть, а открыть мы его не можем.
Или когда пишем вроде бы в файл "вася.txt", а на диске создается "РеРеРеРе.txt".

А>>Посему считаю очень правильным подход, примененный в Qt и wxWidgets: вся работа со строками ведется только с юникодом (безо всяких UTF), а уже когда понадобится char* — перекодируем из юникода осознанно.
C>С каким "юникодом"? UCS-4?

Для меня как для пользователя библиотеки абсолютно не важно, какой конкретно вариант представления выберут разработчики. Вполне допускаю, что там может и не пахнуть правоверным юникодом.

Основное, что я ожидаю — это то, что
а) его можно легко (средствами библиотеки) перекодировать в тот же UCS-4, UCS-2, UTF-8 или локальную 8-битовую кодировку (в пределах разумного), и
б) один "юникодный" символ соответствует одному "печатному" символу.

Здравствуйте, Аноним, Вы писали:

А>>>- Разбить UTF-8 строку в любом месте нельзя: если разбить ее посреди многобайтового символа, получится лажа.
C>>А зачем это делать? Разбиение по всяким стандартным разделителям (' ', ',', ';'...) работает нормально.
А>Не согласен, т.к. это зависит от задачи.
Что зависит?

А>Если задача стоит порезать строку на куски определенного размера (простейший пример — для какого-нибудь текст-ориентированного протокола), то резьба по разделителям не нужна и даже вредна.
Какой "текст-ориентированный протокол" ещё? Если нужно резать на байты — это уже не "текст-ориентированный" протокол, а совсем уж бинарный.

В прошлом флейме никто не привёл реальных примеров из своей практики зачем нужна адресация посимвольно в utf-8 строке.

C>>А вот за такой "рассчёт размера" (т.е. "ширина страницы / размер символа") я бы избивал железной трубой.
А>Это твои личные переживания или есть какое-то обоснование?

Оно будет криво работать со всеми языками со сложным написанием букв.

C>>Для правильного выравнивания текста подсчёт длины UTF-8 строки будет такой мизерной частью кода, что просто смешно.
А>Зависит от.
А>Если не стоит задача нарисовать свой ворд, разбивка строки на кусочки нужного размера — это 90% всех задач по форматированию текста.

Мимо. Даже в задаче "вывести строку" большая часть сложности — это обработка символов сложного начертания, композитных символов, кернинга и т.п.

"Разбивка на строки" — это такая ерунда.

А>К примеру, багзилла старых версий выводила русский текст в комментариях к багу весьма по-уродски именно потому, что обрабатывала UTF-8 как обычный ASCII.
Зачем ей обрабатывать его?

А>>>- Мы-то знаем, что в строке UTF-8, а вот операционная система и рантайм-библиотека — не в курсе.
C>>А нафиг им это знать?
А>Затем, чтобы использовать ту же кириллицу
А>Скорми русское имя файла в UTF-8 под виндой функции CreateFileA() (или fopen(), или классу std::ofstream ) и удивись.
Винда — это уродец. В Линуксе всё прекрасно работает fopen("Русское Имя") (текст в utf-8) прекрасно откроет файл с таким именем, вне зависимости от кодировки системы.

А>>>А это значит, что придется дополнительно перекодировать из UTF-8 в UCS-2 и обратно при обращении к операционной системе. Заметим, что можно перекодировать и в cтроку char'ов в локальной кодировке, но тогда неизбежна путаница и труднооборимые глюки.
C>>Зачем?
А>Затем, чтобы не появлялось удивительных ошибок, когда файл вроде бы есть, а открыть мы его не можем.
А>Или когда пишем вроде бы в файл "вася.txt", а на диске создается "РеРеРеРе.txt".
Странно. У меня таких ошибок нет. ЧЯДНТ?

C>>С каким "юникодом"? UCS-4?
А>Для меня как для пользователя библиотеки абсолютно не важно, какой конкретно вариант представления выберут разработчики. Вполне допускаю, что там может и не пахнуть правоверным юникодом.
До тех пор, пока твоим пользователям не потребуются символы не из BMP.

А>Основное, что я ожидаю — это то, что
А>а) его можно легко (средствами библиотеки) перекодировать в тот же UCS-4, UCS-2, UTF-8 или локальную 8-битовую кодировку (в пределах разумного), и
utf-8

А>б) один "юникодный" символ соответствует одному "печатному" символу.
Такого нет, и не может быть в принципе.

Здравствуйте, Cyberax, Вы писали:

А>>б) один "юникодный" символ соответствует одному "печатному" символу.
C>Такого нет, и не может быть в принципе.

Шо, и для UCS-32 тоже?

Здравствуйте, Kluev, Вы писали:

А>>>б) один "юникодный" символ соответствует одному "печатному" символу.
C>>Такого нет, и не может быть в принципе.
K>Шо, и для UCS-32 тоже?
Да. Есть композитные символы, и алфавиты со сложным начертанием.

Здравствуйте, Cyberax, Вы писали:

C>>>Для правильного выравнивания текста подсчёт длины UTF-8 строки будет такой мизерной частью кода, что просто смешно.
А>>Зависит от.
А>>Если не стоит задача нарисовать свой ворд, разбивка строки на кусочки нужного размера — это 90% всех задач по форматированию текста.

C>Мимо. Даже в задаче "вывести строку" большая часть сложности — это обработка символов сложного начертания, композитных символов, кернинга и т.п.
Для всего этого библиотеки соответ. есть: uniscribe, gtk

C>"Разбивка на строки" — это такая ерунда.
не совсем: http://en.wikipedia.org/wiki/Word_wrap
хотя gtk вроде и это делать умеет.

Здравствуйте, Kluev, Вы писали:

K>Здравствуйте, Cyberax, Вы писали:

А>>>б) один "юникодный" символ соответствует одному "печатному" символу.
C>>Такого нет, и не может быть в принципе.

K>Шо, и для UCS-32 тоже?
Увы и для UCS-32 тоже. Потому что http://unicode.org/glossary/ :

Glyph. (1) An abstract form that represents one or more glyph images. (2) A synonym for glyph image. In displaying Unicode character data, one or more glyphs may be selected to depict a particular character. These glyphs are selected by a rendering engine during composition and layout processing. (See also character.)

Здравствуйте, alsemm, Вы писали:

А>>>Если не стоит задача нарисовать свой ворд, разбивка строки на кусочки нужного размера — это 90% всех задач по форматированию текста.

C>>Мимо. Даже в задаче "вывести строку" большая часть сложности — это обработка символов сложного начертания, композитных символов, кернинга и т.п.
A>Для всего этого библиотеки соответ. есть: uniscribe, gtk
HarfBuzz и т.п. Да, естественно.

C>>"Разбивка на строки" — это такая ерунда.
A>не совсем: http://en.wikipedia.org/wiki/Word_wrap
A>хотя gtk вроде и это делать умеет.
Я имею в виду разбивку по границам utf-8 code point'ов.

Здравствуйте, Cyberax, Вы писали:

А>>>>- Разбить UTF-8 строку в любом месте нельзя: если разбить ее посреди многобайтового символа, получится лажа.
C>>>А зачем это делать? Разбиение по всяким стандартным разделителям (' ', ',', ';'...) работает нормально.
А>>Не согласен, т.к. это зависит от задачи.
C>Что зависит?

От задачи зависит, допустимо ли разбиение по разделителям, или же требуется разбиение по печатным символам.
Так понятнее?

А>>Если задача стоит порезать строку на куски определенного размера (простейший пример — для какого-нибудь текст-ориентированного протокола), то резьба по разделителям не нужна и даже вредна.

C>Какой "текст-ориентированный протокол" ещё? Если нужно резать на байты — это уже не "текст-ориентированный" протокол, а совсем уж бинарный.

Текст, в отличие от бинарных протоколов, оперирует символами, а не байтами. Надеюсь, разница между ними понятна?

C>В прошлом флейме никто не привёл реальных примеров из своей практики зачем нужна адресация посимвольно в utf-8 строке.

Без примеров вы не согласны понять, о чем речь?

Хорошо, приведу пример из практики: разбивка заголовка письма (RFC822 et al) на строки, не превышающие 80 символов длиной.
Алгоритм примерно такой (несущественные детали опущены):
— рубим строку на байты длины N такой, чтобы length( base64( кусок ) ) < 80
— каждый кусок кодируется в base64 отдельно.

Так вот, если строку порезать посредине символа UTF-8, в большинстве почтовых клиентов заголовок письма отобразится криво.

Это хороший пример?

C>>>А вот за такой "рассчёт размера" (т.е. "ширина страницы / размер символа") я бы избивал железной трубой.
А>>Это твои личные переживания или есть какое-то обоснование?

C>Оно будет криво работать со всеми языками со сложным написанием букв.

Если внутреннее представление библиотеки не допускает сложных написаний букв, оно будет работать прямо.
Никто ведь не утверждает, что внутри библиотеки хранится правоверный UNICODE.

C>>>Для правильного выравнивания текста подсчёт длины UTF-8 строки будет такой мизерной частью кода, что просто смешно.
А>>Зависит от.
А>>Если не стоит задача нарисовать свой ворд, разбивка строки на кусочки нужного размера — это 90% всех задач по форматированию текста.

C>Мимо. Даже в задаче "вывести строку" большая часть сложности — это обработка символов сложного начертания, композитных символов, кернинга и т.п.

Открою страшную тайну: задача "вывести строку" в 99% случаев заключается в установке свойства text у какого-нибудь контрола или виджета.

C>"Разбивка на строки" — это такая ерунда.

Да, согласен.
Но при наличии UTF8 она становится нетривиальной и требует или привлечения специальных библиотек, или сакральных знаний о битовом устройстве UTF8.

А>>К примеру, багзилла старых версий выводила русский текст в комментариях к багу весьма по-уродски именно потому, что обрабатывала UTF-8 как обычный ASCII.
C>Зачем ей обрабатывать его?

Пример не понят, потому что недостаточно понятен? Или, может, потому что Анонимус заведомо говорит пургу?

Багзилла выводит комментарии к багу внутри тега <pre>, чтобы форматирование кода не расползалось.
При этом слишком длинные строки заворачиваются, чтобы не приходилось скроллить страницу влево-вправо при просмотре.

А>>>>- Мы-то знаем, что в строке UTF-8, а вот операционная система и рантайм-библиотека — не в курсе.
C>>>А нафиг им это знать?
А>>Затем, чтобы использовать ту же кириллицу
А>>Скорми русское имя файла в UTF-8 под виндой функции CreateFileA() (или fopen(), или классу std::ofstream ) и удивись.
C>Винда — это уродец. В Линуксе всё прекрасно работает fopen("Русское Имя") (текст в utf-8) прекрасно откроет файл с таким именем, вне зависимости от кодировки системы.

Спасибо, добрый человек, ты открыл глаза человечеству.

Вот только одно "но": тема посвящена гую именно под Windows, поэтому откровения немного не в кассу. Как вы говорите, "мимо".

А>>>>А это значит, что придется дополнительно перекодировать из UTF-8 в UCS-2 и обратно при обращении к операционной системе. Заметим, что можно перекодировать и в cтроку char'ов в локальной кодировке, но тогда неизбежна путаница и труднооборимые глюки.
C>>>Зачем?
А>>Затем, чтобы не появлялось удивительных ошибок, когда файл вроде бы есть, а открыть мы его не можем.
А>>Или когда пишем вроде бы в файл "вася.txt", а на диске создается "РеРеРеРе.txt".
C>Странно. У меня таких ошибок нет. ЧЯДНТ?

Дайте догадаюсь. Линукс?

C>>>С каким "юникодом"? UCS-4?
А>>Для меня как для пользователя библиотеки абсолютно не важно, какой конкретно вариант представления выберут разработчики. Вполне допускаю, что там может и не пахнуть правоверным юникодом.
C>До тех пор, пока твоим пользователям не потребуются символы не из BMP.

Как часто они нужны?

Еще раз повторю: там может и не пахнуть правоверным юникодом.
А значит, разработчики могут кодировать и символы со сложным написанием, и не-ВМР символы как считают нужным. Меня интересует результат.

А>>Основное, что я ожидаю — это то, что
А>>а) его можно легко (средствами библиотеки) перекодировать в тот же UCS-4, UCS-2, UTF-8 или локальную 8-битовую кодировку (в пределах разумного), и
C>utf-8

Не спешите.

А>>б) один "юникодный" символ соответствует одному "печатному" символу.
C>Такого нет, и не может быть в принципе.

"Потому что не может быть никогда", да?

Здравствуйте, Аноним, Вы писали:

C>>Что зависит?
А>От задачи зависит, допустимо ли разбиение по разделителям, или же требуется разбиение по печатным символам.
А>Так понятнее?
Нет.

А>>>Если задача стоит порезать строку на куски определенного размера (простейший пример — для какого-нибудь текст-ориентированного протокола), то резьба по разделителям не нужна и даже вредна.
C>>Какой "текст-ориентированный протокол" ещё? Если нужно резать на байты — это уже не "текст-ориентированный" протокол, а совсем уж бинарный.
А>Текст, в отличие от бинарных протоколов, оперирует символами, а не байтами. Надеюсь, разница между ними понятна?
Нет.

Разницу между глифом, code point'ом, символом и байтом знаем?

C>>В прошлом флейме никто не привёл реальных примеров из своей практики зачем нужна адресация посимвольно в utf-8 строке.
А>Без примеров вы не согласны понять, о чем речь?

Да.

А>Так вот, если строку порезать посредине символа UTF-8, в большинстве почтовых клиентов заголовок письма отобразится криво.
А>Это хороший пример?
Плохой. Так как такой алгоритм не будет работать нормально с арабским. Правильно — это разбить строку на runs по границам слов или глифов.

C>>Оно будет криво работать со всеми языками со сложным написанием букв.
А>Если внутреннее представление библиотеки не допускает сложных написаний букв, оно будет работать прямо.
Учи матчасть: http://en.wikipedia.org/wiki/Complex_scripts и http://en.wikipedia.org/wiki/Unicode#Ready-made_versus_composite_characters Скажем, шрифты с RTL встречаются крайне часто.

С композитными символами можно побороться нормализацией (со своими проблемами), но вот со сложным начертанием простых способов уже нет. И в обоих случаях нафиг не нужна посимвольная адресация.

А>>>Если не стоит задача нарисовать свой ворд, разбивка строки на кусочки нужного размера — это 90% всех задач по форматированию текста.

C>>Мимо. Даже в задаче "вывести строку" большая часть сложности — это обработка символов сложного начертания, композитных символов, кернинга и т.п.
А>Открою страшную тайну: задача "вывести строку" в 99% случаев заключается в установке свойства text у какого-нибудь контрола или виджета.
Да. И поэтому тут нафиг не нужна посимвольная адресация.

C>>"Разбивка на строки" — это такая ерунда.
А>Да, согласен.
А>Но при наличии UTF8 она становится нетривиальной и требует или привлечения специальных библиотек, или сакральных знаний о битовом устройстве UTF8.
Ничуть. Всё делается элементарно, даже с UTF-8.

А>>>К примеру, багзилла старых версий выводила русский текст в комментариях к багу весьма по-уродски именно потому, что обрабатывала UTF-8 как обычный ASCII.
C>>Зачем ей обрабатывать его?
А>Пример не понят, потому что недостаточно понятен? Или, может, потому что Анонимус заведомо говорит пургу?

Да. Да.

А>Багзилла выводит комментарии к багу внутри тега <pre>, чтобы форматирование кода не расползалось.
А>При этом слишком длинные строки заворачиваются, чтобы не приходилось скроллить страницу влево-вправо при просмотре.
Ну так делим по границе слов (по пробелам, запятым и т.п.) и вставляем crlf. Будет прекрасно работать с utf-8.

C>>Винда — это уродец. В Линуксе всё прекрасно работает fopen("Русское Имя") (текст в utf-8) прекрасно откроет файл с таким именем, вне зависимости от кодировки системы.
А>Спасибо, добрый человек, ты открыл глаза человечеству.
Ага.

C>>До тех пор, пока твоим пользователям не потребуются символы не из BMP.
А>Как часто они нужны?

Бывают. Там много полезных символов есть (некоторые символы валют, к примеру).

А>Еще раз повторю: там может и не пахнуть правоверным юникодом.
А>А значит, разработчики могут кодировать и символы со сложным написанием, и не-ВМР символы как считают нужным. Меня интересует результат.
Так, непонимание Unicode detected.

А>>>б) один "юникодный" символ соответствует одному "печатному" символу.
C>>Такого нет, и не может быть в принципе.
А>"Потому что не может быть никогда", да?

Именно. Читай стандарт.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Аноним, Вы писали:

C>>>Что зависит?
А>>От задачи зависит, допустимо ли разбиение по разделителям, или же требуется разбиение по печатным символам.
А>>Так понятнее?
C>Нет.

Боюсь, тогда я помочь ничем не смогу.

А>>>>Если задача стоит порезать строку на куски определенного размера (простейший пример — для какого-нибудь текст-ориентированного протокола), то резьба по разделителям не нужна и даже вредна.
C>>>Какой "текст-ориентированный протокол" ещё? Если нужно резать на байты — это уже не "текст-ориентированный" протокол, а совсем уж бинарный.
А>>Текст, в отличие от бинарных протоколов, оперирует символами, а не байтами. Надеюсь, разница между ними понятна?
C>Нет.

Сожалею.

C>Разницу между глифом, code point'ом, символом и байтом знаем?

Понт защитан.

C>>>В прошлом флейме никто не привёл реальных примеров из своей практики зачем нужна адресация посимвольно в utf-8 строке.
А>>Без примеров вы не согласны понять, о чем речь?

C>Да.

Тогда, может быть, и не надо?

А>>Так вот, если строку порезать посредине символа UTF-8, в большинстве почтовых клиентов заголовок письма отобразится криво.
А>>Это хороший пример?
C>Плохой. Так как такой алгоритм не будет работать нормально с арабским. Правильно — это разбить строку на runs по границам слов или глифов.

То есть для вас приведенный мной пример никак не иллюстрирует проблему разбиения UTF-8 строки?

Печально.

C>>>Оно будет криво работать со всеми языками со сложным написанием букв.
А>>Если внутреннее представление библиотеки не допускает сложных написаний букв, оно будет работать прямо.
C>Учи матчасть: http://en.wikipedia.org/wiki/Complex_scripts и http://en.wikipedia.org/wiki/Unicode#Ready-made_versus_composite_characters Скажем, шрифты с RTL встречаются крайне часто.

Я так понимаю, ради этого момента истины вы и затеяли сей беспредметный спор?

C>С композитными символами можно побороться нормализацией (со своими проблемами), но вот со сложным начертанием простых способов уже нет. И в обоих случаях нафиг не нужна посимвольная адресация.

Опять-таки, зависит от задачи.
Если речь идет о том, чтобы текст правильно отобразился — это одно.
Если же задача состоит в правильном промежуточном преобразовании текста так, чтобы с другой стороны его смогли корректно преобразовать в правильный юникод — это другое.
Если задача состоит в том, чтобы текст не превратился в нечитаемый — это совсем третье.

Впрочем, раз вы отказываетесь понимать о чем речь — спор становится беспредметным.

C>>>"Разбивка на строки" — это такая ерунда.
А>>Да, согласен.
А>>Но при наличии UTF8 она становится нетривиальной и требует или привлечения специальных библиотек, или сакральных знаний о битовом устройстве UTF8.

C>Ничуть. Всё делается элементарно, даже с UTF-8.

Поделитесь сакральным знанием — как же это делается?

А>>Багзилла выводит комментарии к багу внутри тега <pre>, чтобы форматирование кода не расползалось.
А>>При этом слишком длинные строки заворачиваются, чтобы не приходилось скроллить страницу влево-вправо при просмотре.
C>Ну так делим по границе слов (по пробелам, запятым и т.п.) и вставляем crlf. Будет прекрасно работать с utf-8.

Пока не встретится строка длиной этак в пару килобайт без пробелов, запятых и т. п. А встретится она буквально сразу же — бывали-с случаи.

А>>Еще раз повторю: там может и не пахнуть правоверным юникодом.
А>>А значит, разработчики могут кодировать и символы со сложным написанием, и не-ВМР символы как считают нужным. Меня интересует результат.
C>Так, непонимание Unicode detected.

На фоне вашего нарочитого непонимания примеров моя легкая путаница — просто рай.

А>>>>б) один "юникодный" символ соответствует одному "печатному" символу.
C>>>Такого нет, и не может быть в принципе.
А>>"Потому что не может быть никогда", да?

C>Именно. Читай стандарт.

Стандарт я читал, спасибо. Давненько, правда.

Разговор идет не об абстрактных юникодах в вакууме, а о практическом применении юникода в гуевых фреймворках под Windows.
Посему:
— ваши разглагольствования о красоте линукса немного не в тему;
— в реальной жизни под виндой UTF8 неудобен именно из-за своей похожести на текст в локальной восьмибитной кодировке, а его использование часто приводит к ошибкам типа "забыли перекодировать в win1251" и "перекодировали дважды";
— обработка строк в формате UTF8 частенько требует знания о формате кодирования в UTF, чтобы можно было хотя бы находить границы символов. При использовании строк а-ля QString или wxString (с многобайтовым представлением символов внутри) границы искать уже не надо;
— применение к любой юникодной кодировке (и utf8 тоже) некоторых алгоритмов приведет к проблемам с символами со сложным написанием. Но универсального решения тут нет — в зависимости от задачи мы или будем резать текст по разделителям слов, или смиримся с вероятностью того, что "хитрый" текст может слегка подпортиться.

Итого: utf-8 не дает никаких преимуществ по сравнению с многобайтовыми строками, но имеет пару специфических проблем.

Да, и напоследок: реальные программные проекты не пишутся под сферического клиента в вакууме. В большинстве случаев вполне достаточно поддержки латиницы, западноевропейских языков и (иногда) кириллицы. Языки с RTL написанием или со сложными глифами, скорее всего, потребуют специальной адаптации гуя, а это уже отдельный разговор.

Здравствуйте, Аноним, Вы писали:

C>>Разницу между глифом, code point'ом, символом и байтом знаем?

А>Понт защитан.
Невежество атакуе

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

А>Впрочем, раз вы отказываетесь понимать о чем речь — спор становится беспредметным.
Я тоже не понимаю о чем речь. Кто такой "правильный юникод"?

А>Разговор идет не об абстрактных юникодах в вакууме, а о практическом применении юникода в гуевых фреймворках под Windows.
А>Посему:
А>- ваши разглагольствования о красоте линукса немного не в тему;
А>- в реальной жизни под виндой UTF8 неудобен именно из-за своей похожести на текст в локальной восьмибитной кодировке, а его использование часто приводит к ошибкам типа "забыли перекодировать в win1251" и "перекодировали дважды";
На винде UTF16 удобнее только тем, что виндовый API его понимает без дополнительных преобразований. Кстати, UTF16 в винде только с Win2000, до этого она понимала только UCS2.

А>- обработка строк в формате UTF8 частенько требует знания о формате кодирования в UTF, чтобы можно было хотя бы находить границы символов. При использовании строк а-ля QString или wxString (с многобайтовым представлением символов внутри) границы искать уже не надо;
Это было верно для Unicode 2.0. Потом появились surrogate pairs и привет.

А>- применение к любой юникодной кодировке (и utf8 тоже) некоторых алгоритмов приведет к проблемам с символами со сложным написанием. Но универсального решения тут нет — в зависимости от задачи мы или будем резать текст по разделителям слов, или смиримся с вероятностью того, что "хитрый" текст может слегка подпортиться.
"хитрый" текст надо отдавать на анализ спец. библиотеке, чтобы она сказала, где строку можно разбивать, а где нельзя. На десктопной винде очевидный выбор — это uniscribe, ScriptStringAnalyse.

Здравствуйте, Аноним, Вы писали:

C>>>>Что зависит?
А>>>От задачи зависит, допустимо ли разбиение по разделителям, или же требуется разбиение по печатным символам.
А>>>Так понятнее?
C>>Нет.
А>Боюсь, тогда я помочь ничем не смогу.

Т.е. реальных разумных примеров зачем нужна посимвольная произвольная адресация — я так и не увижу, как обычно.

А>>>Так вот, если строку порезать посредине символа UTF-8, в большинстве почтовых клиентов заголовок письма отобразится криво.
А>>>Это хороший пример?
C>>Плохой. Так как такой алгоритм не будет работать нормально с арабским. Правильно — это разбить строку на runs по границам слов или глифов.
А>То есть для вас приведенный мной пример никак не иллюстрирует проблему разбиения UTF-8 строки?

Совершенно не иллюстрирует. Ибо приведённое решение с произвольной адресацией — кривое.

C>>Учи матчасть: http://en.wikipedia.org/wiki/Complex_scripts и http://en.wikipedia.org/wiki/Unicode#Ready-made_versus_composite_characters Скажем, шрифты с RTL встречаются крайне часто.
А>Я так понимаю, ради этого момента истины вы и затеяли сей беспредметный спор?

Собственно, я с самого начала писал, что с символами вообще всё не так уж просто.

C>>С композитными символами можно побороться нормализацией (со своими проблемами), но вот со сложным начертанием простых способов уже нет. И в обоих случаях нафиг не нужна посимвольная адресация.
А>Опять-таки, зависит от задачи.
Задачи — в студию.

А>Впрочем, раз вы отказываетесь понимать о чем речь — спор становится беспредметным.
Точно, никаких конкретных примеров, одни слова про текстовые редакторы и промежуточные преобразования.

А>>>Но при наличии UTF8 она становится нетривиальной и требует или привлечения специальных библиотек, или сакральных знаний о битовом устройстве UTF8.
C>>Ничуть. Всё делается элементарно, даже с UTF-8.
А>Поделитесь сакральным знанием — как же это делается?

Выравнивание по границам символа — примерно 3 строки кода.

C>>Ну так делим по границе слов (по пробелам, запятым и т.п.) и вставляем crlf. Будет прекрасно работать с utf-8.
А>Пока не встретится строка длиной этак в пару килобайт без пробелов, запятых и т. п. А встретится она буквально сразу же — бывали-с случаи.
Ну делишь по границам символа тогда.

А>>>Еще раз повторю: там может и не пахнуть правоверным юникодом.
А>>>А значит, разработчики могут кодировать и символы со сложным написанием, и не-ВМР символы как считают нужным. Меня интересует результат.
C>>Так, непонимание Unicode detected.
А>На фоне вашего нарочитого непонимания примеров моя легкая путаница — просто рай.

Так нет примеров-то.

А>Разговор идет не об абстрактных юникодах в вакууме, а о практическом применении юникода в гуевых фреймворках под Windows.
А>Посему:
А>- ваши разглагольствования о красоте линукса немного не в тему;
В тему, как пример правильного использования utf-8.

А>- в реальной жизни под виндой UTF8 неудобен именно из-за своей похожести на текст в локальной восьмибитной кодировке, а его использование часто приводит к ошибкам типа "забыли перекодировать в win1251" и "перекодировали дважды";
Какой, (непечатно), win-1251?!?! В виндовых программах нужны ровно _две_ кодировки: UCS-2 и utf-8. Все локальные однобайтовые кодовые страницы — максимум для импорта legacy-данных.

А>- обработка строк в формате UTF8 частенько требует знания о формате кодирования в UTF, чтобы можно было хотя бы находить границы символов. При использовании строк а-ля QString или wxString (с многобайтовым представлением символов внутри) границы искать уже не надо;
Нужно. Иначе получаем проблемы с RTL и прочими товарищами. То что ты их не видишь — это просто тебе везёт.

А>- применение к любой юникодной кодировке (и utf8 тоже) некоторых алгоритмов приведет к проблемам с символами со сложным написанием. Но универсального решения тут нет — в зависимости от задачи мы или будем резать текст по разделителям слов, или смиримся с вероятностью того, что "хитрый" текст может слегка подпортиться.
Естественно. Поэтому и нет разницы utf-8 или ucs-2/4.

А>Итого: utf-8 не дает никаких преимуществ по сравнению с многобайтовыми строками, но имеет пару специфических проблем.
Даёт. Хотя бы то, что не надо весь API переделывать.

А>Да, и напоследок: реальные программные проекты не пишутся под сферического клиента в вакууме. В большинстве случаев вполне достаточно поддержки латиницы, западноевропейских языков и (иногда) кириллицы. Языки с RTL написанием или со сложными глифами, скорее всего, потребуют специальной адаптации гуя, а это уже отдельный разговор.
Минимальная бдительность с кодировками (и отсутствие тупоголовых решений типа "обрежем по 80-ти байтам") позволяет делать приложения для 99% языков.

Здравствуйте, alsemm, Вы писали:

A>Я тоже не понимаю о чем речь. Кто такой "правильный юникод"?

Аналогичный тому, что был на входе.

A>На винде UTF16 удобнее только тем, что виндовый API его понимает без дополнительных преобразований. Кстати, UTF16 в винде только с Win2000, до этого она понимала только UCS2.

Внутреннее представление строк в фреймворке (мы ведь все еще о фреймворках, не так ли?) не обязательно должно быть UTF16.

А>>- обработка строк в формате UTF8 частенько требует знания о формате кодирования в UTF, чтобы можно было хотя бы находить границы символов. При использовании строк а-ля QString или wxString (с многобайтовым представлением символов внутри) границы искать уже не надо;
A>Это было верно для Unicode 2.0. Потом появились surrogate pairs и привет.

Внутреннее представление строк в фреймворке (мы ведь все еще о фреймворках, не так ли?) не обязательно должно cjответствовать последнему стандарту Unicode.
Смутно вспоминаю, что в Qt как раз unicode 2.0 в качестве внутренней кодировки, хотя могу и ошибаться.

А>>- применение к любой юникодной кодировке (и utf8 тоже) некоторых алгоритмов приведет к проблемам с символами со сложным написанием. Но универсального решения тут нет — в зависимости от задачи мы или будем резать текст по разделителям слов, или смиримся с вероятностью того, что "хитрый" текст может слегка подпортиться.
A>"хитрый" текст надо отдавать на анализ спец. библиотеке, чтобы она сказала, где строку можно разбивать, а где нельзя. На десктопной винде очевидный выбор — это uniscribe, ScriptStringAnalyse.

Да.

Здравствуйте, Cyberax, Вы писали:

C>>>>>Что зависит?
А>>>>От задачи зависит, допустимо ли разбиение по разделителям, или же требуется разбиение по печатным символам.
А>>>>Так понятнее?
C>>>Нет.
А>>Боюсь, тогда я помочь ничем не смогу.

C>Т.е. реальных разумных примеров зачем нужна посимвольная произвольная адресация — я так и не увижу, как обычно.

Хе-хе, сколько много требований к примерам. Вы забыли добавить "я должен признать, что пример разумен и реален".

Любой пример можно гордо отвергнуть под предлогом, что он неразумен или нереален.

А>>>>Так вот, если строку порезать посредине символа UTF-8, в большинстве почтовых клиентов заголовок письма отобразится криво.
А>>>>Это хороший пример?
C>>>Плохой. Так как такой алгоритм не будет работать нормально с арабским. Правильно — это разбить строку на runs по границам слов или глифов.
А>>То есть для вас приведенный мной пример никак не иллюстрирует проблему разбиения UTF-8 строки?

C>Совершенно не иллюстрирует. Ибо приведённое решение с произвольной адресацией — кривое.

Для забывчивых напомню, что решение приводилось с оговоркой: несущественные детали опущены.

Впрочем, для пуритан напомню еще одно: полученная строка не идет на экран напрямую, она пропускается через декодирующую процедуру (которая, кстати, ничего о юникоде не знает — она работает с байтами). К сожалению, декодирование UTF8-заголовков в большинстве реализаций (outlook, thunderbird, были и другие) кривовато и некорректно обрабатывает случаи, когда UTF-8 символ разрезает пополам. Случаи, когда пополам режется surrogate pair, обрабатываются корректно.

Вы, конечно, можете предложить пользоваться только корректно написанными почтовыми клиентами под истинно-верной операционной системой, но вряд ли вас послушают.

Посему приведенное мной решение — вполне себе корректное для данной задачи (закодировать заголовок так, чтобы он без артефактов читался в почтовых клиентах).

C>>>Учи матчасть: http://en.wikipedia.org/wiki/Complex_scripts и http://en.wikipedia.org/wiki/Unicode#Ready-made_versus_composite_characters Скажем, шрифты с RTL встречаются крайне часто.
А>>Я так понимаю, ради этого момента истины вы и затеяли сей беспредметный спор?

C>Собственно, я с самого начала писал, что с символами вообще всё не так уж просто.

Собственно, я с самого начала писал, что сложная работа с символами требуется не всегда.

C>>>С композитными символами можно побороться нормализацией (со своими проблемами), но вот со сложным начертанием простых способов уже нет. И в обоих случаях нафиг не нужна посимвольная адресация.
А>>Опять-таки, зависит от задачи.
C>Задачи — в студию.

См. выше.
Реальная задача, за решение которой платили разумные деньги.

А>>>>Но при наличии UTF8 она становится нетривиальной и требует или привлечения специальных библиотек, или сакральных знаний о битовом устройстве UTF8.
C>>>Ничуть. Всё делается элементарно, даже с UTF-8.
А>>Поделитесь сакральным знанием — как же это делается?

C>Выравнивание по границам символа — примерно 3 строки кода.

Не могу назвать ваше решение корректным и реальным.

C>>>Ну так делим по границе слов (по пробелам, запятым и т.п.) и вставляем crlf. Будет прекрасно работать с utf-8.
А>>Пока не встретится строка длиной этак в пару килобайт без пробелов, запятых и т. п. А встретится она буквально сразу же — бывали-с случаи.
C>Ну делишь по границам символа тогда.

Т.е. уже не три строчки, а чуть поболее?

C>Так нет примеров-то.

Примеры есть, но вы старательно делаете вид, что их нет.

А>>- ваши разглагольствования о красоте линукса немного не в тему;
C>В тему, как пример правильного использования utf-8.

Тема, позволю себе напомнить, такова: Best GUI for Windows C++ application
Пример другой операционной системы здесь абсолютно не в тему. Это было бы в тему где-нибудь на форуме, где переписывают Windows под использование utf-8. Я таких, к счастью, не знаю.

А>>- в реальной жизни под виндой UTF8 неудобен именно из-за своей похожести на текст в локальной восьмибитной кодировке, а его использование часто приводит к ошибкам типа "забыли перекодировать в win1251" и "перекодировали дважды";
C>Какой, (непечатно), win-1251?!?! В виндовых программах нужны ровно _две_ кодировки: UCS-2 и utf-8. Все локальные однобайтовые кодовые страницы — максимум для импорта legacy-данных.

А как же UTF-16?

А как же неизменность API, о которой вы рассуждаете двумя абзацами ниже?

А>>- обработка строк в формате UTF8 частенько требует знания о формате кодирования в UTF, чтобы можно было хотя бы находить границы символов. При использовании строк а-ля QString или wxString (с многобайтовым представлением символов внутри) границы искать уже не надо;
C>Нужно. Иначе получаем проблемы с RTL и прочими товарищами. То что ты их не видишь — это просто тебе везёт.

Пока что это голословное утверждение.
Какие конкретно проблемы мы получаем с RTL?

А>>- применение к любой юникодной кодировке (и utf8 тоже) некоторых алгоритмов приведет к проблемам с символами со сложным написанием. Но универсального решения тут нет — в зависимости от задачи мы или будем резать текст по разделителям слов, или смиримся с вероятностью того, что "хитрый" текст может слегка подпортиться.
C>Естественно. Поэтому и нет разницы utf-8 или ucs-2/4.

Неправда ваша.
Разница есть: применение "тупого" строкового разрезания к utf8-строке дает кривой результат в бОльшем количестве случаев.

А>>Итого: utf-8 не дает никаких преимуществ по сравнению с многобайтовыми строками, но имеет пару специфических проблем.
C>Даёт. Хотя бы то, что не надо весь API переделывать.

Вы уж определитесь: или мы все срочно пишем только в UCS2, или таки сохраняем старые API и оперируем ~~горячими заку~~ ASCIIZ-строками.

C>Минимальная бдительность с кодировками (и отсутствие тупоголовых решений типа "обрежем по 80-ти байтам") позволяет делать приложения для 99% языков.
К сожалению, ваше заявление — благое пожелание, и не больше. В реальных проектах, пишущихся в течение нескольких лет, а возможно, и разными программистами, минимальная бдительность с кодировками невозможна. Тут спасает только несовместимость строк на уровне компилятора (char* в wxString не скопируешь — придется преобразовывать осознанно). Если в программе везде используются строки char*, а кодировок больше одной — тушите свет, обязательно откуда-нибудь просочится строчка в неожиданной кодировке.

Здравствуйте, Аноним, Вы писали:

А>>>Боюсь, тогда я помочь ничем не смогу.

C>>Т.е. реальных разумных примеров зачем нужна посимвольная произвольная адресация — я так и не увижу, как обычно.
А>Хе-хе, сколько много требований к примерам. Вы забыли добавить "я должен признать, что пример разумен и реален".

А>Любой пример можно гордо отвергнуть под предлогом, что он неразумен или нереален.
Мне всего-то нужен пример, где для его корректной реализации прямо так критична посимвольная адресация.

Примеров типа: "мне нужно взять десятый символ слева" я могу десятки придумать.

C>>>>Плохой. Так как такой алгоритм не будет работать нормально с арабским. Правильно — это разбить строку на runs по границам слов или глифов.
А>>>То есть для вас приведенный мной пример никак не иллюстрирует проблему разбиения UTF-8 строки?

C>>Совершенно не иллюстрирует. Ибо приведённое решение с произвольной адресацией — кривое.
А>Для забывчивых напомню, что решение приводилось с оговоркой: несущественные детали опущены.
Ага.

А>Впрочем, для пуритан напомню еще одно: полученная строка не идет на экран напрямую, она пропускается через декодирующую процедуру (которая, кстати, ничего о юникоде не знает — она работает с байтами). К сожалению, декодирование UTF8-заголовков в большинстве реализаций (outlook, thunderbird, были и другие) кривовато и некорректно обрабатывает случаи, когда UTF-8 символ разрезает пополам. Случаи, когда пополам режется surrogate pair, обрабатываются корректно.
А при обработке обрезанного символа переключения RTL? Поэтому корректная реализация как раз будет учитывать все сложность Unicode. И там посимвольная адресация будет уже нафиг не нужна.

C>>Собственно, я с самого начала писал, что с символами вообще всё не так уж просто.
А>Собственно, я с самого начала писал, что сложная работа с символами требуется не всегда.
Иногда сойдёт халтура, да.

C>>Задачи — в студию.
А>См. выше.
А>Реальная задача, за решение которой платили разумные деньги.
Переплатили.

C>>>>Ну так делим по границе слов (по пробелам, запятым и т.п.) и вставляем crlf. Будет прекрасно работать с utf-8.
А>>>Пока не встретится строка длиной этак в пару килобайт без пробелов, запятых и т. п. А встретится она буквально сразу же — бывали-с случаи.
C>>Ну делишь по границам символа тогда.
А>Т.е. уже не три строчки, а чуть поболее?

Ровно 3 строчки. Написать?

C>>Какой, (непечатно), win-1251?!?! В виндовых программах нужны ровно _две_ кодировки: UCS-2 и utf-8. Все локальные однобайтовые кодовые страницы — максимум для импорта legacy-данных.
А>А как же UTF-16?

Да, сорри. Имел в виду именно её.

А>А как же неизменность API, о которой вы рассуждаете двумя абзацами ниже?
Внутреннего API. Конверсию в UTF-16 можно делать в самый момент вызова системных API.

C>>Нужно. Иначе получаем проблемы с RTL и прочими товарищами. То что ты их не видишь — это просто тебе везёт.
А>Пока что это голословное утверждение.
А>Какие конкретно проблемы мы получаем с RTL?
Обрезаем символ смены направления — и арабы читают текст слева направо.

C>>Естественно. Поэтому и нет разницы utf-8 или ucs-2/4.
А>Неправда ваша.
А>Разница есть: применение "тупого" строкового разрезания к utf8-строке дает кривой результат в бОльшем количестве случаев.
Разрезание по токенам из ASCII — всегда корректно.

А>>>Итого: utf-8 не дает никаких преимуществ по сравнению с многобайтовыми строками, но имеет пару специфических проблем.
C>>Даёт. Хотя бы то, что не надо весь API переделывать.
А>Вы уж определитесь: или мы все срочно пишем только в UCS2, или таки сохраняем старые API и оперируем ~~горячими заку~~ ASCIIZ-строками.
Второе.

C>>Минимальная бдительность с кодировками (и отсутствие тупоголовых решений типа "обрежем по 80-ти байтам") позволяет делать приложения для 99% языков.
А>К сожалению, ваше заявление — благое пожелание, и не больше. В реальных проектах, пишущихся в течение нескольких лет, а возможно, и разными программистами, минимальная бдительность с кодировками невозможна.
Ещё как возможна. И как раз использование utf-8 этому очень способствует.

А>Тут спасает только несовместимость строк на уровне компилятора (char* в wxString не скопируешь — придется преобразовывать осознанно). Если в программе везде используются строки char*, а кодировок больше одной — тушите свет, обязательно откуда-нибудь просочится строчка в неожиданной кодировке.
Более одной кодировки => в морг. Нафиг однобайтовые кодовые страницы-то?!?

Здравствуйте, Cyberax, Вы писали:

C>Примеров типа: "мне нужно взять десятый символ слева" я могу десятки придумать.

Отлично.

А>>Впрочем, для пуритан напомню еще одно: полученная строка не идет на экран напрямую, она пропускается через декодирующую процедуру (которая, кстати, ничего о юникоде не знает — она работает с байтами). К сожалению, декодирование UTF8-заголовков в большинстве реализаций (outlook, thunderbird, были и другие) кривовато и некорректно обрабатывает случаи, когда UTF-8 символ разрезает пополам. Случаи, когда пополам режется surrogate pair, обрабатываются корректно.

C>А при обработке обрезанного символа переключения RTL?

Ошибка возникает при декодировании кусочков строки из base64. Обрезания не возникает, если utf-8 символ не порезан пополам (потому как кусочки строки потом соединяются, и "обрезки" прекрасно сливаются).
Посему при обработке символа переключения RTL ничего необычного не случится.

C> Поэтому корректная реализация как раз будет учитывать все сложность Unicode. И там посимвольная адресация будет уже нафиг не нужна.

Да-да, конечно-конечно.

C>>>Собственно, я с самого начала писал, что с символами вообще всё не так уж просто.
А>>Собственно, я с самого начала писал, что сложная работа с символами требуется не всегда.
C>Иногда сойдёт халтура, да.

Иногда это зависит не от нас.

C>>>Задачи — в студию.
А>>См. выше.
А>>Реальная задача, за решение которой платили разумные деньги.
C>Переплатили.

Цитаты из книги личных переживаний вы можете оставить в своем блоге.
В данном случае критерием оценки является не высказанное вами ценное мнение, а довольство заказчика.

C>>>>>Ну так делим по границе слов (по пробелам, запятым и т.п.) и вставляем crlf. Будет прекрасно работать с utf-8.
А>>>>Пока не встретится строка длиной этак в пару килобайт без пробелов, запятых и т. п. А встретится она буквально сразу же — бывали-с случаи.
C>>>Ну делишь по границам символа тогда.
А>>Т.е. уже не три строчки, а чуть поболее?

C>Ровно 3 строчки. Написать?

Конечно.

А>>А как же неизменность API, о которой вы рассуждаете двумя абзацами ниже?
C>Внутреннего API. Конверсию в UTF-16 можно делать в самый момент вызова системных API.

Под виндой зачастую оказывается, что в ASCII-строчке — не utf8, а локальная кодировка.

C>>>Нужно. Иначе получаем проблемы с RTL и прочими товарищами. То что ты их не видишь — это просто тебе везёт.
А>>Пока что это голословное утверждение.
А>>Какие конкретно проблемы мы получаем с RTL?
C>Обрезаем символ смены направления — и арабы читают текст слева направо.

Пример надуманный.

Символ смены направления обычно находится в начале строки, а не в середине.

C>>>Естественно. Поэтому и нет разницы utf-8 или ucs-2/4.
А>>Неправда ваша.
А>>Разница есть: применение "тупого" строкового разрезания к utf8-строке дает кривой результат в бОльшем количестве случаев.
C>Разрезание по токенам из ASCII — всегда корректно.

Но как мы уже выяснили — не является универсальным методом, а зависит от задачи и от того, что именно мы режем.

А>>>>Итого: utf-8 не дает никаких преимуществ по сравнению с многобайтовыми строками, но имеет пару специфических проблем.
C>>>Даёт. Хотя бы то, что не надо весь API переделывать.
А>>Вы уж определитесь: или мы все срочно пишем только в UCS2, или таки сохраняем старые API и оперируем ~~горячими заку~~ ASCIIZ-строками.
C>Второе.

А то, что старые API периодически выдают строки в странной не-utf8 кодировке, вас не смущает?

C>>>Минимальная бдительность с кодировками (и отсутствие тупоголовых решений типа "обрежем по 80-ти байтам") позволяет делать приложения для 99% языков.
А>>К сожалению, ваше заявление — благое пожелание, и не больше. В реальных проектах, пишущихся в течение нескольких лет, а возможно, и разными программистами, минимальная бдительность с кодировками невозможна.
C>Ещё как возможна. И как раз использование utf-8 этому очень способствует.

Голословное утверждение номер 2.

А>>Тут спасает только несовместимость строк на уровне компилятора (char* в wxString не скопируешь — придется преобразовывать осознанно). Если в программе везде используются строки char*, а кодировок больше одной — тушите свет, обязательно откуда-нибудь просочится строчка в неожиданной кодировке.
C>Более одной кодировки => в морг. Нафиг однобайтовые кодовые страницы-то?!?

Дык — нативный API, который вы сохраняете, работает под виндовсом именно с однобайтовыми кодировками, зависящими от дефолтной локали винды.

А кодировок не обязательно будет много. В пределах программы их может быть всего две (utf8 и ANSI), но на разных региональных вариантах винды кодовая страница будет в этом ANSI разная.

Виндовс — в морг, всем срочно ставить линукс, и вопрос переименовать в "Best GUI for Linux C++ application"? Я вас правильно понимаю?

Здравствуйте, Аноним, Вы писали:

A>>На винде UTF16 удобнее только тем, что виндовый API его понимает без дополнительных преобразований. Кстати, UTF16 в винде только с Win2000, до этого она понимала только UCS2.

А>Внутреннее представление строк в фреймворке (мы ведь все еще о фреймворках, не так ли?) не обязательно должно быть UTF16.
Выбор-то невелик — UTF8, UTF16, или UTF32.

А>Смутно вспоминаю, что в Qt как раз unicode 2.0 в качестве внутренней кодировки, хотя могу и ошибаться.
unicode — это не кодировка.

Здравствуйте, Аноним, Вы писали:

C>>А при обработке обрезанного символа переключения RTL?
А>Ошибка возникает при декодировании кусочков строки из base64. Обрезания не возникает, если utf-8 символ не порезан пополам (потому как кусочки строки потом соединяются, и "обрезки" прекрасно сливаются).
А>Посему при обработке символа переключения RTL ничего необычного не случится.
А ты попробуй.

А>>>Т.е. уже не три строчки, а чуть поболее?

C>>Ровно 3 строчки. Написать?
А>Конечно.
А лень

А>>>А как же неизменность API, о которой вы рассуждаете двумя абзацами ниже?
C>>Внутреннего API. Конверсию в UTF-16 можно делать в самый момент вызова системных API.
А>Под виндой зачастую оказывается, что в ASCII-строчке — не utf8, а локальная кодировка.
Это надо очень постараться при минимальной гигиене.

C>>Обрезаем символ смены направления — и арабы читают текст слева направо.
А>Пример надуманный.

А>Символ смены направления обычно находится в начале строки, а не в середине.
Ну мы же можем и с начала обрезать.

А>>>Вы уж определитесь: или мы все срочно пишем только в UCS2, или таки сохраняем старые API и оперируем ~~горячими заку~~ ASCIIZ-строками.
C>>Второе.
А>А то, что старые API периодически выдают строки в странной не-utf8 кодировке, вас не смущает?

Какие именно?

А>>>Тут спасает только несовместимость строк на уровне компилятора (char* в wxString не скопируешь — придется преобразовывать осознанно). Если в программе везде используются строки char*, а кодировок больше одной — тушите свет, обязательно откуда-нибудь просочится строчка в неожиданной кодировке.
C>>Более одной кодировки => в морг. Нафиг однобайтовые кодовые страницы-то?!?
А>Дык — нативный API, который вы сохраняете, работает под виндовсом именно с однобайтовыми кодировками, зависящими от дефолтной локали винды.

Неа. В Винде нынче весь API есть в wide-варианте (Win98 уже не считаем), так что никто не мешает делать преобразование сразу же в utf-8 после получения результата из API.

Здравствуйте, Cyberax, Вы писали:

C>>>А при обработке обрезанного символа переключения RTL?
А>>Ошибка возникает при декодировании кусочков строки из base64. Обрезания не возникает, если utf-8 символ не порезан пополам (потому как кусочки строки потом соединяются, и "обрезки" прекрасно сливаются).
А>>Посему при обработке символа переключения RTL ничего необычного не случится.
C>А ты попробуй.

А лень

А>>>>Т.е. уже не три строчки, а чуть поболее?

C>>>Ровно 3 строчки. Написать?
А>>Конечно.
C>А лень

Что еще раз подтверждает цель вашего визита в тему.

На том и порешим.

А>>>>А как же неизменность API, о которой вы рассуждаете двумя абзацами ниже?
C>>>Внутреннего API. Конверсию в UTF-16 можно делать в самый момент вызова системных API.
А>>Под виндой зачастую оказывается, что в ASCII-строчке — не utf8, а локальная кодировка.
C>Это надо очень постараться при минимальной гигиене.

К сожалению, реальность несколько отличается от вашего идеализированного представления о гигиене.

C>>>Обрезаем символ смены направления — и арабы читают текст слева направо.
А>>Пример надуманный.

А>>Символ смены направления обычно находится в начале строки, а не в середине.
C>Ну мы же можем и с начала обрезать.

Задача была поставлена иначе.
Если у программиста вдруг разыгралась фантазия и он сделал все с другого конца, задачу поручат другому программисту.

А>>>>Вы уж определитесь: или мы все срочно пишем только в UCS2, или таки сохраняем старые API и оперируем ~~горячими заку~~ ASCIIZ-строками.
C>>>Второе.
А>>А то, что старые API периодически выдают строки в странной не-utf8 кодировке, вас не смущает?

C>Какие именно?

Посмотрите сами, какие API возвращают ASCIIZ строки в операционной системе windows.

А>>>>Тут спасает только несовместимость строк на уровне компилятора (char* в wxString не скопируешь — придется преобразовывать осознанно). Если в программе везде используются строки char*, а кодировок больше одной — тушите свет, обязательно откуда-нибудь просочится строчка в неожиданной кодировке.
C>>>Более одной кодировки => в морг. Нафиг однобайтовые кодовые страницы-то?!?
А>>Дык — нативный API, который вы сохраняете, работает под виндовсом именно с однобайтовыми кодировками, зависящими от дефолтной локали винды.

C>Неа. В Винде нынче весь API есть в wide-варианте (Win98 уже не считаем), так что никто не мешает делать преобразование сразу же в utf-8 после получения результата из API.
Неа. В винде нынче весь API есть в ASCII-варианте, о чем, собственно, и ведется речь.

	От:	Аноним
	Дата:	08.10.10 03:25
	Оценка:

	От:	Mazay
	Дата:	08.10.10 04:42
	Оценка:	6 (1) +1 -1

	От:	fdn721
	Дата:	08.10.10 04:49
	Оценка:	+1

	От:	Аноним
	Дата:	08.10.10 04:58
	Оценка:

	От:	Mazay
	Дата:	08.10.10 05:04
	Оценка:

От:	Ytz	https://github.com/mtrempoltsev
Дата:	08.10.10 06:12
Оценка:

	От:	Тот кто сидит в пруду
	Дата:	08.10.10 16:51
	Оценка:

От:	t_rex	http://www.wxwidgets.info
Дата:	08.10.10 18:10
Оценка:

От:	c-smile	http://terrainformatica.com
Дата:	08.10.10 18:19
Оценка:

	От:	Centaur
	Дата:	09.10.10 02:49
	Оценка:	6 (1) +2

От:	jazzer	Skype: enerjazzer
Дата:	09.10.10 03:58
Оценка:	+1

От:	artem_korneev	https://www.linkedin.com/in/artemkorneev/
Дата:	12.10.10 18:27
Оценка:	+1