Рабочая область окна

Kernel-side graphics support
  • ChE

    Ты читал описание системных функций KolibriOS?
    Там все текущие функции для работы с графикой описаны.
    А то,что в ядре пока нет буферизации окон - это не меняет сути дела. Читай документацию. Долго и внимательно.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • ChE
    1. А разве код kfm открыт?
    Да, он с самого начала был открытым, но я для себя считаю его не GPL, а BSD что по сути дает другим еще больше прав пользования кодом.
    Исходники содержатся в архиве исходников любого дистрибутива, лучше брать не ниже дистрибутива 0750.
    2. Насчёт трудности реализации: функция 0, по сути, устанавливает эту область и отрисовывает окно. Можно попробовать сделать функцию установки области отдельной и включить её в код других функций. Примерно так (для функции 0): устанавливаем рабочую область "по умолчанию", вызываем отрисовку окна. После отрисовки окон со скином, можно сделать область поменьше, это, кстати, решит некоторые "ляпы" таких окон.
    После этого не потребуется даже переписывать имеющиеся программы, ведь новую функцию никого не заставляют использовать
    Честно скажу - заниматься этим некому.
    Тогда я хочу, чтобы оконный менеджер определил мне битмап, в который я могу рисовать.
    Функция 65 и делай все что твоей душе угодно, а затем выводи собранный RAW.

    Если нужен набор некоторых компонентов, то есть совместно разрабатываемаея мной и <Lrz> библиотека BoxLib. Пока только 6 компонентов, но скоро будет еще 2. Тема библиотеки box_lib.obj - библиотека gui компонентов

    andrew_programmer
    Было бы хорошо объединить усилия, чтобы не делать параллельно одинаковую работу. Принцип орагнизации BoxLib достаточно универсален и абсолютно разные компоненты друг другу не мешают. Однако если решил все таки делать свою библиотеку дело твое. Уважаю твое мнение и труд.
    Last edited by Mario on Thu Aug 13, 2009 9:00 pm, edited 1 time in total.
  • Mario wrote: Честно скажу - заниматься этим некому.
    Честно скажу - жаль. Тогда, считаю тему закрытой.
  • Mario
    К сожалению, лицензия BSD дала право, например, фирме Apple использовать СВОБОДНЫЙ код ядра FreeBSD в своей НЕСВОБОДНОЙ системе MacOS X...
    То есть сегодня ты лицензируешь свой код под BSD, а завтра кто-нибудь использует твой код в своей проприетарной разработке и будет продавать за большие деньги. И лицензия BSD никак не будет ему в этом препятствовать. А с GPL он не смог бы это сделать...
  • andrew_programmer
    Было бы хорошо объединить усилия, чтобы не делать параллельно одинаковую работу. Принцип орагнизации BoxLib достаточно универсален и абсолютно разные компоненты друг другу не мешают. Однако если решил все таки делать свою библиотеку дело твое. Уважаю твое мнение и труд.
    Mario

    Моя библиотека полностью написана на C, поэтому объединить усилия не получиться. Подход к работе с контролами похож на подход GTK+, но есть и отличия.
    Тем не менее, наличие разных GUI библиотек - это хорошо для программиста. Можно в зависимости от задачи выбрать нужную библиотеку. Альтернатива - это хорошо.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • Атауальпа
    Вот зачем мне рассказывать это? Я сам вписал текст лицензии BSD в компоненты которые включил в BoxLib. Я прекрасно отдаю отчет в том что могут сделать с моим кодом и я не возражаю. Я делаю это осознанно, с трезвым и холодным рассудком. BSD лицензия дает мне самому права не меньшие. Я могу сам написать как свободный открытый так и закрытый коммерческий код пользуясь кодом основанным на лицензии BSD. При этом никто никому ничего не обязан! Это самый свободный принцип.
    GPL это такое ярмо навесив на свою шею которое программист обязан тащить и тащить, ничего кроме спасибо, и то врядли, он даже теоретически не получит.
    Я щас знаю чо скажут - типа по лицензии GPL можно тоже продавать продукты, ага щас их тут же и купили - принципиально никто ничего никому не будет платить, еще и возмущатсья будут.
    BSD это самая честная лицензия и самая свободная - хватит уже ханжества с GPL!
  • Атауальпа вся идея лицензии BSD в этом, и если тебе потом будет жалко что твой код использовали, используй другую лицензию...
    К сожалению, лицензия BSD дала право, например, фирме Apple использовать СВОБОДНЫЙ код ядра FreeBSD в своей НЕСВОБОДНОЙ системе MacOS X
    Зато теперь все вспоминают FreeBSD при упоминании о MacOS, лучше рекламы для свободного проекта не придумаешь.
  • andrew_programmer wrote:
    andrew_programmer
    Было бы хорошо объединить усилия, чтобы не делать параллельно одинаковую работу. Принцип орагнизации BoxLib достаточно универсален и абсолютно разные компоненты друг другу не мешают. Однако если решил все таки делать свою библиотеку дело твое. Уважаю твое мнение и труд.
    Mario

    Моя библиотека полностью написана на C, поэтому объединить усилия не получиться. Подход к работе с контролами похож на подход GTK+, но есть и отличия.
    Тем не менее, наличие разных GUI библиотек - это хорошо для программиста. Можно в зависимости от задачи выбрать нужную библиотеку. Альтернатива - это хорошо.
    Не вижу ни каких трудностей, что бы невозможно было объединить код написанный на C/C++ и код написанный на асм.
    Другое дело, будет ли библиотека libGUI работать достаточно быстро и иметь не большой объем кода? Можно из одной библиотеки вызывать код другой библиотеки, не нужно будет изобретать велосипед(компоненты) снова.
  • Можно ещё вопрос: кроме меня кто-то считает эту функцию нужной?
  • ChE
    Я считаю нужно и полезной, но таковых вещей необходимых к реализации очень много. Если готов сам взяться будет замечаетельно.
  • Другое дело, будет ли библиотека libGUI работать достаточно быстро и иметь не большой объем кода?
    Для сравнения. Динамические библиотеки находятся в оперативной памяти компьютера в распакованном виде. Ассемблерная libGUI в распакованном виде имела размер 70 килобайт. Текущий вариант libGUI на C значительно мощнее и функциональней ассемблерного варианта и имеет размер в неупакованном виде 51 килобайт, а в упакованном виде 15 килобайт. И это при том, что я ещё не до конца провёл оптимизацию по размеру и скорости. А если ещё код скомпилировать не GCC, а MSVC, то он будет ещё меньше. Так что библиотеки на C не всегда большие и тормозные. Тормоза получаются, когда библиотеки работают через сеть других библиотек.

    Давайте для начала подождём выхода библиотеки, а потом будем обсуждать.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • Who is online

    Users browsing this forum: No registered users and 6 guests