Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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.
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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.
Re: Ideal D GUI Toolkit
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/vtaufckbpdkpuxyzt...@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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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.
Re: Ideal D GUI Toolkit
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.
Re: Ideal D GUI Toolkit
On Tue, 21 May 2013 00:16:15 -0700, Jacob Carlborg d...@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/
Re: Ideal D GUI Toolkit
On Tue, 21 May 2013 00:24:30 -0700, Jacob Carlborg d...@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/
Re: Ideal D GUI Toolkit
On Tue, 21 May 2013 00:01:36 -0700, Jacob Carlborg d...@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/
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
On Tue, 21 May 2013 10:50:40 -0700 Adam Wilson flybo...@gmail.com wrote: On Tue, 21 May 2013 00:16:15 -0700, Jacob Carlborg d...@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.
Re: Ideal D GUI Toolkit
On Tue, 21 May 2013 13:33:18 +0200 Kiith-Sa kiithsa...@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).
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
On Tue, 21 May 2013 14:31:53 +0200 Diggory digg...@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.
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
On Tue, 21 May 2013 20:55:11 +0200 Jacob Carlborg d...@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?
i18n (was: Ideal D GUI Toolkit)
On Tue, 21 May 2013 14:12:11 +0200 Jacob Carlborg d...@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.) So many things wrong with that...
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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.
Re: Ideal D GUI Toolkit
On Tue, 21 May 2013 22:44:30 +0200 Jacob Carlborg d...@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.)
Re: Ideal D GUI Toolkit
On Tue, 21 May 2013 17:38:15 -0400 Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On Tue, 21 May 2013 22:44:30 +0200 Jacob Carlborg d...@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.
Re: Ideal D GUI Toolkit
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 flybo...@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
Re: Ideal D GUI Toolkit
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.
Re: Ideal D GUI Toolkit
On 2013-05-21 12:31:53 +, Diggory digg...@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.for...@michelf.ca http://michelf.ca/
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
On 21/05/13 16:35, Nick Sabalausky wrote: On Mon, 20 May 2013 23:21:28 -0700 Brad Roberts bra...@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
Re: Ideal D GUI Toolkit
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. :)
Re: Ideal D GUI Toolkit
On Tue, 21 May 2013 11:40:15 -0700, Jacob Carlborg d...@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/
Re: Ideal D GUI Toolkit
On Tue, 21 May 2013 11:38:31 -0700, Jacob Carlborg d...@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/
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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.
Re: Ideal D GUI Toolkit
On Thu, 23 May 2013 09:51:17 +1000 Peter Williams pwil3...@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.
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 20:46:48 -0700, Tyler Jameson Little beatgam...@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. See my DConf talk in a few days (I was #3 on Day 2). It has a 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'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/
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
See my DConf talk in a few days (I was #3 on Day 2). It has a 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.
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 23:00:10 -0700 Adam Wilson flybo...@gmail.com wrote: On Mon, 20 May 2013 20:46:48 -0700, Tyler Jameson Little beatgam...@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.
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 23:21:28 -0700 Brad Roberts bra...@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
Re: Ideal D GUI Toolkit
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 ;)
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
On Monday, 20 May 2013 at 22:48:01 UTC, Adam Wilson wrote: On Mon, 20 May 2013 15:35:57 -0700, Flamaros flamaros.xav...@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.
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
eles e...@eles.com wrote in message news:ksirfxsiejlweyhom...@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=-
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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.
Re: Ideal D GUI Toolkit
Jonathan M Davis jmdavisp...@gmx.com wrote in message
news:mailman.1428.1369071743.4724.digitalmar...@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.
Re: Ideal D GUI Toolkit
On 5/21/13, Adam Wilson flybo...@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. :)
Re: Ideal D GUI Toolkit
On 5/21/13, Jacob Carlborg d...@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.
Re: Ideal D GUI Toolkit
On Tuesday, 21 May 2013 at 11:06:44 UTC, Andrej Mitrovic wrote: On 5/21/13, Adam Wilson flybo...@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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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.
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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.
Re: Ideal D GUI Toolkit
Tyler Jameson Little beatgam...@gmail.com wrote in message news:vtaufckbpdkpuxyzt...@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.
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
On Sun, 19 May 2013 22:25:49 -0700, Tyler Jameson Little beatgam...@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
Re: Ideal D GUI Toolkit
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.
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 11:01:35 -0700 Adam Wilson flybo...@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.
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 12:09:47 -0700, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On Mon, 20 May 2013 11:01:35 -0700 Adam Wilson flybo...@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/
Re: Ideal D GUI Toolkit
20-May-2013 22:01, Adam Wilson пишет: On Sun, 19 May 2013 22:25:49 -0700, Tyler Jameson Little beatgam...@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. I sure hope savings in amount of idiomatic D code vs C# idiomatic code 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
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 12:28:16 -0700, Dmitry Olshansky dmitry.o...@gmail.com wrote: 20-May-2013 22:01, Adam Wilson пишет: On Sun, 19 May 2013 22:25:49 -0700, Tyler Jameson Little beatgam...@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 ;) 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-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? * 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). 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, 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. I sure hope savings in amount of idiomatic D code vs C# idiomatic code OOP code could help here. You have no idea... 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. 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. 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 one 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 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
Re: Ideal D GUI Toolkit
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.
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 12:28:09 -0700 Adam Wilson flybo...@gmail.com wrote: On Mon, 20 May 2013 12:09:47 -0700, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On Mon, 20 May 2013 11:01:35 -0700 Adam Wilson flybo...@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.
Re: Ideal D GUI Toolkit
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.
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 23:28:16 +0400 Dmitry Olshansky dmitry.o...@gmail.com wrote: 20-May-2013 22:01, Adam Wilson пишет: * 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 ;) 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. Markup for GUI layout seems like a decent idea. 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. 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] 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.
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 12:41:08 -0700 Adam Wilson flybo...@gmail.com wrote: On Mon, 20 May 2013 12:28:16 -0700, Dmitry Olshansky dmitry.o...@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.
Re: Ideal D GUI Toolkit
20-May-2013 23:41, Adam Wilson пишет: On Mon, 20 May 2013 12:28:16 -0700, Dmitry Olshansky dmitry.o...@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. I sure hope savings in amount of idiomatic D code vs C# idiomatic code 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
Re: Ideal D GUI Toolkit
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 seewebsitetocontac...@semitwist.com wrote: On Mon, 20 May 2013 12:41:08 -0700 Adam Wilson flybo...@gmail.com wrote: On Mon, 20 May 2013 12:28:16 -0700, Dmitry Olshansky dmitry.o...@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.
Re: Ideal D GUI Toolkit
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
Re: Ideal D GUI Toolkit
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.
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 12:52:39 -0700, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On Mon, 20 May 2013 12:28:09 -0700 Adam Wilson flybo...@gmail.com wrote: On Mon, 20 May 2013 12:09:47 -0700, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On Mon, 20 May 2013 11:01:35 -0700 Adam Wilson flybo...@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/
Re: Ideal D GUI Toolkit
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.
