• Advertisement
Sign in to follow this  

need help designing an event-based gui system

This topic is 3311 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'd like to know what systems should I write to create an event based GUI system. the language is not OOP so I would like to understand how each system is supposed to work, that way I can implement it in a structured manner. What do I need to write?. Thanks

Share this post


Link to post
Share on other sites
Advertisement
That's not much to go on.

It's a UI. You need to display stuff, respond to input. That's a start until there's some more specific requirements or at least some background regarding your skill, target audience, language...

Share this post


Link to post
Share on other sites
Thanks for your answer but why is it that most answers don't really help at all?.

I'd like to know what goes on GUI systems like the windows one where events and messages are handled, etc. For instance, how does the DRAW message ever appear if it's not caused by user input? or is it?. I want to read on how things should be done... Obviously I could cook something up in a few hours and it'll just "work" but next month I might not want that code in any project of mine since it'll be hideous to say the least.

I already have a small bunch of 'components' that handle the drawing of rects and also intersection tests between rects, points and rects, etc. That's settled. I now need some sort of queue list for my messages but I never implemented anything like it.

Also, the fact that it isn't OOP limits me a bit since I got used to think in OOP and now it's harder than ever to 'go back'...




Share this post


Link to post
Share on other sites
Quote:
Original post by gusso
Thanks for your answer but why is it that most answers don't really help at all?.


Ask a vague question, get a vague answer.

Quote:

I'd like to know what goes on GUI systems like the windows one where events and messages are handled, etc. For instance, how does the DRAW message ever appear if it's not caused by user input?


They're caused by user input (mostly). Moving a widget, being obscured by another widget, being clicked on... these all generally send invalidate messages that cause a paint. Animations might simply be triggered by timer. Some games don't bother with invalidation and just run such things as part of the render loop.

Quote:

I want to read on how things should be done... Obviously I could cook something up in a few hours and it'll just "work" but next month I might not want that code in any project of mine since it'll be hideous to say the least.


Good planning won't make your code or interfaces any less horrible. That's something that only comes with experience. And there's no one way things should be done. Does it work? Is it maintainable? Is it flexible? Is it fast?

Quote:

I now need some sort of queue list for my messages but I never implemented anything like it.


So whip out google and research. Whip out the IDE and prototype one up.

Quote:

Also, the fact that it isn't OOP limits me a bit since I got used to think in OOP and now it's harder than ever to 'go back'...


Oh?

If it's a style you're not used to, maybe it's better to focus on learning not producing. And please, if it's not OOP what is it? How are we supposed to even conceptualize a design when we don't know what style it's in?

Share this post


Link to post
Share on other sites
I recommend reading a book on Windows (GUI) programming. That ought to give you a good idea of how Windows does its tricks and you might 'copy' those ideas and add your own.

Secondly, and that is just my hunch while reading your posts, you might be in for something that is over your head. If you are not comfortable with data structures like stacks/queues, you might want to start a bit smaller than this.

Share this post


Link to post
Share on other sites
While i won't be able to answer you most likely I can see you are asking a question that doesn't make much sense.

So let me ask you do you mean...
What commands go in a GUI?
How are GUI's initially displayed?
How do you program a GUI without OOP?
...?

Share this post


Link to post
Share on other sites
You didn't specify what language you're using. Since every language probably deserves its own answer, I have a choice between giving you one different answer for every possible language, or giving you a single very vague answer that applies in all cases but isn't useful. Since I'm lazy, I'm going to go for the shortest possibility until you actually provide more information (such as, what language you're using).

You need to provide a way for the programmer to define a GUI. This involves describing the GUI layout using a data structure of your choice, and binding events to code provided by the programmer.

Share this post


Link to post
Share on other sites
If you read carefully I'm not asking "how to write XYZ in this language", perhaps many so called newbies do ask those things, all I asked for was "what systems should I write to create an event based gui system".

Doesn't matter in which language, if one implies 'write' and 'gui' and 'systems' then, which systems should one write? - doesn't matter if something already exists, that's not in the scope of writing now is it?. Sure now discuss me about the wonders of BOOST and whatnot, that's not what I'm after here.

All I need is a bunch of pointers toward the right information, google doesn't seem to bother on this and I've been filtering the results for a long time without any good results, all I see are hacks here and hacks there, no real gui system at all and the ones I did indeed perceive as such, they were all so abstracted into the world of OOP that I couldn't make up any of it into a non-oop environment.

Flag me as pedant but I don't care, it seems as if a bunch of "very knowledgeable" people roam around this forums but they just do so to point and laugh at others instead of actually helping out with real answers. I know where I stand and I also know nothing about GUIs, this is my first attempt and sure I'll probably end up rewriting the code once I'm done with it, but that doesn't matter. I still need to know out of theory what should go in such a system.

Hacking your way through everything is a vague way of programming.


Eeyore: thanks I'll take a look.



Share this post


Link to post
Share on other sites
Quote:
Original post by gusso
If you read carefully I'm not asking "how to write XYZ in this language", perhaps many so called newbies do ask those things, all I asked for was "what systems should I write to create an event based gui system".


You should write whatever damned well you please. There are about 5 billion ways to make a GUI. Pick one.

Quote:

Doesn't matter in which language, if one implies 'write' and 'gui' and 'systems' then, which systems should one write?


To what level of abstraction, for what requirements, on what hardware, with how many people who have what level of knowledge...? Are you using a language that provides events, or do we need to spell that out for you too?

Quote:

- doesn't matter if something already exists, that's not in the scope of writing now is it?.


No, it's in the scope of doing due diligence to make sure you're not remaking the wheel. Or at least doing research to see what academic/practical findings were done to understand how best to construct and present UI systems.

Quote:

