GUI компоненты для MeOS

Discussing libraries simplifying applications development
  • >библиотеки GUI компонент. Идея предполагает разработку визуальных компонент наподобие в Делфи
    интересненько, т.е. ты хочешь сделать ОО гуи? сорцы это, вощем неважно =) расскажи подробнее что из себя представляет каждый оъект, в чьём контексте и как происходит взаимодействие?
  • Последние данные по этой разработке можно узнать здесь: http://www.mestack.narod.ru
  • Прошла заSHITа моего диплома, и вот я уже маладой специалист! :)
    Ну это типа лирическое отступление!

    По теме! Как я и обещал товарищу Хексу, я решил попробовать продолжить разработку ГУИ компонент (библиотек)...
    при этом конечно начну всё с нуля, ибо механизм реализации надо тщательно переделать...

    Вроде были уже подобные разработки, хотелось бы пообщаться с создателями, посмотреть на готовые проги с использованием уже разработанных ГУИ...

    изза диплома я не часто просматривал форум и отстал от жизни в плане МеОС, но как я понял уже реализхован механизм сворачивания окон, что конечно не может не радовать!

    Хотелось бы скачать последний релиз... посмотреть что нового...

    Идеи на счёт гуи я уже излаживал ранее, но видать это на старом форуме....

    вот что я думаю:

    -во первых применить обьектно-ориентированных подход
    -компонентный подход как в делфях
    -продумана система отлова событий (осталось придумать механизм взаимодействия компонент - думаю IPC здесь не совсем уместен будет...
    вобщем что то на подобия стека или массива компонент, что бы делать групповые операции (активации, фокус ввода и прочее)
    -система отлова событий приносит некоторую громоздкость кода, что проект будет состоять уже не из одного файла типа proga.asm, а
    нескольких (всё то же делфи, но своя специфика - файл форм, файл кода, файл обработчиков событий...)
    -ну и пока нет реализации менеджера памяти и ДЛЛ, все компоненты как и прежде пока будут вкомпиливаться в приложения, что отразится на размере... но это пока...

    Вобщем ищу соратников по этому нелёгкому и неблагодарному делу ))))
    пишите сюда и в асю 166399000

    Жду идей!
  • FreGL
    Как всегда - я буду помогать и ждать результатов! ;)
  • решил создать библиотеки основных (generic) классов (не только гуи, но и системных, исключений, обработчиков событий и т.п.)...

    в ближайшее время выложу примеры
  • К сожалению на форуме нельзя прикреплять файлы - я давеча набросал схемку отлова событий и их сипользование разработчиками через классы... :(

    ну тогда выложу идейку на словах, может найдутся единомышленники моего подхода...

    я думаю уже большинуству надоело писать однообразный и планарный код с jmp и малоинформативными метками, при этом в данном коде можно запутаться даже самому разработчика (по крайней мере такое иногда бывает :) )...
    я хочу применить мехаизм отлова событий как в делфях
    т.е.
    есть несколько основных классов:
    TGenericEvents - класс отлова основых событий (через 10 функцию)
    в нем есть адреса обработчиков событий
    .OnGMouse - проверка мыши
    .OnGKeyboard - работа клавы
    .OnGWindow - перерисовка окна
    .OnGSocket - данные в сокетах
    .OnGIPC - IPC (надо ещё раздуплить чё это такое...)
    ....

    вобщем есть цикл в основной процедуре чтото навроде следующего
    .MainEventLoop:
    .@@EventLoop:
    mov eax,10
    int 0x40
    а теперь как и всегда делалось перебираем , какое же событие было, но механизм я немного усложнил
    идёт простой case перебор

    Code: Select all

    cmp eax,1
    jne .@@Next1:
    CallEvent .OnGWindow
    jmp .@@EventLoop
    .@@Next1:
    cmp eax,2
    jne .@@Next2
    CallEvent .OnGKeyboard
    jmp .@@EventLoop
    .@@Next2:
    ....
    jmp .@@EventLoop
    ret
    
    как видно для определённого события вызывается его обработчик, однако нам мало получить лишь состояние мыши или кнопки,
    надо узнать какая кнопка нажата, в каком состоянии находится окно или пришли ли данные в сокет нормально или с ошибкой
    поэтому следует основные события разбивать на уже более менее конкретные осбытия типа (мышь переместилась, нажата правая кнопка, левая, двойной клик, окно начало перерисовываться или уже закончило... данные пришли или ещё не отправлены и т.п.)

    поэтому в обработчике мыши имеем следующее

    .OnGMouse:
    проверяем изменились ли текущие координаты, если да вызываем событие .OnMouseMove
    проверям какая нажата клавиша и вызываем соответсвтенно .OnMouseClick или .OnMouseRightClick (хотя можно просто отслеживать сами кнопки в одном событии OnClick) .OnMouseDoubleClick...
    ret
    в сокете
    типа
    .OnPortGet
    .OnPortFree
    .OnSend
    .OnReceive
    .OnError....

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

    а далее (думаю это будет реализовано с помощью динамических списков или массивов)

    что то типа такого

    onMouseMove_UserProc:
    for i:=1 to Controls.Count do ; просмотр всех компонент на фокус
    begin
    Controls.CheckFocus;
    if Controls.inFocus then ; если компонент в фокусе
    begin
    Controls.GetFocus; ;он его захватывает
    Controls.Action; ;основное действие (в зависимости уже от самого контрола - ввод текста, подсветка и т.п.)
    break; выход
    end;
    end;

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

    вот такие идейки...

    на счёт переопределения обработчика, делается все просто

    SetEvent TSocket.OnDataReceive,myProcReceive
    SetEvent TSocket.OnError,fuck_error_proc

    а дальше в другом файле для удобства

    myProcReceive:
    обработка полученныз данных
    ret

    ....


    ну плюс ещё надо доделать систему сообщений на подобия Windows Messages и исключений (класс TException)...

    жду здоровой критики и советов!
  • 1.Может лучше номер контрола с фокусом хранить в некоторой переменной? Тогда ненужен перебор контролов и не сможет случайно оказаться 2 контрола с фокусом.
    2.Что ты думаешь на счет шрифтов?
    3.Что ты думаешь на счет буферизации изображения или каких-либо других способах уменьшения мелькания изображения? Может нужно внести какие-либо изменения в ядро :wink: ?
    PS Не все программисты на Delphi используют VCL. Я пишу в основном на API поэтому, например, не знаю как там все устроено :? .
  • Да и вообще в VCL не все так как надо было бы сделано :?
    Я уже отошел от нее....хотя я не поклонник delphi, я на C++Builder писал, но когда перестали выходить новые версии, появилась .net и прочие навороты, то я понял, что C++Builder умер...и вместе с ним для умер и VCL.
  • GUI-компоненты от FreGL можно найти по адресу http://shade.msu.ru/~msu-se/home.html
    точные ссылки:
    http://shade.msu.ru/~msu-se/Event_Scheme.rar - рисунок описывающий схему компонентов.
    http://shade.msu.ru/~msu-se/GUI_V01.rar - исходники самих компонентов и маленький пример.
  • 1. Идея принята на рассмотрение :)
    2. Со шрифтами надо ещё разобраться...
    3. А вот про буфферизацию не плохо было бы нарыть инфы... я уже думал над этим, но пока что представления довольно смутные...

    Если есть инфа по 2 и 3 пункту бы ло бы не плохо ссылки или хотя бы где искать...
  • Попытки реализовать 2 и 3 есть в коде, который я тебе посылал (myproject.rar).
  • >3.Что ты думаешь на счет буферизации изображения или каких-либо других способах уменьшения мелькания изображения? Может нужно внести какие-либо изменения в ядро
    А если рендерить в картинку, а потом всю её выводить, поможет?
    Test не компилится даешь socket.def в студию :)
    +В процедуре установки указателя вместо нуля надо компарить с Null`ом а то какой смысл его определять %)
    И вообще, даешь CMouse, какой нафик T :)
  • socket.def тоже самое что и stack.inc, тока там одни описания констант, вынесено для удобства... что то типа заголовочного файла )

    придётся класс Events пока убрать... а то что то отлов событий в структуре глючит ( а может я глючу? ;) )... просто сделаю одну процедурку
    типа WinMain тока назову её EventLoop для простоты, а обработчики так и будут переопределяться...

    тогда структура програмы примет вид такой:

    Code: Select all

    include ... ; вызов стандартных либов
    
    ;Заголовок
    
    AppHeader
    
    ;обьявление компонент, хотя можно вынести в отдельный файлец типа comp.asm ; наподобие файла dfm в делфях
    
    C1 TC1
    C2 TC2
    ...
    
    AppStart
    
    include 'events.def' ; здесь в файле переопределяются обработчики событий пользователем
    
    call EventLoop
    
    ; ресурсы проги, типа строки картинки прочий бред что то же можно вынести например в include 'appname.res'
    
    AppEnd
    
    а содержимое файла events.def

    Code: Select all

    SetEvent   App.OnCreate,APP_CREATE
    SetEvent   App.OnClose,APP_CLOSE
    SetEvent   Button1.OnClick,BTN1_CLICK
    .....
    
    APP_CREATE:
    call   Button1.Create
    call   Button2.Create
    ....
    ret
    
    APP_CLOSE:
    
    ... сохраняем что надо в файле и прочее перед выходом
    затем вызываем деструкторы установленных компонентов (это когда мне удастся сделать динамические обьекты)
    
    call   Button1.Destroy
    call   Button2.Destroy
    ret
    
    BTN1_CLICK:
    ... выполняем действия которые надо сделать при нажатии онной кнопочки..)
    rer
    

    вобщем таков механизм работы...

    в настоящее время пока работы с ГУИ отложены, хочу отладить и довести до ума сам механизм отлова сообщений

    кстати, как думаете, будет ли рационально выделять для каждой проги отдельный поток в котором будет EventLoop или проще его юзать в основном потоке?
  • не плохо было бы ещё в 10ю функцию добавить отлов исключений (типа деление на ноль и прочее)...
  • Who is online

    Users browsing this forum: No registered users and 37 guests