On 2013-02-19 10:29, rumbu wrote:

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

That would be good if it could work like that. But that's not what I have usually seen with custom widgets. They just don't work in one way or another.

The problem isn't just designing a widget the looks differently on different devices. Sometimes the application needs to be completely different.

-- 
/Jacob Carlborg

On Sunday, 17 February 2013 at 19:01:14 UTC, Adam Wilson wrote:
> On Sat, 16 Feb 2013 19:28:27 -0800, js.mdnq <js_adddot+mdng@gmail.com> wrote:
>
>> WPF is pretty nice for .net. Is there any work towards building a nice gui presentation layer for D, something that has or will have all those nice modern features we are seeing in stuff like WPF, QT, etc?
>
> If you're looking for something that is as easy to use as WPF with as much power, you won't find it in the open-source world. WPF is over 40,000 classes strong, and while Open-Source is generally good for large systems projects WPF requires some specialized knowledge to pull off with any success. I have the graphics training required and I would love to get started on a WPF for D but given that it is such a huge undertaking i'd need help, if you're interested in helping let me know. I'd love to put together a team and starting hacking out some code....


I'm interested in joining.

On Tue, 19 Feb 2013 02:37:47 -0800, Jacob Carlborg <doob@me.com> wrote:

> On 2013-02-19 10:29, rumbu wrote:
>
>> 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.
>
> That would be good if it could work like that. But that's not what I have usually seen with custom widgets. They just don't work in one way or another.
>

In the old OS widget model where you have to rebuild the widget from the ground up if you want to change the look this is absolutely the case, most programmers suck at reimplementing this stuff. With WPF this is a complete non-issue. Because the look (style) of the widget is completely, 100%, and unquestionably separated from the function of the control, I can use a known-good implementation of the widget without being locked into each OS's look-and-feel, which means that my app has the same look-and-feel across many devices. Users LOVE that.

As a UI design I don't give one hoot what the OS thinks my UI should look like, that's MY job, I succeed or fail on my own, and TBH, OS UI uniformity is no guarantee of success. I've seen just as many good OS UI's as bad ones. Because it turns out that the OS UI isn't the determining factor in a UI's success, the designer is.

> The problem isn't just designing a widget the looks differently on different devices. Sometimes the application needs to be completely different.
>

RIGHT! Which is why re-styling controls is so critical. I can get uniform functionality with infinite stylistic possibilities that allow me to choose the best style for each device.

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

On 2013-02-19 21:06, Adam Wilson wrote:

> RIGHT! Which is why re-styling controls is so critical. I can get
> uniform functionality with infinite stylistic possibilities that allow
> me to choose the best style for each device.

It's not about styling a control differently. It's about using a different control.

-- 
/Jacob Carlborg

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

> I think it could be easily implemented if instead of using runtime XAML
> deserialization and reflection we used a specialized GUI definition
> language that is translated into D at compile time. This would give the
> required flexibility to work around D's lack of the deep reflection
> capabilities that .NET has and make the app much quicker at runtime. I'd
> prefer to avoid reflection as much as possible due to the associated
> performance hits.
>
> I love the ideas behind WPF, but as usual at Microsoft, WPF is a very
> poor implementation of a fantastic idea.
>
> Thumbnail sketch of my vision for a WPF-like GUI Library in D, for now
> I'll call it Horizon:
> - Purpose built domain specific language for GUI declaration
> - Pluggable language compiler back-end to support different target
> languages.
> - Dependency Property system similar to WPF to support flexible
> databinding.
> - Concurrent Dependency Properties to allow multi-threaded access to the
> UI. (Needs specialized container support in Phobos.)
> - Pluggable rendering core to support multiple operating systems.

When using a custom tool kit like this. How do you handle windows, you do need to use native windows, right? I mean, you need to receive events and similar for your application.

-- 
/Jacob Carlborg

On Tue, 19 Feb 2013 12:35:17 -0800, Jacob Carlborg <doob@me.com> wrote:

> On 2013-02-17 23:29, Adam Wilson wrote:
>
>> I think it could be easily implemented if instead of using runtime XAML
>> deserialization and reflection we used a specialized GUI definition
>> language that is translated into D at compile time. This would give the
>> required flexibility to work around D's lack of the deep reflection
>> capabilities that .NET has and make the app much quicker at runtime. I'd
>> prefer to avoid reflection as much as possible due to the associated
>> performance hits.
>>
>> I love the ideas behind WPF, but as usual at Microsoft, WPF is a very
>> poor implementation of a fantastic idea.
>>
>> Thumbnail sketch of my vision for a WPF-like GUI Library in D, for now
>> I'll call it Horizon:
>> - Purpose built domain specific language for GUI declaration
>> - Pluggable language compiler back-end to support different target
>> languages.
>> - Dependency Property system similar to WPF to support flexible
>> databinding.
>> - Concurrent Dependency Properties to allow multi-threaded access to the
>> UI. (Needs specialized container support in Phobos.)
>> - Pluggable rendering core to support multiple operating systems.
>
> When using a custom tool kit like this. How do you handle windows, you do need to use native windows, right? I mean, you need to receive events and similar for your application.
>

Same way games handle windows, you get the window, hijack the handle for DirectX or OpenGL and then tell those toolkits what window style you want. This allows the designer to choose to keep the window chrome or not.

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

On Tue, 19 Feb 2013 12:31:55 -0800, Jacob Carlborg <doob@me.com> wrote:

> On 2013-02-19 21:06, Adam Wilson wrote:
>
>> RIGHT! Which is why re-styling controls is so critical. I can get
>> uniform functionality with infinite stylistic possibilities that allow
>> me to choose the best style for each device.
>
> It's not about styling a control differently. It's about using a different control.
>

My point is that I should not have to rebuild a scrollbar from the ground up when I want to make it look different. Or button, or textbox, or whatever. When I need scrolling functionality I just use a scrollbar then style it for the required usage, in many ways this vastly reduces improper widget function due to being able to apply a standard implementation to a much wider variety of usages, I have ListBoxes in my WPF projects that you'd have no idea were just ListBoxes because the look nothing like an OS ListBox For example one ListBox I have looks more like a TreeView, except that I didn't actually need the TreeView capability, I just need to make it LOOK like one. I also usually add some useful visuals that the OS widget could never do.

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

On 2013-02-19 21:43, Adam Wilson wrote:

> My point is that I should not have to rebuild a scrollbar from the
> ground up when I want to make it look different. Or button, or textbox,
> or whatever. When I need scrolling functionality I just use a scrollbar
> then style it for the required usage, in many ways this vastly reduces
> improper widget function due to being able to apply a standard
> implementation to a much wider variety of usages, I have ListBoxes in my
> WPF projects that you'd have no idea were just ListBoxes because the
> look nothing like an OS ListBox For example one ListBox I have looks
> more like a TreeView, except that I didn't actually need the TreeView
> capability, I just need to make it LOOK like one. I also usually add
> some useful visuals that the OS widget could never do.

Most in most tool kits you can override a drawing function or specify some properties to change to look of a control.

-- 
/Jacob Carlborg

On 2013-02-19 21:38, Adam Wilson wrote:

> Same way games handle windows, you get the window, hijack the handle for
> DirectX or OpenGL and then tell those toolkits what window style you
> want. This allows the designer to choose to keep the window chrome or not.

Games are usually full screen and everything is rendered in a single window.

-- 
/Jacob Carlborg

On Tue, 19 Feb 2013 23:40:12 -0800, Jacob Carlborg <doob@me.com> wrote:

> On 2013-02-19 21:38, Adam Wilson wrote:
>
>> Same way games handle windows, you get the window, hijack the handle for
>> DirectX or OpenGL and then tell those toolkits what window style you
>> want. This allows the designer to choose to keep the window chrome or not.
>
> Games are usually full screen and everything is rendered in a single window.
>

Sure, but the method they use to do that works just fine for this as well. You grab the window handle, you own the whole drawing process, you can do with it what you want. Windowed mode in games is quite common when debugging. And WPF handles multiple windows just find.

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