Bruno Medeiros wrote:
> 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)
> 
> 

Are you talking about GTK? If so, maybe you should check out DUI. ( www.dsource.org/projects/dui )

In article <ds8n8h$t0a$1@digitaldaemon.com>, Andrew Fedoniouk says...
>
>
>"Walter Bright" <newshound@digitalmars.com> wrote in message news:ds8lvv$s2k$2@digitaldaemon.com...
>>
>> QT cannot be used because it's a proprietary, non-free product.
>
>Yep, and yet: http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12 :)
>

SWTs problems are slightly different, although that's a pretty good assessment of the Java API. It tries to be too modular. It's fine to be modular, too abstract, a factory for building blueprints of factories that builds factories for hammer.  It's fine to be that modular, as long as you provide an easy-to-grasp API that people can just start using. Java doesn't do that, one really bad example is the secure sockets in Java 5.

In article <ds8lvv$s2k$2@digitaldaemon.com>, Walter Bright says...
>
>
>"nick" <nick_member@pathlink.com> wrote in message news:ds8f77$mvh$1@digitaldaemon.com...
>> If I had to pick a toolkit to port right off the top of my head, I would choose QT.
>
>QT cannot be used because it's a proprietary, non-free product.
>
QT is an open source product. It is only proprietary if you plan to use it for proprietary means. KDE is based on QT from ground up.

The very least we can do, is ask advice from Scott; he would gladly help an open source initiative.

nick wrote:
> In article <ds8lvv$s2k$2@digitaldaemon.com>, Walter Bright says...
>>
>> "nick" <nick_member@pathlink.com> wrote in message news:ds8f77$mvh$1@digitaldaemon.com...
>>> If I had to pick a toolkit to port right off the top of my head, I would choose QT.
>> QT cannot be used because it's a proprietary, non-free product. 
>>
> QT is an open source product. It is only proprietary if you plan to use it for
> proprietary means. KDE is based on QT from ground up.
> 
> The very least we can do, is ask advice from Scott; he would gladly help an open
> source initiative.

The problem is that while the D libraries are open source, not all applications using D will be.  Given the viral nature of open-source licenses, I think this would prevent Qt from being used in such a project, no?


Sean

In article <ds8kd6$r1b$1@digitaldaemon.com>, Bruno Medeiros says...

>We need it now, really? Why?
>Of all the problems people have with D: language features (templates,
>ITFI, many more...), fixing/improving the standard library,
>fixing/improving the docs, contributing new stuff(regexps, recls, etc.)
>possibly in-language, toolchain (full-featured IDE/editor, full-featured
>debugger), books in D, and "having a GUI", the GUI one is a superficial
>one.
>We already have pretty decent GUI libs and the difference between a GUI
>being official/standard or not could only possibly be in having to
>download and install an additional package besides the compiler, whereas
>the other problems are actually important. They cannot be workedaround
>and will actually require significant work by part of Walter and/or
>someone else in the community. So how can *anyone* call this GUI issue a
>real problem?
>
>I would like the GUI proponents to explain this to me, as the few posts about this that I vaguely recall from far ago were simple "D needs a GUI too, because I like GUI very much", but no rationale how or why (or even explicit mention of the term "standard").
>

Having the default gui saves people the trouble of having to do research and find the best one.

With that said, I think that an IDE is the biggest showstopper in the foreseeable future. Many tasks don't require a gui, but almost everyone wants to avoid the command line(ok, some 1337 linux people like it).

