MinCL

[daesher]

Начал проект с рабочим названием "mincl" - минимальная библиотека компонентов в "стиле VCL/LCL". Причина - "монстрообразность" LCL, несовместимость KOL и тем более - MSE, FPGui.
Главная цель - баланс между функциональностью и размером кода. Пока в рамках разработки стараюсь поддерживать возможность компиляции как с FPC, так и с VirtualPascal.
Поддерживаемые платформы - X11 (сейчас работает) и Win32 (или win64, не принципиально, впрочем, надо ввести переопределения).
На данный момент работает только X11, Win32 "сломано".
Поддерживаются:
- форма, канва с парой функций
- кнопки.
Стадия разработки: планирование и первичная реализация.

Адрес проекта http://code.google.com/p/mincl/

[bw]

Хорошая идея, понаблюдаю за проектом.
Пока могу сказать что "шрифт говно", есть некоторые нормы оформления кода и их нужно придерживаться. Кстати MSE в основном по этому меня и отталкивает, очень неприятно работать с исходниками. И ещё. Стоит уже сейчас разделять платформозависимый код на модули, а не пихать всё в один. Ну и шкуры (для X'ов, например) нужны. На себя (гипотетически, в будущем :-) я готов взять портирование на Kolibri и GTK.

..bw

[daesher]

Стоит уже сейчас разделять платформозависимый код на модули, а не пихать всё в один

Здесь всё спорно, бывают разные варианты. "Распихивая" код по модулям, рискуешь прийти к тому, что получилось в LCL: сначала создаётся одна прослойка, потом на ней - другая (в MSE, кстати, то же самое). Т.е., не надо создавать ни одного лишнего класса. Платформно-зависимого кода не так уж и много, пока платформы всего лишь две - лишние модули будут "лишними". Но, правда, надо смотреть на перспективу.

А норм оформления кода не так уж и мало, кто-то считает общепринятым одно, кто-то - немного другое, кто-то придерживается лишь минимума правил.
Определённые ограничения накладывает VirtualPascal (хотя с ним ещё немало возиться).
KolibriOS - это, конечно, отлично, кстати, как там FPC, а то как-то работала только одна версия, и то в ужасном варианте.
Сейчас вылавливаю баг под Win32, а то летит стек, хотя первое окно у меня появилось именно там.

Добавлено спустя 6 минут 58 секунд:
Проблема решена, иду дальше

[bw]

При чём здесь прослойки, сделай mgraphics_win и mgraphics_x11 вместо mgraphics и используй нужный в зависимости от обстоятельств.
FPC под KOS никому не нужно, как и сама KOS :-), так что никто им не занимался с тех пор как я забросил это дело, но пытаюсь сейчас обновить. Про ужасный вариант не знаю, со всеми задачами, которые я решал в то время, портированный RTL справился.

..bw

[daesher]

При чём здесь прослойки, сделай mgraphics_win и mgraphics_x11 вместо mgraphics и используй нужный в зависимости от обстоятельств.

Это, конечно, можно, но там уж слишком много общего кода. И, наоборот, в нём же (и в других модулях, например, mControls. Ладно, посмотрю, что можно сделать.Эх, winapi, winapi...Xlib даже проще...

[debi12345]

Если не оговорить сразу и жестко порог фишек и функционала, то любой изначально минималисткий проект соберет множество "wishes" и наберет тяжеловесность сперва FpGUi, затем MseGUI,... Или сразу нужно вводить "defines" на компиляцию либо только базового функционала, либо расширенного.

[daesher]

Совершенно согласен. С другой стороны, сейчас проект ещё на таком минималистическом уровне, что границу описать сложно. Тем не менее, на что пока следует обращать внимание:
1. Ресурсы (формы и т.п.). Нужны, как минимум, в define
2. Якоря. Скорее всего, их не будет.
3. Кодировка (UTF8, ANSI и т.п.). Пока на неё не особо обращаю внимание, НО предполагается, что проект будет интегрировать себя в IDE Lazarus, а там без UTF8 жить тяжело. Во всяком случае, от однобайтовой "внешней" кодировки (тогда, когда s[5] - это именно 5-я буква строки s) отказываться не хочется.
4. Большинство расширенных компонентов будет в отдельных модулях, так что проблема "разбухания" решится сама.
5. Компоненты для XLib - саморисованные окна (альтернатива - саморисованные виджеты). Компоненты для Win - пока тоже, в перспективе будет выбор (по подключению нативных компонентов).

VirtualPascal - отдельный разговор. С одной стороны, он генерирует более оптимальный код (?), у него менее раздута RTL(точно), поэтому перекомпиляция с ним уменьшит программу почти вдвое. С другой - он очень мало чего может, но это как раз не проблема. С третьей - пока не удалось собрать с ним что-либо серьёзное на платформе Linux. Попытался переписать импорт XLib, но он даже не пытается его воспринимать - сегфолтится при запуске, отладочных символов нет, все bt висят в загрузчике. С другой стороны, с трудом удаётся импортировать функцию из libc.
Думаю, для FreePascal надо будет создавать модули mClasses и mSysUtils (опционально).

[debi12345]

Во всяком случае, от однобайтовой "внешней" кодировки (тогда, когда s[5] - это именно 5-я буква строки s) отказываться не хочется.

Тогда однозначно WideString(UCS-2). Будет и s[5], и нативность (не нужно перкодировки при вызовах Win-32 API) в NT4+, и портируемость проектов, и перекрытие всех символов (кроме расширенного китайского - который самими китайцамив сфере IT практически не применяется).
В MseGUI данный подход себя более чем оправдывает. Однако исходники в MSE опционально кодируются в UTF-8 - для 1) сохранения размера и 2) чтения ASCII (99% исходного текста) без перекодировки.

