View mode: basic / threaded / horizontal-split · Log in · Help
January 17, 2004
Re: D gui
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
January 18, 2004
Re: D gui
>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
January 18, 2004
Re: D gui (openGL GUI)
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
January 18, 2004
Re: D gui (dig source)
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/
January 18, 2004
Re: D gui (dig source)
>
>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
January 19, 2004
Re: D gui
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
January 19, 2004
Re: D gui
>
>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
January 19, 2004
Re: D gui
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
January 19, 2004
Re: D gui
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
January 19, 2004
Re: D gui
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
2 3 4 5 6 7 8 9 10
Top | Discussion index | About this forum | D home