Everything split from "GUI Design" ;)
Everything split from "GUI Design" ;)
Ever thought about using Object-C to write the WIMP interface
Re:GUI Designed
Hey, buddy! You have done very little for 1.5 years.... Sorry if this offends you, but I've been able to do the same stuff, without any source code help from the net, in about 6 months. I've added a windowing system also, but its got tons of work left. I work on it about 2 hrs a day, but of late ive been coming down with a bit of a backache.... Maybe i'd better hike up on coffee...
Heres my point: I planned for 1 month, written docs and all. I'd like to share the stuff with you, i'm just not sure how to. I'd also like to see your stuff, not the source code, just the concepts, as thats all I'm willing to share. Concepts come and concepts go, but its the ones you use that matter. Source code I've written in assembly language, you can write it in french if you like, that doesn't matter to anyone. Once you have the concepts, you can write anything, anyhow, anytime.
Contact me at [email protected] if you're interested, and we'll see what we can do!
Heres my point: I planned for 1 month, written docs and all. I'd like to share the stuff with you, i'm just not sure how to. I'd also like to see your stuff, not the source code, just the concepts, as thats all I'm willing to share. Concepts come and concepts go, but its the ones you use that matter. Source code I've written in assembly language, you can write it in french if you like, that doesn't matter to anyone. Once you have the concepts, you can write anything, anyhow, anytime.
Contact me at [email protected] if you're interested, and we'll see what we can do!
-
- Member
- Posts: 1600
- Joined: Wed Oct 18, 2006 11:59 am
- Location: Vienna/Austria
- Contact:
Re:Graphical User Interface Design
@chaitanya dhareshwar: Oooohhh, cool genius thou you are, but tell me then: *how stable is it* How much is left to be done?
Better you grow up and learn to watch your language. It is not polite to put down others efforts this way.
I 've needed two and a half years to have a stable kernel with decent functionality supporting all the needs of my services and user level programs - even the GUI service which I have developped alongside all the other stuff.
Want to know, why it needs so long? Sure you want, don't you? As simple as that: I have to gain my living, lad. Work, get it?
Not so difficult to grasp.
Oh, and I gonna take as much time as I want to to make something welldone, nothing put togehter in haste just to show off.
Better you grow up and learn to watch your language. It is not polite to put down others efforts this way.
I 've needed two and a half years to have a stable kernel with decent functionality supporting all the needs of my services and user level programs - even the GUI service which I have developped alongside all the other stuff.
Want to know, why it needs so long? Sure you want, don't you? As simple as that: I have to gain my living, lad. Work, get it?
Not so difficult to grasp.
Oh, and I gonna take as much time as I want to to make something welldone, nothing put togehter in haste just to show off.
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
BlueillusionOS iso image
Re:Graphical User Interface Design
It has taken me about a year to get into pmode, fix textmode functions and keyboard input..
I had my little breaks now and then, but still it?s going very slow.
I had my little breaks now and then, but still it?s going very slow.
Re:Graphical User Interface Design
Wow these guys are fast, it's taken me one year to get from a basic text printing asm kernel to realy basic c kernel, im trying to implament my old asm kernel in c, which included a fully functional command prompt with command parsing, usual stuff... ;D
I think a new liscence for os development would be good...
Last year i spent 3 months playing with vesa, my code kept throwing back wierd errors, and sometines undocumented error codes, not usefull.... But i would be happy to share my source under a strick liscence agreement.
I think a new liscence for os development would be good...
Last year i spent 3 months playing with vesa, my code kept throwing back wierd errors, and sometines undocumented error codes, not usefull.... But i would be happy to share my source under a strick liscence agreement.
Re:Graphical User Interface Design
Shouldn't someone rername this post 'ShowOff', 'Look Im a smartass' or 'Liscence Idea'... ???
Re:Graphical User Interface Design
i have tried to put together my future lincence, wich is supposed to let me have controll over the project, let people view and learn from the source, but not copying it.
(free use for any non-commercial purpose)
look at the attachment, any suggestions?
(free use for any non-commercial purpose)
look at the attachment, any suggestions?
-
- Member
- Posts: 1600
- Joined: Wed Oct 18, 2006 11:59 am
- Location: Vienna/Austria
- Contact:
Re:Graphical User Interface Design
you won't have control over your source code if making it public available: anyone can nick the code and don't tell you. It is always depending on the other ppl. so either make code available or close it. But the 'just-look-at-and-learn' doesn't work out.
Ha en bra dag. Here in vienna it's still aper.
Ha en bra dag. Here in vienna it's still aper.
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
BlueillusionOS iso image
Re:Graphical User Interface Design
If you are honest to yourself, there is very little you can do if someone wants to rip you off. Reverse engineering, patent / trademark lawsuits, or just downright buying you out.beyond infinity wrote: you won't have control over your source code if making it public available: anyone can nick the code and don't tell you. It is always depending on the other ppl. so either make code available or close it. But the 'just-look-at-and-learn' doesn't work out.
That being said, I've always been a believer in the shareware idea, and as such my license draft tells you you are obliged to follow the license (and, after 1.0 release, potentially pay fees), but I don't force people.
Call it an enlightened view. Don't discourage people who believe in the good in mankind.
Every good solution is obvious once you've found it.
-
- Member
- Posts: 1600
- Joined: Wed Oct 18, 2006 11:59 am
- Location: Vienna/Austria
- Contact:
Re:Graphical User Interface Design
I'm for the speaking straight. it has nothing to do with "believing in the good in mankind" *gg* Just like what we say in Vienna (if we know the old dialect): tacheles reden.
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
BlueillusionOS iso image
Re:Graphical User Interface Design
Hi everyone
I am 14 and me and two other friends are making our own operating system...sounds stupid doesnt it. Well i was wondering..what kind of program language should i use to write the GUI in ie: C++, Basic, Fortran and COBOL.
I am 14 and me and two other friends are making our own operating system...sounds stupid doesnt it. Well i was wondering..what kind of program language should i use to write the GUI in ie: C++, Basic, Fortran and COBOL.
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Graphical User Interface Design
GUIs are *much* easier to design in a OO high-level language. That means something like C++ or Objective C ... Make sure you have the support of a fully-featured runtime for that language before you start your GUI, though. I guess people using the GUI will not like it if they cannot have access to exceptions because your home-brew-now-mandatory language runtime doesn't support it
Re:Graphical User Interface Design
Urgh. I'd say "GUI Widget Toolkits" are much easier to design with an OOP language. But basicly, I find there are no less than 4 essential components of a good GUI, and while they can all live in the same GUI server if you want, I'm still going to claim that designing them separately is a good idea.
At highest level you have a widget system. A button is a widget. A window is a widget. A label or a menu is a widget. This level is definitely best served with object-oriented design. I'd also consider signals and slots here.
Then there's the drawing layer. We draw into surfaces. In many GUIs a surface can be a "window" or an "offscreen buffer" but essentially a surface is a bitmap. When it's given a location inside another surface, you can translate drawing commands directly to the top-most surface's coordinate system, avoiding copying surfaces. Now, I don't necessary think that OOP is all that useful here. For what I know, many flexible drawing systems seem to be variants of FORTH: (Display)PostScript, Flash and (essentially) even HTML. In fact, I would argue that being able to run some Forth-like drawing code on the server (=videodriver) side can be a real win, especially if your apps and GUI live in different processes (or machines) and you care about perfomance.
Ok, great, we have widgets, and they can draw stuff. Next we want to handle events. And yes, widgets should handle nice OOP like event-system for high-level events, but for low-level events I'd go with something more simple. Separating the low-level and high-level event handling is a good idea. Most of the time you can use the coordinate systems of your hierarchical surfaces (and some additional data for focus and such) to figure out which widget should get a low-level event. I'd also try to avoid relying on queues too much here: queues can be overrun, and most of the time you can make your event protocol almost totally stateless --- which usually also makes it more ligh-weight. Once you've found your widget, OOP is cool from there on.
Ok, so why did I say "4 parts"? Because for a GUI to be really usable, you want to integrate your applications with each other, so you need some kind of "inter-application communication protocol". You will want to use that for doing things like drag-and-drop, or maybe some remote scripting (say, tell an existing browser to open a new tab when a link is clicked in an email reader) and such. This is probably not going to be the highest priority, and you can always use primitive services of the operating system, but having a GUI specific communication system is going to make writing cool applications a lot easier. This part CAN use OOP design, but a simple procedural notification protocol might actually work just as well if not better for simple things. For complex stuff like OLE-style embedding of some components, you probably want a full OO-RPC system like COM or CORBA (actually, you don't want CORBA ) or whatever.
At highest level you have a widget system. A button is a widget. A window is a widget. A label or a menu is a widget. This level is definitely best served with object-oriented design. I'd also consider signals and slots here.
Then there's the drawing layer. We draw into surfaces. In many GUIs a surface can be a "window" or an "offscreen buffer" but essentially a surface is a bitmap. When it's given a location inside another surface, you can translate drawing commands directly to the top-most surface's coordinate system, avoiding copying surfaces. Now, I don't necessary think that OOP is all that useful here. For what I know, many flexible drawing systems seem to be variants of FORTH: (Display)PostScript, Flash and (essentially) even HTML. In fact, I would argue that being able to run some Forth-like drawing code on the server (=videodriver) side can be a real win, especially if your apps and GUI live in different processes (or machines) and you care about perfomance.
Ok, great, we have widgets, and they can draw stuff. Next we want to handle events. And yes, widgets should handle nice OOP like event-system for high-level events, but for low-level events I'd go with something more simple. Separating the low-level and high-level event handling is a good idea. Most of the time you can use the coordinate systems of your hierarchical surfaces (and some additional data for focus and such) to figure out which widget should get a low-level event. I'd also try to avoid relying on queues too much here: queues can be overrun, and most of the time you can make your event protocol almost totally stateless --- which usually also makes it more ligh-weight. Once you've found your widget, OOP is cool from there on.
Ok, so why did I say "4 parts"? Because for a GUI to be really usable, you want to integrate your applications with each other, so you need some kind of "inter-application communication protocol". You will want to use that for doing things like drag-and-drop, or maybe some remote scripting (say, tell an existing browser to open a new tab when a link is clicked in an email reader) and such. This is probably not going to be the highest priority, and you can always use primitive services of the operating system, but having a GUI specific communication system is going to make writing cool applications a lot easier. This part CAN use OOP design, but a simple procedural notification protocol might actually work just as well if not better for simple things. For complex stuff like OLE-style embedding of some components, you probably want a full OO-RPC system like COM or CORBA (actually, you don't want CORBA ) or whatever.
Re:Graphical User Interface Design
It dosen't really sound all that stupid... I started writing an OS in C at age 12Andrew Woods wrote: Hi everyone
I am 14 and me and two other friends are making our own operating system...sounds stupid doesnt it. Well i was wondering..what kind of program language should i use to write the GUI in ie: C++, Basic, Fortran and COBOL.
Re:Graphical User Interface Design
WOW, age 12...at age 12 i was just starting to do basic programming with c++! man ur kool, i wish i had learned eriler....
and no! not kind of stupid...you cannot call your self a good programmer unless u can or at least are trying to learn OSD. if you can do OSD, then you can do any kind of programming
and no! not kind of stupid...you cannot call your self a good programmer unless u can or at least are trying to learn OSD. if you can do OSD, then you can do any kind of programming