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

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

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.

On Thu, 23 May 2013 09:51:17 +1000
Peter Williams <pwil3058@bigpond.net.au> wrote:

> On 22/05/13 16:44, Jacob Carlborg wrote:
> > On 2013-05-22 07:00, Peter Williams wrote:
> >
> >> My experience (with PyGTK) is that GUI building tools actually make the task harder not easier (once you become familiar with the API).  Of course, things may have changed since I last used such a tool but I doubt it.
> >
> > Then you obviously haven't used Interface Builder/Xcode on Mac OS X. It's a great tool for window building.
> 
> That is indeed the case.  I avoid all things Apple as my experience has been that they seem to think they still own a device after they've sold it to me.
> 

Unfortunately *everyone* seems to think that now. And not just devices, software too. You should hear a lot of the game industry: many of the people there (not all obviously, but a lot) *genuinely* believe first-sale doctrine is invalid/inexcusable/inapplicable/etc and that they still have true, unalienable rights *after* the first sale. It's unbelievable, it's like talking to caricatures of Enron execs.

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

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

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

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

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.

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