My own GUI ;P

[Adam B]

Czytając forum postanowiłem napisać własne GUI, w celu napisania aplikacji okienkowej - zagadnienie dla mnie nowe bo nigdy w większym stopniu nie miałem do czynienia z okienkami od strony programowania.
Z założenie ma być to proste GUI:

 - okna
 - przyciski
 - rozwijane menu

Programując chce się wzorować na swingu znanego z javy.

Do projektu postanowiłem zaprzęgnąć OpenGL +glut. Zastanawiam się jednak czy jeżeli ma być to proste GUI i na pewno nie będzie w przyszłości służyć do robienia czegokolwiek w 3d nie prościej będzie skorzystać z allegro? Prosił bym ludzi którzy mieli z tym jakieś doświadczenie o opinie.

Pozdrawiam serdecznie.

[Mr. Spam]

[Kos]

Do projektu postanowiłem zaprzęgnąć OpenGL +glut.

A co takiego ma GLUT, co mogłoby być potrzebne w GUI? :)


Najsensowniej chyba będzie, jeśli zrobisz to GUI niezależne od wyświetlania, a osobno zrobisz moduł rysujący je na np. OpenGL. Jeśli któregoś dnia zapragniesz odpalić je pod allegro, to dorobisz drugi moduł wyświetlania i już. Rozważ taką opcję.

[Adam B]

Do projektu postanowiłem zaprzęgnąć OpenGL +glut.

A co takiego ma GLUT, co mogłoby być potrzebne w GUI? :)


Najsensowniej chyba będzie, jeśli zrobisz to GUI niezależne od wyświetlania, a osobno zrobisz moduł rysujący je na np. OpenGL. Jeśli któregoś dnia zapragniesz odpalić je pod allegro, to dorobisz drugi moduł wyświetlania i już. Rozważ taką opcję.

5 linii kodu i już jest okno po którym można malować w OpenGL - tylko tyle :)

Mi bardziej się właśnie rozchodzi w pytaniu o samą funkcję "show" albo "draw" i ogolnie czy są jakieś przeciwskazania napisania ich w allegro ?

[taki_tam]

czy są jakieś przeciwskazania napisania ich w allegro ?

No ale przecież, Allegro to tylko render, który nie powinien mieć nic wspólnego z całym systemem GUI.
Innymi słowy, ja przeciwwskazań nie widzę.

Pozdro! ;)

[bs.mechanik]

Ogolnie sprawa wyglada tak, ze oddzielasz renderowanie od systemu GUI. Renderowanie mozesz podlaczyc np. dziedziczac po interfejsach. Mozesz napisac potem kilka rendererow, zeby user mogl szybko podlaczyc GUI do swojego app.
Tyle.

:)

[bs.mechanik]

Nie rob tego co ci kolega Kos tutaj radzi. Tylko zmarnujesz czas.

Bedziesz musial cos tam obsluzyc to i przepiszesz.

[Kos]

Nie zgadzam się. Nawet, jeśli żadny inny system wyświetlania nie miałby powstać, to warto wg mnie sobie wyrabiać dobre nawyki i uczyć się oddzielać logikę od widoku. Poza tym kod będzie wtedy łatwiejszy do zarządzania i rozbudowy.

[Adam B]

Nie zgadzam się. Nawet, jeśli żadny inny system wyświetlania nie miałby powstać, to warto wg mnie sobie wyrabiać dobre nawyki i uczyć się oddzielać logikę od widoku. Poza tym kod będzie wtedy łatwiejszy do zarządzania i rozbudowy.

Też tak myślę.

bs.mechanik sugerujesz stworzenie kilkudziesięciu różnych klas do wyświetlania ? Bo chyba nie zrozumiałem Twojej idei

[bs.mechanik]

Jezeli nie bedzie nigdy obslugi innego api graficznego to bedzie to tylko kolejna niepotrzebna warstwa abstrakcji.

[bs.mechanik]

