Здравствуйте, 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 (значительный оверхед).

Здравствуйте, 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? Это не так.

Здравствуйте, 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.

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

Автор: Ytz
Дата: 12.10.10

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 (кажется), так я проклял всех гуй-дизайнеров на свете. Пока настроишь режим работы монитора, обновлений, оповещений с ума сойти можно, от вырвиглазия лезущего из каждой щели. Это мне напомнило "умом нужно выделяться"

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

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

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

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

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

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

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

Здравствуйте, 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 вроде и это делать умеет.