OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 19:21

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 387 ]  На страницу Пред.  1 ... 8, 9, 10, 11, 12, 13, 14 ... 20  След.
Автор Сообщение
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Понедельник, 23 Январь, 2023 10:27 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
arisu, у вас с полями ввода уже более менее зафиксированный вариант? Мне бы надо его попробовать перенести для одного проекта на MDI сборку, хочу опробовать. Или вы еще что-то там хотите дорабатывать ближайшее время?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Понедельник, 23 Январь, 2023 11:01 

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

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

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


Последний раз редактировалось arisu Понедельник, 23 Январь, 2023 11:23, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Понедельник, 23 Январь, 2023 11:13 

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Понедельник, 23 Январь, 2023 11:42 
Аватара пользователя

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Понедельник, 23 Январь, 2023 16:13 

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Понедельник, 23 Январь, 2023 16:49 
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Понедельник, 23 Январь, 2023 16:55 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
arisu писал(а):
p.s.: красивые преривистые линии в `MarkRect()` на dimXXX делать? в винде именно так, могу приблизительно похожие dashed и тут запилить.
Да, это будет просто замечательно, если сделаете ближе к тому, как было в винде.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Понедельник, 23 Январь, 2023 18:05 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
вот. это винда (ну, вайн, понятно ;-):
Изображение

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Вторник, 24 Январь, 2023 15:24 
Аватара пользователя

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Вторник, 24 Январь, 2023 15:32 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Чтобы на progress bar написать текст, не вникая в обрезания краев, нужно просто-напросто вставить дополнительный вид, и Views обеспечит вам обрезание. И это правильнее, чем лезть в механизм SetRect/GetRect.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Вторник, 24 Январь, 2023 15:53 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Про меню и клавиши.

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Вторник, 24 Январь, 2023 16:09 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Иван просил высказаться про пиксели. Я их не люблю, поэтому мне нечего сказать про тот пиксель с краю линий.

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Вторник, 24 Январь, 2023 18:44 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
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.: впрочем, лично я не фанат сглаживания вообще, и при наличии выбора предпочитаю просто его оторвать.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Вторник, 24 Январь, 2023 23:52 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
arisu писал(а):
но узнать об этом можно только проштудировав исходники системы

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

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

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

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

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

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

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Среда, 25 Январь, 2023 09:09 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
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.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Четверг, 26 Январь, 2023 00:36 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Кстати, про аккорды. Универсальные контейнеры в 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 не срабатывает.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Четверг, 26 Январь, 2023 06:08 

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Четверг, 02 Февраль, 2023 17:53 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
и хитрый вопрос: а если я хочу подменю, а оверлей только один, как быть, куды бежать? делать оверлей размером чтобы всё влезло, и руками там менеджить views? не, я не против, просто может я чего не заметил полезного?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Четверг, 02 Февраль, 2023 18:21 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
arisu писал(а):
и хитрый вопрос: а если я хочу подменю, а оверлей только один, как быть, куды бежать? делать оверлей размером чтобы всё влезло, и руками там менеджить views? не, я не против, просто может я чего не заметил полезного?

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Четверг, 02 Февраль, 2023 19:27 

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 387 ]  На страницу Пред.  1 ... 8, 9, 10, 11, 12, 13, 14 ... 20  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 9


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB