On Friday, 16 August 2013 at 07:19:09 UTC, Marek Janukowicz wrote:
> If we are discussing X's shortcomings: why don't we use something like http://wayland.freedesktop.org/

I don't have it installed on my computer! I do have X though.

BTW, my minigui.d (previously crappygui.d) is moving along at a decent pace. Now has menus too, yay! I decided to use native widgets on Windows after all, when applicable. It looks better and automatically handles focus, hotkeys, etc. It still uses a simple automatic layout function though, so you just add children to the window and it figures out the sizes.

On X though, I'm still doing it all myself, keeping it small (and fast on remote X! lol). So far, the minigui.d is 1100 lines long. I think I can do everything I want to do in between 2000 and 3000 lines. The test program on windows is 370 KB, no outside dependencies built with dmd, and the only modules it needs are my simpledisplay.d and color.d, though I might have it depend on eventloop later too. (It is about the same size using custom widgets too; calls to Rectangle() and LineTo(), via simpledisplay.d's ScreenPainter, aren't significantly bigger than calls to CreateWindow()).


Anyway though, I'll probably post this to my github at some point over the weekend. There isn't much to it.... but IMO that's the best feature. The other D gui libs I've tried are all just too complex for me.

On Thursday, 15 August 2013 at 20:09:34 UTC, Jonas Drewsen wrote:
> * SDL for input - would be awesome to get rid of this by using some of AdamRuppes work maybe.

heh, I'm *almost* to the point where I can replace SDL for  my own little games. I ported stb_truetype.h to D earlier in the week, I have some joystick input code and sound output code laying around, and once simpledisplay.d gets OpenGL context creation (probably tomorrow), that'll be almost everything I use there!

Anyway though, as I write my minigui.d, I'm finally finishing simpledisplay.d's input events. (Previously, I only used that module as a quick image display thing, and the only events I was really interested in was basic click and key presses, 'a', 's', pressed, etc. But now I'm trying to write a little Text Edit control, so it needs a lot more detail.)

Anyway, I'm fixing a lot of input bugs this weekend, so if you want to give simpledisplay.d a try next week, it might be useful to you then.

On Friday, 16 August 2013 at 13:56:20 UTC, Adam D. Ruppe wrote:
> On Thursday, 15 August 2013 at 20:09:34 UTC, Jonas Drewsen wrote:
>> * SDL for input - would be awesome to get rid of this by using some of AdamRuppes work maybe.
>
> heh, I'm *almost* to the point where I can replace SDL for  my own little games. I ported stb_truetype.h to D earlier in the week, I have some joystick input code and sound output code laying around, and once simpledisplay.d gets OpenGL context creation (probably tomorrow), that'll be almost everything I use there!
>
> Anyway though, as I write my minigui.d, I'm finally finishing simpledisplay.d's input events. (Previously, I only used that module as a quick image display thing, and the only events I was really interested in was basic click and key presses, 'a', 's', pressed, etc. But now I'm trying to write a little Text Edit control, so it needs a lot more detail.)
>
> Anyway, I'm fixing a lot of input bugs this weekend, so if you want to give simpledisplay.d a try next week, it might be useful to you then.

Awesome... looking forward to have a look at it.

/Jonas

On Friday, 16 August 2013 at 12:36:39 UTC, Wyatt wrote:
> On Thursday, 15 August 2013 at 18:35:22 UTC, Joakim wrote:
>>
>> I've only done X11 forwarding over ssh, both WAN and LAN, it was incredibly laggy in both cases.
>>
> As Andrei and I have pointed out, NX does a much better job of things.  If nothing else, read the explanation of how it works-- there are perceptual subtleties to this that aren't apparent at first glance:
> http://www.nomachine.com/documents/NX-XProtocolCompression.php

I don't much care if X11 can be made faster.  Unless you plan on bundling an X server with your Windows app, it's not an option for a cross-platform GUI.

In any case, if X11 is in fact similar to the approach I laid out, I obviously think that approach can be done speedily, though X11 probably bites off too much whereas I carefully constrained the problem for my Crack client.

I suggest to first find out what we really want (and therefore who "we" is).

It seems to me that there are basically 3 groups:

- looking for some kind of GUI-kit that is less massive than gtk, qt, etc. and runs pretty everywhere.
  Need addressed: Well, sometimes a GUI is needed. A no frills basic thingy will do; most importantly it must run everywhere and more or less feel like the native GUI.
  One approach: D'ize Fox

- Looking for sophisticated GUI, possibly mainly for games, video etc.
  Need addressed: Graphics intense applications. Speed is important.

- Add a GUI toolkit to D
  Need addressed: D should have a GUI toolkit anyway. Why not create a major one and do it a) the D way and b) properly, possibly attracting more users to D?


