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