On Thursday, 28 November 2013 at 14:49:33 UTC, Chris wrote:
> On Thursday, 28 November 2013 at 13:30:53 UTC, Luís Marques wrote:
>> On Thursday, 28 November 2013 at 12:13:42 UTC, Chris wrote:
>>> What I meant was no bindings to native widgets or other toolkits. DWT (like SWT) uses the native widgets and needs an interface. I was thinking of a toolkit where everything is provided by D and done in D without any reference to native frameworks (Cocoa etc.).
>>
>> Whatever API / bindings you use, please don't expose non-native UIs to users (drawn from scratch, either mimicking the native UI or not). They never completely integrate with the OS, subtly deviating from the native behaviour in ways that range from awkward to infuriating, and are always playing catch-up to the latest OS changes.
>>
>> For instance, take Viber for the Mac: what could be a great application (most of the complexity of a VoIP app isn't even in the UI), has awkward behaviors (e.g., the scrolling panes don't implement rubber banding, which makes them feel extremely unresponsive in OS X), badly imitated controls (e.g., the chat text box context menu, in OS X at least), etc. Features which are both complex and subtle like internationalisation also tend to break.
>>
>> The situation was already bad when the Windows, Mac and Linux interfaces were, overall, pretty similar (many of the non-optimal design decisions in apps with non-native UIs tended to appear where there were differences, such as in OS X global menus vs Windows' per window menus). With the trend toward newer and more diverse interface approaches, such as attempts to try to bring traditional computers to touch screen hardware, non-native UIs will tend to perform even worse, feeling even more alien to the end users.
>
> I don't know, but there are apps out there that do their own thing rather than relying on the system. I think Chrome and Opera are implemented like that. The thing is that people are getting used to different UIs now, because they use e.g. an iPad, an Android phone and a Windows PC (both privately and at work). So maybe everything is going in the direction of common UI features. Take for example multi-touch. Years ago Apple was way ahead (zooming in and out, rotating pictures etc.). Now most touch screen devices feature the same set of movements (e.g. scroll with middle and ring finger on track pad).
>
> Also, when writing bindings to native widgets, you're always playing catch-up too. Once you've got your bindings, the native toolkit has new methods, features and classes. I still think it would be good to have an independent GUI toolkit, like Java Swing / FX as opposed to SWT.

Current Opera stuff is "everything javascript".The setting page is a js stuff the download page is a js stuff...And everybody complain about this: js ans css.
Seriously, opera is not anymore a good example.

Le 29/11/2013 03:00, Chris Cain a écrit :
> On Friday, 29 November 2013 at 01:44:34 UTC, Dicebot wrote:
>> Still lacking proper beard ;)
>
> A programmer without a beard! Blasphemy! Witch!
>
> ----
>
> But anyway, going along with what you guys are saying, if you've ever
> seen reviews on Android apps, a lot of apps get lots of bad reviews for
> not adhering to the Android design standards. Using cross-platform
> toolkits are usually a death sentence for your rating. So, there's a lot
> to be said about making sure your app looks consistent in the OS it's
> running in.
>
> Some apps do "get away" with something that is somewhat custom. Take,
> for instance, Steam on Windows. It doesn't look like a "proper" Windows
> application, but it works very well for it regardless. That said, Steam
> on Mac is terrible because it feels too much like a windows app there
> (mainly in regards to scrolling behavior).
>
> That all said, if I were writing a GUI app in D right now, I would
> probably write my own toolkit and make something super simple (but
> "good" looking) to test out some new ideas. I think we really need an
> easy, straight-forward, and powerful UI toolkit that takes advantage of
> D's unique features (such as compile-time specialization, maybe using
> DSLs that compiled & used at compile-time instead of runtime) while
> reflecting well in comparison to the newest paradigms of application
> design (think how Android & iOS apps are made and maybe even a bit of
> web design). I can't quite precisely quantify what we need, but I think
> a fresh approach to the UI programming interface could set D apart in
> this area.
>
> Simply using a translation of an old UI toolkit is "easy" but will not
> make UI applications pleasing to develop.
+1

For my work I work on a huge application that was actually only available on iOS, with his interface wrote in cocoa. The next version will be ported to iOS, Android, Windows and Mac OS X (maybe linux), so we completely rewrite the interface with QML, because to increase the application identity over multiple platforms and provide something really easy to use for customers. Providing an UI that match to mobile ones will remove the apprehension of users instead of Widgets making the application looks like a professional tool.

I also think that professionals want beautiful apps too, just take a look to Visual, less and less developers want use vim or emacs.

A lot of progress have to be done on UI and I don't think that it will necessary impulse by OS developers.

