On Sunday, 28 October 2018 at 05:56:21 UTC, Adam Wilson wrote:
> No arguments from me. So let's do it right.

https://newsroom.ibm.com/2018-10-28-IBM-To-Acquire-Red-Hat-Completely-Changing-The-Cloud-Landscape-And-Becoming-Worlds-1-Hybrid-Cloud-Provider
>IBM To Acquire Red Hat, Completely Changing The Cloud Landscape And Becoming World's #1 Hybrid Cloud Provider
>Most significant tech acquisition of 2018 will unlock true value of cloud for business
>IBM and Red Hat to provide open approach to cloud, featuring unprecedented security and portability across multiple clouds
>Deal accelerates IBM's high-value business model, making IBM the #1 hybrid cloud provider in an emerging $1 trillion growth market
>Red Hat to operate as a distinct unit within IBM's Hybrid Cloud team

$34 billion were just launched into cloud, not Qt, not UWP. $1 trillion growth market.

On Monday, 29 October 2018 at 15:15:44 UTC, Kagamin wrote:
> On Sunday, 28 October 2018 at 05:56:21 UTC, Adam Wilson wrote:
>> No arguments from me. So let's do it right.
>
> https://newsroom.ibm.com/2018-10-28-IBM-To-Acquire-Red-Hat-Completely-Changing-The-Cloud-Landscape-And-Becoming-Worlds-1-Hybrid-Cloud-Provider
>>IBM To Acquire Red Hat, Completely Changing The Cloud Landscape And Becoming World's #1 Hybrid Cloud Provider
>>Most significant tech acquisition of 2018 will unlock true value of cloud for business
>>IBM and Red Hat to provide open approach to cloud, featuring unprecedented security and portability across multiple clouds
>>Deal accelerates IBM's high-value business model, making IBM the #1 hybrid cloud provider in an emerging $1 trillion growth market
>>Red Hat to operate as a distinct unit within IBM's Hybrid Cloud team
>
> $34 billion were just launched into cloud, not Qt, not UWP. $1 trillion growth market.


Someone is not so happy about that move: as usual, a news is a news, and you can extract whatever you want from it.

https://www.zerohedge.com/news/2018-10-28/desperation-move-ibm-buys-red-hat-34-billion-largest-ever-acquisition

https://www.zerohedge.com/news/2018-10-29/ibm-bond-yields-default-risk-spike-after-red-hat-deal

On Thursday, 25 October 2018 at 00:00:49 UTC, Adam Wilson wrote:
> might be helpful. That said even the ISO C++ Standards Committee's SG13 has been struggling with graphics for the past 7 years. Although, given that this is a C++ ISO group, that could easily be the result of non-technical factors.

Precisely! I am not sure D community at current state would more than what C++ people tried to do... It requires huuuuge effort to come up with solution that is agreeable upon by all interested parties. Not impossible, but problem is - this requires a full-time job, IMHO.

On Wednesday, 24 October 2018 at 06:20:05 UTC, Adam Wilson wrote:
>
> At this point in time HTML/CSS/JS is by far the most prevalent UX toolkit in use today and not a single modern website uses the native widget theme. The bare minimum is Bootstrap.
>
> In terms of the usage of publicly available software to sample the HTML stack is utilized more than all other stacks combined. Next up is mobile apps, but even here usage of the default theme is in the trivial minority, the vast majority of mobile apps use themes that closely match the websites they are derived from.
>
> I firmly believe that a non-native, cross-platform, UX library will open D up to a whole new market of users that are desperate for something better than what they have now.

I believe most people in this community are not designers primarily so this might not seem like a "very worth it" goal to reach. But its clearly obvious to me...cus I've been doing web development and used GTK+ and some native GUI tookits for development...I use Linux a s my primary desktop. I also fairly know about how Android's UI works. Its clear that all new and most used GUI tookits are those that allow customization and abstract low-level details across platforms. Native tookit works really well when targeting a single platform which D already has a couple.

> I think this is a key point. The theme itself is now part of a brand and using the native toolkit would be a branding disaster. American Express, Facebook, or Google aren't in the business of showcasing Microsoft's, GNOME's, or Apple's branding, they want their apps to showcase their own brands.

I couldn't agree more. When you look at apps in Play Store or Apple's app store (Mac & iOS), you'll see the most popular apps are those designed and themed to look nice CROSS PLATFORM (for them most part). The thing with native toolkits is each platform is designed to look and work differently...you find yourself implementing hacks...lots of work...and what happens when OS vendor stop developing it like Window's often does for the new thing.


> And none of this is even counting the tooling ecosystem that would be recreate from scratch. Qt has QML, WPF and UWP have different flavors of XAML. There are special pre-compilers. The list goes on. So when individual sets out to bind a UX toolkit they inevitably flame-out because the amount of effort required to get something simple working is enormous.

That doesn't really matter much IMO. Most of these toolkits have such layout languages but they are not often used much beyound some niches...but its worth it though. The most important part is a well designed and simplistic APIs...and something like being able to customize UI elements/nodes with something like a subset of CSS...which GTK+ does really well. See elementary OS (elementary.io) for how beautiful GTK+ can be themed/customized.  Anther is Using SVG for icons and graphics by DEFAULT to simplify things...like scaling.


