On 2011-04-04 17:27:05 -0400, Matthias Pleh <jens@konrad.net> said:

> I would like to fill this gap and create a really good D GUI library
> 
> Any thoughts, comments ... ?

Just an observation...

Cross platform libraries are fine, but they generally aren't very great either. They'll always stretch in one way or another the standard way to do things when put on a given platform. The end result will almost always look substandard when using that library in the environment it was not primarily designed for.

On the other hand, one thing that is missing right now, in D and in most languages, is a standard way to display graphics. By that I mean if we had in Phobos a module that could just open a window and let you draw things in it, it'd make learning programming much more fun and it'd be useful for rapid prototyping of anything that involves graphics. It doesn't need to be complicated -- it doesn't even need to have a GUI -- just drawing things and viewing them somewhere on a screen would be great. Later on you can add click support, full screen mode and other features if deemed useful, but the goal would never be provide bindings for every piece of GUI on all platforms.

So my observation is that a cross platform full-featured GUI will always fail somewhere (mostly where those platforms differs) whereas a cross platform drawing module with display capabilities is much more universally useful, is more easily approachable, and is much less code to maintain.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Hello all,

"Matthias Pleh" <jens@konrad.net> wrote in message news:indhmm$3q4$1@digitalmars.com...
> Am 05.04.2011 00:14, schrieb Daniel Gibson:
>> Maybe your company could help the DWT or QtD guys?
>> Getting something stable out of that would most probably not take as
>> long as developing your own cross-platform GUI toolkit.
>> Furthermore many people are already familiar with SWT and Qt, so they
>> wouldn't have to learn another toolkit for D.
>
> You have missed the point. For our company the decision is made. We
> already use C++/Qt now.
> But I really like the D programming language and I use it for all my
> private projects. So I think, we, as the D community, should create a
> modern D GUI library entirely written in D.

Are you familiar with Tcl/Tk?  I am working on D bindings for them.  It is a lot less effort than reimplementing a whole GUI system!

Ned

Michel Fortin wrote:
> On the other hand, one thing that is missing right now, in D and in most languages, is a standard way to display graphics.

Actually, I wrote something to do that last year, but I thought it was too trivial to share.

What you do is just draw some RGB stuff to a big memory buffer. Then you can save as bmp, png, or create a window to display it.

There was no interaction with the window, except closing it. You'd pop up the window so the user can review the picture, then he closes it and your program continues where it left off.

Changing it to allow some updating and interaction shouldn't be too hard.

It worked for both win32 and x11, no libraries required.


The reason I wrote it was that I really miss the simplicity of DOS programming, where with just a few lines of inline asm, you have a dead-simple video buffer to play with.

On 04/05/2011 01:41 AM, Michel Fortin wrote:
> On 2011-04-04 17:27:05 -0400, Matthias Pleh <jens@konrad.net> said:
>
>> I would like to fill this gap and create a really good D GUI library
>>
>> Any thoughts, comments ... ?
>
> Just an observation...
>
> Cross platform libraries are fine, but they generally aren't very great either.
> They'll always stretch in one way or another the standard way to do things when
> put on a given platform. The end result will almost always look substandard
> when using that library in the environment it was not primarily designed for.
>
> On the other hand, one thing that is missing right now, in D and in most
> languages, is a standard way to display graphics. By that I mean if we had in
> Phobos a module that could just open a window and let you draw things in it,
> it'd make learning programming much more fun and it'd be useful for rapid
> prototyping of anything that involves graphics. It doesn't need to be
> complicated -- it doesn't even need to have a GUI -- just drawing things and
> viewing them somewhere on a screen would be great. Later on you can add click
> support, full screen mode and other features if deemed useful, but the goal
> would never be provide bindings for every piece of GUI on all platforms.
>
> So my observation is that a cross platform full-featured GUI will always fail
> somewhere (mostly where those platforms differs) whereas a cross platform
> drawing module with display capabilities is much more universally useful, is
> more easily approachable, and is much less code to maintain.

I would love that! Actually was thinking at something like that yesterday.

An ideal design (for me) for this kind of exploratory / fun programming would be having
* a drawing frame using most of the screen
* a minimal terminal frame down there (like in prog editors)
* a 'control' frame on the left
The control part beeing firstly for feedback on what happens in the drawing part. Eg display range, min/max, average... when drawing a function's curve.
Then, all kinds of sophiscation (control allows input, mouse, whatever...) can be added.

Unfortunately, I really have no idea on how to do that; else, I would have developped it already. But I would definitely help, if possible, anyone who knows and wants to invest time on such a project.

My uses for this would be similar to Michel's "make learning programming much more fun and it'd be useful for rapid prototyping". Especially around toy games / aspects of games / samples. Having no visualisation (read: the model w/o the view) is deeply frustrating and makes everything abstract (read: far harder).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 2011-04-04 19:55:44 -0400, Adam Ruppe <destructionator@gmail.com> said:

> Michel Fortin wrote:
>> On the other hand, one thing that is missing right now, in D and in
>> most languages, is a standard way to display graphics.
> 
> Actually, I wrote something to do that last year, but I thought
> it was too trivial to share.
> 
> What you do is just draw some RGB stuff to a big memory buffer. Then
> you can save as bmp, png, or create a window to display it.
> 
> There was no interaction with the window, except closing it. You'd
> pop up the window so the user can review the picture, then he closes
> it and your program continues where it left off.
> 
> Changing it to allow some updating and interaction shouldn't be
> too hard.
> 
> It worked for both win32 and x11, no libraries required.