Sugeruję stworzenie interfejsu dzieki któremu będziesz mógł komunikować się z warstwą renderującą, a potem jego implementację, by bibliotekę można było szybko wprowadzić do własnego projektu (oddzielnie dla DX, ogl, DXm itp). Interfejs po to, by user mial jednak możliwośc dopisania własnego renderera. 

[Adam B]

Sugeruję stworzenie interfejsu dzieki któremu będziesz mógł komunikować się z warstwą renderującą, a potem jego implementację, by bibliotekę można było szybko wprowadzić do własnego projektu (oddzielnie dla DX, ogl, DXm itp). Interfejs po to, by user mial jednak możliwośc dopisania własnego renderera. 

Ja mam to tak rozplanowane:

Kod: [Zaznacz]


////////////////////////KLASA GUI
class gui_button{
  public: 
    gui_button(string lname, int lx, int ly, int lwidth, int lheight);
     
  public:
    string name;
    int x;
    int y;
    int width;
    int height;
};

//////////////////////////////KLASA RYSUJACA

class visual{
  public:
void button(gui_button * b){    
       rectfill(screen, b->x, b->y, b->width, b->height, makecol(128,30,30)); 
     }

//////////////////////////////W PROGRAMIE

visual rysuj;
...
rysuj.button(wsk);


o coś takiego chodzi?

[bs.mechanik]

Masz interfejs, załóżmy IRenderer. Jak wiadomo, ma on same metody czysto wirtualne. Masz klasę odpowiedzialną za logikę gui - CGUI. Dodajesz do swojego GUI nowe przyciski (CButtons), ikonki (CIcon) itp (pGui->addObject(pButton)). Na końcu przekazujesz do klasy renderującej (wydziedziczonej po IRenderer) obiekt klasy CGUI, który zawiera wszystkie informacje o położeniu przycisków, ich stanie itp. Renderujesz  (pOpenGLGuiRenderer->render(pGui) lub pDXRenderer->render(pGui)).

Ja sobie wyobrażam to tak. Nie pisałem jeszcze wlasnego GUI, więc możliwe, że projekt jest zły :)

Wadą tego są wszędobylskie funkcje wirtualne i dziedziczenie, jednak na dobrą sprawę, nie jest to duży narzut.

[rm-f]

KISS.

[yarpen]

Zainteresuj sie konceptem Immediate Mode GUI. Nie cieszy sie moze zbyt wielka popularnoscia, bo ma za malo klas, dziedziczenia i f-kcji wirtualnych, za to swietnie sprawdza sie w praktyce (o ile nie piszesz Worda).

[Krzysiek K.]

Jezeli nie bedzie nigdy obslugi innego api graficznego to bedzie to tylko kolejna niepotrzebna warstwa abstrakcji.

Są przynajmniej dwa powody, by dodać tą warstwę:
1. Można w niej umieścić rzeczy specyficzne dla danego API (np. w przypadku OpenGL i DirectX zrobić batching prymitywów - bez wplanowanego batchingu nie ma co nawet zaczynać robić GUI).
2. GUI ma być pod OpenGL, więc warto zabezpieczyć się na przyszłość, jak już przyjdzie do przesiadki na Direct3D.

Zainteresuj sie konceptem Immediate Mode GUI. Nie cieszy sie moze zbyt wielka popularnoscia, bo ma za malo klas, dziedziczenia i f-kcji wirtualnych, za to swietnie sprawdza sie w praktyce (o ile nie piszesz Worda).

Brzmi jak podejście, do którego sam doszedłem pisząc swoje GUI - jeśli tak, to naprawdę gorąco polecam.
- Zalety: proste w obsłudze i mało kodu do napisania.
- Wady: mało kodu do napisania (ktoś może czuć się głupio pisząc wypasione GUI na trzech klasach bez żadnego dziedziczenia).

W mojej implementacji wadą była jeszcze konieczność odświeżania GUI co klatkę, ale przy GUI akcelerowanych sprzętowo nie jest to aż tak wielkim problemem. :)