www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Ideas for a brand new widget toolkit

reply "Paul Z. Barsan" <paulmegabyte gmail.com> writes:
Hello everyone,

These days I've been searching for a cross-platform IDE for D and 
I found out that there aren't any viable standalone options. 
After a few clicks, I've ran over this topic: 
http://forum.dlang.org/thread/astrlgbptrlvcdicqxux forum.dlang.org 
and it wasn't a surprise to see there are other people searching 
for the very same thing.One of the reasons for the absence of 
such IDEs is that there are no widget toolkits written in D 
except DWT, but some people are complaining about DWT for being a 
clone of SWT and that clients will want DWT to be in sync with 
SWT since SWT is a "marketing paradigm". As such, I want to 
embark on a long journey of writing a new widget toolkit from 
scratch.

Here are the ideas that people came up with so far(sorry if I 
omitted something):

evilrat:
* we need a truly D UI(not wrapper) first
* there are almost no declarative cross platform(i mean major OS) 
toolkit for writing simple yet highly customizable UI's, with 
HTML markup-like,
customizable UI's without messing with 
imperative(C/C++/D/whatever) code

eles:
* a D-ported version of a rather anonymous toolkit won't be 
shaded by the original
* evolution is slower, so not a fast-moving target
* the team behind that toolkit will be more than glad to help, as 
their toolkit will gain in popularity, and could even be 
converted to D-development (instead of C or C++ or whatever)
* re-write FOX tk in D, not to bind to it
* drivers as the lower bound in my original post. The rest should 
be drawn...

Trvhgoy:
* define the layout with a markup language like XAML or XUL for 
example and the styling with a CSS-like definition.

Mike Parker:
* Harmonia might be a good place to start: 
http://harmonia.terrainformatica.com/doku.php

Chris:
* a UI tool like Glade or Interface Builder is indispensible

Jacob Carlborg:
* You would still need to some graphics primitives. Do you want 
to implement them yourself as well? I mean, you have to draw the 
line somewhere. There's always a layer beneath you that you rely 
on, if you're not doing embedded or similar.
* you want a non-native toolkit.
* primitives would be implemented on top of OpenGL or DirectX. 
OpenGL is implemented in the graphics drivers, don't know how it 
works with DirectX.

Now let me complete these notes:

* I think that porting an anonymous toolkit to D will do more 
harm than good because if the original project was lacking some 
features then clients will think that the ported version lacks 
them as well. If we want to take this route then, besides 
Harmonia and FOX tk, we might borrow things from FLTK(Fast Light 
Toolkit)
* If the projects starts from zero, with its own design and is 
"shiny new" then people will be more attracted.
* Even if we don't port a toolkit we can still get inspired to 
see how they interact with the underlying system. For example, we 
can take a look over the SDL way of handling input.
* for drawing primitives we can use Cairo(curently used by GTK) 
or libX11 on linux and Directx on windows.Bindings for cairo and 
libX11 are provided by Deimos. I'm not sure if we can use OpenGL 
because it requires a rendering window or it renders in 
fullscreen mode.That rendering window can be provided by other 
toolkits but I don't think we want to depend on them. The OS 
window manager(xorg on linux) needs to keep track of the things 
it draws on its root window or surface and must be aware what to 
clean-up after you close your program. So the layer beneath this 
widget toolkit on Linux would be X(libX11).
* XAML is being developed by Microsoft and XUL by Mozzilla. I 
think XUL is a better choice for a markup language and more 
friendlier with an open source toolkit. It would be pretty nice 
if we can make the GuiParser and abstract class and provide an 
implementation for XUL because that will allow us to write an 
implementation for the QML(Qt) aswell or other flavors of layout 
and style files.
* If we want the project to scale up nicely then we should do 
things by the book. That is doing some research to see what 
technologies are involved, what the client programmers want(this 
thread) and then write some specs.
* After we have the specs then we can start designing the toolkit 
using UML diagrams such that we will end up with a clean API and 
avoid future re-factoring. For UML designs, I recommend this web 
app https://www.draw.io/ which saves its files in XML format and 
we can store them in the git repository.
* Only after we have a good design we will begin the actual 
coding.
* there is this 3D modelling tool called Blender which has a 
modern-looking UI. People have been wondering if that GUI can be 
used as a library and the answer is no because the gui is 
harcoded into Blender. If our default ui look resembles that 
one(not necessarily identical) then we will gain more 
clients.Maybe we can even get support from its huge community of 
artists. Take a look: 
http://www.blender.org/features-gallery/features/
* this toolkit can complement DWT because DWT will provide native 
look and this one will provide the same look on all platforms.

In the previously mentioned forum thread, I've seen that there 
are other developers willing to contribute to a new widget 
toolkit project.I haven't hosted the project yet because I'm 
undecided what hosting service should I use. AFAIK, sourceforge 
is for projects and it gives you the option of hosting a website, 
using other bugtrackers such as Trac and github is focused more 
on the code. So where do you think a project of this magnitude 
should be hosted ?

Think of this topic as writing letters to Santa, so: what say you 
?
Aug 13 2013
next sibling parent reply Tobias Pankrath <lists pankrath.net> writes:
On 08/13/2013 03:23 PM, Paul Z. Barsan wrote:

 Think of this topic as writing letters to Santa, so: what say you ?
I'd bet on QtD.
Aug 13 2013
parent reply "Paul Z. Barsan" <paulmegabyte gmail.com> writes:
On Tuesday, 13 August 2013 at 13:32:04 UTC, Tobias Pankrath wrote:
 I'd bet on QtD.
QtD provides language bindings just like GtkD or wxD. Qt as a framework is a mammoth. It provides support for networking, threads and even has wrappers for basic types such as QString. Phobos already provides support for this sort of things. Besides that, there are widget toolkits written in all major programming languages: GTK+ in C, Qt in C++, Swing in Java and so on. Another gui toolkit will bring more users to D itself. On Tuesday, 13 August 2013 at 13:51:40 UTC, John Colvin wrote:
 http://pages.github.com/ perhaps?
I didn't know of this github feature. I only used sourceforge and bitbucket before. Another option was dsource but it seems to me like a sinking boat and its user are moving their projects to github. Thanks for the tip !
Aug 13 2013
next sibling parent reply Tobias Pankrath <lists pankrath.net> writes:
On 08/13/2013 04:10 PM, Paul Z. Barsan wrote:
     QtD provides language bindings just like GtkD or wxD. Qt as a
 framework is a mammoth. It provides support for networking, threads and
 even has wrappers for basic types such as QString. Phobos already
 provides support for this sort of things.
So additionally to a GUI Toolkit we get a framework full of useful things, that many C++ programmer already know. I'll take that as an argument pro QtD.
     Besides that, there are widget toolkits written in all major
 programming languages: GTK+ in C, Qt in C++, Swing in Java and so on.
Nope. GTK+, Qt and Swing all have a over hundred man years advantage over yet-another-gui-toolkit. Programmer who want to build a non trivially gui, will just take a language that has a comparable solution to these three. That will not be D.
 Another gui toolkit will bring more users to D itself.
Good bindings to an existant GUI toolkit will bring users to D. No one really cares, which language it's originally written in. See Python/Ruby.
Aug 13 2013
parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 13 August 2013 at 14:22:09 UTC, Tobias Pankrath wrote:
 So additionally to a GUI Toolkit we get a framework full of 
 useful things
Useful for C++. Sometimes. Actually, that was a reason to prefer GTK over Qt for me even in C++ times. No way I'll ever use this monster in D.
Aug 13 2013
prev sibling parent "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Tuesday, 13 August 2013 at 14:10:24 UTC, Paul Z. Barsan wrote:
 On Tuesday, 13 August 2013 at 13:32:04 UTC, Tobias Pankrath 
 wrote:
 I'd bet on QtD.
QtD provides language bindings just like GtkD or wxD. Qt as a framework is a mammoth. It provides support for networking, threads and even has wrappers for basic types such as QString. Phobos already provides support for this sort of things.
clip Qt is modular. I would assume a qtD would only need to support QtCore and QtGui (those are pretty big though), but you still shouldn't need to support all of the Qt Framework (XML, Networking, QtConcurrent, etc.). Craig
Aug 13 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 13 August 2013 at 13:23:07 UTC, Paul Z. Barsan wrote:
 I haven't hosted the project yet because I'm undecided what 
 hosting service should I use. AFAIK, sourceforge is for 
 projects and it gives you the option of hosting a website, 
 using other bugtrackers such as Trac and github is focused more 
 on the code. So where do you think a project of this magnitude 
 should be hosted ?
http://pages.github.com/ perhaps?
Aug 13 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
Coincidentally, I started slapping one together over the weekend.

As you can see, it is hideous:
http://arsdnet.net/gui.png

And if I saw someone else coding a gui the way I am, I'd call 
them silly for rejecting all things that are good and decent.

So, what am I doing and why am I doing it that way?

Let's start with the why:

Qt and GTK are just too big, and other lightweight wrappers still 
tend to have runtime requirements that i hate. I want to be able 
to distribute a stand-alone exe that people can use that is < 1 
MB, so there's a reasonable download time from my slow computer.

The qtd and gtkd wrappers make them even bigger and more fragile. 
The D forms library is ok, still a bit big and buggy when I 
tried, but the real blocker there is zero linux support.

So I'm doing just win32 and xlib, built on my simpledisplay.d 
that already provides basics. Since xlib doesn't provide any 
widgets, I'm diying there. (But might change my mind later and 
dynamically link gtk, idk, the linux version will probably only 
be used by myself so it isn't that important.)

My goal: provide very basic, but useful, capabilities in one D 
module.



What exactly am I doing? Just drawing rectangles and reading 
events (simpledisplay.d supports these, and I'm improving it as 
needed for this) and calling it a gui!


I don't my approach of from scratch, custom widgets is a good 
idea in most cases.
Aug 13 2013
prev sibling next sibling parent dennis luehring <dl.soluz gmx.net> writes:
Am 13.08.2013 15:23, schrieb Paul Z. Barsan:
 Think of this topic as writing letters to Santa, so: what say you
sorry your list is much to big - feels like the next Doom 5 128 Bit with hypergigagraphics... your talking about serveral years of development - and yes - there are many developers that want a new great gui blabla thing - but don't want to invest time to produce it - want != personal invest just look at the design and code of Qt and you will see that is much much more needed then just nice ideas (and even if D will help to keep out strange looking codestuff, macros etc - you will still neede much of the surounding code btw: you should not start to design a new gui system without deep knowledge of the currently used ones (like GtK, Qt, ... XUL, XAML,...)
Aug 13 2013
prev sibling next sibling parent "Suliman" <evermind live.ru> writes:
Start else another GUI toolkit it's bad idea, we already have 
about 5-6 GUI toolkit's that's done only on half. Much better to 
take any of existent, for example http://code.google.com/p/dgui/ 
and continue of it's developing
Aug 13 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-08-13 15:23, Paul Z. Barsan wrote:
 Hello everyone,
