SEAL Forum Index SEAL
The SEAL Forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Graphics API planning
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    SEAL Forum Index -> Seal 3.0 Development
View previous topic :: View next topic  
Author Message
llogiq



Joined: 05 Jul 2002
Posts: 52
Location: Germany

PostPosted: Mon Jul 15, 2002 2:58 am    Post subject: More food for thought...yummy! Reply with quote

First, you're right about hiding implementation behind a clear interface. Consider my argument as an not-so-good troll - good point

Now, to your code:
    * x and y should be private to a point, not protected. Read on before you disagree.
    * Inheritance Abuse Alarm!!! The inheritance relation maintains an "x is-a y" relation. A Rectangle is not a point. Nor is a circle or a polygon.
    * That said, Rectangles can use two points to determine their position and height/width. If we decide that (height, width) represent a point in the rectangle's own coordinate system...
    * Don't know what a Rect is? It's a rectangle, dammit!


Anyway, I am not too comfortable about the staticness of our toolkit. Why do we have to use classes on such a low level? The (position) information will no doubt come from a higher level, so there's nothing to be stored. Why not just create the following:
Code:
void StkDrawPoint(int x, int y, Color c);
void StkDrawRectangle(int x, int y, int height, int width, Color c);
void StkDrawRectangle(int x, int y, int height, int width, Surface s); /* where Surface is a buffer to fill our rectangle with) */
void StkDrawCircle(int x, int y, int radius);
/* ...to be continued... */

and leave the information in the higher layers, where it belongs.

That said, there is no rule that forbids us to set up data structures to capture position or other information. But we should not forbid ourselves to calculate that information without storing it - maybe the calculation will be trivial.
Back to top
View user's profile Send private message
_xduffy_
Administrator


Joined: 15 Mar 2002
Posts: 894
Location: Sweden

PostPosted: Mon Jul 15, 2002 10:54 am    Post subject: Reply with quote

What you write is quite interesting

Though Im not so sure about using C functions instead...
What I meant with the classes was to build the foundation on which we build the gui controls... But maybe another approach is better??

