OberonCore
https://forum.oberoncore.ru/

BlackBox 2.0
https://forum.oberoncore.ru/viewtopic.php?f=134&t=6819
Страница 11 из 20

Автор:  Иван Денисов [ Понедельник, 23 Январь, 2023 10:27 ]
Заголовок сообщения:  Re: BlackBox 2.0

arisu, у вас с полями ввода уже более менее зафиксированный вариант? Мне бы надо его попробовать перенести для одного проекта на MDI сборку, хочу опробовать. Или вы еще что-то там хотите дорабатывать ближайшее время?

Автор:  arisu [ Понедельник, 23 Январь, 2023 11:01 ]
Заголовок сообщения:  Re: BlackBox 2.0

Иван Денисов писал(а):
arisu, у вас с полями ввода уже более менее зафиксированный вариант?
я всё потихоньку дорабатываю. в принципе, его уже можно использовать (я ж как раз свои контролы и использую при работе ;-), я сейчас чуть-чуть поломал, но выправлю, и ночью/утром кину сюда текущий рабочий вариант тогда, не проблема.

а вы хотите только поля ввода, или все готовые контролы? в принципе, не вижу, отчего бы тому, что есть, не заработать на MDI — надо только хитро директорию заменить, чтобы она недостающее роутила обратно в WinCFrames.

upd: упс, кажется я ошибся с ошибкой клипа, если кто-то успел заметить — сделайте вид, что не. ;-)

Автор:  arisu [ Понедельник, 23 Январь, 2023 11:13 ]
Заголовок сообщения:  Re: BlackBox 2.0

Иван Денисов писал(а):
arisu писал(а):
на ней мы видим, что размер последнего пикселя указан как `s`. очевидно, что при `s = 0` последнего пикселя быть не должно, а при любом другом s — должно. так по картинке выходит, так я и сделал в коде. ;-) а в виндоверсии, кажется, ошибка, при `s = 1` последний пиксель всё равно пропадает (надо перепроверить). если да — то это явный баг.
Ух ты, как интересно. Никогда не думал про этот пиксель. Да было бы здорово это поправить, чтобы везде было одинаково.
в виндоверсии его нет при `s = 0` и `s = 1`. я считаю, что при единичке — это баг в виндоверсии, где его и надо исправлять. будем делать вид, что мы выше bug-to-bug compatibility, или мне сделать эмуляцию виндобага при единичке тоже?

Автор:  Иван Денисов [ Понедельник, 23 Январь, 2023 11:42 ]
Заголовок сообщения:  Re: BlackBox 2.0

arisu писал(а):
Иван Денисов писал(а):
arisu писал(а):
на ней мы видим, что размер последнего пикселя указан как `s`. очевидно, что при `s = 0` последнего пикселя быть не должно, а при любом другом s — должно. так по картинке выходит, так я и сделал в коде. ;-) а в виндоверсии, кажется, ошибка, при `s = 1` последний пиксель всё равно пропадает (надо перепроверить). если да — то это явный баг.
Ух ты, как интересно. Никогда не думал про этот пиксель. Да было бы здорово это поправить, чтобы везде было одинаково.
в виндоверсии его нет при `s = 0` и `s = 1`. я считаю, что при единичке — это баг в виндоверсии, где его и надо исправлять. будем делать вид, что мы выше bug-to-bug compatibility, или мне сделать эмуляцию виндобага при единичке тоже?

Единичка я думаю, что не имеет смысла. При f.dot, есть ли этот пиксель?

Автор:  arisu [ Понедельник, 23 Январь, 2023 16:13 ]
Заголовок сообщения:  Re: BlackBox 2.0

Иван Денисов писал(а):
Единичка я думаю, что не имеет смысла. При f.dot, есть ли этот пиксель?
я и имел в виду дот, просто писал уже в терминах бэкэнда (потому что как раз оттуда вылез недавно), извините, не уточнил. винда не умеет* иначе рисовать, однако, с её точки зрения и hairline, и однодот — одинаковое. поэтому и пикселя одинаково нет.

* ну, умеет, с шаманством, но я не об том. ;-)

p.s.: красивые преривистые линии в `MarkRect()` на dimXXX делать? в винде именно так, могу приблизительно похожие dashed и тут запилить.

