OberonCore

Надо переделывать все по аналогии с тем, как сделан сейчас немодальный диалог выбора файлов, устанавливается колбэк, который вызывается при выборе цвета. Придётся кое-где переделать в каркасе эти места.

Стратегически лучше оставить узкую стыковку элементов, и не факт, что не придется какими-то другими средствами в ББ потом делать эти элементы, а также все ещё стоит задача поддержки старых проектов на базе 2.0. Возможность делать нативно выглядящие формы тоже замечательная. Так что это не про BlackBox 2.0. Сейчас надо оставить максимально совместимо всё с 1.7.2 и документировать изменения. Убрать баги. Ну и параллельно, конечно, будут существовать уже новые контролы, как наработка для ваших проектов и будущих версий. Просто пока давайте отделять.

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

«я перечитал Кинга, и понял что так и было.» (ц) Олег Медведев.

короче, я перечитал Controls и WinCFrames, и понял, что делал всё неправильно. так что пилю заново. извините, но никак по пути не смог удержаться от этого. очень уж нежню я люблю Window Maker (и NextSTEP через него).

также сильно прошу добавить в StdCFrames вот это:

оно совершенно ничему не мешает, ничего не ломает, а мне надо до зарезу чтобы редактор нормально запилить. ну, корявость, конечно, ради сохранения API, в идеале просто сигнатуру `KeyDown` поменять надо; но Совместимость Über Alles.

ну, и в Controls везде вызовы поменять, там их немного.

в принципе, за исключением вышеприведённого нюанса меня CFrames особо не ограничивают пока. может со временем даже undo/redo в редакторе будет нормальный (я пока не буду делать TextModel, наверное, и заморачиваться с прочей ундо-механикой, но потом надо будет; пока мне просто не очень ясно, не придётся ли снова расширять CFrames чуть-чуть).

ещё не хватает штатных сообщений MouseEnter/MouseLeave, чтобы сделать нормальный hover. ну да, MouseEnter можно через `Controllers.PollCursorMsg`, но MouseLeave нету. а опрашивать каждый раз в Restore «где мышь» как-то некультурно, получается помесь рисовалки и менеджера состояний (и, кстати, это как раз будет тот патологический пример, когда каждый контрол постоянно вызывает `.Input()`, и из-за пауз всё тормозит).

а. ещё я не понял точно, поддерживает ли система для форм прозрачный double buffering. кажется, нет — потому что мне удалось рисованием кучи линий заставить текст радиокнопки моргать. жаль, если так: рисование чего-то сложного в контролах тогда off limits.

p.s.: омики недодали dashed lines! хоть бы dashed hairline для рисования фокуса бы дали…

Я высказался о своем отношении к StdCFrames, его интерфейсом не дорожу.
Но, размышляя о высоком - если уж убер алес, то вставить опрос клавиатуры на предмет модификаторов - было бы лаконичнее всего, только в редакторе, и на производительность (шумелку) не повлияет. Вам ведь еще придется дифференцировать, что вызывать из Controls: KeyDown или KeyDownEx. Или и то, и другое?
Но, опять же, дело ваше.
Захотите отмену, захотите поддержку свойств - придется полный набор процедур Handle..

Вот еще одни грабли WinCFrames. Винапишные приборы управления несовместимы с двойной буферизацией. Из того, что мне в интернете удалось найти - вообще никак не совместимы. За 30 лет их жизни никому не удалось. Качественно сделано .
Поэтому в ББ сделали так: покуда рисуются ББ-виды - двойной буфер включен. Как только рисуется кадр для винапишного - двойной буфер выключается. Это прекрасно видно в WinCFrames, там вызовы r.port.CloseBuffer выделены жирным. Предполагаю, было так: Некто начинал плеваться: куда девалась буферизация? копался, искал причину, находил, ругался на идиотов, которые вставили это отключение сюда, убирал отключение - и тогда вообще все безнадежно ехало. Он опять ругался, теперь на других идиётов, и возвращал отключение на место. После Н итераций сделали жирным, чтобы намекнуть, что это неспроста здесь.

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

ПРо мышь предлагаю отдельно продолжить https://forum.oberoncore.ru/viewtopic.php?f=134&t=6888

