www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - WPFfor d

reply "js.mdnq" <js_adddot+mdng gmail.com> writes:
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?
Feb 16 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-17 04:28, js.mdnq 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?
DWT is a GUI library written in D. It's a port of the Java library SWT. I'm don't know exactly which features you're referring to. DWT: https://github.com/d-widget-toolkit/dwt -- /Jacob Carlborg
Feb 17 2013
prev sibling next sibling parent reply "Michael" <pr m1xa.com> writes:
On Sunday, 17 February 2013 at 03:28:29 UTC, js.mdnq 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?
WPF - hardware accelerated gui. gtk3 (in D - gtkD) or any with open gl window support. If about xaml - Qt/qml, gtk/glade etc. If I understand correctly ;) But even MS promote C++/xaml without wpf. Wpf generally for corporate users, legacy reasons.
Feb 17 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 17.02.2013 13:37, schrieb Michael:
 On Sunday, 17 February 2013 at 03:28:29 UTC, js.mdnq 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?
WPF - hardware accelerated gui. gtk3 (in D - gtkD) or any with open gl window support. If about xaml - Qt/qml, gtk/glade etc. If I understand correctly ;) But even MS promote C++/xaml without wpf. Wpf generally for corporate users, legacy reasons.
There we go again, XAML is WPF. The fact that Silverlight, WPF and XAML/WinRT have some changes among them does not change the fact that the technology at his core is the same. -- Paulo
Feb 17 2013
parent reply "Michael" <pr m1xa.com> writes:
On Sunday, 17 February 2013 at 15:29:56 UTC, Paulo Pinto wrote:
 There we go again, XAML is WPF.
xaml can be used with WinForms. yes, maybe technology the same, but concrete implementations are different. For example, they all use hardware acceleration.
Feb 17 2013
parent reply "rumbu" <rumbu rumbu.ro> writes:
On Sunday, 17 February 2013 at 16:05:49 UTC, Michael wrote:
 On Sunday, 17 February 2013 at 15:29:56 UTC, Paulo Pinto wrote:
 There we go again, XAML is WPF.
xaml can be used with WinForms. yes, maybe technology the same, but concrete implementations are different. For example, they all use hardware acceleration.
XAML is a descriptive markup language and has nothing to do with WinForms. Of course, you can host a WPF user control in a WinForms ElementHost but that's all. The closest thing to WPF that you can use in D is QML/QtD. And Microsoft is promoting C++/XAML for Windows Store Applications, you cannot write desktop applications using WinRT. You're stuck in the desktop world to classic WinAPI/C++ development or WPF/any .NET language.
Feb 17 2013
next sibling parent "Michael" <pr m1xa.com> writes:
 XAML is a descriptive markup language and has nothing to do 
 with WinForms.
just google winforms xaml.
 And Microsoft is promoting C++/XAML for Windows Store 
 Applications, you cannot write desktop applications using 
 WinRT. You're stuck in the desktop world to classic WinAPI/C++ 
 development or WPF/any .NET language.
MFC... Anything that able read serialized form(xaml/xmlreader, glade, qml, fluid etc) and push it to runtime if not rely solely on ms stack.
Feb 17 2013
prev sibling parent reply "Roy Obena" <robena gmail.com> writes:
 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)
Feb 18 2013
parent "Michael" <pr m1xa.com> writes:
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.
Feb 18 2013
prev sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
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.... -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Feb 17 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-17 20:00, Adam Wilson wrote:

 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've been thinking for a long time to try and serialize widgets in DWT. And then build a tool for graphically creating GUIs. I guess that's similar to how XAML works. -- /Jacob Carlborg
Feb 17 2013
next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Sun, 17 Feb 2013 11:06:40 -0800, Jacob Carlborg <doob me.com> wrote:

 On 2013-02-17 20:00, Adam Wilson wrote:

 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've been thinking for a long time to try and serialize widgets in DWT. And then build a tool for graphically creating GUIs. I guess that's similar to how XAML works.
