On 5/20/13, Adam D. Ruppe <destructionator@gmail.com> wrote:
> Hell, I've even done this. https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/simpledisplay.d
>
> nothing fancy but it works.

Yeah I did one of my own as well. It's kind of in a todo state, I started implementing layout support but then got so tired of trying to figure out how to properly do it that I've left it to collect some digital dust for a while.

On 5/20/13, Adam D. Ruppe <destructionator@gmail.com> wrote:
> Oh btw I think a generic event loop is important too, for gui and non gui stuff.

Yeah that's interesting. I went the Qt route and implemented a prioritized message queue, so higher-priority events get dispatched before lower-priority events. And then for other more important things events can be dispatched immediately rather than queued (this is very much like Qt's sendEvent vs postEvent).

On 5/20/13, Adam D. Ruppe <destructionator@gmail.com> wrote:
>>     2) Solid leadership.
> but yeah this isn't me.

If I had the actual experience of using major GUI libs like WPF for an extended period of time (and preferably in a commercial setting where successful projects were released), then I'd volunteer to do it. Otherwise it's no good acting like Stalin if you don't know exactly *what* you're doing. :P

On 5/21/13, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> Just discussion the

*discussing

On Mon, 20 May 2013 13:49:28 -0700
"Adam Wilson" <flyboynw@gmail.com> wrote:
> 
> And my point is that your assertion that it can never be done is patently untrue. If MS can do it, there is no technical barrier to FOSS doing it, other than our own mental conception of what we are capable of. The point about WPF is that the system is so flexible in it's rendering that you can precisely emulate any native OS toolkit, or go off in a completely new direction. I prefer that flexibility as a UI designer.
> 

I still have a hard time believing that it's realistic for it take take everything into account. *Even* if you go to all the effort to make every render and behavior pixel-perfect, you're *still* failing to account for all of the following things, all of which actually *exist*:

- Software to allow the user to custom-reskin the system. Yes, even on
  Windows this exists, and has for a looong time. Getting a third-party
  GUI toolkit compatible with this would likely be quite difficult, if
  even possible.

- On windows, I use a program called KatMouse that allows me to scroll
  any control by just pointing at it and using my mouse's scroll-wheel.
  No need to manually "focus" the control before the retarded Win system
  allows me to scroll it. This is literally my #1 favorite windows
  program. But this obviously doesn't work on programs that merely
  *emulate* the system's look-and-feel, no matter how meticulous the
  emulation. Hell, even the UI changes in "native" MS-developed Vista
  and Win7 break it at least half the time.

- Tools to reveal the value behind "******"-filled password boxes.
  Sounds like a black-hat tool, but I've personally had legitimate
  need to use it.

- Anything else that involves either GUI-introspection or adding a
  cross-application UI feature. There's plenty of other
  entirely valid use-cases.

Unless I'm mistaken, these sorts of things *cannot* be handled by a non-native UI without either the given utility special-casing every specific UI toolkit out there, or the UI toolkit (somehow) special-casing every such tool/utility. Neither approach is scalable enough to be a real solution. Ultimately, there must be *some* common system-wide UI, without cheaters, so that cross-cutting features are *realistically* possible and not inherently unreliable.

Of course, you could say that such uses aren't important, but I'd very strongly disagree.

On Mon, 20 May 2013 14:58:24 -0700
"Adam Wilson" <flyboynw@gmail.com> wrote:

> On Mon, 20 May 2013 14:36:11 -0700, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:
> > With only a brief, cursory understanding of the current state-of-the-art, any attempts to "advance the field" automatically carry a high risk of *regression* under the false guise of advancement.
> >
> > And I strongly believe that's already been happening *a lot* over the past decade. Wheels are being reinvented, only this time most of them are squares.
> >
> >
> 
> Well arguably that regression in markup based UI was WPF. They made a lot of mistakes that to this day murder performance and the markup is pretty bulky. But they've gone backed and fixed a lot of the perf and markup issues with WinRT, and I am seeing some better markups in newer toolkits that look like they learned from WPF. But arguably HTML/CSS was the first, and IMHO they made WAY to many mistakes there and only now just starting to catch up to where WPF was in 2005.
> 

Well, I wasn't really directing that at anything in particular, whether UI markups or otherwise. Just a general comment. Although many of the specific instances I have in mind *do* involve the web.

With a friend/coworker we work on a prototype of a GUI system like QML.

QML is not native and visual aspect can't follow platform specific style efficiently, but today GUI style changes often and fast. Old Windows Widget style seems dying. Microsoft now use Aero and Office don't looks close to old Widgets applications. An other important point is that smallest devices now support OpenGL
 more and more.

We choose to do something like QML because it's a relatively to implement, the user have to create it's own components and give a fine control of GUI behavior.
http://en.wikipedia.org/wiki/QML

Techno we use :
 - OpenGL 2.1 (to support older hardware)
 - SDL2
 - Lua for ui declaration (QML use a javascript engine, JIT cause some issues on iOS for exemple, a move to D should be great in a future)
 - __traits to generate bindings
 - D signals (we don't use thread for the moment)

Status of "DQuick" :
The major features actually missing in the script engine are components and user defined properties to allow user to declare it's own virtual types, without this it's not possible to create a Button because it's not a base type.
Property binding just works fine.
For other part of DQuick a lot of objects are missing, like State, Animation, Loader. Our item can't be loaded asynchronously and for images it can be an issue.

Issues :
 - Remote desktop doesn't seems work under Windows (due to OpenGL? or bad driver?)
 - Realtime resize doesn't works (investigation need to be done)


We may open our code when components will be implemented plus the addition of a better demonstration. We are really far of a production release and a schedule can't be done for the moment, don't hope to much on it :-).

