On 2013-02-17 23:29, Adam Wilson wrote:

> - Concurrent Dependency Properties to allow multi-threaded access to the
> UI. (Needs specialized container support in Phobos.)

How is this going to work? Some of the native GUI systems are not thread safe.

-- 
/Jacob Carlborg

On Monday, 18 February 2013 at 08:30:32 UTC, Jacob Carlborg wrote:
> On 2013-02-17 23:29, Adam Wilson wrote:
>
>> - Concurrent Dependency Properties to allow multi-threaded access to the
>> UI. (Needs specialized container support in Phobos.)
>
> How is this going to work? Some of the native GUI systems are not thread safe.

WPF is far from a native GUI. All "controls" are drawn of the screen using DirectX and all well known input events are DirectInput calls. All objects in WPF world inherit from a DispatcherObject associated with a Dispatcher. The Dispatcher is responsible of queuing, filtering redundant calls or prioritising requests.

On 2013-02-18 09:59, rumbu wrote:

> WPF is far from a native GUI. All "controls" are drawn of the screen
> using DirectX and all well known input events are DirectInput calls. All
> objects in WPF world inherit from a DispatcherObject associated with a
> Dispatcher. The Dispatcher is responsible of queuing, filtering
> redundant calls or prioritising requests.

Yeah, I suspected that. But creating a new platform independent GUI library from scratch is an enormous task. I was thinking building on top of the native ones that already exist.

-- 
/Jacob Carlborg

>
> The closest thing to WPF that you can use in D is QML/QtD.
>

So why not support QML/QtD?

Also, maybe there's a lesson to be learned from the evolution of
Qt's widget toolkit from native to QML (based on CSS/Javascript)

On Mon, 18 Feb 2013 01:33:51 -0800, Jacob Carlborg <doob@me.com> wrote:

> On 2013-02-18 09:59, rumbu wrote:
>
>> WPF is far from a native GUI. All "controls" are drawn of the screen
>> using DirectX and all well known input events are DirectInput calls. All
>> objects in WPF world inherit from a DispatcherObject associated with a
>> Dispatcher. The Dispatcher is responsible of queuing, filtering
>> redundant calls or prioritising requests.
>
> Yeah, I suspected that. But creating a new platform independent GUI library from scratch is an enormous task. I was thinking building on top of the native ones that already exist.
>

Indeed it is a massive undertaking, but platform independence is KEY to making this work for D because D itself is platform independent. Building on-top of native kits comes with it's own complexities too. So kits have things that others don't, so you end up with a very small set of available widgets, AND no way to make new ones, short of huge amounts of custom coding. You also run into layout problems as you can specify a single size for all widgets, they have different paddings and margins so the UI never looks right outside of the UI system the software was designed on (for example the KDE widgets are very different sizes from GNOME).

The beauty of WPF/Silverlight/WinRT XAML, is that it looks the same no matter where you're running. I understand that there are purists out there who believe that you should always use the OS widgets, but in today's fractured environments, it's just not realistic from a UI design perspective anymore.

XAML-type systems have the same thing in common with HTML/CSS that EVERYONE loves right now, with a little bit of design effort, they can automatically reflow themselves for any device. Like it or not, the OS widgets are a hold over from the pre-mobile era. How many people actually use the default OS widget skin for HTML buttons?

-- 
Using Opera's mail client: http://www.opera.com/mail/

On Monday, 18 February 2013 at 15:05:03 UTC, Roy Obena wrote:
>>
>> The closest thing to WPF that you can use in D is QML/QtD.
>>
>
> So why not support QML/QtD?
>

Overhead in api bindings.

Wpf and its data banding system are intented for MVVM pattern. It's have own + and -.
It's more realistic to build a js-like runtime and widgets runtime, for example, based on something native like dwt gui.
In opensource we have: qml, fluid, glade for C/C++. So it's possible in D ;)

But also a lot of design pattern are additionaly available.

On 2013-02-18 21:10, Adam Wilson wrote:

> Indeed it is a massive undertaking, but platform independence is KEY to
> making this work for D because D itself is platform independent.
> Building on-top of native kits comes with it's own complexities too. So
> kits have things that others don't, so you end up with a very small set
> of available widgets, AND no way to make new ones, short of huge amounts
> of custom coding. You also run into layout problems as you can specify a
> single size for all widgets, they have different paddings and margins so
> the UI never looks right outside of the UI system the software was
> designed on (for example the KDE widgets are very different sizes from
> GNOME).

I haven't run into any problems with different sizes of widgets using DWT/SWT. Do you think DWT/SWT just lay out widgets with standard behavior? The code contains a huge amount of configuration to make the widgets behave the same on all platforms. Setting values, overriding rendering functions an so on.

Of course you can make new ones. Perhaps not as easy. But I see no reason why you couldn't add a layer on top make it just as easy.

The custom tool kits always invent their own ways of doing things, breaking with the rest of the OS. The user then just gets confused when one thing works in one application but not in the other.

> The beauty of WPF/Silverlight/WinRT XAML, is that it looks the same no
> matter where you're running. I understand that there are purists out
> there who believe that you should always use the OS widgets, but in
> today's fractured environments, it's just not realistic from a UI design
> perspective anymore.

It only runs on Windows.

> XAML-type systems have the same thing in common with HTML/CSS that
> EVERYONE loves right now, with a little bit of design effort, they can
> automatically reflow themselves for any device. Like it or not, the OS
> widgets are a hold over from the pre-mobile era. How many people
> actually use the default OS widget skin for HTML buttons?

If you want to build serious applications that take full advantage of the platform, that never works. Just look at iPhone and iPad, they have different widgets even though they're so similar.

-- 
/Jacob Carlborg

On Mon, 18 Feb 2013 12:34:20 -0800, Jacob Carlborg <doob@me.com> wrote:

> On 2013-02-18 21:10, Adam Wilson wrote:
>
>> Indeed it is a massive undertaking, but platform independence is KEY to
>> making this work for D because D itself is platform independent.
>> Building on-top of native kits comes with it's own complexities too. So
>> kits have things that others don't, so you end up with a very small set
>> of available widgets, AND no way to make new ones, short of huge amounts
>> of custom coding. You also run into layout problems as you can specify a
>> single size for all widgets, they have different paddings and margins so
>> the UI never looks right outside of the UI system the software was
>> designed on (for example the KDE widgets are very different sizes from
>> GNOME).
>
> I haven't run into any problems with different sizes of widgets using DWT/SWT. Do you think DWT/SWT just lay out widgets with standard behavior? The code contains a huge amount of configuration to make the widgets behave the same on all platforms. Setting values, overriding rendering functions an so on.
>
> Of course you can make new ones. Perhaps not as easy. But I see no reason why you couldn't add a layer on top make it just as easy.
>

Define "not as easy"? I can restyle a List in WPF so completely that you can't even tell it's a list in about 1/2 hour. Sure the list may not look much like a list but it functions like one and looks the way that makes most sense for it's usage. I have NEVER met an OS toolkit that could come close to doing such major restyling so quickly. I'd have to build a new widget from the ground up. QML can ... but it's also not an OS widget toolkit either. QML also proves that it isn't just MS that thinks this is a good thing...

> The custom tool kits always invent their own ways of doing things, breaking with the rest of the OS. The user then just gets confused when one thing works in one application but not in the other.
>

I have yet to encounter this fabled user confusion during usability testing, so I am gonna file this one under "myth".

>> The beauty of WPF/Silverlight/WinRT XAML, is that it looks the same no
>> matter where you're running. I understand that there are purists out
>> there who believe that you should always use the OS widgets, but in
>> today's fractured environments, it's just not realistic from a UI design
>> perspective anymore.
>
> It only runs on Windows.
>

That has more to do with the fact that MS made it than any technical limitation.

>> XAML-type systems have the same thing in common with HTML/CSS that
>> EVERYONE loves right now, with a little bit of design effort, they can
>> automatically reflow themselves for any device. Like it or not, the OS
>> widgets are a hold over from the pre-mobile era. How many people
>> actually use the default OS widget skin for HTML buttons?
>
> If you want to build serious applications that take full advantage of the platform, that never works. Just look at iPhone and iPad, they have different widgets even though they're so similar.
>

