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/

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

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.

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/

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/

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

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

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.

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/

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