но как я выше где-то в теме писал — это идеологически неверно, потому что получает данные из двух потенциально независимых источников. если я буду, например, делать action replay путём посылки синтезированых сообщений, то информация о модификаторах должна из сообщений и браться, реальная физическая в этом случае неактуальна. (пример с потолка, просто чтобы показать, что два источника — не комильфо.)

нет, только `KeyDownEx`. стандартная (неперекрытая) `KeyDownEx` — просто вызывает `KeyDown`, и для старого кода всё выглядит так, как будто ничего не изменилось. костылик, да — но минимальной болью, так сказать. в смысле — я это у себя уже сделал, оно работает just as planned.

ну да, я поэтому пока и отложил на потом (возможно, на «никогда», и просто сделаю отмену в строчных редакторах контролов независимой от остальных отмен).

да, про это я знаю. но у меня-то моргают StdStdCFrames — и я не понимаю, почему. я пока не заморачиваюсь, и рисую пиксмап (который с точечкой) для RadioButton через кучу горизонтальных линий и точек (ну, у меня в сишном тулките так было, я для быстроты просто код перетащил, потом сделаю нормально). и вот если я его рисую ДО текста — то текст моргает. а если после — то нет (ну понятно, долгая операция последняя). то есть, буферизацию, получается, отключают где-то раньше, ещё до вызова рисовалок CFrames? я просто не очень пока в курсе потрохов настолько глубоко.

идеологически согласен. Инструментарий для тестирования тоже был бы гораздо проще, если в одном сообщении. Синтезированных, правда, в ББ нету - тут все они, как в бане, равносинтезированные ).



Поищите по тексту .CloseBuffer, но мне не попадалось нигде подозрительного, кроме WinCFrames.

и тут, кстати, мы с размаху натыкаемся на чудесные циклы с `Input`. например, PushButton делает такой цикл, пока мышь не «отжата». но всё равно читать клавиатуру напрямую в `KeyDown` неправильно. ;-)

ну, оно да, просто я не могу придумать нормальных слов для «синтезированых из непосредственного ввода пользователя», и «синтезированых из каких-то других данных». ;-)

спасибо. ладно, «будем искать.» (ц)

страшнопикча. ну так, чисто посмеяться — они там многие в мак-формате, а для него в оригинале есть коекакерская виндорисовалка, которую я ещё более укоекакерил за пол-часика. это, конечно, надо в хук и платформозависимо рисовать. а то надоело кнопочки красить. ;-)

кстати, очень не хватает в портовых наездниках (по-моему, крутой термин получился!) операции `BlitPixmap()`. тогда можно было бы делать платформо-независимые читалки разных графических форматов.

Здорово, что вы занялись стандартными инструментами. Модуль StdCFrames — это закрытый модуль Блэкбокса и очень мало людей делают свои расширения инструментов. Также и Антон сказал, что не дорожит этим модулем, так что как я понимаю, он не возражает. Так что лучше поменять аргументы, чем усложнять интерфейс. Это всё же не смена интерфейсов системных модулей.

спасибо. я их переписываю, потихоньку подглядывая в WinCFrames сейчас. выношу движок редактора строки в отдельный объект, чтобы использовать везде одно и то же, а не копипасту, делаю общую рисовалку для всяких списков… короче, получается что я эмулирую наличие «родных» контролов по сути. ;-) но в принципе — не самый плохой вариант, не скажу, что я так уж сильно недоволен: особых неудобств пока что не испытываю.

надеюсь, против NextSTEP-подобного вида возражений нет? он простенький, возможно несколько старомодный — но по-моему, выглядит вполне нормально, и главное: не бросается в глаза и не мешает. и обычный интерфейс винды-95 на него немножко похож, так что у людей не будет большого шока от кардинальной смены внешнего вида форм при переходе. конечно, я делаю так, чтобы всё можно было через подобие скинов перекрасить.

ну, раз так — то с удовольствием вместо костылика добавлю аргумент, конечно.

я тогда ещё один пустой метод туда докину, можно? мне удобно его иметь в общем предке для всех CFrames, чтобы не городить лишние WITH.

