Charles wrote:
>> because SWT is a large toolkit that has severe issues.
> 
> What issues ?
(Brief reply, gotta go to work)

There are many if you google for them. In short, their class hierarchy is poorly designed. Since that's what we'd be borrowing from them, I view that as a pretty bad move.

Also, the various SWT implementations don't always work well. Finally, since the core of SWT is in C, you can make it crass REALLY bad. Running a while(1) System.out.print("."); in an SWT thread can cause a BSOD on windows.

The SWT layout engine isn't bad, but it isn't fantastic either.
.
.
.
But this is just me rambling. These sort of issues need to be itemized and presented in an organized fashion.

Oh, and: http://www.hacknot.info/hacknot/action/showEntry?eid=74

those issues too.

"Derek Parnell" <derek@psych.ward> wrote in message news:e2nam8zl4e3k$.1htyv23ne0hg2.dlg@40tude.net...
> On Sun, 5 Feb 2006 20:31:44 -0800, Andrew Fedoniouk wrote:
>
>
> [snip]
>
>> Let's start from the fact that "Standard D Graphics" has its
>> own value ...
>> ... So first is SDG as it is really independent module.
>>
>> Next thing on the road to Standard GUI Framework is
>>
>> Application Module:
>>   It contains Application and Window classes.
>>
>>   Application is a wrapper around main/winmain
>>   and implementation of message pump. (Get/DispatchMessage)
>>
>>   Window (or Frame) is a top level OS window.
>>
> ...
>> And after that we can define
>> OsWidgets module ...
>
>> I am not sure if I expalined this clear enough...
>
> I think we are one on this. You have explained it well and I agree with
> the
> strategy.
>
> Have we enough skills to write a fast 2D library or do we leverage off
> existing ones? I know I can write a basic graphics library ('cos I've done
> it a couple of times already) but I've never had to optimize it to the Nth
> degree as I suspect one would have to for general usage. For example, do
> we
> use hardware acceleration when possible or do it all through software? And
> do we worry about unusual screen geometries (such as multiple screens
> making a single virtual screen)? I assume a stock 2d library would not be
> interested in 3d effects (shading, Z-axis, etc...) but it would be
> interested in anti-aliasing and alpha-blending.
>

I thought about something different.

Typical implementation is:

Two classes:
Graphics and GraphicsEx : Graphics
and interface ISurface.

Graphics is a set of basic functions to draw on some
surface. GraphicsEx is a set of extended functions,
in Java it is known as Graphics2D - extended set for
vector drawings - antialiasing and extended line styles,
transformations etc.

Graphics in Windows is a pretty much wrapper of
HDC functions, ISurface is a HDC handler provider:
Objects like Window, Image and Printer implement
ISurface.

GraphicsEx (2D) could be a wrapper of GDI+, OpenGL, Quartz2D, AGG or DirectX derived gfx subsystem of Vista.

The idea is simple: for UI implementation
you need only Graphics (like in Harmonia I use only 10 or so
graphic functions). For various vector graphic tasks you will
need GraphicsEx.

Having them both will allow to use only what is needed.
As GraphicsEx is a Graphics too thus you can draw your
UI on e.g. OpenGL surfaces if needed.

Graphics has concrete implementations
for each platform : on windows it is Graphics:Win32Graphics
or even Graphics:GC on DWT if DWT will need to use some
components knowing only about Graphics.

Even on the same platform there are multiple rendering
engines available. Graphics[Ex] will alow to cover them.
I don't think that we need to implement low level drawing.
It would be too much for most of practical cases.
For sure we shall cover at least official OS
drawing primitives GDI/GDI+  and DirectDraw/Quarts2D.

Andrew Fedoniouk.
http://terrainformatica.com

"nick" <nick.atamas@gmail.com> wrote in message news:ds7542$2fvm$1@digitaldaemon.com...
> I should caution you against DWT/SWT. In addition to reasons outlined by Roberto Mariottini SWT will be viewed by many people as a "bad move for D", because SWT is a large toolkit that has severe issues. This will create a negative image of stagnation and other negative characteristics associated with SWT. JFace is even more problematic.