(I have followed the discussions in the other thread but haven't answered 'cause I have had to agree w/ illogic... so I didn't bother to just write that...)
_________________
http://xduffystuff.sourceforge.net/Desktop/
www.xduffy.com
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
llogiq



Joined: 05 Jul 2002
Posts: 52
Location: Germany

PostPosted: Tue Jul 16, 2002 1:54 am    Post subject: Reply with quote

_xduffy_ wrote:
What you write is quite interesting

Thanx.

Quote:
Though Im not so sure about using C functions instead...

Why not? Unless someone comes up with something better...
But seriously, when looking from the upside down, do you want to bother with loads of objects you have to set up and destroy later if all you want is to color a pixel? No, you want the pixel colored, pronto! (Btw. look at gtk and tell me if there is a single object beneath the widget level - other than gtkobject, which provides base functionality your search will be fruitless)
In "Design Patterns", Gamma et al describe a "Facade" pattern, which is just a single interface to a multitude of objects. This facade decouples the outside world from the implementation of these objects and thereby hides the undelying complexity. The facade is implemented as an object, although it is in fact just an interface. Objects are IMO a poor way to define interfaces, while a bunch of C functions are a proven good way of doing so.

(And by the way, it's llogiq, not illogic, though the pseudonym may be tempting... )
Back to top
View user's profile Send private message
BadSector
Administrator


Joined: 24 Oct 2001
Posts: 328
Location: Greece, Samos

PostPosted: Tue Jul 16, 2002 4:39 am    Post subject: Reply with quote

why not:

Code:

class CPixel
{
    int x_pos, y_pos;
    int color;
    public:
    CPixel();
    void SetColor(int new_color);
    void SetPosition(int x, int y);
    void Put();
    int Get();
};

void CPixel::CPixel()
{
    x_pos = y_pos = color = 0;
}

void CPixel::SetColor(int new_color)
{
    color = new_color;
}

void CPixel::SetPosition(int x, int y)
{
    x_pos = x;
    y_pos = y;
}

void CPixel::Put()
{
    LowLevelPixelDrawingFunction(x_pos, y_pos, color);
}

int CPixel::Get()
{
    color = LowLevelPixelGettingFunction(x_pos, y_pos);
    return
        color;
}

Example of use:
Code:

// This C++ Code Puts a Pixel
CPixel *Pixel = new CPixel();
Pixel->SetPosition(160, 120);
Pixel->SetColor(COLOR_FUNKY);
Pixel->Put();
delete CPixel;


The Ultimate C++ Way!!!


(j/k)
_________________
main(){printf("Hello, world!n"); return 0;}
Bad Sector - http://www.bsector.cjb.net/
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
ganesh



Joined: 11 Jul 2002
Posts: 133
Location: Vancouver, BC, CA

PostPosted: Tue Jul 16, 2002 7:18 am    Post subject: Reply with quote

Actually i was thinking of leaving out all the lowlevel stuff (rects, points). I mean we are _too_ fixed on rectangular objects.

You have a super class called stkWidget (same as Window in MSWIN, or GtkWidget) and so many sub classes.

You can have a canvas widget, with functions such as the above.
_________________
Ganesh lives @
www.iamganesh.com
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
llogiq



Joined: 05 Jul 2002
Posts: 52
Location: Germany

PostPosted: Tue Jul 16, 2002 7:28 am    Post subject: Reply with quote

BadSector wrote:
The Ultimate C++ Way!!!

Funny, now that you mention it... If only the Put() method hadn't contained a "LowLevelPixelDrawingFunction" call, someone could have taken it serious.
Back to top
View user's profile Send private message
_xduffy_
Administrator


Joined: 15 Mar 2002
Posts: 894
Location: Sweden

PostPosted: Tue Jul 16, 2002 1:11 pm    Post subject: Reply with quote

Ok illogiq i think i've got your point I was just too object oriented in my mind And if you don't really dislikes it, Im gonna call you illogiq anyway I think that nick have a good ring to it

The pixel and drawing stuff should be in sdk right?

So... any gui object will be derived from stkWidget, right? So will any circular, rectangular etc. shape? Thought so

I got scared when I read your post BS Mr Green
_________________
http://xduffystuff.sourceforge.net/Desktop/
www.xduffy.com
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
llogiq



Joined: 05 Jul 2002
Posts: 52
Location: Germany

PostPosted: Tue Jul 16, 2002 11:14 pm    Post subject: Reply with quote

ganesh wrote:
Actually i was thinking of leaving out all the lowlevel stuff (rects, points). I mean we are _too_ fixed on rectangular objects.

Yep, that belongs to sdk, which should clearly be done in C.

Quote:
You have a super class called stkWidget (same as Window in MSWIN, or GtkWidget) and so many sub classes.

Why make the same mistakes over and over? The bloat in most desktop environments comes from a deep inheritance hierarchy. Why make everything a widget, when this generalization is not needed?

For example, will our Menues ever hold something that does not resemble a MenuEntry (which may also be a MenuBox, that in turn holds other MenuEntries)? I doubt so. Why should it hold widgets? And my favourite example: Why should anything inherit from a tooltip? Should we allow anyone to use his own tooltips? If no, why should there be a virtual function involved ("draw", for example)? For flexibility?

"Programmers use genericity to great flexibility and constraints to great performance." -- well, ok, I made that one up myself.

There's no one banging your head with a Stroustrup book for not using inheritance. Or encapsulation (especially in those cases where you have to pass objects through a big hierarchy only to get around class boundaries, where a simple publicly available global would have done). On the other hand using OO where it's not needed will bloat our code and lead to badly readable code as well as a performance hog.

So when designing the STK, the first task will be to create a simple containment hierarchy (for example application -> menu, menu->menubox|menuentry, menubox->menubox|menuentry, and so on) as a directed acyclic graph (a tree, but with backlinks) or grammar if you prefer. Then we can find the constraints we deem reasonable and turn them into performance

_xbuffy_: Please. I'm llogiq, leave it at that
Back to top
View user's profile Send private message
_xduffy_
Administrator


Joined: 15 Mar 2002
Posts: 894
Location: Sweden

PostPosted: Wed Jul 17, 2002 1:40 am    Post subject: Reply with quote

ok, ilogiq but if you ever call me xbuffy again...

What do you mean? Not using inheritance or just havin inheritance where it is needed?

What I really wonder is if there's gonna be the possibility to mix widgets/objects in a way that we didn't think of before without a rewrite of the hierchary?

I still think the event manager should be inherited. A class called EventManager or something like that which have virtual functions... and you reimplement the ones you're interested in in you app... or widget/object
_________________
http://xduffystuff.sourceforge.net/Desktop/
www.xduffy.com
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
ganesh



Joined: 11 Jul 2002
Posts: 133
Location: Vancouver, BC, CA

PostPosted: Wed Jul 17, 2002 2:15 am    Post subject: Reply with quote

Quote:

Yep, that belongs to sdk, which should clearly be done in C.


Why C again ? Whats wrong with a single object with C code in it ?? Look at sdkWindowManager.

In future, (or when I am interested), Seal will support virtual desktops. At that point its just a matter of making a linked list out of sdkWindowManager and handling the right events. It becomes simpler in the future....

Quote:

Why make the same mistakes over and over? The bloat in most desktop environments comes from a deep inheritance hierarchy. Why make everything a widget, when this generalization is not needed?


What ? Do you think Qt and MFC programmers are fools ? Then, I think you have a problem.

All items on screen have to be redrawn, be it stkMenuItems or stkTooltips or whatever. Are you going to store a function pointer for each kindof object and then call it ? Thats BAD.

Moreover, all widgets have certain basic props like parent, coods, etc...If you see my post on C vc CPP, inheritance provides no serious advantage over containment. So as well stick with inheritance. At least you cant forget to attach function pointers.

Quote:

For example, will our Menues ever hold something that does not resemble a MenuEntry (which may also be a MenuBox, that in turn holds other MenuEntries)? I doubt so. Why should it hold widgets?


If all widgets inherit stkWidget, then you can "child_add" any stkWidget. So menues can hold radio buttons, checkboxes, labels, etc.....Any stkMenuItem will not even know who the child is.

Quote:

And my favourite example: Why should anything inherit from a tooltip? Should we allow anyone to use his own tooltips? If no, why should there be a virtual function involved ("draw", for example)? For flexibility?


Who asked you to inherit from a tooltip ? tooltips inherits its properties from stkWidget.

BTW, we can have so many kinds of tooltips, ballon tips for example. In that case it may be possible to inherit from tooltips ( of course, you could always set the style property and then handle it in event_draw())

Quote:

There's no one banging your head with a Stroustrup book for not using inheritance. Or encapsulation (especially in those cases where you have to pass objects through a big hierarchy only to get around class boundaries, where a simple publicly available global would have done). On the other hand using OO where it's not needed will bloat our code and lead to badly readable code as well as a performance hog.


Let me put it this way....No one is banging your head with a K&R book for not using structs and function pointers. The rest of the description I can parse. Can you write code ?

I think code speaks a thousand words.

Quote:

So when designing the STK, the first task will be to create a simple containment hierarchy (for example application -> menu, menu->menubox|menuentry, menubox->menubox|menuentry, and so on) as a directed acyclic graph (a tree, but with backlinks) or grammar if you prefer. Then we can find the constraints we deem reasonable and turn them into performance icon_biggrin.gif


Have you read Eric Raymonds notes on free software development. He says there a lot of peopl who say "it has to be this way,...when designing this should......this concept sucks..." etc.. But the people who finally write the code are few.

its this way for now, stkWidget->stkMenuBar->stkMenuItem
stkMenuItem can hold another stkMenuBar and so on.....So its a tree. happy ??
_________________
Ganesh lives @
www.iamganesh.com
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
llogiq



Joined: 05 Jul 2002
Posts: 52
Location: Germany

PostPosted: Wed Jul 17, 2002 2:47 am    Post subject: Reply with quote

_xduffy_ wrote:
ok, ilogiq but if you ever call me xbuffy again...

Ok, xpuffy, but it's still llogiq, not ilogiq. You know who you are

Quote:
What do you mean? Not using inheritance or just havin inheritance where it is needed?

Using it where it gives us more advantages than disadvantages. Remember that you have to carry everything that you inherit. That can suck up lots of RAM, since you probably inherit more than you need.

Quote:
What I really wonder is if there's gonna be the possibility to mix widgets/objects in a way that we didn't think of before without a rewrite of the hierchary?

Good point. Well, if we want them to mix, we just add what we need. What could be easier?
Fact is, there are a lot of ways we can think of that we don't want objects to mix. And have a look at the "flexible" systems out there: A menu bar is still a menu bar, so the code doesn't really change. Our applications should look roughly the same, and we can prevent coders from misusing widgets (which disrupts expectation conformity) in the code, instead of having to set up "style guides".

Quote:
I still think the event manager should be inherited. A class called EventManager or something like that which have virtual functions... and you reimplement the ones you're interested in in you app... or widget/object

I fully agree to that design decision. Maybe we would split the EventManager into different Managers, MouseEventManager, KeyEventManager and others. HotKeys could well be implemented by just calling the onClick function of a manager and some application magic.
Back to top
View user's profile Send private message
_xduffy_
Administrator


Joined: 15 Mar 2002
Posts: 894
Location: Sweden

PostPosted: Wed Jul 17, 2002 10:01 am    Post subject: Reply with quote

Quote:
Ok, xpuffy...

Ok, whatever you say dislogiq

Quote:
Using it where it gives us more advantages than disadvantages. Remember that you have to carry everything that you inherit. That can suck up lots of RAM, since you probably inherit more than you need.

Well, what about ganesh question in the matter? Should we have some strange function pointer? And how about all the common props that ganesh talks about? Couldn't we just make a better implementation of the same thing that MFC/QT does? Wouldn't that be a lot easier both for us and for ppl with experience from other systems...

Quote:
Have you read Eric Raymonds notes on free software development. He says there a lot of peopl who say "it has to be this way,...when designing this should......this concept sucks..." etc.. But the people who finally write the code are few.

You are totally correct, but we haven't entered the phase yet where everybody should start coding like sh*t to make Seal happen... We need planning and design decisions, otherwise we wont be able to roll out Seal 3 with all the good stuff we want...

Quote:
I fully agree to that design decision. Maybe we would split the EventManager into different Managers, MouseEventManager, KeyEventManager and others. HotKeys could well be implemented by just calling the onClick function of a manager and some application magic.

Good idea... I think hotkeys should be very easy to implement 'cause otherwise there will be a great risk that ppl wont do it... and hotkeys are just sooo good
_________________
http://xduffystuff.sourceforge.net/Desktop/
www.xduffy.com
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
llogiq



Joined: 05 Jul 2002
Posts: 52
Location: Germany

PostPosted: Thu Jul 18, 2002 1:11 am    Post subject: Reply with quote

ganesh wrote:
Why C again ? Whats wrong with a single object with C code in it ?? Look at sdkWindowManager.

Why not C? If you merely like it, I'll call it a set of static global C++ functions. And I still think they are a good solution. Let me explain why:
    * There can be more than one C++ object of a class. But - at least in my view - there should be only one windowManager.
    * So our windowManager is (or should be) a singleton. If two windowManagers are instantiated, something goes inherently wrong.
    * When we need only and exactly one windowManager, we can set one up as a static struct with some functions. Remember that static objects in C++ lead to undefined behaviour on shutdown (Things like segfaults may occur). This will also save the time we would need to set up dynamic objects at runtime.

Now please tell me, in words - not in code - why your OO solution would be better.

ganesh wrote:
What ? Do you think Qt and MFC programmers are fools ? Then, I think you have a problem.

The Qt and MFC programmers did a good job. The Qt designers even showed something of the finest pattern usage I've ever seen in code. But both had different goals: The Qt programmers wanted beautiful code more than fast code and the MFC programmers had no intent to port their code - it should just work. They produced some shoddy API design, as every windoze coder will tell you.

ganesh wrote:
All items on screen have to be redrawn, be it stkMenuItems or stkTooltips or whatever. Are you going to store a function pointer for each kindof object and then call it ? Thats BAD.

All items on screen that are subject to change have to be redrawn. (Sory for nitpicking, but I want things clear) When using a virtual function (and that's what you invariably do) you create that function pointer yourself. Or rather the compiler does it for you. So technically both solutions are the same. I do not advocate the use of C where C++ does the job.

ganesh wrote:
Moreover, all widgets have certain basic props like parent, coods, etc...If you see my post on C vc CPP, inheritance provides no serious advantage over containment. So as well stick with inheritance. At least you cant forget to attach function pointers.

Either I don't get you right, or your logic has a serious flaw: If inheritance has no (serious) advantage, you anyway vote for it, because you can throw away function pointers? (What do you think you create when you say int y(int)=0; ?) By the way, does a widget need to know its parent? Why? Does it need to know its coordinates (unless it is drawn)?

ganesh wrote:
If all widgets inherit stkWidget, then you can "child_add" any stkWidget. So menues can hold radio buttons, checkboxes, labels, etc.....Any stkMenuItem will not even know who the child is.

My question is: Would you like an application that has radio buttons in its menues? Or, for the sake of discussion, a spreadsheet? I for sure wouldn't.
ganesh wrote:
Can you write code ?

Yes. But I've made the mistake of writing code without design once (you can see the result at http://klack.sf.net) and learned from it.
ganesh wrote:
I think code speaks a thousand words.

A good design is worth more than a thousand lines of poor code.
ganesh wrote:
Have you read Eric Raymonds notes on free software development. He says there a lot of peopl who say "it has to be this way,...when designing this should......this concept sucks..." etc.. But the people who finally write the code are few.

First, yes I have read his notes. Why are you so authority-religious? First Qt/MFC coders, and now ESR...

We want to clean-rebuild a working system, so we ask ourselves what happened to the system that it needs to be rebuilt, instead of putting the same system in OO handcuffs.

"Complex systems that work are invariably found to emerge from simple systems that work." -- Unknown
Back to top
View user's profile Send private message
Fenix*NBK*



Joined: 29 Nov 2003
Posts: 28

PostPosted: Sun Nov 30, 2003 12:13 am    Post subject: Hello Guys! Reply with quote

I am a new user of The Seal.
I liked it, because it reminds me the good-old Windows 3.11.

I heard, that you have a problem with a GUI.

I have a solution. My Engine, AAuto2D is written
entirely in C++, and is platform-independed, however since it started as an MFC project, the interface may remind you MFC a little.

Anyway, I don't know C, so I can't port AAuto2D to seal, but I can give you the code, and tell what EXACTLY must be changed and WHERE, so you will get it working quickly. It's not perfect, slow, may have little bugs (not too much, not critical), but has a LOT of features Seal can only dream about having them.

I can make it a reality.

Features:

Pixels, Lines, Circles, Ellipses, Rectangle, and RoundRectangles.
It has gradients (rectangles and triangles), flood-fills, anti-aliasing,
can draw stars, has grayscaling, gamma, contrast, platform specific Hardware 2D Acceleration, palletes, more than 200 predefined color in color library, color-transformations library,
Data Types : Rectangles, Triangles, Lines, RoundRects, ...

Unfortunately, Text Drawing is supported only in MFC (Win32).
I couldn't develop my own platform-independed fonts.

Now about the licensing terms: I will give you this engine, with source code for free, but if I'll want to use it later for commercial projects,
I'll leave this right to me.
Back to top
View user's profile Send private message Send e-mail
biggyp



Joined: 16 Oct 2001
Posts: 1473
Location: England, United Kingdom

PostPosted: Wed Dec 03, 2003 8:09 am    Post subject: Reply with quote

look at the last serious posts around here, and then examine their dates.

and, come on, if you want to see your code played with you'll have to license it in line with the rest of SEAL2, GNU GPL(or compatible) please, or forget it.
_________________
http://www.theopencd.org/ - OpenSource for the Masses

Gallery



Last edited by biggyp on Mon Dec 15, 2003 1:29 pm; edited 1 time in total
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
Display posts from previous:   
Post new topic   Reply to topic    SEAL Forum Index -> Seal 3.0 Development All times are GMT - 7 Hours
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group