It does with a Silverlight type toolkit. The iPhone/iPad widget situation demonstrates part of the problem with OS widgets. They are tied intrinsically to the platform, I am trying to free myself from having to have multiple UI layouts for each platform. My point about fracturing is that the same app can have completely different layouts from iPhone to Android, all enforced by the OS. You don't honestly think thats a good thing for cross-platform usability ... ? Sure, much of the difference has more to do with Apple being dicks in the courtroom but as a third party that doesn't provide any one style, they can't really make a legal case against it. It's not like I am trying to copy their style or anything...

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On 2013-02-19 05:18, Adam Wilson wrote:

> I have yet to encounter this fabled user confusion during usability
> testing, so I am gonna file this one under "myth".

Perhaps not confused. But I get darn annoyed when a widget doesn't work like I expect it to do or like it look like.

A scroll bar is the perfect example of this. I scroll bar usually have these components:

* Background
* Slider
* Two arrow buttons

This is the behavior I would expect:

* When I click on any of the arrow buttons it should scroll the view
* When I drag the slider it should scroll the view
* When I click on the background it should scroll the view
* When I use the scroll wheel on the mouse it should scroll the view

I have seen many custom scroll bars when one or more of these behavior don't work. Even if it has the component graphically.

> That has more to do with the fact that MS made it than any technical
> limitation.

If it's only run on platform you don't have the problem on having it look the same on some other platform.

> It does with a Silverlight type toolkit. The iPhone/iPad widget
> situation demonstrates part of the problem with OS widgets. They are
> tied intrinsically to the platform, I am trying to free myself from
> having to have multiple UI layouts for each platform. My point about
> fracturing is that the same app can have completely different layouts
> from iPhone to Android, all enforced by the OS. You don't honestly think
> thats a good thing for cross-platform usability ... ? Sure, much of the
> difference has more to do with Apple being dicks in the courtroom but as
> a third party that doesn't provide any one style, they can't really make
> a legal case against it. It's not like I am trying to copy their style
> or anything...

There are different widgets of different platforms because the screen size is very different.

iPad has slightly different widgets because it has a larger screen then the iPhone. With these widgets one can take better advantage of the larger screen size.

The tabs in Safari is a perfect example of this. On the iPad it has tabs that look and behave more or less the same as on the desktop version. On the iPhone it looks and behaves very different. The reason for this is that you have a larger screen on iPad then iPhone.

Also on a device with a touch screen you need larger buttons. Using them same buttons on a desktop application would just be a waste of space that could be used for the content area instead. You can use a lot smaller buttons on a desktop application where you have access to a mouse. Using the same small buttons on a device with a touch screen would not be very smart.

BTW, what Microsoft is doing with Windows 8, I think that's so wrong I don't know how to describe it.

I feel like we have had this discussion before...

-- 
/Jacob Carlborg

On Tuesday, 19 February 2013 at 09:06:37 UTC, Jacob Carlborg wrote:

>
> Also on a device with a touch screen you need larger buttons. Using them same buttons on a desktop application would just be a waste of space that could be used for the content area instead. You can use a lot smaller buttons on a desktop application where you have access to a mouse. Using the same small buttons on a device with a touch screen would not be very smart.
>
> BTW, what Microsoft is doing with Windows 8, I think that's so wrong I don't know how to describe it.
>


That's the power of a declarative UI: separate behaviour and design. If you want a larger button, touch sensitive - even thought sensitive :), just change the design to better suit device features, but don't change the behaviour. Just to keep your scroll bar example: in desktop world we can keep the scroll bar visible on the screen. In the touch sensitive world, we can hide most of scrollbar content, keep only some arrows to tell the user there is more data, but leave it to respond to common gestures to scroll up and down. From the programmer perspective, The scrollbar object will have the same methods, same events and the same properties. The end user/designer will call/use these methods/properties performing different actions specific to target device.