Oh, another one of these threads...
 These days I've been searching for a cross-platform IDE for D and I
 found out that there aren't any viable standalone options. After a few
 clicks, I've ran over this topic:
 http://forum.dlang.org/thread/astrlgbptrlvcdicqxux forum.dlang.org and
 it wasn't a surprise to see there are other people searching for the
 very same thing.One of the reasons for the absence of such IDEs is that
 there are no widget toolkits written in D except DWT, but some people
 are complaining about DWT for being a clone of SWT and that clients will
 want DWT to be in sync with SWT since SWT is a "marketing paradigm". As
 such, I want to embark on a long journey of writing a new widget toolkit
 from scratch.

 Jacob Carlborg:
 * You would still need to some graphics primitives. Do you want to
 implement them yourself as well? I mean, you have to draw the line
 somewhere. There's always a layer beneath you that you rely on, if
 you're not doing embedded or similar.
 * you want a non-native toolkit.
 * primitives would be implemented on top of OpenGL or DirectX. OpenGL is
 implemented in the graphics drivers, don't know how it works with DirectX.
This is very out of context and not what I think, I just responded to a post.
 Think of this topic as writing letters to Santa, so: what say you ?
All I can say that creating a new toolkit from scratch is a huge amount of work. -- /Jacob Carlborg
Aug 13 2013
prev sibling next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Tuesday, 13 August 2013 at 13:23:07 UTC, Paul Z. Barsan wrote:
 Think of this topic as writing letters to Santa, so: what say 
 you ?
Aww, you've gone and reminded me of Hybrid [1] again. D1/Tango IIRC, but I think it had good potential. No lazy updates, though, so probably not as useful for ordinary desktop applications. ...I wonder if Tomasz will ever come back? -Wyatt [1] http://h3.gd/code/hybrid/wiki/
Aug 13 2013
prev sibling next sibling parent captaindet <2krnk gmx.net> writes:
On 2013-08-13 08:23, Paul Z. Barsan wrote:
 Now let me complete these notes:

 * I think that porting an anonymous toolkit to D will do more harm
 than good because if the original project was lacking some features
 then clients will think that the ported version lacks them as well.
 If we want to take this route then, besides Harmonia and FOX tk, we
 might borrow things from FLTK(Fast Light Toolkit) * If the projects
 starts from zero, with its own design and is "shiny new" then people
 will be more attracted. * Even if we don't port a toolkit we can
 still get inspired to see how they interact with the underlying
 system. For example, we can take a look over the SDL way of handling
 input. * for drawing primitives we can use Cairo(curently used by
 GTK) or libX11 on linux and Directx on windows.Bindings for cairo and
 libX11 are provided by Deimos. I'm not sure if we can use OpenGL
 because it requires a rendering window or it renders in fullscreen
 mode.That rendering window can be provided by other toolkits but I
 don't think we want to depend on them. The OS window manager(xorg on
 linux) needs to keep track of the things it draws on its root window
 or surface and must be aware what to clean-up after you close your
 program. So the layer beneath this widget toolkit on Linux would be
 X(libX11). * XAML is being developed by Microsoft and XUL by
 Mozzilla. I think XUL is a better choice for a markup language and
 more friendlier with an open source toolkit. It would be pretty nice
 if we can make the GuiParser and abstract class and provide an
 implementation for XUL because that will allow us to write an
 implementation for the QML(Qt) aswell or other flavors of layout and
 style files. * If we want the project to scale up nicely then we
 should do things by the book. That is doing some research to see what
 technologies are involved, what the client programmers want(this
 thread) and then write some specs. * After we have the specs then we
 can start designing the toolkit using UML diagrams such that we will
 end up with a clean API and avoid future re-factoring. For UML
 designs, I recommend this web app https://www.draw.io/ which saves
 its files in XML format and we can store them in the git repository.
 * Only after we have a good design we will begin the actual coding. *
 there is this 3D modelling tool called Blender which has a
 modern-looking UI. People have been wondering if that GUI can be used
 as a library and the answer is no because the gui is harcoded into
 Blender. If our default ui look resembles that one(not necessarily
 identical) then we will gain more clients.Maybe we can even get
 support from its huge community of artists. Take a look:
 http://www.blender.org/features-gallery/features/ * this toolkit can
 complement DWT because DWT will provide native look and this one will
 provide the same look on all platforms.
i like your ideas, especially the the clear top-down strategy. if the vision, i.e. design/API and roadmap is clear, and the documentation is good from the very beginning (something i want to stress particularly), then it could develop some dynamic. to ppl shrugging it off with the arguments that it is too much work or has been tried before: well, these arguments cancel each other out. previous projects have been very promising and accomplished a lot, enough for a kickstart. in theory - as it did not happen. and why? i think their biggest problem was that they were basically one man projects, not community projects. they did not outline design goals, open issues, roadmaps, - heck they did not even provide a sufficient documentation for using them. so they more or less died once the original maintainer lost interest. i often think what nice a D GUI package we would have by now if those 3 or 4 ppl running the previous attempts would have worked together. i played a bit with DFL some years ago and was quite impressed (it even had a GUI designer!) - but only to a certain point. i wanted multi platform and being only the occasional programmer, i need a good, detailed documentation. so back than i decided to not use D altogether as a GUI was a must for my application. (the core procedures being in C i still hope to move it to D at one point though) having a D-simple and D-safe pure D GUI is worth a try and would boost D's popularity. if it takes 2 years before it is usable, so what. it would not slow down improving D in other aspects as i think a GUI development would motivate a different set of ppl to contribute, i.e. would not withdraw current phobos and compiler devs. just my 2c, det
Aug 13 2013
prev sibling next sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
The problem is that the scale of a project like this literally 
stops people from starting. Couple this with the fact that a non 
existent project doesn't attract any developers and you've got 
negative feelings from the start.

I wouldn't worry about that though!

I think the benefits of a project like this far outweigh any 
initial worries about scale. Personally, i would love for there 
to be a D GUI toolkit that is available for all D supported 
platforms. It would be awesome being able to create D GUI 
applications in a straight forward way and something which i 
truly think would attract many more developers to D. IMHO It's 
one of the two big attractors* to using any language, i.e. an 

Python caught on as quickly as they did.

If work is started on a project like this and shows promise, i 
wouldn't be adverse to contributing.

Keep this quote in mind:

"Nobody should start to undertake a large project. You start with 
a small trivial project, and you should never expect it to get 
large. If you do, you'll just overdesign and generally think it 
is more important than it likely is at that stage. Or worse, you 
might be scared away by the sheer size of the work you envision. 
So start small, and think about the details. Don't think about 
some big picture and fancy design. If it doesn't solve some 
fairly immediate need, it's almost certainly over-designed. And 
don't expect people to jump in and help you. That's not how these 
things work. You need to get something half-way useful first, and 
then others will say "hey, that almost works for me", and they'll 
get involved in the project."

Linus Torvalds - Linux Times (2004-10-25)
http://web.archive.org/web/20050404020308/http://www.linuxtimes.net/modules.php?name=News&file=article&sid=145

SO who will be the first to start? ;)

* The other is games programming capability but we'll leave 
discussing building a full opengl games programming framework for 
another thread. ;)
Aug 13 2013
next sibling parent reply "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Tuesday, 13 August 2013 at 17:40:05 UTC, Gary Willoughby wrote:
clip
 I think the benefits of a project like this far outweigh any 
 initial worries about scale. Personally, i would love for there 
 to be a D GUI toolkit that is available for all D supported 
 platforms. It would be awesome being able to create D GUI 
 applications in a straight forward way and something which i 
 truly think would attract many more developers to D. IMHO It's 
 one of the two big attractors* to using any language, i.e. an 

 Python caught on as quickly as they did.
clip What is the Python GUI toolkit you speak of?
Aug 13 2013
parent reply "Gary Willoughby" <dev nomad.so> writes:
On Tuesday, 13 August 2013 at 17:49:21 UTC, Craig Dillabaugh 
wrote:
 What is the Python GUI toolkit you speak of?
As Russel alluded to it was Tkinter i was referring to. It has been bundled with Python for years (since the beginning?) and it's one of the first GUI toolkits i used years ago. It's very very basic but it's ideal for fast prototypes and just for putting something on a window. I have seen people use it for simple editors to scientific work for plotting data, etc. It's not how awesome it was but how easy it was to use and get results. http://wiki.python.org/moin/TkInter
Aug 13 2013
parent reply "Gary Willoughby" <dev nomad.so> writes:
On Tuesday, 13 August 2013 at 18:11:11 UTC, Gary Willoughby wrote:
 I have seen people use it for simple editors to scientific work 
 for plotting data, etc. It's not how awesome it was but how 
 easy it was to use and get results.
e.g. Here's a small open source project i created 12+ years ago to provide a UI for another small project all using Tkinter: http://nathrach.republicofnewhome.org/mappergui.html It was ridiculously easy to use and if it hadn't been so i probably wouldn't of even tried Python. I was into my RPG games and wanted maps! :) (btw the code is horrible so don't bother looking. he he..)
Aug 13 2013
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 8/13/13, Gary Willoughby <dev nomad.so> wrote:
 e.g. Here's a small open source project i created 12+ years ago
 to provide a UI for another small project all using Tkinter:

 http://nathrach.republicofnewhome.org/mappergui.html