It is similar yes. In WPF, XAML is specialized XML that is deserialized at deserialized at runtime. I think for D compile-time deserialization makes sense for two reasons. The first is that you get more flexibility to work around D's lack of the deep reflection capabilites of .NET. The second is that as good as XAML is, it is ridiculously verbose. Creating a purpose-built DSL would be a much more efficient implementation idea IMHO. This would also make it much easier to re-target the GUI language and libraries to other languages. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Feb 17 2013
next sibling parent reply "rumbu" <rumbu rumbu.ro> writes:
On Sunday, 17 February 2013 at 21:56:26 UTC, Adam Wilson wrote:
 On Sun, 17 Feb 2013 11:06:40 -0800, Jacob Carlborg 
 <doob me.com> wrote:

 On 2013-02-17 20:00, Adam Wilson wrote:

 I've been thinking for a long time to try and serialize 
 widgets in DWT. And then build a tool for graphically creating 
 GUIs. I guess that's similar to how XAML works.
It is similar yes. In WPF, XAML is specialized XML that is
XAML code is embedded in assembly as BAML and deserialized to a visual tree at *runtime* through Application.LoadComponent subsequentely calling XamlReader.LoadBaml.
 I think for D compile-time deserialization makes sense for two 
 reasons. The first is that you get more flexibility to work 
 around D's lack of the deep reflection capabilites of .NET.
I doubt that it's possible to implement something like a DependencyProperty mechanism or a simple INotifyPropertyChanged without runtime reflection. Anyway, if you intend to set-up a team in this direction, you can count on me.
Feb 17 2013
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Sun, 17 Feb 2013 15:01:20 -0800, rumbu <rumbu rumbu.ro> wrote:

 On Sunday, 17 February 2013 at 21:56:26 UTC, Adam Wilson wrote:
 On Sun, 17 Feb 2013 11:06:40 -0800, Jacob Carlborg <doob me.com> wrote:

 On 2013-02-17 20:00, Adam Wilson wrote:

 I've been thinking for a long time to try and serialize widgets in  
 DWT. And then build a tool for graphically creating GUIs. I guess  
 that's similar to how XAML works.
It is similar yes. In WPF, XAML is specialized XML that is deserialized
XAML code is embedded in assembly as BAML and deserialized to a visual tree at *runtime* through Application.LoadComponent subsequentely calling XamlReader.LoadBaml.
Correct, but the BAML isn't XAML, it's a binary encoding that deserializes quicker. IMHO, it's still terribly slow. You should see some of the contortions we've made to your WPF interfaces to make them load faster ...
 I think for D compile-time deserialization makes sense for two reasons.  
 The first is that you get more flexibility to work around D's lack of  
 the deep reflection capabilites of .NET.
I doubt that it's possible to implement something like a DependencyProperty mechanism or a simple INotifyPropertyChanged without runtime reflection.
In WPF that statement is true, however, most of the reflection in WPF is not, strictly speaking, required, it's just how they choose to do it, along with a few other monumentally stupid decisions, like rendering a 2D circle as ~1000 polygons... It turns out that if they hadn't gone the deserialization route, they could have done something like DependencyObject.GetValue("PropertyName"), instead of DependencyObject.GetValue(DependencyProperty). Internally it wouldn't have made one iota of difference in speed as the internal implementation of DependencyObject as it is essentially a Dictionary<> collection. If you go the code generation route like I've proposed, the first option is trivially easy and MUCH faster at runtime. The biggest loss? You have to recompile to change the UI. Theoretically in WPF you could change the actual XAML on the fly, in reality, I've never heard of that being done in production code (and MS seems to agree because those features are conspicuously absent in Silverlight/WinRT).
 Anyway, if you intend to set-up a team in this direction, you can count  
 on me.
I'd love to get a team going on this. Note that I have no code written at this point. But as it stands, we'd all need to hash out some design decisions anyways. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Feb 17 2013
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 18.02.2013 00:29, schrieb Adam Wilson:
 [...]>>

 In WPF that statement is true, however, most of the reflection in WPF is
 not, strictly speaking, required, it's just how they choose to do it,
 along with a few other monumentally stupid decisions, like rendering a
 2D circle as ~1000 polygons...
  [...]
I have seen this quite a few times. It is not only how good a compiler/JIT is, but how things get coded as well. Sometimes before reaching for C and C++, it would be enough to use the right data structures or algorithms. -- Paulo
Feb 17 2013
parent "Adam Wilson" <flyboynw gmail.com> writes:
On Sun, 17 Feb 2013 15:49:57 -0800, Paulo Pinto <pjmlp progtools.org>  
wrote:

 Am 18.02.2013 00:29, schrieb Adam Wilson:
 [...]>>

 In WPF that statement is true, however, most of the reflection in WPF is
 not, strictly speaking, required, it's just how they choose to do it,
 along with a few other monumentally stupid decisions, like rendering a
 2D circle as ~1000 polygons...
  [...]
I have seen this quite a few times. It is not only how good a compiler/JIT is, but how things get coded as well. Sometimes before reaching for C and C++, it would be enough to use the right data structures or algorithms. -- Paulo
Well that's kind of my point. The method they used to draw a circle was about the most naive possible way it could be done with the tools they had. In short, the algorithm they used is stupidly brute force. http://jeremiahmorrill.wordpress.com/2011/02/14/a-critical-deep-dive-into-the-wpf-rendering-system/ -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Feb 17 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-18 00:29, Adam Wilson wrote:

 Correct, but the BAML isn't XAML, it's a binary encoding that
 deserializes quicker. IMHO, it's still terribly slow. You should see
 some of the contortions we've made to your WPF interfaces to make them
 load faster ...
On Mac OS X it works fine with runtime deserialization. -- /Jacob Carlborg
Feb 18 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-17 22:56, Adam Wilson wrote:

 It is similar yes. In WPF, XAML is specialized XML that is deserialized

 it is deserialized at runtime. I think for D compile-time
 deserialization makes sense for two reasons. The first is that you get
 more flexibility to work around D's lack of the deep reflection
 capabilites of .NET. The second is that as good as XAML is, it is
 ridiculously verbose. Creating a purpose-built DSL would be a much more
 efficient implementation idea IMHO. This would also make it much easier
 to re-target the GUI language and libraries to other languages.
I would at least start with deserializing at runtime, since that seems easier. This is also how GUI's are built on Mac OS X. Create the GUI in Xcode/InterfaceBuilder and it will serialize it to binary or XML. Then it will be deserialized at runtime. -- /Jacob Carlborg
Feb 18 2013
prev sibling parent "js.mdnq" <js_adddot+mdng gmail.com> writes:
On Sunday, 17 February 2013 at 19:06:41 UTC, Jacob Carlborg wrote:
 On 2013-02-17 20:00, Adam Wilson wrote:

 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've been thinking for a long time to try and serialize widgets in DWT. And then build a tool for graphically creating GUIs. I guess that's similar to how XAML works.
The features that WPF has is XAML - The ability to do much of gui design in a markup language, Binding - The ability to bind variables to each other so one can update another, good "widgets" that all support these types of features, retained mode graphics, and a whole framework that is tightly integrated with the design. Of course, you pay a high price in performance for this but generally it works well for business applications. XAML is basically similar in concept html but it is designed to tie in well with code behind. Anything you do in XAML can be done in code behind. QT 5 has something similar now and maybe better. (in fact, QT seems to have picked up a bunch of wpf concepts and ran with them)
Feb 17 2013
prev sibling next sibling parent reply "rumbu" <rumbu rumbu.ro> writes:
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:
... 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, especially in databinding features of WPF. Right now I have no idea how this can be implemented in D without runtime reflection.
Feb 17 2013
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 17.02.2013 20:21, schrieb rumbu:
 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:
... 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, especially in databinding features of WPF. Right now I have no idea how this can be implemented in D without runtime reflection.
Compile time reflection could be good enough probably.
Feb 17 2013
prev sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Sun, 17 Feb 2013 11:21:54 -0800, rumbu <rumbu rumbu.ro> wrote:

 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:
... 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, especially in databinding features of WPF. Right now I have no idea how this can be implemented in D without runtime reflection.
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. Make no mistake, this will be a huge undertaking, WPF is massive! But it could very well be the killer app for D. The ability to make GUI apps that function at native speeds while retaining much of the ease of WPF is highly attractive to a lot of developers, myself included... -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Feb 17 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Feb 18 2013
parent reply "rumbu" <rumbu rumbu.ro> writes:
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.
Feb 18 2013
parent reply Jacob Carlborg <doob me.com> writes:
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
Feb 18 2013
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
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/
Feb 18 2013
parent reply Jacob Carlborg <doob me.com> writes:
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
Feb 18 2013
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
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/
Feb 18 2013
parent reply Jacob Carlborg <doob me.com> writes:
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
Feb 19 2013
parent reply "rumbu" <rumbu rumbu.ro> writes:
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.
Feb 19 2013
parent reply Jacob Carlborg <doob me.com> writes:
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
Feb 19 2013
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
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/
Feb 19 2013
parent reply Jacob Carlborg <doob me.com> writes:
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
Feb 19 2013
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
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/
Feb 19 2013
parent reply Jacob Carlborg <doob me.com> writes:
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
Feb 19 2013
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Tue, 19 Feb 2013 23:37:58 -0800, Jacob Carlborg <doob me.com> wrote:

 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.
Most allow you to tweak certain aspects, not remove the entire rendering output and start over. I've never found any OS widget kit that allows completely and total control of the widget at the pixel level. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Feb 20 2013
next sibling parent reply "Michael" <pr m1xa.com> writes:
 Most allow you to tweak certain aspects, not remove the entire 
 rendering output and start over. I've never found any OS widget 
 kit that allows completely and total control of the widget at 
 the pixel level.
On win mobile if std win forms were not enough, we were able use win api(good old c and pointers). It's highly customizable, but with high amount of hand work. In gui kits most slogans - "write less, get more". It's boosts development, but with less control.
Feb 20 2013
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Wed, 20 Feb 2013 11:21:57 -0800, Michael <pr m1xa.com> wrote:

 Most allow you to tweak certain aspects, not remove the entire  
 rendering output and start over. I've never found any OS widget kit  
 that allows completely and total control of the widget at the pixel  
 level.
On win mobile if std win forms were not enough, we were able use win api(good old c and pointers). It's highly customizable, but with high amount of hand work.
Right, in XAML I get the same customizability without the huge amounts of hand coding.
 In gui kits most slogans - "write less, get more". It's boosts  
 development, but with less control.
More to the point, very few approach it with the idea of splitting the View (style) from the Model(implementation). When you do that, you can do some very cool things with a reasonable amount of work. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Feb 20 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-20 21:01, Adam Wilson wrote:

 More to the point, very few approach it with the idea of splitting the
 View (style) from the Model(implementation). When you do that, you can
 do some very cool things with a reasonable amount of work.
Cocoa does that on Mac OS X. SWT does that together with JFace. -- /Jacob Carlborg
Feb 20 2013
parent "rumbu" <rumbu rumbu.ro> writes:
On Wednesday, 20 February 2013 at 21:03:31 UTC, Jacob Carlborg 
wrote:
 On 2013-02-20 21:01, Adam Wilson wrote:

 More to the point, very few approach it with the idea of 
 splitting the
 View (style) from the Model(implementation). When you do that, 
 you can
 do some very cool things with a reasonable amount of work.
Cocoa does that on Mac OS X. SWT does that together with JFace.
I studied these days some existing declarative alternatives to xaml (qml and yaml) and unfortunatelly they are far far far away from WPF. There is some thin support for data binding, but there is nothing like animations, triggers, templates, behaviours, typography, effects, validation and so on. If someone will dare sometime to such endeavor to port something like WPF for D, I reitrate my opinion that D will need some kind of runtime reflection, at least for design time support. Parsing tens of thousands of lines of code (if available) just to query the properties available for an object is not such a good idea. Another approach found in the native world is the one used by Delphi/FreePascal, but this will need to rethink the lib structure and will introduce a new language protection attribute. Delphi/Lazarus uses a new level of protection ("published") to decorate a object property available at runtime. Published properties are stored in the lib file (dcu file in Pascal) with type information. These kind of properties allow access to object internal structure for IDE form designers. Of course, a simple compiler switch will strip runtime information from the release version of the target executable.
Feb 20 2013
prev sibling next sibling parent reply "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Wednesday, 20 February 2013 at 16:56:11 UTC, Adam Wilson wrote:
 On Tue, 19 Feb 2013 23:37:58 -0800, Jacob Carlborg 
 <doob me.com> wrote:
clip
 Most in most tool kits you can override a drawing function or 
 specify some properties to change to look of a control.