Of course, having a non-finalized language spec seems pretty problematic as well... but it may be a good idea to make some hard choices and freeze the language spec soon. There can always be a D1.1 and D 1.2 and so on; features can be removed and inserted. (Hey, we've got the deprecate keyword!)

So, basically I agree with you.

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

In article <ds8tqr$11ti$1@digitaldaemon.com>, Sean Kelly says...
>
>nick wrote:
>> In article <ds8lvv$s2k$2@digitaldaemon.com>, Walter Bright says...
>>>
>>> "nick" <nick_member@pathlink.com> wrote in message news:ds8f77$mvh$1@digitaldaemon.com...
>>>> If I had to pick a toolkit to port right off the top of my head, I would choose QT.
>>> QT cannot be used because it's a proprietary, non-free product.
>>>
>> QT is an open source product. It is only proprietary if you plan to use it for proprietary means. KDE is based on QT from ground up.
>> 
>> The very least we can do, is ask advice from Scott; he would gladly help an open source initiative.
>
>The problem is that while the D libraries are open source, not all applications using D will be.  Given the viral nature of open-source licenses, I think this would prevent Qt from being used in such a project, no?
>

I really don't see what the problem is. If by some miracle we convince trolltech to write d bindings/a d port, anyone will be free to write software using that tech as long as they open source it. If you plan to make money, you have to pay a fee. That doesn't seem like a problem to me.

And I keep saying this "Let's present our dilemma to Scott Collins and ask him for an opinion". As far as I know, he is a GUI expert and will help open source ideas as well as licensing issues. D is a largely open source project. I just think that perhaps Walter should be the one to ask. I would do it, but that would be going over Walter's head.

>Sean

"nick" <nick_member@pathlink.com> wrote in message news:ds8v5t$12sr$1@digitaldaemon.com...
>
> I really don't see what the problem is. If by some miracle we convince
> trolltech
> to write d bindings/a d port, anyone will be free to write software using
> that
> tech as long as they open source it. If you plan to make money, you have
> to pay
> a fee. That doesn't seem like a problem to me.
>
> And I keep saying this "Let's present our dilemma to Scott Collins and ask
> him
> for an opinion". As far as I know, he is a GUI expert and will help open
> source
> ideas as well as licensing issues. D is a largely open source project. I
> just
> think that perhaps Walter should be the one to ask. I would do it, but
> that
> would be going over Walter's head.
>

I think that porting of such huge thing is not feasible at all at current
stage.
Automatic conversion is not possible especially in the light
of their own preprocessor for SINGNAL/SLOT code generation.
And benefits are doubtfull for small applications like notepad.exe
notepad.exe implementation in pure Win32 API is one file - not more.

If someone needs QT style UI/Application in D he can use
Harmonia even in its(her) current state.

Andrew.

nick wrote:
> In article <ds8tqr$11ti$1@digitaldaemon.com>, Sean Kelly says...
>> nick wrote:
>>> In article <ds8lvv$s2k$2@digitaldaemon.com>, Walter Bright says...
>>>> "nick" <nick_member@pathlink.com> wrote in message news:ds8f77$mvh$1@digitaldaemon.com...
>>>>> If I had to pick a toolkit to port right off the top of my head, I would choose QT.
>>>> QT cannot be used because it's a proprietary, non-free product. 
>>>>
>>> QT is an open source product. It is only proprietary if you plan to use it for
>>> proprietary means. KDE is based on QT from ground up.
>>>
>>> The very least we can do, is ask advice from Scott; he would gladly help an open
>>> source initiative.
>> The problem is that while the D libraries are open source, not all applications using D will be.  Given the viral nature of open-source licenses, I think this would prevent Qt from being used in such a project, no?
>>
> 
> I really don't see what the problem is. If by some miracle we convince trolltech
> to write d bindings/a d port, anyone will be free to write software using that
> tech as long as they open source it. If you plan to make money, you have to pay
> a fee. That doesn't seem like a problem to me.

So suppose Qt becomes the standard GUI interface through 1.0.  Joe decides to write an app using standard D tools and he doesn't want to open source it for whatever reason.  You're saying he would have to pay Trolltech a fee for doing so?  For using a standard library tool? Frankly, if someone tried to convince me to use a language whose standard library had such "hidden fees" I'd laugh at them.  The only alternative I'd consider is if the licensing fee could be built into the cost of the compiler or standard library distribution, and then only if the amount were eminently reasonable (say no more than $50).

> And I keep saying this "Let's present our dilemma to Scott Collins and ask him
> for an opinion". As far as I know, he is a GUI expert and will help open source
> ideas as well as licensing issues. D is a largely open source project. I just
> think that perhaps Walter should be the one to ask. I would do it, but that
> would be going over Walter's head.

You could phrase things in such a way so as not to assume any authority over the situation.  As long as it's clear you're not speaking for Walter I don't see any problem with asking.


Sean

"Sean Kelly" <sean@f4.ca> wrote in message news:ds8tqr$11ti$1@digitaldaemon.com...
> The problem is that while the D libraries are open source, not all applications using D will be.  Given the viral nature of open-source licenses, I think this would prevent Qt from being used in such a project, no?

That's right. A *standard* component of D needs to be usable by commercial projects without needing to pay license fees. That would be no problem if Qt were optional, but if it was standard it would impede the adoption of D.

"nick" <nick_member@pathlink.com> wrote in message news:ds8v5t$12sr$1@digitaldaemon.com...
> And I keep saying this "Let's present our dilemma to Scott Collins and ask
> him
> for an opinion". As far as I know, he is a GUI expert and will help open
> source
> ideas as well as licensing issues. D is a largely open source project. I
> just
> think that perhaps Walter should be the one to ask. I would do it, but
> that
> would be going over Walter's head.

Feel free to ask him. If he's willing to allow a Qt in D for open source, free commercial use, then that removes a fatal obstacle for making it a standard part of D.