Small note: I'm working on an updated D wrapper around Tk v8.6. There was a project like this called Dkinter, but it got abandoned 5 years ago (and was largely incomplete), so I've started my own wrappping effort. I think an alpha version should be ready in ~10 weeks, maybe more (I hate to guess time schedules like this, and I'm rather busy these days, but the progress is steady).
Aug 13 2013
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Tue, 2013-08-13 at 19:40 +0200, Gary Willoughby wrote:
[=E2=80=A6]
 truly think would attract many more developers to D. IMHO It's=20
 one of the two big attractors* to using any language, i.e. an=20

 Python caught on as quickly as they did.
Python has no widget set. It wraps and ships tk by default. There are wrappers for Qt, wxWidgets, GTK, and others. So the Python message is "use other people's widget sets". Easy graphics, both UI and data visualization, is a huge attractor. cf. SciPy (Matplotlib), PyGame, etc. [=E2=80=A6]
 Keep this quote in mind:
=20
 "Nobody should start to undertake a large project. You start with=20
 a small trivial project, and you should never expect it to get=20
 large. If you do, you'll just overdesign and generally think it=20
 is more important than it likely is at that stage. Or worse, you=20
 might be scared away by the sheer size of the work you envision.=20
 So start small, and think about the details. Don't think about=20
 some big picture and fancy design. If it doesn't solve some=20
 fairly immediate need, it's almost certainly over-designed. And=20
 don't expect people to jump in and help you. That's not how these=20
 things work. You need to get something half-way useful first, and=20
 then others will say "hey, that almost works for me", and they'll=20
 get involved in the project."
=20
 Linus Torvalds - Linux Times (2004-10-25)
 http://web.archive.org/web/20050404020308/http://www.linuxtimes.net/modul=
es.php?name=3DNews&file=3Darticle&sid=3D145 This is basically a reaffirmation of John Gall's observation from 1975 "General systemantics, an essay on how systems work, and especially how they fail...": "A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system." [=E2=80=A6] --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Aug 13 2013
prev sibling next sibling parent reply "Michael" <pr m1xa.com> writes:
Maybe a port of Fltk library? Small and good enough.
Aug 13 2013
parent "kdmult" <kdmult ya.ru> writes:
On Tuesday, 13 August 2013 at 19:21:31 UTC, Michael wrote:
 Maybe a port of Fltk library? Small and good enough.
There is a C++ GUI framework (BSD license) with good design and native controls http://vcf-online.org/. Is it good enough for making a partial port?
Aug 13 2013
prev sibling next sibling parent reply "Joakim" <joakim airpost.net> writes:
On Tuesday, 13 August 2013 at 13:23:07 UTC, Paul Z. Barsan wrote:
 Think of this topic as writing letters to Santa, so: what say 
 you ?
I'll take this opportunity to put forward a GUI idea I plan on implementing in D at some point. The concept is to build a client-server GUI runtime that is as simple as possible on the client side. That means the client's graphics are a small wrapper around OpenGL, simply slapping rectangles composed of pngs and text on screen and handling mouse and keyboard events. The client sends event data back to the server in a highly optimized binary protocol, which then does all layout and GUI calculations. Finally, the server sends simple commands back to the server saying what text/pngs/rectangles it wants moved or updated. The client simply handles absolutely positioned rectangles with a z-index, all relative layout and higher-level state is calculated on the server. The idea is to keep the GUI client as lean as possible, moving as much calculation as possible to the server, ie when you resize your window, the server has to recalculate layout, not the client. It would be incredibly easy to port this client to new platforms, such a lean client would be ideal for mobile platforms, efficient and low power. I think of it as the web, ie HTML/CSS/javascript, done right. There would be no javascript or other general purpose language on the client, far too complicated and insecure. Obviously this runtime wouldn't suffice for everything: you're not going to write real-time physics-based games in such a GUI runtime, which you could do in javascript in a web browser. The network lag would kill you, since all layout and GUI calculations are done on the server. But such a lean GUI runtime would handle most light and medium-strength GUI applications, most apps south of Photoshop. ;) This is a unique, innovative approach I'd like to see taken, planning to do it myself if nobody gets around to it first. But I thought I'd throw it out there as a possible approach for a D GUI to take, see what others think.
Aug 13 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 13 August 2013 at 20:00:31 UTC, Joakim wrote:
 The concept is to build a client-server GUI runtime that is as 
 simple as possible on the client side.
Are you familiar with X11? It is the 80's version of that concept. There's some downsides though to this model; it is pretty sensitive to network latency, especially. I've been wanting to do a network transparent gui myself, and is one thing I might do with my crappy implementation once it is a little more complete. I'd make the display a little thicker though, with basic widgets being there so it can just communicate in higher level events. I also want the ability to detach and reattach elsewhere, ala gnu screen.
Aug 13 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Tuesday, 13 August 2013 at 20:13:05 UTC, Adam D. Ruppe wrote:
 On Tuesday, 13 August 2013 at 20:00:31 UTC, Joakim wrote:
 The concept is to build a client-server GUI runtime that is as 
 simple as possible on the client side.
Are you familiar with X11? It is the 80's version of that concept. There's some downsides though to this model; it is pretty sensitive to network latency, especially.
You mentioned X11 to me before, when we talked about this idea over email. I'm not very familiar with X11, but when I looked at the X11 reference, it seems that it provides for a lot more commands and complexity in the client than I have in mind. I don't think X11 is well optimized, as I've found it laggy simply when running xterm or small GUI apps on a local wifi network with extremely low latency. Yes, such networked GUIs assume low latency, just as most of the web assumes a working internet connection. ;) This is not a solution for offline GUIs, and so wouldn't work as a general-purpose GUI toolkit. I wonder if offline is a niche worth serving these days however.
 I've been wanting to do a network transparent gui myself, and 
 is one thing I might do with my crappy implementation once it 
 is a little more complete. I'd make the display a little 
 thicker though, with basic widgets being there so it can just 
 communicate in higher level events. I also want the ability to 
 detach and reattach elsewhere, ala gnu screen.
Yeah, I saw your DWS writeup, seems like we have some similar ideas: :) http://arsdnet.net/dws/ What basic widgets do you have in mind, to keep on the client-side? Also, just widgets in the client or some basic layout too? With my idea, the client is only given sizes and absolute positions of rectangles, with pngs or text to render inside the rectangle: it has no conception of what it is rendering and can't do any layout on its own. For example, an offline web browser can layout a page anew when the window is resized, but all layout for my client is done on the server. As for detaching and reattaching, that is easier to do, the more state is kept on the server. :) You could do it in most webapps today, after you login at the new location, but since it's more complicated to code all that reattaching functionality and isn't necessary for most apps, most app devs don't bother.
Aug 13 2013
next sibling parent reply "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Tuesday, 13 August 2013 at 20:33:48 UTC, Joakim wrote:
clip
 Yes, such networked GUIs assume low latency, just as most of 
 the web assumes a working internet connection. ;) This is not a 
 solution for offline GUIs, and so wouldn't work as a 
 general-purpose GUI toolkit.  I wonder if offline is a niche 
 worth serving these days however.
clip A couple of comments on the point above. 1. Could it not work for offine GUIs, assuming the server and client were on the same machine, in which case one would hope the latency is low. For example X11 works locally without a network connection. 2. Based on your "I wonder if offline is a niche ...." I get the impression you live in a part of the world that has more reliable internet access than where I am from :o)
Aug 13 2013
parent "Joakim" <joakim airpost.net> writes:
On Tuesday, 13 August 2013 at 21:05:21 UTC, Craig Dillabaugh 
wrote:
 1. Could it not work for offine GUIs, assuming the server and
 client
 were on the same machine, in which case one would hope the
 latency is
 low.  For example X11 works locally without a network 
 connection.
Yes, you could put the server on the user's desktop, then drive the GUI runtime locally. But this could raise a host of issues with portability and capability, which you see with webapps that try this offline model today. You'd need to make sure that the Apache server and your oddball-cool Erlang webapp can run on the user's Windows desktop, that they won't fry his Celeron with all the stuff you can do easily on your Xeon server. But yeah, if you kept the server-side lean and portable, you could go offline this way, and I imagined that something like this would be the solution for offline use eventually.
 2. Based on your "I wonder if offline is a niche ...." I get the
 impression you live in a part of the world that has more 
 reliable
 internet access than where I am from :o)
Actually no, which is why I have multiple redundant internet connections at my place, only one of which is connected right now. ;) But offline apps are increasingly fading away: most people spend most of their time these days using apps that are constantly connected to the internet, whether email or webapps. I'm offering an idea for a specialized solution that optimizes that common connected use case, rather than a general solution that is more work for the programmer, forcing him to write more low-level networking and GUI synchronization code on his own. That's the tack the web takes, I'm following in that vein with a different approach. I'm not trying to say offline apps aren't an important use case; I'm just saying there can be other GUI toolkits to handle mostly-offline apps for now.
Aug 13 2013
prev sibling next sibling parent reply "barryharris" <slackovsky gmail.com> writes:
On Tuesday, 13 August 2013 at 20:33:48 UTC, Joakim wrote:
 On Tuesday, 13 August 2013 at 20:13:05 UTC, Adam D. Ruppe wrote:
 On Tuesday, 13 August 2013 at 20:00:31 UTC, Joakim wrote:
 The concept is to build a client-server GUI runtime that is 
 as simple as possible on the client side.
Are you familiar with X11? It is the 80's version of that concept. There's some downsides though to this model; it is pretty sensitive to network latency, especially.
You mentioned X11 to me before, when we talked about this idea over email. I'm not very familiar with X11, but when I looked at the X11 reference, it seems that it provides for a lot more commands and complexity in the client than I have in mind. I don't think X11 is well optimized, as I've found it laggy simply when running xterm or small GUI apps on a local wifi network with extremely low latency.
Have you seen this? http://wayland.freedesktop.org/
Aug 13 2013
next sibling parent reply "Joakim" <joakim airpost.net> writes:
On Tuesday, 13 August 2013 at 22:07:48 UTC, barryharris wrote:
 Have you seen this?

 http://wayland.freedesktop.org/
I've heard of it, but I didn't look at it much before. It's always described as a leaner version of X11, just as I'm suggesting a much leaner runtime than the web, but I never saw specifics on how Wayland translated that at the protocol level. I now see that remote access, like VNC or X11 provide, is unimplemented for Wayland: it's only for local use at the moment. I don't see how that's relevant to the networked GUIs we're talking about.
Aug 13 2013
parent "qznc" <qznc web.de> writes:
On Tuesday, 13 August 2013 at 22:27:16 UTC, Joakim wrote:
 On Tuesday, 13 August 2013 at 22:07:48 UTC, barryharris wrote:
 http://wayland.freedesktop.org/
I don't see how that's relevant to the networked GUIs we're talking about.
The interesting part is the rational, why they do not support remote access (for now). Short version: VNC does it better on-top than X11 does it natively, so just use VNC (or RDP or any other on-top solution).
Aug 13 2013
prev sibling parent "barryharris" <slackovsky gmail.com> writes:
On Tuesday, 13 August 2013 at 22:07:48 UTC, barryharris wrote:
 On Tuesday, 13 August 2013 at 20:33:48 UTC, Joakim wrote:
 On Tuesday, 13 August 2013 at 20:13:05 UTC, Adam D. Ruppe 
 wrote:
 On Tuesday, 13 August 2013 at 20:00:31 UTC, Joakim wrote:
 The concept is to build a client-server GUI runtime that is 
 as simple as possible on the client side.
Are you familiar with X11? It is the 80's version of that concept. There's some downsides though to this model; it is pretty sensitive to network latency, especially.
You mentioned X11 to me before, when we talked about this idea over email. I'm not very familiar with X11, but when I looked at the X11 reference, it seems that it provides for a lot more commands and complexity in the client than I have in mind. I don't think X11 is well optimized, as I've found it laggy simply when running xterm or small GUI apps on a local wifi network with extremely low latency.
Have you seen this? http://wayland.freedesktop.org/
I only mention it as it might provide a good platform to build upon in D, or at least provide a solid place to start expermenting with ideas. It's small and written in C. It also has a compositor component called Weston, again in C.
Aug 13 2013
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 13 August 2013 at 20:33:48 UTC, Joakim wrote:
 You mentioned X11 to me before, when we talked about this idea 
 over email.
Ah yes. I think X's biggest problem though is that it doesn't do *enough*. The protocol is fairly efficient for what it does, but it just doesn't do enough so the commands aren't particularly compact when you start to get fancier. For instance, in my crappygui.d, I used XDrawString to draw text. This was the result: http://arsdnet.net/gui.png That's a true type font (Bitstream Vera Sans, a fairly good looking font), but X doesn't support antialiasing. There's a library called Xft that draws fonts prettier. But how does it work? Instead of sending DrawText(x, y, "hello world!") to the display server, it uses a drawing library to render the text as an image in the application, then sends that image to the display server. And BTW if the display doesn't support the alpha blending extension (the XRender extension), it first takes a partial screenshot, does the blending in library, and sends that image back! Note that the X protocol does not compress the image data. So if you send a 100x30 pixel image of text, you're shooting some 10 KB - or double that without XRender - down the network wire instead of the .... idk exactly for sure, but I think it is about 32 bytes to just send the draw instruction. Now, you can compress an X stream over ssh, so it isn't always this bad in practice, but still, since the X display server doesn't support the expected modern feature, it blows up in bandwidth to compensate and that can kill the user experience. Note btw though, you *can* save the image on the display server to reuse it later, so every time you print a string it doesn't necessarily send that data across, but I'm not sure if the higher level libraries actually do this... the downsides of abstractions is you can miss important details like this. This is why my simpledisplay.d now has a class Sprite in addition to class Image, and why Qt has QImages and QPixmaps, but how often do you think of drawing text as being something that needs a Pixmap to be efficient? Again the library might handle it, I'm not sure, but the relatively pathetic performance of a lot of apps on a remote X connection makes me think they probably don't. Anyway, the other thing too is all events go to the client application from the display server, and then the application's changes go back to the display server. Since X itself doesn't offer any kind of widgets, a text control for instance would work like this: application -> display: draw the box display -> application: key press event application -> display: draw the character, advance the cursor,,, and if oyu have to scroll btw it might draw a whole lot of stuff (though if you know you're on a potentially networked app, you'd do something like XCopyArea and tell the display to move a whole block of data up without resending it all, but again the leaky abstraction can kill you) But yeah, the event needs a round trip to react. On a LAN, you're probably ok, but what about on the open internet where there's some latency? Well, sometimes it is actually quite fine there too, I spend a *lot* of time using both X and ssh remotely, but sometimes it gets to be really, really annoying. So I'd want to do higher level events too, and the application can request them. For instance, if all you want is a basic text input, output something like <textarea></textarea> and let the display do the details. (Another really nice benefit here, if we do it right, is it could use native controls on systems like Windows, or even pipe it to an external app on unix, and get a nice customized, adaptable system. Though while it sounds simpler in ways, this is easier said than done.) With these higher level events and widgets, unless you need to override some event, it can just be handled without the round trip and improve response time on slow connections. Though, if you do need real time event processing, you're back to the round trip, but meh, some speedup is better than none. But, indeed, we don't want to go *too* far either, especially since then we'd end up with a web browser situation where people write their applications in the scripting language...
 What basic widgets do you have in mind, to keep on the 
 client-side?  Also, just widgets in the client or some basic 
 layout too?
Layout would be nice too. Ideally, I'd love if my apps worked on both guis and text mode uis and laying them out would be a bit different. For my crappygui.d, I'm aiming to do: menus, labels, radio box, checkbox, buttons, grid layouts, text input, slider, number chooser, list boxes, and basic 2d drawing. Pretty much the basic stuff you get on html forms. Maybe more later, but I want to actually be able to get this working over the next weekend or two, so I'm keeping it simple. (And right now I'm not actually doing network transparency, I'll come back to that, my basic idea there is to simply forward all the function calls with rpc.)
 As for detaching and reattaching, that is easier to do, the 
 more state is kept on the server. :)
Yeah, my old DWS idea was to do three applications, but that was a pain, a lot of duplication to add a new function. So now I want the middle man program to be really simple, basically a switchboard, and then the detach/attach messages will be handled by the application, just shooting its current state to the new display.
 it's more complicated to code all that reattaching 
 functionality and isn't necessary for most apps, most app devs 
 don't bother.
If we do it right, it will be zero effort :) GNU Screen has pretty much pulled it off for unix terminal programs. GUIs have Remote Desktop and friends... rdp is amazing btw, Microsoft (or whoever wrote it originally and sold it to them) did an excellent job and is a decent counter argument to me - I think remote desktop is a simple viewer, the rdesktop app on unix isn't a particularly large piece of code and works quite well, but still I like my way.
Aug 13 2013
next sibling parent reply "Tyler Jameson Little" <beatgammit gmail.com> writes:
On Wednesday, 14 August 2013 at 02:23:07 UTC, Adam D. Ruppe wrote:
 On Tuesday, 13 August 2013 at 20:33:48 UTC, Joakim wrote:
 You mentioned X11 to me before, when we talked about this idea 
 over email.
Ah yes. I think X's biggest problem though is that it doesn't do *enough*. The protocol is fairly efficient for what it does, but it just doesn't do enough so the commands aren't particularly compact when you start to get fancier. snip...
I'm in the opposite camp. The server is never going to be able to support everything, and people are just going to fall back to rendering themselves anyway. For example, say you need to screw a screw into a piece of wood. Let's also say you have the following: hammer, screwdriver (doesn't fit the screw), means to fab a new screwdriver. Let's also say that the screw needs to be in by tomorrow. Will you: a) spend all night trying to get the screwdriver to work? b) design a new screwdriver (also takes all night) c) pound the screw in with the hammer (< 5 minutes) and promise yourself you'll make that screwdriver (which will never get done) I think most people will go with c. This is exactly what happened with X. People didn't care enough to put font-rendering into X, so they wrote a rendering library and used it everywhere. This way they don't have to force their users to upgrade their X server, and they still get pretty fonts (at the risk of slow X forwarding, which hardly anyone uses anyway).
 Anyway, the other thing too is all events go to the client 
 application from the display server, and then the application's 
 changes go back to the display server. Since X itself doesn't 
 offer any kind of widgets, a text control for instance would 
 work like this:

 application -> display: draw the box
 display -> application: key press event
 application -> display: draw the character, advance the 
 cursor,,, and if oyu have to scroll btw it might draw a whole 
 lot of stuff (though if you know you're on a potentially 
 networked app, you'd do something like XCopyArea and tell the 
 display to move a whole block of data up without resending it 
 all, but again the leaky abstraction can kill you)


 But yeah, the event needs a round trip to react. On a LAN, 
 you're probably ok, but what about on the open internet where 
 there's some latency? Well, sometimes it is actually quite fine 
 there too, I spend a *lot* of time using both X and ssh 
 remotely, but sometimes it gets to be really, really annoying.
Just tried to X forward Chrome on a local lan. It worked, but it was dog slow. I can't imagine trying this over a dodgy network. The problem is likely that Chrome (like most apps) makes extensive use of x frame buffer. This is the way many apps are going, and that trend is not likely to change.
 So I'd want to do higher level events too, and the application 
 can request them. For instance, if all you want is a basic text 
 input, output something like <textarea></textarea> and let the 
 display do the details.

 (Another really nice benefit here, if we do it right, is it 
 could use native controls on systems like Windows, or even pipe 
 it to an external app on unix, and get a nice customized, 
 adaptable system. Though while it sounds simpler in ways, this 
 is easier said than done.)

 With these higher level events and widgets, unless you need to 
 override some event, it can just be handled without the round 
 trip and improve response time on slow connections.

 Though, if you do need real time event processing, you're back 
 to the round trip, but meh, some speedup is better than none.
It just seems simpler to render into buffers on the client then upload entire chunks to the server. This will have less round-trips at the expense of larger packets each update. For many high-latency networks, bandwidth is not a big problem. This is why websites try to reduce the number of downloads they have by increasing sizes of each download. For example, Opera Mobile worked well because they would render the page to an image before it got to the phone. Phones were on high-latency networks, so this meant fewer round-trips.
 But, indeed, we don't want to go *too* far either, especially 
 since then we'd end up with a web browser situation where 
 people write their applications in the scripting language...


 What basic widgets do you have in mind, to keep on the 
 client-side?  Also, just widgets in the client or some basic 
 layout too?
Layout would be nice too. Ideally, I'd love if my apps worked on both guis and text mode uis and laying them out would be a bit different.
This is nice. I've also thought about how to make this not suck. My initial thought was to see how ViM works (gvim runs stand-alone, vim runs in console).
 For my crappygui.d, I'm aiming to do:

 menus, labels, radio box, checkbox, buttons, grid layouts, text 
 input, slider, number chooser, list boxes, and basic 2d 
 drawing. Pretty much the basic stuff you get on html forms. 
 Maybe more later, but I want to actually be able to get this 
 working over the next weekend or two, so I'm keeping it simple. 
 (And right now I'm not actually doing network transparency, 
 I'll come back to that, my basic idea there is to simply 
 forward all the function calls with rpc.)

 As for detaching and reattaching, that is easier to do, the 
 more state is kept on the server. :)
Yeah, my old DWS idea was to do three applications, but that was a pain, a lot of duplication to add a new function. So now I want the middle man program to be really simple, basically a switchboard, and then the detach/attach messages will be handled by the application, just shooting its current state to the new display.
 it's more complicated to code all that reattaching 
 functionality and isn't necessary for most apps, most app devs 
 don't bother.
If we do it right, it will be zero effort :) GNU Screen has pretty much pulled it off for unix terminal programs. GUIs have Remote Desktop and friends... rdp is amazing btw, Microsoft (or whoever wrote it originally and sold it to them) did an excellent job and is a decent counter argument to me - I think remote desktop is a simple viewer, the rdesktop app on unix isn't a particularly large piece of code and works quite well, but still I like my way.
You may find this interesting: http://tech.slashdot.org/story/13/04/03/1219239/remote-desktop-backend-merged-into-wayland I would love attach/reattach for UIs. This seems like it would have to be supported at the protocol level. I like the idea of Wayland, because we can both have our cake and eat it too! (just use a compositor that supports whatever you like).
Aug 13 2013
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 14 August 2013 at 06:46:53 UTC, Tyler Jameson 
Little wrote:
 Just tried to X forward Chrome on a local lan. It worked, but 
 it was dog slow. I can't imagine trying this over a dodgy 
 network. The problem is likely that Chrome (like most apps) 
 makes extensive use of x frame buffer. This is the way many 
 apps are going, and that trend is not likely to change.
Yep, this is pretty much the issue. Any application that needs own rendering (any 3d, web browsers, custom widgets) does not make use of efficient X primitives - it just renders everything into buffer and provides it to server as a whole picture. Of course, X wasn't designed to work remotely in such model. And I actually doubt primitive-based protocol can be created that does it generic enough.
Aug 14 2013
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 14 August 2013 at 06:46:53 UTC, Tyler Jameson 
Little wrote:
 I'm in the opposite camp. The server is never going to be able 
 to support everything, and people are just going to fall back 
 to rendering themselves anyway.
Couldn't you make the same argument against any gui library? But there's a lot of stuff in common that might be sped up. Menus are very slow on Qt over remote X11 (at least with the default theme). Ironically though, the tabbed widgets are pretty fast, aside from a somewhat slow startup. But menus are pretty much the same for any application, so that'd be a good thing to put in the display library. Of course, you do want just "blit this image" as a generic fallback, and we can do better than X too, by just making it use png+jpg or something. Boom, transparency (yes, X has this in the render extension) and some big compression boosts. Add display side scaling, perhaps make the pixmap be implemented as an opengl texture so you can scale, rotate, quickly paint, etc., and that's pretty useful for a lot of things. But I don't think it replaces the usefulness of higher level concepts like menus, buttons, etc. Sure, the app might have to customize them, but do they have to customize *all* of them?
 You may find this interesting: 
 http://tech.slashdot.org/story/13/04/03/1219239/remote-desktop-backend-merged-into-wayland
hmm, indeed.
 I would love attach/reattach for UIs. This seems like it would 
 have to be supported at the protocol level.
Yeah, and probably a middle man of some sort too so each application doesn't have to be listening on a port. But with the client state, if it can just send that back to the new connection, it shouldn't be too hard.
Aug 14 2013
parent "Wyatt" <wyatt.epp gmail.com> writes:
On Wednesday, 14 August 2013 at 14:26:12 UTC, Adam D. Ruppe wrote:
 Of course, you do want just "blit this image" as a generic 
 fallback, and we can do better than X too, by just making it 
 use png+jpg or something. Boom, transparency (yes, X has this 
 in the render extension) and some big compression boosts.
I recall NX does something like this, plus a number of other neat tricks. http://www.nomachine.com/documents/NX-XProtocolCompression.php -Wyatt
Aug 14 2013
prev sibling next sibling parent "qznc" <qznc web.de> writes:
On Wednesday, 14 August 2013 at 02:23:07 UTC, Adam D. Ruppe wrote:
 On Tuesday, 13 August 2013 at 20:33:48 UTC, Joakim wrote:
 You mentioned X11 to me before, when we talked about this idea 
 over email.
Ah yes. I think X's biggest problem though is that it doesn't do *enough*. The protocol is fairly efficient for what it does, but it just doesn't do enough so the commands aren't particularly compact when you start to get fancier. For instance, in my crappygui.d, I used XDrawString to draw text. This was the result: http://arsdnet.net/gui.png That's a true type font (Bitstream Vera Sans, a fairly good looking font), but X doesn't support antialiasing. There's a library called Xft that draws fonts prettier. But how does it work? Instead of sending DrawText(x, y, "hello world!") to the display server, it uses a drawing library to render the text as an image in the application, then sends that image to the display server. And BTW if the display doesn't support the alpha blending extension (the XRender extension), it first takes a partial screenshot, does the blending in library, and sends that image back! Note that the X protocol does not compress the image data. So if you send a 100x30 pixel image of text, you're shooting some 10 KB - or double that without XRender - down the network wire instead of the .... idk exactly for sure, but I think it is about 32 bytes to just send the draw instruction.
Font rendering is often application specific and very complex. This is why it is done client-side in X11 nowadays. State of Text Rendering on Linux: http://behdad.org/text/
Aug 14 2013
prev sibling parent reply "Joakim" <joakim airpost.net> writes:
On Wednesday, 14 August 2013 at 02:23:07 UTC, Adam D. Ruppe wrote:
 On Tuesday, 13 August 2013 at 20:33:48 UTC, Joakim wrote:
 You mentioned X11 to me before, when we talked about this idea 
 over email.
Ah yes. I think X's biggest problem though is that it doesn't do *enough*. The protocol is fairly efficient for what it does, but it just doesn't do enough so the commands aren't particularly compact when you start to get fancier.
As you point out later, I don't think it's the compactness of the commands that is the problem as much as that X11 bites off too much. If you're going to be both efficient and allow remote GUI forwarding, that's an incredibly difficult and orthogonal set of features to deliver on, which is why Wayland only focuses on efficiency. I'd punt on much of the stuff X11 tries to do with my lean GUI runtime, which I'll call Crack from here on out.
 For instance, in my crappygui.d, I used XDrawString to draw 
 text. This was the result: http://arsdnet.net/gui.png
--snip--
 Note btw though, you *can* save the image on the display server 
 to reuse it later, so every time you print a string it doesn't 
 necessarily send that data across, but I'm not sure if the 
 higher level libraries actually do this... the downsides of 
 abstractions is you can miss important details like this.
Interesting, it does highlight what a mess X11 is. I see no reason to build on such an old protocol.
 This is why my simpledisplay.d now has a class Sprite in 
 addition to class Image, and why Qt has QImages and QPixmaps, 
 but how often do you think of drawing text as being something 
 that needs a Pixmap to be efficient? Again the library might 
 handle it, I'm not sure, but the relatively pathetic 
 performance of a lot of apps on a remote X connection makes me 
 think they probably don't.
This is why I'd implement text layout and rendering in the Crack client, with the server simply passing along strings for the client to render, breaking the simple OpenGL wrapper promised before. ;) Here's some other exceptions I'd put in, which I mentioned to you before: Text input - As you say below, you wouldn't want to hit the server for every keypress, so text input boxes would be handled by the client. It would be easy to implement since you're already doing text layout and rendering in the client. Scrolling - Just as with text input, if you're using one rectangle onscreen as a scrollbar, you usually wouldn't want to hit the server just to get the new scroll position of the other rectangle it controls. There would be some scrolling-related event-handling in the Crack client, so that you could designate one rectangle as the scrollbar control for another rectangle and the client would handle scrolling, simply notifying the server of the new scroll position after the user is done scrolling. Upload/Download progress - Another ability you'll need is to update a rectangle based on the progress of files being downloaded or uploaded, so you can create a progress bar without having to constantly hit the server to get the status of file transfers. File chooser - And of course, access to the native file chooser widget. Caching - Finally, you'll want some resource and event-handling caching so that you can load updates quicker, just like AJAX once hacked into the web stack. Say you're implementing a photo gallery, you'll have the Crack client download the next photo in the gallery and be able to tell the client that if a certain rectangle is clicked, it should swap in the next photo without checking with the server first. This is similar to your "predictive paths" idea from DWS and would greatly decrease network traffic and GUI lag. The caching of event handling would be narrowly circumscribed, boolean logic with mouse/keyboard events as input and GUI updates as output, so that it's simpler and much more secure than a full language interpreter like javascript. Obviously, all these exceptions break the simple OpenGL wrapper that I'd wanted Crack to be, but the goal is to minimize such exceptions, so that you don't become the bloated beast that the web client has become today. :)
 Anyway, the other thing too is all events go to the client 
 application from the display server, and then the application's 
 changes go back to the display server. Since X itself doesn't 
 offer any kind of widgets, a text control for instance would 
 work like this:
--snip--
 So I'd want to do higher level events too, and the application 
 can request them. For instance, if all you want is a basic text 
 input, output something like <textarea></textarea> and let the 
 display do the details.
I agree, text input boxes should be handled by the Crack client.
 (Another really nice benefit here, if we do it right, is it 
 could use native controls on systems like Windows, or even pipe 
 it to an external app on unix, and get a nice customized, 
 adaptable system. Though while it sounds simpler in ways, this 
 is easier said than done.)
I was thinking along similar lines for other widgets, like a video player. I don't think video should be in the initial release, too complex, but just as HTML5 eventually added video functionality, you're going to want it in Crack someday. The way I formulated it is that users would choose from various video player widgets and that widget would come up in any app that played video, ie the video player is out of the control of the app developer. This avoids the problem you see with video on the web today, where you are presented with dozens of different video player implementations, whether implemented in Flash, Silverlight, or HTML5, all broken in their own special ways. ;) The app simply sends a video file to the Crack client and then the video player widget of the user's choice kicks in. This video player widget would be written in D and the user would be given a choice of which player widget best suits them when they download the Crack runtime. Alternatively, you could use plugins, but the key is to tightly control where these player widgets could come from, so that you aren't running untrusted code in the runtime. Perhaps the same choice could be offered with text input boxes and other functionality in the client.
 With these higher level events and widgets, unless you need to 
 override some event, it can just be handled without the round 
 trip and improve response time on slow connections.
Yeah, you do need local logic or widgets for some special cases, no doubt about it.
 But, indeed, we don't want to go *too* far either, especially 
 since then we'd end up with a web browser situation where 
 people write their applications in the scripting language...
Agreed, you need to keep tight limitations, or things get out of hand into the mess that the web stack is today. This is why I wouldn't put javascript or any other scripting language in Crack.
 What basic widgets do you have in mind, to keep on the 
 client-side?  Also, just widgets in the client or some basic 
 layout too?
Layout would be nice too. Ideally, I'd love if my apps worked on both guis and text mode uis and laying them out would be a bit different.
I want to keep as much layout as possible out of the Crack client, and I don't think this warrants it.
 For my crappygui.d, I'm aiming to do:

 menus, labels, radio box, checkbox, buttons, grid layouts, text 
 input, slider, number chooser, list boxes, and basic 2d 
 drawing. Pretty much the basic stuff you get on html forms. 
 Maybe more later, but I want to actually be able to get this 
 working over the next weekend or two, so I'm keeping it simple. 
 (And right now I'm not actually doing network transparency, 
 I'll come back to that, my basic idea there is to simply 
 forward all the function calls with rpc.)
Most, but not all, of those can be done with just rectangles directed from the server in Crack, with the aforementioned exceptions of sliders and text input. As for basic 2D drawing, I see no worthwhile use case. We've had the canvas tag in the browser for years now, anyone really using it?
 it's more complicated to code all that reattaching 
 functionality and isn't necessary for most apps, most app devs 
 don't bother.
If we do it right, it will be zero effort :) GNU Screen has pretty much pulled it off for unix terminal programs. GUIs have Remote Desktop and friends... rdp is amazing btw, Microsoft (or whoever wrote it originally and sold it to them) did an excellent job and is a decent counter argument to me - I think remote desktop is a simple viewer, the rdesktop app on unix isn't a particularly large piece of code and works quite well, but still I like my way.
While remote desktop is decent, it's trying to do too much: mirroring an entire desktop is overkill. Better to use a lean client that handles most situations.
Aug 14 2013
next sibling parent reply "Tyler Jameson Little" <beatgammit gmail.com> writes:
On Wednesday, 14 August 2013 at 17:35:24 UTC, Joakim wrote:
 While remote desktop is decent, it's trying to do too much: 
 mirroring an entire desktop is overkill.  Better to use a lean 
 client that handles most situations.
Maybe this is because I'm used to Linux, but I generally just want to forward an application, not the entire desktop. On Linux, this is trivial: $ ssh -X user host $ gui-program <args> However, Windows doesn't have this workflow, so mirroring the entire desktop became necessary. Simpler is usually better, as long as simpler doesn't prevent you from creating something robust on top. In a widget toolkit, I think the same applies: make just enough controls that most people are satisfied, then make the toolkit easy to extend with custom controls.
Aug 14 2013
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 15 August 2013 at 01:03:24 UTC, Tyler Jameson Little 
wrote:
 However, Windows doesn't have this workflow, so mirroring the 
 entire desktop became necessary.
It does now, Server 2008 I think was the first one, or maybe Windows 7, they call it Seamless RDP.
 In a widget toolkit, I think the same applies: make just enough 
 controls that most people are satisfied, then make the toolkit 
 easy to extend with custom controls.
Yeah, and that's a much more modest goal too. BTW I spent a couple more hours on my crappygui.d today. No network transparency here, just drawing non-native widgets. So yeah it sucks, but it is small, simple, and standalone. Take a look at this screenie! http://arsdnet.net/gui2.png My keyboard is literally falling apart and backspace doesn't work in the text edit yet (big downside of non-native widgets, the behavior is hard to get right)... so not much of an edit lol... but yeah it is moving along. I think by the end of this weekend, it will be good enough for me and I'll put the code on my misc github. The event model is lifted from javascript: button.addEventListener("click", { window.close(); }); and mouseenter, keydown, etc. are implemented too. It does the capture, bubble, preventDefault, stopPropagation, just like the w3c dom. I kinda like that model.
Aug 14 2013
prev sibling parent reply "Joakim" <joakim airpost.net> writes:
On Thursday, 15 August 2013 at 01:03:24 UTC, Tyler Jameson Little 
wrote:
 On Wednesday, 14 August 2013 at 17:35:24 UTC, Joakim wrote:
 While remote desktop is decent, it's trying to do too much: 
 mirroring an entire desktop is overkill.  Better to use a lean 
 client that handles most situations.
Maybe this is because I'm used to Linux, but I generally just want to forward an application, not the entire desktop. On Linux, this is trivial: $ ssh -X user host $ gui-program <args> However, Windows doesn't have this workflow, so mirroring the entire desktop became necessary.
Sure, but X forwarding is still laggy, as you pointed out.
 Simpler is usually better, as long as simpler doesn't prevent 
 you from creating something robust on top.
Well, that's where the problems come in. :) Making something robust usually implies complexity. Best to split up the job, client-server runtimes, like webapps or the lean Crack client I'm talking about, handle most non-realtime online GUIs, while other toolkits handle the offline or real-time cases. No one toolkit can do it all, the market has already splintered this way.
 In a widget toolkit, I think the same applies: make just enough 
 controls that most people are satisfied, then make the toolkit 
 easy to extend with custom controls.
I'm suggesting taking that philosophy to an extreme: almost no local controls, just a simple rendering runtime that slaps up rectangles and renders text, along with a few niceties like caching to lessen lag. All the controls are composed and placed into a layout on the server, which then tells the client how to build those controls out of very simple primitives: put a rectangle here and render this png into it, which happens to look like a button to the user. This won't work for side-scrolling games or other real-time stuff that's usually done in Flash now, but it will handle the long tail of apps.
Aug 15 2013
next sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Thursday, 15 August 2013 at 14:50:43 UTC, Joakim wrote:
 Sure, but X forwarding is still laggy, as you pointed out.
I think that's only because it's a naive, uncompressed implementation. Proper protocol compression pretty much removes that for most use cases. -Wyatt
Aug 15 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Aug 15, 2013 at 06:03:35PM +0200, Wyatt wrote:
 On Thursday, 15 August 2013 at 14:50:43 UTC, Joakim wrote:
Sure, but X forwarding is still laggy, as you pointed out.
I think that's only because it's a naive, uncompressed implementation. Proper protocol compression pretty much removes that for most use cases.
[...] I've run X11 forwarding over a compressed SSH tunnel before. It's actually usable. Not fast, but usable. (And this was over the internet, not in a LAN, which would be significantly faster.) I used to run X11 forwarding over an uncompressed channel, and it was unusably slow. X11 was really designed for server + many workstations LAN setups, and it still works pretty well in those scenarios. It was never designed to be used over WANs, so it performs poorly when your link goes through the internet. It also wasn't designed for desktop apps, though modern X servers bypass most of the performance overhead by extensions that allow direct memory mapping between the server and client, so you could, e.g., directly access VRAM once it's negotiated with the server. T -- In theory, software is implemented according to the design that has been carefully worked out beforehand. In practice, design documents are written after the fact to describe the sorry mess that has gone on before.
Aug 15 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Thursday, 15 August 2013 at 16:44:21 UTC, H. S. Teoh wrote:
 On Thu, Aug 15, 2013 at 06:03:35PM +0200, Wyatt wrote:
 On Thursday, 15 August 2013 at 14:50:43 UTC, Joakim wrote:
Sure, but X forwarding is still laggy, as you pointed out.
I think that's only because it's a naive, uncompressed implementation. Proper protocol compression pretty much removes that for most use cases.
[...] I've run X11 forwarding over a compressed SSH tunnel before. It's actually usable. Not fast, but usable. (And this was over the internet, not in a LAN, which would be significantly faster.) I used to run X11 forwarding over an uncompressed channel, and it was unusably slow.
I've only done X11 forwarding over ssh, both WAN and LAN, it was incredibly laggy in both cases.
 X11 was really designed for server + many workstations LAN 
 setups, and
 it still works pretty well in those scenarios. It was never 
 designed to
 be used over WANs, so it performs poorly when your link goes 
 through the
 internet. It also wasn't designed for desktop apps, though 
 modern X
 servers bypass most of the performance overhead by extensions 
 that allow
 direct memory mapping between the server and client, so you 
 could, e.g.,
 directly access VRAM once it's negotiated with the server.
What is the latency or bandwidth threshold that X11 needs? I've found it slow even with low latency and plenty of bandwidth, ie over a local LAN. "It also wasn't designed for desktop apps:" what was it designed for then, xterm and xclock and that's it? On Thursday, 15 August 2013 at 17:10:13 UTC, Tobias Pankrath wrote:
 Another solution would be to have a client/server architecture 
 in your application. Usually the GUI talks via std.concurrency 
 messages to your business logic and itself receives input 
 events this way. However if you're doing remote it's 
 transparently replaced with messages over the network.
Yeah, Craig and I talked about this possibility earlier in this thread.
 The other option discussed here: 'Yeah, X11 is kinda cool, 
 sadly the protocol didn't forsee the future 20 years, but the 
 approach is right!'
 will be considered failure in 20 years.
Like Adam said, that's good enough. X11 had it's time; if a Crack client can have it's time, that's all that matters. Trying to look ahead 20 years is a mug's game. On Thursday, 15 August 2013 at 17:18:53 UTC, Adam D. Ruppe wrote:
 On Thursday, 15 August 2013 at 14:50:43 UTC, Joakim wrote:
 All the controls are composed and placed into a layout on the 
 server
How do you handle styling? If the application defines its own theme, your thing will be good, but if you want to blend in with the rest of the desktop, that's a lot of work. One option though would be to ask the display for its current them when you connect, and then render using it in the library. Actually that's not a bad idea at all.
I don't think "blending in with the rest of the desktop" is a worthwhile goal. Web controls largely don't do this and that hasn't hurt the web. But yeah, you can try to recreate the user's theme on the server, once the client tells you what OS it's running on, if you really wanted to. There are a lot of possibilities: you could run Qt or Gtk+ on the server and then write a backend for each of those toolkits so they can call the simple Crack server APIs and render to the Crack client. The essential idea here is to push as much as possible to the server, which the developer actually controls. So he doesn't have to deal with a dozen browsers, all with their subtle implementation differences of the web protocols. He doesn't have to deal with a dozen different native widget libraries, rewriting his UI in each. You get a lot of the benefits of the web, without some of the costs, hopefully. ;)
 Of course, this applies to any GUI library: native vs DIY is 
 one of the great divides here....
I come down on the DIY side, at least for this runtime, with the possible exception of client-side widgets like a video player. But you have the flexibility to ape the native theme, if you can reproduce it faithfully on the server.
Aug 15 2013
next sibling parent reply "sclytrack tired.com" <sclytrack fakeaspie.com> writes:
 There are a lot of possibilities: you could run Qt or Gtk+ on 
 the server and then write a backend for each of those toolkits 
 so they can call the simple Crack server APIs and render to the 
 Crack client.
Gtk Broadway. http://www.youtube.com/watch?v=fr8eo4RlPw4
Aug 15 2013
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 15 August 2013 at 18:38:40 UTC, sclytrack tired.com 
wrote:
 Gtk Broadway.
nice. My first draft for my idea had an html client too, but this was some years ago before the html5 stuff was around, so it did ajax long polling for events and tried to map it to JS. Didn't work out super well, but did actually work - my three example apps (notepad, calculator, and an AIM client) all functioned on it, with minor bugs. WebSockets and <canvas> make me want to do it again. In simpledisplay.d, I added a version(html5) but didn't actually get anywhere with it...
Aug 15 2013
prev sibling parent "Joakim" <joakim airpost.net> writes:
On Thursday, 15 August 2013 at 18:38:40 UTC, sclytrack tired.com 
wrote:
 There are a lot of possibilities: you could run Qt or Gtk+ on 
 the server and then write a backend for each of those toolkits 
 so they can call the simple Crack server APIs and render to 
 the Crack client.
Gtk Broadway. http://www.youtube.com/watch?v=fr8eo4RlPw4
I saw that a couple years ago, cool demo, though I wonder how precise or laggy it'd be over the network. Do you know if they're using canvas or webGL to render? All I see online is that they used websockets for networking. I did find this cool post when looking for more info: https://brendaneich.com/2013/05/today-i-saw-the-future/ I'm skeptical about all the engineering challenges of that GPU cloud stuff though. I'd rather work on getting a good thin client going first, which the web should have been but never got right, before getting into all this whiz-bang stuff with so many moving parts.
Aug 15 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Aug 15, 2013 at 08:35:20PM +0200, Joakim wrote:
 On Thursday, 15 August 2013 at 16:44:21 UTC, H. S. Teoh wrote:
