OberonCore
https://forum.oberoncore.ru/

BlackBox на OpenGL
https://forum.oberoncore.ru/viewtopic.php?f=114&t=4287
Страница 7 из 7

Автор:  Jordan [ Вторник, 05 Ноябрь, 2013 20:02 ]
Заголовок сообщения:  Re: BlackBox на OpenGL

Понятно, обида вас гложет.

Ваши предположения ошибочны.

Автор:  Jordan [ Вторник, 05 Ноябрь, 2013 20:23 ]
Заголовок сообщения:  Re: BlackBox на OpenGL

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

Автор:  Евгений Темиргалеев [ Вторник, 05 Ноябрь, 2013 20:39 ]
Заголовок сообщения:  Re: BlackBox на OpenGL

Jordan писал(а):
Хотелось бы узнать судьбу проекта. Что сделано, что осталось, развивается ли?
Идите и посмотрите: https://bitbucket.org/petryxa/bb16rc6ogl (доступно отсюда: http://oberoncore.ru/members/%D0%BA%D1% ... 0%BF%D0%BC)

Автор:  Димыч [ Суббота, 14 Декабрь, 2013 18:02 ]
Заголовок сообщения:  Re: BlackBox на OpenGL

Посмотрел сделанную работу.

Петр, снимаю шляпу!
Великолепно, не говоря уже о том, какой объем работы сделан!

Что касается графики и шрифтов из ветки AGG.
Одно другому не мешает.
По-крупному, AGG создает битовую карту и позволяет с помощью векторов на ней рисовать. Последующее отображение и использование находится за рамками библиотеки. То же самое касается и шрифтовой группы. Если ты можешь с помощью ОС/сторонней библиотеки прочитать структуру глифа, то дальнейшее его отображение (на битовой карте), в целом, тривиально.
А отображение битовой карты в OpenGL должно быть просто.

Чтение шрифтов можно разнести в платформо-зависимые модули.
В WinAPI есть функции чтения глифов, для остальных систем есть FreeType.
Может быть есть другие библиотеки чтения шрифтовой информации, надо поискать.

Автор:  Пётр Кушнир [ Суббота, 14 Декабрь, 2013 18:59 ]
Заголовок сообщения:  Re: BlackBox на OpenGL

Димыч писал(а):
Посмотрел сделанную работу.

Петр, снимаю шляпу!
Великолепно, не говоря уже о том, какой объем работы сделан!
В этом мне простота ББ и КП сильно помогли.

Димыч писал(а):
Чтение шрифтов можно разнести в платформо-зависимые модули.
В WinAPI есть функции чтения глифов, для остальных систем есть FreeType.
Одна из целей была - изоляция от винапи, потому что я в нем не шарю :mrgreen:
Вот freeglut удобная штука для изоляции от оконной системы Винды. А когда окна заработали, во freetype все и уперлось, я просто C не знаю, и толком биндинги писать не могу, а потом проект завис, потом исчезло свободное время, а сейчас у нас пока этап пересмотра внутренней структуры ББ, возможно, скоро возродим проект BB+OpenGL. Но и там возникнет проблема с freetype.
Вот я и подумал, что в AGG с этим попроще будет. Чтобы можно было не знать С, а сразу писать то, что нужно. Мечты-мечты.

Автор:  Димыч [ Понедельник, 16 Декабрь, 2013 10:13 ]
Заголовок сообщения:  Re: BlackBox на OpenGL

Не знаю, в какую ветку поместить, модераторы, поправьте меня, если не прав.

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

Очень элегантное (и сильно недооцененное) решение было предложено в языке Modula-3

Описание ГУИ:
http://pro.dimina.ru/dl/modula-3/SRC-068.pdf
http://pro.dimina.ru/dl/modula-3/SRC-069.pdf

Исходники:
http://pro.dimina.ru/dl/modula-3/pm3-1.1.15-src.tar.bz2

Автор:  Пётр Кушнир [ Понедельник, 16 Декабрь, 2013 11:04 ]
Заголовок сообщения:  Re: BlackBox на OpenGL

Вопрос самостоятельного рисования интерфейсов упирается в необходимость нанять дизайнера, а затем его идеи положить на соответствующее техническое обеспечение. В этом треде уже были скриншоты страшненьких контролов, а чуть раньше я уже показывать ypkHostTabFrames на чистом ББ, прямые линии, сплошные цвета. Уныло. Даже с учетом повального упрощения форм и устранения объемов в современном UI.
Вот бы можно было обеспечить возможности фрейма на уровне графического редактора, тогда проблема изобразить красивый дизайн кнопки не будет проблемой. С точки зрения встраивания в каркас и сохранения совместимости со старым ББ в этом проблем нет.
То есть, прежде чем рисовать сам гуй, оформляя окна тайлами или на гранях трехмерного куба надо реализовать средства, которыми это все будет нарисовано.
Но я думаю, что эта задача уже будет реализована в следующей итерации проекта.

