On Sat, 17 Jan 2004 20:53:01 +0000, John Reimer wrote:

> 
>>Keep us updated on progress ?
>>
>>C
> 
> Sure, once in awhile maybe. But it may be awhile until I have anything that works. Or it may not... :)

can we just create the entire class hierarchy,
using swig. then we just "fill in the blanks".

my swig is still running
let me see what I can do in 30 mn.
(maybe 20mn it's dinner time here)

what is wxUniversal is that what we need?

Ant

>can we just create the entire class hierarchy,
>using swig. then we just "fill in the blanks".

You sure can try! I don't know much about swig, so it would be nice if you could look into that.  The conversion may be pretty ugly, though.

>my swig is still running
>let me see what I can do in 30 mn.
>(maybe 20mn it's dinner time here)

Sure thing.  I'm at work all weekend so I'm stuck using a limited station computer.  I can't do much from here anyway other than study some of the web-interfaced sources.

>what is wxUniversal is that what we need?

www.wxwindows.org/wxuniv.htm

That's the new port for all platforms that implements it's own widget sets instead of calling OS dependent ones. This allows it to have a look/feel consistant across platforms.  I'm sure it bloats wxWindows quite a bit too. It's not really functional yet.  It might be best to stick to a msw (ms windows branch) or gtk branch.

My own plan was to create a significantly reduced skeleton of wxWindows following it's design.  I'm a little confused, though, at how to implement the main in windows: I want to hide the winmain entry so no windows specific functuality is revealed to the library user.  I'll have to check dig out again to see how Burton did it. wxWindows uses a ton of macros to hide it.  Is there a web viewable version of the dig source? I can't download it to this computer so I need to view it somehow.

Later,

John

Ant wrote:

>On Sun, 18 Jan 2004 02:52:16 +0800, J Anderson wrote:
>
>  
>
>>Ant
>>
>>    
>>
>>>Can we go with an OpenGL toolkit?
>>>      
>>>
>>I should add that before you brought this up I was seriously considering doing an openGL toolkit for Windy, basing it of dig's openGL but taking it further.  Parhaps forming a group (Yeah right you say! Are there any D groups at all?)
>>    
>>
>
>there are lots of D groups (one element each)
>
>I still didn't give up.
>I'll post here 'significative' milestones on this idea.
>please do the same.
>
>  
>
>>to do small parts of the openGL toolkit such as texture loading, scenegraphs, gltext and an openGL gui toolbox -> some of which would simply be converted C libraries. The openGL part of Windy could be separted, to reduce size if it got to large.
>>
>>However, that was one of the many spare-time-projects I may consider 4 or 5 months from now when I get free time.  And I'm not commiting to anything at the moment ;)
>>    
>>
>
>In 4/5 months we should have the API for the main D GUI toolkit
>(positive thinking - in reality this all project will be forgotten
>in 1 week :( ) so maybe it's a better idea to use the API from that.
>That will mean we will have another implementations of the D GUI
>that is good for "new systems" not dependent on a "battery charge"...
>
>Ant
>
>  
>
Yeah, something like that. But generally, your still going to need all the basics in openGL (such as glText ect...) before you can have a GUI.  Plus, I wasn't only thinking openGL GUI.  Common things like scene graphs and static material graphs could be put into the openGL toolkit, which wouldn't nessarly be related to openGL.

The trouble I've had with openGL, is that it's missing allot of things, such as text and menus.  And in most cases using the OS standard GUI, just doesn't look right (game like).  Everybody that uses it virtually has to go hunting for the right opengl extensions or write them themselves.

I was also think parhaps having something that could be used cross-gui. The gui's would simply do the ralivent interfacing. ie both Windy and DUI would interface to the same openGL toolkit.  But all that's (for me at least is 4 or 5 months away).

-Anderson

John Reimer wrote:
...
> My own plan was to create a significantly reduced skeleton of wxWindows
> following it's design.  I'm a little confused, though, at how to implement the
> main in windows: I want to hide the winmain entry so no windows specific
> functuality is revealed to the library user.  I'll have to check dig out again
> to see how Burton did it. wxWindows uses a ton of macros to hide it.  Is there a
> web viewable version of the dig source? I can't download it to this computer so
> I need to view it somehow.
> 
> Later,
> 
> John

Here is some newly created html-ized dig source:
http://jcc_7.tripod.com/d/dig/

It's not all of the dig sources, but I hope it'll show you want you want to know.  (I can't tell you how dig works; I just know that it does work.)

* examples.scintilla is the shortest example.
* platform.frame has an event handler.

Good luck.

-- 
Justin
http://jcc_7.tripod.com/d/

>
>Here is some newly created html-ized dig source: http://jcc_7.tripod.com/d/dig/
>
>It's not all of the dig sources, but I hope it'll show you want you want to know.  (I can't tell you how dig works; I just know that it does work.)
>
>* examples.scintilla is the shortest example.
>* platform.frame has an event handler.
>
>Good luck.

Thanks, Justin! I really appreciate this!

I'm thinking of getting a laptop so that I can carry all the code with me while I'm away for my 4-5 day work stints.  Then I can experiment away as much as necesary. That's one of the few advantages of my job.

Thanks again,

John

In article <bucjga$q2n$1@digitaldaemon.com>, John Reimer says...
>
>>can we just create the entire class hierarchy,
>>using swig. then we just "fill in the blanks".
>
>You sure can try!

Couldn't even get to first base...

>
>That's the new port for all platforms that implements it's own widget sets instead of calling OS dependent ones.

Interesting (roughly and roughly chronological):
java AWT - use only common native widgets
java swing - don't use native widget, implements "full" set of widgets
eclise SWT - use native widgets where possible, implement others
wxWindows - use native widgets
wxWindowsUniversal - don't use native widgets.

Seems people still doesn't know what's more important,
give the user a consistent look and feel on a specific platform or
give the same application the same look and feel accross different
platforms.

(Definitivly the user sould have a consistent look and feel in one platform. Or maybe that's a view of the past?)

>This allows it to have a look/feel
>consistant across platforms.  I'm sure it bloats wxWindows quite a bit too.

Seems that wxWindows is just the API all those are implementations of that API. How independent are they?

>My own plan was to create a significantly reduced skeleton of wxWindows following it's design.  I'm a little confused, though, at how to implement the main in windows: I want to hide the winmain entry so no windows specific functuality is revealed to the library user.

I wouldn't worry too much with implementation right now. Let's see what we have and design a strategy before jump into it.

If you start doing things "your way" people will avoid colaborating. if we start slower maybe we can get into a faster speed later.

Do you wanna do it your self or create a colaborating group?

Ant

>
>Couldn't even get to first base...
>

I was wondering if that would happen.

>Interesting (roughly and roughly chronological):
>java AWT - use only common native widgets
>java swing - don't use native widget, implements "full" set of widgets
>eclise SWT - use native widgets where possible, implement others
>wxWindows - use native widgets
>wxWindowsUniversal - don't use native widgets.
>
>Seems people still doesn't know what's more important,
>give the user a consistent look and feel on a specific platform or
>give the same application the same look and feel accross different
>platforms.

>(Definitivly the user sould have a consistent look and feel in one platform. Or maybe that's a view of the past?)

I tend to think the same.  The user should get the look/feel of each platform verses one universal one. Other opinions?

>>This allows it to have a look/feel
>>consistant across platforms.  I'm sure it bloats wxWindows quite a bit too.
>
>Seems that wxWindows is just the API all those are implementations of that API. How independent are they?

Yes, I believe so.  As far as I can see, the different ports are mostly just changing the underlying GUI code (win32 or gtk+).  Classes and such should stay mostly the same.  There does appear to be some variances, such as enabling support for proprietary "features" on each platform.  These are enabled/disabled per user preference.

>
>>My own plan was to create a significantly reduced skeleton of wxWindows following it's design.  I'm a little confused, though, at how to implement the main in windows: I want to hide the winmain entry so no windows specific functuality is revealed to the library user.
>
>I wouldn't worry too much with implementation right now. Let's see what we have and design a strategy before jump into it.

Ok, agreed. I was eager to see some results, that's all :).

>If you start doing things "your way" people will avoid colaborating. if we start slower maybe we can get into a faster speed later.
>
>Do you wanna do it your self or create a colaborating group?

I initially wasn't thinking of collaborating, partly because it was a personal curiosity, and I wasn't sure how many people would take active interest in it. But now that you mention it, you're right.  I would be stupid to take on this thing without collaborating. I'm not an experienced developer and could use some direction here and plenty of collaboration with individuals of far superior knowledge/experience.  That would be the only sure way to guarantee a well-designed D port. If you are willing to take part in this, I would be honoured to work it out with you.  I know you are a busy developer, but if you could spare some time and experience with this, I think it is a worthy project. At least, we'll find out if it is.

Later,

John

In article <bu6op9$3fr$1@digitaldaemon.com>, Ant wrote:
> In article <bu6nm5$1fk$1@digitaldaemon.com>, Patrick Down says...
>>If it's available.  Most new systems shipped today have some decent/minimal hardware accelerated graphics but this but this trend is only a couple of years old.  There are a lot of legacy systems out there that would have trouble supporting this.
> 
> Don't look back! Look forward!

Good principle, especially when basic hardware 2d/3d acceleration is such an abundant feature that you can expect to have it everywhere. And you could have different implementations for the toolkit, not necessarily looking the same - implemented using OpenGL, DirectX, native graphics primitives, even one using the native widget set if the back-end is made high-level enough.

>>It would be interesting to look at.  Isn't the GUI for MacOS X done with OpenGL?
> 
> This is not a new idea.
> The first time I remember was some years ago when I was
> experiment with the fox toolkit.
> ( http://www.fox-toolkit.org )
> One of the fox objectives is to be fast and the guy
> said that he sould really skip all the layers and go
> directly to OpenGL interface.

Is Fox really implemented in "pure" OpenGL? I didn't find any mention about it in the docs... Anyway, thanks for the link, it looks like a nice toolkit. I had never heard about it before!

-Antti

In article <slrnc0oa7s.1o3.jsykari@pulu.hut.fi>, Antti =?iso-8859-1?Q?Syk=E4ri?= says...
>
>
>Is Fox really implemented in "pure" OpenGL? I didn't find any mention about it in the docs...

oh, no, I'm sorry if I miss lead you.
That's something he said on the mailing list several years
ago when speaking on all the layers from the application
to the hardware. He said that OpenGL would a more direct route.

>Anyway, thanks for the link, it looks like a
>nice toolkit. I had never heard about it before!
>
>-Antti
>

Ant

In article <buh7gc$27up$1@digitaldaemon.com>, John Reimer says...
>
> If you are willing to take part in this,

Sure, but I also want to finish my other D projects.
DUI is still valid.
Ant I wouldn't start this without a minimum IDE (ie leds;)

Ant