On Tuesday, 21 May 2013 at 11:33:19 UTC, Kiith-Sa wrote:
> On Tuesday, 21 May 2013 at 11:06:44 UTC, Andrej Mitrovic wrote:
>> On 5/21/13, Adam Wilson <flyboynw@gmail.com> wrote:
>>> Well, it comes down to how you want to render. My preferred solution
>>> woulbd be a rendering thread running all the time doing nothing but the
>>> GPU leg-work
>>
>> Why a GPU? Aren't most GUIs static? And aren't there issues with GPUs
>> where feature X isn't supported on all GPUs or is buggy on a
>> particular one (e.g. driver issues)? Or maybe that was true in the
>> past, I was out of the loop for a while. :)
>
> If you only use basic features (everything you need for GUI), you're not going to have issues. In any case if you go the GPU route it's best to isolate the GPU code behind an interface so you can add a software implementation later if absolutely necessary.
>
> I think the best idea is to stop arguing and just do something. I recommend trying a minimalist project (at most Clutter sized) instead of something massive like Qt that's likely never going to see the light of day. Implement the basics, create a few example apps, and _then_ start a discussion. You might not get a perfect library/framework, but at least you'll get something that exists instead of an infinite flame war getting nowhere as is the tradition in the D world. Getting more than one contributor _and_ not stopping work on it is going to be the main issue, there've been a few D GUI attempts and they're mostly dead due to lost interest.
>
> My (subjective) preferences:
>
> * Human-readable markup, not just through a tool (a tool can be built later). YAML and JSON work well here.
>
> * Look at Hybrid API. Clutter and Qt also have nice APIs, but D allows some things not possible there.
>
> * Library instead of a framework - one of things I like about the Hybrid design

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.

On 2013-05-21 12:31:53 +0000, "Diggory" <diggsey@googlemail.com> said:

> On Tuesday, 21 May 2013 at 12:12:12 UTC, Jacob Carlborg wrote:
>> On 2013-05-20 22:40, Diggory wrote:
>>> UI toolkits are a lot of work but they're not as unreasonably big as
>>> everyone seems to be suggesting... I've written a couple myself in a
>>> procedural language using Direct3D to draw everything. Had all the
>>> standard controls, various layout options, even a syntax highlighted
>>> code editor, clipboard interaction, keyboard focus, etc.
>> 
>> I think you underestimate what's needed and the controls people want to have. Did you have date picker, color picker, support for internationalization, field formatters and so on.
> 
> I had support for custom dialogs, drawing etc. and file dialogs were built in so it was possible to create your own color picker, etc. in a very few lines of code. The way it was designed, custom field formatters were trivial. The point is we don't need to have a date picker and color picker and every other control built in, at least not initially. All we need is an easily extensible framework with the simple controls, and then we can add more complicated controls as they are requested. Once the framework is in place it will be very easy for many people to contribute and everything will get done much more quickly.

Not at all. It's the reverse.

Once the framework is in place, you'll have what you need to put buttons and fields in a window and work with them. Then comes the hard part.

Good luck trying to create a common ground API for table views on Mac, GTK, KDE and Windows. If you want to offer an API to manipulate the data in the table view, you'll likely need to reimplement the whole thing yourself. That's a *huge* amount of work and a pile of details will most likely be off (scrolling, selection behaviour, drag & drop). Or you can try to piggy-back on the platform table view widget, but then you're limiting the API to the lowest common denominator.

Then look at toolbars and the customization panel for toolbar items. Or text views, including styling text, adding links and images inline with the text, supporting selections (where some platforms support disjoint selection), enabling and controlling spell-checking and autocorrection (native at least on OS X).

Then comes the platform-standard UI conventions and controls. On OS X for instance you have popovers, sheets (alerts attached to windows), segmented controls (multiple buttons attached together), multiple layouts for buttons including a specific button style for help buttons, application-specific menu bar on OS X and window-specific everywhere else, the color picker is always a non-modal floating palette on OS X but not on other platforms, preference windows instantly apply their settings on OS X (and have no OK button), not on other platforms. Standard keyboard shortcuts are quite different between platforms too. Each convention not followed will make your app look a little out of place.

And even if you could create the perfect abstraction layer, it'll be a nightmare to write something with it. In theory it'll work everywhere, but in practice you still need to specify different platform-specific things for each control to make them look at home, perhaps using slightly different layouts. Then you need to test it on all platforms, and when you hit a bug you'll need to find out if the bug lies in your application, the platform's code, or the abstracted intermediary GUI layer.

I'm not saying it's impossible to do, just that it'll require a gigantic effort going beyond the simple window-button-field concepts into more featureful widgets and trying to emulate platform-native behaviours and layouts. And don't forget that you'll be chasing multiple moving targets. GUI concepts are still evolving, and each platform is changing things slightly differently these days.

That said, there's plenty of value in having a drawing API capable of showing a window, and perhaps some buttons and menus, for prototyping things. Perhaps you could build a widget API for games that'd work on top of that, as games usually don't use native controls that much. But I can tell that creating an abstraction layer around native widgets won't take you very far. Just try the table view thing if you want to convince yourself. Or toolbars.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/

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

On 21/05/13 16:35, Nick Sabalausky wrote:
> On Mon, 20 May 2013 23:21:28 -0700
> Brad Roberts <braddr@puremagic.com> wrote:
>
>> On 5/20/13 9:49 PM, Peter Williams wrote:
>>>
>>> Yes, if D aspires to be a systems programming language it can't keep
>>> relying on wrappers around C/C++ libraries (especially C++).  In the
>>> long term, it should be D all the way down to the OS API.
>>
>> You wrote this as if not using c and c++ libraries is a predicate for
>> being a systems language.  It's not.
>>
>> What's with the D community's (yes, I'm over generalizing some)
>> not-invented-here syndrome?
>
> Conditioned aversion to C++? (half-serious)
>
>> Avoiding the incredible body of existing
>> code out there that's accumulated over the decades is foolhardy and
>> narrow sighted.  Are all c and c++ libraries great bodies of code,
>> absolutely not.  Is some of the code that predates D worth reusing,
>> yup.

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

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

Peter

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

On 2013-05-21 21:56, Nick Sabalausky wrote:

> Speaking of, what is the current state-of-the-art for i18n? Basically
> just tables of format strings looked up by language and a phrase
> identifier?

Ruby on Rails uses the I18n library and works like this:

In a view you can call the "translate" method:

translate("nested.key")

This will look in the YAML file <locale>.yml:

nested:
  key: bar

So the above will print "bar". The locale is set for each request in the controller based on top domain, path or whatever you want:

I18n.locale = "en"

It also supports interpolation:

translate("nested.key", bar: 3) # the last argument is a hash map

en:
  nested:
    key: foo=%{bar}

Will print: "foo=3". On top of this Rails builds some convenience:

translate(".price", price: product.price)

When the key starts with a dot it will use the path of the view file, including partials. You many have a YAML file looking like this:

en:
  products:
    show:
      details:
        price: "Price: %{price}"

"products" would be a directory, "show" the view file, "details" a partial included in "show" and "price" would be the key.

There's also the "localize" method:

localize(product.updated_at, format: "date")

Will match the following YAML file:

en:
  time:
    formats:
      date: "%Y-%m-%d"

That will print just the date from the given time stamp.

I18n supports any kind of backend that has the following interface:

backend["nested"]["key"]

A standard translation file for English:

https://github.com/svenfuchs/rails-i18n/blob/master/rails/locale/en.yml

Documentation:

http://guides.rubyonrails.org/i18n.html

-- 
/Jacob Carlborg

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

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

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