а, насчёт даблбуфера: это я тупой и попутал два случая. с обычной рисовалкой всё нормально. а вот когда я рисую из `REPEAT f.Input … UNTIL ~isDown` — вот тогда мерцает всё адово. что, в принципе, логично: этой штуке надо рисовать прямо на экран, иначе ж не видно ничего будет. и двойная буферизация, похоже, слетает (в смысле, среда её выключает как раз с учётом возможности подобных ситуаций).

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

С Антоном мы утвердили для настроек некоторый формат. Там он и используется через переменную skin.
Просьба делать так, чтобы можно было путём настроек вернуть старый вид. Он уже много кому пришелся по душе.


Также я когда внедрял расчёт отступов поправил. Можете глянуть в ветке.




Добавьте, это не влияет на существующие расширения.

небольшая проблема в том, что от старого кода там осталось ничего, я в буквальном смысле все пишу заново. старые рисовалки там будут только мешать и мусорить.

у меня есть альтернативное предложение: я заканчиваю свой NextSTEP-alike, а потом на его основе перепиливаю прошлый вид, и мы его кладём в другой модуль. а при инициализации можно будет выбрать или тот, или другой, конкретную механику такого выбора потом утрясём. можно будет менять их на лету сменой фабрики просто, и «новооткрытые» формы будут в новом виде.

перепилка у меня довольно масштабная: я выделяю куски, которые нужны нескольким компонентам (редактор, рисовалки списков, etc.) в отдельные объекты (но не view); а собственно контролы потом занимаются тем, что считают координаты, рисуют рамочки, и для остального используют эти «псевдовьюшки» (хихи, я, получается, эмулирую наличие «системных контролов»). я как раз в процессе написания утрясаю интерфейсы, а потом модуль с «новыми старыми рамочками» пересадить на эту механику будет несложно, чисто немного почти механической работы. заодно эти же штуки люди смогут использовать чтобы делать другие внешние виды, не ограничиваясь просто перекраской.

возможно, эти мои «псевдовьюшки» вообще будет иметь смысл потом перенести в `StdCFrames`, потому что они «общеупотребительные», так сказать. соответственно, `StdCFrames` будет содержать большинство общей механики, необходимой для создания своего вида, а конкретизироваться она будет уже в модулях-реализациях.

p.s.: существующий код всё равно в куче мест переменную скинов игнорирует, и использует прибитые гвоздями цвета. заодно и это починю.

Количество проклятых из-за этой (казалось бы) мелочи "софтоделов" не поместится в INTEGER...

в общем, черновую реализацию нового движка сделал, реализовал поверх неё тот же набор контролов, что и был. комбобокс по дороге получил нормальный рабочий редактор, а листбокс научился показывать попап при маленькой высоте. как и планировалось, главную работу делают EditorCtl и ListCtl, а основные фрэймы только их пинают. попап понимает размеры своего окна, и умеет правильно работать, если высота меньше чем ему надо.

теперь надо сделать самое сложное: нормальный интерфейс к EditorCtl и ListCtl, чтобы они брали цвета, некоторые размеры и отступы не из глобала скинов — и тогда можно на них переводить прежние контролы. и унесу их в StdCFrames, им там самое место. на самом деле надо бы в отдельный модуль, но ведь опять скажут что не надо новый модуль заводить. ;-) или может всё-таки согласитесь добавить StdCFramesMecha? ну некрасиво же эти конкретные кишки пихать в StdCFrames, который по сути абстрактный интерфейс же…

p.s.: ну, или StdCFramesGuts, если фанатов ОБЧР тут нет. ;-)

пока я буду ждать сохранения десктопа, у меня внуки уже бороды отрастят — несмотря на то, что у меня и детей-то нет. ;-) пришлось применить любимый навык «пишу патчи не приходя в сознание», и накоекакить себе. не покажу, потому что сделано через задницу задницы задницы, и падает, если неаккуратно чихнуть. но периодически с задачей справляется, и мне этого достаточно.

я не в претензии, если что, понятно, что времени и ресурсов на всё не хватает. я к тому, что если вдруг это специально для меня где-то вверху TODO стояло (ну могу я помечтать, ну!), то можно смело спихнуть в самый низ: я пока обойдусь своим хаком.

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

Такие обещания двигают развитие Блэкбокса, так что я всё же починю, когда доделаю по работе две важные задачи.