Добавлено спустя 3 минуты 14 секунд:

С третьей - пока не удалось собрать с ним что-либо серьёзное на платформе Linux.

Зря связались с abandoned-проектом, без исходников. Кстати, в VP прекрасная связка IDE+отладчик (кажется, даже класс-браузер работает), вот этот бы отладчик да заимствовать в FPC...

[daesher]

Зря связались с abandoned-проектом, без исходников.

Не то, чтобы связываюсь - базовая разработка идёт в fpc. Но сам fpc настолько захламлён (по крайней мере, с ветки 2.2 или даже с 2.0), включая и его rtl, что желание куда-то откатиться, пусть даже опционально, велико. Кстати, интересный эффект: на ноутбуке, который я держу на работе (древний RoverBook на базе процессора VIA, память сейчас 512 Мб) при компиляции именно FPC (особенно при самосборке, но и при сборке больших проектов тоже) наблюдается полный слёт системы в непредсказуемый момент, причём и под Windows, и под Linux. Не знаю, в чём проблема, может, перегрузка процессора (но другие-то программы работают, а процессор грузят только так любые более или менее современные программы на таком старье, тот же flash). Во времена первых версий я такого не замечал. VP там, конечно, работает "на ура" (хотя linux его ограничивает)

[debi12345]

Но сам fpc настолько захламлён (по крайней мере, с ветки 2.2 или даже с 2.0), включая и его rtl, что желание куда-то откатиться, пусть даже опционально, велико.

В смысле "захламлен" ? Часть RTL, не используемая программой, выкидывается при smartlink-сборке (c опциями "-CX -XX" ).

[daesher]

В смысле "захламлен" ? Часть RTL, не используемая программой, выкидывается при smartlink-сборке (c опциями "-CX -XX" ).

Ну, во-первых, не всё, а только то, что не завязано на классы и их иерархическую структуру. Во-вторых, механизмы работы с теми же AnsiString и многое другое - посмотрите, в какую "кашу" (или правильнее говорить - "спагетти"?) превратился модуль System. Сколько там отсылок к самому компилятору (встроенных функций), "магических" фич и т.п. Как-то пытался разбираться с системным программированием - и что теперь надо, чтобы построить минимальный набор модулей для новой платформы?

Добавлено спустя 4 минуты 39 секунд:

Тогда однозначно WideString(UCS-2). Будет и s[5], и нативность

Да, для внутренней работы у этого типа есть свои плюсы, но есть и огромный минус - несовместимость вообще ни с чем в паскале, включая lazarus. Моё мнение - хотя бы на уровне пользователя отказываться от юникода вообще и в принципе там, где он не нужен (не указывается явно). Кодировку выберет сам пользователь, его дело. Главная проблема - lazarus с его utf8.

[debi12345]

. Моё мнение - хотя бы на уровне пользователя отказываться от юникода вообще и в принципе там

???
Юникод must be! Как портабельность исходников и программ обеспечите - например между выневой ср1251 и линевыми KOI8 UTF8 ?

ПС:
ИМХО, "Лазарь" зря с UTF-8 связался - она медленная, не позволяет доступ к строками как массивами символов,.. Ради только расширеннго китайского - который практически не используется ?

[daesher]

???
Юникод must be! ?

Только там, где он на самом деле нужен! А нужен он, прежде всего, там, где в тексте (!) предполагают использовать символы из разных раскладок(!). Не такая и частая ситуация, согласитесь. Маленький текстовый файл в той же винде прочитают только в cp1251, ну ещё cp866, несмотря на всю её юникодность.

например между выневой ср1251 и линевыми KOI8 UTF8 ?

Во-первых, KOI-8R - уже труп, найти его будет сложно (только во внутренностях берущего начало из древности софта, да на старых web-страницах). Так что в качестве однобайтовой кодировки в 90 % случаев подойдёт cp1251, т.к. именно она используется большинством (не считая юникодов). Перекодировка же в UTF8 всё равно требуется.

ПС:
ИМХО, "Лазарь" зря с UTF-8 связался - она медленная, не позволяет доступ к строками как массивами символов,.. Ради только расширеннго китайского - который практически не используется ?

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

Добавлено спустя 1 минуту 16 секунд:
Закоммитил в транк вариант с раздельными платформенными включаемыми файлами. Да, некоторая потеря места есть, но читабельность повысилась.

[debi12345]

Только там, где он на самом деле нужен! А нужен он, прежде всего, там, где в тексте (!) предполагают использовать символы из разных раскладок(!). Не такая и частая ситуация, согласитесь.

Как сказать... Гораздо более частая ситуация, чем применение расширеного китайского. Например - отчет, в котором применяются знаки сумма, сигма, бесконечность, производная,... Чтобы не рисовать их графикой, а выводить прямо TTF-шрифтом - с наклоном, масштабированием вместе со шрифтом. Опять-таки в mseGUI такие ( знак "сумма" ) отчеты делал, удобно - не то слово

[daesher]

Например - отчет, в котором применяются знаки сумма, сигма, бесконечность, производная,... Чтобы не рисовать их графикой, а выводить прямо TTF-шрифтом - с наклоном, масштабированием вместе со шрифтом.

То-то и оно, что вместе со шрифтом. А тут ещё понадобятся подстрочные, надстрочные символы... Многоэтажные дроби, надсимвольные надписи... Короче, от "plain text" очень далеко!