All I need is a bunch of pointers toward the right information, google doesn't seem to bother on this and I've been filtering the results for a long time without any good results, all I see are hacks here and hacks there, no real gui system at all and the ones I did indeed perceive as such, they were all so abstracted into the world of OOP that I couldn't make up any of it into a non-oop environment.


The get programming windows by Petzold before .NET came out; or just browse through the Form library in .NET's libs (or X11 source if you're masochistic). They're real UI systems. The best we have, and are still glorified hacks; or at least a hack evolved into something mildly stable if still gelatinous...

And no offense, but everyone here is going to describe things in OOP terms. It is most of our (and the general web's) expertise's, and fits well in to UI systems. Especially since you've still not said if you're doing functional programming or imperative or something wildly different.

Quote:

Flag me as pedant but I don't care, it seems as if a bunch of "very knowledgeable" people roam around this forums but they just do so to point and laugh at others instead of actually helping out with real answers.


A pendant wouldn't ask vague questions. A pedant would make nice detailed counterarguments rather than stumbling over their own contradictions, getting angry and insulting people.

If you want real answers, ask a real question.

Share this post


Link to post
Share on other sites
We all know it is easier to give an answer than it is to formulate a question.

Most of the time when a question is precise, you know the answer.

Questions can be very abstract, answer can be very abstract too. Whether they are abstract or not, they need to be precise to get answered.

That is why people here ask questions like "please give more details", "what are you aiming for". It is not to insult, it is to help define the question.

Things like programming languages, OO and natural languages are tools to both express the question and the answer. Do not dismiss a tool unless you have a very good reason to do so. Many times you will have to learn a new tool to address a new question (and its answers).

So when you ask about a subject that is relatively new to you and people start giving answers expect new tools to show up. It is part of the answer to learn the new tools.

For GUIs, OO is a very natural tool, however, an OO design 'can' be implemented in a non-OO language. Expect most documentation on GUIs to use OO to explain the workings, so you might end up translation the OO design into a non-OO implementation.

Read Petzold's "Programming Windows" book and ask more questions.

Share this post


Link to post
Share on other sites
Gusso, what do you mean by systems?

I know there is a QBASIC example of a GUI out there that I came across years ago. And they are used in BIOS all the time. Both of those are non-OOP

I just don't get your question.

a GUI is a graphical user interface. It's function is to serve as a menu to quickly access other screens or menus that you would otherwise need to know a direct pathway to. There is nothing else to it.

Generally speaking a GUI needs an active and inactive state and you will want to figure out a way to encapsulate this without OOP.

This should not be a problem to do as if you know OOP you should know that essentially all the stuff in OOP based languages are mostly just more elegant, efficient, and understandable code.

In OOP your going to make a class/object (excuse me if my usage is not correct as I only moderately use OOP) that has function that will set a variable in that object to active/inactive and it will then display the menu. All you are doing is taking all that code out of the Class and setting a basic array to act in the manner they would in the class...

If that is what you are looking to do then your question leaves me with the question of why did you say systems when you should have said functions or sub-functions or processes...or any number of other words that make more sense.

This is the only thing I can think of that you might be meaning using what you asked.

Share this post


Link to post
Share on other sites
Theres an interesting technique gui for having a realy lightweight memory footprint. I dont remember whats is called, but it can look something like this:


void handleEvent(struct Event * event) {
if (button(0, 0, 100, 10, "Ok", event, OK_BUTTON_ID)) {
handleOkWasPressed();
}
if (button(0, 10, 100, 10, "Cancel", event, CANCEL_BUTTON_ID)) {
handleCancelWasPressed();
}
}

int button(int x, int y, int width, int height, char * text, struct Event * event, int id)
{
switch(event->type) {
case RENDER_EVENT:
renderButton(x, y, width, height, text);
break;

case MOUSE_BUTTON:
if (!hitTest(x, y, width, height, event->x, event->y)
break;
/* fallthrough */

case SELECT:
return TRUE;

case NEXT_BUTTON:
if (event->state->selected == id)
event->state->selected = 0;
else if (event->state->selected == 0)
event->state->selected = id;
break;

case NEXT_BUTTON:
break;

....
}
return FALSE;
}


Where a minimum och ram is used. This is however more usefull for old consoles where there is more rom than ram. Using this sort of programming you can get a gui system roling on just 256 bytes of ram.

The biggest drawback is the problem of using dynamic layout.

[Edited by - mzeo77 on December 28, 2008 5:27:43 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by gusso
If you read carefully I'm not asking "how to write XYZ in this language", perhaps many so called newbies do ask those things, all I asked for was "what systems should I write to create an event based gui system".


Just as Telastyn said; there's plenty of ways of doing something, specially in programming. I'm a programmer, too and I've learned people are not going to do your homework. What do I mean? Ask yourself some interesting questions:

Q: What is a GUI?
A: http://en.wikipedia.org/wiki/Graphical_user_interface

Q: What is a GUI composed by?
A: http://www.webopedia.com/TERM/G/Graphical_User_Interface_GUI.html

Q: How can I implement a way of handling those things on my own?
A: You have the answer... nobody else does.

Asking something like: "What do I need to make a GUI system?" will lead you to a better answer than asking what you should write (writing involves studying and doing your homework).

Quote:
Original post by gusso
All I need is a bunch of pointers toward the right information, google doesn't seem to bother on this and I've been filtering the results for a long time without any good results, all I see are hacks here and hacks there, no real gui system at all and the ones I did indeed perceive as such, they were all so abstracted into the world of OOP that I couldn't make up any of it into a non-oop environment.


Ok... another option is learning from others and study their code:

http://www.cegui.org.uk/wiki/index.php/Main_Page
http://www.minigui.org/
http://guichan.sourceforge.net/wiki/index.php/Main_Page

I hope I helped a little bit a remember to always go from the ground up

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement