www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Ideal D GUI Toolkit

reply "Tyler Jameson Little" <beatgammit gmail.com> writes:
I've been looking into trying to fix QtD, but it seems writing a 
binding to a C++ library is a bit complicated. I've read on the 
forums that a native D GUI toolkit is the most desirable 
long-term, so I'd like to start that discussion.

First off, I've heard of the DWT project, which looks promising, 
but it seems like a direct port of Java's SWT instead of a 
reimagining using idiomatic D. I understand the allure here 
(works, little translation for new developers), but since it's 
not yet in Phobos, I can only assume it's still up for discussion.

Personally, I want these features:

* simple and extensible
   * minimal components (something like HTMLs feature-set)
   * custom components (embed OpenGL/direct frame buffer)
* "native" window decorations by default, but can provide custom 
decorations
* markup (like QML) or programmable (like SWT)

Nice-to-haves:

* hardware accelerated (2D OpenGL)
* GUI designer (much easier with QML-esque markup)
* part of Phobos

I'm willing to lend a hand, but I'd like to know in what 
direction the community would like to go. I'd also like to know 
the likelihood of getting a GUI toolkit into Phobos.

Thoughts?
May 19 2013
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, May 20, 2013 07:25:49 Tyler Jameson Little wrote:

  I'd also like to know
 the likelihood of getting a GUI toolkit into Phobos.


It's come up before, and I don't think that any sort of decision has ever been 
made on that, though personally, that strikes me as the sort of thing that 
doesn't really belong in the standard library. Certainly, if it did end up in 
there, it would probably have to be very minamalistic.

Also, I thought that general consensus had been that while it would be awesome 
to have a GUI toolkit written in D at some point, that's the sort of thing 
that takes a ton of time and effort, and we have enough other stuff that needs 
doing that the time and effort of the community was better spent on other 
things and that wrapping a C++ GUI toolkit was a better move for the 
forseeable future (with a full D GUI toolkit being something that might happen 
once D is much larger). But anyone who wants to work on a GUI toolkit in D is 
welcome to do it. IIRC, there was at least one small one done in D1 using 
OpenGL. And having at least a minimal one so that very basic GUIs could be 
written fully in D would certainly be very cool.

Personally, I have too much other stuff to do and not very much expertise in 
this area, so it's the sort of thing that I'm very unlikely to be involved in 
and am likely to leave most of the decisions up to others who are much more 
versed in this sort of thing.

- Jonathan M Davis
May 19 2013
parent "Tyler Jameson Little" <beatgammit gmail.com> writes:
 It's come up before, and I don't think that any sort of 
 decision has ever been
 made on that, though personally, that strikes me as the sort of 
 thing that
 doesn't really belong in the standard library. Certainly, if it 
 did end up in
 there, it would probably have to be very minamalistic.


That's exactly what I want, something to build off of. I'm 
thinking modeling it on Clutter or something like this: 
http://swtch.com/~rsc/thread/cws.pdf. The link is to a simple, 
nested windowing system that serves as the basic architecture of 
the Plan9 GUI. It's super simple and flexible. Everything would 
be asynchronous, and only the most essential components would be 
provided.


 Also, I thought that general consensus had been that while it 
 would be awesome
 to have a GUI toolkit written in D at some point, that's the 
 sort of thing
 that takes a ton of time and effort, and we have enough other 
 stuff that needs
 doing that the time and effort of the community was better 
 spent on other
 things and that wrapping a C++ GUI toolkit was a better move 
 for the
 forseeable future (with a full D GUI toolkit being something 
 that might happen
 once D is much larger). But anyone who wants to work on a GUI 
 toolkit in D is
 welcome to do it. IIRC, there was at least one small one done 
 in D1 using
 OpenGL. And having at least a minimal one so that very basic 
 GUIs could be
 written fully in D would certainly be very cool.


That's the feeling I got. If it's designed well, it might be one 
of the major things that draws people to D, and everyone would 
benefit from that.

I'm willing to work on one, but I don't want to duplicate effort 
if the community is already standardizing on something. I ran 
into that earlier when I tried to expand std.json, only to find 
out that a std.serialize was in the works, hence the question.

I can't say I'm an expert, but I've got a little extra time and I 
want to eventually build a game in D, and I need something to 
build off of.
May 19 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-05-20 07:25, Tyler Jameson Little wrote:

 I've been looking into trying to fix QtD, but it seems writing a binding
 to a C++ library is a bit complicated. I've read on the forums that a
 native D GUI toolkit is the most desirable long-term, so I'd like to
 start that discussion.

 First off, I've heard of the DWT project, which looks promising, but it
 seems like a direct port of Java's SWT instead of a reimagining using
 idiomatic D. I understand the allure here (works, little translation for
 new developers), but since it's not yet in Phobos, I can only assume
 it's still up for discussion.

 Personally, I want these features:

 * simple and extensible
    * minimal components (something like HTMLs feature-set)
    * custom components (embed OpenGL/direct frame buffer)
 * "native" window decorations by default, but can provide custom
 decorations
 * markup (like QML) or programmable (like SWT)

 Nice-to-haves:

 * hardware accelerated (2D OpenGL)
 * GUI designer (much easier with QML-esque markup)
 * part of Phobos

 I'm willing to lend a hand, but I'd like to know in what direction the
 community would like to go. I'd also like to know the likelihood of
 getting a GUI toolkit into Phobos.

 Thoughts?


Creating a new GUI toolkit is a huge amount of work. It's more than you 
can imagine. A GUI toolkit for creating a window with a button isn't 
that much work. But it's all the rest of the stuff, that a toolkit can 
do and people will expect from it. Like stuff you didn't think of or 
even didn't know they existed.

A GUI toolkit in Phobos will probably not happen.

-- 
/Jacob Carlborg
May 19 2013
prev sibling next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Tyler Jameson Little" <beatgammit gmail.com> wrote in message 
news:vtaufckbpdkpuxyztyoi forum.dlang.org...

 I've been looking into trying to fix QtD, but it seems writing a binding 
 to a C++ library is a bit complicated. I've read on the forums that a 
 native D GUI toolkit is the most desirable long-term, so I'd like to start 
 that discussion.

 [snip]

 Thoughts?


I don't know much about Qt's source, but automatic conversion to D, like we 
are doing for the compiler, might be worth looking into.  If it is written 
in modern-ish C++ (not too many preprocessor hacks), which from a quick look 
it appears to be, this might be a much more reasonable task than writing a 
new gui lib from scratch.
May 20 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, May 21, 2013 03:33:01 Daniel Murphy wrote:

 I don't know much about Qt's source, but automatic conversion to D, like we
 are doing for the compiler, might be worth looking into. If it is written
 in modern-ish C++ (not too many preprocessor hacks), which from a quick look
 it appears to be, this might be a much more reasonable task than writing a
 new gui lib from scratch.


IIRC, they use macros quite a bit for various stuff (like signals and slots), 
and they have their own version of make to set up some stuff for you. So, my 
first guess is that conversion would be a bit of a beast. But it's been a while 
since I did much with Qt.

- Jonathan M Davis
May 20 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-05-20 19:42, Jonathan M Davis wrote:


 IIRC, they use macros quite a bit for various stuff (like signals and slots),
 and they have their own version of make to set up some stuff for you. So, my
 first guess is that conversion would be a bit of a beast. But it's been a while
 since I did much with Qt.


They have (or used to have) a special compiler to collect metadata used 
for reflection and similar.

-- 
/Jacob Carlborg
May 20 2013
prev sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.1428.1369071743.4724.digitalmars-d puremagic.com...

 On Tuesday, May 21, 2013 03:33:01 Daniel Murphy wrote:

 I don't know much about Qt's source, but automatic conversion to D, like 
 we
 are doing for the compiler, might be worth looking into. If it is written
 in modern-ish C++ (not too many preprocessor hacks), which from a quick 
 look
 it appears to be, this might be a much more reasonable task than writing 
 a
 new gui lib from scratch.


 IIRC, they use macros quite a bit for various stuff (like signals and 
 slots),
 and they have their own version of make to set up some stuff for you. So, 
 my
 first guess is that conversion would be a bit of a beast. But it's been a 
 while
 since I did much with Qt.

 - Jonathan M Davis


If the macro can be easily converted to a mixin or function call, it usually 
isn't too bad.  It's when the code is not even close to valid c++ (COM class 
definitions spring to mind) that things get tricky.

eg
#define INC(x) do { (x)++; } while(0)
is fine as it can be translated to a function call, but
#define BEGIN {
is a huge problem, because it won't parse.

Even if the macros are hairy, so long as there are a relatively small 
number, they can be special cased.

Qt's special preprocessor is a whole other story, but hopefully that can be 
emulated somewhat in D code.  Requiring a template mixin per Qt class is not 
too big a deal.
May 21 2013
prev sibling next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Sun, 19 May 2013 22:25:49 -0700, Tyler Jameson Little  
<beatgammit gmail.com> wrote:


 I've been looking into trying to fix QtD, but it seems writing a binding  
 to a C++ library is a bit complicated. I've read on the forums that a  
 native D GUI toolkit is the most desirable long-term, so I'd like to  
 start that discussion.

 First off, I've heard of the DWT project, which looks promising, but it  
 seems like a direct port of Java's SWT instead of a reimagining using  
 idiomatic D. I understand the allure here (works, little translation for  
 new developers), but since it's not yet in Phobos, I can only assume  
 it's still up for discussion.

 Personally, I want these features:

 * simple and extensible
    * minimal components (something like HTMLs feature-set)
    * custom components (embed OpenGL/direct frame buffer)
 * "native" window decorations by default, but can provide custom  
 decorations
 * markup (like QML) or programmable (like SWT)

 Nice-to-haves:

 * hardware accelerated (2D OpenGL)
 * GUI designer (much easier with QML-esque markup)
 * part of Phobos

 I'm willing to lend a hand, but I'd like to know in what direction the  
 community would like to go. I'd also like to know the likelihood of  
 getting a GUI toolkit into Phobos.

 Thoughts?


So I've been around D a while pushing for native D UI toolkit. And here  
are a few trends I've seen in the community.

* There is a deep-seated distrust of any toolkit that does not use the OS  
Native UI widgets. The people in this community prefer native toolkits to  
the point of jihad. Now I am a XAML guy myself, and I saw the light a long  
time ago, but around here, the majority are still command line gurus.
* There is absolutely no chance of inclusion in Phobos, and to-be-honest I  
don't think it really belongs there. GUI toolkits are too use-case  
specific to belong in a standard library. However, if we can make (and I  
think we can) a truly cross-platform UI toolkit, we can make a stronger  
case for using at a standard UI toolkit.
* Nobody believes that we can do it, you'll hear a lot of moaning about  
how much work it is. My reply to that is: And Linux is such a piece of  
cake right? It's only the most widely used kernel on the planet.

Here's the deal. Building a GUI toolkit, particularly a useful one, is a  
massive undertaking. WPF is the single largest library in all of .NET.  
IIRC it weighs in at 40,000 classes. Building a UI toolkit in D will  
require something that D itself does not. A highly dedicated team of  
people with many diverse skills. The project is simply too big for a  
single person.

Part of the problem with UI toolkits is the number of skills you'll need  
for the team. Graphics programmers who can make GPU's sing, API designers  
who can make it easy access, UI designers capable of replicating the looks  
of each OS. Experts for each targeted OS. And I can think of more.

My point here is not to be discouraging, I want a UI toolkit with  
capabilities similar to WPF in D probably more than anybody else here. But  
I want to be realistic about the effort required. The dedication required  
is immense, you'll be writing code for months before you even get anything  
on the screen.

Here is another factor to consider. A UI toolkit must be designed. You  
won't have the luxury of Phobos of design-by-iteration simply because  
you'll be throwing out entire systems. For example a fairly complete  
render path is required before you can show anything on the screen. But  
what happens when your render-path is too OS specific? Oops, you pitch  
months of work and start over from scratch. But now you have to rebuild  
everything you've built on top of it. Do that a few times and you'll give  
up because you can never seem to get anywhere. The smart thing to do is  
sit down with a knowledgeable group of people and design the system, the  
design doesn't have to be perfect or complete, but it does need to provide  
a framework to work within and vision to guide the team.

Lastly, we'll need something that D doesn't have much of, but Linux does.  
Leadership. You can't pull together something this complex without someone  
or someones holding the bigger picture in their heads, otherwise you'll  
end up with a mish-mash of contradictory merged pulled requests.

In my experience in Open-Source, it's never a problem to find people who  
have vision and want to lead a project. The problem is finding people who  
agree with the vision enough to help without wanting to be in charge  
because they really know better. FOSS's major drawback is the ridiculous  
amounts of duplication. I don't see a WPF-style UI toolkit as duplication  
because as near as I can tell there is nothing like WPF in the OSS world,  
but, everybody has their own opinion about HOW it should be done and  
almost nobody is willing to swallow their ego, quit sweating the small  
stuff, and work towards a common goal, even if they don't agree 100%.

A UI toolkit in D would be a fantastic showcase for demonstrating just how  
powerful D is. But make no mistake, it will not be easy getting it done.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 20 May 2013 11:01:35 -0700
"Adam Wilson" <flyboynw gmail.com> wrote:

 
 Graphics programmers who can make GPU's sing,


[...]

 UI designers capable of replicating the looks [REPLYER'S EDIT: "and
 feel"] of each OS.
 


Embrace native and those two concerns disappear.

And that latter of those two is *NEVER* going to be pulled off
successfully with a non-native toolkit anyway.
May 20 2013
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 12:09:47 -0700, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:


 On Mon, 20 May 2013 11:01:35 -0700
 "Adam Wilson" <flyboynw gmail.com> wrote:

 Graphics programmers who can make GPU's sing,


 [...]

 UI designers capable of replicating the looks [REPLYER'S EDIT: "and
 feel"] of each OS.


 Embrace native and those two concerns disappear.

 And that latter of those two is *NEVER* going to be pulled off
 successfully with a non-native toolkit anyway.


Demonstrably untrue. Windows Aero in WinForms (native OS widgets) and WPF  
(retained mode GPU rendering) are pixel identical. Only way to tell the  
difference is if it doesn't use the default (native) styling. Nick, I work  
exclusively in WPF/XAML all day every day at work, but the last app I  
wrote was WinForms, what's your experience?

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 20 May 2013 12:28:09 -0700
"Adam Wilson" <flyboynw gmail.com> wrote:


 On Mon, 20 May 2013 12:09:47 -0700, Nick Sabalausky  
 <SeeWebsiteToContactMe semitwist.com> wrote:
 

 On Mon, 20 May 2013 11:01:35 -0700
 "Adam Wilson" <flyboynw gmail.com> wrote:

 Graphics programmers who can make GPU's sing,


 [...]

 UI designers capable of replicating the looks [REPLYER'S EDIT: "and
 feel"] of each OS.


 Embrace native and those two concerns disappear.

 And that latter of those two is *NEVER* going to be pulled off
 successfully with a non-native toolkit anyway.


 
 Demonstrably untrue. Windows Aero in WinForms (native OS widgets) and
 WPF (retained mode GPU rendering) are pixel identical. Only way to
 tell the difference is if it doesn't use the default (native)
 styling. Nick, I work exclusively in WPF/XAML all day every day at
 work, but the last app I wrote was WinForms, what's your experience?
 


WPF/XAML is first-party, therefore it's native by definition
regardless of whether or not it internally hands off to the older UI
code. Saying WPF isn't native is like saying that Quartz isn't native
just because it doesn't use...uhh, whatever the UI was called in Mac OS
9.

Besides, having access to all of MS's internal code, documents,
probably even some of the original developers still around, etc., is
naturally going to change the feasibility in a way that no third party
toolkit (which is exactly what we're talking about here) is
realistically going to be able to match.

In other words, despite your antagonism, I was implicitly **agreeing**
with your assertion that it's one a hell of an undertaking,
*especially* if you don't make use of native APIs under-the-hood.
May 20 2013
next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 12:52:39 -0700, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:


 On Mon, 20 May 2013 12:28:09 -0700
 "Adam Wilson" <flyboynw gmail.com> wrote:


 On Mon, 20 May 2013 12:09:47 -0700, Nick Sabalausky
 <SeeWebsiteToContactMe semitwist.com> wrote:


 On Mon, 20 May 2013 11:01:35 -0700
 "Adam Wilson" <flyboynw gmail.com> wrote:

 Graphics programmers who can make GPU's sing,


 [...]

 UI designers capable of replicating the looks [REPLYER'S EDIT: "and
 feel"] of each OS.


 Embrace native and those two concerns disappear.

 And that latter of those two is *NEVER* going to be pulled off
 successfully with a non-native toolkit anyway.


 Demonstrably untrue. Windows Aero in WinForms (native OS widgets) and
 WPF (retained mode GPU rendering) are pixel identical. Only way to
 tell the difference is if it doesn't use the default (native)
 styling. Nick, I work exclusively in WPF/XAML all day every day at
 work, but the last app I wrote was WinForms, what's your experience?


 WPF/XAML is first-party, therefore it's native by definition
 regardless of whether or not it internally hands off to the older UI
 code. Saying WPF isn't native is like saying that Quartz isn't native
 just because it doesn't use...uhh, whatever the UI was called in Mac OS
 9.


It's first party only insofar as it's Microsoft, but that's where it ends.  
WPF is DevDiv, Win32 (i.e. WinForms) is WinDiv, being completely separate  
divisions at a company like MS means they might as well be separate  
companies. And your Mac OS 9 analogy would be correct about the  
Win32/WinRT differences, but not WPF. WPF exists completely outside the  
scope of the OS.


 Besides, having access to all of MS's internal code, documents,
 probably even some of the original developers still around, etc., is
 naturally going to change the feasibility in a way that no third party
 toolkit (which is exactly what we're talking about here) is
 realistically going to be able to match.


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.


 In other words, despite your antagonism, I was implicitly **agreeing**
 with your assertion that it's one a hell of an undertaking,
 *especially* if you don't make use of native APIs under-the-hood.


Now that I think we all agree on. It is hard, but I think it might  
actually be more difficult to create a unified (standard) library on top  
of the native toolkits for each OS supported in Phobos. The OS  
requirements for a rendered UI such as WPF are actually far fewer,  
basically just a direct connection to the GPU and a windowing mechanism,  
virtually every OS provides those, for example, OpenGL and X. Therefore  
building the amount of shim building required is MUCH smaller.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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

  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.
May 20 2013
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 15:21:22 -0700, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:


 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.


What if as a UI designer I know that I want to specifically disallow  
skinning? It's not even that hard of a decision to reach. If the skinning  
changes the layout metrics at all (margin, padding, size, even shape), my  
app can end up looking terrible and I have to take a support call for a  
case that I couldn't have possibly dreamed up.


 - 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

   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.


I'd say it's on the developers of KatMouse to get their crap together. It  
sounds like their development model is "don't upgrade from WinXP because  
we like that one." By saying that even the MS native changes break it,  
you've kind of invalidated your point. You are telling me that's it not  
really a UI problem but a problem with the tool. Yes, this would be  
completely non-functional in WPF and similar. But I'd stand by the  
statement that it is imprudent to support extreme corner cases. You may  
like it, by I've never even heard of it, and my guess is that almost  
nobody else has either.


 - 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.


Ehrm, TBH, I consider breaking those tools a good thing. Yes there may be  
legitimate uses, but the number if illegitimate uses far exceeds the  
benefit.


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


What is the use case for GUI introspection?


 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.


Manipulating a UI from another process is bad, evil, and a massive  
security problem, I'd say that disallowing it is a service to the world.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 20 May 2013 15:50:06 -0700
"Adam Wilson" <flyboynw gmail.com> wrote:


 On Mon, 20 May 2013 15:21:22 -0700, Nick Sabalausky  
 <SeeWebsiteToContactMe semitwist.com> wrote:
 

 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.


 
 What if as a UI designer I know that I want to specifically disallow  
 skinning? It's not even that hard of a decision to reach. If the
 skinning changes the layout metrics at all (margin, padding, size,
 even shape), my app can end up looking terrible and I have to take a
 support call for a case that I couldn't have possibly dreamed up.
 


Basing software decisions upon worries of "What if some user shoots
himself and calls our support?" is *always* a bad idea.

The user overrides the developer/designer. Always. The user is the
whole reason for *anything* we do in this field. The user may as well be
God - if they want to do something questionable, we can raise warnings,
but it is *absolutely* not our place to prevent it. As soon as you
start down that route, anything you do becomes a pointess waste that
defeats its own reason for existence.



 - 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

 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.


 
 I'd say it's on the developers of KatMouse to get their crap
 together. It sounds like their development model is "don't upgrade
 from WinXP because we like that one."[...]


You're missing the point:

The point is NOT that "XP -> 7 should be seamless for all software". I
don't believe that, and I would never claim it or deliberately imply it.

The point is that even the most *meticulous* and convincing native
emulation is *still* insufficient (and ultimately a big waste of time).

Should it be the responsibility of the program itself support newer
versions of Win? Obviously. (Unfortunately, KatMouse appears to
be closed-source abandonware, but that's completely beside the point.)

Should it be the responsibility of the program itself to support the
various non-native third-party GUIs just because some
self-important GUI developers didn't feel like playing ball and
decided that *their* internal conveniences were more important than
their users, the very people for whom the all this software exists
in the first place? *Absolutely not*.



 You may like it, by I've never even
 heard of it, and my guess is that almost nobody else has either.
 


popularity != importance
popularity != value
popularity != worthiness

(popularity != a goddamn thing)

It is unreasonable to expect GUI developers or GUI designers to
explicitly support various tools like KatMouse? Absolutely. It is
definitely unreasonable. And that's *exactly* why non-native GUIs are
horrible idea.



 - 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.


 
 Ehrm, TBH, I consider breaking those tools a good thing. Yes there
 may be legitimate uses, but the number if illegitimate uses far
 exceeds the benefit.
 


I strongly disagree:

First of all, there is very little, if any, illegitimate use of this
that doesn't require *at least* as significant a security breach to
have *already* occurred.

Secondly, we're not babysitters or self-appointed police here. To
engage in such a level of control is *already* a very serious breach
of our moral obligations.



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


 
 What is the use case for GUI introspection?
 


Just for example, Spy++ or any similar such developer tool. Or GUI
macros. Those are just off the top of my head. I'm sure people can, and
have, thought of any number of other different uses.


 
 Manipulating a UI from another process is bad, evil, and a massive  
 security problem, I'd say that disallowing it is a service to the
 world.
 


I couldn't disagree more. I don't believe for a second that that's
even the slightest bit different from saying "Using a computer is bad,
evil, and a massive security problem; disallowing them is a service to
the world."

We're not Big Brother and I, for one, refuse to be party to anything
even remotely smelling as such, which is something (ie, "Big Brother")
that I very much believe your views on our responsibilities as
developers *do*, by necessity, constitute.
May 20 2013
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 17:04:40 -0700, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:


 On Mon, 20 May 2013 15:50:06 -0700
 "Adam Wilson" <flyboynw gmail.com> wrote:


 On Mon, 20 May 2013 15:21:22 -0700, Nick Sabalausky
 <SeeWebsiteToContactMe semitwist.com> wrote:


 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.


 What if as a UI designer I know that I want to specifically disallow
 skinning? It's not even that hard of a decision to reach. If the
 skinning changes the layout metrics at all (margin, padding, size,
 even shape), my app can end up looking terrible and I have to take a
 support call for a case that I couldn't have possibly dreamed up.


 Basing software decisions upon worries of "What if some user shoots
 himself and calls our support?" is *always* a bad idea.


Is it though? Because regardless of whether or not they should call me,  
they will, and I will have to spend money to deal with it. Again, I have  
real problems that are clashing with ideology. When that happens the  
engineer in me demands that I address the real problems.


 The user overrides the developer/designer. Always. The user is the
 whole reason for *anything* we do in this field. The user may as well be
 God - if they want to do something questionable, we can raise warnings,
 but it is *absolutely* not our place to prevent it. As soon as you
 start down that route, anything you do becomes a pointess waste that
 defeats its own reason for existence.


Why? The user mostly doesn't care as long as it works and solves their  
problem, I personally spend less and less time customizing my environments  
for two-fold reasons, I have an every growing number of them, and I care  
less and less, just get out of my way and let me work. Don't make me  
decide on a hundred details before I can get started.


 - 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

 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.


 I'd say it's on the developers of KatMouse to get their crap
 together. It sounds like their development model is "don't upgrade
 from WinXP because we like that one."[...]


 You're missing the point:

 The point is NOT that "XP -> 7 should be seamless for all software". I
 don't believe that, and I would never claim it or deliberately imply it.

 The point is that even the most *meticulous* and convincing native
 emulation is *still* insufficient (and ultimately a big waste of time).

 Should it be the responsibility of the program itself support newer
 versions of Win? Obviously. (Unfortunately, KatMouse appears to
 be closed-source abandonware, but that's completely beside the point.)

 Should it be the responsibility of the program itself to support the
 various non-native third-party GUIs just because some
 self-important GUI developers didn't feel like playing ball and
 decided that *their* internal conveniences were more important than
 their users, the very people for whom the all this software exists
 in the first place? *Absolutely not*.



 You may like it, by I've never even
 heard of it, and my guess is that almost nobody else has either.


 popularity != importance
 popularity != value
 popularity != worthiness

 (popularity != a goddamn thing)

 It is unreasonable to expect GUI developers or GUI designers to
 explicitly support various tools like KatMouse? Absolutely. It is
 definitely unreasonable. And that's *exactly* why non-native GUIs are
 horrible idea.



 - 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.


 Ehrm, TBH, I consider breaking those tools a good thing. Yes there
 may be legitimate uses, but the number if illegitimate uses far
 exceeds the benefit.


 I strongly disagree:

 First of all, there is very little, if any, illegitimate use of this
 that doesn't require *at least* as significant a security breach to
 have *already* occurred.

 Secondly, we're not babysitters or self-appointed police here. To
 engage in such a level of control is *already* a very serious breach
 of our moral obligations.


In the real world, yes, we are. You see, it's a small inconvenience known  
as the lawsuit. Specifically that I am legally liable for any and all  
security vulnerabilities within my product. There is case-history going  
back to support this since the dawn of legal systems. It is ironclad,  
ideology will not change it. I consider cross-process of a UI a MAJOR  
security problem because it allows malicious software to modified my  
software in subtle ways that compromise the security of the system. And  
apparently I am not the only one who thinks this way because every mobile  
OS available today does not allow ANY kind of cross-process UI  
manipulation of any kind, going so far as to sandbox each app. Where is  
your outrage over Android or iOS or WinRT or Blackberry or Symbian?


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


 What is the use case for GUI introspection?


 Just for example, Spy++ or any similar such developer tool. Or GUI
 macros. Those are just off the top of my head. I'm sure people can, and
 have, thought of any number of other different uses.


GUI macros work on WPF apps. Snoop does what Spy++ does.


 Manipulating a UI from another process is bad, evil, and a massive
 security problem, I'd say that disallowing it is a service to the
 world.


 I couldn't disagree more. I don't believe for a second that that's
 even the slightest bit different from saying "Using a computer is bad,
 evil, and a massive security problem; disallowing them is a service to
 the world."

 We're not Big Brother and I, for one, refuse to be party to anything
 even remotely smelling as such, which is something (ie, "Big Brother")
 that I very much believe your views on our responsibilities as
 developers *do*, by necessity, constitute.


Have you ever built any software where you are legally liable for any  
security holes your software opens up? My guess is no. Because if you had,  
you'd get where I am coming from.

Ideology is fine, right up until you have to meet the real world. Do you  
honestly expect your users to each become security experts? Such a thought  
is laughable on the face of it. They have neither the time nor the  
interest, and nor should they, it is not a productive use of their time.  
This is why the law makes it MY fault for security flaws, because there is  
not, and can be no, reasonable expectation that they are security experts,  
that's MY job.

Ergo, allowing cross-process UI manipulation is inherently wrong, it's  
also legally and ethically wrong.  Putting my users at risk in the name of  
ideology is so wrong that I am dry heaving at the thought. Incidentally,  
this is why no mobile OS ever allows it, it's WAY to legally risky. Not  
even Google can make that lawsuit go away.


Nick, I hate to break it to you, but you are so far out on the extreme end  
of the scale on this one that it will be impossible to advance technology  
and keep you happy, so I'll have to leave you behind, because the 99% want  
there software to just work, and could care less how it does it. I don't  
like leaving people behind and pissing them off, but I have to go where  
the majority goes, otherwise I'm just a penniless artist with a rigid  
ideology and no friends.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
next sibling parent reply "Diggory" <diggsey googlemail.com> writes:
On Tuesday, 21 May 2013 at 02:47:59 UTC, Adam Wilson wrote:

 could care less


http://www.youtube.com/watch?v=om7O0MFkmpw

Sorry...
May 20 2013
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 21 May 2013 05:26:29 +0200
"Diggory" <diggsey googlemail.com> wrote:


 On Tuesday, 21 May 2013 at 02:47:59 UTC, Adam Wilson wrote:

 could care less


 
 http://www.youtube.com/watch?v=om7O0MFkmpw
 
 Sorry...


Yes! I've been pointing that out for years! First time I've ever seen
anyone else address it. And it's hilarious, too.
May 20 2013
prev sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 20:26:29 -0700, Diggory <diggsey googlemail.com> wrote:


 On Tuesday, 21 May 2013 at 02:47:59 UTC, Adam Wilson wrote:

 could care less


 http://www.youtube.com/watch?v=om7O0MFkmpw

 Sorry...


I type quickly but not always accurately, I actually caught that right  
after hitting send.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 20 May 2013 19:48:00 -0700
"Adam Wilson" <flyboynw gmail.com> wrote:


 On Mon, 20 May 2013 17:04:40 -0700, Nick Sabalausky  
 <SeeWebsiteToContactMe semitwist.com> wrote:
 

 On Mon, 20 May 2013 15:50:06 -0700
 "Adam Wilson" <flyboynw gmail.com> wrote:

 What if as a UI designer I know that I want to specifically
 disallow skinning? It's not even that hard of a decision to reach.
 If the skinning changes the layout metrics at all (margin,
 padding, size, even shape), my app can end up looking terrible and
 I have to take a support call for a case that I couldn't have
 possibly dreamed up.


 Basing software decisions upon worries of "What if some user shoots
 himself and calls our support?" is *always* a bad idea.


 
 Is it though? Because regardless of whether or not they should call
 me, they will, and I will have to spend money to deal with it. Again,
 I have real problems that are clashing with ideology. When that
 happens the engineer in me demands that I address the real problems.
 


No, you most certainly do *not* have real problems clashing with
ideology:

What you have is a contrived "what if" scenario that you think is a
"real" threat to your business despite the fact that you yourself are
convinced that hardly anyone is going to be messing with their settings
anyway.

Then you're running around crying "It's ideology versus successful
business! I'd better disregard my user's settings or else the sky will
fall!" Yea, I'm exaggerating, but your whole argument here is clearly
exaggerated bullshit.

And if you're really *are* that worried about enough "coffee mug in the
CD tray"-mentality users changing their system settings and then calling
you about that, enough that it would pull you under, then you can just
*not* invent a new UI styling to force on them in the first place. Big
freaking deal. Like you said, most of them don't care anyway, right?


 
 Why? The user mostly doesn't care as long as it works and solves
 their problem, I personally spend less and less time customizing my
 environments for two-fold reasons, I have an every growing number of
 them, and I care less and less, just get out of my way and let me
 work. Don't make me decide on a hundred details before I can get
 started.
 


Ok. So then why in the world are you wasting *your* time inventing new
UI styles for your software if so few of your users care?



 Secondly, we're not babysitters or self-appointed police here. To
 engage in such a level of control is *already* a very serious breach
 of our moral obligations.


 
 In the real world, yes, we are. You see, it's a small inconvenience
 known as the lawsuit. Specifically that I am legally liable for any
 and all security vulnerabilities within my product. There is
 case-history going back to support this since the dawn of legal
 systems. It is ironclad, ideology will not change it. I consider
 cross-process of a UI a MAJOR security problem because it allows
 malicious software to modified my software in subtle ways that
 compromise the security of the system. And apparently I am not the
 only one who thinks this way because every mobile OS available today
 does not allow ANY kind of cross-process UI manipulation of any kind,
 going so far as to sandbox each app.


I think we're getting offtopic here. If we're associating
"legally-accountable security negligence" together with "using native UI
toolkits", then clearly we've already taken a nose-dive off the deep
end.


 Where is your outrage over
 Android or iOS or WinRT or Blackberry or Symbian?
 


Heh. If you think I *don't* have a deep seething hatred for Android, iOS
and WinRT, on both practical and ethical grounds, then you're very much
mistaken ;)

I don't always agree with Stallman, but one thing I did always agree
completely with him on is how Steve Job's last decade of work was
"the computer as a jail made cool, designed to sever fools from their
freedom". Stallman didn't change my mind with that, but he did word it
far better than I ever could have.



 Just for example, Spy++ or any similar such developer tool. Or GUI
 macros. Those are just off the top of my head. I'm sure people can,
 and have, thought of any number of other different uses.


 
 GUI macros work on WPF apps.


Does the same macro utility system also work across WPF, GTK, Qt,
Delphi apps, whatever the fuck Nero, Winamp or Windows iTunes use,
*and* Joe Schmo's Yet Another NIH-Fueled OpenGL-based Toolkit?



 Snoop does what Spy++ does.
 


Same question as above.


 
 Have you ever built any software where you are legally liable for
 any security holes your software opens up? My guess is no. Because if
 you had, you'd get where I am coming from.
 


Let's not dive into ad-hominem time-wasting here. I'm not going to get
into what really amounts to an "I'm more l33t than you" contest under
the false pretense that the answer has any bearing whatsoever on the
topic at hand.



 Ideology is fine, right up until you have to meet the real world. Do
 you honestly expect your users to each become security experts? Such
 a thought is laughable on the face of it. They have neither the time
 nor the interest, and nor should they, it is not a productive use of
 their time. This is why the law makes it MY fault for security flaws,
 because there is not, and can be no, reasonable expectation that they
 are security experts, that's MY job.


Again, you're taking one thing here and then contorting it into a
mutant, paranoid strawman with only a vague connection to the real
discussion:

1. The ideology of *allowing* the users who *want* control over their
own computer to *have* control over their own computer is *not* in
conflict with "the real world". That's downright crazed paranoia. It's
not going to drown your company in support costs. It's not going to get
you thrown in jail for negligent security. It's not going to eat your
children and destroy family values and make the sky fall. Take a step
back and look at this with some perspective.

2. If this stuff we're talking about constitutes such major security
negligence, then so does damn near every other thing computers ever do.
Almost anything useful that programmers use is every bit as
much exploitable. "Hackers can use functions to help create their
exploits?! Holy hell! We must stop this evil 'function' thing since,
after all, legitimate software can just use GOTO!" Or: "Your address
book software lets me put in all that sensitive info?! How dare you!
That means anyone who grabs my phone while I have it unlocked has easy
access to it! I'll sue you!" For fuck's sake, everything useful is
exploitable. Let's go back to our caves. (Oh shit! Rocks!)

3. Where in the would did you pull this "expect your users to each
become security experts" crap from in the first place? That came
completely out of nowhere.


 
 Ergo, allowing cross-process UI manipulation is inherently wrong,
 it's also legally and ethically wrong.  Putting my users at risk in
 the name of ideology is so wrong that I am dry heaving at the
 thought.


Better make sure the cops never find out if you've used Snoop or GUI
macros. Or Tcl Expect. Or a debugger. Or stdin/stdout. Or...



 Incidentally, this is why no mobile OS ever allows it, it's
 WAY to legally risky. Not even Google can make that lawsuit go away.
 


I'm seeing an unsubstantiated claim here.


 
 Nick, I hate to break it to you, but you are so far out on the
 extreme end of the scale on this one that it will be impossible to
 advance technology and keep you happy,


As opposed to being so far out in paranoia that it'll be impossible
for you to use or create technology at all and still feel safe and
secure from lawsuits, support call stampedes, black hats...You really
are a nut here.


 so I'll have to leave you
 behind, because the 99% want there software to just work, and could
 care less how it does it. I don't like leaving people behind and
 pissing them off, but I have to go where the majority goes,


Ok, I understood. Ideals result in lawsuit, and so does failing to
chase trends. Ok, gotcha. Back to your padded room...Don't forget your
tinfoil hat over there...


 otherwise
 I'm just a penniless artist with a rigid ideology and no friends.
 


You just can't help using all these slipperly slope arguments, can
you? Besides, I'm guessing that paranoia doesn't help win friends and
money either.
May 20 2013
parent "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 22:00:39 -0700, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:


 On Mon, 20 May 2013 19:48:00 -0700
 "Adam Wilson" <flyboynw gmail.com> wrote:


 On Mon, 20 May 2013 17:04:40 -0700, Nick Sabalausky
 <SeeWebsiteToContactMe semitwist.com> wrote:


 On Mon, 20 May 2013 15:50:06 -0700
 "Adam Wilson" <flyboynw gmail.com> wrote:

 What if as a UI designer I know that I want to specifically
 disallow skinning? It's not even that hard of a decision to reach.
 If the skinning changes the layout metrics at all (margin,
 padding, size, even shape), my app can end up looking terrible and
 I have to take a support call for a case that I couldn't have
 possibly dreamed up.


 Basing software decisions upon worries of "What if some user shoots
 himself and calls our support?" is *always* a bad idea.


 Is it though? Because regardless of whether or not they should call
 me, they will, and I will have to spend money to deal with it. Again,
 I have real problems that are clashing with ideology. When that
 happens the engineer in me demands that I address the real problems.


 No, you most certainly do *not* have real problems clashing with
 ideology:

 What you have is a contrived "what if" scenario that you think is a
 "real" threat to your business despite the fact that you yourself are
 convinced that hardly anyone is going to be messing with their settings
 anyway.

 Then you're running around crying "It's ideology versus successful
 business! I'd better disregard my user's settings or else the sky will
 fall!" Yea, I'm exaggerating, but your whole argument here is clearly
 exaggerated bullshit.

 And if you're really *are* that worried about enough "coffee mug in the
 CD tray"-mentality users changing their system settings and then calling
 you about that, enough that it would pull you under, then you can just
 *not* invent a new UI styling to force on them in the first place. Big
 freaking deal. Like you said, most of them don't care anyway, right?


I didn't think we were talking about styling but about cross-process UI  
manipulation, styling isn't a security threat as you've correctly pointed  
out, but allowing other processes to manipulate a UI, is, otherwise all  
new native UI toolkit's allow it. Last I checked none of the mobile OS's  
do. WinRT on Win8 does not either. I'd say the trend is away from  
cross-process UI manipulation, not towards


 Why? The user mostly doesn't care as long as it works and solves
 their problem, I personally spend less and less time customizing my
 environments for two-fold reasons, I have an every growing number of
 them, and I care less and less, just get out of my way and let me
 work. Don't make me decide on a hundred details before I can get
 started.


 Ok. So then why in the world are you wasting *your* time inventing new
 UI styles for your software if so few of your users care?



 Secondly, we're not babysitters or self-appointed police here. To
 engage in such a level of control is *already* a very serious breach
 of our moral obligations.


 In the real world, yes, we are. You see, it's a small inconvenience
 known as the lawsuit. Specifically that I am legally liable for any
 and all security vulnerabilities within my product. There is
 case-history going back to support this since the dawn of legal
 systems. It is ironclad, ideology will not change it. I consider
 cross-process of a UI a MAJOR security problem because it allows
 malicious software to modified my software in subtle ways that
 compromise the security of the system. And apparently I am not the
 only one who thinks this way because every mobile OS available today
 does not allow ANY kind of cross-process UI manipulation of any kind,
 going so far as to sandbox each app.


 I think we're getting offtopic here. If we're associating
 "legally-accountable security negligence" together with "using native UI
 toolkits", then clearly we've already taken a nose-dive off the deep
 end.


 Where is your outrage over
 Android or iOS or WinRT or Blackberry or Symbian?


 Heh. If you think I *don't* have a deep seething hatred for Android, iOS
 and WinRT, on both practical and ethical grounds, then you're very much
 mistaken ;)

 I don't always agree with Stallman, but one thing I did always agree
 completely with him on is how Steve Job's last decade of work was
 "the computer as a jail made cool, designed to sever fools from their
 freedom". Stallman didn't change my mind with that, but he did word it
 far better than I ever could have.



 Just for example, Spy++ or any similar such developer tool. Or GUI
 macros. Those are just off the top of my head. I'm sure people can,
 and have, thought of any number of other different uses.


 GUI macros work on WPF apps.


 Does the same macro utility system also work across WPF, GTK, Qt,
 Delphi apps, whatever the fuck Nero, Winamp or Windows iTunes use,
 *and* Joe Schmo's Yet Another NIH-Fueled OpenGL-based Toolkit?



 Snoop does what Spy++ does.


 Same question as above.


 Have you ever built any software where you are legally liable for
 any security holes your software opens up? My guess is no. Because if
 you had, you'd get where I am coming from.


 Let's not dive into ad-hominem time-wasting here. I'm not going to get
 into what really amounts to an "I'm more l33t than you" contest under
 the false pretense that the answer has any bearing whatsoever on the
 topic at hand.


I wasn't intended on starting a pissing contest, I was merely pointing out  
a legitimate concern. It may be ad hominem and for that I do apologize.


 Ideology is fine, right up until you have to meet the real world. Do
 you honestly expect your users to each become security experts? Such
 a thought is laughable on the face of it. They have neither the time
 nor the interest, and nor should they, it is not a productive use of
 their time. This is why the law makes it MY fault for security flaws,
 because there is not, and can be no, reasonable expectation that they
 are security experts, that's MY job.


 Again, you're taking one thing here and then contorting it into a
 mutant, paranoid strawman with only a vague connection to the real
 discussion:

 1. The ideology of *allowing* the users who *want* control over their
 own computer to *have* control over their own computer is *not* in
 conflict with "the real world". That's downright crazed paranoia. It's
 not going to drown your company in support costs. It's not going to get
 you thrown in jail for negligent security. It's not going to eat your
 children and destroy family values and make the sky fall. Take a step
 back and look at this with some perspective.

 2. If this stuff we're talking about constitutes such major security
 negligence, then so does damn near every other thing computers ever do.
 Almost anything useful that programmers use is every bit as
 much exploitable. "Hackers can use functions to help create their
 exploits?! Holy hell! We must stop this evil 'function' thing since,
 after all, legitimate software can just use GOTO!" Or: "Your address
 book software lets me put in all that sensitive info?! How dare you!
 That means anyone who grabs my phone while I have it unlocked has easy
 access to it! I'll sue you!" For fuck's sake, everything useful is
 exploitable. Let's go back to our caves. (Oh shit! Rocks!)

 3. Where in the would did you pull this "expect your users to each
 become security experts" crap from in the first place? That came
 completely out of nowhere.


 Ergo, allowing cross-process UI manipulation is inherently wrong,
 it's also legally and ethically wrong.  Putting my users at risk in
 the name of ideology is so wrong that I am dry heaving at the
 thought.


 Better make sure the cops never find out if you've used Snoop or GUI
 macros. Or Tcl Expect. Or a debugger. Or stdin/stdout. Or...



 Incidentally, this is why no mobile OS ever allows it, it's
 WAY to legally risky. Not even Google can make that lawsuit go away.


 I'm seeing an unsubstantiated claim here.


 Nick, I hate to break it to you, but you are so far out on the
 extreme end of the scale on this one that it will be impossible to
 advance technology and keep you happy,


 As opposed to being so far out in paranoia that it'll be impossible
 for you to use or create technology at all and still feel safe and
 secure from lawsuits, support call stampedes, black hats...You really
 are a nut here.


 so I'll have to leave you
 behind, because the 99% want there software to just work, and could
 care less how it does it. I don't like leaving people behind and
 pissing them off, but I have to go where the majority goes,


 Ok, I understood. Ideals result in lawsuit, and so does failing to
 chase trends. Ok, gotcha. Back to your padded room...Don't forget your
 tinfoil hat over there...


 otherwise
 I'm just a penniless artist with a rigid ideology and no friends.


 You just can't help using all these slipperly slope arguments, can
 you? Besides, I'm guessing that paranoia doesn't help win friends and
 money either.



-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-05-20 21:52, Nick Sabalausky wrote:


 WPF/XAML is first-party, therefore it's native by definition
 regardless of whether or not it internally hands off to the older UI
 code. Saying WPF isn't native is like saying that Quartz isn't native
 just because it doesn't use...uhh, whatever the UI was called in Mac OS
 9.

 Besides, having access to all of MS's internal code, documents,
 probably even some of the original developers still around, etc., is
 naturally going to change the feasibility in a way that no third party
 toolkit (which is exactly what we're talking about here) is
 realistically going to be able to match.

 In other words, despite your antagonism, I was implicitly **agreeing**
 with your assertion that it's one a hell of an undertaking,
 *especially* if you don't make use of native APIs under-the-hood.


I completely agree.

-- 
/Jacob Carlborg
May 20 2013
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
20-May-2013 22:01, Adam Wilson пишет:

 On Sun, 19 May 2013 22:25:49 -0700, Tyler Jameson Little
 <beatgammit gmail.com> wrote:


 I've been looking into trying to fix QtD, but it seems writing a
 binding to a C++ library is a bit complicated. I've read on the forums
 that a native D GUI toolkit is the most desirable long-term, so I'd
 like to start that discussion.

 First off, I've heard of the DWT project, which looks promising, but
 it seems like a direct port of Java's SWT instead of a reimagining
 using idiomatic D. I understand the allure here (works, little
 translation for new developers), but since it's not yet in Phobos, I
 can only assume it's still up for discussion.

 Personally, I want these features:

 * simple and extensible
    * minimal components (something like HTMLs feature-set)
    * custom components (embed OpenGL/direct frame buffer)
 * "native" window decorations by default, but can provide custom
 decorations
 * markup (like QML) or programmable (like SWT)

 Nice-to-haves:

 * hardware accelerated (2D OpenGL)
 * GUI designer (much easier with QML-esque markup)
 * part of Phobos

 I'm willing to lend a hand, but I'd like to know in what direction the
 community would like to go. I'd also like to know the likelihood of
 getting a GUI toolkit into Phobos.

 Thoughts?


 So I've been around D a while pushing for native D UI toolkit. And here
 are a few trends I've seen in the community.

 * There is a deep-seated distrust of any toolkit that does not use the
 OS Native UI widgets. The people in this community prefer native
 toolkits to the point of jihad.


It's just one crazy Nick ;)


 Now I am a XAML guy myself, and I saw
 the light a long time ago, but around here, the majority are still
 command line gurus.


Markup for GUI layout seems like a decent idea.


 * There is absolutely no chance of inclusion in Phobos, and to-be-honest
 I don't think it really belongs there.


Where you take that from? I thought it was quite the opposite if written 
in D. Even C++ guys seem interested in GUIs in std library(!)

[snip]


 * Nobody believes that we can do it, you'll hear a lot of moaning about
 how much work it is. My reply to that is: And Linux is such a piece of
 cake right? It's only the most widely used kernel on the planet.


If anything D community is full of people doing things close to 
impossible (esp given the limited spare time and other constraints).


 Here's the deal. Building a GUI toolkit, particularly a useful one, is a
 massive undertaking. WPF is the single largest library in all of .NET.
 IIRC it weighs in at 40,000 classes. Building a UI toolkit in D will
 require something that D itself does not. A highly dedicated team of
 people with many diverse skills. The project is simply too big for a
 single person.



OOP code could help here.

 Part of the problem with UI toolkits is the number of skills you'll need
 for the team. Graphics programmers who can make GPU's sing, API
 designers who can make it easy access, UI designers capable of
 replicating the looks of each OS. Experts for each targeted OS. And I
 can think of more.


Well, then you'll also become an expert in a couple of cool fields ;)
Seriously a few helping hands are sorely needed.

[snip other good points]


 A UI toolkit in D would be a fantastic showcase for demonstrating just
 how powerful D is. But make no mistake, it will not be easy getting it
 done.



-- 
Dmitry Olshansky
May 20 2013
next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 12:28:16 -0700, Dmitry Olshansky  =

<dmitry.olsh gmail.com> wrote:


 20-May-2013 22:01, Adam Wilson =D0=BF=D0=B8=D1=88=D0=B5=D1=82:

 On Sun, 19 May 2013 22:25:49 -0700, Tyler Jameson Little
 <beatgammit gmail.com> wrote:


 I've been looking into trying to fix QtD, but it seems writing a
 binding to a C++ library is a bit complicated. I've read on the foru=






ms

 that a native D GUI toolkit is the most desirable long-term, so I'd
 like to start that discussion.

 First off, I've heard of the DWT project, which looks promising, but=







 it seems like a direct port of Java's SWT instead of a reimagining
 using idiomatic D. I understand the allure here (works, little
 translation for new developers), but since it's not yet in Phobos, I=







 can only assume it's still up for discussion.

 Personally, I want these features:

 * simple and extensible
    * minimal components (something like HTMLs feature-set)
    * custom components (embed OpenGL/direct frame buffer)
 * "native" window decorations by default, but can provide custom
 decorations
 * markup (like QML) or programmable (like SWT)

 Nice-to-haves:

 * hardware accelerated (2D OpenGL)
 * GUI designer (much easier with QML-esque markup)
 * part of Phobos

 I'm willing to lend a hand, but I'd like to know in what direction t=






he

 community would like to go. I'd also like to know the likelihood of
 getting a GUI toolkit into Phobos.

 Thoughts?


 So I've been around D a while pushing for native D UI toolkit. And he=




re

 are a few trends I've seen in the community.

 * There is a deep-seated distrust of any toolkit that does not use th=




e

 OS Native UI widgets. The people in this community prefer native
 toolkits to the point of jihad.


 It's just one crazy Nick ;)


Well, there are a couple vocal others.


 Now I am a XAML guy myself, and I saw
 the light a long time ago, but around here, the majority are still
 command line gurus.


 Markup for GUI layout seems like a decent idea.


HTML is markup. XAML is markup. QML is markup. XUL is markup. iOS is  =

markup. Android is markup. Realistically, the age of OS native toolkits =
 =

has passed, markup is the future. *shrug* For me it's a practical thing,=
  =

markup is extensible, OS widgets are not.


 * There is absolutely no chance of inclusion in Phobos, and to-be-hon=




est

 I don't think it really belongs there.


 Where you take that from? I thought it was quite the opposite if writt=


en  =


 in D. Even C++ guys seem interested in GUIs in std library(!)

 [snip]


I would LOVE to see it included in Phobos, but making it multi-platform =
 =

places an pretty hard requirement that it not be OS native widgets, some=
  =

OS's have widgets that others don't, some OS's have incompatible UI  =

declaration models, for example: WinForms is Win23 API calls where iOS i=
s  =

markup. It is workable, but it is even MORE work than building a GPU bas=
ed  =

UI toolkit from scratch. How big is Qt compared to WPF?


 * Nobody believes that we can do it, you'll hear a lot of moaning abo=




ut

 how much work it is. My reply to that is: And Linux is such a piece o=




f

 cake right? It's only the most widely used kernel on the planet.


 If anything D community is full of people doing things close to  =



 impossible (esp given the limited spare time and other constraints).


Agreed. But as soon as you bring up UI toolkits then it's too much, it's=
  =

impossible, it makes no sense, etc, etc, etc. That's kind of my point, D=
  =

takes the "impossible" and makes is merely difficult.


 Here's the deal. Building a GUI toolkit, particularly a useful one, i=




s a

 massive undertaking. WPF is the single largest library in all of .NET=




.

 IIRC it weighs in at 40,000 classes. Building a UI toolkit in D will
 require something that D itself does not. A highly dedicated team of
 people with many diverse skills. The project is simply too big for a
 single person.





  =


 OOP code could help here.


You have no idea...


 Part of the problem with UI toolkits is the number of skills you'll n=




eed

 for the team. Graphics programmers who can make GPU's sing, API
 designers who can make it easy access, UI designers capable of
 replicating the looks of each OS. Experts for each targeted OS. And I=





 can think of more.


 Well, then you'll also become an expert in a couple of cool fields ;)
 Seriously a few helping hands are sorely needed.


Absolutely, but my point is that some of those are entire fields of stud=
y  =

and bodies of knowledge that can take years or decades a too acquire. It=
's  =

a bit unrealistic for first time GPU coder to write an efficient shader.=
  =

UI design is a whole field unto itself. Etc. My point here is that no on=
e  =

person has a realistic shot of being able to acquire and maintain the  =

required knowledge single-handedly.


 [snip other good points]


 A UI toolkit in D would be a fantastic showcase for demonstrating jus=




t

 how powerful D is. But make no mistake, it will not be easy getting i=




t

 done.





-- =

Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 20 May 2013 at 19:41:09 UTC, Adam Wilson wrote:

 Well, there are a couple vocal others.


My preference for native stuff is just simply that the 
alternative seems to be reinventing a gigantic wheel.

Though, at the same time, for a while I was playing with the idea 
of using my simple htmlwidget.d as a gui thing. It can only 
handle simple html.... but that does include events, and we can 
get quite a bit done with crappy html. In theory, we could write 
up all kinds of tags and make something out of it.

But I don't do enough gui stuff anymore to worry much about it 
personally.
May 20 2013
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 20 May 2013 12:41:08 -0700
"Adam Wilson" <flyboynw gmail.com> wrote:


 On Mon, 20 May 2013 12:28:16 -0700, Dmitry Olshansky  
 <dmitry.olsh gmail.com> wrote:

 Markup for GUI layout seems like a decent idea.


 
 HTML is markup. XAML is markup. QML is markup. XUL is markup. iOS is  
 markup. Android is markup. Realistically, the age of OS native
 toolkits has passed, markup is the future. *shrug* For me it's a
 practical thing,


And what takes that markup and actually executes it? Magical GUI
fairies? ;)

Markup is, by necessity, nothing more than a front-end for a
code-based GUI engine/toolkit/whatever-we-want-to-call-it. The GUI
toolkits will always be there whether it's the UI designers that use it
directly or the markup developers that use it directly.


markup is extensible, OS widgets are not.
 


I don't know where you got that idea.
May 20 2013
next sibling parent reply Timothee Cour <thelastmammoth gmail.com> writes:
The following will take much less time and can achieve good, native results
quickly:

Design a user-code facing clean api using idiomatic D (front end code):
windows, widgets, callbacks via delegates, etc.
Design a glue layer to talk to different backends: gtkd, wxd, qtd, fltk etc.

This is what python does with matplotlib:
http://matplotlib.org/faq/usage_faq.html : they support pygtk, wxpython,
tkinter, qt, macosx, or fltk, and also non interactive backends)
The user code stays clean, the results are native (depending on backend),
and the wheel is not reimplemented.

On Mon, May 20, 2013 at 1:20 PM, Nick Sabalausky <
SeeWebsiteToContactMe semitwist.com> wrote:


 On Mon, 20 May 2013 12:41:08 -0700
 "Adam Wilson" <flyboynw gmail.com> wrote:


 On Mon, 20 May 2013 12:28:16 -0700, Dmitry Olshansky
 <dmitry.olsh gmail.com> wrote:

 Markup for GUI layout seems like a decent idea.


 HTML is markup. XAML is markup. QML is markup. XUL is markup. iOS is
 markup. Android is markup. Realistically, the age of OS native
 toolkits has passed, markup is the future. *shrug* For me it's a
 practical thing,


 And what takes that markup and actually executes it? Magical GUI
 fairies? ;)

 Markup is, by necessity, nothing more than a front-end for a
 code-based GUI engine/toolkit/whatever-we-want-to-call-it. The GUI
 toolkits will always be there whether it's the UI designers that use it
 directly or the markup developers that use it directly.


markup is extensible, OS widgets are not.


 I don't know where you got that idea.
May 20 2013
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 20 May 2013 13:36:42 -0700
Timothee Cour <thelastmammoth gmail.com> wrote:


 The following will take much less time and can achieve good, native
 results quickly:
 
 Design a user-code facing clean api using idiomatic D (front end
 code): windows, widgets, callbacks via delegates, etc.
 Design a glue layer to talk to different backends: gtkd, wxd, qtd,
 fltk etc.
 
 This is what python does with matplotlib:
 http://matplotlib.org/faq/usage_faq.html : they support pygtk,
 wxpython, tkinter, qt, macosx, or fltk, and also non interactive
 backends) The user code stays clean, the results are native
 (depending on backend), and the wheel is not reimplemented.
 


Yea, that would definitely be my approach, too.
May 20 2013
parent reply "Flamaros" <flamaros.xavier gmail.com> writes:
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 :-).
May 20 2013
parent "Flamaros" <flamaros.xavier gmail.com> writes:
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.
May 20 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-05-20 22:36, Timothee Cour wrote:

 The following will take much less time and can achieve good, native
 results quickly:

 Design a user-code facing clean api using idiomatic D (front end code):
 windows, widgets, callbacks via delegates, etc.
 Design a glue layer to talk to different backends: gtkd, wxd, qtd, fltk etc.

 This is what python does with matplotlib:
 http://matplotlib.org/faq/usage_faq.html : they support pygtk, wxpython,
 tkinter, qt, macosx, or fltk, and also non interactive backends)
 The user code stays clean, the results are native (depending on
 backend), and the wheel is not reimplemented.


That is a huge a mount of work as well. Yes I know, I'm working on DWT. 
Seems a bit unnecessary to support non-native backends? I mean, you will 
get a couple of extra backends. It's more then enough work with the 
native ones.

-- 
/Jacob Carlborg
May 21 2013
prev sibling next sibling parent reply Timothee Cour <thelastmammoth gmail.com> writes:
 The following will take much less time and can achieve good, native
 results quickly:

 Design a user-code facing clean api using idiomatic D (front end code):
 windows, widgets, callbacks via delegates, etc.
 Design a glue layer to talk to different backends: gtkd, wxd, qtd, fltk
 etc.

 This is what python does with matplotlib:
 http://matplotlib.org/faq/usage_faq.html : they support pygtk, wxpython,
 tkinter, qt, macosx, or fltk, and also non interactive backends)
 The user code stays clean, the results are native (depending on backend),
 and the wheel is not reimplemented.


The other advantage of this is we can have results early on (leveraging
existing backends), but nothing prevents us to work in parallel on a
backend that's purely written in D (written on top of opengl for example)
if need be.
May 20 2013
parent "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 13:58:04 -0700, Timothee Cour  
<thelastmammoth gmail.com> wrote:


 The following will take much less time and can achieve good, native
 results quickly:

 Design a user-code facing clean api using idiomatic D (front end code):
 windows, widgets, callbacks via delegates, etc.
 Design a glue layer to talk to different backends: gtkd, wxd, qtd, fltk
 etc.

 This is what python does with matplotlib:
 http://matplotlib.org/faq/usage_faq.html : they support pygtk, wxpython,
 tkinter, qt, macosx, or fltk, and also non interactive backends)
 The user code stays clean, the results are native (depending on  
 backend),
 and the wheel is not reimplemented.


 The other advantage of this is we can have results early on (leveraging
 existing backends), but nothing prevents us to work in parallel on a
 backend that's purely written in D (written on top of opengl for example)
 if need be.


Every design I've discussed with various people in the community relies on  
have a pluggable rendering backend. It's the only sensible way really, the  
best way to custom draw stuff on Windows is DirectX, whereas its OGL on  
Linux/Mac, or OpenGL ES on Android and iOS.

And by going straight for the lowest level of GPU interaction for each  
platform we avoid an extra layer of abstraction in the rendering pipeline,  
which is very performance sensitive.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
prev sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 13:20:22 -0700, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:


 On Mon, 20 May 2013 12:41:08 -0700
 "Adam Wilson" <flyboynw gmail.com> wrote:


 On Mon, 20 May 2013 12:28:16 -0700, Dmitry Olshansky
 <dmitry.olsh gmail.com> wrote:

 Markup for GUI layout seems like a decent idea.


 HTML is markup. XAML is markup. QML is markup. XUL is markup. iOS is
 markup. Android is markup. Realistically, the age of OS native
 toolkits has passed, markup is the future. *shrug* For me it's a
 practical thing,


 And what takes that markup and actually executes it? Magical GUI
 fairies? ;)


Depends on the system, in WPF the XAML is encoded into a binary form of  
XML and then the objects are deserialized at runtime. Note that given D's  
CTFE I would NOT choose this path for any D UI toolkit. D is perfect for a  
system where you use markup to declare your UI in a CTFE manner and then  
have the compiler do the dirty work of actually generating the code. Fast  
AND Simple, Go D!


 Markup is, by necessity, nothing more than a front-end for a
 code-based GUI engine/toolkit/whatever-we-want-to-call-it. The GUI
 toolkits will always be there whether it's the UI designers that use it
 directly or the markup developers that use it directly.


 markup is extensible, OS widgets are not.


 I don't know where you got that idea.


I mean extensible in terms of look or style, sorry for the ambiguity. OS  
widgets require tons of custom coding to change the style, I've done it,  
and I hated every minute of it. But with WPF I don't even think twice, I  
just do it, because I can get the exact style in under an hour.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 20 May 2013 13:58:56 -0700
"Adam Wilson" <flyboynw gmail.com> wrote:


 On Mon, 20 May 2013 13:20:22 -0700, Nick Sabalausky  
 <SeeWebsiteToContactMe semitwist.com> wrote:
 

 On Mon, 20 May 2013 12:41:08 -0700
 "Adam Wilson" <flyboynw gmail.com> wrote:





 markup is extensible, OS widgets are not.


 I don't know where you got that idea.


 
 I mean extensible in terms of look or style, sorry for the ambiguity.


Ahh, ok, I wasn't actually sure exactly what sort of "extensible" you
meant.


 OS widgets require tons of custom coding to change the style, I've
 done it, and I hated every minute of it. But with WPF I don't even
 think twice, I just do it, because I can get the exact style in under
 an hour.
 


Honestly, I'd consider that a major downside: Anything that
helps/encourages developers to disregard a user's system settings
(style or otherwise) is a very bad thing, IMO.

Of course, if the toolkit automatically comes with a
guaranteed user-selectable setting, outside of the app's control, to
optionally disable any custom styling on a per-app or global basis, then
that's the best solution of all: It attracts the "To hell with the
user's system settings because *I* deserve to be in control of my user's
computer" crowd and then uses that to hand control *back* to the user,
where it belongs. I've often thought about developing a system like
that.
May 20 2013
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 14:27:51 -0700, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:


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


 On Mon, 20 May 2013 13:20:22 -0700, Nick Sabalausky
 <SeeWebsiteToContactMe semitwist.com> wrote:


 On Mon, 20 May 2013 12:41:08 -0700
 "Adam Wilson" <flyboynw gmail.com> wrote:





 markup is extensible, OS widgets are not.


 I don't know where you got that idea.


 I mean extensible in terms of look or style, sorry for the ambiguity.


 Ahh, ok, I wasn't actually sure exactly what sort of "extensible" you
 meant.


 OS widgets require tons of custom coding to change the style, I've
 done it, and I hated every minute of it. But with WPF I don't even
 think twice, I just do it, because I can get the exact style in under
 an hour.


 Honestly, I'd consider that a major downside: Anything that
 helps/encourages developers to disregard a user's system settings
 (style or otherwise) is a very bad thing, IMO.

 Of course, if the toolkit automatically comes with a
 guaranteed user-selectable setting, outside of the app's control, to
 optionally disable any custom styling on a per-app or global basis, then
 that's the best solution of all: It attracts the "To hell with the
 user's system settings because *I* deserve to be in control of my user's
 computer" crowd and then uses that to hand control *back* to the user,
 where it belongs. I've often thought about developing a system like
 that.


Very few actual users care about changing the behavior of the widgets.  
Most people who want to change them just want to skin them.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 20 May 2013 15:54:10 -0700
"Adam Wilson" <flyboynw gmail.com> wrote:

 
 Very few actual users care about changing the behavior of the
 widgets. Most people who want to change them just want to skin them.
 


One standard deviation is all that ever matters. Everyone else can and
should just go fuck off. It's their own goddamn fault anyway for being
such a bunch of unreasonable jackasses. Fuck 'em, nobody cares about
them anyway, especially since we all know perfectly well they're just a
bunch of fat unshowered virgin slobs living in their parent's basement
and jerking to "7 of 9".



...Right?



Or, of course, we could just go with the classic favorite: "It's just
business."
May 20 2013
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 18:04:10 -0700, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:


 On Mon, 20 May 2013 15:54:10 -0700
 "Adam Wilson" <flyboynw gmail.com> wrote:

 Very few actual users care about changing the behavior of the
 widgets. Most people who want to change them just want to skin them.


 One standard deviation is all that ever matters. Everyone else can and
 should just go fuck off. It's their own goddamn fault anyway for being
 such a bunch of unreasonable jackasses. Fuck 'em, nobody cares about
 them anyway, especially since we all know perfectly well they're just a
 bunch of fat unshowered virgin slobs living in their parent's basement
 and jerking to "7 of 9".



 ...Right?



 Or, of course, we could just go with the classic favorite: "It's just
 business."


So the basic premise of the argument is that if we can't make everyone  
happy we shouldn't do anything at all? Let me pose you this question. If a  
piece of software did something for you that you absolutely had to do and  
nothing else did, but had a non-native widget UI, would you use that piece  
of software?

Most people, even the prideful ones, would just use it, because not using  
the software is worse than the UI decisions by the designer.

Also, mobile, particularly WinRT, but also Android, do not enforce a look,  
in fact Android enshrines the idea of many different looks for widgets, my  
S3 is NOT the vanilla Android look. Only iOS enforces a "look" but it's  
still overridable. And WinRT doesn't even have the concept of OS enforced  
widgets looks, all it has a default style.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
next sibling parent reply "Tyler Jameson Little" <beatgammit gmail.com> writes:
 So the basic premise of the argument is that if we can't make 
 everyone happy we shouldn't do anything at all?


That's the initial feeling I get, but I think it comes more from 
the idea that a large piece of software they didn't write might 
be dumped on them. It's a legitimate concern, so I think a GUI 
library should not be included in Phobos if a group has not 
agreed to maintain it.


 Also, mobile, particularly WinRT, but also Android, do not 
 enforce a look, in fact Android enshrines the idea of many 
 different looks for widgets, my S3 is NOT the vanilla Android 
 look. Only iOS enforces a "look" but it's still overridable. 
 And WinRT doesn't even have the concept of OS enforced widgets 
 looks, all it has a default style.


Trying to cover all bases seems like a headache that doesn't make 
sense in a standard library. For me, a standard library would 
provide a simple way to get basic tasks done; anything more 
complicated should be built on top if possible, but the core 
shouldn't be too bloated.

I'm thinking something closer to Clutter, not WPF. WPF is fine, 
but as you mentioned earlier, it has something like 40,000 
classes. I'm sure much of it is just OO baggage (stupid little 
20-line classes), but that still translates to a lot of code. 
Browsing Ohloh.net, here's an idea of the scope of other FOSS GUI 
toolkits:

* Qt 5 - ~7.7 million SLOC
* wkWidgets - ~1.3 million SLOC
* Gtk+ - ~769k SLOC
* EFL - ~535k SLOC
* Clutter - ~133k SLOC

As for my opinionated ideals (doesn't affect the overall design 
much):

* no XML (yaml maybe, but XML just isn't user-friendly)
* very limited number of default components (external libraries 
can provide more)
* liberally licensed (Phobos requires Boost, so that's a minimum; 
I prefer BSD)

I also don't like the idea of external processes interfering with 
the UI. I can only see security holes that cannot be plugged 
because of the design decision. This can, of course, be provided 
by a developer, but it should not be provided by default in the 
library code.
May 20 2013
next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 20:32:30 -0700, Tyler Jameson Little  
<beatgammit gmail.com> wrote:


 So the basic premise of the argument is that if we can't make everyone  
 happy we shouldn't do anything at all?


 That's the initial feeling I get, but I think it comes more from the  
 idea that a large piece of software they didn't write might be dumped on  
 them. It's a legitimate concern, so I think a GUI library should not be  
 included in Phobos if a group has not agreed to maintain it.


 Also, mobile, particularly WinRT, but also Android, do not enforce a  
 look, in fact Android enshrines the idea of many different looks for  
 widgets, my S3 is NOT the vanilla Android look. Only iOS enforces a  
 "look" but it's still overridable. And WinRT doesn't even have the  
 concept of OS enforced widgets looks, all it has a default style.


 Trying to cover all bases seems like a headache that doesn't make sense  
 in a standard library. For me, a standard library would provide a simple  
 way to get basic tasks done; anything more complicated should be built  
 on top if possible, but the core shouldn't be too bloated.

 I'm thinking something closer to Clutter, not WPF. WPF is fine, but as  
 you mentioned earlier, it has something like 40,000 classes. I'm sure  
 much of it is just OO baggage (stupid little 20-line classes), but that  
 still translates to a lot of code. Browsing Ohloh.net, here's an idea of  
 the scope of other FOSS GUI toolkits:

 * Qt 5 - ~7.7 million SLOC
 * wkWidgets - ~1.3 million SLOC
 * Gtk+ - ~769k SLOC
 * EFL - ~535k SLOC
 * Clutter - ~133k SLOC

 As for my opinionated ideals (doesn't affect the overall design much):

 * no XML (yaml maybe, but XML just isn't user-friendly)
 * very limited number of default components (external libraries can  
 provide more)
 * liberally licensed (Phobos requires Boost, so that's a minimum; I  
 prefer BSD)

 I also don't like the idea of external processes interfering with the  
 UI. I can only see security holes that cannot be plugged because of the  
 design decision. This can, of course, be provided by a developer, but it  
 should not be provided by default in the library code.


I actually find WPF too be far to heavy to be realistic for our purposes  
too. I know why they choose XML for XAML (they had existing XML  
parser/serialization libraries to leverage) but it ends up being  
frighteningly verbose. I am think a DSL and CTFE/mixins would be a MUCH  
more compact system and would be much more in line with D's principles. I  
personally have no problem with Boost, the goal is to get people using it  
in all scenarios, not restricting it to one licensing ideology or another.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-21 05:32, Tyler Jameson Little wrote:


 As for my opinionated ideals (doesn't affect the overall design much):

 * no XML (yaml maybe, but XML just isn't user-friendly)


Do people actual "code" in the markup. Isn't that just for a GUI 
building tool.

-- 
/Jacob Carlborg
May 21 2013
next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Tue, 21 May 2013 00:24:30 -0700, Jacob Carlborg <doob me.com> wrote:


 On 2013-05-21 05:32, Tyler Jameson Little wrote:


 As for my opinionated ideals (doesn't affect the overall design much):

 * no XML (yaml maybe, but XML just isn't user-friendly)


 Do people actual "code" in the markup. Isn't that just for a GUI  
 building tool.


I wouldn't call markup coding. It's designing, and ideally it's WYSIWYG,  
but properly done it's completely separate from code. A markup UI language  
should exist completely on top of the langauge. The best case scenario is  
where the markup language can be translated down to any other language  
supported by the UI framework by a compiler switch.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 21 2013
prev sibling parent reply Peter Williams <pwil3058 bigpond.net.au> writes:
On 21/05/13 17:24, Jacob Carlborg wrote:

 On 2013-05-21 05:32, Tyler Jameson Little wrote:


 As for my opinionated ideals (doesn't affect the overall design much):

 * no XML (yaml maybe, but XML just isn't user-friendly)


 Do people actual "code" in the markup. Isn't that just for a GUI
 building tool.


My experience (with PyGTK) is that GUI building tools actually make the 
task harder not easier (once you become familiar with the API).  Of 
course, things may have changed since I last used such a tool but I 
doubt it.

Having said that I have to admit that I've implemented my own "list/tree 
specification" mechanism for that particular job because it made it 
easier to find where to make changes.  In my defence, last time I used 
one of the GUI building tools it contained no support for building lists 
and trees so making my own made sense.

Peter
May 21 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-22 07:00, Peter Williams wrote:


 My experience (with PyGTK) is that GUI building tools actually make the
 task harder not easier (once you become familiar with the API).  Of
 course, things may have changed since I last used such a tool but I
 doubt it.


Then you obviously haven't used Interface Builder/Xcode on Mac OS X. 
It's a great tool for window building.


 Having said that I have to admit that I've implemented my own "list/tree
 specification" mechanism for that particular job because it made it
 easier to find where to make changes.  In my defence, last time I used
 one of the GUI building tools it contained no support for building lists
 and trees so making my own made sense.


If the tool didn't support trees you obviously used a bad tool. In Xcode 
you can drag in a standard view, then change the implementation class. 
This allows you to add your custom views to the window using the GUI 
builder. It used to have plugins for this but they were removed in Xcode 4.

-- 
/Jacob Carlborg
May 21 2013
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 22 May 2013 at 06:44:48 UTC, Jacob Carlborg wrote:

 On 2013-05-22 07:00, Peter Williams wrote:


 My experience (with PyGTK) is that GUI building tools actually 
 make the
 task harder not easier (once you become familiar with the 
 API).  Of
 course, things may have changed since I last used such a tool 
 but I
 doubt it.


 Then you obviously haven't used Interface Builder/Xcode on Mac 
 OS X. It's a great tool for window building.


Or Delphi. :)
May 22 2013
prev sibling parent reply Peter Williams <pwil3058 bigpond.net.au> writes:
On 22/05/13 16:44, Jacob Carlborg wrote:

 On 2013-05-22 07:00, Peter Williams wrote:


 My experience (with PyGTK) is that GUI building tools actually make the
 task harder not easier (once you become familiar with the API).  Of
 course, things may have changed since I last used such a tool but I
 doubt it.


 Then you obviously haven't used Interface Builder/Xcode on Mac OS X.
 It's a great tool for window building.


That is indeed the case.  I avoid all things Apple as my experience has 
been that they seem to think they still own a device after they've sold 
it to me.

Most of my experience with such tools was with Glade.

I found that Glade produced a lot of code to do very little.


 Having said that I have to admit that I've implemented my own "list/tree
 specification" mechanism for that particular job because it made it
 easier to find where to make changes.  In my defence, last time I used
 one of the GUI building tools it contained no support for building lists
 and trees so making my own made sense.


 If the tool didn't support trees you obviously used a bad tool.


Probably.


 In Xcode
 you can drag in a standard view, then change the implementation class.
 This allows you to add your custom views to the window using the GUI
 builder. It used to have plugins for this but they were removed in Xcode 4.


What you describe isn't a very attractive work flow (for me).  Using 
PyGTK direct I just use normal OOP techniques to extend widget classes 
and adding a widget to a window is very simple operation (1 statement) 
and certainly doesn't need a GUI to achieve it.

The part of creating a tree that I use my specification mechanism for is 
defining/setting up the columns and setting options on them which I 
don't think would be made easier using a GUI.

Peter
May 22 2013
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 23 May 2013 09:51:17 +1000
Peter Williams <pwil3058 bigpond.net.au> wrote:


 On 22/05/13 16:44, Jacob Carlborg wrote:

 On 2013-05-22 07:00, Peter Williams wrote:


 My experience (with PyGTK) is that GUI building tools actually
 make the task harder not easier (once you become familiar with the
 API).  Of course, things may have changed since I last used such a
 tool but I doubt it.


 Then you obviously haven't used Interface Builder/Xcode on Mac OS X.
 It's a great tool for window building.


 
 That is indeed the case.  I avoid all things Apple as my experience
 has been that they seem to think they still own a device after
 they've sold it to me.
 


Unfortunately *everyone* seems to think that now. And not just
devices, software too. You should hear a lot of the game industry:
many of the people there (not all obviously, but a lot) *genuinely*
believe first-sale doctrine is invalid/inexcusable/inapplicable/etc and
that they still have true, unalienable rights *after* the first sale.
It's unbelievable, it's like talking to caricatures of Enron execs.
May 22 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-23 01:51, Peter Williams wrote:


 That is indeed the case.  I avoid all things Apple as my experience has
 been that they seem to think they still own a device after they've sold
 it to me.


I can understand that. But if we are to create something like this 
thread suggest I would say that it's almost irresponsible to not try all 
the alternatives. Ok, it might not be that easy to try the Apple stuff, 
need the correct hardware and so on. Yes, there are workarounds as well.


 What you describe isn't a very attractive work flow (for me).  Using
 PyGTK direct I just use normal OOP techniques to extend widget classes
 and adding a widget to a window is very simple operation (1 statement)
 and certainly doesn't need a GUI to achieve it.


You will need do the same thing in Xcode as well. What I described here 
was how to add a custom view, that you already have created using 
inheritance, using the GUI builder to a window. I can add as well that 
you're not forced to use the GUI builder, but it's generally easier.


 The part of creating a tree that I use my specification mechanism for is
 defining/setting up the columns and setting options on them which I
 don't think would be made easier using a GUI.

 Peter



-- 
/Jacob Carlborg
May 22 2013
parent Peter Williams <pwil3058 bigpond.net.au> writes:
On 23/05/13 16:36, Jacob Carlborg wrote:

 On 2013-05-23 01:51, Peter Williams wrote:


 That is indeed the case.  I avoid all things Apple as my experience has
 been that they seem to think they still own a device after they've sold
 it to me.


 I can understand that. But if we are to create something like this
 thread suggest I would say that it's almost irresponsible to not try all
 the alternatives. Ok, it might not be that easy to try the Apple stuff,
 need the correct hardware and so on. Yes, there are workarounds as well.


If I had been advocating the banning of GUI builders that would be the 
case but I was just saying I found them not very useful once I was 
familiar with the API proper.


 What you describe isn't a very attractive work flow (for me).  Using
 PyGTK direct I just use normal OOP techniques to extend widget classes
 and adding a widget to a window is very simple operation (1 statement)
 and certainly doesn't need a GUI to achieve it.


 You will need do the same thing in Xcode as well. What I described here
 was how to add a custom view, that you already have created using
 inheritance, using the GUI builder to a window. I can add as well that
 you're not forced to use the GUI builder, but it's generally easier.


For you maybe.  My experience has been the opposite.  I'm not proposing 
that you shouldn't be able to use such a tool if that's your preference 
just that it shouldn't be the only way to create a GUI.

Peter
PS I'm a great believer in GUIs and have spent a great deal of time 
writing GUI wrappers for tools such a quilt, mercurial and git just to 
avoid having to type the same thing over and over at the command line. 
But I always include a mechanism for typing in commands directly as 
cases always arise where the GUI can't do exactly what you want.
May 23 2013
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 20 May 2013 19:24:44 -0700
"Adam Wilson" <flyboynw gmail.com> wrote:


 On Mon, 20 May 2013 18:04:10 -0700, Nick Sabalausky  
 <SeeWebsiteToContactMe semitwist.com> wrote:
 

 On Mon, 20 May 2013 15:54:10 -0700
 "Adam Wilson" <flyboynw gmail.com> wrote:

 Very few actual users care about changing the behavior of the
 widgets. Most people who want to change them just want to skin
 them.


 One standard deviation is all that ever matters. Everyone else can
 and should just go fuck off. It's their own goddamn fault anyway
 for being such a bunch of unreasonable jackasses. Fuck 'em, nobody
 cares about them anyway, especially since we all know perfectly
 well they're just a bunch of fat unshowered virgin slobs living in
 their parent's basement and jerking to "7 of 9".



 ...Right?



 Or, of course, we could just go with the classic favorite: "It's
 just business."


 
 So the basic premise of the argument is that if we can't make
 everyone happy we shouldn't do anything at all?


The basic premise is that "fuck the minority" is asinine. I know you've
never worded it in such a way, but that's exactly what it amounts to.



 Let me pose you this
 question. If a piece of software did something for you that you
 absolutely had to do and nothing else did, but had a non-native
 widget UI, would you use that piece of software?
 


There's nothing hypothetical about that:

I *do* use Claws mail, Gimp, DVDFab (to remove PUOs from my - yes,
legitimate - discs) and various others, I have used iTunes, Flash and
others in the past, and those are all non-native abominations. And yes,
I put up with them *even over some native UI alternatives*, because for
one reason or another they're the best option (for me) that I can find.

That still doesn't change the fact that I hate putting up with them and
I would immediately jump ship given an all-around sufficient
alternative.



 Most people, even the prideful ones, would just use it, because not
 using the software is worse than the UI decisions by the designer.
 


So I take it you *really* weren't expecting my answer above then. You
were maybe convinced I was something I'm clearly not, hmm? Just because
I don't chase trends eagerly? Or just that someone not sharing your
opinion, or who doesn't engage in group-think, couldn't possibly be
rational? Something else, perhaps?
May 20 2013
parent "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 22:18:31 -0700, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:


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


 On Mon, 20 May 2013 18:04:10 -0700, Nick Sabalausky
 <SeeWebsiteToContactMe semitwist.com> wrote:


 On Mon, 20 May 2013 15:54:10 -0700
 "Adam Wilson" <flyboynw gmail.com> wrote:

 Very few actual users care about changing the behavior of the
 widgets. Most people who want to change them just want to skin
 them.


 One standard deviation is all that ever matters. Everyone else can
 and should just go fuck off. It's their own goddamn fault anyway
 for being such a bunch of unreasonable jackasses. Fuck 'em, nobody
 cares about them anyway, especially since we all know perfectly
 well they're just a bunch of fat unshowered virgin slobs living in
 their parent's basement and jerking to "7 of 9".



 ...Right?



 Or, of course, we could just go with the classic favorite: "It's
 just business."


 So the basic premise of the argument is that if we can't make
 everyone happy we shouldn't do anything at all?


 The basic premise is that "fuck the minority" is asinine. I know you've
 never worded it in such a way, but that's exactly what it amounts to.



 Let me pose you this
 question. If a piece of software did something for you that you
 absolutely had to do and nothing else did, but had a non-native
 widget UI, would you use that piece of software?


 There's nothing hypothetical about that:

 I *do* use Claws mail, Gimp, DVDFab (to remove PUOs from my - yes,
 legitimate - discs) and various others, I have used iTunes, Flash and
 others in the past, and those are all non-native abominations. And yes,
 I put up with them *even over some native UI alternatives*, because for
 one reason or another they're the best option (for me) that I can find.

 That still doesn't change the fact that I hate putting up with them and
 I would immediately jump ship given an all-around sufficient
 alternative.



 Most people, even the prideful ones, would just use it, because not
 using the software is worse than the UI decisions by the designer.


 So I take it you *really* weren't expecting my answer above then. You
 were maybe convinced I was something I'm clearly not, hmm? Just because
 I don't chase trends eagerly? Or just that someone not sharing your
 opinion, or who doesn't engage in group-think, couldn't possibly be
 rational? Something else, perhaps?


Pretty much the answer I expected actually.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-20 22:58, Adam Wilson wrote:


 Depends on the system, in WPF the XAML is encoded into a binary form of
 XML and then the objects are deserialized at runtime. Note that given
 D's CTFE I would NOT choose this path for any D UI toolkit. D is perfect
 for a system where you use markup to declare your UI in a CTFE manner
 and then have the compiler do the dirty work of actually generating the
 code. Fast AND Simple, Go D!


Surely we want to have both. I'm thinking when you're developing you 
don't want to recompile you're application if you can avoid it just when 
the GUI is changed.

-- 
/Jacob Carlborg
May 21 2013
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Tue, 21 May 2013 00:16:15 -0700, Jacob Carlborg <doob me.com> wrote:


 On 2013-05-20 22:58, Adam Wilson wrote:


 Depends on the system, in WPF the XAML is encoded into a binary form of
 XML and then the objects are deserialized at runtime. Note that given
 D's CTFE I would NOT choose this path for any D UI toolkit. D is perfect
 for a system where you use markup to declare your UI in a CTFE manner
 and then have the compiler do the dirty work of actually generating the
 code. Fast AND Simple, Go D!


 Surely we want to have both. I'm thinking when you're developing you  
 don't want to recompile you're application if you can avoid it just when  
 the GUI is changed.


Well, that depends, if it comes down to a trade off between program  
execution speed vs. compile speed, i'll pick program execution speed.  
Right now, I know of no UI toolkit that lets you redesign without  
recompiling, so i'd say that should be a secondary priority.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 21 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-05-21 19:50, Adam Wilson wrote:


 Well, that depends, if it comes down to a trade off between program
 execution speed vs. compile speed, i'll pick program execution speed.
 Right now, I know of no UI toolkit that lets you redesign without
 recompiling, so i'd say that should be a secondary priority.


As far as I know on Mac OS X it works like this. It just reads the nib 
file at runtime.

-- 
/Jacob Carlborg
May 21 2013
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 21 May 2013 10:50:40 -0700
"Adam Wilson" <flyboynw gmail.com> wrote:


 On Tue, 21 May 2013 00:16:15 -0700, Jacob Carlborg <doob me.com>
 wrote:

 Surely we want to have both. I'm thinking when you're developing
 you don't want to recompile you're application if you can avoid it
 just when the GUI is changed.


 
 Well, that depends, if it comes down to a trade off between program  
 execution speed vs. compile speed, i'll pick program execution
 speed. Right now, I know of no UI toolkit that lets you redesign
 without recompiling, so i'd say that should be a secondary priority.
 


Not that I'm pushing for it, but that doesn't strike me as something
that would likely be a real bottleneck in a GUI application. Just my
gut impression, though.
May 21 2013
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
20-May-2013 23:41, Adam Wilson пишет:

 On Mon, 20 May 2013 12:28:16 -0700, Dmitry Olshansky
 <dmitry.olsh gmail.com> wrote:


[snip]


 * There is absolutely no chance of inclusion in Phobos, and to-be-honest
 I don't think it really belongs there.


 Where you take that from? I thought it was quite the opposite if
 written in D. Even C++ guys seem interested in GUIs in std library(!)

 [snip]


 I would LOVE to see it included in Phobos, but making it multi-platform
 places an pretty hard requirement that it not be OS native widgets, some
 OS's have widgets that others don't, some OS's have incompatible UI
 declaration models, for example: WinForms is Win23 API calls where iOS
 is markup. It is workable, but it is even MORE work than building a GPU
 based UI toolkit from scratch. How big is Qt compared to WPF?


Keep in mind that Qt as other frameworks basically bend the whole world 
into a certain ideology. They build everything anew from atoms (or 
rather quarks) up. Strings(!), smart pointers, events, semaphores, 
threads,  containers, allocators, signals/slots, you name it - they 
build it ALL.

Not to blame them - C++ std simply doesn't have it/cut it. D on the 
other hand can leverage the incredibly flexible (but incomplete 
currently) "framework" of Phobos.

Note that all of GUI frameworks are pre C++11 (hint-hint).


 Here's the deal. Building a GUI toolkit, particularly a useful one, is a
 massive undertaking. WPF is the single largest library in all of .NET.
 IIRC it weighs in at 40,000 classes. Building a UI toolkit in D will
 require something that D itself does not. A highly dedicated team of
 people with many diverse skills. The project is simply too big for a
 single person.



 OOP code could help here.


 You have no idea...


Of course, I haven't seen the video yet :)

[snip]

 Well, then you'll also become an expert in a couple of cool fields ;)
 Seriously a few helping hands are sorely needed.


 Absolutely, but my point is that some of those are entire fields of
 study and bodies of knowledge that can take years or decades a too
 acquire.


I believe this is a fallacy as given the current pace of progress people 
can then no longer hope to become experts anymore ;)
(Or at least in anything even remotely actual). A year or 2 is more then 
enough to get to the state of the art, and amount of experience is not 
proportional to inventing something new (and advancing the field).

Another thing to understand is that for example it took years to develop 
classical analysis in math but nowadays it's just a couple of semesters. 
Stealing a good vision from other expert(s) is a good interim short-cut.

Also believe it or not there is a quite large intersections between all 
of fields you just listed (at least pair-wise).


 It's a bit unrealistic for first time GPU coder to write an
 efficient shader.


And these change often enough that 5-years old experience has little 
advantage - you still have to re-read all the specs again.


 UI design is a whole field unto itself. Etc. My point
 here is that no one person has a realistic shot of being able to acquire
 and maintain the required knowledge single-handedly.


The only path is to develop even in teams is having a good taste 
(=vision) and lead others to follow it. If you don't understand UI 
design at all chances to succeed with you at head are low, ditto GPUs 
ditto everything else.


 [snip other good points]







-- 
Dmitry Olshansky
May 20 2013
next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 13:32:09 -0700, Dmitry Olshansky  =

<dmitry.olsh gmail.com> wrote:


 20-May-2013 23:41, Adam Wilson =D0=BF=D0=B8=D1=88=D0=B5=D1=82:

 On Mon, 20 May 2013 12:28:16 -0700, Dmitry Olshansky
 <dmitry.olsh gmail.com> wrote:


 [snip]


 * There is absolutely no chance of inclusion in Phobos, and  =









 to-be-honest
 I don't think it really belongs there.


 Where you take that from? I thought it was quite the opposite if
 written in D. Even C++ guys seem interested in GUIs in std library(!=






)

 [snip]


 I would LOVE to see it included in Phobos, but making it multi-platfo=




rm

 places an pretty hard requirement that it not be OS native widgets, s=




ome

 OS's have widgets that others don't, some OS's have incompatible UI
 declaration models, for example: WinForms is Win23 API calls where iO=




S

 is markup. It is workable, but it is even MORE work than building a G=




PU

 based UI toolkit from scratch. How big is Qt compared to WPF?


 Keep in mind that Qt as other frameworks basically bend the whole worl=


d  =


 into a certain ideology. They build everything anew from atoms (or  =



 rather quarks) up. Strings(!), smart pointers, events, semaphores,  =



 threads,  containers, allocators, signals/slots, you name it - they  =



 build it ALL.

 Not to blame them - C++ std simply doesn't have it/cut it. D on the  =



 other hand can leverage the incredibly flexible (but incomplete  =



 currently) "framework" of Phobos.

 Note that all of GUI frameworks are pre C++11 (hint-hint).


Agreed, however, I think with D/Phobos we are in a situation where we ca=
n  =

go the WPF route and just build on top of the existing work instead of  =

having to create a whole new "standard" library to accompany it.


 Here's the deal. Building a GUI toolkit, particularly a useful one,=








  =


 is a
 massive undertaking. WPF is the single largest library in all of .N=








ET.

 IIRC it weighs in at 40,000 classes. Building a UI toolkit in D wil=








l

 require something that D itself does not. A highly dedicated team o=








f

 people with many diverse skills. The project is simply too big for =








a

 single person.









de

 OOP code could help here.


 You have no idea...


 Of course, I haven't seen the video yet :)

 [snip]


Well, the video isn't NEARLY that broad in scope, but I do find on avera=
ge  =



certain use cases like UI declaration with CTFE it could be a LOT smalle=
r.


 Well, then you'll also become an expert in a couple of cool fields ;=






)

 Seriously a few helping hands are sorely needed.


 Absolutely, but my point is that some of those are entire fields of
 study and bodies of knowledge that can take years or decades a too
 acquire.


 I believe this is a fallacy as given the current pace of progress peop=


le  =


 can then no longer hope to become experts anymore ;)
 (Or at least in anything even remotely actual). A year or 2 is more th=


en  =


 enough to get to the state of the art, and amount of experience is not=


  =


 proportional to inventing something new (and advancing the field).

 Another thing to understand is that for example it took years to devel=


op  =


 classical analysis in math but nowadays it's just a couple of semester=


s.  =


 Stealing a good vision from other expert(s) is a good interim short-cu=


t.

 Also believe it or not there is a quite large intersections between al=


l  =


 of fields you just listed (at least pair-wise).


There may be some truth to this, however, GPU's in particular remain an =
 =

area where specialized knowledge is required. Ask Manu. ;-) That said,  =

even if most of who we needed are generalists, we'd still need a small  =

army of them. Now this is open-source, and we can actually find that sma=
ll  =

army. But organizing them is far more difficult than at a corporation, a=
t  =

least there you have some unifying vision from the top. Out here is FOSS=
  =

land it's a free-for-all, and in projects of this scope that tends creat=
e  =

many competing visions, and implementations. Subsequently teams fragment=
  =

quickly and duplication settles in.


 It's a bit unrealistic for first time GPU coder to write an
 efficient shader.


 And these change often enough that 5-years old experience has little  =



 advantage - you still have to re-read all the specs again.


Sadly this is true, but you still have your domain experience, yes the  =

details changed, but the general processes and procedures you are used t=
o  =

don't generally change that fast.


 UI design is a whole field unto itself. Etc. My point
 here is that no one person has a realistic shot of being able to acqu=




ire

 and maintain the required knowledge single-handedly.


 The only path is to develop even in teams is having a good taste  =



 (=3Dvision) and lead others to follow it. If you don't understand UI  =



 design at all chances to succeed with you at head are low, ditto GPUs =


 =


 ditto everything else.


 [snip other good points]






Some days I wish I had the charisma and vision to develop that team,  =

because I badly want a D UI toolkit that can do with WPF can. I may or m=
ay  =

not have the right vision, but I am no charismatic. ;-)


-- =

Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 20 May 2013 14:14:30 -0700
"Adam Wilson" <flyboynw gmail.com> wrote:

 Some days I wish I had the charisma and vision to develop that team,  
 because I badly want a D UI toolkit that can do with WPF can. I may
 or may not have the right vision, but I am no charismatic. ;-)
 


What would you say would be a good introduction to WPF?
May 20 2013
parent "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 14:38:51 -0700, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:


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

 Some days I wish I had the charisma and vision to develop that team,
 because I badly want a D UI toolkit that can do with WPF can. I may
 or may not have the right vision, but I am no charismatic. ;-)


 What would you say would be a good introduction to WPF?


If you want a high level overview of WPF the wikipedia article is a good  
place to start:  
http://en.wikipedia.org/wiki/Windows_Presentation_Foundation

If you want a more technical approach to working with WPF the Microsoft  
docs are king: http://msdn.microsoft.com/en-us/library/ms754130.aspx

Of particular interest should be it's rendering model and Dependency  
Properties.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 21 May 2013 00:32:09 +0400
Dmitry Olshansky <dmitry.olsh gmail.com> wrote:


 20-May-2013 23:41, Adam Wilson =D0=BF=D0=B8=D1=88=D0=B5=D1=82:

 Absolutely, but my point is that some of those are entire fields of
 study and bodies of knowledge that can take years or decades a too
 acquire.


=20
 I believe this is a fallacy as given the current pace of progress
 people can then no longer hope to become experts anymore ;)
 (Or at least in anything even remotely actual). A year or 2 is more
 then enough to get to the state of the art, and amount of experience
 is not proportional to inventing something new (and advancing the
 field).
=20


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.



 Another thing to understand is that for example it took years to
 develop classical analysis in math but nowadays it's just a couple of
 semesters. Stealing a good vision from other expert(s) is a good
 interim short-cut.
=20


Well, there *is* that, too.
May 20 2013
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 14:36:11 -0700, Nick Sabalausky  =

<SeeWebsiteToContactMe semitwist.com> wrote:


 On Tue, 21 May 2013 00:32:09 +0400
 Dmitry Olshansky <dmitry.olsh gmail.com> wrote:


 20-May-2013 23:41, Adam Wilson =D0=BF=D0=B8=D1=88=D0=B5=D1=82:

 Absolutely, but my point is that some of those are entire fields of=







 study and bodies of knowledge that can take years or decades a too
 acquire.


 I believe this is a fallacy as given the current pace of progress
 people can then no longer hope to become experts anymore ;)
 (Or at least in anything even remotely actual). A year or 2 is more
 then enough to get to the state of the art, and amount of experience
 is not proportional to inventing something new (and advancing the
 field).


 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 lo=
t  =

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 firs=
t,  =

and IMHO they made WAY to many mistakes there and only now just starting=
  =

to catch up to where WPF was in 2005.


 Another thing to understand is that for example it took years to
 develop classical analysis in math but nowadays it's just a couple of=





 semesters. Stealing a good vision from other expert(s) is a good
 interim short-cut.


 Well, there *is* that, too.



-- =

Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
May 20 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-20 21:41, Adam Wilson wrote:


 HTML is markup. XAML is markup. QML is markup. XUL is markup. iOS is
 markup. Android is markup. Realistically, the age of OS native toolkits
 has passed, markup is the future. *shrug* For me it's a practical thing,
 markup is extensible, OS widgets are not.


What is exactly do you mean with "markup"? On iOS the native toolkit is 
used. But you create the interface graphically using Xcode, it then will 
serialize it to XML and/or binary. Is that XML what you refer to as 
"markup"?

-- 
/Jacob Carlborg
May 21 2013
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Tue, 21 May 2013 00:01:36 -0700, Jacob Carlborg <doob me.com> wrote:


 On 2013-05-20 21:41, Adam Wilson wrote:


 HTML is markup. XAML is markup. QML is markup. XUL is markup. iOS is
 markup. Android is markup. Realistically, the age of OS native toolkits
 has passed, markup is the future. *shrug* For me it's a practical thing,
 markup is extensible, OS widgets are not.


 What is exactly do you mean with "markup"? On iOS the native toolkit is  
 used. But you create the interface graphically using Xcode, it then will  
 serialize it to XML and/or binary. Is that XML what you refer to as  
 "markup"?


Yes, I know it's a bit of stretch but it's the same basic idea as XAML,  
graphically created XML that is serialized to XML or binary. :-)

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 21 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-21 19:51, Adam Wilson wrote:


 Yes, I know it's a bit of stretch but it's the same basic idea as XAML,
 graphically created XML that is serialized to XML or binary. :-)


Then markup has nothing to do with a GUI toolkit being native or not.

-- 
/Jacob Carlborg
May 21 2013
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Tue, 21 May 2013 11:38:31 -0700, Jacob Carlborg <doob me.com> wrote:


 On 2013-05-21 19:51, Adam Wilson wrote:


 Yes, I know it's a bit of stretch but it's the same basic idea as XAML,
 graphically created XML that is serialized to XML or binary. :-)


 Then markup has nothing to do with a GUI toolkit being native or not.


Indeed, it does not, and I hope I didn't try to sound like I was saying it  
did. Markup is just one way to express the UI. DSL's are another.  
Personally I prefer the DSL approach, as it is usually more compact.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 21 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-05-21 20:44, Adam Wilson wrote:


 Indeed, it does not, and I hope I didn't try to sound like I was saying
 it did. Markup is just one way to express the UI. DSL's are another.
 Personally I prefer the DSL approach, as it is usually more compact.


I have no problem with markup or DSL, as long as a GUI builder can 
handle it.

-- 
/Jacob Carlborg
May 21 2013
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 20 May 2013 23:28:16 +0400
Dmitry Olshansky <dmitry.olsh gmail.com> wrote:


 20-May-2013 22:01, Adam Wilson =D0=BF=D0=B8=D1=88=D0=B5=D1=82:

 * There is a deep-seated distrust of any toolkit that does not use
 the OS Native UI widgets. The people in this community prefer native
 toolkits to the point of jihad.


=20
 It's just one crazy Nick ;)
=20


Heh :) It's really not just me, though. But, gee, it is nice to know I'm
in people's thoughts...I think... ;)


 Now I am a XAML guy myself, and I saw
 the light a long time ago, but around here, the majority are still
 command line gurus.


=20
 Markup for GUI layout seems like a decent idea.
=20


Indeed. XML wouldn't have been my choice though, but UI layout is an
appropriate area for some DSL-ness.


 * There is absolutely no chance of inclusion in Phobos, and
 to-be-honest I don't think it really belongs there.


=20
 Where you take that from? I thought it was quite the opposite if
 written in D. Even C++ guys seem interested in GUIs in std library(!)
=20
 [snip]


There's interest, sure, but it'd have to be really, *really* freaking
good. Enough to obviate most needs/desires for the other popular
GUI toolkits. It'd have to do for us what WPF did for MS, *and* be
cross-platform. Not impossible, strictly speaking, but a tall order
even for us.

Not saying it isn't worth attempting for those skilled and motivated
enough, but I wouldn't have my hopes up. And I'm not sure how much we'd
really gain by having it in phobos anyway: By the time any toolkit like
that was built and ready, I'm sure DUB will have gotten big enough that
being an external library won't be an issue.
May 20 2013
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/20/13, Adam Wilson <flyboynw gmail.com> wrote:

 * There is a deep-seated distrust of any toolkit that does not use the OS
 Native UI widgets.


That's a shame. If you go native you'll have the "look and feel", but
you'll have X times the work where X is the number of platforms
supported. Also, each platform has its own bugs, so you'd have to
write a lot of workaround code as well (e.g. wxWidgets is full of
win32 workarounds).

Doing it non-native slows you down at first, but it gives you a lot
more control on how you can render things. You can add a feature
without having to worry on how to port the feature to other platforms.
And finally, you can simulate the native windowing environment.

Just to mention this, we already have native libraries (and written in
D without wrapping C++ libs) such as DGUI, DFL, DWT. I hardly find
them successful, they get the occasional pull request, but otherwise
they seem to lack any sort of team effort or going-forward schedule.
So I'd say going "native" has already been a failed experiment (take
that with a huge grain of salt, it's just my personal viewpoint :) ).


 * Nobody believes that we can do it, you'll hear a lot of moaning about
 how much work it is. My reply to that is: And Linux is such a piece of
 cake right? It's only the most widely used kernel on the planet.


I think the lesson with Linux is that one person initially did a lot
of heavy lifting, and then others joined in. I doubt it would work as
it did if instead Linus opened a thread asking for a team of
developers to create a new OS from scratch.

Anyway, there's no doubt a D GUI would be a huge undertaking. There
would almost certainly be a lot of rewriting involved. It's very easy
to make mistakes early on and hardcode something, only later to
realize it's way too brittle so it requires a rewrite. If the system
is modular enough then the rewrites become less painful. And if the
system is properly unit tested then regressions become less likely,
and this is important.


From what I've seen when a codebase becomes large enough, what


inevitably happens is people stop hacking on the codebase almost
entirely. It's usually because the codebase is huge and not modular,
or undocumented, or not tested, or doesn't have any sort of schedule
on the work that needs to be done.

I have zero doubt that we have the know-how or hacking ability to
actually work and solve GUI problems in D, but I have big doubts that
we would ever have leadership that would make sure we have a proper
schedule and todo list, proper discussions, the guts to say "no" to
features, etc. It's just not going to work if people randomly create
pull requests with some code they thought would be nice to include in
a GUI library.

So to actually do it, I think we need:

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

2) Solid leadership.
May 20 2013
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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


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.


 2) Solid leadership.


but yeah this isn't me.
May 20 2013
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
Oh btw I think a generic event loop is important too, for gui and 
non gui stuff.

I slapped something together to get started with that too:
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/eventloop.d

and even (optionally) use it in my (cross platform btw) 
terminal.d:
https://github.com/robik/ConsoleD/blob/master/terminal.d


But since it isn't something I personally use a lot it just gets 
updated when something comes up, more often than not from other 
people using it.
May 20 2013
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/21/13, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:

 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




It's also interesting how people implement GUI libraries in very
different ways. Especially in D where you have CTFE/templates/mixins,
you could literally do it any number of ways. Just discussion the
initial approach would probably span a thousand replies, where
everyone has their own unique idea and where they disagree with each
other.
May 20 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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! If I was restarting that 
simpledisplay from scratch right now, I'd probably do it 
differently. The method I used there was like an interface and 
then a bunch of mixins, the idea being that the OS 
implementations could then be easily moved to a different file 
and the interior interface and the exterior interface are 
decoupled... but adding features to it the way I did it here 
feels like it could be easier.

But this is partially why I just slap together these files myself 
and toss them out there: I think too many discussions have too 
much talk and not enough code. Even if it is crappy, something 
that works (yet is also disposable if it ends up being really 
awful) is better than nothing.
May 20 2013
parent reply Brad Roberts <braddr puremagic.com> writes:
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
May 20 2013
parent "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 15:35:16 -0700, Brad Roberts <braddr puremagic.com>  
wrote:


 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


Brad, normally I'd agree with you because I am lazy. I hate reinventing,  
occasionally I spend more time trying to not reinvent than it would've  
taken to reinvent.

However, are we really reinventing? Yes, on a broad level it's yet another  
GUI toolkit. But the goal is WPF, not native. And to date the closest  
thing I've found is QtD, and that requires you fit the Qt ideology, it's  
not D native. But more to the point Qt is just a shadow of WPF. They are  
starting to work towards it but they've got a long way to go. D offers  
inherent advantages that can pretty dramatically speed up the process. We  
are really creating a markup based UI toolkit in native D. I don't think  
that exists. It'll can become a showcase for D and has the potential to be  
used outside of D. Because of that, I don't think it's really reinvention,  
we're using existing ideas and applying them to D.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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
May 20 2013
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/21/13, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:

 Just discussion the


*discussing
May 20 2013
prev sibling next sibling parent reply "Flamaros" <flamaros.xavier gmail.com> writes:
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.
May 20 2013
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
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/
May 20 2013
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/21/13, Adam Wilson <flyboynw gmail.com> wrote:

 Sub-pixel font hinting. Almost no games use this, and almost every OS
 toolkit does.


There used to be a nice article about font rendering in OpenGL
(methinks) here: http://h3.gd/dmedia/?n=Tutorials.TextRendering1

But the link is dead. Most h3r3tic links are dead, not even
archive.org has them.
May 20 2013
next sibling parent reply "Kiith-Sa" <kiithsacmp gmail.com> writes:
On Monday, 20 May 2013 at 23:40:34 UTC, Andrej Mitrovic wrote:

 On 5/21/13, Adam Wilson <flyboynw gmail.com> wrote:

 Sub-pixel font hinting. Almost no games use this, and almost 
 every OS
 toolkit does.


 There used to be a nice article about font rendering in OpenGL
 (methinks) here: http://h3.gd/dmedia/?n=Tutorials.TextRendering1

 But the link is dead. Most h3r3tic links are dead, not even
 archive.org has them.


I have code based in that tutorial in my current project:

https://github.com/kiith-sa/awesome2D

See the font subdirectory and demo/texturepacker.d
(Note that the package/module structure is badly organized due to 
rushing).


A slightly different implementation is in my older project, ICE, 
but it doesn't compile with current DMD.

I'm also working on a simple in-game GUI library as a part of 
this project,
but I'm only doing what I need myself (which is virtually nothing 
right
now, because time) and its not nearly  as convenient to use as it 
could be. Also, not intended for OS-style GUIs, just game GUIs 
and maybe non-standard stuff like what you see in graphics 
programs.

H3r3tic had a more advanced GUI framework (still not native), 
hybrid, which IMO has a far better API than any framework I've 
seen, but I never found the source,
only documentation somewhere on his (unmaintained) site.
May 20 2013
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/21/13, Kiith-Sa <kiithsacmp gmail.com> wrote:

 H3r3tic had a more advanced GUI framework (still not native),
 hybrid, which IMO has a far better API than any framework I've
 seen, but I never found the source,
 only documentation somewhere on his (unmaintained) site.


It's here though, hidden in another project:

https://bitbucket.org/h3r3tic/boxen/src/76f3fab1b889/src/xf/hybrid?at=default
May 20 2013
prev sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 21 May 2013 at 00:04:03 UTC, Kiith-Sa wrote:

 H3r3tic had a more advanced GUI framework (still not native), 
 hybrid, which IMO has a far better API than any framework I've 
 seen, but I never found the source,
 only documentation somewhere on his (unmaintained) site.


https://bitbucket.org/h3r3tic/boxen/src.

That project repo is worth a try for many of Tomasz' (resp. 
team0xf's) projects.

David
May 21 2013
prev sibling parent reply "Diggory" <diggsey googlemail.com> writes:
On Monday, 20 May 2013 at 23:40:34 UTC, Andrej Mitrovic wrote:

 On 5/21/13, Adam Wilson <flyboynw gmail.com> wrote:

 Sub-pixel font hinting. Almost no games use this, and almost 
 every OS
 toolkit does.


 There used to be a nice article about font rendering in OpenGL
 (methinks) here: http://h3.gd/dmedia/?n=Tutorials.TextRendering1

 But the link is dead. Most h3r3tic links are dead, not even
 archive.org has them.


Generally the idea is to pack the characters into a texture and 
then render from that - it's very fast as you don't have to 
switch textures which is relatively slow. There are a few 
different ways of representing the characters (for large text 
signed distance maps seem to be currently the state of the art) 
while for small text a simple single channel alpha map is good 
and fast.

TBH the rendering itself is fairly simple, the hard part is the 
layout, glyph conversion and kerning. It seems like the new 
std.uni module actually does some of the glyph conversion which 
is nice.

Another technique that might be worth looking into is simply 
getting the OS to render the text as it will be displayed to a 
texture and then it's just a case of blitting that to the screen. 
With some caching that could be efficient enough, most gui text 
does not change very often, otherwise you wouldn't have time to 
read it...
May 20 2013
parent "Kiith-Sa" <kiithsacmp gmail.com> writes:
On Tuesday, 21 May 2013 at 00:05:21 UTC, Diggory wrote:

 On Monday, 20 May 2013 at 23:40:34 UTC, Andrej Mitrovic wrote:

 On 5/21/13, Adam Wilson <flyboynw gmail.com> wrote:

 Sub-pixel font hinting. Almost no games use this, and almost 
 every OS
 toolkit does.


 There used to be a nice article about font rendering in OpenGL
 (methinks) here: 
 http://h3.gd/dmedia/?n=Tutorials.TextRendering1

 But the link is dead. Most h3r3tic links are dead, not even
 archive.org has them.


 Generally the idea is to pack the characters into a texture and 
 then render from that - it's very fast as you don't have to 
 switch textures which is relatively slow. There are a few 
 different ways of representing the characters (for large text 
 signed distance maps seem to be currently the state of the art) 
 while for small text a simple single channel alpha map is good 
 and fast.

 TBH the rendering itself is fairly simple, the hard part is the 
 layout, glyph conversion and kerning. It seems like the new 
 std.uni module actually does some of the glyph conversion which 
 is nice.

 Another technique that might be worth looking into is simply 
 getting the OS to render the text as it will be displayed to a 
 texture and then it's just a case of blitting that to the 
 screen. With some caching that could be efficient enough, most 
 gui text does not change very often, otherwise you wouldn't 
 have time to read it...


The code I linked to takes care of glyph positioning/kerning/etc; 
although I didn't test it with e.g. asian languages, and there 
might be bugs to work out there.
May 20 2013
prev sibling parent "Flamaros" <flamaros.xavier gmail.com> writes:
On Monday, 20 May 2013 at 22:48:01 UTC, Adam Wilson wrote:

 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.


QML do sub pixel with a shader, but us think to start with a 
pixel perfect alignment. In games we works on, we don't have 
issues specifics to OS with fonts. Default font can't be the same 
but FreeType support many types of font files. As our games are 
mainly on smartphone we use kerning to save spacing, and space 
character to automatic wrapping. An advanced wrapping can only be 
done with dictionaries.

My vision is actually to start something to see if it's a valid 
choice. After other questions will find answers with the 
communauty.
May 21 2013
prev sibling next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 14:47:47 -0700, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:


 On 5/20/13, Adam Wilson <flyboynw gmail.com> wrote:

 * There is a deep-seated distrust of any toolkit that does not use the  
 OS
 Native UI widgets.


 That's a shame. If you go native you'll have the "look and feel", but
 you'll have X times the work where X is the number of platforms
 supported. Also, each platform has its own bugs, so you'd have to
 write a lot of workaround code as well (e.g. wxWidgets is full of
 win32 workarounds).

 Doing it non-native slows you down at first, but it gives you a lot
 more control on how you can render things. You can add a feature
 without having to worry on how to port the feature to other platforms.
 And finally, you can simulate the native windowing environment.

 Just to mention this, we already have native libraries (and written in
 D without wrapping C++ libs) such as DGUI, DFL, DWT. I hardly find
 them successful, they get the occasional pull request, but otherwise
 they seem to lack any sort of team effort or going-forward schedule.
 So I'd say going "native" has already been a failed experiment (take
 that with a huge grain of salt, it's just my personal viewpoint :) ).


 * Nobody believes that we can do it, you'll hear a lot of moaning about
 how much work it is. My reply to that is: And Linux is such a piece of
 cake right? It's only the most widely used kernel on the planet.


 I think the lesson with Linux is that one person initially did a lot
 of heavy lifting, and then others joined in. I doubt it would work as
 it did if instead Linus opened a thread asking for a team of
 developers to create a new OS from scratch.

 Anyway, there's no doubt a D GUI would be a huge undertaking. There
 would almost certainly be a lot of rewriting involved. It's very easy
 to make mistakes early on and hardcode something, only later to
 realize it's way too brittle so it requires a rewrite. If the system
 is modular enough then the rewrites become less painful. And if the
 system is properly unit tested then regressions become less likely,
 and this is important.


It's not the rewriting itself that bothers me, I've worked on enough team  
projects to know that it's nigh inevitable. My point was just that a good  
design process can reduce the amount of rewriting that happens by keeping  
a clear focus on the end goal and being willing to say "no".


 From what I've seen when a codebase becomes large enough, what
 inevitably happens is people stop hacking on the codebase almost
 entirely. It's usually because the codebase is huge and not modular,
 or undocumented, or not tested, or doesn't have any sort of schedule
 on the work that needs to be done.

 I have zero doubt that we have the know-how or hacking ability to
 actually work and solve GUI problems in D, but I have big doubts that
 we would ever have leadership that would make sure we have a proper
 schedule and todo list, proper discussions, the guts to say "no" to
 features, etc. It's just not going to work if people randomly create
 pull requests with some code they thought would be nice to include in
 a GUI library.

 So to actually do it, I think we need:

 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

 2) Solid leadership.








say that they have the technical chops to make it happen. I mean how many  
of us actually do GUI coding every day? I know I do, but I don't think  
that is enough to qualify one as a leader. We also need a vision and  
developer commitment.

I'd be willing to lead the project, I'm just not sure I am the right  
person to do so. I have a vision, and the skeleton of a design, but no  
code. I am willing, but my ability is a question mark...

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
next sibling parent reply Peter Williams <pwil3058 bigpond.net.au> writes:
On 21/05/13 08:49, Adam Wilson wrote:

 I'd be willing to lead the project, I'm just not sure I am the right
 person to do so. I have a vision, and the skeleton of a design, but no
 code. I am willing, but my ability is a question mark...


I'd volunteer to be a foot soldier on this project as I'd like D to have 
a useful GUI capability.  At the moment, my experience of GUI 
programming is at the user of the API end of the spectrum (mostly using 
PyGTK to write GUI wrappers for command line programs to make my life 
easier) but I think I'm a quick learner.  Also as a GUI API user I have 
some idea of the sorts of thing that make a good API.

If D had a usable GUI API I would port at least one of my current PyGTK 
programs to D as it would benefit from better number crunching 
capability than Python possesses.

So, if this gets up, give me a call.
Peter
May 20 2013
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 16:50:47 -0700, Peter Williams  
<pwil3058 bigpond.net.au> wrote:


 On 21/05/13 08:49, Adam Wilson wrote:

 I'd be willing to lead the project, I'm just not sure I am the right
 person to do so. I have a vision, and the skeleton of a design, but no
 code. I am willing, but my ability is a question mark...


 I'd volunteer to be a foot soldier on this project as I'd like D to have  
 a useful GUI capability.  At the moment, my experience of GUI  
 programming is at the user of the API end of the spectrum (mostly using  
 PyGTK to write GUI wrappers for command line programs to make my life  
 easier) but I think I'm a quick learner.  Also as a GUI API user I have  
 some idea of the sorts of thing that make a good API.

 If D had a usable GUI API I would port at least one of my current PyGTK  
 programs to D as it would benefit from better number crunching  
 capability than Python possesses.

 So, if this gets up, give me a call.
 Peter


I'd love to get this up and running but I think we've got a blocker right  
now in D and that is the lack of package import, the GUI system is going  
to be a monster no matter how it's sliced and I'd lack to avoid the  
std.datetime effect. Sorry Jonathan Davis!

Once we get package import into D we can start building out the basics. Do  
you have any experience with concurrent hashmaps by chance? Or any other  
types of containers?

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
parent reply Peter Williams <pwil3058 bigpond.net.au> writes:
On 21/05/13 12:53, Adam Wilson wrote:

 On Mon, 20 May 2013 16:50:47 -0700, Peter Williams
 <pwil3058 bigpond.net.au> wrote:


 On 21/05/13 08:49, Adam Wilson wrote:

 I'd be willing to lead the project, I'm just not sure I am the right
 person to do so. I have a vision, and the skeleton of a design, but no
 code. I am willing, but my ability is a question mark...


 I'd volunteer to be a foot soldier on this project as I'd like D to
 have a useful GUI capability.  At the moment, my experience of GUI
 programming is at the user of the API end of the spectrum (mostly
 using PyGTK to write GUI wrappers for command line programs to make my
 life easier) but I think I'm a quick learner.  Also as a GUI API user
 I have some idea of the sorts of thing that make a good API.

 If D had a usable GUI API I would port at least one of my current
 PyGTK programs to D as it would benefit from better number crunching
 capability than Python possesses.

 So, if this gets up, give me a call.
 Peter


 I'd love to get this up and running but I think we've got a blocker
 right now in D and that is the lack of package import,
 the GUI system is
 going to be a monster no matter how it's sliced and I'd lack to avoid
 the std.datetime effect. Sorry Jonathan Davis!


Why do you need package import?  Can't you achieve the equivalent by 
having one module that imports all the others publicly leaving the 
application programmer only one module to import?


 Once we get package import into D we can start building out the basics.
 Do you have any experience with concurrent hashmaps by chance?


No. Why do you want concurrency? Aren't associative arrays hashmaps?  My 
only experience with hashing techniques (other than as an end user of 
classes/functions/features using them) was implementing git binary 
patches in Python for use in one of my GUIs.


 Or any
 other types of containers?


I implemented a "left leaning red black" tree in Go (as a basis for 
implementing various "set" containers) a while back before I abandoned 
Go due to their silly "inject ';' at the end of lines" hack in the 
lexical analyser.  Also, the basis of my PhD thesis was the equivalent 
of an optimal redundant discrimination tree which is a kind of container 
albeit fairly specialised.

Peter
May 20 2013
next sibling parent reply "Tyler Jameson Little" <beatgammit gmail.com> writes:
 I'd love to get this up and running but I think we've got a 
 blocker
 right now in D and that is the lack of package import,
 the GUI system is
 going to be a monster no matter how it's sliced and I'd lack 
 to avoid
 the std.datetime effect. Sorry Jonathan Davis!


 Why do you need package import?  Can't you achieve the 
 equivalent by having one module that imports all the others 
 publicly leaving the application programmer only one module to 
 import?


I also agree. But a package import is in the works apparently, so 
by the time something is ready to show, the feature will be 
there. Just shim for now (with an all.d or whatever) and get 
stuff done. I think we're looking at a 1yr or so investment 
before trying to include in Phobos becomes a consideration.


 Once we get package import into D we can start building out 
 the basics.
 Do you have any experience with concurrent hashmaps by chance?


 No. Why do you want concurrency? Aren't associative arrays 
 hashmaps?  My only experience with hashing techniques (other 
 than as an end user of classes/functions/features using them) 
 was implementing git binary patches in Python for use in one of 
 my GUIs.


I agree. UIs are asynchronous by nature, not concurrent. If we 
agree on this premise, basic associative arrays can be used, and 
all access to them can be guarded by a simple mutex.

I'm completely willing to head up the initial development. I 
probably won't get anything done, and any initial work will be 
Linux-specific (I honestly don't care about Mac OS X or Windows). 
If anything does get done, I'll definitely come back here to get 
help on the design. I'm willing to do some leg-work, but I'm not 
experienced in any way, shape or form with GUI development (most 
of my work is server-type stuff in Go or front-end stuff in 
JS/HTML5/CSS3).

If we're generally in agreement that a UI toolkit is a good 
direction, I'd love to waste the next few months of my life doing 
something that likely won't go anywhere. I personally think it's 
much more exciting to make something in native D instead of 
trying to work around the lack of concern other C++ toolkits like 
Qt have for cross-language portability.
May 20 2013
next sibling parent Peter Williams <pwil3058 bigpond.net.au> writes:
On 21/05/13 13:46, Tyler Jameson Little wrote:

 I'm completely willing to head up the initial development. I probably
 won't get anything done, and any initial work will be Linux-specific (I
 honestly don't care about Mac OS X or Windows).


Nor me, really.

Nevertheless, I've found using PyGTK means that my GUIs run on 
Mac/Windows provided the users are able to install the command line 
packages that they're wrappers for (where that's necessary).  I will 
admit that I had to do a very small bit of Windows specific code to 
properly run CLI commands and capture their output (20 or 30 lines).


 If anything does get
 done, I'll definitely come back here to get help on the design. I'm
 willing to do some leg-work, but I'm not experienced in any way, shape
 or form with GUI development (most of my work is server-type stuff in Go
 or front-end stuff in JS/HTML5/CSS3).

 If we're generally in agreement that a UI toolkit is a good direction,
 I'd love to waste the next few months of my life doing something that
 likely won't go anywhere. I personally think it's much more exciting to
 make something in native D instead of trying to work around the lack of
 concern other C++ toolkits like Qt have for cross-language portability.


Yes, if D aspires to be a systems programming language it can't keep 
relying on wrappers around C/C++ libraries (especially C++).  In the 
long term, it should be D all the way down to the OS API.

Peter
May 20 2013
prev sibling next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 20:46:48 -0700, Tyler Jameson Little  
<beatgammit gmail.com> wrote:


 I'd love to get this up and running but I think we've got a blocker
 right now in D and that is the lack of package import,
 the GUI system is
 going to be a monster no matter how it's sliced and I'd lack to avoid
 the std.datetime effect. Sorry Jonathan Davis!


 Why do you need package import?  Can't you achieve the equivalent by  
 having one module that imports all the others publicly leaving the  
 application programmer only one module to import?


 I also agree. But a package import is in the works apparently, so by the  
 time something is ready to show, the feature will be there. Just shim  
 for now (with an all.d or whatever) and get stuff done. I think we're  
 looking at a 1yr or so investment before trying to include in Phobos  
 becomes a consideration.


 Once we get package import into D we can start building out the basics.
 Do you have any experience with concurrent hashmaps by chance?


 No. Why do you want concurrency? Aren't associative arrays hashmaps?   
 My only experience with hashing techniques (other than as an end user  
 of classes/functions/features using them) was implementing git binary  
 patches in Python for use in one of my GUIs.


 I agree. UIs are asynchronous by nature, not concurrent. If we agree on  
 this premise, basic associative arrays can be used, and all access to  
 them can be guarded by a simple mutex.



concurrent data mutation at the end that might be more useful than a  
global lock, which has some pretty disturbing implications for  
high-performance rendering code.


 I'm completely willing to head up the initial development. I probably  
 won't get anything done, and any initial work will be Linux-specific (I  
 honestly don't care about Mac OS X or Windows). If anything does get  
 done, I'll definitely come back here to get help on the design. I'm  
 willing to do some leg-work, but I'm not experienced in any way, shape  
 or form with GUI development (most of my work is server-type stuff in Go  
 or front-end stuff in JS/HTML5/CSS3).


As far as rendering goes I was think about designing something pluggable,  
so it would have to follow a defined interface. It might be good to at  
least sketch out what that interface needs. It should be as simple as  
possible, basically just the primitives and anything needed to accurately  
render the visual tree.


 If we're generally in agreement that a UI toolkit is a good direction,  
 I'd love to waste the next few months of my life doing something that  
 likely won't go anywhere. I personally think it's much more exciting to  
 make something in native D instead of trying to work around the lack of  
 concern other C++ toolkits like Qt have for cross-language portability.


I can't tell if this is snark or not so I'll assume it isn't. :-) I don't  
know how likely cross-language portability is to be achieved by any UI  
toolkit, way to many things that need more advanced language features. If  
we use D we'd probably end-up using a non-portable set of language  
features anyways...

It'd be nice, but given how constraining C++ is compared to D it might not  
be practical in the long run. Although the rendering interface might be  
able to plug with D. That should be simple enough...

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
next sibling parent "Diggory" <diggsey googlemail.com> writes:

 pattern for concurrent data mutation at the end that might be 
 more useful than a global lock, which has some pretty 
 disturbing implications for high-performance rendering code.


I can't help but feel that making them concurrent is going to 
provide very marginal benefits. Rendering code is already 
essentially concurrent since you don't usually block until the 
GPU is done rendering, you just tell it what to do and let it get 
on with it.

Also, there's no point doing multiple renders per UI update 
because you'll just be drawing the same thing, and no point doing 
multiple UI updates per render because in the end only the most 
recent update will be shown. Anything other than sequentially 
executing "render -> update -> render -> update" is redundant.

To me it makes more sense to do all the updating and rendering in 
a background thread with a thin layer over the top to hide the 
details of synchronising with this background thread from the 
programmer.
May 20 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 20 May 2013 23:00:10 -0700
"Adam Wilson" <flyboynw gmail.com> wrote:


 On Mon, 20 May 2013 20:46:48 -0700, Tyler Jameson Little  
 <beatgammit gmail.com> wrote:
 

 If we're generally in agreement that a UI toolkit is a good
 direction, I'd love to waste the next few months of my life doing
 something that likely won't go anywhere. I personally think it's
 much more exciting to make something in native D instead of trying
 to work around the lack of concern other C++ toolkits like Qt have
 for cross-language portability.


 
 I can't tell if this is snark or not so I'll assume it isn't. :-) I
 don't know how likely cross-language portability is to be achieved by
 any UI toolkit, way to many things that need more advanced language
 features. If we use D we'd probably end-up using a non-portable set
 of language features anyways...
 
 It'd be nice, but given how constraining C++ is compared to D it
 might not be practical in the long run. Although the rendering
 interface might be able to plug with D. That should be simple
 enough...
 


I was thinking that starting out by building off of bindings to a C/C++
library could be a good idea for two reasons:

- Hedging bets. If the D-ification runs into any problems (either the
  project as a whole, or just a specific problem that a user needs to
  temporarily work around), there's always the raw binding to fall back
  on. Besides, any brand-new API/lib is naturally going to be riskier
  than bindings to a proven one.

- Bootstrapping. I find that building off an existing thing, even if
  you just end up replacing it with a homemade solution later
  (usually piecemeal), helps get the project jump-started, which gets
  you to more important things (such as a usable/stable state) earlier,
  which also helps maintain morale and momentum.
May 20 2013
prev sibling parent "Tyler Jameson Little" <beatgammit gmail.com> writes:
 I can't tell if this is snark or not so I'll assume it isn't. 
 :-) I don't know how likely cross-language portability is to be 
 achieved by any UI toolkit, way to many things that need more 
 advanced language features. If we use D we'd probably end-up 
 using a non-portable set of language features anyways...

 It'd be nice, but given how constraining C++ is compared to D 
 it might not be practical in the long run. Although the 
 rendering interface might be able to plug with D. That should 
 be simple enough...


A little bit of snark, but there's some truth there. I realize 
that my work will likely come to naught, but I think it's an 
interesting project none-the-less. I'm tired of the industry's 
focus on C++, and it seems that most people have come to accept 
it. C++ devs I know would gladly move to D, if it had proper 
tools, such as a GUI library.

Personally I hate C++; I find it to be a terribly confusing 
language with no real benefit, except the availability of 
libraries, which isn't even a language feature. I do, however, 
think that whatever D uses should be relatively portable. I'm not 
sure how easy it is to import D code into C++, but it seems to be 
possible.

Maybe I'll just have a go and check back once you're done with 
you're bickering ;)
May 20 2013
prev sibling next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 5/20/13 9:49 PM, Peter Williams wrote:

 Yes, if D aspires to be a systems programming language it can't keep
 relying on wrappers around C/C++ libraries (especially C++).  In the
 long term, it should be D all the way down to the OS API.


You wrote this as if not using c and c++ libraries is a predicate for 
being a systems language.  It's not.

What's with the D community's (yes, I'm over generalizing some) 
not-invented-here syndrome?  Avoiding the incredible body of existing 
code out there that's accumulated over the decades is foolhardy and 
narrow sighted.  Are all c and c++ libraries great bodies of code, 
absolutely not.  Is some of the code that predates D worth reusing, yup.

Sigh,
Brad
May 20 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 20 May 2013 23:21:28 -0700
Brad Roberts <braddr puremagic.com> wrote:


 On 5/20/13 9:49 PM, Peter Williams wrote:

 Yes, if D aspires to be a systems programming language it can't keep
 relying on wrappers around C/C++ libraries (especially C++).  In the
 long term, it should be D all the way down to the OS API.


 
 You wrote this as if not using c and c++ libraries is a predicate for 
 being a systems language.  It's not.
 
 What's with the D community's (yes, I'm over generalizing some) 
 not-invented-here syndrome?


Conditioned aversion to C++? (half-serious)


 Avoiding the incredible body of existing 
 code out there that's accumulated over the decades is foolhardy and 
 narrow sighted.  Are all c and c++ libraries great bodies of code, 
 absolutely not.  Is some of the code that predates D worth reusing,
 yup.
 
 Sigh,
 Brad
May 20 2013
parent Peter Williams <pwil3058 bigpond.net.au> writes:
On 21/05/13 16:35, Nick Sabalausky wrote:

 On Mon, 20 May 2013 23:21:28 -0700
 Brad Roberts <braddr puremagic.com> wrote:


 On 5/20/13 9:49 PM, Peter Williams wrote:

 Yes, if D aspires to be a systems programming language it can't keep
 relying on wrappers around C/C++ libraries (especially C++).  In the
 long term, it should be D all the way down to the OS API.


 You wrote this as if not using c and c++ libraries is a predicate for
 being a systems language.  It's not.

 What's with the D community's (yes, I'm over generalizing some)
 not-invented-here syndrome?


 Conditioned aversion to C++? (half-serious)


 Avoiding the incredible body of existing
 code out there that's accumulated over the decades is foolhardy and
 narrow sighted.  Are all c and c++ libraries great bodies of code,
 absolutely not.  Is some of the code that predates D worth reusing,
 yup.




Don't think of it as reinventing.  Think of it as reimplementing.

After all that's what we've done with wheels over the millennia.

Peter
May 21 2013
prev sibling parent reply Peter Williams <pwil3058 bigpond.net.au> writes:
On 21/05/13 16:21, Brad Roberts wrote:

 On 5/20/13 9:49 PM, Peter Williams wrote:

 Yes, if D aspires to be a systems programming language it can't keep
 relying on wrappers around C/C++ libraries (especially C++).  In the
 long term, it should be D all the way down to the OS API.


 You wrote this as if not using c and c++ libraries is a predicate for
 being a systems language.  It's not.


It is for me. I also won't count D as a systems language until DMD is 
implemented in D.


 What's with the D community's (yes, I'm over generalizing some)
 not-invented-here syndrome?  Avoiding the incredible body of existing
 code out there that's accumulated over the decades is foolhardy and
 narrow sighted.


I did say "in the long term".


 Are all c and c++ libraries great bodies of code,
 absolutely not.


I am not a fan of C++ (and don't really trust C++ libraries).  I went to 
C++ from Modula-2 due to job constraints but eventually ditched it and 
moved on to C - yes, I went from C++ to C.  The main reasons were that I 
felt C++ caused more problems than it cured.  Plain C is a perfectly 
good language for OOP as GTK+ demonstrates and there's no need for all 
the complexity that comes with C++.


  Is some of the code that predates D worth reusing, yup.


Yes, but "in the long term" it should be replaced by D code so that you 
get all the many advantages (better testing, contracts, simplicity, 
etc.) that brings.  Redo the ones that suck first but do them all 
eventually.

Peter
May 20 2013
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 21 May 2013 at 06:39:39 UTC, Peter Williams wrote:

 On 21/05/13 16:21, Brad Roberts wrote:

 On 5/20/13 9:49 PM, Peter Williams wrote:

 Yes, if D aspires to be a systems programming language it 
 can't keep
 relying on wrappers around C/C++ libraries (especially C++).  
 In the
 long term, it should be D all the way down to the OS API.


 You wrote this as if not using c and c++ libraries is a 
 predicate for
 being a systems language.  It's not.


 It is for me. I also won't count D as a systems language until 
 DMD is implemented in D.


 What's with the D community's (yes, I'm over generalizing some)
 not-invented-here syndrome?  Avoiding the incredible body of 
 existing
 code out there that's accumulated over the decades is 
 foolhardy and
 narrow sighted.


 I did say "in the long term".


 Are all c and c++ libraries great bodies of code,
 absolutely not.


 I am not a fan of C++ (and don't really trust C++ libraries).  
 I went to C++ from Modula-2 due to job constraints but 
 eventually ditched it and moved on to C - yes, I went from C++ 
 to C.  The main reasons were that I felt C++ caused more 
 problems than it cured.  Plain C is a perfectly good language 
 for OOP as GTK+ demonstrates and there's no need for all the 
 complexity that comes with C++.


I went from Turbo Pascal to C++, with a very short stop on C.

Security exploits by design? No thanks. C++ might still have the 
C security quicksand underneath, but at the same time it offers 
more secure constructs.

Of course the best way would be to drop C and C++ altogether, but 
it will take a few decades I would say.

--
Paulo
May 21 2013
prev sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 20:26:33 -0700, Peter Williams  
<pwil3058 bigpond.net.au> wrote:


 On 21/05/13 12:53, Adam Wilson wrote:

 On Mon, 20 May 2013 16:50:47 -0700, Peter Williams
 <pwil3058 bigpond.net.au> wrote:


 On 21/05/13 08:49, Adam Wilson wrote:

 I'd be willing to lead the project, I'm just not sure I am the right
 person to do so. I have a vision, and the skeleton of a design, but no
 code. I am willing, but my ability is a question mark...


 I'd volunteer to be a foot soldier on this project as I'd like D to
 have a useful GUI capability.  At the moment, my experience of GUI
 programming is at the user of the API end of the spectrum (mostly
 using PyGTK to write GUI wrappers for command line programs to make my
 life easier) but I think I'm a quick learner.  Also as a GUI API user
 I have some idea of the sorts of thing that make a good API.

 If D had a usable GUI API I would port at least one of my current
 PyGTK programs to D as it would benefit from better number crunching
 capability than Python possesses.

 So, if this gets up, give me a call.
 Peter


 I'd love to get this up and running but I think we've got a blocker
 right now in D and that is the lack of package import,
 the GUI system is
 going to be a monster no matter how it's sliced and I'd lack to avoid
 the std.datetime effect. Sorry Jonathan Davis!


 Why do you need package import?  Can't you achieve the equivalent by  
 having one module that imports all the others publicly leaving the  
 application programmer only one module to import?


You can but it's a hack that doesn't always work well. That said for  
initial development it would work fine.


 Once we get package import into D we can start building out the basics.
 Do you have any experience with concurrent hashmaps by chance?


 No. Why do you want concurrency? Aren't associative arrays hashmaps?  My  
 only experience with hashing techniques (other than as an end user of  
 classes/functions/features using them) was implementing git binary  
 patches in Python for use in one of my GUIs.


Well, it comes down to how you want to render. My preferred solution  
woulbd be a rendering thread running all the time doing nothing but the  
GPU leg-work, then have a UI thread thread were the work of maintaining  
the UI would get done. That thread would periodically update the render  
thread. I discussed a concurrent data mutation pattern in my DConf talk  
that could be used to make this update process simpler and less error  
prone (lock avoidance). It'll probably be online next week or the one  
after.


 Or any
 other types of containers?


 I implemented a "left leaning red black" tree in Go (as a basis for  
 implementing various "set" containers) a while back before I abandoned  
 Go due to their silly "inject ';' at the end of lines" hack in the  
 lexical analyser.  Also, the basis of my PhD thesis was the equivalent  
 of an optimal redundant discrimination tree which is a kind of container  
 albeit fairly specialised.

 Peter


Interesting... :-)

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/21/13, Adam Wilson <flyboynw gmail.com> wrote:

 Well, it comes down to how you want to render. My preferred solution
 woulbd be a rendering thread running all the time doing nothing but the
 GPU leg-work


Why a GPU? Aren't most GUIs static? And aren't there issues with GPUs
where feature X isn't supported on all GPUs or is buggy on a
particular one (e.g. driver issues)? Or maybe that was true in the
past, I was out of the loop for a while. :)
May 21 2013
parent reply "Kiith-Sa" <kiithsacmp gmail.com> writes:
On Tuesday, 21 May 2013 at 11:06:44 UTC, Andrej Mitrovic wrote:

 On 5/21/13, Adam Wilson <flyboynw gmail.com> wrote:

 Well, it comes down to how you want to render. My preferred 
 solution
 woulbd be a rendering thread running all the time doing 
 nothing but the
 GPU leg-work


 Why a GPU? Aren't most GUIs static? And aren't there issues 
 with GPUs
 where feature X isn't supported on all GPUs or is buggy on a
 particular one (e.g. driver issues)? Or maybe that was true in 
 the
 past, I was out of the loop for a while. :)


If you only use basic features (everything you need for GUI), 
you're not going to have issues. In any case if you go the GPU 
route it's best to isolate the GPU code behind an interface so 
you can add a software implementation later if absolutely 
necessary.

I think the best idea is to stop arguing and just do something. I 
recommend trying a minimalist project (at most Clutter sized) 
instead of something massive like Qt that's likely never going to 
see the light of day. Implement the basics, create a few example 
apps, and _then_ start a discussion. You might not get a perfect 
library/framework, but at least you'll get something that exists 
instead of an infinite flame war getting nowhere as is the 
tradition in the D world. Getting more than one contributor _and_ 
not stopping work on it is going to be the main issue, there've 
been a few D GUI attempts and they're mostly dead due to lost 
interest.

My (subjective) preferences:

* Human-readable markup, not just through a tool (a tool can be 
built later). YAML and JSON work well here.

* Look at Hybrid API. Clutter and Qt also have nice APIs, but D 
allows some things not possible there.

* Library instead of a framework - one of things I like about the 
Hybrid design
May 21 2013
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 21 May 2013 13:33:18 +0200
"Kiith-Sa" <kiithsacmp gmail.com> wrote:

 
 My (subjective) preferences:
 
 * Human-readable markup, not just through a tool (a tool can be 
 built later). YAML and JSON work well here.
 


*cough* SDL <https://github.com/Abscissa/SDLang-D> *wink, wink, nudge,
nudge* ;)


 * Look at Hybrid API. Clutter and Qt also have nice APIs,


I will! I've never heard of Clutter before. Or some of the other ones
that have been mentioned in this thread (Fox, IUP).
May 21 2013
prev sibling parent reply "Tyler Jameson Little" <beatgammit gmail.com> writes:
On Tuesday, 21 May 2013 at 11:33:19 UTC, Kiith-Sa wrote:

 On Tuesday, 21 May 2013 at 11:06:44 UTC, Andrej Mitrovic wrote:

 On 5/21/13, Adam Wilson <flyboynw gmail.com> wrote:

 Well, it comes down to how you want to render. My preferred 
 solution
 woulbd be a rendering thread running all the time doing 
 nothing but the
 GPU leg-work


 Why a GPU? Aren't most GUIs static? And aren't there issues 
 with GPUs
 where feature X isn't supported on all GPUs or is buggy on a
 particular one (e.g. driver issues)? Or maybe that was true in 
 the
 past, I was out of the loop for a while. :)


 If you only use basic features (everything you need for GUI), 
 you're not going to have issues. In any case if you go the GPU 
 route it's best to isolate the GPU code behind an interface so 
 you can add a software implementation later if absolutely 
 necessary.

 I think the best idea is to stop arguing and just do something. 
 I recommend trying a minimalist project (at most Clutter sized) 
 instead of something massive like Qt that's likely never going 
 to see the light of day. Implement the basics, create a few 
 example apps, and _then_ start a discussion. You might not get 
 a perfect library/framework, but at least you'll get something 
 that exists instead of an infinite flame war getting nowhere as 
 is the tradition in the D world. Getting more than one 
 contributor _and_ not stopping work on it is going to be the 
 main issue, there've been a few D GUI attempts and they're 
 mostly dead due to lost interest.

 My (subjective) preferences:

 * Human-readable markup, not just through a tool (a tool can be 
 built later). YAML and JSON work well here.

 * Look at Hybrid API. Clutter and Qt also have nice APIs, but D 
 allows some things not possible there.

 * Library instead of a framework - one of things I like about 
 the Hybrid design
May 21 2013
parent "Tyler Jameson Little" <beatgammit gmail.com> writes:
Oops, sorry for the empty message.


 I think the best idea is to stop arguing and just do something. 
 I recommend trying a minimalist project (at most Clutter sized) 
 instead of something massive like Qt that's likely never going 
 to see the light of day. Implement the basics, create a few 
 example apps, and _then_ start a discussion. You might not get 
 a perfect library/framework, but at least you'll get something 
 that exists instead of an infinite flame war getting nowhere as 
 is the tradition in the D world. Getting more than one 
 contributor _and_ not stopping work on it is going to be the 
 main issue, there've been a few D GUI attempts and they're 
 mostly dead due to lost interest.


This was the direction I was thinking of going. Do something 
simple like Clutter (or even just a part of it), get something 
usable, then decide where we want to go from there.

This should keep it reasonably scoped so that it may stand a 
chance of getting done.


 My (subjective) preferences:

 * Human-readable markup, not just through a tool (a tool can 
 be built later). YAML and JSON work well here.




Definitely. This makes source control a lot more effective, 
because I'd have a chance of understanding what's going on in the 
markup.


 * Look at Hybrid API. Clutter and Qt also have nice APIs, but 
 D allows some things not possible there.

 * Library instead of a framework - one of things I like about 
 the Hybrid design




Clutter does have a nice API, and I think that's a good place to 
start. I'll have to study it a bit before attempting an 
implementation. Qt is just such a beast though.
May 21 2013
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 20 May 2013 15:49:48 -0700
"Adam Wilson" <flyboynw gmail.com> wrote:


 On Mon, 20 May 2013 14:47:47 -0700, Andrej Mitrovic  
 <andrej.mitrovich gmail.com> wrote:

 So to actually do it, I think we need:

 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

 2) Solid leadership.





 

 

 could say that they have the technical chops to make it happen. I
 mean how many of us actually do GUI coding every day? I know I do,
 but I don't think that is enough to qualify one as a leader. We also
 need a vision and developer commitment.
 
 I'd be willing to lead the project, I'm just not sure I am the right  
 person to do so. I have a vision, and the skeleton of a design, but
 no code. I am willing, but my ability is a question mark...
 


If only vision and willingness weren't the easy, plentiful
parts :(  Believe me, I'm in the same boat.
May 20 2013
parent "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 18:12:20 -0700, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:


 On Mon, 20 May 2013 15:49:48 -0700
 "Adam Wilson" <flyboynw gmail.com> wrote:


 On Mon, 20 May 2013 14:47:47 -0700, Andrej Mitrovic
 <andrej.mitrovich gmail.com> wrote:

 So to actually do it, I think we need:

 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

 2) Solid leadership.








 could say that they have the technical chops to make it happen. I
 mean how many of us actually do GUI coding every day? I know I do,
 but I don't think that is enough to qualify one as a leader. We also
 need a vision and developer commitment.

 I'd be willing to lead the project, I'm just not sure I am the right
 person to do so. I have a vision, and the skeleton of a design, but
 no code. I am willing, but my ability is a question mark...


 If only vision and willingness weren't the easy, plentiful
 parts :(  Believe me, I'm in the same boat.


Hehe. Sad but true. Why do you think I am hesitant. :-)

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 20 May 2013 23:47:47 +0200
Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:


 On 5/20/13, Adam Wilson <flyboynw gmail.com> wrote:

 * There is a deep-seated distrust of any toolkit that does not use
 the OS Native UI widgets.


=20
 That's a shame. If you go native you'll have the "look and feel", but
 you'll have X times the work where X is the number of platforms
 supported. Also, each platform has its own bugs, so you'd have to
 write a lot of workaround code as well (e.g. wxWidgets is full of
 win32 workarounds).
=20
 Doing it non-native slows you down at first, but it gives you a lot
 more control on how you can render things. You can add a feature
 without having to worry on how to port the feature to other platforms.
 And finally, you can simulate the native windowing environment.
=20


While non-native does have certain potential benefits, it's ultimately
an inherently-flawed approach because the whole "simulate the native"
starts becoming under-valued.

This under-valuing is inevitable because not only is "simulate the
native" far harder to get right than it seems, but it turns
out not to even be realistically possible in many cases that aren't
immediately obvious, but are nonetheless important.

This inevitable "under-valuing" of "simulate the native" is
necessarily an erosion of respect for the user's property and
preferences. The convenience of the toolkit's developers, and app's
developers *becomes* the "center of the universe" so to speak.


technology has already failed it's raison d'=EAtre. At that point,
nothing else matters and it's all becomes pointless waste of time.

tl;dr: Developing a non-native GUI is a cheap shortcut. The hidden cost
comes as severely diminished value for all software that uses it,
thus ultimately wasting everyone's time, including the toolkit's
original developers.


 Just to mention this, we already have native libraries (and written in
 D without wrapping C++ libs) such as DGUI, DFL, DWT. I hardly find
 them successful, they get the occasional pull request, but otherwise
 they seem to lack any sort of team effort or going-forward schedule.
 So I'd say going "native" has already been a failed experiment (take
 that with a huge grain of salt, it's just my personal viewpoint :) ).
=20


By the same token, we don't have any non-native GUIs in D that have
fared any better.


=20
 I have zero doubt that we have the know-how or hacking ability to
 actually work and solve GUI problems in D, but I have big doubts that
 we would ever have leadership that would make sure we have a proper
 schedule and todo list, proper discussions, the guts to say "no" to
 features, etc. It's just not going to work if people randomly create
 pull requests with some code they thought would be nice to include in
 a GUI library.
=20


I tend to feel the same way, to be honest.

Or rather, I suspect we may actually have the potential leadership, but
any such people are struggling to find the necessary time to
dedicate to it. Leadership is more than just the willingness and
ability to lead, but also about having the time (and any other
needed resources) with which to do it.
May 20 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-20 23:47, Andrej Mitrovic wrote:


 Just to mention this, we already have native libraries (and written in
 D without wrapping C++ libs) such as DGUI, DFL, DWT. I hardly find
 them successful, they get the occasional pull request, but otherwise
 they seem to lack any sort of team effort or going-forward schedule.
 So I'd say going "native" has already been a failed experiment (take
 that with a huge grain of salt, it's just my personal viewpoint :) ).


I hardly believe it has anything to do with being a (native) GUI 
library. Most D projects look like this.

-- 
/Jacob Carlborg
May 21 2013
next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Tuesday, 21 May 2013 at 09:29:36 UTC, Jacob Carlborg wrote:

 I hardly believe it has anything to do with being a (native) 
 GUI library. Most D projects look like this.


I'd say it is about having a persistent user. If project floats 
around as an abstract one without any frequent practical 
application and demands for improvements, it can become very hard 
to move forward.
May 21 2013
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/21/13, Jacob Carlborg <doob me.com> wrote:

 On 2013-05-20 23:47, Andrej Mitrovic wrote:


 Just to mention this, we already have native libraries (and written in
 D without wrapping C++ libs) such as DGUI, DFL, DWT. I hardly find
 them successful, they get the occasional pull request, but otherwise
 they seem to lack any sort of team effort or going-forward schedule.
 So I'd say going "native" has already been a failed experiment (take
 that with a huge grain of salt, it's just my personal viewpoint :) ).


 I hardly believe it has anything to do with being a (native) GUI
 library. Most D projects look like this.


Heh, yeah, you're probably right.
May 21 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-05-20 20:01, Adam Wilson wrote:


 A UI toolkit in D would be a fantastic showcase for demonstrating just
 how powerful D is. But make no mistake, it will not be easy getting it
 done.


I agree. It's a massive amount of work. Before we can even think if 
starting a project like this there are a lot of things needed to be 
implemented and fixed. I don't keep list of these things but, I'm 
thinking: runtime reflection, ABI compatible with Objective-C (this is 
really needed before doing any work on Mac OS X), other similar things 
that can be implemented regardless if the GUI toolkit gets implemented.

-- 
/Jacob Carlborg
May 21 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-20 20:01, Adam Wilson wrote:


 So I've been around D a while pushing for native D UI toolkit. And here
 are a few trends I've seen in the community.


BTW, how do you intend the controls to behave:

* Emulate the behavior of each platform
* Picking one platform and emulate that across all platforms
* Doing something completely custom

?

-- 
/Jacob Carlborg
May 21 2013
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Tue, 21 May 2013 11:40:15 -0700, Jacob Carlborg <doob me.com> wrote:


 On 2013-05-20 20:01, Adam Wilson wrote:


 So I've been around D a while pushing for native D UI toolkit. And here
 are a few trends I've seen in the community.


 BTW, how do you intend the controls to behave:

 * Emulate the behavior of each platform
 * Picking one platform and emulate that across all platforms
 * Doing something completely custom

 ?


Controls will be completely "lookless". So a control is simply a class in  
code with no associated styling whatsoever. That means that "look" is  
defined entirely with styles. This presents us with the flexibility to  
automatically load the correct look and behavior for a platform by  
default, and then let the user override it with his own styles should he  
choose to do so.

In this plan styles, as with CSS, include much of the styling behavior too.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 21 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-21 20:48, Adam Wilson wrote:


 Controls will be completely "lookless". So a control is simply a class
 in code with no associated styling whatsoever. That means that "look" is
 defined entirely with styles. This presents us with the flexibility to
 automatically load the correct look and behavior for a platform by
 default, and then let the user override it with his own styles should he
 choose to do so.

 In this plan styles, as with CSS, include much of the styling behavior too.


I mean how the controls will behave, not the style. I.e. Windows doesn't 
support click/scroll through while most other systems do.

-- 
/Jacob Carlborg
May 21 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 21 May 2013 20:55:11 +0200
Jacob Carlborg <doob me.com> wrote:

 
 I mean how the controls will behave, not the style. I.e. Windows
 doesn't support click/scroll through while most other systems do.
 


What do you mean by "click/scroll through"?
May 21 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-21 21:47, Nick Sabalausky wrote:


 What do you mean by "click/scroll through"?


I can scroll in a window while having another window selected. I think I 
read you had a tool/application for that on Windows.

-- 
/Jacob Carlborg
May 21 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 21 May 2013 22:44:30 +0200
Jacob Carlborg <doob me.com> wrote:


 On 2013-05-21 21:47, Nick Sabalausky wrote:
 

 What do you mean by "click/scroll through"?  


 
 I can scroll in a window while having another window selected. I
 think I read you had a tool/application for that on Windows.
 


Oh, yea. That's one of my biggest annoyances on Windows. Makes no
sense, and only ever gets in the way. I use the freeware KatMouse to
fix that:

http://ehiti.de/katmouse/

It works great on XP, but on Win7 it only works about half the time
(even on the same program: it'll work one day, then have no effect
another time, and then work again some other time). Doesn't work at all
on Claws Mail, I suspect this may be an incompatibility with GTK
programs in general since they reinvent all the UI controls.

Unfortunately, KatMouse appears to be both abandonware (last update was
2007) and closed-source.

(I've never understood why people make closed-source freeware:
Closed-source commercial, ok. OSS, ok. But closed-source freeware?
Seems kinda pointless.)
May 21 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 21 May 2013 17:38:15 -0400
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:


 On Tue, 21 May 2013 22:44:30 +0200
 Jacob Carlborg <doob me.com> wrote:
 

 On 2013-05-21 21:47, Nick Sabalausky wrote:
 

 What do you mean by "click/scroll through"?  


 
 I can scroll in a window while having another window selected. I
 think I read you had a tool/application for that on Windows.
 


 
 Oh, yea. That's one of my biggest annoyances on Windows. Makes no
 sense, and only ever gets in the way. I use the freeware KatMouse to
 fix that:
 
 http://ehiti.de/katmouse/
 
 It works great on XP, but on Win7 it only works about half the time
 (even on the same program: it'll work one day, then have no effect
 another time, and then work again some other time). Doesn't work at
 all on Claws Mail, I suspect this may be an incompatibility with GTK
 programs in general since they reinvent all the UI controls.
 
 Unfortunately, KatMouse appears to be both abandonware (last update
 was 2007) and closed-source.
 
 (I've never understood why people make closed-source freeware:
 Closed-source commercial, ok. OSS, ok. But closed-source freeware?
 Seems kinda pointless.)
 


Strange, it seems to be working in Claws Mail now...

Oh, wait, now that I think about it, it wasn't KatMouse that didn't work
with Claws Mail, it was my touchpad's "circular motion to scroll"
feature. That's a great feature when I don't have my trackball plugged
into my laptop.
May 21 2013
prev sibling next sibling parent Byron Heads <byron.heads gmail.com> writes:
On Mon, 20 May 2013 07:25:49 +0200, Tyler Jameson Little wrote:


 I've been looking into trying to fix QtD, but it seems writing a binding
 to a C++ library is a bit complicated. I've read on the forums that a
 native D GUI toolkit is the most desirable long-term, so I'd like to
 start that discussion.
 
 First off, I've heard of the DWT project, which looks promising, but it
 seems like a direct port of Java's SWT instead of a reimagining using
 idiomatic D. I understand the allure here (works, little translation for
 new developers), but since it's not yet in Phobos, I can only assume
 it's still up for discussion.
 
 Personally, I want these features:
 
 * simple and extensible
    * minimal components (something like HTMLs feature-set)
    * custom components (embed OpenGL/direct frame buffer)
 * "native" window decorations by default, but can provide custom
 decorations * markup (like QML) or programmable (like SWT)
 
 Nice-to-haves:
 
 * hardware accelerated (2D OpenGL)
 * GUI designer (much easier with QML-esque markup)
 * part of Phobos
 
 I'm willing to lend a hand, but I'd like to know in what direction the
 community would like to go. I'd also like to know the likelihood of
 getting a GUI toolkit into Phobos.
 
 Thoughts?



FLTK might be easier the Qt.  Also libcairo maybe used if you build one 
yourself.
May 20 2013
prev sibling next sibling parent reply "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Monday, 20 May 2013 at 05:25:50 UTC, Tyler Jameson Little 
wrote:

 Thoughts?


I don't think it will make it in Phobos. At least not for a long 
time. It will first need to be proven and show a strong use in 
the community/world.

As said, it is a massive undertaking so people are skeptical and 
I like the point made that it will require collaboration from 
many knowledge areas.

Linux was mentioned. Just remember Linus is just building an OS 
for fun, trying to see if he can mimic Unix on his system. He 
doesn't have any interest in supporting hardware non-SCSI (or 
something like that) since he doesn't have a machine with that 
hardware. The fact that others are providing support for those 
things and he is merging them in is irrelevant.

I like DWT, but it is a lot to learn. I've been using DFL and 
wish to switch to DWT but re-writing my simple GUI isn't a 
priority. DWT could use a D face, but I'm ok with examples 
compiling with little change.
May 20 2013
parent reply "Diggory" <diggsey googlemail.com> writes:
UI toolkits are a lot of work but they're not as unreasonably big 
as everyone seems to be suggesting... I've written a couple 
myself in a procedural language using Direct3D to draw 
everything. Had all the standard controls, various layout 
options, even a syntax highlighted code editor, clipboard 
interaction, keyboard focus, etc.

The main difficulties with doing the same thing in opengl and 
making it cross platform seem to be:
- Font rendering, especially with support for the combining 
unicode characters and RTL languages. It would probably be worth 
finding an existing library for this.
- Making it consistent with the host OS, it would be possible to 
have a number of skins for each OS but that would probably be 
breaking all sorts of copyright rules. Generating the skin on the 
fly using the native drawing commands shouldn't be too hard...

On the other hand you get the advantages of hardware acceleration 
and pretty much unlimited custom drawing capabilities and I'd 
expect to see a lot of interesting custom controls out there. I'd 
definitely favour this option!

A native OS UI would be less work - although you'd effectively 
need to write an implementation specifically for each OS, the OS 
would take care of most of it for you. The main problems here 
would be getting consistent behaviour across all OSes and also it 
would be a lot of work to add controls that don't already exist 
in the OS.


What would be neat is if there was a CTFE based compiler which 
took some form of markup describing part of the UI and converted 
it to D code. That way you could mixin bits of UI markup either 
from files or string literals, directly into your classes and it 
would be really easy to hook up events and things.
May 20 2013
next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 13:40:06 -0700, Diggory <diggsey googlemail.com> wrote:


 UI toolkits are a lot of work but they're not as unreasonably big as  
 everyone seems to be suggesting... I've written a couple myself in a  
 procedural language using Direct3D to draw everything. Had all the  
 standard controls, various layout options, even a syntax highlighted  
 code editor, clipboard interaction, keyboard focus, etc.

 The main difficulties with doing the same thing in opengl and making it  
 cross platform seem to be:
 - Font rendering, especially with support for the combining unicode  
 characters and RTL languages. It would probably be worth finding an  
 existing library for this.
 - Making it consistent with the host OS, it would be possible to have a  
 number of skins for each OS but that would probably be breaking all  
 sorts of copyright rules. Generating the skin on the fly using the  
 native drawing commands shouldn't be too hard...

 On the other hand you get the advantages of hardware acceleration and  
 pretty much unlimited custom drawing capabilities and I'd expect to see  
 a lot of interesting custom controls out there. I'd definitely favour  
 this option!

 A native OS UI would be less work - although you'd effectively need to  
 write an implementation specifically for each OS, the OS would take care  
 of most of it for you. The main problems here would be getting  
 consistent behaviour across all OSes and also it would be a lot of work  
 to add controls that don't already exist in the OS.


 What would be neat is if there was a CTFE based compiler which took some  
 form of markup describing part of the UI and converted it to D code.  
 That way you could mixin bits of UI markup either from files or string  
 literals, directly into your classes and it would be really easy to hook  
 up events and things.


As far as I am concerned this is pretty much the only way to do it. D's  
CTFE gives us so much power in the markup->code translation phase we'd be  
terminally stupid not to use it. :-D

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 20 May 2013 22:40:06 +0200
"Diggory" <diggsey googlemail.com> wrote:

 
 The main difficulties with doing the same thing in opengl and 
 making it cross platform seem to be:


[...]

 
 On the other hand you get the advantages of hardware acceleration 
 and pretty much unlimited custom drawing capabilities and I'd 
 expect to see a lot of interesting custom controls out there. I'd 
 definitely favour this option!
 


These days, native UIs are already hardware accelerated. Aero is,
Quartz is, etc. There was a huge push towards this ten-plus years ago.
May 20 2013
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 14:44:04 -0700, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:


 On Mon, 20 May 2013 22:40:06 +0200
 "Diggory" <diggsey googlemail.com> wrote:

 The main difficulties with doing the same thing in opengl and
 making it cross platform seem to be:


 [...]

 On the other hand you get the advantages of hardware acceleration
 and pretty much unlimited custom drawing capabilities and I'd
 expect to see a lot of interesting custom controls out there. I'd
 definitely favour this option!


 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.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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? ;)
May 20 2013
parent "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 May 2013 15:44:06 -0700, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:


 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? ;)


Windows 8!!!!!!111111

:-S

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
May 20 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-20 22:40, Diggory wrote:

 UI toolkits are a lot of work but they're not as unreasonably big as
 everyone seems to be suggesting... I've written a couple myself in a
 procedural language using Direct3D to draw everything. Had all the
 standard controls, various layout options, even a syntax highlighted
 code editor, clipboard interaction, keyboard focus, etc.


I think you underestimate what's needed and the controls people want to 
have. Did you have date picker, color picker, support for 
internationalization, field formatters and so on.

-- 
/Jacob Carlborg
May 21 2013
next sibling parent reply "Diggory" <diggsey googlemail.com> writes:
On Tuesday, 21 May 2013 at 12:12:12 UTC, Jacob Carlborg wrote:

 On 2013-05-20 22:40, Diggory wrote:

 UI toolkits are a lot of work but they're not as unreasonably 
 big as
 everyone seems to be suggesting... I've written a couple 
 myself in a
 procedural language using Direct3D to draw everything. Had all 
 the
 standard controls, various layout options, even a syntax 
 highlighted
 code editor, clipboard interaction, keyboard focus, etc.


 I think you underestimate what's needed and the controls people 
 want to have. Did you have date picker, color picker, support 
 for internationalization, field formatters and so on.


I had support for custom dialogs, drawing etc. and file dialogs 
were built in so it was possible to create your own color picker, 
etc. in a very few lines of code. The way it was designed, custom 
field formatters were trivial. The point is we don't need to have 
a date picker and color picker and every other control built in, 
at least not initially. All we need is an easily extensible 
framework with the simple controls, and then we can add more 
complicated controls as they are requested. Once the framework is 
in place it will be very easy for many people to contribute and 
everything will get done much more quickly.
May 21 2013
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 21 May 2013 14:31:53 +0200
"Diggory" <diggsey googlemail.com> wrote:

 
 The point is we don't need to have 
 a date picker and color picker and every other control built in, 
 at least not initially. All we need is an easily extensible 
 framework with the simple controls, and then we can add more 
 complicated controls as they are requested.


That's certainly a good approach, but it does need to be fairly
pro-active on the developer's part: Unless there's already a solid user
base, most people aren't going to bother requesting what they want,
they'll just move on to something else.
May 21 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-21 14:31, Diggory wrote:


 I had support for custom dialogs, drawing etc. and file dialogs were
 built in so it was possible to create your own color picker, etc. in a
 very few lines of code. The way it was designed, custom field formatters
 were trivial. The point is we don't need to have a date picker and color
 picker and every other control built in, at least not initially. All we
 need is an easily extensible framework with the simple controls, and
 then we can add more complicated controls as they are requested. Once
 the framework is in place it will be very easy for many people to
 contribute and everything will get done much more quickly.


I would expect that the system needs to be designed from the ground up 
with support for something like internationalization. There are probably 
other features were this is true as well.

-- 
/Jacob Carlborg
May 21 2013
parent reply "Diggory" <diggsey googlemail.com> writes:
On Tuesday, 21 May 2013 at 18:59:08 UTC, Jacob Carlborg wrote:

 I would expect that the system needs to be designed from the 
 ground up with support for something like internationalization. 
 There are probably other features were this is true as well.


Of course, although I think internationalization is actually not 
one of them.

We could implement something like 
https://en.wikipedia.org/wiki/Gettext in D which would be great 
because unlike Gettext we wouldn't have to have a separate 
compiler to generate the equivalent of the .pot file, we should 
be able to do that as part of the normal compilation process.
May 21 2013
parent reply Peter Williams <pwil3058 bigpond.net.au> writes:
On 22/05/13 07:27, Diggory wrote:

 On Tuesday, 21 May 2013 at 18:59:08 UTC, Jacob Carlborg wrote:

 I would expect that the system needs to be designed from the ground up
 with support for something like internationalization. There are
 probably other features were this is true as well.


 Of course, although I think internationalization is actually not one of
 them.

 We could implement something like https://en.wikipedia.org/wiki/Gettext


I agree.  I would very much like to see a D implementation of gettext() 
as IMHO it is the best i18n mechanism around - simple and easy to use.

I also think that putting i18n hooks in your code is not just good 
manners but good sense as it widens your potential customer base.  I do 
it with all of my PyGTK GUIs (as Python's standard has gettext()) but 
don't do any l8n as I figure that's not my responsibility.


 in D which would be great because unlike Gettext we wouldn't have to
 have a separate compiler to generate the equivalent of the .pot file, we
 should be able to do that as part of the normal compilation process.


This would be great.  I had been toying with the idea of making a tool 
to do that but if the compiler could do it things would be greatly 
simplified.

Peter
May 22 2013
next sibling parent "Diggory" <diggsey googlemail.com> writes:
I've been looking at GtkD and it seems very complete and up to 
date in terms of exposing the Gtk+ API and wrapping it, but 
there's still a lot of Dification that could be done which would 
make it much closer to an ideal gui toolkit:

- Compile time implementation of GtkBuilder
- Instead of connecting up signals using strings specified in 
glade, use  Handles attribute to easily hook up to events from D 
code
- Generator to easily convert a D class into a custom widget for 
glade, completing the circle
- Automated setup so it's easier to get started using GtkD and 
glade

Advantages:
- Relatively small amount of work required
- Could be made to support most of the features suggested so far, 
potentially even hardware acceleration using the experimental 
opengl back-end
- Lots of potential for Dification
- GtkD already works well
- Cross platform

Disadvantages:
- Gtk+ is a fairly large dependency
- It's not D, although on the other hand it's not C++ either :P
May 22 2013
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
I've never actually done i18n so I might be full of crap, but I 
think a nice way to do it would be something along these lines:

1) (optionally) all printing functions actually take a different 
type than just plain string, forcing you to use the translation 
function

2) the function looks something like this:

PrintableString tr(string fmt, T...)(T t) {
     version(getstrings)
          pragma(msg, "string: " ~ fmt);
     return PrintableString(format(translation[lang][fmt], t));
}


So if you compile with -version=getstrings, the output from dmd 
can then be used to make your translation key file. It takes a 
format string so the translator can use positional arguments if 
they need to be reordered.

I've got half a mind to make those params commentable too so you 
can name them or something but not sure how to do that without 
being annoying. Maybe they can be alias arguments to the 
template, and then use stringof to get the variable name and 
annotations, but idk.
May 22 2013
parent reply Peter Williams <pwil3058 bigpond.net.au> writes:
On 23/05/13 11:23, Adam D. Ruppe wrote:

 I've never actually done i18n so I might be full of crap, but I think a
 nice way to do it would be something along these lines:

 1) (optionally) all printing functions actually take a different type
 than just plain string, forcing you to use the translation function


Not all strings should be translated.  So you need a way to say which 
ones do need to be translated.  Many schemes have been invented over the 
years (by Sun, Microsoft, etc.) but most of them died when gettext() 
came along as they were all very complex compared to gettext() and 
usually involved creating digests and giving strings id numbers etc. 
which rapidly became a maintenance nightmare.

The key simplicity of gettext() is the each string is its own identifier 
and notification that a string needs translating and doing the 
translation call is the one piece of code.

There is a minor complication with using strings declared as variables 
in COMPILED languages as the translation can't be done at compile time 
so they have two notations:

1. what I described above it gettext('string') means mark 'string' for 
translation and also return me the translation of 'string' i.e. a 
compile time meaning and a runtime meaning
2. a second template gettext_noop('string') which just means mark the 
string for translation and that's all.  In C and C++ this is usually 
just a macro that does nothing.  Then when you need the string variable 
later on you use gettext(<variable name>) to get the translation.  NB 
down in the guts it's just the contents of the string that is used as 
the key in the translation mechanism and there's no need to track the 
fact that it contains a translatable string.  Gettext() never fails and 
if it's called with a string that it cant find the translation for it 
just returns its argument unchanged.  In D, I imagine the best way to do 
this would be to have some sort of qualifier that could be used as part 
of the string variable declaration to tag it as a target for translation.

One of the things that is useful when doing i18n is having writef, etc. 
have the ability to specify which arguments should be placed where in 
the format string as it sometimes necessary to reorder them in order to 
make a translation that makes sense in the target language (as not all 
languages have a subject-verb-object grammar e.g. Yoda).

An example of how I would envisage gettext being used in D is:

writefln(gettext("%s: unknown variable at line %s"), filename, linenumber);

It is a common practice, to define a macro (or equivalent) _(arg) as an 
alias for gettext(arg) (and N_(arg) for gettext_noop(arg)) because 
people like brevity.

I would suggest using the gettext() functionality for i18n but design 
the notation used within programs (to access that functionality) 
according to what best suits the D paradigm.

Peter
May 22 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-23 08:27, Peter Williams wrote:


 An example of how I would envisage gettext being used in D is:

 writefln(gettext("%s: unknown variable at line %s"), filename, linenumber);

 It is a common practice, to define a macro (or equivalent) _(arg) as an
 alias for gettext(arg) (and N_(arg) for gettext_noop(arg)) because
 people like brevity.

 I would suggest using the gettext() functionality for i18n but design
 the notation used within programs (to access that functionality)
 according to what best suits the D paradigm.


Is the text you want to translate the actual key? That sounds very 
stupid. What if I need to change the text?

-- 
/Jacob Carlborg
May 23 2013
next sibling parent reply "Diggory" <diggsey googlemail.com> writes:
On Thursday, 23 May 2013 at 07:19:46 UTC, Jacob Carlborg wrote:

 On 2013-05-23 08:27, Peter Williams wrote:


 An example of how I would envisage gettext being used in D is:

 writefln(gettext("%s: unknown variable at line %s"), filename, 
 linenumber);

 It is a common practice, to define a macro (or equivalent) 
 _(arg) as an
 alias for gettext(arg) (and N_(arg) for gettext_noop(arg)) 
 because
 people like brevity.

 I would suggest using the gettext() functionality for i18n but 
 design
 the notation used within programs (to access that 
 functionality)
 according to what best suits the D paradigm.


 Is the text you want to translate the actual key? That sounds 
 very stupid. What if I need to change the text?


If you need to change the text then you also need to update the 
translations, or at least check that they're still correct, so I 
see that as a benefit rather than a problem...

What's great about it is you can develop your program with having 
to mess about with keys or anything to do with i18n, just 
remember to call "gettext()" and when your done it's already 
ready for translations to be added. Most other schemes require 
you to create a key before you can do anything which is a massive 
waste of time while developing when you may end up changing it 
numerous times or end up not even needing it.
May 23 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-23 09:29, Diggory wrote:


 If you need to change the text then you also need to update the
 translations, or at least check that they're still correct, so I see
 that as a benefit rather than a problem...


Say I have:

gettext("%s: unknown variable at line %s")

Then I want to change the text to:

gettext("%s: not yet known variable at line %s")

I have to find all places where this text is used in the code. Then I 
also need to updated the translations. If I used a key instead I only 
need to update all the translations. I don't need to change my code.

-- 
/Jacob Carlborg
May 23 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-23 10:29, Jacob Carlborg wrote:


 Say I have:

 gettext("%s: unknown variable at line %s")

 Then I want to change the text to:

 gettext("%s: not yet known variable at line %s")

 I have to find all places where this text is used in the code. Then I
 also need to updated the translations. If I used a key instead I only
 need to update all the translations. I don't need to change my code.


Also, with the key approach I can just send a separate file to someone 
else to do the translation, even the English translation. Sure I 
probably could have a separate file for the English translation as well 
but that would be duplicating the string.

-- 
/Jacob Carlborg
May 23 2013
next sibling parent reply "Diggory" <diggsey googlemail.com> writes:
On Thursday, 23 May 2013 at 08:31:46 UTC, Jacob Carlborg wrote:

 On 2013-05-23 10:29, Jacob Carlborg wrote:


 Say I have:

 gettext("%s: unknown variable at line %s")

 Then I want to change the text to:

 gettext("%s: not yet known variable at line %s")

 I have to find all places where this text is used in the code. 
 Then I
 also need to updated the translations. If I used a key instead 
 I only
 need to update all the translations. I don't need to change my 
 code.


 Also, with the key approach I can just send a separate file to 
 someone else to do the translation, even the English 
 translation. Sure I probably could have a separate file for the 
 English translation as well but that would be duplicating the 
 string.


Given a change that is purely aesthetic like that you could just 
change the english translation instead... Also "find and replace" 
takes a few seconds...

If you are suggesting to use a named constant as a key, this also 
suffers from the exact problem you are pointing out that if you 
need to change the name slightly you need to do it in all places 
that constant is used in the code.

It also suffers from the fact that unless you use unreasonably 
long names for the constant you can't easily tell what it 
contains.

Plus assuming these constants are internally numbered and that is 
the key used, you get the problem of translations matched to the 
wrong key and nobody realising because the key does not relate in 
any way to the meaning. With a text key the only time you reuse a 
key is if it has the same meaning.
May 23 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-05-23 10:45, Diggory wrote:

 Given a change that is purely aesthetic like that you could just change
 the english translation instead... Also "find and replace" takes a few
 seconds...

 If you are suggesting to use a named constant as a key, this also
 suffers from the exact problem you are pointing out that if you need to
 change the name slightly you need to do it in all places that constant
 is used in the code.


I'm not suggesting you should change the key at all.


 It also suffers from the fact that unless you use unreasonably long
 names for the constant you can't easily tell what it contains.


Rails uses "nested keys". It's strings that are translated to keys, i.e.:

translate("items.show.title")

Translation file:

en:
   items:
     show:
       title: Foobar

With a bit of magic it becomes:

translate(".title")

See my reply to Nick:

http://forum.dlang.org/thread/vtaufckbpdkpuxyztyoi forum.dlang.org?page=14#post-knhqji:241uq9:241:40digitalmars.com


 Plus assuming these constants are internally numbered and that is the
 key used, you get the problem of translations matched to the wrong key
 and nobody realising because the key does not relate in any way to the
 meaning. With a text key the only time you reuse a key is if it has the
 same meaning.


No, see above.

-- 
/Jacob Carlborg
May 23 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/23/13 4:31 AM, Jacob Carlborg wrote:

 On 2013-05-23 10:29, Jacob Carlborg wrote:


 Say I have:

 gettext("%s: unknown variable at line %s")

 Then I want to change the text to:

 gettext("%s: not yet known variable at line %s")

 I have to find all places where this text is used in the code. Then I
 also need to updated the translations. If I used a key instead I only
 need to update all the translations. I don't need to change my code.


 Also, with the key approach I can just send a separate file to someone
 else to do the translation, even the English translation. Sure I
 probably could have a separate file for the English translation as well
 but that would be duplicating the string.


enum string unknownVar = "9b4db58e27bf9fac1be43ed754fbc44c";
... gettext(unknownVar) ...


Andrei
May 23 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/23/13 4:29 AM, Jacob Carlborg wrote:

 On 2013-05-23 09:29, Diggory wrote:


 If you need to change the text then you also need to update the
 translations, or at least check that they're still correct, so I see
 that as a benefit rather than a problem...


 Say I have:

 gettext("%s: unknown variable at line %s")

 Then I want to change the text to:

 gettext("%s: not yet known variable at line %s")

 I have to find all places where this text is used in the code. Then I
 also need to updated the translations. If I used a key instead I only
 need to update all the translations. I don't need to change my code.


enum string unknownVar = "%s: unknown variable at line %s";
... gettext(unknownVar) ...


Andrei
May 23 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-05-23 14:56, Andrei Alexandrescu wrote:


 enum string unknownVar = "%s: unknown variable at line %s";
 ... gettext(unknownVar) ...


That's kind of the same thing as using the key approach that Diggory 
didn't like.

-- 
/Jacob Carlborg
May 23 2013
prev sibling parent Peter Williams <pwil3058 bigpond.net.au> writes:
On 23/05/13 17:29, Diggory wrote:

 What's great about it is you can develop your program with having to
 mess about with keys or anything to do with i18n, just remember to call
 "gettext()" and when your done it's already ready for translations to be
 added. Most other schemes require you to create a key before you can do
 anything which is a massive waste of time while developing when you may
 end up changing it numerous times or end up not even needing it.


Exactly.  From the programmers POV i18n with gettext() is a breeze.

Peter
PS retrofitting i18n using gettext() is equally painless to the point of 
being boring.
May 23 2013
prev sibling parent reply Peter Williams <pwil3058 bigpond.net.au> writes:
On 23/05/13 17:19, Jacob Carlborg wrote:

 On 2013-05-23 08:27, Peter Williams wrote:


 An example of how I would envisage gettext being used in D is:

 writefln(gettext("%s: unknown variable at line %s"), filename,
 linenumber);

 It is a common practice, to define a macro (or equivalent) _(arg) as an
 alias for gettext(arg) (and N_(arg) for gettext_noop(arg)) because
 people like brevity.

 I would suggest using the gettext() functionality for i18n but design
 the notation used within programs (to access that functionality)
 according to what best suits the D paradigm.


 Is the text you want to translate the actual key?


Yes.


 That sounds very
 stupid. What if I need to change the text?


Well. the translation will also need to be changed to any extra id that 
you'd given the original string is now useless.

Believe me, the give the strings an extra id idea has been tried (many 
times) and it failed badly (compared to gettext's model).

Peter
May 23 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-05-24 01:36, Peter Williams wrote:


 Believe me, the give the strings an extra id idea has been tried (many
 times) and it failed badly (compared to gettext's model).


It's been working in Ruby on Rails for years.

-- 
/Jacob Carlborg
May 24 2013
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 23 May 2013 at 06:27:28 UTC, Peter Williams wrote:

 On 23/05/13 11:23, Adam D. Ruppe wrote:

 I've never actually done i18n so I might be full of crap, but 
 I think a
 nice way to do it would be something along these lines:

 1) (optionally) all printing functions actually take a 
 different type
 than just plain string, forcing you to use the translation 
 function


 Not all strings should be translated.  So you need a way to say 
 which ones do need to be translated.  Many schemes have been 
 invented over the years (by Sun, Microsoft, etc.) but most of 
 them died when gettext() came along as they were all very 
 complex compared to gettext() and usually involved creating 
 digests and giving strings id numbers etc. which rapidly became 
 a maintenance nightmare.


I never used gettext except in the very few cases I did any C 
development on UNIX systems.

Qt, JVM and Win32/.NET languages have other mechanisms, which are 
pretty much alive.

--
Paulo
May 23 2013
prev sibling parent Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-05-21 12:31:53 +0000, "Diggory" <diggsey googlemail.com> said:


 On Tuesday, 21 May 2013 at 12:12:12 UTC, Jacob Carlborg wrote:

 On 2013-05-20 22:40, Diggory wrote:

 UI toolkits are a lot of work but they're not as unreasonably big as
 everyone seems to be suggesting... I've written a couple myself in a
 procedural language using Direct3D to draw everything. Had all the
 standard controls, various layout options, even a syntax highlighted
 code editor, clipboard interaction, keyboard focus, etc.


 
 I think you underestimate what's needed and the controls people want to 
 have. Did you have date picker, color picker, support for 
 internationalization, field formatters and so on.


 
 I had support for custom dialogs, drawing etc. and file dialogs were 
 built in so it was possible to create your own color picker, etc. in a 
 very few lines of code. The way it was designed, custom field 
 formatters were trivial. The point is we don't need to have a date 
 picker and color picker and every other control built in, at least not 
 initially. All we need is an easily extensible framework with the 
 simple controls, and then we can add more complicated controls as they 
 are requested. Once the framework is in place it will be very easy for 
 many people to contribute and everything will get done much more 
 quickly.


Not at all. It's the reverse.

Once the framework is in place, you'll have what you need to put 
buttons and fields in a window and work with them. Then comes the hard 
part.

Good luck trying to create a common ground API for table views on Mac, 
GTK, KDE and Windows. If you want to offer an API to manipulate the 
data in the table view, you'll likely need to reimplement the whole 
thing yourself. That's a *huge* amount of work and a pile of details 
will most likely be off (scrolling, selection behaviour, drag & drop). 
Or you can try to piggy-back on the platform table view widget, but 
then you're limiting the API to the lowest common denominator.

Then look at toolbars and the customization panel for toolbar items. Or 
text views, including styling text, adding links and images inline with 
the text, supporting selections (where some platforms support disjoint 
selection), enabling and controlling spell-checking and autocorrection 
(native at least on OS X).

Then comes the platform-standard UI conventions and controls. On OS X 
for instance you have popovers, sheets (alerts attached to windows), 
segmented controls (multiple buttons attached together), multiple 
layouts for buttons including a specific button style for help buttons, 
application-specific menu bar on OS X and window-specific everywhere 
else, the color picker is always a non-modal floating palette on OS X 
but not on other platforms, preference windows instantly apply their 
settings on OS X (and have no OK button), not on other platforms. 
Standard keyboard shortcuts are quite different between platforms too. 
Each convention not followed will make your app look a little out of 
place.

And even if you could create the perfect abstraction layer, it'll be a 
nightmare to write something with it. In theory it'll work everywhere, 
but in practice you still need to specify different platform-specific 
things for each control to make them look at home, perhaps using 
slightly different layouts. Then you need to test it on all platforms, 
and when you hit a bug you'll need to find out if the bug lies in your 
application, the platform's code, or the abstracted intermediary GUI 
layer.

I'm not saying it's impossible to do, just that it'll require a 
gigantic effort going beyond the simple window-button-field concepts 
into more featureful widgets and trying to emulate platform-native 
behaviours and layouts. And don't forget that you'll be chasing 
multiple moving targets. GUI concepts are still evolving, and each 
platform is changing things slightly differently these days.

That said, there's plenty of value in having a drawing API capable of 
showing a window, and perhaps some buttons and menus, for prototyping 
things. Perhaps you could build a widget API for games that'd work on 
top of that, as games usually don't use native controls that much. But 
I can tell that creating an abstraction layer around native widgets 
won't take you very far. Just try the table view thing if you want to 
convince yourself. Or toolbars.

-- 
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca/
May 21 2013
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 21 May 2013 14:12:11 +0200
Jacob Carlborg <doob me.com> wrote:

 
 I think you underestimate what's needed and the controls people want
 to have. Did you have date picker, color picker, support for 
 internationalization, field formatters and so on.
 


Speaking of, what is the current state-of-the-art for i18n? Basically
just tables of format strings looked up by language and a phrase
identifier?

Like (more or less):

assert("Hello $name" == i18n[US_ENGLISH][HELLO]);

?


I do know of at least one way *not* to do it. I once worked at a
VB6 company where their idea of i18n was:

XLate("You have ") + numOranges + XLate(" oranges.")

Sooooo many things wrong with that...
May 21 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-05-21 21:56, Nick Sabalausky wrote:


 Speaking of, what is the current state-of-the-art for i18n? Basically
 just tables of format strings looked up by language and a phrase
 identifier?


Ruby on Rails uses the I18n library and works like this:

In a view you can call the "translate" method:

translate("nested.key")

This will look in the YAML file <locale>.yml:

nested:
   key: bar

So the above will print "bar". The locale is set for each request in the 
controller based on top domain, path or whatever you want:

I18n.locale = "en"

It also supports interpolation:



en:
   nested:
     key: foo=%{bar}

Will print: "foo=3". On top of this Rails builds some convenience:

translate(".price", price: product.price)

When the key starts with a dot it will use the path of the view file, 
including partials. You many have a YAML file looking like this:

en:
   products:
     show:
       details:
         price: "Price: %{price}"

"products" would be a directory, "show" the view file, "details" a 
partial included in "show" and "price" would be the key.

There's also the "localize" method:

localize(product.updated_at, format: "date")

Will match the following YAML file:

en:
   time:
     formats:
       date: "%Y-%m-%d"

That will print just the date from the given time stamp.

I18n supports any kind of backend that has the following interface:

backend["nested"]["key"]

A standard translation file for English:

https://github.com/svenfuchs/rails-i18n/blob/master/rails/locale/en.yml

Documentation:

http://guides.rubyonrails.org/i18n.html

-- 
/Jacob Carlborg
May 22 2013
prev sibling next sibling parent "Mr. Anonymous" <mailnew4ster gmail.com> writes:
On Monday, 20 May 2013 at 05:25:50 UTC, Tyler Jameson Little 
wrote:

 I've been looking into trying to fix QtD, but it seems writing 
 a binding to a C++ library is a bit complicated. I've read on 
 the forums that a native D GUI toolkit is the most desirable 
 long-term, so I'd like to start that discussion.

 First off, I've heard of the DWT project, which looks 
 promising, but it seems like a direct port of Java's SWT 
 instead of a reimagining using idiomatic D. I understand the 
 allure here (works, little translation for new developers), but 
 since it's not yet in Phobos, I can only assume it's still up 
 for discussion.

 Personally, I want these features:

 * simple and extensible
   * minimal components (something like HTMLs feature-set)
   * custom components (embed OpenGL/direct frame buffer)
 * "native" window decorations by default, but can provide 
 custom decorations
 * markup (like QML) or programmable (like SWT)

 Nice-to-haves:

 * hardware accelerated (2D OpenGL)
 * GUI designer (much easier with QML-esque markup)
 * part of Phobos

 I'm willing to lend a hand, but I'd like to know in what 
 direction the community would like to go. I'd also like to know 
 the likelihood of getting a GUI toolkit into Phobos.

 Thoughts?


What about D Forms Library (DFL)?
I didn't try it yet, but I've heard it's not bad.
https://github.com/Rayerd/dfl
May 20 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-20 07:25, Tyler Jameson Little wrote:

 I've been looking into trying to fix QtD, but it seems writing a binding
 to a C++ library is a bit complicated. I've read on the forums that a
 native D GUI toolkit is the most desirable long-term, so I'd like to
 start that discussion.


Here we go again, yet another massive thread about GUI toolkits :)

-- 
/Jacob Carlborg
May 20 2013
parent reply "eles" <eles eles.com> writes:
On Tuesday, 21 May 2013 at 06:41:24 UTC, Jacob Carlborg wrote:

 On 2013-05-20 07:25, Tyler Jameson Little wrote:
 Here we go again, yet another massive thread about GUI toolkits 
 :)


Anyway, the thread is already started, I think the alternatives 
are:

1) pick up a major well-known GUI library, fork it and spend some 
important time to re-write in D. Choices: Qt, GTK, wxWindows etc.

2) pick up a lighter GUI library, while still cross-platform, and 
re-write it in D. Spent time is less. Choices: FLTK, FOX Toolkit

3) start from scratch and write something new, while still having 
to decide if will wrap OS widgets or no.

Just to be sure that you know about FOX Toolkit:

http://fox-toolkit.org/goals.html
May 21 2013
next sibling parent "Mike James" <foo bar.com> writes:
"eles" <eles eles.com> wrote in message 
news:ksirfxsiejlweyhomwmh forum.dlang.org...

 On Tuesday, 21 May 2013 at 06:41:24 UTC, Jacob Carlborg wrote:

 On 2013-05-20 07:25, Tyler Jameson Little wrote:
 Here we go again, yet another massive thread about GUI toolkits :)


 Anyway, the thread is already started, I think the alternatives are:

 1) pick up a major well-known GUI library, fork it and spend some 
 important time to re-write in D. Choices: Qt, GTK, wxWindows etc.

 2) pick up a lighter GUI library, while still cross-platform, and re-write 
 it in D. Spent time is less. Choices: FLTK, FOX Toolkit

 3) start from scratch and write something new, while still having to 
 decide if will wrap OS widgets or no.

 Just to be sure that you know about FOX Toolkit:

 http://fox-toolkit.org/goals.html


There is also IUP...

http://www.tecgraf.puc-rio.br/iup/

-=mike=-
May 21 2013
prev sibling parent reply "Juan Manuel Cabo" <juanmanuel.cabo gmail.com> writes:
On Tuesday, 21 May 2013 at 07:47:56 UTC, eles wrote:

 On Tuesday, 21 May 2013 at 06:41:24 UTC, Jacob Carlborg wrote:

 On 2013-05-20 07:25, Tyler Jameson Little wrote:
 Here we go again, yet another massive thread about GUI 
 toolkits :)


 Anyway, the thread is already started, I think the alternatives 
 are:

 1) pick up a major well-known GUI library, fork it and spend 
 some important time to re-write in D. Choices: Qt, GTK, 
 wxWindows etc.

 2) pick up a lighter GUI library, while still cross-platform, 
 and re-write it in D. Spent time is less. Choices: FLTK, FOX 
 Toolkit

 3) start from scratch and write something new, while still 
 having to decide if will wrap OS widgets or no.

 Just to be sure that you know about FOX Toolkit:

 http://fox-toolkit.org/goals.html


DWT is completely written in D. It is a port of a java library 
which originally contained java + jni + C++ code, which were all 
ported to D exclusively.

DWT interfaces directly with the OS in windows, and with GTK in 
linux.

So there. A native D GUI library already exists (DWT), which can 
work as a starting point for something else. Note that it is hard 
to create a GUI designer directly for SWT (because it would need 
to generate code), but a layer of declarative xml can be built on 
top, so that it is easier.

Code originally written for SWT 
http://www.eclipse.org/swt/widgets/  works with little 
modification.

I've been using DWT for some time and it seems stable for me. 
Thanks to Jacob Carlborg for maintaining it!

--jm
May 22 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-05-23 03:16, Juan Manuel Cabo wrote:


 I've been using DWT for some time and it seems stable for me. Thanks to
 Jacob Carlborg for maintaining it!


:) Thank you to everyone contributing with pull requests.

-- 
/Jacob Carlborg
May 22 2013