OberonCore
https://forum.oberoncore.ru/

Toward Ultimate Unicode
https://forum.oberoncore.ru/viewtopic.php?f=3&t=795		 Страница 3 из 4
Автор:  Trurl [ Понедельник, 12 Март, 2012 12:47 ]
Заголовок сообщения:  Re: Toward Ultimate Unicode
С формами проблема в том, что свойсва контролов, созданных в ББ 1.5, записаны в кодировке 1251.
Кажется, можно сделать перекодировщик, аналогичный тому, что для текстов.
А вот со ссылками не придумал ничего, кроме как раскрывать их, перекодировать текст, а потом пересоздавать.

Идиот! Можно было сделать перекодировщик, как и для форм.
Автор:  Trurl [ Понедельник, 12 Март, 2012 13:03 ]
Заголовок сообщения:  Re: Toward Ultimate Unicode
Info21 писал(а):
И какую литерку предлагается вставлять перед строкой УТФ-8?
Чтобы её видел стандартный ББ?
Разве это возможно?

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

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

Конечно, можно просто забить и перекомпилировать исходники. Но хочется совместимости, хотя бы в одну сторону: чтобы стандартные бинарники работали. Ну еще, если все имена попадают в Latin-1, то чтобы бинарники получались стандартными. :) Сейчас это выполняется только если имена помещаютя в ASCII/
Автор:  Info21 [ Понедельник, 12 Март, 2012 16:22 ]
Заголовок сообщения:  Re: Toward Ultimate Unicode
Trurl писал(а):
Info21 писал(а):
Тут скрытое предположение:
что коллаборация стандартных бинарников и уникодных должна быть прозрачной, невидимой.
Конечно, можно просто забить и перекомпилировать исходники.
Но хочется совместимости, хотя бы в одну сторону
Речь о перекомпиляции не шал, речь шла о тулзе, вроде, или о механизме типа интерфейсных модулей.

Я пытаюсь вытащить из Вашего подсознания все эти вещи:

Да, разумно требовать совместимости в одну сторону.
Но если можно предусмотреть тулзовину для совместимости в обратную сторону, то тоже неплохо.
Автор:  Trurl [ Вторник, 13 Март, 2012 13:23 ]
Заголовок сообщения:  Re: Toward Ultimate Unicode
Info21 писал(а):
Речь о перекомпиляции не шал, речь шла о тулзе, вроде, или о механизме типа интерфейсных модулей.

О перекомпиляции - это я подумал. По сути сейчас ситуация аналогична той, что сложилась с русским ББ1.5.
Вроде бы несовместимость со стандартным не особенно мешает.
Автор:  Info21 [ Четверг, 15 Март, 2012 12:17 ]
Заголовок сообщения:  Re: Toward Ultimate Unicode
Trurl писал(а):
... По сути сейчас ситуация аналогична той, что сложилась с русским ББ1.5.
Вроде бы несовместимость со стандартным не особенно мешает.
Не уверен, что "по сути".

Русский ББ1.5 -- это школьная такая учебная штука.
Особого хода именно как *русский* ББ она не имеет.
Во всяком случае мне об этом не известно.

У-ББ1.6 -- это совсем другая песня.
Глобальная. Потенциально встраивается в комбинации глобального масштаба.
Раcтормозите чуток воображение и помыслите ... ну, хотя бы, Samsung. Так, чисто для примера.

Призываю очень тщательно, не спеша повертеть в голове сценарии для У-ББ1.6.
Автор:  Trurl [ Четверг, 22 Март, 2012 16:15 ]
Заголовок сообщения:  Re: Toward Ultimate Unicode
Вот повертел немножко.

Сначала проблемы нынешнего Блэкбокса.
1. Ссылки. Можно создать ссылку на файл с именем "привет", но при сохранении это имя будет обрезано до "?@825B". Идеального решения, похоже, нет. Можно изменить StdLinks или создать собственную замену, но такие ссылки не будут открываться в стандартном ББ.
Подобные проблемы есть в StdFolds и StdStamps, но это менее актуально.

2. Локализация. Сейчас после установки языка через Dialog.SetLanguage подгружаются соответствующие строковые ресурсы. Кроме того, в командах OpenDoc и т.п. можно ссылаться на документы в зависимости от языка, например 'Docu/*/Views'.
Хотелось бы, чтобы это работало и для меню, сообщений об ошибках. Тем более, что меню уже обновляются при смене языка.