Some remarks in no special order:

- Doing something HTML (ideally 5) based looks very attractive and cross plattform. It brings with it, however, either the need for a built in http server and the interface app/server - or - an HTML component which again needed  obe based on some GUI kit.

- Whatever we come up with should use native controls where existing and otherwise simulate them using other more basic native controls.
This sounds ugly, can, however, actually be a major chance and interesting approach.

- Simply creating yet another GTK or QT is unattractive - they already exist and so do bindings to D (if I'm not mistaken. Otherwise those bindings can be created)

- We should avoid some errors made by others and prepare for environmental changes (like X possibly being replace by wayland).

In summary I'd consider to create
- something new (rather than creating a, say, fox binding)
- that starts simple, already addressing many needs
- is designed in a way as to allow for some unobtrusive http binding (meaning: usually it runs by itself but it *can* - without breaking ones arm - also work through http)
- is based on a clearly defined set of basic widgets that are commonly available in all major targets (X, Windows, mac, possibly android, etc)
- is designed in a modular way so as to provide a) a basic GUI kit and b) - optionally - extensions or a "large" kit version. Reasoning: in 80% of cases a gui is needed simply as a gui interface for whatever programm. Sometimes, though, more is needed like e.g. a video widget.
This a) eases design and development and b) is attractive because pretty every existing solution is either smallish (often too small) or a monster (often way to big)
- could, in the long run, offer an HTML component so as to make HTML targets self hosting yet keep the http option open for new operating systems.

My first target would be something like "designing a new 'fox' fully using D's superior capabilities and doing that along the lines I listed above".

In other words: Let's scratch some itching that is a) common and b) not yet properly addressed by what is available.

regards - Ramon

On 8/19/2013 5:01 PM, Ramon wrote:
> I suggest to first find out what we really want (and therefore who "we"
> is).

...

> My first target would be something like "designing a new 'fox' fully using D's superior capabilities and doing that along the lines I listed above".
> 
> In other words: Let's scratch some itching that is a) common and b) not yet properly addressed by what is available.

IMO, a useful start would be choosing a moderately real-life use case and stepping through imaginary code or markup that would be required for it to work using each proposed approach (including data binding, event handling and so on).

On 2013-08-19 23:01, Ramon wrote:

> - Whatever we come up with should use native controls where existing and
> otherwise simulate them using other more basic native controls.
> This sounds ugly, can, however, actually be a major chance and
> interesting approach.

If native controls are used then the first step is make sure we have proper and easy to use bindings to these. For example, it's a PITA to access Objective-C frameworks (needed for Mac OS X) form D. So we need this:

http://michelf.ca/projects/d-objc/syntax/

Most up to date code: https://github.com/jacob-carlborg/dmd/tree/d-objc

-- 
/Jacob Carlborg

On Friday, 16 August 2013 at 22:22:06 UTC, Jonas Drewsen wrote:
> Awesome... looking forward to have a look at it.

I pushed the changes to my github today. Still a few little changes I want to make, but nothing major. (for example, the input enum is based on my US keyboard, so it doesn't have entries for other keys. But that's generally additive so should be be major breakage.)

https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff

simpledisplay.d and color.d are the two you'll need.


To make an OpenGL window:


        import simpledisplay;
        auto win = new SimpleWindow(Size(400, 400), "GL Test", OpenGlOptions.yes);

     // this uses a delegate so it can be automatically called when the window is uncovered
        win.redrawOpenGlScene = {
               glBegin(GL_QUADS);
               // blah blah blah
               glEnd();
        }

        win.redrawOpenGlSceneNow();
        win.eventLoop(0);


I'm not completely happy with this and might change some things, but the meat is there now. simpledisplay.d includes some opengl function definitions, but not all of them.

On Windows, you need to explicitly add -version=with_opengl and get your own opengl32.lib and glu32.lib since they don't come with dmd yet. (I wish Walter would reply to that thread!)

On Monday, 19 August 2013 at 21:01:49 UTC, Ramon wrote:
> - looking for some kind of GUI-kit that is less massive than gtk, qt, etc. and runs pretty everywhere.

I'm now working on a minigui.d and pushed a very incomplete start to my github:

https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/minigui.d

Also depends on simpledisplay.d and color.d from the same repo. There's still a *lot* I have to finish and change in there, but you can see my basic direction:

1) somewhat thinly wrap Win32 controls, then DIY to similar functionality on X for cross platformness. If you add a manifest resource/file, this uses the theming api too, so on WinXP it looks like an XP app, on Vista it looks like vista, etc.

