www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What Features Should A GUI toolkit have?

reply "Taylor Hillegeist" <taylorh140 gmail.com> writes:
So I have played with a few GUI libraries with bindings available 
through D. Personally I find that it seems like there is alot of 
effort being put forth on GUI projects.

It is my experience that most project's fail or die, not because 
of lack of effort but lack of specification, many people start 
projects thinking, can i make it do this? how about this? and a 
project is born! but soon interest is lost and the project dies. 
But specification can lead to projects that become useful 
earlier, more stable, and live longer happier lives.

At this point i think the following features are the most useful.

-Ease of setup-
dub integration is awesome, without it things are more difficult. 
This has very little to do with the actual toolkit.

-Minimal dependencies-
Personally If i can statically link a toolkit to my GUI and it 
has zero dependencies outside of the OS typically install. I am 
very happy. really the less that can be messed with the better.

best in my opinion: DWT MiniGUI DGUI at least for windows.

-Rock Solid Stable-
So when I do the hello world application I resize the window push 
the buttons and do pretty normal things. But on some libraries I 
get weird stuff going on sometimes the window even becomes 
invisible..... scary.

best in my opinion: GTKD TKD

-GUI EDITOR/BUILDER-
Good- You can edit a static layout
Better- you can edit a layout and re-size the window layout 
responds
Best- you can edit the actual window in real time without 
recompile.

Good- You have a pallet of basic widgets that you can place.
Better- You have a pallet of basic widgets + custom widgets that 
you can edit.
Best- You have the above + a database were people can share 
widgets :)

-Widgets-
Personally I think that all layout items like HBar should be 
children of widget that way i can make more modular component, 
but that's just my opinion.

-Data Binding-
Most of the time I use that data a widget represents and much 
less often the events they produce.

-Ease of Use-
Your tookits should work for you... not the other way round.

-layout-
I have seen some schemes like Winforms Dock,javaFX HBar, HTML5's 
float/static/absolute/realitive... Idk what seems the most 
freindly... HTML5/css seems the most complex. I have a dream 
H/VBar + align/distribution/wrap options.

I know some of these are RAD things. I don't have an opinion on 
thread safe guis. personally I would like to see a GUI tookit 
that the community said... use X it is just the way to go for 
most things.
Mar 05 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 6/03/2015 7:02 p.m., Taylor Hillegeist wrote:

 So I have played with a few GUI libraries with bindings available
 through D. Personally I find that it seems like there is alot of effort
 being put forth on GUI projects.

 It is my experience that most project's fail or die, not because of lack
 of effort but lack of specification, many people start projects
 thinking, can i make it do this? how about this? and a project is born!
 but soon interest is lost and the project dies. But specification can
 lead to projects that become useful earlier, more stable, and live
 longer happier lives.

 At this point i think the following features are the most useful.

 -Ease of setup-
 dub integration is awesome, without it things are more difficult. This
 has very little to do with the actual toolkit.

 -Minimal dependencies-
 Personally If i can statically link a toolkit to my GUI and it has zero
 dependencies outside of the OS typically install. I am very happy.
 really the less that can be messed with the better.

 best in my opinion: DWT MiniGUI DGUI at least for windows.


Devisualization projects were all designed with this in mind.


 -Rock Solid Stable-
 So when I do the hello world application I resize the window push the
 buttons and do pretty normal things. But on some libraries I get weird
 stuff going on sometimes the window even becomes invisible..... scary.

 best in my opinion: GTKD TKD

 -GUI EDITOR/BUILDER-
 Good- You can edit a static layout
 Better- you can edit a layout and re-size the window layout responds
 Best- you can edit the actual window in real time without recompile.


+1
Reasonable, as long as the events that is D code doesn't change. And 
even then it could be doable via shared libraries.


 Good- You have a pallet of basic widgets that you can place.
 Better- You have a pallet of basic widgets + custom widgets that you can
 edit.
 Best- You have the above + a database were people can share widgets :)


Yeah no. Would realistically required D code unless you want something 
like lua.


 -Widgets-
 Personally I think that all layout items like HBar should be children of
 widget that way i can make more modular component, but that's just my
 opinion.


+1


 -Data Binding-
 Most of the time I use that data a widget represents and much less often
 the events they produce.


+1


 -Ease of Use-
 Your tookits should work for you... not the other way round.


+1


 -layout-
 I have seen some schemes like Winforms Dock,javaFX HBar, HTML5's
 float/static/absolute/realitive... Idk what seems the most freindly...
 HTML5/css seems the most complex. I have a dream H/VBar +
 align/distribution/wrap options.


My opinion which isn't exactly normal is that layout's are just an 
algorithm on how to size/location of the child elements. Keep them 
separate and configurable. These issues can all be abstracted away.


 I know some of these are RAD things. I don't have an opinion on thread
 safe guis. personally I would like to see a GUI tookit that the
 community said... use X it is just the way to go for most things.


Threading is a big no no with GUI's. Don't even consider it. Well for 
rendering anyway.
Separating out the controls raw data from the drawing is important for 
this. That way other threads can control where widgets ext. are or there 
data without directly drawing.


I'll summarize my views on all of this.
We keep making the same damn mistakes time after time. Especially with 
GUI's.
Stop trying to make GUI toolkits! Seriously just stop.
WE DO NOT HAVE THE INFRASTRUCTURE FOR IT. Yes I know that is yelling but 
it is true. We're still a long way off having proper image manipulation. 
Or even basic OpenGL wrapping functions. DirectX don't even joke.

So what can we do to get to this point? Continue on improving dub. You 
know what doesn't matter? file format for dub. What does matter is 
getting proper live reloading capabilities. Livereload is good and all 
but most of you won't be happy with it.
We also need a strong image toolkit. We still don't have a common color 
definition.

After an image toolkit/color definition has been sorted the next target 
is get extern(Obj-C) working. We need this for OSX.

Now a project like Devisualization.Window can be extended to support 
e.g. displays. Also getting the OSX window code in D instead of Objective-C.

So to recap, image toolkit is number 1 goal right now. Second is to get 
Devisualization.Window similar project extended.

Once this is done, then it is on to e.g. a scenegraph. A good 2d 
scenegraph can be used to represent widget hierarchies. A good 3d one 
can be used in games. Combine them both and you can have 2d overlayed on 
3d for games. Can you say game UI which is not dedicated to games?

We have the ability to create instances of classes at runtime using only 
there names. Dynamic eventing isn't an issue here. Of course if we could 
pair dmd-fe up with a JIT we could do amazing things... Also embedded 
interface files would be rather useful for this.

Now and only now can we consider a GUI toolkit. The scary thing is I 
don't know why I even say all of this. Because by the time we get our 
act together it will be atleast 4-5 years.

TLDR: We think far too big and never actually work with a clear 
strategic path towards a goal in mind.
Mar 05 2015
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 06 Mar 2015 19:30:40 +1300, Rikki Cattermole wrote:


 Stop trying to make GUI toolkits! Seriously just stop.


+4624!

