Linux support

Среда PascalABC.NET
#1

А теперь более сложная тема.

К сожалению, программы написанные на PascalABC.NET 3.0 очень пложо работают под mono и Linux. В частности любое использование модуля ABCObjects или процедуры Redraw из модуля GraphABC приводят к крэшу изза проблем с отрисовкой не в том треде(?).

Вторая проблема, это работа keypressed при наличии графического окна. кнопки приходится нажимать в консольном окне при том что действие происходит в графическом.

Третья проблема это мапинг кнопок. #71 и прочие обозначения стрелочек Привычные ещё с турбопаскаля не работают под Linux.

1 лайк
#2

Да, это всё непереносимо и работать не будет.

#3

А вам не кажется,странным заявлять совместимость с Linux, И не делать ничего, чтобы всё работало нормально? Может быть найти энтузиаста, который поможет?

#4

Да, давайте. Коды открыты, разработка свободна. Любой может присоединиться:

Компилятор совместим, графические библиотеки - нет. Их надо полностью переписывать.

#5

Да, я, пожалуй, попробывал бы. Я, правда, не столь хорошо помню паскаль, но думаю, осилил бы библиотеку примитивов. Однако, я не нашел документации и плана развития.

В АВС 3.0 нам по умолчанию доступен практически весь дотнет, это здрово, конечно, но плохо соответствует принципу наименьшего удивления. При этом добавляя своей магии. Так, ребёнок, осваивая императивный стиль традиционного паскаля вдруг подключается к событию onMouseDown, которое срабатывает псевдопараллельно. Однако из всего многообразия результатов дотнетовских событий мыши получает строго 2 варианта: нажата левая кнопка мыши, или нажата правая при ненажатой левой.

Также хотелось бы узнать команды препроцессора, чтобы отделять виндовый код, от линуксового. Похоже, что проблемой keypressed кто-то занимался, потому что в коде есть такая вещь как CurrentIOSystem однако это не влияет на то, как работает keypressed в Linux.

Хотелось бы побольше узнать про магию из GraphABC

//ne udaljat, IB 7.10.08

//с дополнениями 2015.01 (mabr)

{$apptype windows}

и как это сочетается с CRT

unit CRT;

{$apptype console}

И, самое главное, как должно сочетаться.

Буду рад присоединиться, если моя помощь пригодится.

#6

Гипотеза: графические модули можно реализовать полностью на .NET и, соответственно, не заботиться о зависимости от платформы.

#7

Они и так реализованы на дотнете. Задача их ухудшить так чтобы они одинаково работали из Паскаля.

#8

Модуль GraphABC надо полностью переписывать. Возможно, используя другие примитивы для инициализации. Там при рисовании во внеэкранном буфере я использовал unsafe-код. Вероятно, поэтому и не работает под Линуксом.

Вообще, WinForms плохо работает под Линуксом.

И - у нас там два потока, графические команда - я помню - выполняются в основном, а окно создается во втором. Возможно, в Линуксе это тоже не работает или работает не так.

Но основное - это внеэкранный буфер конечно. Я пробовал рисовать на Image, но это оказалось страшно долго, зато он запоминает изображение при сворачивании окна. Может, под Линуксом это сгодится.

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

CurrentIOSystem никак не связана с Linux. KeyPressed никак не связана с CurrentIOSystem. И KeyPressed мы не любим, поэтому сами реализовывать не будем.

GraphABC никак не сочетается с CRT и никогда сочетаться не будет. Всё лень запретить. CRT - это консольный режим, GraphABC - оконный. Вместе они не живут.

Втрая версия - там у нас работают два потока

#9

Может, впилите нечто подобное?

Пишут, что есть пара кроссплатформенных фреймворков.

#10

Прочитал GraphABC. Переписать его, наверное, неплохая идея, хотя для воссоздания всей функциональности работа потребуется большая.

Из замеченного:

Как-то не все вызовы рисуют и в gr и в gbmp (В частности Picture.Draw)

Объект f, который используется как мьютекс(?) имеет, конечно, шикарное имя, и иногда перекрывается локальными переменными. Он, кстати, используется тремя способами,

  1. Monitor.Enter(f);
  2. (Un)lockGraphics, инкапсулирующая пункт 1, но использующаяся лишь в паре мест.
  3. lock f do, менее популярная чем п.1 альтернатива.

Я обнаружил процедуру FullRedraw которая отлично работает в Линуксе. и прекрасно заменяет Redraw, Однако UnlockDrawing использует внутри себя именно Redraw.

Я не понимаю, с чем связана довольно запутанная система инициализации, Вроде бы реально работает только __InitModule, однако в коде дополнительно присутствует __InitModule__ и замечательная переменная __initialized Такая же ситуация в GraphABCHelper.

Хотя я разделяю идею, что Код - лучшая документация. Всё же для библиотек нужно что-то ещё помимо кода самой библиотеки. например демонстрационное приложение, в котором подробно и по порядку покажут работу всех процедур и функций. Сейчас программирование графики на PascalABC выглядит как хождение по минному полю, с периодическими порталами в C#, чтоб сделать что-то интересное.

#11

И не мерцает при перерисовке?

#12

Эти функции используются при запуске с ускорением и вызываются из PABCRtl.dll

#13 
gr.DrawImage(bmp,0,0);

По идее не должен мерцать. Возможно не хватает скорости. Действительно, плавно едущий по экрану объект странно ведёт себя по краям, однако те части кадра, которые не изменили цвет не мерцают 100%.

Краевой эффект выглядит так, будто вместо отрисовки кадра 1, а затем 2, рисуется несколько переходных. На скриншотах этого не видно, однако на видео можно наблюдать то, что видно и глазом тоже. https://drive.google.com/file/d/0B0rwvTeZdtLiejlENTJxOENOc1k/view?usp=sharing