Теперь о возможном "консервативном" расширении.
С компилятором относительно просто: можно сделать кодировку, сохраняющую буквы из Latin-1. Тогда модули можно будет запускать и в стандартном ББ, если интерфейсная часть останется латинской.
А вот дальше - хуже.
В Meta предусмотрена установка раширений, но многие модули используют напрямую Kernel. Большая их часть локализована в Dev, котрую все равно менять. Но вот Kernel.SplitName затрагивает все.
В некоторые модули зашита проверка имен (в русском ББ1.5 там National.IsIdentChar). Тут уж точно без правки не обойтись.
В общем без аналога дельты не обойтись.
Автор:  Роман М. [ Воскресенье, 25 Март, 2012 15:43 ]
Заголовок сообщения:  Re: Toward Ultimate Unicode
Trurl писал(а):
А вот дальше - хуже.
В Meta предусмотрена установка раширений, но многие модули используют напрямую Kernel. Большая их часть локализована в Dev, котрую все равно менять. Но вот Kernel.SplitName затрагивает все.

Можно сдублировать проц-ры SplitName и MakeFileName в отдельный модуль и избавиться от зависимости Kernel во многих модулях. Проверено.
Автор:  Роман М. [ Воскресенье, 25 Март, 2012 15:51 ]
Заголовок сообщения:  Re: Toward Ultimate Unicode
А, собственно, отчего боязнь модификаций базовых модулей каркаса? Или до сих пор уповаем на развитие со стороны OM?

Предлагаю переделать дистрибутив так, как это удобно и правильно, чтобы обойтись без костылей.
Автор:  Info21 [ Воскресенье, 25 Март, 2012 19:51 ]
Заголовок сообщения:  Re: Toward Ultimate Unicode
Роман М. писал(а):
Можно сдублировать проц-ры SplitName и MakeFileName в отдельный модуль и избавиться от зависимости Kernel во многих модулях. Проверено.
Это, в принципе, правильный подход.
Он и в других местах приложим.

Но надо обсуждать: давать списки, что выделить, с сигнатурами etc., и обсуждать.
Автор:  Trurl [ Воскресенье, 25 Март, 2012 20:16 ]
Заголовок сообщения:  Re: Toward Ultimate Unicode
Роман М. писал(а):
Можно сдублировать проц-ры SplitName и MakeFileName в отдельный модуль и избавиться от зависимости Kernel во многих модулях. Проверено.

Но, например,StdCmds ведь все равно вызывает Kernel.SplitName.
Автор:  Info21 [ Воскресенье, 25 Март, 2012 22:02 ]
Заголовок сообщения:  Re: Toward Ultimate Unicode
Trurl писал(а):
Роман М. писал(а):
Можно сдублировать проц-ры SplitName и MakeFileName в отдельный модуль и избавиться от зависимости Kernel во многих модулях. Проверено.
Но, например,StdCmds ведь все равно вызывает Kernel.SplitName.
И?..
Автор:  Trurl [ Понедельник, 26 Март, 2012 07:30 ]
Заголовок сообщения:  Re: Toward Ultimate Unicode
И будет искать модули по-старому, невзирая на нашу собственную SplitName.
Автор:  Роман М. [ Понедельник, 26 Март, 2012 10:06 ]
Заголовок сообщения:  Re: Toward Ultimate Unicode
Info21 писал(а):
Роман М. писал(а):
Можно сдублировать проц-ры SplitName и MakeFileName в отдельный модуль и избавиться от зависимости Kernel во многих модулях. Проверено.
Это, в принципе, правильный подход.
Он и в других местах приложим.

Но надо обсуждать: давать списки, что выделить, с сигнатурами etc., и обсуждать.

А какие другие зависимости остаются от модуля Kernel и в каких модулях?
Автор:  Info21 [ Пятница, 27 Апрель, 2012 11:50 ]
Заголовок сообщения:  Re: Toward Ultimate Unicode
Урывками дожимаю новую школьную версию.
Вот оттуда рабочий инструментик (в приаттаченном зипе, там есть неказистый рабочий диаложек).
Инструментик такой, чтобы можно было иметь интерактивный контроль за происходящим.

Можно искать сегменты расширенного аски или юникодные, и туда-сюда конвертировать куски с сохранением атрибутов и вьюшек (для вьюшек deep copy).

Конвертация всегда в новое окно.