it should be turned inside out: to be productive we need component=20
framework a-la BlackBox Component Builder. sadly, most people were never=20
worked with *real* component framework, so they keep thinking that "ide +=20
gui builder + compiler is like component framework". no, no, and no. not=20
even close. that loses the main property of component frameworks: you=20
aren't writing program using CF, you are simply extending CF until it can=20
do what you want.

D is one small step away from the goal: all it need is dynamic module=20
loader. i.e. a module that can load other compiled modules with all their=20
dependences, and can unload modules (again removing all unused=20
dependencies). with dynamic loader the way to component framework is open.

but alas: dynamic loader means that D should stop producing that "object=20
files" for linkers. it has to produce something like delphi .dcus (a=20
compiled code, plus all the interface -- it can be titled "rich object=20
file").

writing "gui toolkits" is like randomly throwing bricks, windows, doors=20
and floor panes onto buildint site and hoping that they somehow will=20
arrange themselves into the real house.=
Mar 05 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 6 March 2015 at 07:49:51 UTC, ketmar wrote:

 it should be turned inside out: to be productive we need 
 component
 framework a-la BlackBox Component Builder. sadly, most people 
 were never
 worked with *real* component framework, so they keep thinking 
 that "ide +
 gui builder + compiler is like component framework". no, no, 
 and no. not
 even close. that loses the main property of component 
 frameworks: you
 aren't writing program using CF, you are simply extending CF 
 until it can
 do what you want.


Components are coming to HTML5:

http://jonrimmer.github.io/are-we-componentized-yet/

Google is experimenting with implementing their "Material GUI" in 
it:

https://www.polymer-project.org/components/paper-elements/demo.html#paper-checkbox

Sure, you can do your own in D, but you probably cannot keep up 
if this takes off... It would make a lot more sense to focus on 
efficient synchronization between native D arrays and javascript 
and utilize what already is there. HTML5 provides ArrayView 
objects that basically are slices of raw memory.

It could work out nicely.
Mar 06 2015
next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 2015-03-06 at 10:01 +0000, via Digitalmars-d wrote:

 


[…]

 Components are coming to HTML5:
 
 […]
 
 It could work out nicely.
 


On the other hand for a non-browser UI, it doesn't really make sense!

Personally I cannot see a new D implemented graphics system and GUI 
system on top of it being anything more than hobby project there is 
not enough resource or traction with D to compete against Qt. Hate it 
or really hate it, Qt is currently the leader in Linux, UNIX (inc 
OSX), Windows agnostic graphics and GUI.

It would be really good if there were resource, especially given the 
demise of OpenGL and OpenCL in the face of Vulkan, since this would be 
an opportunity for D to excel. But without serious dosh, I can't see 
it happening: consider the amount of money spent on JavaFX.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Mar 06 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 6 March 2015 at 10:42:37 UTC, Russel Winder wrote:

 On Fri, 2015-03-06 at 10:01 +0000, via Digitalmars-d wrote:

 


 […]

 Components are coming to HTML5:
 
 […]
 
 It could work out nicely.
 


 On the other hand for a non-browser UI, it doesn't really make 
 sense!


Not sure what you mean by a "non-browser UI". You need a model, a 
layout engine, a composition engine and know-how. Competing with 
browser engines is a lot of work.

It is going to be very hard to compete with reusable UI 
components implemented in html+javascript, when they have worked 
out the quirks, due to:

1. ease of development
2. ease of modification
3. volume of UI components
4. styling know-how
5. integration
6. installed base

What you need is a reactive layer that access native data. And 
webtech provides the basic building blocks for it, thanks to the 
requirements of asm.js/pnacl.
Mar 06 2015
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 6 March 2015 at 11:30:58 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 6 March 2015 at 10:42:37 UTC, Russel Winder wrote:

 On Fri, 2015-03-06 at 10:01 +0000, via Digitalmars-d wrote:

 


 […]

 Components are coming to HTML5:
 
 […]
 
 It could work out nicely.
 


 On the other hand for a non-browser UI, it doesn't really make 
 sense!


 Not sure what you mean by a "non-browser UI". You need a model, 
 a layout engine, a composition engine and know-how. Competing 
 with browser engines is a lot of work.

 It is going to be very hard to compete with reusable UI 
 components implemented in html+javascript, when they have 
 worked out the quirks, due to:

 1. ease of development
 2. ease of modification
 3. volume of UI components
 4. styling know-how
 5. integration
 6. installed base

 What you need is a reactive layer that access native data. And 
 webtech provides the basic building blocks for it, thanks to 
 the requirements of asm.js/pnacl.


I am hoping mobile applications and application stores bring an 
end to the non-sense of bending documents into applications.

Or that we get to have the second comeback of XHTML, and finally 
have something like XAML on the browser, which was XHTML original 
idea.

--
Paulo
Mar 06 2015
next sibling parent reply "Kagamin" <spam here.lot> writes:
On Friday, 6 March 2015 at 12:30:36 UTC, Paulo  Pinto wrote:

 Or that we get to have the second comeback of XHTML, and 
 finally have something like XAML on the browser, which was 
 XHTML original idea.


There's already XUL, I use it, a small program eats ~100MB of RAM.
Mar 06 2015
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 6 March 2015 at 12:49:11 UTC, Kagamin wrote:

 On Friday, 6 March 2015 at 12:30:36 UTC, Paulo  Pinto wrote:

 Or that we get to have the second comeback of XHTML, and 
 finally have something like XAML on the browser, which was 
 XHTML original idea.


 There's already XUL, I use it, a small program eats ~100MB of 
 RAM.


I never cared about XUL, as it always meant bundling together 
with a browser.

..
Paulo
Mar 06 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 6 March 2015 at 12:30:36 UTC, Paulo  Pinto wrote:

 I am hoping mobile applications and application stores bring an 
 end to the non-sense of bending documents into applications.


Yes, the model-view separation could be better for large datasets 
( > 5000 items), but you can do it just fine now that 
hardware/engines are fast enough (by absolute positioning 
relative to the list view). Once most platforms are fast enough 
you can get good updates/framerates even if HTML5 is somewhat 
inefficient for some display strategies. The good thing is that 
we are really close to that threshold now, and that better 
refresh rates than 60hz makes no sense.


 Or that we get to have the second comeback of XHTML, and 
 finally have something like XAML on the browser, which was 
 XHTML original idea.


I think HTML5 brings very nice semantics to document markup, so 
you can use XHTML5 if you want. And Shadow-DOM/Polymer with 
two-way binding (variables and UI-elements are automatically 
updated when one change) is more like an extensible display-graph 
than a document, but you can also turn XML-ish/JSON-ish data into 
a pre-filled form to have a custom editor in a document like 
fashion.

Quite a few quirks and some boilerplate at the moment, but one 
can play with it already. I am testing Dart+Polymer+Paper 
Elements for an Chrome based admin interface right now. I think 
it is moving in the right direction, although at bit 
"complicated" without tooling.