Автор:  Иван Денисов [ Понедельник, 23 Январь, 2023 16:49 ]
Заголовок сообщения:  Re: BlackBox 2.0

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

Автор:  Иван Денисов [ Понедельник, 23 Январь, 2023 16:55 ]
Заголовок сообщения:  Re: BlackBox 2.0

arisu писал(а):
p.s.: красивые преривистые линии в `MarkRect()` на dimXXX делать? в винде именно так, могу приблизительно похожие dashed и тут запилить.
Да, это будет просто замечательно, если сделаете ближе к тому, как было в винде.

Автор:  arisu [ Понедельник, 23 Январь, 2023 18:05 ]
Заголовок сообщения:  Re: BlackBox 2.0

вот. это винда (ну, вайн, понятно ;-):
Изображение

это линукс:
Изображение

всё то же самое. общие размеры чуть другие, потому что unit разный.

Автор:  adimetrius [ Вторник, 24 Январь, 2023 15:24 ]
Заголовок сообщения:  Re: BlackBox 2.0

Не нужно для отрисовки без мерцаний использовать OpenBuffer.
Для безотлагательной отрисовки есть Views.RestoreRoot, Views.RootOf. И если все правильно сделано (т.е. по правилам каркаса), то не будет мерцаний.
Я сделал отрисовку сложного контейнера со всем его содержимым в процессе перетаскивания мыши, и никаких мерцаний. Похоже, например, на редактор блок-схем, в котором при перетаскивании блока перерисовывается сам блок, перепрокладываются маршруты стрелочек, так чтобы не пересекать другие блоки, и перерисовываются. И при этом каждый сдвиг - как отдельная операция, т.е. много всякого из фреймворка задействовано прямо внутри активного опроса с .Input. И никаких мерцаний. И никаких OpenBuffer. Т.е. Views.RestoreRoot достаточно.

Сдается мне (как и раньше сдавалось), что гиблое это дело - StdCFrames.

(Views.RestoreRoot и ряд других не документированы вовсе, и это нехорошо)

Автор:  adimetrius [ Вторник, 24 Январь, 2023 15:32 ]
Заголовок сообщения:  Re: BlackBox 2.0

Чтобы на progress bar написать текст, не вникая в обрезания краев, нужно просто-напросто вставить дополнительный вид, и Views обеспечит вам обрезание. И это правильнее, чем лезть в механизм SetRect/GetRect.

В каркасе в одном месте (кроме Views) использовали этот механизм - для отрисовки квадратиков вокруг singleton. И этот фрагмент очень "непластичный": он опирается на неявные инварианты, и поэтому изменить характер или механизм отрисовки выделения - головная боль.

Автор:  adimetrius [ Вторник, 24 Январь, 2023 15:53 ]
Заголовок сообщения:  Re: BlackBox 2.0

Про меню и клавиши.

Задачу я понимаю так: вы хотите установить приоритетность, например, чтобы Alf+F активировала кнопку на форме, а не пункт меню.
Иногда это хочется иметь. Но это спорное решение. И не каждый пользователь будет этого ожидать.
Оно подразумевает, что окно - модально; и так и есть в Вин Лин - обычных модальных UI системах.

Но я не против, чтобы дать возможность желающим построить такой интерфейс построить такой интерфейс.

Однако нужно, кмк, поискать другое решение. То, что вы предложили, добавляет связности в систему. Т.е. меню связно с контейнерами (а может и формами еще), окнами и документами. Такая связность погубит гибкость. Сейчас StdMenus не импортирует Windows/StdWindows, т.е. нет этой связности. Импорт Containers и StdDocuments есть, но их обоих следует устранить, и это несложно разрешимая задача.

Я не знаю, на каком этапе Иван откололся от моих изменений. В моей версии StdWindows/StdDocuments сейчас есть отдельное сообщение, которое предшествует EditMsg и как раз предназначено для того, чтобы заинтересованные виды (напр. меню, но не ограничиваясь им) могли узнать о нажатии Alf+F (и любых других "аккордах") и отменить дальнейшую отправку EditMsg. При желании вы можете научить свою кнопку его обрабатывать, или сделать универсальный вид-корпус (wrapper). Полагаю, что этот механизм с доработками позволит решить вашу задачу. Но при этом не повысит связности между модулями.

