Lazarus жив вообще ?

[Павел Ишенин]

- 80 kb - это новые модули в LCL (поддержка тем)
- Smart Linking и в .22 включал теже модули - так устроен LCL сейчас
- Drag Drop - надо пример с тем что не нравится и как нравится - иначе ничего не ясно.

ps:
Видимо каждая новая версия вызывает у пользователей отторжение. Помнится 0.9.22 также не была принята с радостю и некоторые собирались откатываться на .20 или на .18

[betatester]

Павел, спасибо за ответ.

Я не пользователь , а разработчик.

Что касается Drag-Drop - моя программа находится по адресу http://betatester.by.ru/sysinfolinux.html

Там, на третьей странице, есть TreeView, показывающий содержимое выбранного диска (файловой системы) . Обрабатывается сообщение OnSelectionChanged для подсчёта размера выбранного каталога. Так вот, в процессе обработки OnSelectionChaged рисуется сплаш-скрин и вызывается Application.ProcessMessages.
Это, в свою очередь, почему-то заставляет Lazarus думать, что наступило событие OnStartDrag...

Что касается всего остального - повторюсь ещё раз. Я от перехода на FPC 2.2.0/Lazarus 0.9.24 ждал трёх вещей, все они были обещаны:
- улучшение Smart Link, уменьшение размера "экзешника"
- увеличения скорости работы линковщика
- картинки в PNG в ресурсах.

По всем трём позициям - болт. Больше, медленнее, XPM.

Без обид - просто констатация факта. А новые иконки в меню понравились.

[Павел Ишенин]

- Smart link обещаны были скорее со стороны fpc а не lazarus
- компиляция/линковка под win серьезно ускорилась
- по поводу последнего я не понял что именно в png должно было быть. Для IDE куча картинок переведена из XPM в PNG.

На Drag and Drop погляжу.

[betatester]

По поводу картинок. Вот кусок моего кода:

Код: Выделить всё

//Устанавливаем картинки
 F1stPImage.Picture.Pixmap.LoadFromLazarusResource('1stpage');
 F4thPImage.Picture.Pixmap.LoadFromLazarusResource('4thpage');
 
 BBDetails .Glyph.LoadFromLazarusResource('application-details');
 BBExit    .Glyph.LoadFromLazarusResource('application-exit');
//Загружаем ImageList
 FDiskTVImages  .AddLazarusResource('folder');            //#0
 FDiskTVImages  .AddLazarusResource('folder-open');       //#1
 FDiskTVImages  .AddLazarusResource('folder-symlink');    //#2
 
 FDiskTVImages  .AddLazarusResource('file');              //#3
 FDiskTVImages  .AddLazarusResource('file-symlink');      //#4
 
 FX11TVImages   .AddLazarusResource('empty16x16');        //#0
 FX11TVImages   .AddLazarusResource('net-host');          //#1
 FX11TVImages   .AddLazarusResource('x11-font');          //#2
 FX11TVImages   .AddLazarusResource('x11-display');       //#3
 FX11TVImages   .AddLazarusResource('x11-x');             //#4

Картинки собираются в файл sires.lrs программой lazres. Если туда добавить файлы *.png, то они не грузятся вышеуказанными методами, потому как (дальше идёт исходный код LCL)

Код: Выделить всё

function TPixmap.LazarusResourceTypeValid(const ResourceType: string): boolean;
begin
  Result:=(ResourceType='XPM');
end;

и

Код: Выделить всё

function TBitmap.LazarusResourceTypeValid(const ResourceType: string): boolean;
begin
  Result:=((ClassType=TBitmap) or (ClassType=TPixmap) or (ClassType=TIcon))
     and ((AnsiCompareText(ResourceType,'XPM')=0)
       or (AnsiCompareText(ResourceType,'BMP')=0));
end;

Уж не знаю, какие там у Lazarus "ресурсы в PNG"...

[Павел Ишенин]

попробуй заменить
BBDetails .Glyph.LoadFromLazarusResource('application-details')