When the quirks are ironed out, the tooling certainly will 
come... Overall, I think it will be easier to use than Cocoa et 
al, with roughly the same capability, but a lot more ready made 
components. If Google keeps investing in the tech... The only 
problem would be that it might be too complicated for avarage web 
devs without tooling, and that the tooling-devs wait for avarage 
web devs to pick it up. Catch 22.
Mar 06 2015
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 6 March 2015 at 13:02:05 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 6 March 2015 at 12:30:36 UTC, Paulo  Pinto wrote:

 I am hoping mobile applications and application stores bring 
 an end to the non-sense of bending documents into applications.


 Yes, the model-view separation could be better for large 
 datasets ( > 5000 items), but you can do it just fine now that 
 hardware/engines are fast enough (by absolute positioning 
 relative to the list view). Once most platforms are fast enough 
 you can get good updates/framerates even if HTML5 is somewhat 
 inefficient for some display strategies. The good thing is that 
 we are really close to that threshold now, and that better 
 refresh rates than 60hz makes no sense.


 Or that we get to have the second comeback of XHTML, and 
 finally have something like XAML on the browser, which was 
 XHTML original idea.


 I think HTML5 brings very nice semantics to document markup, so 
 you can use XHTML5 if you want. And Shadow-DOM/Polymer with 
 two-way binding (variables and UI-elements are automatically 
 updated when one change) is more like an extensible 
 display-graph than a document, but you can also turn 
 XML-ish/JSON-ish data into a pre-filled form to have a custom 
 editor in a document like fashion.

 Quite a few quirks and some boilerplate at the moment, but one 
 can play with it already. I am testing Dart+Polymer+Paper 
 Elements for an Chrome based admin interface right now. I think 
 it is moving in the right direction, although at bit 
 "complicated" without tooling.

 When the quirks are ironed out, the tooling certainly will 
 come... Overall, I think it will be easier to use than Cocoa et 
 al, with roughly the same capability, but a lot more ready made 
 components. If Google keeps investing in the tech... The only 
 problem would be that it might be too complicated for avarage 
 web devs without tooling, and that the tooling-devs wait for 
 avarage web devs to pick it up. Catch 22.



I am doing web development alongside native since the .com days, 
those quirks will never go away as long as the trend of building 
hack on top of hack continues.

--
Paulo
Mar 06 2015
prev sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 2015-03-06 at 11:30 +0000, via Digitalmars-d wrote:
[=E2=80=A6]

=20
 Not sure what you mean by a "non-browser UI". You need a model, a=20
 layout engine, a composition engine and know-how. Competing with=20
 browser engines is a lot of work.


I meant a user interface not using a browser as the infrastructure.
Cocoa, Qt, GTK, JavaFX, etc. are all there already, and have everything
browsers are still trying to get. I agree the pressure of fashion and
orthodoxy is moving to HTML and JavaScript as the one true UI framework,
but it's only real positive is that it is (supposed to be) pre-installed
and the same on every machine. Sadly though, from what I can see, vast
amounts of code and time is spent dealing with the differences between
browsers.


 It is going to be very hard to compete with reusable UI=20
 components implemented in html+javascript, when they have worked=20
 out the quirks, due to:
=20
 1. ease of development
 2. ease of modification
 3. volume of UI components
 4. styling know-how
 5. integration
 6. installed base


HTML and Javascript may have an edge on ease of deployment, but
regarding the other dimensions, I fear you must have imbibed of the
Kool-Aid. I agree that most people creating UIs do so with browsers,
HTML and JS, but that doesn't mean they are doing it right or not
blindly recreating from scratch a whole mass of things that were already
known. We would be a lot further forward today on UI and UX if people in
the Web arena had researched more and taken NIH attitudes less. Clearly
new technology and new application require new things, but simply
ignoring already known stuff is just wrong.


 What you need is a reactive layer that access native data. And=20
 webtech provides the basic building blocks for it, thanks to the=20
 requirements of asm.js/pnacl.


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Mar 06 2015
next sibling parent "Chris" <wendlec tcd.ie> writes:
On Saturday, 7 March 2015 at 07:33:03 UTC, Russel Winder wrote:

 On Fri, 2015-03-06 at 11:30 +0000, via Digitalmars-d wrote:
 […]

 
 Not sure what you mean by a "non-browser UI". You need a 
 model, a layout engine, a composition engine and know-how. 
 Competing with browser engines is a lot of work.


 I meant a user interface not using a browser as the 
 infrastructure.
 Cocoa, Qt, GTK, JavaFX, etc. are all there already, and have 
 everything
 browsers are still trying to get. I agree the pressure of 
 fashion and
 orthodoxy is moving to HTML and JavaScript as the one true UI 
 framework,
 but it's only real positive is that it is (supposed to be) 
 pre-installed
 and the same on every machine. Sadly though, from what I can 
 see, vast
 amounts of code and time is spent dealing with the differences 
 between
 browsers.


 It is going to be very hard to compete with reusable UI 
 components implemented in html+javascript, when they have 
 worked out the quirks, due to:
 
 1. ease of development
 2. ease of modification
 3. volume of UI components
 4. styling know-how
 5. integration
 6. installed base


 HTML and Javascript may have an edge on ease of deployment, but
 regarding the other dimensions, I fear you must have imbibed of 
 the
 Kool-Aid. I agree that most people creating UIs do so with 
 browsers,
 HTML and JS, but that doesn't mean they are doing it right or 
 not
 blindly recreating from scratch a whole mass of things that 
 were already
 known. We would be a lot further forward today on UI and UX if 
 people in
 the Web arena had researched more and taken NIH attitudes less. 
 Clearly
 new technology and new application require new things, but 
 simply
 ignoring already known stuff is just wrong.


I'm the first who would welcome a better approach to UIs. 
However, in the real world you cannot wait until the industry 
finally "gets it". You cannot tell users "Yeah, no, we won't make 
an app, because we are not happy with existing frameworks, you 
know".

I hate JS for various reasons, one reason is that HTML5/JS makes 
you reinvent the wheel again and again. However, while 
reinventing the wheel, it helps you to understand that existing 
frameworks are not the be all end all either.


 What you need is a reactive layer that access native data. And 
 webtech provides the basic building blocks for it, thanks to 
 the requirements of asm.js/pnacl.
Mar 07 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 7 March 2015 at 07:33:03 UTC, Russel Winder wrote:

 I meant a user interface not using a browser as the 
 infrastructure.
 Cocoa, Qt, GTK, JavaFX, etc. are all there already, and have 
 everything
 browsers are still trying to get.


All I can say that you can cut down on development time, get 
better portability, greater reuse and greater flexibility by 
using HTML5. The only downside has been performance and toolkits, 
but that is changing over time. Shadow DOM is an essential 
component to that, by encapsulating GUI elements, and reactive 
frameworks allows you to tie them together with effortless 
two-way binding.


 but it's only real positive is that it is (supposed to be) 
 pre-installed
 and the same on every machine. Sadly though, from what I can 
 see, vast
 amounts of code and time is spent dealing with the differences 
 between browsers.


