need help designing an event-based gui system
Author
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
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...
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...
Author
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'...
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'...
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?
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.
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.
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?
...?
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?
...?
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.
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.
Author
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