Автор:  adimetrius [ Вторник, 24 Январь, 2023 16:09 ]
Заголовок сообщения:  Re: BlackBox 2.0

Иван просил высказаться про пиксели. Я их не люблю, поэтому мне нечего сказать про тот пиксель с краю линий.

То, что в ББ на уровне кадров нумеруются не точки, как у прочих, а границы между точками - это мне кажется великолепным свойством системы, ни в коем случае его нельзя терять. Но в беседе речь про интерфейс Ports.Rider, как я понял, а там пиксели. Так что там ограничение, что r - l пикселей по ширине, и рисуется внутри. Если толщина границы не помещается внутри (математически), и "вылезает" наружу - я полагаю, это ошибка реализации.

Меня беспокоит вот какая пиксельная тема.

Когда рисуются сглаженные круги, ессно, включается обрезка. Эта обрезка обрезает бледные пиксели, которые добавляет сглаживатель. (Если я прально понимаю, что тут происходит). Как решать эту проблему?
Вложение:
clipped.png
clipped.png [ 5.1 КБ | Просмотров: 1801 ]

На рисунке верхнее и левое сглаживание обрезаны (у обоих кругов), а нижнее и правое - нет. Я предполагаю (но не проверял), что в Лин некорректно рассчитываются прямоугольники обрезающие, потому что время от времени в разных местах появляется мусор шириной в пиксель по правой и нижней границе какого-нибудь вида, например текста.

Автор:  arisu [ Вторник, 24 Январь, 2023 18:44 ]
Заголовок сообщения:  Re: BlackBox 2.0

adimetrius писал(а):
Не нужно для отрисовки без мерцаний использовать OpenBuffer.
Для безотлагательной отрисовки есть Views.RestoreRoot, Views.RootOf. И если все правильно сделано (т.е. по правилам каркаса), то не будет мерцаний.
но узнать об этом можно только проштудировав исходники системы, потому что — как вы верно заметили — никаких описаний и good practices нет, увы. я простой: что в документации нашёл — то и использовал.

adimetrius писал(а):
Сдается мне (как и раньше сдавалось), что гиблое это дело - StdCFrames.
зато работает. подход не лучший, и мне тоже не очень нравится, но «beta than nothing», как говорится. рабочие контролы нужны уже сейчас, как могу — так и пилю. я ж говорил, что совершенно не против, если это всё потом выкинут и заменят на нормальное. ;-)

adimetrius писал(а):
Чтобы на progress bar написать текст, не вникая в обрезания краев, нужно просто-напросто вставить дополнительный вид, и Views обеспечит вам обрезание.
«или так.» (ц) ;-)

adimetrius писал(а):
Задачу я понимаю так: вы хотите установить приоритетность, например, чтобы Alf+F активировала кнопку на форме, а не пункт меню.
совершенно верно.

adimetrius писал(а):
Иногда это хочется иметь. Но это спорное решение. И не каждый пользователь будет этого ожидать.
здесь я склонен не согласиться: по-моему, подавляющее большинство пользователей, увидев подчёркнутую «F» на кнопке в активном окне, будет ожидать, что нажатие «Alt+F» активирует именно кнопку, а не меню. предполагать, что при активном окне приоритет всё ещё у меню — как раз необычно для современных интерфейсов. и вдобавок ещё и неудобно: я это сделал потому что задолбался жать хоткеи и попадать в меню вместо активации кнопок. конечно, можно жонглировать хоткеями, пытаясь их как-то развести без конфликтов, но мне кажется, это не то, о чём имеет смысл задумываться пользователю; да и каждый раз перепроверять все-все формы, чтобы нигде конфликтов не было…

adimetrius писал(а):
Однако нужно, кмк, поискать другое решение.
я, опять же, не против. мои хаки в основном продиктованы нежеланием на данном этапе делать большие изменения в среде, и желанием сохранять совместимость с тем, что было.