That's in the past. The time spent referencing caniuse.com (about 
once every 15 minutes for me) allows you to use new features 
without having to reimplement for another browser. I spend less 
than 1% on cross browser issues now that I am on IE10+. Before 
that, 10-20%.

But that is not relevant here, since we are talking about 
building Chromium into the app, as in statically.


 HTML and Javascript may have an edge on ease of deployment, but
 regarding the other dimensions, I fear you must have imbibed of 
 the Kool-Aid.


No Kool-Aid, just a fair knowledge about usability, GUIs and the 
cost of doing native development as well as what browser engines 
now provide. Going native costs you twice as much in GUI work 
than a design that fits HTML5.

HTML is by far the most stable and portable platform over time... 
Because it is backed by an adopted standard. Without a standard, 
it would be worth nothing. Low risk implies adoption.

Flexibility is also important for creating good UIs. Complex 
applications never reuse much from existing GUIs, they create 
their own for all the critical tasks. That applies to just about 
all applications where screen estate and workflow matters: 
audio-visual applications, CAD etc.


 Clearly
 new technology and new application require new things, but 
 simply
 ignoring already known stuff is just wrong.


I am not ignoring anything. I am pragmatic, and I also know the 
UI theory and what the portable UI frameworks has offered since 
the 1980s.

HTML5 is an adopted agreed upon standard with backwards 
compatible enhancements that works cross platform. Everything 
else is not. Therefore HTML5 will grow more over time. Just like 
C++ will grow more than D...
Mar 09 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
Some applications that use Chromium Embedded:

http://en.wikipedia.org/wiki/Chromium_Embedded_Framework#Applications_using_CEF
Mar 09 2015
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 9 March 2015 at 12:29:54 UTC, Ola Fosheim Grøstad 
wrote:

 Some applications that use Chromium Embedded:

 http://en.wikipedia.org/wiki/Chromium_Embedded_Framework#Applications_using_CEF


I don't use any of them and Github for Windows was done in WPF 
last time I checked, how come it is listed there?

--
Paulo
Mar 09 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Monday, 9 March 2015 at 08:13:47 UTC, Ola Fosheim Grøstad 
wrote:

 Flexibility is also important for creating good UIs. Complex 
 applications never reuse much from existing GUIs, they create 
 their own for all the critical tasks.


They still mostly rely on existing functionality, and I wouldn't 
say it will be easier in HTML5. You will deal with all the same 
primitives, which of course will break with next update.


 HTML5 is an adopted agreed upon standard with backwards 
 compatible enhancements that works cross platform.


Yet, web 2.0 technologies have only rudimentary notion of 
backward compatibility, all it breaks routinely.
Mar 10 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 10 March 2015 at 08:02:00 UTC, Kagamin wrote:

 Yet, web 2.0 technologies have only rudimentary notion of 
 backward compatibility, all it breaks routinely.


No... there are sometimes regressions, but only for a few 
releases. It does not matter when you bundle the engine with the 
application.
Mar 10 2015
parent reply Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 10/03/2015 11:16, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" a écrit :

 On Tuesday, 10 March 2015 at 08:02:00 UTC, Kagamin wrote:

 Yet, web 2.0 technologies have only rudimentary notion of backward
 compatibility, all it breaks routinely.


 No... there are sometimes regressions, but only for a few releases. It
 does not matter when you bundle the engine with the application.


Personally I am totally against HTML/CSS. It's a pain to get a good 
presentation, and the way styles are applied is just to hard to follow 
don't forget the !important keyword in CSS.

Even with bootstrap I have difficulties to get results I want.


A year ago I start learn QML (http://doc.qt.io/qt-5/qtqml-index.html) 
for my job and it was difficult to understand the property binding 
paradigm, but after that you can do just what you want. And code is 
really simple and not as verbose as HTML for doing the same things.
Mar 11 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 11 March 2015 at 08:32:07 UTC, Xavier Bigand wrote:

 after that you can do just what you want. And code is really 
 simple and not as verbose as HTML for doing the same things.


With web components you can create your own markup and 
encapsulate the implementation.
Mar 11 2015
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 11 March 2015 at 10:50:44 UTC, Ola Fosheim Grøstad 
wrote:

 On Wednesday, 11 March 2015 at 08:32:07 UTC, Xavier Bigand 
 wrote:

 after that you can do just what you want. And code is really 
 simple and not as verbose as HTML for doing the same things.


 With web components you can create your own markup and 
 encapsulate the implementation.


There is no such thing as encapsulation.

The browser will just see a gigantic HTML page open to all sorts 
of side effects.

Unless they have gained a closed environment definition recently,

--
Paulo
Mar 11 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 11 March 2015 at 11:34:45 UTC, Paulo  Pinto wrote:

 Unless they have gained a closed environment definition 
 recently,


They have:

http://www.w3.org/TR/shadow-dom/
Mar 11 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
Btw: this is a demo app using the tech:

https://polymer-topeka.appspot.com/

Not sure if it works well outside Chrome. I only use 
Chrome+Dart+Polymer with this tech.
Mar 11 2015
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 11 March 2015 at 12:14:00 UTC, Ola Fosheim Grøstad 
wrote:

 Btw: this is a demo app using the tech:

 https://polymer-topeka.appspot.com/

 Not sure if it works well outside Chrome. I only use 
 Chrome+Dart+Polymer with this tech.


that was pretty well done in some ways. Pity it doesn't 
understand what the back button means.
Mar 11 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 06 Mar 2015 10:01:34 +0000, Ola Fosheim Gr=C3=B8stad wrote:


 On Friday, 6 March 2015 at 07:49:51 UTC, ketmar wrote:

 it should be turned inside out: to be productive we need component
 framework a-la BlackBox Component Builder. sadly, most people were
 never worked with *real* component framework, so they keep thinking
 that "ide +
 gui builder + compiler is like component framework". no, no, and no.
 not even close. that loses the main property of component frameworks:
 you aren't writing program using CF, you are simply extending CF until
 it can do what you want.


=20
 Components are coming to HTML5:
=20
 http://jonrimmer.github.io/are-we-componentized-yet/


wow, what a shitload of crap! exactly what i mean when i wrote "most=20
people doing it wrong".


 Sure, you can do your own in D, but you probably cannot keep up if this
 takes off... It would make a lot more sense to focus on efficient
 synchronization between native D arrays and javascript and utilize what
 already is there. HTML5 provides ArrayView objects that basically are
 slices of raw memory.
=20
 It could work out nicely.


but that's crap. it's in no way even near the Component Framework. it's=20
the same old GUI crap, but this time with fancy new name.=
Mar 06 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 6 March 2015 at 10:55:34 UTC, ketmar wrote:

 wow, what a shitload of crap! exactly what i mean when i wrote 
 "most
 people doing it wrong".


Describe what is right?

To most developers, doing it right means saving developer time 
and if possible push "design declarative programming" onto 
designers.

Which is basically what shadow-dom allows you to do. There are 
some quirks with styling still, but there is overall progress.
Mar 06 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 06 Mar 2015 11:34:14 +0000, Ola Fosheim Gr=C3=B8stad wrote:


 On Friday, 6 March 2015 at 10:55:34 UTC, ketmar wrote:

 wow, what a shitload of crap! exactly what i mean when i wrote "most
 people doing it wrong".


=20
 Describe what is right?


i did alot of times. Smalltalk, Oberon, BCB. old Symbolics Lisp machines=20
to some extent. ;-) BlueBottle OS.


 To most developers, doing it right means saving developer time and if
 possible push "design declarative programming" onto designers.