On Thu, Aug 15, 2013 at 06:03:35PM +0200, Wyatt wrote:
On Thursday, 15 August 2013 at 14:50:43 UTC, Joakim wrote:
Sure, but X forwarding is still laggy, as you pointed out.
I think that's only because it's a naive, uncompressed implementation. Proper protocol compression pretty much removes that for most use cases.
[...] I've run X11 forwarding over a compressed SSH tunnel before. It's actually usable. Not fast, but usable. (And this was over the internet, not in a LAN, which would be significantly faster.) I used to run X11 forwarding over an uncompressed channel, and it was unusably slow.
I've only done X11 forwarding over ssh, both WAN and LAN, it was incredibly laggy in both cases.
You need to run ssh -C, otherwise it just goes uncompressed plus the overhead of encrypting/decrypting each packet. But yeah, it's not exactly fast. Definitely can't play FPS's over it. :)
X11 was really designed for server + many workstations LAN setups,
and it still works pretty well in those scenarios. It was never
designed to be used over WANs, so it performs poorly when your link
goes through the internet. It also wasn't designed for desktop apps,
though modern X servers bypass most of the performance overhead by
extensions that allow direct memory mapping between the server and
client, so you could, e.g., directly access VRAM once it's negotiated
with the server.
What is the latency or bandwidth threshold that X11 needs? I've found it slow even with low latency and plenty of bandwidth, ie over a local LAN. "It also wasn't designed for desktop apps:" what was it designed for then, xterm and xclock and that's it?
[...] Sorry, I was unclear, I meant that it wasn't really intended to have the server and client both run on the same box. Of course, this problem is largely alleviated by X extensions that allow direct memory mapping between server and client. But the base protocol wasn't really designed for optimized localhost communication (needing to talk to a localhost server via sockets adds a lot of overhead, esp. given X11's verboseness in terms of protocol). T -- The fact that anyone still uses AOL shows that even the presence of options doesn't stop some people from picking the pessimal one. - Mike Ellis
Aug 15 2013
parent "Wyatt" <wyatt.epp gmail.com> writes:
On Thursday, 15 August 2013 at 18:52:21 UTC, H. S. Teoh wrote:
 You need to run ssh -C, otherwise it just goes uncompressed 
 plus the
 overhead of encrypting/decrypting each packet.
SSH compression is something of a worst-case scenario for compressing remote X traffic. As a fun aside, for X forwarding on LAN I find -c arcfour offers better performance. -C just slows things down.
 But yeah, it's not exactly fast. Definitely can't play FPS's 
 over it. :)
This... I was going to say it's pretty much impossible, but thinking about it, I'm not so sure. X forwarding uses indirect rendering, which has never given me good performance, but it MAY be possible on modern hardware with good bandwidth, clever compression, and client-side prediction (Something like Frankensteining NX, GGPO, VirtualGL, and ICER together?). Probably not for FPS, so much, but a lot of other semi-realtime applications. Fundamentally, you have to deal with getting a frame up inside of 33 milliseconds, however you do it, and input latency somewhere in the same apartment block as 50ms (else people hem and haw like you wouldn't believe). OnLive, for how they hilariously over-promised on infrastructural matters, looked to have some pretty interesting tech underneath; but they claim to have relied heavily on custom ASICs to pull it off. -Wyatt
Aug 16 2013
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
You're probably using bloated apps! I'm using my crappygui.d on remote X and it works quite well. Of course it is mostly rectangles of solid colors :) I also just tried creating an OpenGL window remotely, and it performed reasonably well too, drawing some colorful triangles. I think I'll add some minimal support for creating opengl contexts to simpledisplay.d, that's useful stuff.
 I don't think "blending in with the rest of the desktop" is a 
 worthwhile goal.
Eh, it is something I can live without, but would like to have. Applications just feel more complete when they blend in.
Aug 15 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/15/13 12:42 PM, Adam D. Ruppe 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.
You're probably using bloated apps! I'm using my crappygui.d on remote X and it works quite well. Of course it is mostly rectangles of solid colors :) I also just tried creating an OpenGL window remotely, and it performed reasonably well too, drawing some colorful triangles. I think I'll add some minimal support for creating opengl contexts to simpledisplay.d, that's useful stuff.
The X Window System is slow by design, particularly when used over a network (regardless how fast). There are various proxies and alternate remoting protocols that avoid its inherent latencies. At work we use OpenNX. Andrei
Aug 15 2013
parent reply Marek Janukowicz <marek janukowicz.net> writes:
Andrei Alexandrescu wrote:

 On 8/15/13 12:42 PM, Adam D. Ruppe 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.
You're probably using bloated apps! I'm using my crappygui.d on remote X and it works quite well. Of course it is mostly rectangles of solid colors :) I also just tried creating an OpenGL window remotely, and it performed reasonably well too, drawing some colorful triangles. I think I'll add some minimal support for creating opengl contexts to simpledisplay.d, that's useful stuff.
The X Window System is slow by design, particularly when used over a network (regardless how fast). There are various proxies and alternate remoting protocols that avoid its inherent latencies. At work we use OpenNX.
If we are discussing X's shortcomings: why don't we use something like http://wayland.freedesktop.org/ which will (hopefully) become next big standard and which addresses many of X's flaws? -- Marek Janukowicz
Aug 16 2013
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Aug 16 2013
prev sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
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
 What is the latency or bandwidth threshold that X11 needs?
They talk a bit about this in the above link, too. -Wyatt
Aug 16 2013
parent reply "Joakim" <joakim airpost.net> writes:
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.
Aug 19 2013
parent reply "Ramon" <spam thanks.no> writes:
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
Aug 19 2013
next sibling parent reply Gambler <fake feather.org.ru> writes:
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).
Aug 19 2013
parent "Ramon" <spam thanks.no> writes:
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
Aug 20 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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
Aug 20 2013
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Aug 20 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-08-20 15:30, Adam D. Ruppe wrote:

 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.)
So no port for Mac OS X in sight? No X doesn't count. -- /Jacob Carlborg
Aug 20 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 20 August 2013 at 17:43:46 UTC, Jacob Carlborg wrote:
 So no port for Mac OS X in sight?
I don't have a Mac, so unless someone else wants to do it (probably best to wait until the Windows version is more complete though, so you don't have to keep up with my changing my mind every other day), then no. A couple years ago, someone from the ng contributed a Cocoa port of simpledisplay.d to me, and it is now in that file, but I can't actually test it myself so it is unlikely to even compile now with the other changes to the file. Here's something you might be able to help with though: what keywords would get me search results for an acceptable but cheap Mac for this kind of thing? I don't even know what version D works best with, and don't have a lot of money to spend on another computer right now. But if I can get a used one for like a hundred bucks on ebay or something, I'll do it and then maintain the port myself.
Aug 20 2013
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 20 August 2013 at 17:56:27 UTC, Adam D. Ruppe wrote:
 On Tuesday, 20 August 2013 at 17:43:46 UTC, Jacob Carlborg 
 wrote:
 So no port for Mac OS X in sight?
I don't have a Mac, so unless someone else wants to do it (probably best to wait until the Windows version is more complete though, so you don't have to keep up with my changing my mind every other day), then no. A couple years ago, someone from the ng contributed a Cocoa port of simpledisplay.d to me, and it is now in that file, but I can't actually test it myself so it is unlikely to even compile now with the other changes to the file. Here's something you might be able to help with though: what keywords would get me search results for an acceptable but cheap Mac for this kind of thing? I don't even know what version D works best with, and don't have a lot of money to spend on another computer right now. But if I can get a used one for like a hundred bucks on ebay or something, I'll do it and then maintain the port myself.
Depending on where you're based and how you feel about breaking unenforceable EULAs, just buy an OS X install disk/usb and go here and DIY: http://www.tonymacx86.com/home.php
Aug 20 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-08-20 20:12, John Colvin wrote:

 Depending on where you're based and how you feel about breaking
 unenforceable EULAs, just buy an OS X install disk/usb and go here and
 DIY: http://www.tonymacx86.com/home.php
If I recall correctly it's possibly to run Mac OS X in VMware 4, without any hacks. Apparently they forgot to add the limitation that you can only run Mac OS X as a guest system on an actual Mac. -- /Jacob Carlborg
Aug 20 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-08-20 19:56, Adam D. Ruppe wrote:

 I don't have a Mac, so unless someone else wants to do it (probably best
 to wait until the Windows version is more complete though, so you don't
 have to keep up with my changing my mind every other day), then no.
I have no direct interest in doing it, more of a general question because developers often forget about Mac OS X, at least here. -- /Jacob Carlborg
Aug 20 2013
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 15 August 2013 at 14:50:43 UTC, Joakim wrote:
 All the controls are composed and placed into a layout on the 
 server
How do you handle styling? If the application defines its own theme, your thing will be good, but if you want to blend in with the rest of the desktop, that's a lot of work. One option though would be to ask the display for its current them when you connect, and then render using it in the library. Actually that's not a bad idea at all. But I think it is just easier to use native widgets on the display when you can, then they are styled automatically. Of course, this applies to any GUI library: native vs DIY is one of the great divides here....
Aug 15 2013
prev sibling parent reply Tobias Pankrath <lists pankrath.net> writes:
On 14.08.2013 19:35, Joakim wrote:
 On Wednesday, 14 August 2013 at 02:23:07 UTC, Adam D. Ruppe wrote:
[snip a lot of discussion of Adam and Joakim]
 If we do it right, it will be zero effort :) GNU Screen has pretty
 much pulled it off for unix terminal programs. GUIs have Remote
 Desktop and friends... rdp is amazing btw, Microsoft (or whoever wrote
 it originally and sold it to them) did an excellent job and is a
 decent counter argument to me -  I think remote desktop is a simple
 viewer, the rdesktop app on unix isn't a particularly large piece of
 code and works quite well, but still I like my way.
While remote desktop is decent, it's trying to do too much: mirroring an entire desktop is overkill. Better to use a lean client that handles most situations.
Another solution would be to have a client/server architecture in your application. Usually the GUI talks via std.concurrency messages to your business logic and itself receives input events this way. However if you're doing remote it's transparently replaced with messages over the network. Starting a remote session for the first time could involve wget and rdmd though. The other option discussed here: 'Yeah, X11 is kinda cool, sadly the protocol didn't forsee the future 20 years, but the approach is right!' will be considered failure in 20 years.
Aug 15 2013
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 15 August 2013 at 17:10:13 UTC, Tobias Pankrath 
wrote:
 Another solution would be to have a client/server architecture 
 in your application.
This is actually how I did D gui apps before, with the "server" being a C++ dll that uses the qt library. (I tried qtd but it crashed too much.)
 The other option discussed here: 'Yeah, X11 is kinda cool, 
 sadly the protocol didn't forsee the future 20 years, but the 
 approach is right!'
 will be considered failure in 20 years.