Автор:  Иван Кузьмицкий [ Понедельник, 16 Декабрь, 2013 11:52 ]
Заголовок сообщения:  Re: BlackBox на OpenGL

Димыч писал(а):
Раз уж пошел такой разговор и фактически речь идет о переписывании подсистемы графического интерфейса, предлагаю рассмотреть помимо масштабных библиотек типа GTK, вопрос самостоятельной отрисовки интерфейса.
Я так считаю, что GTK и прочие пусть идут мимо :) OpenGL-версии, которая должна рисовать интерфейс по каким-то векторным заготовкам.

Автор:  Jordan [ Понедельник, 16 Декабрь, 2013 15:01 ]
Заголовок сообщения:  Re: BlackBox на OpenGL

За основу можно взять SDL2, в данной версии реализована многооконность. Написать минимальный биндинг для данной версии. Преимущества, шрифты, картинки и opengl, идёт в комплекте + аудио.

Минимальная прослойка. Главное низкоуровщина спрятана, за вменяемыми функциями, абстрагирующие конкретные подсистемы.

Пётр Кушнир писал(а):
Вопрос самостоятельного рисования интерфейсов упирается в необходимость нанять дизайнера, а затем его идеи положить на соответствующее техническое обеспечение. В этом треде уже были скриншоты страшненьких контролов, а чуть раньше я уже показывать ypkHostTabFrames на чистом ББ, прямые линии, сплошные цвета. Уныло. Даже с учетом повального упрощения форм и устранения объемов в современном UI.


Дизайнер, то зачем? Здесь нужен программист. Тот же ББ, без выкрутасов. Обычные контроллы. Что ещё надо? Или улучшать интерфейс по мере необходимости. Всё сразу, можно не осилить.

Автор:  Jordan [ Понедельник, 16 Декабрь, 2013 15:06 ]
Заголовок сообщения:  Re: BlackBox на OpenGL

Самое главное. Гуй можно написать на любом языке, и сделать биндинг для КП. Это как вариант.

1. Доступность для других языков.
2. Кроссплатформенность, на данный момент времени у ББ её нет.

Автор:  Иван Кузьмицкий [ Понедельник, 16 Декабрь, 2013 15:27 ]
Заголовок сообщения:  Re: BlackBox на OpenGL

Jordan писал(а):
Дизайнер, то зачем? Здесь нужен программист. Тот же ББ, без выкрутасов. Обычные контроллы. Что ещё надо? Или улучшать интерфейс по мере необходимости. Всё сразу, можно не осилить.
Нет. Хороший дизайн - штука непростая и дорогая. Одни и те же контролы могут как отвратить своим видом, так и дать приятное ощущение. Так что программист пусть лучше занимается своим делом - например, созданием инструмента для дизайнера.

Автор:  Jordan [ Понедельник, 16 Декабрь, 2013 15:35 ]
Заголовок сообщения:  Re: BlackBox на OpenGL

Иван Кузьмицкий писал(а):
Jordan писал(а):
Дизайнер, то зачем? Здесь нужен программист. Тот же ББ, без выкрутасов. Обычные контроллы. Что ещё надо? Или улучшать интерфейс по мере необходимости. Всё сразу, можно не осилить.
Нет. Хороший дизайн - штука непростая и дорогая. Одни и те же контролы могут как отвратить своим видом, так и дать приятное ощущение. Так что программист пусть лучше занимается своим делом - например, созданием инструмента для дизайнера.


Вы имеете в виду создание гуя в стиле delphi? Конроллы рисуются визуально? Я говорил об обычных функциях.

Допустим отрисовка кнопки. Обычный прямоугольник с цветом + линии со всех сторон, для придания тени(Для объёмности).

Автор:  Димыч [ Понедельник, 16 Декабрь, 2013 17:00 ]
Заголовок сообщения:  Re: BlackBox на OpenGL

Jordan писал(а):
Допустим отрисовка кнопки. Обычный прямоугольник с цветом + линии со всех сторон, для придания тени(Для объёмности).


Вообще-то хорошо отрисовать кнопку - это два-три градиента, текст с тенью, тень под кнопкой, размытие тени под кнопкой.

Подробнее можно посмотреть по запросу "кнопка css3" и скевоморфизм.

Т.е. в динамике это задача нетривиальная.

Но все же технически задача сводится к смене нескольких битовых карт для разного состояния - click, hover, selected и т.д. А рисование на этих картах - да, дизайнер тут поможет.

Автор:  Jordan [ Понедельник, 16 Декабрь, 2013 17:19 ]
Заголовок сообщения:  Re: BlackBox на OpenGL