On 5/20/13 3:08 PM, Adam D. Ruppe wrote:
> On Monday, 20 May 2013 at 22:04:06 UTC, Andrej Mitrovic wrote:
>> everyone has their own unique idea and where they disagree with each
>> other.
>
> I don't even agree with myself!

I've been trying to find a good point in this thread to inject my basic thoughts on the subject.  This is probably the best place (and it's not directly specifically at you Adam but rather the topic).

I think it's a pretty huge fallacy to even consider that there can be one true standardized gui toolkit.  As evidence, just look at the sheer number of them that exist right now.  If you could pick a top 10 list, and I think even that would be hard, there's not a clearly ahead of the others champion.  There's just too many different philosophies and approaches to the problem with too many competing goals.

The "ideal GUI" is something that I believe can't be defined, much less exist.

As to re-invent vs wrap.. just consider the number of man years poured into your favorite gui toolkits that already exist, and then consider repeating that cost.  Aren't there a number of other projects, todo's, bug fixes, etc that would benefit from even a fraction of that sort of investment?

My 2 cents,
Brad

On Monday, 20 May 2013 at 21:47:56 UTC, Andrej Mitrovic wrote:

> 1) A "core" for a GUI library written in D that people can start
> hacking on (meaning you can create windows, and draw in a pixel
> buffer, capture device input, all platform-independent), and
>

Dereclit and SDL already does that. Rewrite SDL isn't needed, for my work it's already something I do and can tell you that it's really hard to support many platforms as Android, iOS, Windows, MacOS, consoles,... It's too long to learn all specifications and issues.

On Mon, 20 May 2013 14:51:36 -0700
"Adam Wilson" <flyboynw@gmail.com> wrote:

> On Mon, 20 May 2013 14:44:04 -0700, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:
> 
> >
> > These days, native UIs are already hardware accelerated. Aero is, Quartz is, etc. There was a huge push towards this ten-plus years ago.
> >
> 
> Erm, when it comes to Aero, that depends. Aero Glass, the window chrome is rendered in Hardware. But the styling of each UI widget, buttons for example, is still done by GDI in software.
> 

Really? Wow. What in the world *have* they been accomplishing in the past decade? ;)

On Monday, 20 May 2013 at 22:26:39 UTC, Flamaros wrote:
> With a friend/coworker we work on a prototype of a GUI system like QML.
>
> QML is not native and visual aspect can't follow platform specific style efficiently, but today GUI style changes often and fast. Old Windows Widget style seems dying. Microsoft now use Aero and Office don't looks close to old Widgets applications. An other important point is that smallest devices now support OpenGL
>  more and more.
>
> We choose to do something like QML because it's a relatively to implement, the user have to create it's own components and give a fine control of GUI behavior.
> http://en.wikipedia.org/wiki/QML
>
> Techno we use :
>  - OpenGL 2.1 (to support older hardware)
>  - SDL2
>  - Lua for ui declaration (QML use a javascript engine, JIT cause some issues on iOS for exemple, a move to D should be great in a future)
>  - __traits to generate bindings
>  - D signals (we don't use thread for the moment)
>
> Status of "DQuick" :
> The major features actually missing in the script engine are components and user defined properties to allow user to declare it's own virtual types, without this it's not possible to create a Button because it's not a base type.
> Property binding just works fine.
> For other part of DQuick a lot of objects are missing, like State, Animation, Loader. Our item can't be loaded asynchronously and for images it can be an issue.
>
> Issues :
>  - Remote desktop doesn't seems work under Windows (due to OpenGL? or bad driver?)
>  - Realtime resize doesn't works (investigation need to be done)
>
>
> We may open our code when components will be implemented plus the addition of a better demonstration. We are really far of a production release and a schedule can't be done for the moment, don't hope to much on it :-).

I forgot that we don't support text for the moment, but we'll use FreeType library, but we already have some experiences with it.

On Mon, 20 May 2013 15:35:57 -0700, Flamaros <flamaros.xavier@gmail.com> wrote:

> On Monday, 20 May 2013 at 21:47:56 UTC, Andrej Mitrovic wrote:
>
>> 1) A "core" for a GUI library written in D that people can start
>> hacking on (meaning you can create windows, and draw in a pixel
>> buffer, capture device input, all platform-independent), and
>>
>
> Dereclit and SDL already does that. Rewrite SDL isn't needed, for my work it's already something I do and can tell you that it's really hard to support many platforms as Android, iOS, Windows, MacOS, consoles,... It's too long to learn all specifications and issues.

Well I talked to Mike Parker (Derelict maintainer) at DConf and even he seemed to think that Derelict wasn't up to the task. The general consensus was that Derelict is primarily targeted at games. Which poses a number of issues in terms of UI toolkits, most of the relating to font rendering.

Specifically:
Font rendering is allowed to be vastly different across platforms.
Much of what we would require in UI's of the font rendering engine is not available at all, wrapping, line spacing, layout, etc.
Sub-pixel font hinting. Almost no games use this, and almost every OS toolkit does.
There was more that I am forgetting...

Derelict may be useful as a binding to OpenGL, but that's about where it ends, there is still MUCH work to be done on top of it.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/