One crazy idea...

← →
Boguslaw (2003-05-29 00:00) [0]

This could be possible crazy idea for many , but...
Could XCL be reactivated ? I mean just a few fixes to make it compatible with Free Pascal Compiler, another few to allow dual compilation for Windows and Linux (it could be possible since it is based on drawing on canvas , not creating controls from WinAPI) and at least to make opaque - to be compatible with KOL (compatible interface )

For example :

NewTimer(...)
{
Result := XTimer.Create(...);
}

This way we could make KOL program in Windows and later after a small fix compile it in Linux (and it will be working with only X11 library , not using eighter GTK+ nor QT libs)

Is this crazy ?

Boguslaw

← →
Кладов (2003-05-29 08:32) [1]

I suppose that it is possible to make an extension of KOL based on XCL (just grabbing Paint code from its classes and adding self-paint capabilities for KOL objects). In such case we could obtain a possibility to compile KOL projects for Linux (and may be for other unix-based OS). But what about object to class compatibility? If Free Pascal become "objects" compatible (earlier we"ve found that it does not support for properties in objects, doesn"t it?).

← →
Boguslaw (2003-05-29 18:28) [2]

Vladimir,

It"s no matter since original XCL was class based and even then programs were small (not so small like with KOL eighter) Anyway this could be the best GUI library for Linux , becouse program I suppose to be under 100k in size in Linux without needs for GTK+ or QT. FPC 1.1 can compile XCL when we trhow away all MFC code and replace assembler functions by pascal ones. The only problem with Free Pascal Compiler 1.1 is that TObject is linked to executable in all cases (even not using TObject class hierarchy) which is a bug and I"m pretty sure that FPC creators would fix this immediately (this is not related to objects which they don"t like)

It seems to be more possible then I thought.

Boguslaw

← →
Кладов (2003-05-29 19:25) [3]

I do not think that it is very good to reactivate XCL as stanalone library. Many projects already made with KOL, and it would be better to get a capability for KOL projects to migrate to Linux (and Unix) without serious changes in projects theirselves.

My thought is that it is possible to create a small utility (KOL2FPC) which converts KOL.PAS to KOLFPC.PAS on base of simple directives inserted into KOL.PAS. E.g.:

{#Remove[} this text will be removed {#]Remove}
or shorter: {#-[} ... {#]-}
{#Insert[}(* this text is inserted *){#]Insert}
or shorter: {#+[}(* ... *){#]+}
{#Include filename_to_insert_to_KOLFPC.pas}
{#Replace[@ Self][Self]}
{#Replace[= object(][= class(]}
{#Noreplace[@ Self]}

etc.

An advantage is that in all future changes in KOL.PAS, new version of KOLFPC.PAS can be obtained just running KOL2FPC again, no synchronization problem, no work duplicating.

← →
Boguslaw (2003-05-29 22:55) [4]

Vladimir,

The main problem is in fact that no one accept poor object style in the way that Delphi does.So the idea is to make xcl with kol interface . This eliminate porting issues becouse XCL porting is much less pain that porting KOL to Linux (which in fact would be a process of creating KOLLINUX from scratch) At least I think that after a few fixes I could compile XCL simple samples with FPC under Windows ,and after more changes in xCanvas it maybe compilable under Linux too.
The problem may be in font manipulation and of course X11 API knowledge.If someone has experience with X11 API to look if this is really possible ,please do that and let us know !

Boguslaw

← →
Кладов (2003-05-30 08:03) [5]

Anyway xCanvas implemented using Windows API and it must be rewritten for X11 API. This is the same as for KOL"s TCanvas. But there are a lot of projects, may be hundreds already, made in KOL. And it would be very useful to create KOLLINUX so that almost without any changes most of such projects (if not Windows-specific itselves) could be mirgated just recompiling/rebuilding it. And this does not matter if we use any library (QT, GTK or something else) or work with X11 directly. Or even if create text-mode windows either for DOS or Unix.

← →
Gandalf (2003-06-02 11:26) [6]

Мое понимание этого вопроса такое, не надо воскрешать XCL, надо латать KOLnMCK, и довести до мульти платформы - а код само отрисовки можно почерпнуть, это не проблемма. Но часть кода все равно будет АПИ зависимо, потому активно использувать надо условную компиляцию, от себя добавлю что не плохобы сейчас добавить условную компиляцию для пока версии Вин и IE под которой код работает. Т.е. типа {$DEFINE IE_VER=...}
{$DEFINE WIN_VER=...} и код оформлять в виде {$IFDEF IE_VER} ну и т.д. а если {$IFELSE WARNING="Incompatible IE version"} (вроде так, а может и error бросать). Конечно нельзя забывать про константу WIN_ANY, IE_ANY. Тогда компилится по любому. Это позволило бы указывать платформено зависимые участки кода (которые так не любит Кладов).

← →
Кладов (2003-06-02 13:27) [7]

> Мое понимание этого вопроса такое, не надо воскрешать XCL,
> надо латать KOLnMCK

Абсолютно согласен. Не перетаскивать же все проекты опять из KOL в XCL. А рисовальные процедуры передрать как раз несложно. Вот только подозреваю, что не много мы там нарисуем. XCL дошел максимум до некоего подобия TStringGrid, а ведь надо обеспечить отрисовку еще кучи развитых контролов, вроде listview или treeview. Впрочем, можно опять же делать несколько версий - для поддержки разных библиотек (той же QT). Моя (маленькая) мечта, чтобы можно было делать окна в том числе для текстового режима, все равно, под ДОС, ОС/2 или Юникс, и при этом для компиляции программы в нужном режиме достаточно было бы просто поменять опции компиляции :)

> условную компиляцию для пока версии Вин и IE

разве только предупреждение/ошибку генерировать, больше никакого применения не вижу. Программист ведь и так знает, что он использует. Если ошибку не кидать, все равно ведь откомпилится. А потом программу, которая только для IE4, запустят на машине IE3, и что скажут "умные" юзеры? Дурак программист, скажут, программировать не умеет :) А вот если программист сам вставит в код, который выполняется, проверку версии вин/ие, и честно скажет, что мол, то-то и то-то не установлено, работать не будем - это уже серьезно. Но опции-то тут при чем?

One crazy idea... Найти похожие ветки