Я уже писал на menuet.fastbb.ru про идею создания стандартной
библиотеки GUI компонент.
Идея предполагает разработку визуальных компонент наподобие в Делфи. Над темой работаю недавно, поэтому извините за сырые и
далеко не оптимизированные исходники. Прилогается первая демка -
компонента TEditBox. Думаю разобраться не трудно. Шлите отзывы и предложения на аську. Приложение также отслеживает фокус ввода.
Исходники предоставляются пока так сказать free as is - никаких ссылок на меня делать не надо . Однако надеюсь найдутся люди которые до ума его доведут (мой проектик).
Хм. Странно! не нашёл как прикрепить файл.. .
Вобщем пишите в Асю!
GUI компоненты для MeOS
>библиотеки GUI компонент. Идея предполагает разработку визуальных компонент наподобие в Делфи
интересненько, т.е. ты хочешь сделать ОО гуи? сорцы это, вощем неважно =) расскажи подробнее что из себя представляет каждый оъект, в чьём контексте и как происходит взаимодействие?
интересненько, т.е. ты хочешь сделать ОО гуи? сорцы это, вощем неважно =) расскажи подробнее что из себя представляет каждый оъект, в чьём контексте и как происходит взаимодействие?
Последние данные по этой разработке можно узнать здесь: http://www.mestack.narod.ru
Прошла заSHITа моего диплома, и вот я уже маладой специалист!
Ну это типа лирическое отступление!
По теме! Как я и обещал товарищу Хексу, я решил попробовать продолжить разработку ГУИ компонент (библиотек)...
при этом конечно начну всё с нуля, ибо механизм реализации надо тщательно переделать...
Вроде были уже подобные разработки, хотелось бы пообщаться с создателями, посмотреть на готовые проги с использованием уже разработанных ГУИ...
изза диплома я не часто просматривал форум и отстал от жизни в плане МеОС, но как я понял уже реализхован механизм сворачивания окон, что конечно не может не радовать!
Хотелось бы скачать последний релиз... посмотреть что нового...
Идеи на счёт гуи я уже излаживал ранее, но видать это на старом форуме....
вот что я думаю:
-во первых применить обьектно-ориентированных подход
-компонентный подход как в делфях
-продумана система отлова событий (осталось придумать механизм взаимодействия компонент - думаю IPC здесь не совсем уместен будет...
вобщем что то на подобия стека или массива компонент, что бы делать групповые операции (активации, фокус ввода и прочее)
-система отлова событий приносит некоторую громоздкость кода, что проект будет состоять уже не из одного файла типа proga.asm, а
нескольких (всё то же делфи, но своя специфика - файл форм, файл кода, файл обработчиков событий...)
-ну и пока нет реализации менеджера памяти и ДЛЛ, все компоненты как и прежде пока будут вкомпиливаться в приложения, что отразится на размере... но это пока...
Вобщем ищу соратников по этому нелёгкому и неблагодарному делу ))))
пишите сюда и в асю 166399000
Жду идей!
Ну это типа лирическое отступление!
По теме! Как я и обещал товарищу Хексу, я решил попробовать продолжить разработку ГУИ компонент (библиотек)...
при этом конечно начну всё с нуля, ибо механизм реализации надо тщательно переделать...
Вроде были уже подобные разработки, хотелось бы пообщаться с создателями, посмотреть на готовые проги с использованием уже разработанных ГУИ...
изза диплома я не часто просматривал форум и отстал от жизни в плане МеОС, но как я понял уже реализхован механизм сворачивания окон, что конечно не может не радовать!
Хотелось бы скачать последний релиз... посмотреть что нового...
Идеи на счёт гуи я уже излаживал ранее, но видать это на старом форуме....
вот что я думаю:
-во первых применить обьектно-ориентированных подход
-компонентный подход как в делфях
-продумана система отлова событий (осталось придумать механизм взаимодействия компонент - думаю IPC здесь не совсем уместен будет...
вобщем что то на подобия стека или массива компонент, что бы делать групповые операции (активации, фокус ввода и прочее)
-система отлова событий приносит некоторую громоздкость кода, что проект будет состоять уже не из одного файла типа proga.asm, а
нескольких (всё то же делфи, но своя специфика - файл форм, файл кода, файл обработчиков событий...)
-ну и пока нет реализации менеджера памяти и ДЛЛ, все компоненты как и прежде пока будут вкомпиливаться в приложения, что отразится на размере... но это пока...
Вобщем ищу соратников по этому нелёгкому и неблагодарному делу ))))
пишите сюда и в асю 166399000
Жду идей!
FreGL
Как всегда - я буду помогать и ждать результатов!
Как всегда - я буду помогать и ждать результатов!
решил создать библиотеки основных (generic) классов (не только гуи, но и системных, исключений, обработчиков событий и т.п.)...
в ближайшее время выложу примеры
в ближайшее время выложу примеры
К сожалению на форуме нельзя прикреплять файлы - я давеча набросал схемку отлова событий и их сипользование разработчиками через классы...
ну тогда выложу идейку на словах, может найдутся единомышленники моего подхода...
я думаю уже большинуству надоело писать однообразный и планарный код с jmp и малоинформативными метками, при этом в данном коде можно запутаться даже самому разработчика (по крайней мере такое иногда бывает )...
я хочу применить мехаизм отлова событий как в делфях
т.е.
есть несколько основных классов:
TGenericEvents - класс отлова основых событий (через 10 функцию)
в нем есть адреса обработчиков событий
.OnGMouse - проверка мыши
.OnGKeyboard - работа клавы
.OnGWindow - перерисовка окна
.OnGSocket - данные в сокетах
.OnGIPC - IPC (надо ещё раздуплить чё это такое...)
....
вобщем есть цикл в основной процедуре чтото навроде следующего
.MainEventLoop:
.@@EventLoop:
mov eax,10
int 0x40
а теперь как и всегда делалось перебираем , какое же событие было, но механизм я немного усложнил
идёт простой case перебор
как видно для определённого события вызывается его обработчик, однако нам мало получить лишь состояние мыши или кнопки,
надо узнать какая кнопка нажата, в каком состоянии находится окно или пришли ли данные в сокет нормально или с ошибкой
поэтому следует основные события разбивать на уже более менее конкретные осбытия типа (мышь переместилась, нажата правая кнопка, левая, двойной клик, окно начало перерисовываться или уже закончило... данные пришли или ещё не отправлены и т.п.)
поэтому в обработчике мыши имеем следующее
.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)...
жду здоровой критики и советов!
ну тогда выложу идейку на словах, может найдутся единомышленники моего подхода...
я думаю уже большинуству надоело писать однообразный и планарный код с 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.Что ты думаешь на счет буферизации изображения или каких-либо других способах уменьшения мелькания изображения? Может нужно внести какие-либо изменения в ядро ?
PS Не все программисты на Delphi используют VCL. Я пишу в основном на API поэтому, например, не знаю как там все устроено .
2.Что ты думаешь на счет шрифтов?
3.Что ты думаешь на счет буферизации изображения или каких-либо других способах уменьшения мелькания изображения? Может нужно внести какие-либо изменения в ядро ?
PS Не все программисты на Delphi используют VCL. Я пишу в основном на API поэтому, например, не знаю как там все устроено .
Да и вообще в VCL не все так как надо было бы сделано
Я уже отошел от нее....хотя я не поклонник delphi, я на C++Builder писал, но когда перестали выходить новые версии, появилась .net и прочие навороты, то я понял, что C++Builder умер...и вместе с ним для умер и 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 - исходники самих компонентов и маленький пример.
точные ссылки:
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. А вот про буфферизацию не плохо было бы нарыть инфы... я уже думал над этим, но пока что представления довольно смутные...
Если есть инфа по 2 и 3 пункту бы ло бы не плохо ссылки или хотя бы где искать...
Попытки реализовать 2 и 3 есть в коде, который я тебе посылал (myproject.rar).
>3.Что ты думаешь на счет буферизации изображения или каких-либо других способах уменьшения мелькания изображения? Может нужно внести какие-либо изменения в ядро
А если рендерить в картинку, а потом всю её выводить, поможет?
Test не компилится даешь socket.def в студию
+В процедуре установки указателя вместо нуля надо компарить с Null`ом а то какой смысл его определять %)
И вообще, даешь CMouse, какой нафик T
А если рендерить в картинку, а потом всю её выводить, поможет?
Test не компилится даешь socket.def в студию
+В процедуре установки указателя вместо нуля надо компарить с Null`ом а то какой смысл его определять %)
И вообще, даешь CMouse, какой нафик T
socket.def тоже самое что и stack.inc, тока там одни описания констант, вынесено для удобства... что то типа заголовочного файла )
придётся класс Events пока убрать... а то что то отлов событий в структуре глючит ( а может я глючу? )... просто сделаю одну процедурку
типа WinMain тока назову её EventLoop для простоты, а обработчики так и будут переопределяться...
тогда структура програмы примет вид такой:
а содержимое файла events.def
вобщем таков механизм работы...
в настоящее время пока работы с ГУИ отложены, хочу отладить и довести до ума сам механизм отлова сообщений
кстати, как думаете, будет ли рационально выделять для каждой проги отдельный поток в котором будет EventLoop или проще его юзать в основном потоке?
придётся класс 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
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