and most of the tools that are trying to help with that fails miserably.=20
i still remember how fast, easy and fun everything was in BlackBox=20
Component Builder. words are nothing, you have to work with it (not play,=20
but work) to feel it's unique power.


 Which is basically what shadow-dom allows you to do. There are some
 quirks with styling still, but there is overall progress.


it doesn't matter how much they advancing wheelchairs, wheelchairs will=20
never become Lamborghinis.=
Mar 06 2015
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 6 March 2015 at 11:34:15 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 6 March 2015 at 10:55:34 UTC, ketmar wrote:

 wow, what a shitload of crap! exactly what i mean when i wrote 
 "most
 people doing it wrong".


 Describe what is right?

 To most developers, doing it right means saving developer time 
 and if possible push "design declarative programming" onto 
 designers.

 Which is basically what shadow-dom allows you to do. There are 
 some quirks with styling still, but there is overall progress.


I've been working with various GUIs (Swing, Cocoa, JavaFX, SWT, 
GTKD, TKinter etc.) and I am working with HTML/CSS/JS (have to!). 
Frankly speaking, I hate JS and wish there was a way to get rid 
of it (please, don't try to convince me that JS is somehow good - 
it isn't - and that there is jquery and blah dee blah. Please 
don't.).
What I can tell from my own personal experience is that in 
_theory_ something like HTML5 would be very nice, due to the fact 
that it is supported, maintained and improved on all platforms 
(manpower & brainpower), so that you come pretty close to the 
"write once, run everywhere" ideal. Given the plethora of 
platforms nowadays, especially in the mobile sector, it is 
impossible to develop a GUI application for each platform. What 
you want is something based on browser technology that is 
understood everywhere, without having to worry about any platform 
specific quirks or pitfalls. Something that is only a thin layer 
that is agnostic to the logic, the data processing that goes on 
in the app. Unfortunately, the only way to do this today is 
HTML5+JS (it's the JS bit that annoys me).

In the old days (before smartphones), people would develop 
applications for Windows, OS X, and maybe Linux (if it was in the 
budget). But today this is simply impossible. So yes, from a 
developer's point of view, you want something like HTML5/CSS/JS, 
only better, regardless of what's the GUI ideal. Using 
technologies (other than HTML5) that interface to native widgets, 
is not maintainable, you're always one step behind.

To cut a long story short, ideals and pragmatism are at 
loggerheads here, but at the end of the day, you have to get your 
apps out there for as many people and as many platforms as 
possible, with the least effort possible. So HTML5 and related 
technologies win in this respect. And users don't care what's 
under the hood. They simply ask "Can I download an app?". If they 
can't, they are very annoyed. D should find a way to interact 
with the "app world".
Mar 06 2015
next sibling parent reply "Kagamin" <spam here.lot> writes:
On Friday, 6 March 2015 at 12:29:46 UTC, Chris wrote:

 To cut a long story short, ideals and pragmatism are at 
 loggerheads here, but at the end of the day, you have to get 
 your apps out there for as many people and as many platforms as 
 possible, with the least effort possible. So HTML5 and related 
 technologies win in this respect.


A web UI like that of fossil? Fossil doesn't use JS in its UI.
Mar 06 2015
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 6 March 2015 at 12:46:10 UTC, Kagamin wrote:

 On Friday, 6 March 2015 at 12:29:46 UTC, Chris wrote:

 To cut a long story short, ideals and pragmatism are at 
 loggerheads here, but at the end of the day, you have to get 
 your apps out there for as many people and as many platforms 
 as possible, with the least effort possible. So HTML5 and 
 related technologies win in this respect.


 A web UI like that of fossil? Fossil doesn't use JS in its UI.


But Fossil is not yet usable, is it?
Mar 06 2015
next sibling parent "Kagamin" <spam here.lot> writes:
On Friday, 6 March 2015 at 16:23:34 UTC, Chris wrote:

 A web UI like that of fossil? Fossil doesn't use JS in its UI.


 But Fossil is not yet usable, is it?


Why not? You can try it right now: http://www.fossil-scm.org/
Mar 06 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 06 Mar 2015 16:23:33 +0000, Chris wrote:


 On Friday, 6 March 2015 at 12:46:10 UTC, Kagamin wrote:

 On Friday, 6 March 2015 at 12:29:46 UTC, Chris wrote:

 To cut a long story short, ideals and pragmatism are at loggerheads
 here, but at the end of the day, you have to get your apps out there
 for as many people and as many platforms as possible, with the least
 effort possible. So HTML5 and related technologies win in this
 respect.


 A web UI like that of fossil? Fossil doesn't use JS in its UI.


=20
 But Fossil is not yet usable, is it?


it's completely usable. and it is used to develop fossil itself and=20
sqlite.=
Mar 06 2015
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 6 March 2015 at 16:57:01 UTC, ketmar wrote:

 On Fri, 06 Mar 2015 16:23:33 +0000, Chris wrote:


 On Friday, 6 March 2015 at 12:46:10 UTC, Kagamin wrote:

 On Friday, 6 March 2015 at 12:29:46 UTC, Chris wrote:

 To cut a long story short, ideals and pragmatism are at 
 loggerheads
 here, but at the end of the day, you have to get your apps 
 out there
 for as many people and as many platforms as possible, with 
 the least
 effort possible. So HTML5 and related technologies win in 
 this
 respect.


 A web UI like that of fossil? Fossil doesn't use JS in its UI.


 
 But Fossil is not yet usable, is it?


 it's completely usable. and it is used to develop fossil itself 
 and
 sqlite.


I saw a comment saying "project not finished, no downloads" or 
something like this. But now I've found the right link.

I've just downloaded and compiled it. I will play around with it 
later, when I have time. Any tips?
Mar 06 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 06 Mar 2015 16:59:18 +0000, Chris wrote:


 A web UI like that of fossil? Fossil doesn't use JS in its UI.


=20
 But Fossil is not yet usable, is it?


 it's completely usable. and it is used to develop fossil itself and
 sqlite.


=20
 I saw a comment saying "project not finished, no downloads" or something
 like this. But now I've found the right link.
=20
 I've just downloaded and compiled it. I will play around with it later,
 when I have time. Any tips?


i'm not a fossil user myself, i've just played with it for some (little)=20
time. but for me it feels like any other dvcs, just simplier. and i like=20
it's feature to "pack" repository in single file. yet it may be somewhat=20
unusual to "unpack" repository prior to work with it.=
Mar 06 2015
prev sibling parent "Kagamin" <spam here.lot> writes:
On Friday, 6 March 2015 at 16:59:19 UTC, Chris wrote:

 I've just downloaded and compiled it. I will play around with 
 it later, when I have time. Any tips?


About web UI: 
http://www.fossil-scm.org/index.html/doc/trunk/www/webui.wiki
Mar 06 2015
prev sibling next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 06 Mar 2015 12:29:45 +0000, Chris wrote:


 To cut a long story short, ideals and pragmatism are at loggerheads
 here, but at the end of the day, you have to get your apps out there for
 as many people and as many platforms as possible, with the least effort
 possible. So HTML5 and related technologies win in this respect. And
 users don't care what's under the hood. They simply ask "Can I download
 an app?". If they can't, they are very annoyed. D should find a way to
 interact with the "app world".


that's exactly what Component Framework can provide: solid foundation to=20
build upon. clear separation of data and UI and software as components=20
which can interoperate seamlessly. there is no such thing as "application=20
package" in CF, there is only "CF extension package". add "everything is=20
a document" here, and you will have a killer.

the worst thing of current software is that it's bundled in form of=20
"applications". and then people try to glue that "applications" together,=20
and... and the whole thing is a mess.

people with virtual machines was almost there... almost. it seems that=20
they were too scared with the idea, and choose to go "traditional" way.=20
sure, you can't sell the thing that can't build "standalone=20
applications" (technically, CF can, but they sux). apple tried that with=20
OpenDoc and failed. microsoft tried that with COM and failed.

but that doesn't mean that the idea is wrong, it's just bussines is not=20
ready to bundle "extensions" instead of "applications". especially when=20
your extension can be freely used by any other extension. so we have what=20
we have.=
Mar 06 2015
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 6 March 2015 at 12:29:46 UTC, Chris wrote:

 to!). Frankly speaking, I hate JS and wish there was a way to 
 get rid of it (please, don't try to convince me that JS is 
 somehow good - it isn't - and that there is jquery and blah dee 
 blah. Please don't.).


It isn't good, but once you figured out what to avoid, you can 
use a subset of it pretty well. Like C++ and D ;^)

It feels weird to type "Object.create(null)" to get a 
dictionary-like object, but it will probably be fixed in 
ECMAScript 6?


 worry about any platform specific quirks or pitfalls. Something 
 that is only a thin layer that is agnostic to the logic, the 
 data processing that goes on in the app. Unfortunately, the 
 only way to do this today is HTML5+JS (it's the JS bit that 
 annoys me).


Yeah, but I think if you only do the GUI (the View part of MVC) 
in JS using shadow dom it should be quite ok. And nothing should 
prevent one from generating the JS bindings from D to JS/HTML5 
from D code.


 Using technologies (other than HTML5) that interface to native 
 widgets, is not maintainable, you're always one step behind.


I agree. The alternative is to develop only for a few markets 
(e.g. iOS/Cocoa). People are also quite used to the common UI 
paradigms used on the web by now, so "learnability" is not the 
same as in the 80s/90s where regular users would be terribly 
confused when encountering innovative UI components. Text books 
on usability probably lags a bit behind there...

Qt et al might work in markets where there is little competition 
(low volume narrow markets), but I have trouble seeing a future 
for it without a major player backing it 100% to gain market 
share.

I believe Google depends on HTML5 domination to keep 
Apple/Microsoft from getting "too big".


 technologies win in this respect. And users don't care what's 
 under the hood. They simply ask "Can I download an app?". If 
 they can't, they are very annoyed.


Yep, and businesses ask for features they wanted last week. So 
time to market matters ("can you deliver this new feature within 
2-4 weeks?").
Mar 06 2015
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 6 March 2015 at 13:22:47 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 6 March 2015 at 12:29:46 UTC, Chris wrote:

 to!). Frankly speaking, I hate JS and wish there was a way to 
 get rid of it (please, don't try to convince me that JS is 
 somehow good - it isn't - and that there is jquery and blah 
 dee blah. Please don't.).


 It isn't good, but once you figured out what to avoid, you can 
 use a subset of it pretty well. Like C++ and D ;^)

 It feels weird to type "Object.create(null)" to get a 
 dictionary-like object, but it will probably be fixed in 
 ECMAScript 6?


 worry about any platform specific quirks or pitfalls. 
 Something that is only a thin layer that is agnostic to the 
 logic, the data processing that goes on in the app. 
 Unfortunately, the only way to do this today is HTML5+JS (it's 
 the JS bit that annoys me).


 Yeah, but I think if you only do the GUI (the View part of MVC) 
 in JS using shadow dom it should be quite ok. And nothing 
 should prevent one from generating the JS bindings from D to 
 JS/HTML5 from D code.


 Using technologies (other than HTML5) that interface to native 
 widgets, is not maintainable, you're always one step behind.


 I agree. The alternative is to develop only for a few markets 
 (e.g. iOS/Cocoa). People are also quite used to the common UI 
 paradigms used on the web by now, so "learnability" is not the 
 same as in the 80s/90s where regular users would be terribly 
 confused when encountering innovative UI components. Text books 
 on usability probably lags a bit behind there...


Except the browser only offers a 80s/90s view of the desktop.

No way of providing an immersive experience with all the UI 
features the native platforms expose to their applications.

I lost count how many times I had to explain that the feature X, 
that the customers like so much in a given native application, is 
not possible in their new web based UI.

Last one was an upload progress bar with status with amount of 
uploaded data for files dragged into the browser, working the 
same way across all required browsers.


 Qt et al might work in markets where there is little 
 competition (low volume narrow markets), but I have trouble 
 seeing a future for it without a major player backing it 100% 
 to gain market share.

 I believe Google depends on HTML5 domination to keep 
 Apple/Microsoft from getting "too big".


They have Android for that.

ChromeOS might sell well in Amazon US, but I never saw one in my 
travels around Europe, except for the ones at German Saturn shops 
bundled with every type of promotion to try to get them out of 
the shop, with decreasing prices every time I come by.

--
Paulo
Mar 06 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 6 March 2015 at 14:22:21 UTC, Paulo  Pinto wrote:

 Last one was an upload progress bar with status with amount of 
 uploaded data for files dragged into the browser, working the 
 same way across all required browsers.


Meaning IE9? You can do it, by reporting back from the server 
(well, not on GAE, since uploads are dealt with by a separate 
system).

 From IE11 and up the support for modern web tech is quite 
impressive IMO.


 They have Android for that.


That's only one platform. They need to make sure that people are 
happy to use web apps on iOS, OS-X and Windows too.
Mar 06 2015
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 6 March 2015 at 14:43:20 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 6 March 2015 at 14:22:21 UTC, Paulo  Pinto wrote:

 Last one was an upload progress bar with status with amount of 
 uploaded data for files dragged into the browser, working the 
 same way across all required browsers.


 Meaning IE9? You can do it, by reporting back from the server 
 (well, not on GAE, since uploads are dealt with by a separate 
 system).


IE 8, tablets and smartphones with multiple browser versions.


 From IE11 and up the support for modern web tech is quite 
 impressive IMO.


 They have Android for that.


 That's only one platform. They need to make sure that people 
 are happy to use web apps on iOS, OS-X and Windows too.


Yep, that is why Inbox was made with J2ObjC.

http://arstechnica.com/information-technology/2014/11/how-google-inbox-shares-70-of-its-code-across-android-ios-and-the-web/
Mar 06 2015
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 6 March 2015 at 13:22:47 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 6 March 2015 at 12:29:46 UTC, Chris wrote:

 to!). Frankly speaking, I hate JS and wish there was a way to 
 get rid of it (please, don't try to convince me that JS is 
 somehow good - it isn't - and that there is jquery and blah 
 dee blah. Please don't.).


 It isn't good, but once you figured out what to avoid, you can 
 use a subset of it pretty well. Like C++ and D ;^)

 It feels weird to type "Object.create(null)" to get a 
 dictionary-like object, but it will probably be fixed in 
 ECMAScript 6?


 worry about any platform specific quirks or pitfalls. 
 Something that is only a thin layer that is agnostic to the 
 logic, the data processing that goes on in the app. 
 Unfortunately, the only way to do this today is HTML5+JS (it's 
 the JS bit that annoys me).


 Yeah, but I think if you only do the GUI (the View part of MVC) 
 in JS using shadow dom it should be quite ok. And nothing 
 should prevent one from generating the JS bindings from D to 
 JS/HTML5 from D code.