Димыч писал(а):
Вообще-то хорошо отрисовать кнопку - это два-три градиента, текст с тенью, тень под кнопкой, размытие тени под кнопкой.

Подробнее можно посмотреть по запросу "кнопка css3" и скевоморфизм.


Выглядит красиво.

Я думал о таком интерфейсе, простой и без бирюлек. Как минимум на первое время, пока нет дизайнера.
Изображение

Мне просто такой интерфейс нравится, личное предпочтение.

Автор:  Иван Кузьмицкий [ Среда, 04 Июнь, 2014 16:38 ]
Заголовок сообщения:  Re: BlackBox на OpenGL

Пётр Кушнир писал(а):
Роман М. писал(а):
Было бы глупо просто выкинуть HostFonts, не зная особенностей реализации.
Ну послушайте, есть интерфейс (System)Fonts, зачем знать что-то о реализации, это же антикомпонентно. :)
Поковырявшись в HostFonts, я немного изменил своё мнение. О реализации полезно знать некоторые вещи. Например, особенности кэширования шрифтов. Кэш там построен на базе Kernel.Identifier, это сам по себе интересный механизм и его можно использовать точно таким же образом в своей реализации.
Или такой момент - размер шрифта округляется до Fonts.point. Что это - особенности Windows-реализации или недокументированная охрана?

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

Автор:  Пётр Кушнир [ Среда, 04 Июнь, 2014 21:00 ]
Заголовок сообщения:  Re: BlackBox на OpenGL

Вот так абстракции и протекают (больше чем нужно) :D

Автор:  Иван Кузьмицкий [ Среда, 04 Июнь, 2014 21:26 ]
Заголовок сообщения:  Re: BlackBox на OpenGL

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

Автор:  Иван Кузьмицкий [ Понедельник, 16 Февраль, 2015 16:43 ]
Заголовок сообщения:  Re: BlackBox на OpenGL

Пётр Кушнир писал(а):
Как оказалось, работа механизмов должна выполняться в пределах одного фрейма, то есть, если при перерисовке окна фреймы перестроятся, то старый фрейм исчезнет, и будет ошибка выполнения внутри Containers.
В этом выражается главная особенность фреймового движка ББ: обработка сообщений во фреймах может приводить к накоплению областей, требующих перерисовки, а сама перерисовка всех накопленных областей (с возможным перестроением всего дерева фреймов документа) произойдёт одним махом "когда-нибудь", по таймеру или другому глобальному событию. Отсюда вывод - при обработке сообщения внутри фрейма нельзя пытаться перестроить всё дерево.

И тут зарыта проблема с циклом f.Input, конечно же: если вы хотите внутри фрейма обрабатывать нажатие-отпускание мышки, то придётся делать опрос мышки через f.Input в монолитном (синхронном) цикле WHILE прямо внутри обработчика события HandleCtrlMsg. Иначе, если нажатие и отпускание будут обработаны асинхронно, то между ними (всегда рассчитываем на худший сценарий) произойдёт перестройка дерева и фрейм, над которым произошло нажатие, будет потерян. А в какой новый фрейм посылать сигнал об отпускании кнопки мыши - нам не определить, потому что отображение может находиться в нескольких фреймах.

Думаю, именно для защиты от этой ситуации сообщение Controllers.TrackMsg приходит исключительно по нажатию мышки, а отпускание можно отследить только внутри фрейма с помощью f.Input!

Автор:  Иван Денисов [ Вторник, 17 Февраль, 2015 07:52 ]
Заголовок сообщения:  Re: BlackBox на OpenGL

Ну, да всегда через этот f.Input. И в примерах так сделано, например ObxLines.

Код:
REPEAT
   f.Input(x, y, modifiers, isDown);
   IF (x # x1) OR (y # y1) THEN
      GetBox(x0, y0, x1, y1, l, t, r, b); f.RestoreRect(l-1, t-1, r+1, b+1, Ports.keepBuffer);
      x1 := x; y1 := y;
      IF res = 0 THEN f.DrawLine(x0, y0, x1, y1, Ports.point, v.color) END
   END
UNTIL ~isDown;

Автор:  Иван Кузьмицкий [ Вторник, 17 Февраль, 2015 09:12 ]
Заголовок сообщения:  Re: BlackBox на OpenGL

Всё потому, что дерево визуальных объектов одновременно является и каналом коммуникации. Нельзя одновременно строить дерево и передавать сообщения. Либо одно, либо другое. Сообщение проходит по дереву синхронно, ловим его на фрейме и входим в цикл - в котором состояние мыши можно получить только через объект фрейма! Только так. Фрейм ведь может попросту исчезнуть при очередном перестроении дерева и ваш алгоритм разрушится. Так что возможность асинхронной обработки мыши отключена намеренно, я думаю.

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