Le 29/11/2013 14:31, Jacob Carlborg a écrit :
> On 2013-11-28 21:54, Xavier Bigand wrote:
>
>> Yep, that the goal, having applications with a real personality. I don't
>> think it's an issue especially when application is full screen and
>> respect pictographs (icons and texts) standards,...
>
> "real personality", it's more of trying to emulate the native toolkit to
> fails.
>
>> Having custom UI can help applications to improve ergonomic with
>> dedicated behaviors when it's needed.
>>
>> D itself isn't limited to one policy, you can do objects or not,... the
>> only things that is important is to let a strong default couple of style
>> and ergonomic without adding complexity for users want do some custom
>> stuff.
>>
>>
>> What is native on windows ?
>>   - Win32
>>   - Winforms
>>   - Qt Widgets (that is near Win32)?
>>
>> And on linux ?
>>   - GTK (with gnome and KDE)
>>   - Qt QML (KDE future)
>>
>> A native UI isn't necessary considered as the standard one, maybe Qt
>> have a chance to be a real standard (on many platforms).
>
> There's one thing in creating a completely new GUI, like games do, and a
> completely different thing in trying to emulate a native toolkit and
> fail. The above video is an example of the latter.
>
QML and mostly Qt Quick Controls are really young technologies and certainly not finished. The important things of Quick Controls is that it provides the default skin of the OS and the correct behaviors, but It's preferable to adapt it to import a custom Skin.

Digia certainly think that it's important to simplify the transition between old (OS natvie UI) and new (fully custom UI) usages.

Le 29/11/2013 18:08, thedeemon a écrit :
> On Thursday, 28 November 2013 at 20:55:02 UTC, Xavier Bigand wrote:
>> What is native on windows ?
>>  - Win32
>>  - Winforms
>>  - Qt Widgets (that is near Win32)?
>
> I would say Win32. Winforms is mostly a thin wrapper over Win32.
> However things get more complicated if you take into account WPF
> (completely new written from scratch UI library which makes your app
> look a bit different and start in just 25 seconds ;) ) and Win 8 Metro
> UI, again based on different mechanisms and having completely different
> look and feel.

So you just tell that on Windows itself there is no real native UI, it changes. And now when you use Windows 8 you have some old applications based on Win32 UI that looks horrible and not well integrated.
In this case "natives" aren't better.

