digitalmars.D - WPFfor d
- js.mdnq (4/4) Feb 16 2013 WPF is pretty nice for .net. Is there any work towards building a
- Jacob Carlborg (6/9) Feb 17 2013 DWT is a GUI library written in D. It's a port of the Java library SWT.
- Michael (7/11) Feb 17 2013 WPF - hardware accelerated gui. gtk3 (in D - gtkD) or any with
- Paulo Pinto (6/16) Feb 17 2013 There we go again, XAML is WPF.
- Adam Wilson (16/19) Feb 17 2013 If you're looking for something that is as easy to use as WPF with as mu...
- Jacob Carlborg (6/14) Feb 17 2013 I've been thinking for a long time to try and serialize widgets in DWT.
- Adam Wilson (16/28) Feb 17 2013 It is similar yes. In WPF, XAML is specialized XML that is deserialized ...
- rumbu (9/22) Feb 17 2013 XAML code is embedded in assembly as BAML and deserialized to a
- Adam Wilson (28/51) Feb 17 2013 Correct, but the BAML isn't XAML, it's a binary encoding that deserializ...
- Paulo Pinto (7/13) Feb 17 2013 I have seen this quite a few times.
- Adam Wilson (12/27) Feb 17 2013 Well that's kind of my point. The method they used to draw a circle was ...
- Jacob Carlborg (4/8) Feb 18 2013 On Mac OS X it works fine with runtime deserialization.
- Jacob Carlborg (8/17) Feb 18 2013 I would at least start with deserializing at runtime, since that seems
- js.mdnq (13/32) Feb 17 2013 The features that WPF has is XAML - The ability to do much of gui
- rumbu (5/8) Feb 17 2013 I'm interested, especially in databinding features of WPF. Right
- Paulo Pinto (2/10) Feb 17 2013 Compile time reflection could be good enough probably.
- Adam Wilson (30/38) Feb 17 2013 I think it could be easily implemented if instead of using runtime XAML ...
- Jacob Carlborg (5/7) Feb 18 2013 How is this going to work? Some of the native GUI systems are not thread...
- rumbu (7/13) Feb 18 2013 WPF is far from a native GUI. All "controls" are drawn of the
- Jacob Carlborg (6/11) Feb 18 2013 Yeah, I suspected that. But creating a new platform independent GUI
- Adam Wilson (22/31) Feb 18 2013 Indeed it is a massive undertaking, but platform independence is KEY to ...
- Jacob Carlborg (17/37) Feb 18 2013 I haven't run into any problems with different sizes of widgets using
- Adam Wilson (29/64) Feb 18 2013 Define "not as easy"? I can restyle a List in WPF so completely that you...
- Jacob Carlborg (37/52) Feb 19 2013 Perhaps not confused. But I get darn annoyed when a widget doesn't work
- rumbu (15/24) Feb 19 2013 That's the power of a declarative UI: separate behaviour and
- Jacob Carlborg (9/20) Feb 19 2013 That would be good if it could work like that. But that's not what I
- Adam Wilson (23/41) Feb 19 2013 In the old OS widget model where you have to rebuild the widget from the...
- Jacob Carlborg (5/8) Feb 19 2013 It's not about styling a control differently. It's about using a
- Adam Wilson (18/24) Feb 19 2013 My point is that I should not have to rebuild a scrollbar from the groun...
- Jacob Carlborg (5/16) Feb 19 2013 Most in most tool kits you can override a drawing function or specify
- Adam Wilson (10/24) Feb 20 2013 Most allow you to tweak certain aspects, not remove the entire rendering...
- Michael (5/9) Feb 20 2013 On win mobile if std win forms were not enough, we were able use
- Adam Wilson (12/21) Feb 20 2013 Right, in XAML I get the same customizability without the huge amounts o...
- Jacob Carlborg (4/7) Feb 20 2013 Cocoa does that on Mac OS X. SWT does that together with JFace.
- rumbu (22/29) Feb 20 2013 I studied these days some existing declarative alternatives to
- Craig Dillabaugh (8/18) Feb 20 2013 In Qt anyways, you can use QPainter:
- Adam Wilson (11/30) Feb 20 2013 Qt/QML is about the closest thing out there to WPF but it's still not
- Jacob Carlborg (8/11) Feb 20 2013 Sure you can. For example, the drawRect: method in NSView in Cocoa on
- Adam Wilson (14/23) Feb 20 2013 Yep, I can do the same thing in WinForms/GDI+. If that answer was good
- Jacob Carlborg (10/17) Feb 20 2013 I'm not saying that your ideas are bad, except that I'm not a big fan of...
- Jacob Carlborg (6/25) Feb 19 2013 When using a custom tool kit like this. How do you handle windows, you
- Adam Wilson (10/35) Feb 19 2013 Same way games handle windows, you get the window, hijack the handle for...
- Jacob Carlborg (4/7) Feb 19 2013 Games are usually full screen and everything is rendered in a single win...
- Adam Wilson (11/18) Feb 20 2013 Sure, but the method they use to do that works just fine for this as wel...
- Tiberiu Gal (2/17) Feb 19 2013 I'm interested in joining.
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
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
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
Am 17.02.2013 13:37, schrieb Michael:On Sunday, 17 February 2013 at 03:28:29 UTC, js.mdnq wrote: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. -- PauloWPF 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
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
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: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.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
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
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
On Monday, 18 February 2013 at 15:05:03 UTC, Roy Obena wrote: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.The closest thing to WPF that you can use in D is QML/QtD.So why not support QML/QtD?
Feb 18 2013
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
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
On Sun, 17 Feb 2013 11:06:40 -0800, Jacob Carlborg <doob me.com> wrote:On 2013-02-17 20:00, Adam Wilson wrote: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/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.
Feb 17 2013
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:XAML code is embedded in assembly as BAML and deserialized to a visual tree at *runtime* through Application.LoadComponent subsequentely calling XamlReader.LoadBaml.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 isI 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
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: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 Sun, 17 Feb 2013 11:06:40 -0800, Jacob Carlborg <doob me.com> wrote:XAML code is embedded in assembly as BAML and deserialized to a visual tree at *runtime* through Application.LoadComponent subsequentely calling XamlReader.LoadBaml.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 deserializedIn 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).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.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
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
On Sun, 17 Feb 2013 15:49:57 -0800, Paulo Pinto <pjmlp progtools.org> wrote:Am 18.02.2013 00:29, schrieb Adam Wilson: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/[...]>> 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
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
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
On Sunday, 17 February 2013 at 19:06:41 UTC, Jacob Carlborg wrote:On 2013-02-17 20:00, Adam Wilson wrote: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)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.
Feb 17 2013
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 toput 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
Am 17.02.2013 20:21, schrieb rumbu:On Sunday, 17 February 2013 at 19:01:14 UTC, Adam Wilson wrote:Compile time reflection could be good enough probably.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 toput 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
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: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/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 toput 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
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
On Monday, 18 February 2013 at 08:30:32 UTC, Jacob Carlborg wrote:On 2013-02-17 23:29, Adam Wilson 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.- 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.
Feb 18 2013
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
On Mon, 18 Feb 2013 01:33:51 -0800, Jacob Carlborg <doob me.com> wrote:On 2013-02-18 09:59, rumbu 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). 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/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.
Feb 18 2013
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
On Mon, 18 Feb 2013 12:34:20 -0800, Jacob Carlborg <doob me.com> wrote:On 2013-02-18 21:10, Adam Wilson wrote: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...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.I have yet to encounter this fabled user confusion during usability testing, so I am gonna file this one under "myth".That has more to do with the fact that MS made it than any technical limitation.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.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/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.
Feb 18 2013
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
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
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
On Tue, 19 Feb 2013 02:37:47 -0800, Jacob Carlborg <doob me.com> wrote:On 2013-02-19 10:29, rumbu wrote: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.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.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
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
On Tue, 19 Feb 2013 12:31:55 -0800, Jacob Carlborg <doob me.com> wrote:On 2013-02-19 21:06, 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. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/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.
Feb 19 2013
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
On Tue, 19 Feb 2013 23:37:58 -0800, Jacob Carlborg <doob me.com> wrote:On 2013-02-19 21:43, 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. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/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.
Feb 20 2013
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
On Wed, 20 Feb 2013 11:21:57 -0800, Michael <pr m1xa.com> wrote:Right, in XAML I get the same customizability without the huge amounts of hand coding.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.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
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
On Wednesday, 20 February 2013 at 21:03:31 UTC, Jacob Carlborg wrote:On 2013-02-20 21:01, Adam Wilson wrote: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.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.
Feb 20 2013
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:clipIn 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.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.
Feb 20 2013
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: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/On Tue, 19 Feb 2013 23:37:58 -0800, Jacob Carlborg <doob me.com> wrote:clipIn 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.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.
Feb 20 2013
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
On Wed, 20 Feb 2013 13:02:26 -0800, Jacob Carlborg <doob me.com> wrote:On 2013-02-20 17: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? -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/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
Feb 20 2013
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
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
On Tue, 19 Feb 2013 12:35:17 -0800, Jacob Carlborg <doob me.com> wrote:On 2013-02-17 23:29, 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. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/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.
Feb 19 2013
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
On Tue, 19 Feb 2013 23:40:12 -0800, Jacob Carlborg <doob me.com> wrote:On 2013-02-19 21:38, Adam Wilson wrote: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/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.
Feb 20 2013
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:I'm interested in joining.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....
Feb 19 2013