на

B := LoadBitmapFromLazarusResource('application-details')
BBDetails .Glyph.Assign(B)

[betatester]

Спасибо, Павел!

Попробую.

Однако, странно, что функции TPixmap.LazarusResourceTypeValid() и TBitmap.LazarusResourceTypeValid() пока полагают только XPM подходящим форматом...

[Павел Ишенин]

надеюсь переделаем к .26

[betatester]

Сорри, был неправ - вопрос снимается. как дурацкий...

[FedeX]

Не могу сдержать эмоций ...
Только-что скачал Лазаря 0.9.24, скомпилил прогу с горой формой размером 42 кб !!! Набросал разных кнопок, меток и прочих контролов и получил 56 кб!
Наконец-то можно делать приложения нормального размера!!! Спасибо разработчикам!

Ах да забыл сказать - использоварся набор компонент KOL_CE. Но если раньше я пробовал его использовать с Лазарем 0,9,22 то даже без МСК получалось не менее 250-300 кб, а теперь просто сказка. И проекты без КОЛа стали килобайт на 400 меньше (естественно с отключенной вставкой отладочной информации).

Вот Я просто балдею

[betatester]

Чудеса у вас какие-то - исполняемый файл размером 56КБайт? Это и вправду сказка - у меня (Linux/GTK1) пустая форма дает бинарник 1.5МБайт при Smart Link и "форма с кнопочками и контролами" - порядка 2МБ

[FedeX]

Это всё благодаря библиотеке KOL_CE. ...Ну и наверно улучшенному компилеру/линкеру...
Правда если вам надо под линух - КОЛ тут не поможет
Хотя вроде бы чего-то там вроде портируют под иксы...

[Максим]

КОЛ под Иксы не будет портирован никогда.

[FedeX]

А что тогда означает заккоментированная надпись:
//{$IFDEF Q_T} {$UNDEF GDI} {$DEFINE _X_} {$ENDIF}
в самом начале файла kol.pas ?
и подобные есть по всему модулю...
(глянул ещё)
Вот к примеру:
uses {$IFDEF WIN}messages, windows {$IFNDEF NOT_USE_RICHEDIT}, RichEdit {$ENDIF}{$ENDIF WIN}
{$IFDEF LIN}Libc, Xlib{$ENDIF}
{$IFDEF GTK}, Glib2 , Gdk2, Gtk2, pango {$ENDIF GTK}
{$IFDEF CHK_GDI}, ChkGdi {$ENDIF};

[Максим]

Попытка не пытка, конечно, но:

1) KOL является в высшей степени WinAPI-специфичной. Следовательно, при перетаскивании под Иксы должна получиться помесь с эмуляцией WinAPI на верхнем уровне (иначе вся затея смысла не имеет), и использованием GTK/QT/что-там-ещё-есть на нижнем (по смыслу, кстати, напоминающая LCL). Что будет с размерами экзешников, думаю, можно представить.

2) Приведённый выше код наводит на печальные размышления. Например, использование модуля Libc говорит о том, что, скорее всего, тянется это со времён Kylix, и работать в лучшем случае будет только под Linux/i386.

Так что не смеяться надо, а плакать

[betatester]

Ув. Максим!

Позвольте с Вами не согласиться.

Во-первых, все как раз наоборот - структура LCL более близка к WinAPI, а не к GTK Widgets - механизмы взаимодействия Widget основаны на "сигналах", а не на "Очереди сообщений" - это две принципиально разные, как по смыслу, так и по реализации, технологии. Таким образом, в LCL все это по отношению к GTK эмулируется, производя много лишнего кода.

Во-вторых, использование LIBC - это нормальная практика программирования в Linux, стандарт де-факто и де-юре. И то, что FPC/Lazarus не использует LIBC говорит опять же про большую его заточенность под WinAPI.

В третьих - не вижу никакой связи между Kylix и Linux/i386. Кстати, а что это такое? Имеется в виду что-то из ряда Linux/PPC, Linux/Sparc и так далее?