Le 29/11/2013 04:48, Rikki Cattermole a écrit :
> On Thursday, 28 November 2013 at 12:13:42 UTC, Chris wrote:
>> On Thursday, 28 November 2013 at 12:05:09 UTC, Jacob Carlborg wrote:
>>> On 2013-11-28 11:12, Chris wrote:
>>>
>>>> +1 GtkD & Glade (UI builder) are very good (http://gtkd.org/).
>>>> Hopefully
>>>> one day we will have our own pure D GUI toolkit.
>>>
>>> DWT is a pure D GUI toolkit.
>>
>> What I meant was no bindings to native widgets or other toolkits. DWT
>> (like SWT) uses the native widgets and needs an interface. I was
>> thinking of a toolkit where everything is provided by D and done in D
>> without any reference to native frameworks (Cocoa etc.).
>
> DOOGLE[1] currently only depends on libfreetype2, (with Windows as only
> target) Windows API and OpenGL. I would remove libfreetype2 but.. its
> basically standard for font rasterization cross platform wise.
> I have designed it to have its interface abstracted away from the
> implementation fully.
>
> Its current state is well listed on my blog[2] it may not look much now
> and not ready for production use, but definitely should be said.
>
> [1] https://github.com/rikkimax/doogle
> [2]
> http://alphaglosined.blogspot.com/2013/11/web-services-and-opengl-oh-my.html
>

You may want take a look to DQuick :
https://github.com/D-Quick/DQuick

It's run on top of openGL too, the main difference is that you describe the UI in dedicated script files. Scripts provide allow to provide fully dynamical UIs.

An UI file (original lua script format for the moment) :

GraphicItem
{	
    id = "main",

	Image {
		id = "kerningImageButton",
		
		source = "images/border-image.png",
		width = 300,
		height = 50,

		MouseArea {
			id = "kerningButton",
			width = function()
				return kerningImageButton.width
			end,
			height = function()
				return kerningImageButton.height
			end,
		},
	},

	ScrollView {
		id = "scrollView",
	
		y = function()
			return kerningImageButton.height
		end,
		width = function()
			return main.width
		end,
		height = function()
			return main.height - scrollView.y
		end,
		
		clip = true,

		Text {
			id = "text",
		
			wrapMode = Text.WrapMode.WordWrap,
		
			width = function()
				return scrollView.width
			end,
			height = function()
				return scrollView.height
			end,

			text = textFr,
			family = function()
				if (kerningButton.pressed) then
					return "AngsanaUPC"
				end
				return "Arial"
			end,
			fontSize = 24,
			fontStyle = function()
				if (kerningButton.pressed) then
					return Text.FontStyle.Italic
				end
				return Text.FontStyle.Regular
			end,
		},
	},
}

On Friday, 29 November 2013 at 17:03:02 UTC, thedeemon wrote:
> On Thursday, 28 November 2013 at 13:30:53 UTC, Luís Marques wrote:
>> Whatever API / bindings you use, please don't expose non-native UIs to users (drawn from scratch, either mimicking the native UI or not). They never completely integrate with the OS, subtly deviating from the native behaviour in ways that range from awkward to infuriating, and are always playing catch-up to the latest OS changes.
>
> This is pure Mac talk.
> In Windows the "native" UI elements are so scarce and primitive, that most apps with decent UI end up making their own. For example, one would assume that UI elements that can be found in MS Office are native and can be used in other apps. But they are not, Office used its own UI library and never shared it with anyone. Ribbon implementation that comes with recent Visual Studio is a completely different implementation made by custom drawing, mimicking the look of Office. Actually, there are even several different implementations, for different languages.
> Relying purely on native controls leads nowhere.

You are discussing the creation of custom controls, while I was discussing the use of GUI libraries that recreate from scratch things like:

  - all controls, even the basic ones
  - UI behaviours (e.g., scrolling, double click times, etc.), badly mimicking the native system
  - text rendering, unicode/localization processing, etc.
  - integration with the native accessibility features
  - event processing

Is possible to create custom controls while still playing relatively nice with the native UI platform, and thus avoid *some* of the problems mentioned, by inhering as much from the platform as possible (text rendering, scrolling, accessibility, etc.). For Apple platforms the advice is to avoid custom controls when possible, which became easier in iOS when the native controls became more skinnable. When custom controls are needed they still integrate with the platform to a reasonable extent, and thus while the *look* may be foreign, the *behaviours* tend to feel native.

On 11/29/13 9:03 AM, thedeemon wrote:
> On Thursday, 28 November 2013 at 13:30:53 UTC, Luís Marques wrote:
>> Whatever API / bindings you use, please don't expose non-native UIs to
>> users (drawn from scratch, either mimicking the native UI or not).
>> They never completely integrate with the OS, subtly deviating from the
>> native behaviour in ways that range from awkward to infuriating, and
>> are always playing catch-up to the latest OS changes.
>
> This is pure Mac talk.
> In Windows the "native" UI elements are so scarce and primitive, that
> most apps with decent UI end up making their own. For example, one would
> assume that UI elements that can be found in MS Office are native and
> can be used in other apps. But they are not, Office used its own UI
> library and never shared it with anyone. Ribbon implementation that
> comes with recent Visual Studio is a completely different implementation
> made by custom drawing, mimicking the look of Office. Actually, there
> are even several different implementations, for different languages.
> Relying purely on native controls leads nowhere.

I haven't used Windows in a while, but even years ago Office and MSVC were heavy-hitters that notably diverged from Windows' own widgets (and even interface design guidelines). These were (and are) immense and immensely successful applications that for which designing specific widgets was a small incremental cost (and I speculate a way to say "we own the OS so we may as well design widgets that nobody else got"). Most other Windows program were (and may as well still be, I haven't followed) totally fine with the stock widgets.


Andrei

On Friday, 29 November 2013 at 23:46:02 UTC, Xavier Bigand wrote:
> Le 29/11/2013 04:48, Rikki Cattermole a écrit :
>> On Thursday, 28 November 2013 at 12:13:42 UTC, Chris wrote:
>>> On Thursday, 28 November 2013 at 12:05:09 UTC, Jacob Carlborg wrote:
>>>> On 2013-11-28 11:12, Chris wrote:
>>>>
>>>>> +1 GtkD & Glade (UI builder) are very good (http://gtkd.org/).
>>>>> Hopefully
>>>>> one day we will have our own pure D GUI toolkit.
>>>>
>>>> DWT is a pure D GUI toolkit.
>>>
>>> What I meant was no bindings to native widgets or other toolkits. DWT
>>> (like SWT) uses the native widgets and needs an interface. I was
>>> thinking of a toolkit where everything is provided by D and done in D
>>> without any reference to native frameworks (Cocoa etc.).
>>
>> DOOGLE[1] currently only depends on libfreetype2, (with Windows as only
>> target) Windows API and OpenGL. I would remove libfreetype2 but.. its
>> basically standard for font rasterization cross platform wise.
>> I have designed it to have its interface abstracted away from the
>> implementation fully.
>>
>> Its current state is well listed on my blog[2] it may not look much now
>> and not ready for production use, but definitely should be said.
>>
>> [1] https://github.com/rikkimax/doogle
>> [2]
>> http://alphaglosined.blogspot.com/2013/11/web-services-and-opengl-oh-my.html
>>
>
> You may want take a look to DQuick :
> https://github.com/D-Quick/DQuick
>
> It's run on top of openGL too, the main difference is that you describe the UI in dedicated script files. Scripts provide allow to provide fully dynamical UIs.
>
> An UI file (original lua script format for the moment) :
>
> GraphicItem
> {	
>     id = "main",
>
> 	Image {
> 		id = "kerningImageButton",
> 		
> 		source = "images/border-image.png",
> 		width = 300,
> 		height = 50,
>
> 		MouseArea {
> 			id = "kerningButton",
> 			width = function()
> 				return kerningImageButton.width
> 			end,
> 			height = function()
> 				return kerningImageButton.height
> 			end,
> 		},
> 	},
>
> 	ScrollView {
> 		id = "scrollView",
> 	
> 		y = function()
> 			return kerningImageButton.height
> 		end,
> 		width = function()
> 			return main.width
> 		end,
> 		height = function()
> 			return main.height - scrollView.y
> 		end,
> 		
> 		clip = true,
>
> 		Text {
> 			id = "text",
> 		
> 			wrapMode = Text.WrapMode.WordWrap,
> 		
> 			width = function()
> 				return scrollView.width
> 			end,
> 			height = function()
> 				return scrollView.height
> 			end,
>
> 			text = textFr,
> 			family = function()
> 				if (kerningButton.pressed) then
> 					return "AngsanaUPC"
> 				end
> 				return "Arial"
> 			end,
> 			fontSize = 24,
> 			fontStyle = function()
> 				if (kerningButton.pressed) then
> 					return Text.FontStyle.Italic
> 				end
> 				return Text.FontStyle.Regular
> 			end,
> 		},
> 	},
> }

I know, I've kept an eye on all other GUI toolkits since I started work. I'm currently sticking to just plain old class objects to build it primarily because of a) efficiency and b) extra dependencies.
Eventually there will be a meta based system to configure it. But that'll come when I'll start on an IDE.

On Friday, 29 November 2013 at 02:00:50 UTC, Chris Cain wrote:
> On Friday, 29 November 2013 at 01:44:34 UTC, Dicebot wrote:
>> Still lacking proper beard ;)
>
> A programmer without a beard! Blasphemy! Witch!
>
> ----
>
> But anyway, going along with what you guys are saying, if you've ever seen reviews on Android apps, a lot of apps get lots of bad reviews for not adhering to the Android design standards. Using cross-platform toolkits are usually a death sentence for your rating. So, there's a lot to be said about making sure your app looks consistent in the OS it's running in.
>
> Some apps do "get away" with something that is somewhat custom. Take, for instance, Steam on Windows. It doesn't look like a "proper" Windows application, but it works very well for it regardless. That said, Steam on Mac is terrible because it feels too much like a windows app there (mainly in regards to scrolling behavior).
>
> That all said, if I were writing a GUI app in D right now, I would probably write my own toolkit and make something super simple (but "good" looking) to test out some new ideas. I think we really need an easy, straight-forward, and powerful UI toolkit that takes advantage of D's unique features (such as compile-time specialization, maybe using DSLs that compiled & used at compile-time instead of runtime) while reflecting well in comparison to the newest paradigms of application design (think how Android & iOS apps are made and maybe even a bit of web design). I can't quite precisely quantify what we need, but I think a fresh approach to the UI programming interface could set D apart in this area.
>
> Simply using a translation of an old UI toolkit is "easy" but will not make UI applications pleasing to develop.

+1
This is why with DOOGLE I have made shaders for e.g. controls completely overridable at app, system and user levels. Shaders control all looks of the app. Although this does mean a bit of calculation and binding of information regarding screen and component size.

What does this mean? Maintainers for a distro or OS can easily make it look like what is expected for that OS.
With regards to feel that would have to be hard coded at this point.

Is it just me or is a button a layout? As far as I'm aware most gui toolkits think of it as not. It gives much more control over it.
Just my 2 cents over how I feel with them.

Eventually I would like to have DOOGLE emit html/css/js and work like GWT (Google Web Toolkit [1]). This really would be hugely beneficial for making a desktop application into a web app. And set it apart.

[1] http://www.gwtproject.org/

On 11/28/2013 02:54 PM, Xavier Bigand wrote:
> Dquick goes in this direction.

It appears DQcuik uses Lua scripts for UI design.

1. Do we have to supply these script files along with the executable or do they get compiled into the executable?

2. How is the performance?