adimetrius писал(а):
В моей версии StdWindows/StdDocuments сейчас есть отдельное сообщение, которое предшествует EditMsg и как раз предназначено для того, чтобы заинтересованные виды (напр. меню, но не ограничиваясь им) могли узнать о нажатии Alf+F (и любых других "аккордах") и отменить дальнейшую отправку EditMsg. При желании вы можете научить свою кнопку его обрабатывать, или сделать универсальный вид-корпус (wrapper). Полагаю, что этот механизм с доработками позволит решить вашу задачу. Но при этом не повысит связности между модулями.
да, это именно то, чего не хватает. но его в текущей версии нет, поэтому я сделал такой вот хак. я могу, конечно, пуститься во все тяжкие и переделывать более глубоко — но это довольно быстро приведёт к тому, что мой код станет совершенно бесполезен для текущей «общей» версии. я бы не очень этого хотел, потому что активных разработчиков у BBCB и так немного, дробиться ещё сильней мне бы не хотелось. я планирую свой форк, конечно, но по мере сил стараюсь и основному помогать.

adimetrius писал(а):
Иван просил высказаться про пиксели. Я их не люблю, поэтому мне нечего сказать про тот пиксель с краю линий.
однако это важно для рисовалок. вот я заточил рисовалки под «полная линия», попробовал их на виндоверсии — образовались дырки. иногда можно просто линию чуть растянуть, конечно, но иногда это может привести к «лишним пикселям». пусть hairline — довольно специфический инструмент, но линия шириной в dot — уже довольно часто используется.

adimetrius писал(а):
Но в беседе речь про интерфейс Ports.Rider, как я понял, а там пиксели. Так что там ограничение, что r - l пикселей по ширине, и рисуется внутри. Если толщина границы не помещается внутри (математически), и "вылезает" наружу - я полагаю, это ошибка реализации.
однако линии шириной более одного пикселя вполне вылазят за «границы», и это даже на приведённой мной картинке показано как допустимое.

adimetrius писал(а):
Когда рисуются сглаженные круги
для начала, в рисовалке эллипсов ошибка: они рисуются на один пиксель шире и ниже, чем должны. там надо добавить `-1`, чтобы было как в оригинале.

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

а насчёт мусора — это, похоже, проблемы округлений из «универсальных» координат в пиксельные. по уму, финальные «пиксельные» порты должны работать не с челочисленными координатами пикселей, а хотя бы с 24.8 fixed point (а лучше и вовсе с плавающими). да и остальные координаты лучше бы плавающими были. с жёсткой пиксельной сеткой куча проблем.

p.s.: впрочем, лично я не фанат сглаживания вообще, и при наличии выбора предпочитаю просто его оторвать.

Автор:  adimetrius [ Вторник, 24 Январь, 2023 23:52 ]
Заголовок сообщения:  Re: BlackBox 2.0

arisu писал(а):
но узнать об этом можно только проштудировав исходники системы

Ну, тут я бы двояко ответил: с одной стороны, да, нужно задокументировать. Неплохо было бы и статейки, типа Obx, как сделать то и сё (иметь бы только перечень "тоисёх").
С другой стороны - фон Нейман продвигал мысль, что лучшее и простейшее описание сложной системы (напр. мозга) - это сама система. Так что тексты ББ - это самый лучший StackOverflow. Только не аннотированный.

arisu писал(а):
как могу — так и пилю.

Напрашивается: "пилите, шура, пилите" (с). Если надо - знач надо, пилите.

arisu писал(а):
подавляющее большинство пользователей

"Этот - в книжку тычет пальчик", а подавляющий пользователь - давит мышку. Все эти аккорды - для профи. Имхо. Т.е. для нас, любимых, а значит - что может быть важнее )

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

arisu писал(а):
«пиксельные» порты должны работать не с челочисленными координатами пикселей, а хотя бы с 24.8 fixed point (а лучше и вовсе с плавающими)

А чем вам универсальные координаты - не числа с фиксированной запятой?

Отбирать OpenBuffer не надо, да и замучаешься; нормально как есть: написано не трогать руками, а решишь трогать - на твой страх и риск, может все "поехать".

Про привязку к .dot. Если я правильно понимаю, привяжетесь к Frame.dot - и ваши виды не будут поддерживать масштабирование. Оно задается через Frame.unit.
И тут возникает вилка: с одной стороны, чтобы масштабировалось, надо считать в универсалях и привязываться к .unit, а чтобы рамка толщиной третьмиллиметра со всех сторон была по 1 пикселю (а не 2 с одной, а остальные по 1, да еще и какая будет толстой - зависит от положения в контейнере) - надо учитывать .dot. (Меня на такую красоту не хватает - все эти расчеты и учеты программировать.)