Расширенный АСКИ может сидеть внутри линков -- имена файлов и заголовки окон.
Преобразование таких скрытых фрагментов пока не предусмотрено, тоже надо как-то с интерактивным контролем это делать.

Вложения:
unicodetools.zip [14.77 КБ]
Скачиваний: 542
Автор:  Евгений Темиргалеев [ Воскресенье, 27 Май, 2012 11:27 ]
Заголовок сообщения:  Re: Toward Ultimate Unicode
viewtopic.php?p=71322#p71322
Trurl писал(а):
[*]В объектных файлах имена предполагаются в UTF-8 (точнее CESU-8)
А зачем CESU-8? На будущее, когда в текстах вместо UCS-2 будет UTF-16?
Автор:  Евгений Темиргалеев [ Воскресенье, 27 Май, 2012 11:39 ]
Заголовок сообщения:  Re: Toward Ultimate Unicode
Info21 писал(а):
Расширенный АСКИ может сидеть внутри линков -- имена файлов и заголовки окон.
Преобразование таких скрытых фрагментов пока не предусмотрено, тоже надо как-то с интерактивным контролем это делать.
Можно во время преобразования писать в журнал ссылки вида <OpenDoc(original | result); ShowPos(link.context... .Pos())>xxx<>. И контролировать (временный) результат. Мне кажется это проще, нежели ещё тулзу для поиска городить.

http://oberoncore.ru/bbcc/subs/unicode --- тут только выдачу допилить
Автор:  Info21 [ Понедельник, 28 Май, 2012 21:27 ]
Заголовок сообщения:  Re: Toward Ultimate Unicode
Евгений Темиргалеев писал(а):
Мне кажется это проще, нежели ещё тулзу для поиска городить.
А что там такого сложного?
Автор:  Рыжий [ Воскресенье, 03 Февраль, 2013 00:17 ]
Заголовок сообщения:  Re: Toward Ultimate Unicode
Юникод это не "инакоговорящие юзеры", а инакомыслящие.. :mrgreen:, это целая алфавитно-цифровая инфраструктура, применений коей несть числа. :D См. кнопочки:
Изображение
& VBDOS стиль:
Изображение
А теперь приложите к этому события и дин. структуры данных.. :roll: В плане, значить, "текста как интерфейса"..☝
http://graphemica.com/scripts/common
Автор:  Info21 [ Среда, 26 Февраль, 2014 06:22 ]
Заголовок сообщения:  Юникод для идентификаторов КП
Не помню, где обсуждался юникод. Если что, прошу перенести туда.
(модератор: прикреплено к существующей теме, 27.02.2014)

Лично я почти созрел для того, чтобы согласиться с предложением Trurl'я насчёт уникодизации Компонентного Паскаля (т.е. разрешение уникодовых идентификаторов) через UTF-8 внутри.

Ведь Java, вроде, разрешает уникод в идентификаторах, нет?

Хотелось бы ещё раз перечислить/уточнить ключевые пункты.

Самый ключевой: совместимость только в одну сторону:

Литерные цепочки, содержащие только чистый АСКИИ, в UTF-8 вида не меняют, отчего BB 1.6U будет принимать бинарники от BB 1.6, но не наоборот.

Прошу дополнить список.

**

Вопрос по длине идентификаторов.
При неизменной длине SHORT-литерных массивов эффективная длина идентификаторов из не-EASCII литер с применением UTF-8 уменьшится вдвое (?).

Насколько серьезные проблемы возникнут при изменении формата внутренних SHORT-литерных массивов?
Или это уже обсуждалось? Пож., дайте ссылку, кто помнит.
Автор:  Alexander Shiryaev [ Среда, 26 Февраль, 2014 10:10 ]
Заголовок сообщения:  Re: Юникод для идентификаторов КП
Info21 писал(а):
Лично я почти созрел для того, чтобы согласиться с предложением Trurl'я насчёт уникодизации Компонентного Паскаля (т.е. разрешение уникодовых идентификаторов)

А зачем?

Цитата:
через UTF-8 внутри

Почему именно UTF-8? Внутри же UCS-2.

Info21 писал(а):
Ведь Java, вроде, разрешает уникод в идентификаторах, нет?

Java Language Specification, Lexical Structure

Цитата:
При неизменной длине SHORT-литерных массивов эффективная длина идентификаторов из не-EASCII литер с применением UTF-8 уменьшится вдвое (?)

нет
Страница 3 из 4 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/