Yeah, has any further work been done on JS-D bindings? I remember 
there have been little projects here and there ...


 Using technologies (other than HTML5) that interface to native 
 widgets, is not maintainable, you're always one step behind.


 I agree. The alternative is to develop only for a few markets 
 (e.g. iOS/Cocoa). People are also quite used to the common UI 
 paradigms used on the web by now, so "learnability" is not the 
 same as in the 80s/90s where regular users would be terribly 
 confused when encountering innovative UI components. Text books 
 on usability probably lags a bit behind there...


True. Users are more willing to use different UIs these days, I 
guess because most homepages are little apps with a UI. Although 
there are still a few Windows-dinosaurs who go mental, if they 
don't find the "Start" menu in the left corner at the bottom of 
the screen. :)

I like the freedom HTML5 gives you (although CSS can be quite 
annoying sometimes). It's like a blank page. Native framworks are 
too prescriptive.


 Qt et al might work in markets where there is little 
 competition (low volume narrow markets), but I have trouble 
 seeing a future for it without a major player backing it 100% 
 to gain market share.


That's why I'm still sceptical of it. Whether it's worth the 
trouble.


 I believe Google depends on HTML5 domination to keep 
 Apple/Microsoft from getting "too big".


When introducing the iPad, Apple put its money on HTML5/JS to 
fight against Flash. I think everything is going in the direction 
of HTML5, which is understandable given the wide support it has 
and the myriad of different platforms. And Google, being an 
internet company, is of course a big proponent of HTML-based 
technologies.


 technologies win in this respect. And users don't care what's 
 under the hood. They simply ask "Can I download an app?". If 
 they can't, they are very annoyed.


 Yep, and businesses ask for features they wanted last week. So 
 time to market matters ("can you deliver this new feature 
 within 2-4 weeks?").


And the app is just a HTML widget, ha! But who cares once the 
user is happy.
Mar 06 2015
parent "Kagamin" <spam here.lot> writes:
On Friday, 6 March 2015 at 16:17:05 UTC, Chris wrote:

 True. Users are more willing to use different UIs these days


Probably they just got used to web being crap and take it easy, 
and glad it's not as bad as it can be.
Mar 07 2015
prev sibling parent reply "rumbu" <rumbu rumbu.ro> writes:
On Friday, 6 March 2015 at 12:29:46 UTC, Chris wrote:

 HTML5 ... HTML5 ... JS ... JS.. and so on

 To cut a long story short, ideals and pragmatism are at 
 loggerheads here, but at the end of the day, you have to get 
 your apps out there for as many people and as many platforms as 
 possible, with the least effort possible. So HTML5 and related 
 technologies win in this respect. And users don't care what's 
 under the hood. They simply ask "Can I download an app?". If 
 they can't, they are very annoyed. D should find a way to 
 interact with the "app world".


Microsoft already tried this by aggressively promoting 
WinJS/HTML5, hoping that they will attract the large crowd of 
HTML5/JS developers. It seems that nobody in Windows world likes 
it. Only 12% of apps from Store are developped in HTML5/JS. 8% in 


Even Facebook and Google developed their own applications in 

apps in WinJS/HTML5: 
http://www.zdnet.com/article/windows-8-developers-are-shunning-winjs/

In the same time, I think they learnt the lesson and they 
reactivated .net platform by open sourcing it and making it 
available also on Linux & Mac. And finally, the last .net blame 


Anyway, it's clear for me that the age of native controls is 
history. Today interfaces are described in markup languages, the 
OS is responsible to render it, there is a clear separation 
between the user interface and the code behind.
Mar 06 2015
parent reply "Kagamin" <spam here.lot> writes:
On Friday, 6 March 2015 at 21:22:31 UTC, rumbu wrote:

 Anyway, it's clear for me that the age of native controls is 
 history. Today interfaces are described in markup languages, 
 the OS is responsible to render it, there is a clear separation 
 between the user interface and the code behind.


Markup is just a frontend, it can work with anything. In fact, 
history only returned to where it started: UI was described in 
DSL since early versions of Windows (resources), you couldn't 
waste RAM on UI-building code, instead OS was instructed to read 
dialog resource and build the window for you, the resource was 
discarded right away, every byte was counted.
Mar 07 2015
parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Saturday, 7 March 2015 at 10:04:21 UTC, Kagamin wrote:

 On Friday, 6 March 2015 at 21:22:31 UTC, rumbu wrote:

 Anyway, it's clear for me that the age of native controls is 
 history. Today interfaces are described in markup languages, 
 the OS is responsible to render it, there is a clear 
 separation between the user interface and the code behind.


 Markup is just a frontend, it can work with anything. In fact, 
 history only returned to where it started: UI was described in 
 DSL since early versions of Windows (resources), you couldn't 
 waste RAM on UI-building code, instead OS was instructed to 
 read dialog resource and build the window for you, the resource 
 was discarded right away, every byte was counted.


Oh so it was for RAM reasons.
I've always wondered why it was that way for MFC. Since then I 
much prefer UI-building code.
Mar 07 2015
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Saturday, 7 March 2015 at 11:16:44 UTC, ponce wrote:

 On Saturday, 7 March 2015 at 10:04:21 UTC, Kagamin wrote:

 On Friday, 6 March 2015 at 21:22:31 UTC, rumbu wrote:

 Anyway, it's clear for me that the age of native controls is 
 history. Today interfaces are described in markup languages, 
 the OS is responsible to render it, there is a clear 
 separation between the user interface and the code behind.


 Markup is just a frontend, it can work with anything. In fact, 
 history only returned to where it started: UI was described in 
 DSL since early versions of Windows (resources), you couldn't 
 waste RAM on UI-building code, instead OS was instructed to 
 read dialog resource and build the window for you, the 
 resource was discarded right away, every byte was counted.


 Oh so it was for RAM reasons.
 I've always wondered why it was that way for MFC. Since then I 
 much prefer UI-building code.


MFC has an interesting background.

I always favoured OWL and VCL, which had a more C++ friendly 
programming model than what MFC does.

Apparently Microsoft did a poor job making a similar framework 
and from AFX ashes, MFC was born. Hence the Afx prefix.

http://computer-programming-forum.com/82-mfc/d13ea80282846f9f.htm

So we had to wait until Windows 8, to have finally something 
similar to VCL, via XAML/C++.

--
Paulo
Mar 07 2015
prev sibling parent "Piotrek" <no_data no_data.pl> writes:
On Friday, 6 March 2015 at 06:30:45 UTC, Rikki Cattermole wrote:

 I'll summarize my views on all of this.
 We keep making the same damn mistakes time after time. 
 Especially with GUI's.
 Stop trying to make GUI toolkits! Seriously just stop.
 WE DO NOT HAVE THE INFRASTRUCTURE FOR IT. Yes I know that is 
 yelling but it is true. We're still a long way off having 
 proper image manipulation. Or even basic OpenGL wrapping 
 functions. DirectX don't even joke.


Agree to some extent. But we can make small steps. At least if we 
figure out right architecture.


 TLDR: We think far too big and never actually work with a clear 
 strategic path towards a goal in mind.


Can you write briefly somewhere an analysis for gui development? 
Or possibly use add ideas/comments here:

https://github.com/D-Programming-Language-Labs/Proposals/blob/master/proposals/1_std_gui.md

I don't have too much time for gui as I'm currently in the 
process of including Phobos proposal modules into drafting 
library.

Piotrek
Mar 06 2015
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Friday, 6 March 2015 at 06:02:17 UTC, Taylor Hillegeist wrote:

 -Widgets-
 Personally I think that all layout items like HBar should be 
 children of widget that way i can make more modular component, 
 but that's just my opinion.


For user components, a UserControl is provided 
https://msdn.microsoft.com/en-us/library/system.windows.forms.usercontrol.aspx 
it can have layout inside and functionality focused on support 
for composite user components.


 -layout-
 I have a dream H/VBar + align/distribution/wrap options.


That's how GTK works. Layouts can be provided separately, anchors 
is the simplest one, boxes is the most flexible.


 I don't have an opinion on thread safe guis.


If you really need it, you can incapsulate thread-safety in a 
ViewModel (MVVM), while View will remain single-threaded.
Mar 06 2015
prev sibling next sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Friday, 6 March 2015 at 06:02:17 UTC, Taylor Hillegeist wrote:

 So I have played with a few GUI libraries with bindings 
 available through D. Personally I find that it seems like there 
 is alot of effort being put forth on GUI projects.


For consideration/inspiration/whatever, Hybrid was an interesting 
toolkit from the D1 days that I thought had a lot of potential: 
http://h3.gd/code/hybrid/wiki/

I'm still sad Tomasz went back to C++ land. :(

-Wyatt
Mar 06 2015
parent "Chris" <wendlec tcd.ie> writes:
On Friday, 6 March 2015 at 14:30:20 UTC, Wyatt wrote:

 On Friday, 6 March 2015 at 06:02:17 UTC, Taylor Hillegeist 
 wrote:

 So I have played with a few GUI libraries with bindings 
 available through D. Personally I find that it seems like 
 there is alot of effort being put forth on GUI projects.


 For consideration/inspiration/whatever, Hybrid was an 
 interesting toolkit from the D1 days that I thought had a lot 
 of potential: http://h3.gd/code/hybrid/wiki/

 I'm still sad Tomasz went back to C++ land. :(

 -Wyatt


True. True.
Mar 06 2015
prev sibling next sibling parent "Baz" <bb.temp gmx.com> writes:
On Friday, 6 March 2015 at 06:02:17 UTC, Taylor Hillegeist wrote:

 So I have played with a few GUI libraries with bindings 
 available through D. Personally I find that it seems like there 
 is alot of effort being put forth on GUI projects.

 It is my experience that most project's fail or die, not 
 because of lack of effort but lack of specification, many 
 people start projects thinking, can i make it do this? how 
 about this? and a project is born! but soon interest is lost 
 and the project dies. But specification can lead to projects 
 that become useful earlier, more stable, and live longer 
 happier lives.

 At this point i think the following features are the most 
 useful.

 -Ease of setup-
 dub integration is awesome, without it things are more 
 difficult. This has very little to do with the actual toolkit.

 -Minimal dependencies-
 Personally If i can statically link a toolkit to my GUI and it 
 has zero dependencies outside of the OS typically install. I am 
 very happy. really the less that can be messed with the better.

 best in my opinion: DWT MiniGUI DGUI at least for windows.

 -Rock Solid Stable-
 So when I do the hello world application I resize the window 
 push the buttons and do pretty normal things. But on some 
 libraries I get weird stuff going on sometimes the window even 
 becomes invisible..... scary.

 best in my opinion: GTKD TKD

 -GUI EDITOR/BUILDER-
 Good- You can edit a static layout
 Better- you can edit a layout and re-size the window layout 
 responds
 Best- you can edit the actual window in real time without 
 recompile.

 Good- You have a pallet of basic widgets that you can place.
 Better- You have a pallet of basic widgets + custom widgets 
 that you can edit.
 Best- You have the above + a database were people can share 
 widgets :)

 -Widgets-
 Personally I think that all layout items like HBar should be 
 children of widget that way i can make more modular component, 
 but that's just my opinion.

 -Data Binding-
 Most of the time I use that data a widget represents and much 
 less often the events they produce.

 -Ease of Use-
 Your tookits should work for you... not the other way round.

 -layout-
 I have seen some schemes like Winforms Dock,javaFX HBar, 
 HTML5's float/static/absolute/realitive... Idk what seems the 
 most freindly... HTML5/css seems the most complex. I have a 
 dream H/VBar + align/distribution/wrap options.

 I know some of these are RAD things. I don't have an opinion on 
 thread safe guis. personally I would like to see a GUI tookit 
 that the community said... use X it is just the way to go for 
 most things.


Click-able buttons A GUI toolkit should have...Click-able buttons 
rocks !

More seriously, one of the problem which explains why there no 
well-established GUI library around is the lack of serialization, 
component streaming solution. Currently there is no standard way 
in D to save and reload a class instance or a struct.
Mar 09 2015
prev sibling parent Jim Hewes <jimhewes gmail.com> writes:
I'd like to see D with GUI framework like JUCE. That's what would make 
me use D more. For now I'll stick with C++ and JUCE. I know it sounds 
superficial to have your choice of language based so much on GUI, but I 
write software for average people to use, not for other programmers (and 
not for servers). Average people use GUIs. I like with JUCE how it's 
very easy to make your own UI elements when you need to by using drawing 
primitives inside a paint() function. Then you can apply transforms to 
zoom in/out or manipulate easily.
Mar 28 2015