meh, in 20 years they can always write a new one.
Aug 15 2013
prev sibling next sibling parent John Joyus <john.joyus gmail.com> writes:
On 08/13/2013 09:23 AM, Paul Z. Barsan wrote:
 Think of this topic as writing letters to Santa, so: what say you ?
Let me propose a nice a name, RADD (simply pronounced as 'rad') stands for "Rapid Application Development with D".
Aug 13 2013
prev sibling next sibling parent "Tyler Jameson Little" <beatgammit gmail.com> writes:
On Tuesday, 13 August 2013 at 13:23:07 UTC, Paul Z. Barsan wrote:
 Hello everyone,

 These days I've been searching for a cross-platform IDE for D 
 and I found out that there aren't any viable standalone 
 options. After a few clicks, I've ran over this topic: 
 http://forum.dlang.org/thread/astrlgbptrlvcdicqxux forum.dlang.org 
 and it wasn't a surprise to see there are other people 
 searching for the very same thing.One of the reasons for the 
 absence of such IDEs is that there are no widget toolkits 
 written in D except DWT, but some people are complaining about 
 DWT for being a clone of SWT and that clients will want DWT to 
 be in sync with SWT since SWT is a "marketing paradigm". As 
 such, I want to embark on a long journey of writing a new 
 widget toolkit from scratch.
I already opened this can of worms: http://forum.dlang.org/thread/vtaufckbpdkpuxyztyoi forum.dlang.org?page=1 There's some good feedback there. Not sure if you saw this one.
 Here are the ideas that people came up with so far(sorry if I 
 omitted something):

 snip...

 Think of this topic as writing letters to Santa, so: what say 
 you ?
I'm a web developer, and CSS+HTML works quite well. The DOM sucks, but the idea of separating markup, style and code has worked out pretty well. QML uses this model pretty well, and I think we can do something pretty nice with D's awesome template support and CTFE. My general preferences: - simple, orthogonal, efficient - theme-able at runtime - simple event model Opinions: - no XML - few abstractions (i.e. avoid Java-esque OO obsession) Features I'd really like: - direct frame buffer support (like qingy on Linux, but not sucky) - no GC (in an ideal world) - I'm not a big fan of Phobos relying on the GC - removes a barrier to writing bare-metal applications (only have to implement a new backend, not the whole ecosystem) - less expensive to link into a non-D project - CTFE - entire API accessable from C - so I can reuse it in another language (i.e. Rust, Go, Python, etc.) Overall design: - simple buffer layering strategy, with bottom up and top-down message passing http://swtch.com/~rsc/thread/cws.pdf - scene graph (like clutter): http://en.wikipedia.org/wiki/Clutter_%28toolkit%29 I'd be interested in helping out, but I can't promise I'll be dependable enough to be a major maintainer, since I don't have any real projects that use D. Writing a UI toolkit is on my already long list of TODOs.
Aug 13 2013
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Tuesday, 13 August 2013 at 13:23:07 UTC, Paul Z. Barsan wrote:
 Hello everyone,

 These days I've been searching for a cross-platform IDE for D 
 and I found out that there aren't any viable standalone 
 options. After a few clicks, I've ran over this topic: 
 http://forum.dlang.org/thread/astrlgbptrlvcdicqxux forum.dlang.org 
 and it wasn't a surprise to see there are other people 
 searching for the very same thing.One of the reasons for the 
 absence of such IDEs is that there are no widget toolkits 
 written in D except DWT, but some people are complaining about 
 DWT for being a clone of SWT and that clients will want DWT to 
 be in sync with SWT since SWT is a "marketing paradigm". As 
 such, I want to embark on a long journey of writing a new 
 widget toolkit from scratch.

 Here are the ideas that people came up with so far(sorry if I 
 omitted something):

 evilrat:
 * we need a truly D UI(not wrapper) first
 * there are almost no declarative cross platform(i mean major 
 OS) toolkit for writing simple yet highly customizable UI's, 
 with HTML markup-like,
 customizable UI's without messing with 
 imperative(C/C++/D/whatever) code

 eles:
 * a D-ported version of a rather anonymous toolkit won't be 
 shaded by the original
 * evolution is slower, so not a fast-moving target
 * the team behind that toolkit will be more than glad to help, 
 as their toolkit will gain in popularity, and could even be 
 converted to D-development (instead of C or C++ or whatever)
 * re-write FOX tk in D, not to bind to it
 * drivers as the lower bound in my original post. The rest 
 should be drawn...

 Trvhgoy:
 * define the layout with a markup language like XAML or XUL for 
 example and the styling with a CSS-like definition.

 Mike Parker:
 * Harmonia might be a good place to start: 
 http://harmonia.terrainformatica.com/doku.php

 Chris:
 * a UI tool like Glade or Interface Builder is indispensible

 Jacob Carlborg:
 * You would still need to some graphics primitives. Do you want 
 to implement them yourself as well? I mean, you have to draw 
 the line somewhere. There's always a layer beneath you that you 
 rely on, if you're not doing embedded or similar.
 * you want a non-native toolkit.
 * primitives would be implemented on top of OpenGL or DirectX. 
 OpenGL is implemented in the graphics drivers, don't know how 
 it works with DirectX.

 Now let me complete these notes:

 * I think that porting an anonymous toolkit to D will do more 
 harm than good because if the original project was lacking some 
 features then clients will think that the ported version lacks 
 them as well. If we want to take this route then, besides 
 Harmonia and FOX tk, we might borrow things from FLTK(Fast 
 Light Toolkit)
 * If the projects starts from zero, with its own design and is 
 "shiny new" then people will be more attracted.
 * Even if we don't port a toolkit we can still get inspired to 
 see how they interact with the underlying system. For example, 
 we can take a look over the SDL way of handling input.
 * for drawing primitives we can use Cairo(curently used by GTK) 
 or libX11 on linux and Directx on windows.Bindings for cairo 
 and libX11 are provided by Deimos. I'm not sure if we can use 
 OpenGL because it requires a rendering window or it renders in 
 fullscreen mode.That rendering window can be provided by other 
 toolkits but I don't think we want to depend on them. The OS 
 window manager(xorg on linux) needs to keep track of the things 
 it draws on its root window or surface and must be aware what 
 to clean-up after you close your program. So the layer beneath 
 this widget toolkit on Linux would be X(libX11).
 * XAML is being developed by Microsoft and XUL by Mozzilla. I 
 think XUL is a better choice for a markup language and more 
 friendlier with an open source toolkit. It would be pretty nice 
 if we can make the GuiParser and abstract class and provide an 
 implementation for XUL because that will allow us to write an 
 implementation for the QML(Qt) aswell or other flavors of 
 layout and style files.
 * If we want the project to scale up nicely then we should do 
 things by the book. That is doing some research to see what 
 technologies are involved, what the client programmers 
 want(this thread) and then write some specs.
 * After we have the specs then we can start designing the 
 toolkit using UML diagrams such that we will end up with a 
 clean API and avoid future re-factoring. For UML designs, I 
 recommend this web app https://www.draw.io/ which saves its 
 files in XML format and we can store them in the git repository.
 * Only after we have a good design we will begin the actual 
 coding.
 * there is this 3D modelling tool called Blender which has a 
 modern-looking UI. People have been wondering if that GUI can 
 be used as a library and the answer is no because the gui is 
 harcoded into Blender. If our default ui look resembles that 
 one(not necessarily identical) then we will gain more 
 clients.Maybe we can even get support from its huge community 
 of artists. Take a look: 
 http://www.blender.org/features-gallery/features/
 * this toolkit can complement DWT because DWT will provide 
 native look and this one will provide the same look on all 
 platforms.

 In the previously mentioned forum thread, I've seen that there 
 are other developers willing to contribute to a new widget 
 toolkit project.I haven't hosted the project yet because I'm 
 undecided what hosting service should I use. AFAIK, sourceforge 
 is for projects and it gives you the option of hosting a 
 website, using other bugtrackers such as Trac and github is 
 focused more on the code. So where do you think a project of 
 this magnitude should be hosted ?

 Think of this topic as writing letters to Santa, so: what say 
 you ?
I'm currently toying with my own gui toolkit. Not at all ready to show yet. Its originally based on OOGL https://github.com/Overv/OOGL Basically the way I'm planning on it every control is drawn by an opengl shader that can be switched out at the system, user and app level. Enabling themeing by pretty much anybody. It however won't use native controls. I do have a port of OOGL to D but its really just for OOP of opengl. https://github.com/rikkimax/D_OOGL The controls will end up being a seperate library but the core library will basically a much nicer version of it.
Aug 14 2013
prev sibling next sibling parent reply "Jonas Drewsen" <nospam4321 hotmail.com > writes:
I've been tinkering with a GUI framework in D myself to use in my 
own project. This is how it looks:

https://www.youtube.com/watch?v=IfloImORm74&hd=1

* OpenGL

* FreeType for glyphs

* Text layout engine inspired by Qt

* Widget layout inspired by OSX

* SDL for input - would be awesome to get rid of this by using 
some of AdamRuppes work maybe.

* Animations (by using CTFE)(The youtube video is laggy, it looks 
smooth on the machine). I've done this in C++ before and D rocks 
compared!

Project layout:

https://dl.dropboxusercontent.com/u/188292/Capture1.PNG
https://dl.dropboxusercontent.com/u/188292/Capture.PNG

It is Work In Progress but ping me if anyone would like partner 
up on this. I'm open to radical changes and redesigns... whatever 
it takes to make it awesome.

I does require a bit of work to separate it out and put it on 
github so therefore I'm not posting a link to the source before 
someone is interested.

/Jonas
Aug 15 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Aug 16 2013
parent reply "Jonas Drewsen" <nospam4321 hotmail.com > writes:
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
Aug 16 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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!)
Aug 20 2013
parent "Jonas Drewsen" <nospam4321 hotmail.com > writes:
On Tuesday, 20 August 2013 at 13:19:33 UTC, Adam D. Ruppe wrote:
 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
Thanks! /Jonas
Aug 24 2013
prev sibling parent Martin Nowak <code dawg.eu> writes:
On 08/13/2013 03:23 PM, Paul Z. Barsan wrote:
 Jacob Carlborg:
 * You would still need to some graphics primitives. Do you want to
 implement them yourself as well? I mean, you have to draw the line
 somewhere. There's always a layer beneath you that you rely on, if
 you're not doing embedded or similar.
 * you want a non-native toolkit.
 * primitives would be implemented on top of OpenGL or DirectX. OpenGL is
 implemented in the graphics drivers, don't know how it works with DirectX.
Writing a rasterizer isn't actually that hard. https://github.com/dawgfoto/graphics
Aug 15 2013