2) Minimal dependencies, I'm not even using Phobos in here. The result: my test program is a 205 KB exe on Windows, with no dlls needed at runtime (except those that come with Windows), and you can compile it with just my three files, no need for special instructions to build the library, just add them to your dmd command line. (I'm even considering merging it into two files.)

3) The event model is kinda like javascript and the widget layout is a simple stretchy thing based on max/min width/height and a stretchiness factor.

4) Drawing is possible through simpledisplay.d's ScreenPainter or Open GL functions.


I'm about halfway to where I want to be with this now. After making the Windows impl good and the X impl barely working, I'll go back and see about making the X one slightly prettier and better functioning, but my emphasis is still on small size so don't expect too much. (One option would be to do GTK similarly like Windows as an option for nicer X version.)

Then if I still have time, I'll look at my would be nice list: a text mode alternative backend, a html5 thingy, and my plans for network transparency and detaching as discussed earlier in the thread.

But for now, I'm aiming low.

Front up:

As it seems nobody heftily disagrees with my groupings. While I
myself am (as probably many others) in the 1 & 3 camp (looking
for some kind of GUI-kit that is less massive than gtk, qt, etc.
and runs pretty everywhere. - and - Add a GUI toolkit to D) I
took note that there is also a not insignicant need from the 2
group (Looking for sophisticated GUI, possibly mainly for games,
video
etc.).

If I'm not badly mistaken, the 2 groups needs will basically
need/could be addressed by OpenGL. *Please, correct me, if I'm
fundamentally wrong!*


On Tuesday, 20 August 2013 at 01:28:10 UTC, Gambler wrote:
> IMO, a useful start would be choosing a moderately real-life use case
> and stepping through imaginary code or markup that would be required for
> it to work using each proposed approach (including data binding, event
> handling and so on).

Well, yes and no. Actually I think that pretty everyone here
(i.e. people who have a gui need of whatever detail sort) does
have a pretty clear picture of "reasonable basics". Let me name
it:

- Windows (surprise! *g)
- Menus
- the "standard" controls (text boxes, lists, combos, ...)
- font handling
- supporting well established mechanisms like DragnDrop
- and - importantly - a design that allows for creation of more
complex widgets (like spreedsheats) using the basic ones.

On Tuesday, 20 August 2013 at 07:15:38 UTC, Jacob Carlborg wrote:
> On 2013-08-19 23:01, Ramon wrote:
>
>> - Whatever we come up with should use native controls where existing and
>> otherwise simulate them using other more basic native controls.
>> This sounds ugly, can, however, actually be a major chance and
>> interesting approach.
>
> If native controls are used then the first step is make sure we have proper and easy to use bindings to these. For example, it's a PITA to access Objective-C frameworks (needed for Mac OS X) form D. So we need this:

Thanks a lot! Important point.
While there has not yet been defined a list of targets I
assume,pretty everybody can agree on "Win/X11/Mac" and possibly
Android (?) with the letter as well as other more exotic targets
being more of a "we had it in mind and ried har to not block the
road, did however not build it for the time being" kind, right?

Which brings up another important point:

Of course, it's seductive to "just get something working". At the
same time though I suspect this attitude to be a major factor for
GUI kits not having been finished or having been condemned to
insignificance.

I'd strongly suggest to not too quickly go to the "let's hack it"
phase but rather to properly develop a design that is sound,
allows for future changes and improvements (wayland, iphone, ...).

That's true for languages, DBs and other stuff, too. The good and
widely accepted ones have a clear "philosophy" and design behind
them, the insigificant or bad ones don't.
Sure, a programmers, we prefer coding but frankly, as *mature*
developers we know about the importance of thinking, discussing
and pondering before approaching the keyboard, don't we?


@Adam D. Ruppe

Thank you. I think those "etudes" can be very helpful. I suggest,
however, no matter how attractive it might be, to *not* just grab
something and hack on it but (sorry for repeating myself) to
think well and profoundly about important criteria and a
"philosophy" and only then begin to develop a sound design
(before we start to hack the beast).

One seemingly paradoxical reasoning behind my point of view is
that we (well, most of us anyway) are not in the gui and graphics
business but merely developers who need a major itching
scratched, preferably once and for all.

Thinking properly about it we will, if, say, a major new OS
target or windowing system comes up, be able to quite quickly
port our gui and be done with it.

Another issue that we might underestimate are colleagues using
completely different languages, say, Python. Shouldn't they - and
wouldn't they love to - have a chance to grok/bind our D gui into
their language, too? And wouldn't that be a major and quite
convincing advertisement for D?

Thanks everyone for your patience with my long posts - Ramon