New guy

RE: New Guy

> I'd really love to see some hardware acceleration in this puppy.

Harware acceleration is difficult to get working because card manufacturers
have to closely guard their technology these days and can't release specs
openly.  Likewise, they won't develop binary drivers because there isn't
enough of a market for things like GGI, Y, and directFB.

It would be great if someone had the expertise and wilingness to port
XFree86 drivers to these projects, but if they did then we would have seen
accelerated GGI, accelerated DirectFB, and accelerated FBDEV a long time
ago.  As it stands, accelerated GGI is all but dead and the DirectFB project
is still trying to implement acceleration for cards that went obsolete two
years ago.

I think acceleration is too big a fish for now (the catch 22 is that no one
wants to use/develop a new graphics API if it doesn't have acceleration -
*sigh*).

> Mono... I see that this would have to be put off until the 40-some-odd
widgets are
developed and tested.

Correct.  I think porting Mono is about 10 steps ahead of the game at this
point.

Mack

Spec vs. Implementation

I think the best way to develop a window system these days is to develop a
specification instead of a single source tree implementation.  You'd simply
publish the specification (like the X Window spec or Java spec), and let
anyone who wants to develop an implementation have at it.  The advantage of
this is:

1)  Everyone can develop their own Y Server on whatever hardware/OS they
want.  All they have to do is make sure that they interface with the client
API properly.  So, if Joe Blow knows how to do hardware acceleration on a
Xenocorp Model 300X Ultracomputer then by all means he can create his own
fully optimized Model 300X Y Server without having to worry about having to
target SDL, DirectX, OpenGL, GGI, DirectFB, SVGALIB, iPAQ, Palmpilot, etc.
in the same source tree.

2)  In the same vane as point #1 above, it simplifies the reference
implementation (i.e. the current source tree) because it doesn't have to be
portable.  We don't need a gazillion abstraction layers in the reference
implementation to account for every single possible hardware/OS
configuration.

3)  They can write the Y server in whatever programming language they want.
It can be C, C++, Lisp, even friggin perl if they want.  So long as a client
can connect to it and send Y messages, it doesn't matter what language the
server is programmed in.

4)  There can be more developers working/exploring the project.  With one
source tree, only a few people can submit changes without screwing it up.
You don't want everyone and their grandmother dipping into the source and
changing things.  But if there are multiple small groups implementing their
own Y servers they can do as they please.

5)  Makes it easier to develop.  I guess this is just a rehash, but if
everyone can use their own language and coding style; develop and their own
pace; and not have to flip through a huge, over-abstracted, single base of
code; then it will be easier for them to work on the project.  For example,
when I look at a function called DrawWindow() I want to see code that puts a
grey box on the screen.  I don't want to see two or three layers of
abstraction, pointers to user-defined functions, structures that hold
who-knows-what information, and other garbage.

Whaddya think?

Mack

Re: Spec vs. Implementation

On 2004-07-02 11:17:11 +0800 clearm <clearm <at> comcast.net> wrote:

> I think the best way to develop a window system these days is 
> to develop a
> specification instead of a single source tree implementation.  
> You'd simply
> publish the specification (like the X Window spec or Java 
> spec), and let
> anyone who wants to develop an implementation have at it.  The 
> advantage of
> this is:
> 
> 1)  Everyone can develop their own Y Server on whatever 
> hardware/OS they
> want.  All they have to do is make sure that they interface 
> with the client
> API properly.  So, if Joe Blow knows how to do hardware 
> acceleration on a
> Xenocorp Model 300X Ultracomputer then by all means he can 
> create his own
> fully optimized Model 300X Y Server without having to worry 
> about having to
> target SDL, DirectX, OpenGL, GGI, DirectFB, SVGALIB, iPAQ, 
> Palmpilot, etc.
> in the same source tree.
> 
> 2)  In the same vane as point #1 above, it simplifies the 
> reference
> implementation (i.e. the current source tree) because it 
> doesn't have to be
> portable.  We don't need a gazillion abstraction layers in the 
> reference
> implementation to account for every single possible hardware/OS
> configuration.
> 
> 3)  They can write the Y server in whatever programming 
> language they want.
> It can be C, C++, Lisp, even friggin perl if they want.  So 
> long as a client
> can connect to it and send Y messages, it doesn't matter what 
> language the
> server is programmed in.
> 
> 4)  There can be more developers working/exploring the 
> project.  With one
> source tree, only a few people can submit changes without 
> screwing it up.
> You don't want everyone and their grandmother dipping into the 
> source and
> changing things.  But if there are multiple small groups 
> implementing their
> own Y servers they can do as they please.
> 
> 5)  Makes it easier to develop.  I guess this is just a 
> rehash, but if
> everyone can use their own language and coding style; develop 
> and their own
> pace; and not have to flip through a huge, over-abstracted, 
> single base of
> code; then it will be easier for them to work on the project.  
> For example,
> when I look at a function called DrawWindow() I want to see 
> code that puts a
> grey box on the screen.  I don't want to see two or three 
> layers of
> abstraction, pointers to user-defined functions, structures 
> that hold
> who-knows-what information, and other garbage.
> 
> Whaddya think?
> 
> Mack
> 
> 
> 