Most allow you to tweak certain aspects, not remove the entire rendering output and start over. I've never found any OS widget kit that allows completely and total control of the widget at the pixel level.
In Qt anyways, you can use QPainter: http://qt-project.org/doc/qt-4.8/qpainter.html to basically get pixel level control of display for your custom widgets. I am not sure what you mean by 'OS widget kit' though - perhaps you are ruling out something like Qt there.
Feb 20 2013
parent "Adam Wilson" <flyboynw gmail.com> writes:
On Wed, 20 Feb 2013 11:44:26 -0800, Craig Dillabaugh  
<cdillaba cg.scs.carleton.ca> wrote:

 On Wednesday, 20 February 2013 at 16:56:11 UTC, Adam Wilson wrote:
 On Tue, 19 Feb 2013 23:37:58 -0800, Jacob Carlborg <doob me.com> wrote:
clip
 Most in most tool kits you can override a drawing function or specify  
 some properties to change to look of a control.
Most allow you to tweak certain aspects, not remove the entire rendering output and start over. I've never found any OS widget kit that allows completely and total control of the widget at the pixel level.
In Qt anyways, you can use QPainter: http://qt-project.org/doc/qt-4.8/qpainter.html to basically get pixel level control of display for your custom widgets. I am not sure what you mean by 'OS widget kit' though - perhaps you are ruling out something like Qt there.
Qt/QML is about the closest thing out there to WPF but it's still not quite as complete as WPF. Particularly it tends to fall down in the databinding and general view/model seperation areas. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Feb 20 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-20 17:56, Adam Wilson wrote:

 Most allow you to tweak certain aspects, not remove the entire rendering
 output and start over. I've never found any OS widget kit that allows
 completely and total control of the widget at the pixel level.
Sure you can. For example, the drawRect: method in NSView in Cocoa on Mac OS X: https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSView_Class/Reference/NSView.html#//apple_ref/occ/cl/NSView In SWT, just add a listener for the paint event: http://www.java2s.com/Tutorial/Java/0280__SWT/2420__SWT-Image.htm -- /Jacob Carlborg
Feb 20 2013
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Wed, 20 Feb 2013 13:02:26 -0800, Jacob Carlborg <doob me.com> wrote:

 On 2013-02-20 17:56, Adam Wilson wrote:

 Most allow you to tweak certain aspects, not remove the entire rendering
 output and start over. I've never found any OS widget kit that allows
 completely and total control of the widget at the pixel level.
Sure you can. For example, the drawRect: method in NSView in Cocoa on Mac OS X: https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSView_Class/Reference/NSView.html#//apple_ref/occ/cl/NSView In SWT, just add a listener for the paint event: http://www.java2s.com/Tutorial/Java/0280__SWT/2420__SWT-Image.htm
Yep, I can do the same thing in WinForms/GDI+. If that answer was good enough then WPF would never have needed to happen. In WPF I don't have to hook events and hand-implement drawing code, I can use a basic set of primitives to compose the look I want. This is about 10x quicker and scales better in vary screen sizes. I am a little baffled as to why my explanations aren't clicking ... perhaps we are reading the same words differently? -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Feb 20 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-02-21 01:56, Adam Wilson wrote:

 Yep, I can do the same thing in WinForms/GDI+. If that answer was good
 enough then WPF would never have needed to happen. In WPF I don't have
 to hook events and hand-implement drawing code, I can use a basic set of
 primitives to compose the look I want. This is about 10x quicker and
 scales better in vary screen sizes. I am a little baffled as to why my
 explanations aren't clicking ... perhaps we are reading the same words
 differently?
I'm not saying that your ideas are bad, except that I'm not a big fan of non-native GUIs. Perhaps non-native GUI is needed to make these things you explain easy. I really like your idea and would gladly work on it as a paid full time job. But I don't think I would work on this in my spare time. Now I'm trying to stay realistic and work with what we have, see how far that will take us. -- /Jacob Carlborg
Feb 20 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Feb 19 2013
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
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/
Feb 19 2013
parent reply Jacob Carlborg <doob me.com> writes:
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
Feb 19 2013
parent "Adam Wilson" <flyboynw gmail.com> writes:
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/
Feb 20 2013
prev sibling parent "Tiberiu Gal" <galtiberiu gmail.com> writes:
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.
Feb 19 2013