libGUI

Discussing libraries simplifying applications development
  • Мне понравилось, я сейчас заканчиваю очередное переписывание editbox, и затем добавлю в библиотеку компоненты checkbox и radiobutton. (Editbox находиться пока в незавершенном состоянии). Еще один вопрос демки можно будет когда - нить перемещать по экрану ?
  • <Lrz>
    В последнем архиве они перемещаются.
  • http://www.menuetosgame.narod.ru/programs/libGUI.7z
    Скачал, попробовал под эмулятором перемещать демо, ничего не получилось. Поробовал закрыть приложение мышкой, не получилось. Закрыл только по Alt+F4
  • <Lrz>
    Я лично из этого архива запускал в эмуляторе, и все перемещалось. Может у тебя в пути присутствуют русские символы?
  • У меня есть одно предложение. В разработке editbox я продвинулся до того момента когда, возникла возможность в реализации функций copy and paste. (ctrl+c; ctrl+v). Но мне хотелось, что бы вставки контекста были доступны и другим приложениям(программам). Я думаю написать сервис, который будет находиться в памяти, а программы, в которых будет эта поддержка будут работать через него и соответсвтенно копировать контент. Релаизация возможно такая:
    Вот предполагаемый формат, очень похож на XML
    <сору ver 1.0>
    <text cp=1251, color 0x0, ....>
    Копируемый текст
    </text>
    Т.е. при копировании будет оформляться вот такая структура и передаваться запущеному сервису, а он в свою очередь будет перенаправлять другой программе при вызове ctrl+v.
    Если есть у кого предложения, прошу высказаться.
  • > <text
    Если речь про системный буфер обмена, то должен быть предусмотрен также тип image - изображение (участок изображения) в формате bmp или raw
  • Безусловно, просто нужно разработать стандарт и оформить его. Я предлагаю сделать стандарт расширяемым, с поддержкой image bmp или raw, и всего остального. Если этот стандарт будет поддрежан, то в дальнейшем вожможно будет разрабатывать приложения, подключать необходимые модули и не думать о совместимости. Т.е. я предлагаю сделать контейнер на основе XML стандарта.
  • <Lrz>

    Хорошая идея. Только зачем сервис ? Пусть это будут новые функции ядра, и скопированные данные будут храниться в общей памяти ядра.
  • Я против размещения всякой требухи в ядре. Ядро должно выполнять совершенно другие функции, а не обработку контейнера. Допустим запускаем программу, в которой есть компонент, который умеет работать с контейнером(необходимо будет сформировать контейнер) При запуске активируется сервис, который висит в трее(процесс), при CTRL+C формируется контейнер, а сервису передаются указатели на сформировавшийся контейнер (выделяется участок в памяти, в нем и происхоидит формирование). Далее, другая программа, по CRTL+V запрашивает у сервиса вставку содержимого и сервис, передает указатель на контейнер. Программа берет данные и преобразует их в удобочитаемый формат для себя и вставляет. Сервис по оформлению и вставке осуществляет dll-ка, которая подключается к программам, которые используют этот сервис.
  • <Lrz>
    Serge дело говорит - на уровне ядра это будет проще сделать, так как IPC больно мудрено получается.
  • Я не прорю, да проще, но не правильнее. вообще нужно вынести драйвера из ядра, сделать подключаемые сервисы. ОС должна быть масшабируемой, под задачу, а не содержать что нужно и что не нужно.
  • <Lrz>

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

    XML хорошо. но 99% копируемой инормации - текст.
    Я бы сделал так. Определить три типа данных: текст, картинка, и raw данные (контейнер (привет OLE)). Описание данных в XML сделать отдельной строкой и только для контейнеров.
    Тогда copy получает четыре параметра: тип данных, XML-строку или ноль, указатель на данные и их размер.
    Дальше выделяет необходимую память и копирует туда XML и даные.

    get_info получает от программы буфер для XML-строки и его размер. Если буфер достаточной длины туда копируется строка и возвращяется тип данных или ошибка. Если программе надо просто узнать тип данных она передаст нулевой указатель и размер.

    copy получает указатель на буфер для данных и размер буфера. Программа уже знает какого типа данные она получит.

    clear уничтожит буфер если он занимет слишком много места.
  • Обновление libGUI.
    http://www.menuetosgame.narod.ru/programs/libGUI.7z

    Исправлен недочёт,связанный с crate_control(в остальном всё нормально).
    Подкорректированы цвета для 2D кнопок.Теперь они выглядят объёмными при любом цвете скина.
    Оптимизация кода для 2D объектов(кнопки и скролеры).Оптимизация проведена как по скорости, так и по размеру.
    Демка теперь перемещается.

    <Lrz>
    Для выхода из демки используй кнопку Exit.

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

    Что касается обменного буфера, то я думаю, что вариант Serge-а самый лучший.От того, что в памяти ядра разместиться буфер обмена никакого вреда стабильности и безопасности системе не будет.
  • Неплохие компоненты. Давно пора было начать их писать, только чесслово слишком уж они по-виндовсавски смотрятся. Колибри - она маленькая вся, компактная.

    Компоненты должны быть такими же по моему ИМХО.

    А чего не кватает КолибриОС просто катастрофически - это окна выбора файла.
  • Who is online

    Users browsing this forum: Ahrefs [Bot] and 8 guests