I like that idea. Then all Mark has to do is make a reference 
implementation.

opengl

has anybody tried using opengl for drawing widgets?

Generating Interest

I don't mean to advertise, but I started a new website which I hope will
increase interest and knowledge in Y Windows and other 2D graphics projects.
Its at http://www.linux2d.org .  Mostly I'm interested in FBDEV programming,
which is lower level than GGI, SDL and DirectFB.  My goal is to teach people
how to roll their own graphics APIs if they want to instead of relying on
the canned ones.  I'm also interested in developing window systems and GUI
API's.

I remember a few years ago when DOS mode 13h programming was popular and
there were web pages all over dedicated to Mode 13h game programming.
Anyone remember Allegro and DJGPP?  That is the community that I'm trying to
recreate, except I want to do it in the Linux world using the framebuffer
device.  Hopefully, with enough interest and applications written for FBDEV,
we will see more interest in developing accelerated FBDEV drivers.

I'm not all that interested in GGI or DirectFB.  Both of them have obtuse,
over-abstracted API's.  I wonder why people keep trying to write portable
graphics API's when the portability-inspired abstaction layers make them so
complex and over-engineered that nobody wants to use them (let alone port
them) in the first place?!?!

I also recently discovered how to do mouse programming via the new kernel
event interface.  So a new mouse tutorial is coming soon in addition to the
few tutorials that are already there.

Be sure to visit the forum too!  No registration required!  Send me your
libs/links and I'll post them!

MC

RE: opengl

> has anybody tried using opengl for drawing widgets?

Take a look here:  http://glow.sourceforge.net/

Its built on GLUT though.

-- MC

RE: opengl

On 2004-07-02 13:13:55 +0800 clearm <clearm <at> comcast.net> wrote:

>> has anybody tried using opengl for drawing widgets?
> 
> Take a look here:  http://glow.sourceforge.net/
> 
> Its built on GLUT though.
> 

Im going to port Y to opengl using miniglx. I will develop on 
GLX first then port it to miniglx when it has stabilised.

RE: opengl

On 2004-07-02 14:54:25 +0800 Rogelio Serrano 
<rogelio <at> smsglobal.net> wrote:

> On 2004-07-02 14:41:29 +0800 clearm <clearm <at> comcast.net> wrote:
> 
>>> Im going to port Y to opengl using miniglx. I will develop on
>>> GLX first then port it to miniglx when it has stabilised.
>>> 
>>> Check out Glitz while you're at it.  Its the Quartz Extreme 
>>> equivalent
>> being developed by freedesktop.org.
>> 
>> 
> 
> I already did looks ok. Im just a little hesitant to hack 
> cairo and make it 
> work on fbdev/dri and miniglx. Maybe i will try that first. 
> But then that 
> would mean porting Y to cairo instead. I dont want to use Y+ 
> its in c++. And 
> my system is objc only.
> 

It might be easier to develop Y when i can run it in an opengl 
window in x.

Question about events

I have a question about implementing an event system - perhaps someone can
answer this...

BACKGROUND:  Window systems such as X and Y have event systems that notify
client apps when certain events occur.  Some of these notifications are easy
to program, such as key presses and mouse clicks - when the keyboard driver
or mouse driver tells the server that a key is pressed or the mouse is
moved, then the window system simply sends a "keypressNotify" or
"mousemoveNotify" event to the application.  But other notifications seem
very difficult to implement, for example "enterNotify" and "leaveNotify"
events.

QUESTION:  How does a window system know when the mouse enters/leaves the
bounding box of a particular window/widget, especially since these
windows/widgets are nested within one another?  Does the window system have
to test the mouse cursor location against the bounds of each window/widget
*every* time the pointer moves?!?!  That seems like an awful lot of work if
there are a lot of windows/widgets on screen.  It also means a lot of if
statements, which means it's terribly inefficient on a pipelined processor.

How do window systems implement enterNotify and leaveNotify event
notifications?

-- MC