The problem is, I've heard such strongly negative comments about every GUI toolkit out there.

Walter Bright wrote:
> 
> I don't think there is one point - the blocking items for people are different. Some seem to be blocked by templates, others by regex, others by recls (hi Matthew!), others by gui, others by there's no D book, etc. We just have to keep bashing away at this. 
> 
> 
You forgot 'full-featured IDE'. :P


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

clayasaurus wrote:
> Sean Kelly wrote:
>> <snip> For D to be taught in a university course I think it probably needs a book about it. </snip>
>>
>>
>> Sean
> 
> I told my professor about D and he really liked the language comparison chart on digitalmars.com because it used the same words as his 'Principles of Programming Languages' course. He told me he might include D as one of the languages to compare for the next year.

Using that comparision is probably not good, as it is awfully outdated, and (more arguably) perhaps a bit biased. Perhaps the Wiki4D one is better suited. (and Walter, you may want to start thinking about updating that one in light of Java 1.5 and C# 2.0 (or even 3.0))

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

"nick" <nick.atamas@gmail.com> wrote in message news:ds7un0$6va$1@digitaldaemon.com...
> Oh, and: http://www.hacknot.info/hacknot/action/showEntry?eid=74
>
> those issues too.

Thanks for the pointer. One issue stood out for me - that Swing is 7 years ahead of SWT. This reiterates my belief that if D tries to develop our own gui, it will take 10 years. We don't have 10 years to do it. An existing one has to be used.

"Walter Bright" <newshound@digitalmars.com> wrote in message news:ds83p6$bmf$3@digitaldaemon.com...
>
> "nick" <nick.atamas@gmail.com> wrote in message news:ds7542$2fvm$1@digitaldaemon.com...
>> I should caution you against DWT/SWT. In addition to reasons outlined by Roberto Mariottini SWT will be viewed by many people as a "bad move for D", because SWT is a large toolkit that has severe issues. This will create a negative image of stagnation and other negative characteristics associated with SWT. JFace is even more problematic.
>
> The problem is, I've heard such strongly negative comments about every GUI toolkit out there.

The reason is simple: people have different requirements for their tasks. For someone DFL is the best so other toolkits are just garbage. And so on.

No one *toolkit* can serve "Standard D GUI" purposes as each toolkit
is dedicated to be a solution for some task or pretty narrow group of tasks.

E.g. someone needs OpenGL and for him either DFL or DWT is just nothing.

As I mentioned before: task of creation of "Standard D GUI" is conceptually different from creation of a "toolkit". (looks like words game but anyway)

Conceptually:
"Standard D GUI" is a set of modules. Concrete set of particular
modules is a toolkit.

For example "Arcade Game UI Toolkit" is a set of :
   Standard Graphics Module( using OpenGL "surface" for example ),
   Standard Application Module,
   Standard Windowless Widget Set Module,
   Game specific modules.

"IDE Toolkit" is a set of :
   Standard Graphics Module( using basic "surface" ),
   Standard Application Module,
   Standard Windowed Widget Set Module (may be yes or may be no),
   Document/View Module, Plugins Module, etc.

Andrew.

Andrew Fedoniouk wrote:
> "Derek Parnell" <derek@psych.ward> wrote in message news:e2nam8zl4e3k$.1htyv23ne0hg2.dlg@40tude.net...
>> On Sun, 5 Feb 2006 20:31:44 -0800, Andrew Fedoniouk wrote:
>>
>>
>> [snip]
>>
>>> Let's start from the fact that "Standard D Graphics" has its
>>> own value ...
>>> ... So first is SDG as it is really independent module.
>>>
>>> Next thing on the road to Standard GUI Framework is
>>>
>>> Application Module:
>>>   It contains Application and Window classes.
>>>
>>>   Application is a wrapper around main/winmain
>>>   and implementation of message pump. (Get/DispatchMessage)
>>>
>>>   Window (or Frame) is a top level OS window.
>>>
>> ...
>>> And after that we can define
>>> OsWidgets module ...
>>> I am not sure if I expalined this clear enough...
>> I think we are one on this. You have explained it well and I agree with the
>> strategy.
>>
>> Have we enough skills to write a fast 2D library or do we leverage off
>> existing ones? I know I can write a basic graphics library ('cos I've done
>> it a couple of times already) but I've never had to optimize it to the Nth
>> degree as I suspect one would have to for general usage. For example, do we
>> use hardware acceleration when possible or do it all through software? And
>> do we worry about unusual screen geometries (such as multiple screens
>> making a single virtual screen)? I assume a stock 2d library would not be
>> interested in 3d effects (shading, Z-axis, etc...) but it would be
>> interested in anti-aliasing and alpha-blending.
>>
> 
> I thought about something different.
> 
> Typical implementation is:
> 
> Two classes:
> Graphics and GraphicsEx : Graphics
> and interface ISurface.
> 
> Graphics is a set of basic functions to draw on some
> surface. GraphicsEx is a set of extended functions,
> in Java it is known as Graphics2D - extended set for
> vector drawings - antialiasing and extended line styles,
> transformations etc.
> 
> Graphics in Windows is a pretty much wrapper of
> HDC functions, ISurface is a HDC handler provider:
> Objects like Window, Image and Printer implement
> ISurface.
> 
> GraphicsEx (2D) could be a wrapper of GDI+, OpenGL,
> Quartz2D, AGG or DirectX derived gfx subsystem of Vista.
> 
> The idea is simple: for UI implementation
> you need only Graphics (like in Harmonia I use only 10 or so
> graphic functions). For various vector graphic tasks you will
> need GraphicsEx.
> 
> Having them both will allow to use only what is needed.
> As GraphicsEx is a Graphics too thus you can draw your
> UI on e.g. OpenGL surfaces if needed.
> 
> Graphics has concrete implementations
> for each platform : on windows it is Graphics:Win32Graphics
> or even Graphics:GC on DWT if DWT will need to use some
> components knowing only about Graphics.
> 
> Even on the same platform there are multiple rendering
> engines available. Graphics[Ex] will alow to cover them.
> I don't think that we need to implement low level drawing.
> It would be too much for most of practical cases.
> For sure we shall cover at least official OS
> drawing primitives GDI/GDI+  and DirectDraw/Quarts2D.
> 
> Andrew Fedoniouk.
> http://terrainformatica.com
> 

Let the first say I find quite good this idea of having a common (i.e. standard) primitive graphics library in D. Not only because it is more readily available, but especially because it can later be used upon to build higher level libraries like the advanced graphics lib or a GUI lib, with a higher degree of unification. (For instance there could be several GUI libs, but nonetheless they would share the same graphic primitives).

As for this primitive graphics library, there already exists one, (made in C), and it not only exists, but it is *The* library. I hope you know which one I'm talking about, and I hope too that you realize that your work should be to make a D layer/version of this lib. Not a direct C wrapper, as that already exists, but one to make use of the relevant D's prime features (OO and structured namespacing)


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

"nick" <nick.atamas@gmail.com> wrote ...
> There are many if you google for them. In short, their class hierarchy is poorly designed. Since that's what we'd be borrowing from them, I view that as a pretty bad move.

That's a bit nebulous, Nick. Can you be specific as to exactly what is so bad?


> Also, the various SWT implementations don't always work well.

Really? Can you be just a bit more specific?


>Finally, since the core of SWT is in C, you can make it crass REALLY bad.

The core of SWT is written in C? Are you quite, quite sure?


> The SWT layout engine isn't bad, but it isn't fantastic either.

I see. Perhaps you could qualify that also? The statement just seems a bit, empty?


> But this is just me rambling. These sort of issues need to be itemized and presented in an organized fashion.

Yes, they should. It seems you have a strong opinion on the matter and, judging by the above assertions, would appear to be /very/ knowledgable about SWT. It would be helpful if you could back up your points with concrete evidence and examples.