Автор:  arisu [ Среда, 25 Январь, 2023 09:09 ]
Заголовок сообщения:  Re: BlackBox 2.0

adimetrius писал(а):
С другой стороны - фон Нейман продвигал мысль, что лучшее и простейшее описание сложной системы (напр. мозга) - это сама система. Так что тексты ББ - это самый лучший StackOverflow. Только не аннотированный.
с этим я совершенно не спорю. однако тут есть небольшой нюанс: документации или не должно быть вообще, или она должна быть как можно полнее. в первом случае я бы, понятно, не стал искать способ в документации, и полез рыть исходники. а так я предположил, что в документации — раз она есть — способ описан, и взял то, что нашёл. процедуры для root в документации упомянуты, но одной строкой: типа они есть. обычно так упоминают то, что использовать не рекомендуется. а `OpenBuffer()` описано довольно подробно. выбор, в принципе, был очевиден.

вообще, BBCB очень нужен документ типа: «обзор системы для испорченых другими средами, или как отучиться постоянно лазить в кишки и полюбить высокоуровневое программирование». у BBCB странности для «ненулевого новичка» начинаются уже с терминологии: «view -> frame -> root? wtf?! ой, ещё какие-то контексты упоминаются? а это что? упс, InstallFrame, оказывается, не перманентна, её можно и нужно вызывать в `Restore()`? ЧТОТУТПРОИСХОДИТААААА!!!1» это я к тому, что переобучать несколько сложнее, и надо немного иначе, чем обучать с нуля. если я когда-нибудь найду лишние хотя бы часов пять в сутках — напишу, наверное. прежде всего потому, что такая книга нужна лично мне. ;-)

adimetrius писал(а):
Напрашивается: "пилите, шура, пилите" (с). Если надо - знач надо, пилите.
я получаю от этого некоторое извращённое удовольствие. ;-)

adimetrius писал(а):
"Этот - в книжку тычет пальчик", а подавляющий пользователь - давит мышку. Все эти аккорды - для профи. Имхо. Т.е. для нас, любимых, а значит - что может быть важнее )
ну, не скажите, не скажите. когда пользователь (по желанию, или по необходимости) переходит из разряда casual дальше — он тоже начинает ценить шорткаты. но в принципе, под пользователем я имел в виду того, кто в данный момент форму использует. мы же тоже часто просто пользователи. ;-)

adimetrius писал(а):
arisu писал(а):
а насчёт мусора — это, похоже, проблемы округлений из «универсальных» координат в пиксельные
Сомневаюсь, потому что в Вин не наблюдается.
хм. если вы сможете дать минимальный пример, где оно проявляется, и как этого добиться — я с удовольствием посмотрю, в чём причина. у меня пока что из мелкобагов рисовки только один, который я помню ещё по винде пятнадцать лет назад, поэтому и внимания не обращаю.

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

adimetrius писал(а):
arisu писал(а):
«пиксельные» порты должны работать не с челочисленными координатами пикселей, а хотя бы с 24.8 fixed point (а лучше и вовсе с плавающими)
А чем вам универсальные координаты - не числа с фиксированной запятой?
нененене, я не про это, я про те порты, которые в LinPorts и так далее. в смысле, самая нижняя реализация, её надо переделывать с пиксельной сетки на большее разрешение. мы постоянно путаемся в этом, надо какие-нибудь разные термины ввести, что ли.

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

adimetrius писал(а):
Отбирать OpenBuffer не надо, да и замучаешься; нормально как есть: написано не трогать руками, а решишь трогать - на твой страх и риск, может все "поехать".
а без этого не сделать правильное сглаживание: там в любом случае нужно сначала строить сцену, а потом растеризовать, и при этом надо ещё делать гамма-коррекцию, иначе будут сопли и неравномерность вместо иллюзии бо́льшего разрешения. вот статья McSeem про необходимость гаммы.

adimetrius писал(а):
Про привязку к .dot. Если я правильно понимаю, привяжетесь к Frame.dot - и ваши виды не будут поддерживать масштабирование. Оно задается через Frame.unit.
да, dot вроде как (по документации) зависит от point, а не unit. но поскольку в стандартной поставке нет масштабирования по какому-нибудь Ctrl+Wheel, то… ;-)

