libGUI

Discussing libraries simplifying applications development
  • andrew_programmer
    Не всё так просто. Контролы могут покрывать не всю площадь окна. Если не рисовать фон, то окно окажется "дырявым". В окне вообще может быть только 2-3 контрола. Один контрол выводит сообщение пользователю, а остальные предлагают выбрать варианты действий.
    Поэтому нужно отключать рисование фона под контролами, но при этом библиотека должна сама вычислять "дыры"(если они есть) и заполнять их цветом фона. Этот алгоритм пока ещё не реализован, поэтому фон под контролами отрисовываеться.
    Это уже забота программиста приложения, всех вариантов заранее не предусмотришь - есть дырка вызывай 13 функцию и заливай, или вызывай 65 и заливай скином.
    У меня ScrollBar так и рисуется. И ProgressBar также рисовался, только текст поверх него мигал, вот я и ввёл буферизацию. К тому же если выводить текст на ProgressBar-е масштабируемым шрифтом, то нужно производить сглаживание геометрических примитивов, чтобы шрифт казался ровным и гладким. Без буферизации изображения ScrollBar-а этого не сделать. Так что я одним решением избавился сразу от двух проблем.
    Абсолютно не понял причем тут скроллбар применительно к тексту? На нем то текст не рисуется.
    Если количество этих дыр велико, то нужно будет рисовать множество прямоугольников на экране, что потребует немалой загрузки процессора. Лучше уж рисовать в буфере, тем более, что у меня буферы динамические. То есть после использования(после вывода на экран) он освобождается, а не остаётся "висеть" в памяти занимая её.
    Но согласись должна быть соблюдена золотая середина. Если можно обойтись без буфера (пусть даже динамически выделяемого), то почему бы и не обойтись. В BoxLib только один элемент использует буфер это MenuBar, остальные отрисовываются без взсяких буферов. Согласен, что твой прогресбар с надписью требует буферизации, но скроллбар то можно и без буфера. :-)
  • andrew_programmer wrote:Не всё так просто. Контролы могут покрывать не всю площадь окна. Если не рисовать фон, то окно окажется "дырявым". В окне вообще может быть только 2-3 контрола. Один контрол выводит сообщение пользователю, а остальные предлагают выбрать варианты действий.
    Поэтому нужно отключать рисование фона под контролами, но при этом библиотека должна сама вычислять "дыры"(если они есть) и заполнять их цветом фона. Этот алгоритм пока ещё не реализован, поэтому фон под контролами отрисовываеться.
    По-хорошему, контролы должны быть дочерними окнами, и за тем, чтобы отрисовка фона в основном окне их не затрагивала, должен следить оконный менеджер (как сейчас он отслеживает, что отрисовка не трогает соседние окна).
    Ушёл к умным, знающим и культурным людям.
  • Mario, что плохого в возможности менять темы оформления? GTK и QT давно умеют, и вопреки этому всё-таки работают :)
  • Ну, дык я и говрю - если автору не лень будет отлаживать это дело то хорошо, а если будет написано исключительно ради красоты и плевать на стабильность. производительность и потребление памяти, то печально будет.
  • В данном случае радует серьёзное отношение автора к делу. Так что сделает, скорее всего, хорошо))
    А в идеале хорошо бы для Колибри вообще новую графическую оболочку...
  • Согласен, что твой прогресбар с надписью требует буферизации, но скроллбар то можно и без буфера. :-)
    Он и рисуется без буфера. Я имел ввиду, что рисуется он на экране без всяких лишних перерисовок. При первичной отрисовке рисуется весь контрол. Потом рисуются только меняющиеся части. То есть полоса до ползунка с одной стороны, ползунок и полоса после ползунка.
    По-хорошему, контролы должны быть дочерними окнами, и за тем, чтобы отрисовка фона в основном окне их не затрагивала, должен следить оконный менеджер (как сейчас он отслеживает, что отрисовка не трогает соседние окна).
    Только не при том оконном менеджере, который сейчас есть в Колибри. Он восстанавливает фон под окном полной перерисовкой всех нижележащих окон(хоть и не затрагивая перекрывающиеся области). Проведите эксперимент. Запустите, например, файловый менеджер. Поверх него поместите окно Tinypad-а. А потом быстро походите по его менюшкам. В результате увидите мигания при перерисовке окон, расположенных под меню. И это на современном компьютере. Я когда проделал это на старом, то наблюдал крайне неприятное слайд-шоу. Из-за примитивного метода восстановления фона под окнами, возникают мигания при перерисовке и сами меню выбираются медленно.
    В windows и linux мы не наблюдаем миганий и тормозов. Незнаю насчёт windows, но в linux для отрисовки исползуется буферизация. Оконный менеджер Kolibri позволяет экономить память, но при этом возникают проблемы со скоростью работы и качеством перерисовки. Как говорят ,"палка о двух концах". Хочешь экономить память, рисуй без буфера, но с мерцаниями, хочеш мез мерцаний - используй буффер. Кстати, в VESA курсор нужно рисовать не напрямую на экране, а в буфере, накладывая его изображение на часть скопированного в память изображения фона. И выводить наложенный курсор на экран. Так и делает X-сервер. Потому там курсор в VESA и не мигает.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • Атауальпа
    А в идеале хорошо бы для Колибри вообще новую графическую оболочку...
    Термин "Графическая оболочка" используется, если рисованием графики и окон в системе руководит процесс, работающий в user-mode, а не ядро операционной системы. В KolibrOS отрисовкой графичиских объектов и управлением окнами занимается ядро операционной системы. То есть графика встроена в ядро и никакой оболочки нет.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • "То есть графика встроена в ядро и никакой оболочки нет." то что нет никакой оболочки, не значит что нельзя создать новую (она сама по себе будет новой), так что в словах Атауальпы никакой ошибки нет, и я к ним присоединяюсь)
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • andrew_programmer
    У меня конструктивное предложение - возможно имеет смысл переместить libGUI в папку libraries, которая находится рядом. Все таки логичней соблюдать некоторые правила, чтобы уменьшить рост энтропии. :mrgreen:
  • Я о том же самом подумал. Думаю буду вносить новые изменения в библиотеку и перемещу её в папку libraries. Делать перенос в папку отдельной ревизией что-то не хочется.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • Хорошая работа. Main впечатлила.
    Почему KlbInWin не может загрузить библиотеку - я не знаю.
    Странно библиотека прерасно грузится KlbInWin, надо только положить её в директорию lib, в той папке которую ты выделил под рамдиск.
  • Странно библиотека прерасно грузится KlbInWin, надо только положить её в директорию lib, в той папке которую ты выделил под рамдиск.
    У меня не работает. Наверное из-за Windows. Она у меня ужасно глючит. Каждый второй запуск приводит к внезапному вылетанию в перезагрузку. А переустановить windows нельзя иначе у меня grub затрёться и я не смогу грузить linux.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • У меня тоже не работало (я перешёл с Windows на MacOS).
    Из хаоса в космос
  • : [quote="andrew_programmer"]А переустановить windows нельзя иначе у меня grub затрёться и я не смогу грузить linux.[/quote] это миф - GRUB можно восстановить. лучше, конечно сделать загрузочную дискету (диск) заранее, но можно и потом (просто мороки больше). я дважды восстанавливал GRUB. самый простой случай, когда у меня была Mandriva - вставить загрузочный диск и выбрать восстановление загрузчика. второй случай, когда я подрос, поставил Slackware, и после переустановки винды пришлось записывать дискету с GRUB и восстанавливать загрузчик с помощью команд.
  • Who is online

    Users browsing this forum: Google [Bot] and 3 guests