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 C++/XAML. 80% in C#/XAML. Even Facebook and Google developed their own applications in C#/XAML. Curiously, it seems that only Microsoft is developing 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 is fading away: C# compiles directly to native code. 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