Reminds me of David Simcha's plot2kill, which also has such a layer on top of which it implements plot drawing.
<http://www.dsource.org/projects/plot2kill>


> The reason I wrote it was that I really miss the simplicity of DOS
> programming, where with just a few lines of inline asm, you have
> a dead-simple video buffer to play with.

Indeed. Today you generally have to pile up a lot of GUI code just to be able to draw a square; all the simplicity is lost and portability is hard.

I think such a module would be a great addition to Phobos.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 2011-04-04 20:45:49 -0400, spir <denis.spir@gmail.com> said:

> I would love that! Actually was thinking at something like that yesterday.
> 
> An ideal design (for me) for this kind of exploratory / fun programming would be having
> * a drawing frame using most of the screen
> * a minimal terminal frame down there (like in prog editors)
> * a 'control' frame on the left
> The control part beeing firstly for feedback on what happens in the drawing part. Eg display range, min/max, average... when drawing a function's curve.
> Then, all kinds of sophiscation (control allows input, mouse, whatever...) can be added.

Actually, I think it needs to stay simple: provide a drawing area in a window and let the program draw whatever he wants. I'd leave controls and other GUI stuff to actual GUI frameworks (at least in a first incarnation).


> Unfortunately, I really have no idea on how to do that; else, I would have developped it already. But I would definitely help, if possible, anyone who knows and wants to invest time on such a project.

The first thing needed is an API. Ideally, the API would have the concept of an image buffer, some primitives to draw in the buffer, and a way to put the buffer on screen (typically in a window) or elsewhere (in a PNG file for instance).

It would also be nice to be able to load an image from a file, but that's a little more complicated.


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

"Daniel Gibson" <metalcaedes@gmail.com> wrote in message news:inddni$kmi$3@digitalmars.com...
>
> I don't know if wee need yet another GUI library.
> Are you sure Qt and DWT aren't good enough?
>

AIUI:

DWT doesn't support D2 (neither does wxD).

QtD requires a patched DMD, MinGW (which is fucking god-awful), and cmake (I have to let some variant of "make" touch my computer? Why can't we just let make die?). And it requires running your code through a preprocessor.

And none of those have actual API documentation, they just refer to the C/C++ docs. I use D because I never want to look at another line of C++ as long as I live.

Everything else is either non-native or non-cross-platform.

The state of GUIs in D right now is pretty awful, unfortunately. My plate's already overpacked (think: teenager at a one-trip buffet), but maybe I'll see if I can squeeze in enough extra time (hah! there's a concept I've completely lost all memory of) to try to help out on something. After all, I *really* want to get around to making my own web browser (based off either Mozilla or Chromium) - I'm getting really fed up with the current state of available web browsers. Well, and the web as a whole (god I fucking hate the web), but one step at a time, I guess).

"Michel Fortin" <michel.fortin@michelf.com> wrote in message news:indr8m$qfc$1@digitalmars.com...
> On 2011-04-04 19:55:44 -0400, Adam Ruppe <destructionator@gmail.com> said:
>
>> The reason I wrote it was that I really miss the simplicity of DOS programming, where with just a few lines of inline asm, you have a dead-simple video buffer to play with.
>
> Indeed. Today you generally have to pile up a lot of GUI code just to be able to draw a square; all the simplicity is lost and portability is hard.
>

Even with SDL's D bindings?

On 2011-04-04 21:46:08 -0400, "Nick Sabalausky" <a@a.a> said:

> "Michel Fortin" <michel.fortin@michelf.com> wrote in message
> news:indr8m$qfc$1@digitalmars.com...
>> On 2011-04-04 19:55:44 -0400, Adam Ruppe <destructionator@gmail.com> said:
>> 
>>> The reason I wrote it was that I really miss the simplicity of DOS
>>> programming, where with just a few lines of inline asm, you have
>>> a dead-simple video buffer to play with.
>> 
>> Indeed. Today you generally have to pile up a lot of GUI code just to be
>> able to draw a square; all the simplicity is lost and portability is hard.
> 
> Even with SDL's D bindings?

Don't know. What is the minimal code you have to write to open a window and draw a square with SDL?

Also, you have to download the library and link to it and keep the dynamic library around with the compiled program, which is some more hassle.

But you're right that SDL comes pretty close.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

"Michel Fortin" <michel.fortin@michelf.com> wrote in message news:indtda$trl$1@digitalmars.com...
> On 2011-04-04 21:46:08 -0400, "Nick Sabalausky" <a@a.a> said:
>
>> "Michel Fortin" <michel.fortin@michelf.com> wrote in message news:indr8m$qfc$1@digitalmars.com...
>>> On 2011-04-04 19:55:44 -0400, Adam Ruppe <destructionator@gmail.com> said:
>>>
>>>> The reason I wrote it was that I really miss the simplicity of DOS programming, where with just a few lines of inline asm, you have a dead-simple video buffer to play with.
>>>
>>> Indeed. Today you generally have to pile up a lot of GUI code just to be able to draw a square; all the simplicity is lost and portability is hard.
>>
>> Even with SDL's D bindings?
>
> Don't know. What is the minimal code you have to write to open a window and draw a square with SDL?
>

I'm not really sure. I've been sinking in the web-dev quicksand/firepits so long I've never really had a chance to actually use SDL in D, and I don't remember any of SDL's API.

> Also, you have to download the library and link to it and keep the dynamic library around with the compiled program, which is some more hassle.
>
> But you're right that SDL comes pretty close.
>