adimetrius писал(а):
И тут возникает вилка: с одной стороны, чтобы масштабировалось, надо считать в универсалях и привязываться к .unit, а чтобы рамка толщиной третьмиллиметра со всех сторон была по 1 пикселю (а не 2 с одной, а остальные по 1, да еще и какая будет толстой - зависит от положения в контейнере) - надо учитывать .dot. (Меня на такую красоту не хватает - все эти расчеты и учеты программировать.)
да, это, конечно, решается качественной библиотекой aa rendering. но у BBCB такой всё равно в поставке нет. ;-)

это у нас получается эхо конфликта «рисование шрифтов m$-style vs рисование шрифтов apple-style». m$ делает неправильно, но за счёт рихтования по пиксельной сетке выглядит (выглядело во время оно) лучше, чем «размазня» у apple.

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

Автор:  adimetrius [ Четверг, 26 Январь, 2023 00:36 ]
Заголовок сообщения:  Re: BlackBox 2.0

Кстати, про аккорды. Универсальные контейнеры в Containers уже имеют частично функциональность для клавиш-сокращений, типа &Find. Но они срабатывают без Alt и тогда, с т.зр. пользователя, когда фокус не в поле ввода. Делается это с помощью Properties.ControlPref так:
Цитата:
The ControlPref message is sent first to the actual focus view and then to all other views in the container until one of the views sets either the getFocus or the accepts bit or both. If none of the views respond to the message, the character is forwarded to the focus view.

Т.е. получив Controllers.EditMsg, всем своим элементам контейнер "предлагает" введенную литеру. Первый, кто ответит "беру" - получает следом Controllers.EditMsg. И только если никто не ответил - контейнер отправляет EditMsg своему фокусному элементу. Поле ввода, ессно, отвечает "беру" про любую литеру, поэтому &Find не срабатывает.

Автор:  arisu [ Четверг, 26 Январь, 2023 06:08 ]
Заголовок сообщения:  Re: BlackBox 2.0

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

кстати, из-за того, что меню вызывается напрямую из преобразователя клавиатурного события, я не вижу способа сделать как-то красивей. ну да, можно в StdMenus сделать хук, а не прямое обращение к StdWindows. но это, по-моему, мы просто заметаем мусор под ковёр. надо что-то кросивое придумать, как рыбов.

Автор:  arisu [ Четверг, 02 Февраль, 2023 17:53 ]
Заголовок сообщения:  Re: BlackBox 2.0

и хитрый вопрос: а если я хочу подменю, а оверлей только один, как быть, куды бежать? делать оверлей размером чтобы всё влезло, и руками там менеджить views? не, я не против, просто может я чего не заметил полезного?

Автор:  Иван Денисов [ Четверг, 02 Февраль, 2023 18:21 ]
Заголовок сообщения:  Re: BlackBox 2.0

arisu писал(а):
и хитрый вопрос: а если я хочу подменю, а оверлей только один, как быть, куды бежать? делать оверлей размером чтобы всё влезло, и руками там менеджить views? не, я не против, просто может я чего не заметил полезного?

Антон предусмотрел, что вот таких видов может мыть много. Если вы про это.
Код:
StdDocuments.InsertBar(doc, StdDocuments.top, mainLine1, NIL, TRUE, NIL);
StdDocuments.InsertBar(doc, StdDocuments.top, mainLine2, NIL, TRUE, NIL);

Автор:  arisu [ Четверг, 02 Февраль, 2023 19:27 ]
Заголовок сообщения:  Re: BlackBox 2.0

Иван Денисов писал(а):
Если вы про это.
Код:
StdDocuments.InsertBar(doc, StdDocuments.top, mainLine1, NIL, TRUE, NIL);
StdDocuments.InsertBar(doc, StdDocuments.top, mainLine2, NIL, TRUE, NIL);
ненене, это бары — типа верхнего меню и статус-строки. а оверлей — это попап такой (ну, то, что вылазит, когда Alt+F нажать, например). и оверлей — я так понял — может быть только один. что мешает сделать вложеные подменюшки.

Страница 11 из 20 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/