It's about time we settle down and talk about a solid, written in D GUI toolkit that is modern. Something that will compel mass adoption of D to build native apps...where it makes sense. At least, native apps are still relevant today...even for those of us doing more web apps.

On Wednesday, 24 October 2018 at 22:09:24 UTC, dayllenger wrote:
> On Wednesday, 24 October 2018 at 06:20:05 UTC, Adam Wilson wrote:
>> [...]
>
> By the way, I develop a fork of DlangUI for a while. It is pretty raw and doesn't have some important features, has no tutorials and tooling yet.
> https://github.com/dayllenger/atoll
>
> My ideas on its design:
> - use CSS for deep visual customization
> - there is no fixed set of CSS properties - widgets can define their own
> - mimicry to native controls with several themes
> - create few powerful layouts, which will satisfy 99% of demands - free (with manual positioning), stack (with inline flow), grid layout (with fixed, percent and automatic sizes, with cell alignments, with switchable row/column alignments, etc.)
> - make a possibility to embed the library into existing applications, like game engines or games themselves
>
This is exactly what DlangUI should have aimed to be like. Its still chasing after the old GUI path which is an already dying trend. DlangUI is a very impressive achievement and I'm very glad the developer is doing such massive work. However, the direction it's going in terms of layout and theming doesn't meet modern demands. I think CSS/subset of it, is perfect for customization. That's exactly the direction GTK+ is going after years of chasing the layout approach of Qt and other previous Windows toolkits.

> For now I am collecting information to decide what kind of markup language to use, or do not use it at all. I don't really understand necessity of HTML- or QML-like languages in this situation. They facilitate app development, but wait - design may be created in Designer tool, and logic is anyway done in the D language.

I think layout languages haven't really taken off in most toolkits that have them...relative to the use of the APIs themselves. Its a niche thing IMO. A well designed (clean, consistent, simplistic) API should be enough for most needs.


Another thing worth considering is a reactive GUI approach. Most modern toolkits are aiming for reactivity. Its something that can be attached as an opt-in (See RX in D: https://code.dlang.org/packages/rx) or used as a fundamental architecture. It makes so much sense.

Overview by looking at drawback of current OOP approach: https://eugenkiss.com/b/overview-of-reactive-gui-programming

The concept using a demo approach (must read): https://gist.github.com/staltz/868e7e9bc2a7b8c1f754

On Wednesday, 21 November 2018 at 08:25:03 UTC, aberba wrote:
> Another thing worth considering is a reactive GUI approach. Most modern toolkits are aiming for reactivity. Its something that can be attached as an opt-in (See RX in D: https://code.dlang.org/packages/rx) or used as a fundamental architecture. It makes so much sense.
>
> Overview by looking at drawback of current OOP approach: https://eugenkiss.com/b/overview-of-reactive-gui-programming
>
> The concept using a demo approach (must read): https://gist.github.com/staltz/868e7e9bc2a7b8c1f754

Thanks for the links. I thought about reactivity, and there is a lot of stuff to comprehend.

On Wednesday, 24 October 2018 at 06:20:05 UTC, Adam Wilson wrote:
> I was reading the hijacked JAXLondon thread about GUI's and started replying but decided against hijacking the already hijacked thread again.

    FYI, Microsoft just announced the open sourcing of WinForms, WPF and WinUI:

https://blogs.windows.com/buildingapps/2018/12/04/announcing-open-source-of-wpf-windows-forms-and-winui-at-microsoft-connect-2018/

Daniel

On Wednesday, 24 October 2018 at 06:20:05 UTC, Adam Wilson wrote:
>
> The D community, for all it's wonderful attributes does not have a "team" mindset. And this bears out if you audit code.dlang.org. The projects are universally the herculean efforts of one person, and occasionally a small number of secondary contributors.
>
> The way I see it. We either pull together around a unified vision for a UX toolkit written in D from the ground-up or we wait (im)patiently for a benevolent corporate benefactor to appear. It's that simple.
>
> I do have a vision for a non-native, WPF-like, UX toolkit written entirely in D. I estimate that it will take a minimum of three extremely dedicated, multi-disciplinary, individuals about three to five years to complete with the help of a constellation of secondary contributors. I have a rough design sketched out and I'd be happy to post it here but this message is already getting to long.
>
> This isn't the first time I've asked for help. And to be perfectly honest, I expect the same crickets response I've gotten before, but if you are interested and willing to dedicate yourself. Please let me know.
>
> I firmly believe that a non-native, cross-platform, UX library will open D up to a whole new market of users that are desperate for something better than what they have now.

UP

Some of us are unhappy with the situation and created a Working Group towards that more or less same goals https://github.com/DlangGraphicsWG

Anyone can make proposals and vote there.
Disagreement is exposed (reified) and process, requirements, and vision are 100% modifyable ; if you get the favour of the voting process.

It will still take a whole pile of effort (at least 3 man years at the very least), but it seems all the scraps and pieces are there in some D code form already, and getting to agree on things is imho the limiting factor. It turns out it's a controversial and intricated domain.

The workgroup is composed of mainly "bottom-up" library writers people  and it will be great to have more "top-down" people with an UX vision - this vision will have to be sold to others.