Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 20:56:05 UTC, someone wrote: On Tuesday, 1 June 2021 at 16:20:19 UTC, Ola Fosheim Grøstad wrote: [...] I wasn't considering/referring to content in the browser, this is an entirely different arena. [...] Thank you! I can only agree.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Wednesday, 2 June 2021 at 05:43:49 UTC, evilrat wrote: Yep, use Skia/Cairo or something like this, don't build your own full blown 2D engine for every possible graphics API. I would like to tune my C++ bindings generator to be able to handle Skia ASAP, but can't tell when it will be possible. It happens that Skia now has C API. I've generated C bindings and made my own BindBC package from it. https://github.com/Superbelko/bindbc-skia
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Wednesday, 2 June 2021 at 10:17:52 UTC, drug wrote: Usually 1 million of items aren't visible at once. Also there is opinion that total redrawing can be more efficient than caching because of making a decision what to cache and what not can be very complex. Depends on the application. My view on the GPU has changed a bit as some applications may use the GPU for computing application data, also pushing the GPU too hard will make it hot and fans start running (making users wonder what the app is doing). Say, if I used an accounting program and it caused the fan to spin, then I would be annoyed. :-D To estimate the height you need to have height of every elements, you can't dynamically create elements in that case. I create some wrapper over data set that stores height of elements. It's much cheaper and faster than creating a widget per item - that is a real advantage over retained gui. And user has access to that info - that is advantage over immediate gui. But yes, there are tasks that can/should be performed by dynamically created elements. Varying heights can be tricky, so just computing the heights in a wrapper seems reasonable. Another approach is to use an estimate that is updated as you bring in more items, but that is real work (for the programmer).
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
02.06.2021 12:50, Ola Fosheim Grøstad пишет: Depends on the data, I guess, if they are all visible at once then you basically have to very carefully write your own GPU render stage for that view and carefully cache things that does not move by rendering them to buffers (in GPU memory). Usually 1 million of items aren't visible at once. Also there is opinion that total redrawing can be more efficient than caching because of making a decision what to cache and what not can be very complex. But if you deal with large number of items you basically can write your own view and dynamically create elements as the user scrolls. You do need to estimate the height though. To estimate the height you need to have height of every elements, you can't dynamically create elements in that case. I create some wrapper over data set that stores height of elements. It's much cheaper and faster than creating a widget per item - that is a real advantage over retained gui. And user has access to that info - that is advantage over immediate gui. But yes, there are tasks that can/should be performed by dynamically created elements.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Wednesday, 2 June 2021 at 09:37:10 UTC, drug wrote: 02.06.2021 00:47, Ola Fosheim Grøstad пишет: I tried retained and immediate GUI, both fail (imho) for my use case - large data set of 1M+ heterogeneous items. Depends on the data, I guess, if they are all visible at once then you basically have to very carefully write your own GPU render stage for that view and carefully cache things that does not move by rendering them to buffers (in GPU memory). I was forced to invent my own wheel some where in-between retained and immediate GUI. Later I got know that it worked like browsers did (of course in general). I think that browser-like GUI is the future. Just current browsers are very over-engineered. They have some inefficiencies in how the DOM is being manipulated (like setting numeric styles as strings, but there is a fix coming for this, maybe it is available already?) But if you deal with large number of items you basically can write your own view and dynamically create elements as the user scrolls. You do need to estimate the height though. You can have a web-worker handling the dataset and basically stream it to the main thread that does the GUI. There is a delay though, so it takes some tweaking.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
02.06.2021 00:47, Ola Fosheim Grøstad пишет: Note: Many simple GUI toolkits are horribly inefficient as they let each object render themselves. An efficient GUI engine will have to replicate some of the browser complexity... I tried retained and immediate GUI, both fail (imho) for my use case - large data set of 1M+ heterogeneous items. GTK and Qt are very complicated in case of TreeView widgets in contrast to dear imgui or nuklear. In retained GUI (GTK and Qt) you need to prepare your data, create some intermediate data, probably copy data. TreeView in immediate GUI (imgui, nuklear) is pretty trivial and intuitive - you just use your data w/o anything else but it draws all items always so immediate GUI works nice if you have small data set. nuklear lets you use large data set but only if items have the same height. But because an item of TreeView can be collapsed or not its height changes and you need to calculate height for each items - you can do it yourself but available implementations of immediate GUI aren't capable to use that info so you need to modify immediate GUI core system and that is very complicated job in contrast to retained GUI where adding new widget is much easier. I was forced to invent my own wheel some where in-between retained and immediate GUI. Later I got know that it worked like browsers did (of course in general). I think that browser-like GUI is the future. Just current browsers are very over-engineered. My impression is that immediate and retained GUI belong to different domains and are not interchangeable. Browser-like GUI is superset of both retained and immediate GUI. Just it should be implemented properly.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Wednesday, 2 June 2021 at 01:29:51 UTC, cc wrote: It's 2021 and I'm still waiting for parent selectors. Even :has() isn't implemented by anything yet. I think that is because :has() is Selectors Level 4, which is a working draft, so not a standard yet. https://www.w3.org/Style/CSS/current-work
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
Btw there is also (dear) imgui, which is immediate mode GUI that builds geometry to draw for you, how one would draw it is up to programmer. It is very popular in game dev because there is very little setup to get it working. Source https://github.com/ocornut/imgui D bindings with GL3 demo https://github.com/Superbelko/imgui-d On Tuesday, 1 June 2021 at 23:50:35 UTC, Ola Fosheim Grøstad wrote: Not sure how that relates to Skia? Skia is used in many products. If I was to use D for something serious, Skia would probably be the first thing I would consider... Yep, use Skia/Cairo or something like this, don't build your own full blown 2D engine for every possible graphics API. I would like to tune my C++ bindings generator to be able to handle Skia ASAP, but can't tell when it will be possible.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 23:42:58 UTC, someone wrote: Bump. On Tuesday, 1 June 2021 at 23:50:35 UTC, Ola Fosheim Grøstad wrote: Not sure what you meant? errr ... me neither ! Now seriously: attempted to tell you that evidently I know far less than what I think I know. Of course not, D is a hobby and I consider D to be a work-in-progress. Crystal-clear. Not sure how that relates to Skia? Skia is used in many products. If I was to use D for something serious, Skia would probably be the first thing I would consider... ACK.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 20:20:34 UTC, Ola Fosheim Grøstad wrote: Web components are becoming a reality, it essentially means that you have code and styling wrapped up as a component, so that you can use it by inserting a custom html-tag in your code. Given the massive amount of web developers... you'll eventually have a crazy amount of components to choose from. Just waiting for Safari: https://caniuse.com/?search=components I think? It's 2021 and I'm still waiting for parent selectors. Even :has() isn't implemented by anything yet.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 23:42:58 UTC, someone wrote: On Tuesday, 1 June 2021 at 23:16:04 UTC, Ola Fosheim Grøstad wrote: Possibly. Yet, Skia release notes keep mentioning hardware related themes. I guess that could be your canary (wait until release notes no longer list hardware related issues). Huh When Skia release notes no longer mention changes due to hardware, then we can assume that the hardware abstraction is workable. There is no such thing as 2D/3D anymore AFAIK? Shaders are fairly generic. Bump. Not sure what you meant? Skia is less work. Have you actually used it within D for anything remotely "serious" ? By serious I mean something not a casual/hobby project, something that you must rely on. Of course not, D is a hobby and I consider D to be a work-in-progress. Not sure how that relates to Skia? Skia is used in many products. If I was to use D for something serious, Skia would probably be the first thing I would consider...
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 23:16:04 UTC, Ola Fosheim Grøstad wrote: I am of a similar mindset as you, when I use Linux I tend to go minimal WM and setup. It IS depressing how much resources editors use to reach the same fluidity as the editor I used on my Amiga in the 1980s (which used hardware registers for scrolling). Amiga's ? I did have them all (insert REALLY BIG SMILE here) ! I never used anything like Workbench anymore -when I say Ubuntu was snappy-as-hell and now remember what was like on the Amiga ... he. The Windows/Macs of the time seemed escaped out of prehistory those days. Even the Atari was far better. But you know what ? The IBM PC was the **serious** (laughing out loud) way to go. Sad. I did learn a lesson what market forces implied back at the time. Yes, but WebGL is basically the same as ES, WebAssembly containers... D is supposed to support those? Didn't know. Thought it was a totally different story. Will look it up. Of course individually supporting the three main APIs is a no-go, that's why I mentioned Vulkan, you say it is not mature, it will mature. To me Vulkan is like Wayland, there's no going back regardless whether you/we consider it has merits or not. I don't know. Hardware vendors are eager to reach market with new hardware and will most likely continue to ship buggy drivers for the bleeding edge hardware? But we can always hope. :) You have a point. The major bugs/annoyances are pretty soon ironed out for the Windows platform and never reach the nixes in parity. What we got was late, very late, often when two (or more) newer product generations already reached the market and all eyes are set on them and nobody cares supporting old hardware for 1% niche market share of the nixes. Quite understandable by the way. Nvidia/Broadcom being the worst when nix support comes to mind. Possibly. Yet, Skia release notes keep mentioning hardware related themes. I guess that could be your canary (wait until release notes no longer list hardware related issues). Huh There is no such thing as 2D/3D anymore AFAIK? Shaders are fairly generic. Bump. Skia is less work. Have you actually used it within D for anything remotely "serious" ? By serious I mean something not a casual/hobby project, something that you must rely on.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 22:52:41 UTC, Adam D. Ruppe wrote: On Tuesday, 1 June 2021 at 22:39:08 UTC, Ola Fosheim Grøstad wrote: Yes, it does. You get lots of graphic context switches and poor render-caching performance. no not really. you'd have to be really incompetent to do it this wrong. If each widget imperatively draws itself you get graphic context switches every time you draw a different graphical element type. If the render engine manages this, you have much more opportunity to group similar items. E.g. do all text of one font size in one GPU operation. Then you also have the whole issue of backing store (caching) which cannot be done in an optimal fashion if the widget is in control.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 22:50:49 UTC, someone wrote: I noticed and struck me was the responsiveness of the GUI: snappy as hell compared to the usual Windows 7 machines we dealt with at the time, and, I mean snappy as hell **without** customizing it disabling animations and the like, this was a responsive GUI out-of-the-box. It was on gnome 2 of course. The first time I saw gnome 3 was game over. I am of a similar mindset as you, when I use Linux I tend to go minimal WM and setup. It IS depressing how much resources editors use to reach the same fluidity as the editor I used on my Amiga in the 1980s (which used hardware registers for scrolling). IIRC openGL ES is for mobile not for desktop which needs plain openGL. Yes, but WebGL is basically the same as ES, WebAssembly containers... D is supposed to support those? Of course individually supporting the three main APIs is a no-go, that's why I mentioned Vulkan, you say it is not mature, it will mature. To me Vulkan is like Wayland, there's no going back regardless whether you/we consider it has merits or not. I don't know. Hardware vendors are eager to reach market with new hardware and will most likely continue to ship buggy drivers for the bleeding edge hardware? But we can always hope. :) Indeed. But the game industry has totally different requirements/expectations for the hardware than we need to write a classical 2D GUI toolkit. They need APIs close to the hardware as possible and very often bypass everything in its path seeking 3D performance gains. Possibly. Yet, Skia release notes keep mentioning hardware related themes. I guess that could be your canary (wait until release notes no longer list hardware related issues). I guess Vulkan will have separate 2D/3D APIs like openGL so this will be no major concern giving the huge different code base size for each, but I am talking of pure guess, I will eventually read about it (at least) out of sheer curiosity. There is no such thing as 2D/3D anymore AFAIK? Shaders are fairly generic. But you have to support at least Metal and Vulkan, and possibly WebGL. Skia is less work.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 22:39:08 UTC, Ola Fosheim Grøstad wrote: My understanding is that dropping OS icons onto the web view is problematic You have to subscribe to the particular content type so it doesn't always work but it is totally doable. You can play with it using simpledisplay.d's drag and drop support. but maybe they have overcome this because of Chrome OS. No, I don't use it, except for file uploads. Web drag and drop actually dates back to IE 5. It has been cleaned up a little since then and now prefers mime types to the type enum it used to do (though both still tend to work) but it isn't actually all that different. Yes, it does. You get lots of graphic context switches and poor render-caching performance. no not really. you'd have to be really incompetent to do it this wrong.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 21:47:38 UTC, Ola Fosheim Grøstad wrote: Well, on a Mac I would just embed a WebView which already is ready in the OS UI framework. Thanks for the illustration on how you'll eventually proceed with it on the Mac side of things -I use iPhones since the 4 series but frankly I never developed on (or used for a significant time) a modern Mac. Not that much of a performance bottle neck, unless you push a lot of data. I wouldn't use it for an audio/graphics editor. Memory usage is more of an issue though. It just came to mind the first time I installed and used a linux distro for a significant amount of time: it was Ubuntu in the 8~9 time-frame circa 2008~2009 (Jaunty Jackalope if memory serves), and coming from the Windows world, mainly on the Windows server platform which we usually (and thoroughly) optimized as workstations for our daily drivers (we can't even stood for a minute the amount of crap Microsoft dumped on its consumers OSs -even configuring them with the classical UI dumping animations and a zillion more things), the first thing I noticed and struck me was the responsiveness of the GUI: snappy as hell compared to the usual Windows 7 machines we dealt with at the time, and, I mean snappy as hell **without** customizing it disabling animations and the like, this was a responsive GUI out-of-the-box. It was on gnome 2 of course. The first time I saw gnome 3 was game over. Primarily because it cuts down on developer time. It is easy to change and you can easily configure it for many configurations (e.g. easy to create a limited features version). This trend will increase as web component repos become available. At some point it might become prohibitively expensive to develop complex user interfaces without web technology. If we were on slashdot I would undoubtedly mark this as insightful. The problem now is that you have to support both Metal, OpenGL ES, and Direct X. Vulkan isn't well enough supported to be a convenient target. IIRC openGL ES is for mobile not for desktop which needs plain openGL. Of course individually supporting the three main APIs is a no-go, that's why I mentioned Vulkan, you say it is not mature, it will mature. To me Vulkan is like Wayland, there's no going back regardless whether you/we consider it has merits or not. History also tells us that hardware GPU abstractions tend to be weak and not last very long. Indeed. But the market is so huge nowadays that the stakes are set higher. Or so I want to believe. The game industry spends a lot of money supporting/testing various hardware drivers and working around bugs in said drivers/hardware. Indeed. But the game industry has totally different requirements/expectations for the hardware than we need to write a classical 2D GUI toolkit. They need APIs close to the hardware as possible and very often bypass everything in its path seeking 3D performance gains. At the end of the day, the user will be upset if the application crashes because of a vulkan-bug/hardware-bug. So in that context browser-overhead isn't all that bad. I guess Vulkan will have separate 2D/3D APIs like openGL so this will be no major concern giving the huge different code base size for each, but I am talking of pure guess, I will eventually read about it (at least) out of sheer curiosity. It is not so much that I disagree, but the hard reality is that there are few attractive alternatives that are portable and also cuts down on developer time. Sad by true.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 22:13:08 UTC, Adam D. Ruppe wrote: On Tuesday, 1 June 2021 at 21:47:38 UTC, Ola Fosheim Grøstad wrote: Right now, drag-and-drop is not as easily supported in browser UIs though. That is an argument for using native UI. eh web drag and drop isn't half bad at all. Have you ever used it? My understanding is that dropping OS icons onto the web view is problematic, but maybe they have overcome this because of Chrome OS. No, I don't use it, except for file uploads. Note: Many simple GUI toolkits are horribly inefficient as they let each object render themselves. That doesn't make any sense. Yes, it does. You get lots of graphic context switches and poor render-caching performance.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 21:47:38 UTC, Ola Fosheim Grøstad wrote: Right now, drag-and-drop is not as easily supported in browser UIs though. That is an argument for using native UI. eh web drag and drop isn't half bad at all. Have you ever used it? Note: Many simple GUI toolkits are horribly inefficient as they let each object render themselves. That doesn't make any sense.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 20:56:05 UTC, someone wrote:
Now think for a instant, that you choose D for performance so
you expect it to be fast, and you write the hello world app to
begin with, and you fire-up a full-framework like Electron or
the like just to give you basic GUI controls.
Well, on a Mac I would just embed a WebView which already is
ready in the OS UI framework. Electron allows you to execute
native code I think ("Napi" or something?). A better approach is
probably to use Chromium Embedded Framework v3, which supposedly
is multithreaded.
But, why are we, to begin with, stacking layers upon layers of
APIs (meaning millions of lines of code and/or degrading
performance to extreme levels and/or increasing the attack
surface of our lean app) just to say hello world in a window
and expecting the user to close it at any given time and ...
nothing more ?
Not that much of a performance bottle neck, unless you push a lot
of data. I wouldn't use it for an audio/graphics editor. Memory
usage is more of an issue though. Depends on the app, if it is a
"clock" then it obviously is too much. If it is a full
application then it is ok.
Why did we choose to use huge frameworks, embed browsers, etc
to write a simple app ?
Primarily because it cuts down on developer time. It is easy to
change and you can easily configure it for many configurations
(e.g. easy to create a limited features version).
This trend will increase as web component repos become available.
At some point it might become prohibitively expensive to develop
complex user interfaces without web technology.
Right now, drag-and-drop is not as easily supported in browser
UIs though. That is an argument for using native UI.
I think someone with the knowledge to write a classical toolkit
in pure-D following the classical design principles with the
standard controls and nothing more should need deep openGL
knowledge to begin with (however a better choice should be
start from zero with its Vulkan successor) providing he/she has
access to proven code for text input and/or font rendering
(quite complex) and besides full-UniCode support (which in D is
not a problem at all).
The problem now is that you have to support both Metal, OpenGL
ES, and Direct X. Vulkan isn't well enough supported to be a
convenient target.
History also tells us that hardware GPU abstractions tend to be
weak and not last very long.
So you are still stuck with an abstraction layer like Skia. It is
just too expensive to support all hardware yourself.
The game industry spends a lot of money supporting/testing
various hardware drivers and working around bugs in said
drivers/hardware.
At the end of the day, the user will be upset if the application
crashes because of a vulkan-bug/hardware-bug. So in that context
browser-overhead isn't all that bad.
And of course, feel free to argue on everything you disagree
with :)
It is not so much that I disagree, but the hard reality is that
there are few attractive alternatives that are portable and also
cuts down on developer time.
I would personally consider the options:
1. Rolling my own using Skia, especially if I only need mouse
input and no keyboard.
2. CEF or WebView, just to get to a productive stage sooner.
Assuming the UI is not pushing a large amount of data.
3. Qt/Gtk, but I think they come with a lot of baggage... so I
personally don't find it more attractive than WebView for basic
UIs. If you already know webtech it becomes even less attractive
to learn a framework that is less flexible than a webview. I
don't see a healthy future for Qt/Gtk, but webtech is there to
stay.
Note: Many simple GUI toolkits are horribly inefficient as they
let each object render themselves. An efficient GUI engine will
have to replicate some of the browser complexity...
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 16:40:22 UTC, IGotD- wrote: This is also my observation. Browser UI is on the way to take over. They are the symptom that the underlying foundations are broken so we go the easy way: like we don't want to standardize the APIs on our OS so lets fire a browser and get standard APIs. Laziness over righteousness because computer power is cheap. And then we have all our critical internal data right there on the browser and ooops ... what can go wrong ?
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 16:20:19 UTC, Ola Fosheim Grøstad wrote: I don't really agree with this, most of the interesting things for specifying UIs are happening in in web-frameworks/web-standards nowadays. I wasn't considering/referring to content in the browser, this is an entirely different arena. If I were to make a desktop application in D today then I would have chosen to either embed a browser-view and use that for interface, or electron. Not sure if has been mentioned already, but it is an option. I don't agree with that at all but I respect your point and encourage you to do so provided you'll end with something useful to you. The point with that approach is performance, performance, and did I say it ? ... performance. I don't know about you but, what are the reasons you choose to develop in D ? One of the often cited reasons I came across is performance alongside with better-C style comments and full OOP and the like; which as a side-note it happens to be my case. So for a little while put you on my shoes and try to see the subject we are discussing from my point of view: Now think for a instant, that you choose D for performance so you expect it to be fast, and you write the hello world app to begin with, and you fire-up a full-framework like Electron or the like just to give you basic GUI controls. Stretch it a bit, instead of using Electron and family you coded a basic HTML page saying hello world and put a button in a form element to close the page/document and then you embed a web browser within your app, a fully-fucking-huge-meaning-millions-of-lines-of-code-with-thousands-of-non-relevant-modules-like-TLS/SSL-Web-Assembly-JavaScript-and-keep-counting just to ... render hello world inside your blazingly-fast-lean D program ? Will it work ? Sure. But, why are we, to begin with, stacking layers upon layers of APIs (meaning millions of lines of code and/or degrading performance to extreme levels and/or increasing the attack surface of our lean app) just to say hello world in a window and expecting the user to close it at any given time and ... nothing more ? Why did we choose to use huge frameworks, embed browsers, etc to write a simple app ? Because the basics, the foundations, are broken. Instead of trying to fix the broken bits to allow us to choose the obvious/correct/lean/straightforward path, we, developers (and now I am talking from the point of view of the whole community), keep using higher and higher levels of abstraction to accomplish simple things. Given the power of a typical computer nowadays there is no excuse for a GUI to be blazingly-fast, snappy-as-hell, zero-lag. If these symptoms are present we are doing it wrong. Don't get me wrong: browsers are extremely useful pieces of software. The problem is everybody starts to think the browser is the OS. This approach, to my humble point of view, is short-sighted. We came full-circle: from everything done on the mainframe with stupid terminals on the other side of the line, to personal computers offloading work from servers and starting "thinking" by themselves and all the related client/server stuff of the early 90s, to the Sun's vision the-network-is-the-computer and all the related Java stuff which more-or-less brought us the web browsers, to the google's vision the-web-browser-is-the-OS approach. Endless layers upon layers. Web browsers are fantastic for browsing/reading complex documents with all its hyperlinks, stupid things that now assume for granted, but with its complex rendering engines, they are, and I said it once again, fantastic pieces of software. The problem with the web browser, and now we are backing to the GUI subject we are discussing here, is that sometimes in mid-00s their development started to be orchestrated by the commercial world and specifically by the ad industry, seeing them as software to sell relegating its primary purpose of knowledge/browsing documents, that's why we left HTML 4/XHTML 1.0/1.1 behind and got HTML 5 instead of XHMTL 2 which was the right way to go if the browsers kept sticking to their primary goal. Now the browser mandates font face/style/size, strict-layouts, a magazine, a cool selling magazine on my screen. Evolution. Nothing against it, quite the opposite, a document-centric and app-centric browser split was what was needed then. Dreams. So from then on we started to see the decadence of GUI design: buttons that didn't look like buttons at all, etc. Which is that ? Ah, dunno, try to click over it and let's check if anything happens ... are you following me ? Then came Johnny Ives @ Apple with its concept of the flat user interface. Now everything is flat: is this a button ? is this a ... ? Who knows. This was followed by everyone outside Apple since Apple was cool back then, and we got gnome 3 and KDE Plasma and Unity. Everything learned so far went to the trashcan. So real people
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 20:20:34 UTC, Ola Fosheim Grøstad wrote: Web components are becoming a reality, it essentially means Turns out Microsoft has a UI component library for browsers, looks interesting: https://www.fast.design/
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 16:40:22 UTC, IGotD- wrote: This is also my observation. Browser UI is on the way to take over. Advantages are that they are easy to remote, meaning if you have network connection you can run it on another device. Yes, browsers are making X11 obsolete... You can also more easily find people who have the knowledge making cool looking web content, compared to people who know how to make custom UI in Qt or C#. Web components are becoming a reality, it essentially means that you have code and styling wrapped up as a component, so that you can use it by inserting a custom html-tag in your code. Given the massive amount of web developers... you'll eventually have a crazy amount of components to choose from. Just waiting for Safari: https://caniuse.com/?search=components I think?
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 16:20:19 UTC, Ola Fosheim Grøstad wrote: I don't really agree with this, most of the interesting things for specifying UIs are happening in web-frameworks/web-standards nowadays. But it doesn't matter... If I were to make a desktop application in D today then I would have chosen to either embed a browser-view and use that for interface, or electron. Not sure if has been mentioned already, but it is an option. This is also my observation. Browser UI is on the way to take over. Advantages are that they are easy to remote, meaning if you have network connection you can run it on another device. Some mobile phones have a "hidden" web UI if you connect to them using a browser. Another advantage is that web UI scales well with different resolutions and aspect ratios. You can also more easily find people who have the knowledge making cool looking web content, compared to people who know how to make custom UI in Qt or C#. Car infotainment systems often runs the graphics in a browser, without many knowing about it. They work similar to FireFox OS, you boot directly to the browser.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 15:38:51 UTC, someone wrote: It is a mature field, they peaked in the late 90s early 00s. What came afterwards was mainly decoration/cosmetics because the hardware evolved to being able to handle it. But the concepts, what a combo-box is, how it works, etc, remained set on stone. Of course new controls were invented but most of them were for corner-cases or things quite specific like a UI for a pro-audio console mixer. I don't really agree with this, most of the interesting things for specifying UIs are happening in web-frameworks/web-standards nowadays. But it doesn't matter... If I were to make a desktop application in D today then I would have chosen to either embed a browser-view and use that for interface, or electron. Not sure if has been mentioned already, but it is an option.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 11:52:51 UTC, Adam D. Ruppe wrote: Have you ever used github before? No I did not. That's how it works. You "fork" something, do a small change, then open a pull request back to the original. Then your "fork" gets abandoned until next time you want to do a PR. My first guess was lots of projects going on each one's directions. Sorry for this comment. I should know better :( This is perfectly normal on that site. Number of forks is actually correlated with number of *contributors*, not abandonment. ACK.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 11:13:49 UTC, zjh wrote: Right,I prefer 1*100% over 3*90%. Without any doubt.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 10:53:54 UTC, Ola Fosheim Grøstad wrote: It is tempting to think that UI-specification is a mature field, but apparently not. It is still evolving. It is a mature field, they peaked in the late 90s early 00s. What came afterwards was mainly decoration/cosmetics because the hardware evolved to being able to handle it. But the concepts, what a combo-box is, how it works, etc, remained set on stone. Of course new controls were invented but most of them were for corner-cases or things quite specific like a UI for a pro-audio console mixer. I think the best approach is to create an UI for a specific application and then later turn it into a library. Then one at least have experience and can sort out weak spots before handing it to others. I second that providing you use a language like C/C++/D/Rust but not something more high-level. One thing is UI design/specifications, and the other, the implementation is quite a different matter: native vs CSS-style driven etc ... this is where things starts to making conflicts. Maybe if DPlug had more users something interesting would emerge? DPlug is the only framework I find interesting with D right now. Will look for it, didn't know of it till now.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 10:11:25 UTC, evilrat wrote: Would like to pay for something that's not exists where there is already like 10 "good enough"(tm) alternatives? How much people actually use D and willing to pay for that? Another issue is that these hobby projects are not state of the art solutions, they stuck in early 90's (ok, maybe late 90's), where the rest of the world using different architectures and approaches that was evolved several times from then. And yet people who asks for UI libraries goes like "nah, no fancy schmancy CSS, and no markup. gimme good ol' programmatical approach" or "bloat bloat bloat, no thanks" Regarding what you say on the state-of-the-art GUI/toolkits I should clarify that I am not against "modern" UI development. Everyone should work/code as they like and I am no-one to say the contrary. What I am against to is the idea of **unifying** the UIs for desktop and mobile resulting in sub-par experience for both of them -which is what happened. That's the chicken-egg problem - no funding because no decent solutions, no decent solutions because such enormous effort requires compensation. eg: postgreSQL is not on the edge of the state-of-the-art right now but it is closing the gap more than ever to the point that when there have to be a choice made on merits and not politicals it is making a dent in Oracle which is the 800-pound gorilla in this category -even against Microsoft's SQL Server which drives a lot of things in the enterprise/financial world. eg: qGIS is another project widely used, and I mean **really** widely used for big projects not hobby projects; think city plans, dams, and the like -every day real world cases not fuss. I speak of these because it is what I know of, there should be some more, but clearly, this is not the rule, this is the exception -and also have in mind that these two projects don't get indirectly managed by big corporations alla-linux these days.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 06:31:28 UTC, Ola Fosheim Grostad wrote: The solution is to reduce the scope of projects, but that requires design and planning. Hobby projects tend to be experiments that evolve over time. The solution for (at least some critical) projects is to be leaded by a benevolent dictator for their lifespans , but, this is, yes, as you probably guess, and as anyone expects, quite difficult to cope with. This would bring a clear roadmap, consistency, and predictability. But this is irrelevant to this post and the subject for an entirely different thread -I don't want to insert noise here.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 05:26:47 UTC, Mike Parker wrote: But have you actually investigated it? It's being actively maintained. Being advised not to use it is not the same as saying won't use it; however I consider it a red flag, or to say it in other words, something that I have to pay even more attention to before start using it in order to not shoot me on the foot. I am researching the whole subject of GUI toolkits and right now I have no less than 10 toolkits to go so, even downloading, installing, configuring, reading some basic documentation, and making something stupid like a hello world app for each one will take some time, this is no surprise. Up to this point I didn't discard anything since I am aware I still have no deep insights/basis to. Give me some time please, but anything that comes to mind keep telling me, it helps a lot, thanks :) !
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 03:36:00 UTC, someone wrote: On Sunday, 30 May 2021 at 07:03:38 UTC, Chris Piker wrote: Of the 107 forks of dlangui last seen on github ... I can't believe it. What a waste of time/resources. It is like if I forked MATE, changed the title, made 10/20/or-so changes here and there and then dropped out of sight. Pointless. Have you ever used github before? That's how it works. You "fork" something, do a small change, then open a pull request back to the original. Then your "fork" gets abandoned until next time you want to do a PR. This is perfectly normal on that site. Number of forks is actually correlated with number of *contributors*, not abandonment.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 05:26:47 UTC, Mike Parker wrote: But have you actually investigated it? It's being actively maintained. https://github.com/d-widget-toolkit/dwt Yeah, DWT is solidly OK. I'd pick it over gtkd if you wanted to target Windows since it doesn't use gtk there.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 03:16:05 UTC, someone wrote: Skia developed by google for C++ using openGL I think it uses Metal, OpenGL ES, translation layer to OpenGL and Direct X, backend for Vulkan (but Vulkan hardware drivers apparently tend to be buggy). Also a build for webassembly. It is the graphics engine for Chrome and Firefox, so it is probably the best bet if you want cross platform support. See release notes for progression: https://skia.org/docs/user/release/release_notes/
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
We need more "100% projects" that are just plug n play rather than plug n pray Right,I prefer 1*100% over 3*90%.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 10:11:25 UTC, evilrat wrote: Another issue is that these hobby projects are not state of the art solutions, they stuck in early 90's (ok, maybe late 90's), where the rest of the world using different architectures and approaches that was evolved several times from then. And yet people who asks for UI libraries goes like "nah, no fancy schmancy CSS, and no markup. gimme good ol' programmatical approach" or "bloat bloat bloat, no thanks" Yes, I agree. I think Flutter forced Apple's hand, so they made SwiftUI? It is tempting to think that UI-specification is a mature field, but apparently not. It is still evolving. I think the best approach is to create an UI for a specific application and then later turn it into a library. Then one at least have experience and can sort out weak spots before handing it to others. Maybe if DPlug had more users something interesting would emerge? DPlug is the only framework I find interesting with D right now.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 06:31:28 UTC, Ola Fosheim Grostad wrote: On Tuesday, 1 June 2021 at 05:27:41 UTC, Imperatorn wrote: On Tuesday, 1 June 2021 at 03:32:50 UTC, someone wrote: [...] Yeah, "fragmentation" is a problem. We do a lot of things 90%. We need more "100% projects" that are just plug n play rather than plug n pray The solution is to reduce the scope of projects, but that requires design and planning. Hobby projects tend to be experiments that evolve over time. Would like to pay for something that's not exists where there is already like 10 "good enough"(tm) alternatives? How much people actually use D and willing to pay for that? That's the chicken-egg problem - no funding because no decent solutions, no decent solutions because such enormous effort requires compensation. Another issue is that these hobby projects are not state of the art solutions, they stuck in early 90's (ok, maybe late 90's), where the rest of the world using different architectures and approaches that was evolved several times from then. And yet people who asks for UI libraries goes like "nah, no fancy schmancy CSS, and no markup. gimme good ol' programmatical approach" or "bloat bloat bloat, no thanks"
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 05:27:41 UTC, Imperatorn wrote: On Tuesday, 1 June 2021 at 03:32:50 UTC, someone wrote: [...] Yeah, "fragmentation" is a problem. We do a lot of things 90%. We need more "100% projects" that are just plug n play rather than plug n pray The solution is to reduce the scope of projects, but that requires design and planning. Hobby projects tend to be experiments that evolve over time.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 03:18:22 UTC, someone wrote: On Sunday, 30 May 2021 at 12:27:34 UTC, Siemargl wrote: You forget semi-official DWT For starters I was advised that it is in not good shape. Another one going down :( But have you actually investigated it? It's being actively maintained. https://github.com/d-widget-toolkit/dwt
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Tuesday, 1 June 2021 at 03:32:50 UTC, someone wrote: [...] Yeah, "fragmentation" is a problem. We do a lot of things 90%. We need more "100% projects" that are just plug n play rather than plug n pray
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Saturday, 29 May 2021 at 10:52:11 UTC, Alain De Vos wrote: One additional toolkit, fltk, Just checked it: FLTK (aka fulltick) for C++ targeting X with openGL: [screenshots](https://www.fltk.org/shots.php) - we do not depend on text-based attributes (GTK+, MOTIF), complex chains of support libraries (GTK+, KDE, wxWidgets), workarounds to provide OO features in standard C (GTK+), a special compiler preprocessor (KDE), or a non-standard variant of C (Cocoa) - supports UniCode and HiDPI since version 1.3.6-STABLE Seems worth a try I guess.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Sunday, 30 May 2021 at 07:03:38 UTC, Chris Piker wrote: Of the 107 forks of dlangui last seen on github ... I can't believe it. What a waste of time/resources. It is like if I forked MATE, changed the title, made 10/20/or-so changes here and there and then dropped out of sight. Pointless.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Sunday, 30 May 2021 at 11:10:31 UTC, Imperatorn wrote: I'm 100% positive you can do good ui using D, but, I'm not sure what I'd choose because of the fragmentation. Of course you can do a good UI on D, C, C++, Rust, or any other system programming language. That is not disputed. From my humble point of view, the problem, seems to be that everybody is attempting to reinvent gun powder for whatever reasons, many maybe valid ones, but the lot of them I think not. This left us (as a community) with those statements that you came across on any given distro overview/features/wiki page saying something like: for doing such thing you have a lot of apps; being those blah blah blah ... and of course, none of them work and/or accomplish what you want to do because ... a lot of reasons that doesn't matter here. There are **lots** of really good apps in the open source world: comes to mind (from what I use) postgreSQL with its undisputed high quality code/documentation and its "sane" community, QGIS, etc, but every such statement should have a footnote more or less in the following terms: let's stop fooling ourselves.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Sunday, 30 May 2021 at 12:09:22 UTC, cc wrote: https://streamable.com/2uvt4h cool ... to say the least !
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Sunday, 30 May 2021 at 12:27:34 UTC, Siemargl wrote: You forget semi-official DWT For starters I was advised that it is in not good shape. Another one going down :(
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Sunday, 30 May 2021 at 12:18:06 UTC, Ola Fosheim Grøstad wrote: There are many GUIS for OpenGL, but OpenGL is no longer supported on Macs AFAIK. Indeed: openGL on all Apple platforms was finally deprecated on 2018 after Apple introduced its own proprietary Metal API. I suggest using Skia instead: I been reading about it: Skia developed by google for C++ using openGL - most similar in purpose to Cairo or PathFinder (meaning that it focuses on drawing) rather than to other more elaborate infrastructures like QT that provide their own widgets [skia @ wikipedia.org](https://en.wikipedia.org/wiki/Skia_Graphics_Engine) - used by google Chrome, Chrome OS, Chromium OS, Mozilla FireFox ∧ ThunderBird, Android, FireFox OS, LibreOffice, etc - supports several platform-dependent back-ends; including: - CPU-based software rasterization - GPU-accelerated openGL, openGL ES, Vulkan, and Metal - PDF output - SVG output ... partially implemented
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Monday, 31 May 2021 at 02:18:35 UTC, dangbinghoo wrote: don't sell it official, even semi-*. it had very bad platform support, dub support and ... Thanks for the clarification -from what I'm learning and seeing it seems a lot of the toolkits are dead or closer to.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote: Any comments are welcomed, even any comments regarding anyone experience with GUI development within D, no matter whether the answer would be relevant to my specific question seeking a choice or not. Along that tack, and as an informational tidbit, if you (any one, not just to someone) ever find yourself with a desperate need for a gui, but lack development tooling, there is always the messaging interface to GTK, GTK-Server, by Peter van Eerten, author of BaCon. gtk-server is GTK by proxy. Send messages, get GUIs. Not fast, but readily available to hundreds of programming languages. https://gtk-server.org/intro.html And for anyone interested in how some geniuses create programming environments, BaCon is a BASIC to C converter. Ships as a shell script, that reads itself to self-host a C codegen pass, to produce a native compiled bacon compiler. Self hosted as a shell script. *That alone should warrant a trophy.* And Peter has coded the shell script so that it can actually run as the converter compiler for BASIC, or convert itself to C to native bacon. http://basic-converter.org/ worthy of a read. Have good, make well, Blue
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Sunday, 30 May 2021 at 12:27:34 UTC, Siemargl wrote: On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote: Yes, I know this is a question lacking a straightforward answer. Requirements: - desktop only: forget about support for mobile tablets whatever You forget semi-official DWT https://forum.dlang.org/group/dwt don't sell it official, even semi-*. it had very bad platform support, dub support and ...
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 07:20:17 UTC, zjh wrote: On maybe try Gacui.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote: Yes, I know this is a question lacking a straightforward answer. Requirements: - desktop only: forget about support for mobile tablets whatever You forget semi-official DWT https://forum.dlang.org/group/dwt
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Sunday, 30 May 2021 at 12:09:22 UTC, cc wrote: This is overkill for any reasonable application, but I've always wanted to design a whole UI framework in OpenGL, just for the novelty of it. I always end up having to reinvent the wheel for UI elements in my projects anyway. https://streamable.com/2uvt4h There are many GUIS for OpenGL, but OpenGL is no longer supported on Macs AFAIK. I suggest using Skia instead: https://skia.org/ IIRC it is used in Chromium and Flutter.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
This is overkill for any reasonable application, but I've always wanted to design a whole UI framework in OpenGL, just for the novelty of it. I always end up having to reinvent the wheel for UI elements in my projects anyway. https://streamable.com/2uvt4h
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Sunday, 30 May 2021 at 07:03:38 UTC, Chris Piker wrote: On Thursday, 27 May 2021 at 07:00:32 UTC, Imperatorn wrote: I would like to recommend DlangUI [1], but we have tried now for months to get in contact with the owner of it (to take over development) and are getting no reponse. 1. https://github.com/buggins/dlangui Of the 107 forks of dlangui last seen on github, do you know if any contain more recent changes/features than the buggins original repo? If there's a quick way to check without paging through all of them I'm curious to know how it would be done. I'm using D for efficient server-side processes only, since at work we're heavily invested in Java for our end-user GUIs, but I'm curious about the state of D GUI toolkits nonetheless. I'm 100% positive you can do good ui using D, but, I'm not sure what I'd choose because of the fragmentation.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Sunday, 30 May 2021 at 07:03:38 UTC, Chris Piker wrote: On Thursday, 27 May 2021 at 07:00:32 UTC, Imperatorn wrote: I would like to recommend DlangUI [1], but we have tried now for months to get in contact with the owner of it (to take over development) and are getting no reponse. 1. https://github.com/buggins/dlangui Of the 107 forks of dlangui last seen on github, do you know if any contain more recent changes/features than the buggins original repo? If there's a quick way to check without paging through all of them I'm curious to know how it would be done. I'm using D for efficient server-side processes only, since at work we're heavily invested in Java for our end-user GUIs, but I'm curious about the state of D GUI toolkits nonetheless. "Insights -> Network" will show branching overview where you can clearly observe what changes were made on each fork https://github.com/buggins/dlangui/network DlangUI is somewhat primitive but I like it that way, one can quickly hack up pretty much any widget (including graphics) without too much hassle, just subclass suitable widget for the base, override few methods and start hacking. Of course I would like it to be real MVVM with view/data separation, visual/logical hierarchy separation, data bindings, UI automation and stuff. Maybe I'll fork it one day to make it that way, but at this moment I already have too much stuff to do.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 07:00:32 UTC, Imperatorn wrote: I would like to recommend DlangUI [1], but we have tried now for months to get in contact with the owner of it (to take over development) and are getting no reponse. 1. https://github.com/buggins/dlangui Of the 107 forks of dlangui last seen on github, do you know if any contain more recent changes/features than the buggins original repo? If there's a quick way to check without paging through all of them I'm curious to know how it would be done. I'm using D for efficient server-side processes only, since at work we're heavily invested in Java for our end-user GUIs, but I'm curious about the state of D GUI toolkits nonetheless.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Saturday, 29 May 2021 at 01:04:02 UTC, Marcone wrote: Win32Api + Metaprogramming? Yes.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Saturday, 29 May 2021 at 10:51:47 UTC, btiffin wrote: Will politely disagree about 1 or 2 can't do by themselves... Yeah, yeah they can. Well, I've actually done it. My minigui has its quirks I'm slowly working through, but it clearly isn't impossible.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
One additional toolkit, fltk, https://www.fltk.org/
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 16:49:41 UTC, Dejan Lekic wrote: [...] I humbly believe the most complete one is GtKD. https://gtkdcoding.com/ https://gtkd.org We all wish there was a STANDARD D GUI library out there, but that is a huge effort one or two individuals can't do by themselves (that is why all such efforts failed in the past)... Agree about GTK and completeness (though D explorations still counted under 100 hours). Will politely disagree about 1 or 2 can't do by themselves... Yeah, yeah they can. :-) Magic people. Ok, people with skills so advanced (relative to the rest of us) as to be indistinguishable from magic. REBOL, Carl on REBOL dialects for layout with a partner coding view graphic drivers. For example. It can happen, and does happen. Super star doers. Rare, yes. Happens. There is hope. And yes, agree, lots of fail, *but not all, fail*. Have good, make well, Blue
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 17:04:07 UTC, Alain De Vos wrote: Let's also not forget other languages have problems with gui-toolkits. For instance, gtk-ada binding has memory leaks. gtk-crystal binding is broken. I would like to see a binding to wxwidgets which is a very cool toolkit. It seems to me the bindings are the symptoms and not the causes: the problem, to my humble opinion, is that for whatever reasons, we have a **lot** of toolkits trying to reinvent powder over and over. In Windows/Mac there's no problem since more-or-less they have standard controls, and anyone not using them is because they bypass them pursuing multi-platform support. In the nixes is more complicated since there were never standard/unified controls/guidelines. There are people who thinks diversity is a plus and there others stating standardization is the way forward. Like it or not, that is we have on the nixes.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Saturday, 29 May 2021 at 00:57:51 UTC, Marcone wrote: Win32Api. You can use resEdit to create your resource GUI. Work only for Windows. Here is my program created with Dlang and Win32Api GUI: https://sourceforge.net/projects/direct-http-tunnel/ Thanks a lot for your info :) ! I want you to know that I am replying to myself on the first post summarizing what I already learned researching the subject starting with the tips provided by you as well as anyone else that replied to my post. Please, if you want and have the time, check my last post and let me know anything I got wrong. I do have a LOT of experience coding on the Windows platform, I have no less than 20 years at least, since Windows NT 1.0 precisely, I do feel at ease with Win32 and COM. The problem right now is that, for whatever reasons, I stopped being coding Microsoft-centric solutions 5 or-so years ago. I am on archlinux right now and have a few boxes running freeBSD and/or DragonFlyBSD. I do not plan to go back to Microsoft. Obviously, I miss a lot of things; but mainly, SQL-Server, everything XML-related which is rock-solid on the Microsoft side, and last but not least, PowerShell, which I love by design but regret the way that was implemented, specially since the 2.0 release, it ended really bloated, but the concept, rocks. I started to left ship with MicroSoft in the Vista ~ Windows 8 time frame and left definitely on Windows 9/10. My last boxes still run Windows Server 2008 R2 with the newer versions of SQL-Server. Ballmer destroyed Microsoft as quality code. The userspace since Vista was terrible -and don't get me started on the Metro UI.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Saturday, 29 May 2021 at 00:52:10 UTC, someone wrote: sciter, of course. https://sciter.com/ I've also been looking for `good GUI`. Now, I just find `WTL`. I don't like `QT`. It's too big. I don't like `LGPL`. You can't link statically. If you want to bind, I think `wxwidget` is good. `Sciter's` problem is that it doesn't open source. Their binding(`wx/sciter`) is `out of date`. There is also a `beamui`.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
maybe you can try nana. nanapro,I just success compile.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Friday, 28 May 2021 at 17:04:15 UTC, Vinod K Chandran wrote:
On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote:
I am learning D by writing a Windows only GUI library. It is
taking too much time for me since, I am writing some stuff and
then happen to learn some new things about it and re-writing
it.Anyhow, so far so good. This is the code now.
```d
import winglib ;
import std.stdio : log = writeln;
void main() {
auto frm = new Window() ;
frm.text = "Learning D By Writing D";
// C = Control class. Window is derived from Control
// E = EventArgs.
frm.onMouseHover = (c, e) => log("Mouse is now on ", e.x, ",
", e.y);
frm.onMouseLeave = (c, e) => log("Mouse leaved from window") ;
frm.onKeyDown = (c, e) => log(e.keyCode, " key is pressed");
frm.create() ;
auto btn = new Button(frm) ;
btn.font.name = "Calibri" ;
btn.width = 150 ;
btn.text = "DMD Or LDC" ;
btn.font.size = 14 ;
btn.create() ;
frm.show() ;
}
```
I am slowly adding more features to this. Till now, Window &
Button are completed.
Win32Api + Metaprogramming?
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Friday, 28 May 2021 at 01:44:24 UTC, zjh wrote: maybe you can try nana. nana ? can you elaborate please ?
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 16:49:41 UTC, Dejan Lekic wrote: I humbly believe the most complete one is GtKD. https://gtkdcoding.com/ https://gtkd.org We all wish there was a STANDARD D GUI library out there, but that is a huge effort one or two individuals can't do by themselves (that is why all such efforts failed in the past)... Thanks a lot for your info :) ! I want you to know that I am replying to myself on the first post summarizing what I already learned researching the subject starting with the tips provided by you as well as anyone else that replied to my post. Please, if you want and have the time, check my last post and let me know anything I got wrong. As I stated in the original post and feel at ease with GTK+ 2.# and not so with the GTK+ 3.#. That's is why I choose MATE as my desktop environment which in reality is a stripped down version of MATE itself: the widget that rocks is the MATE panel, everything else is questionable, not to mention really bad software like Atril (the PDF viewer). I do run MATE on archlinux right now and built the package myself setting aside everything I do not want/use. Do you know if GTKD will be kepping support for the 2.# branch, or, if they plan to deprecate it moving ahead ?
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote: Yes, I know this is a question lacking a straightforward answer. Requirements: [...] Win32Api. You can use resEdit to create your resource GUI. Work only for Windows. Here is my program created with Dlang and Win32Api GUI: https://sourceforge.net/projects/direct-http-tunnel/
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 09:11:44 UTC, Виталий Фадеев wrote: sciter, of course. https://sciter.com/ Or write Dlang alternative. Thanks a lot for your info :) ! I want you to know that I am replying to myself on the first post summarizing what I already learned researching the subject starting with the tips provided by you as well as anyone else that replied to my post. Please, if you want and have the time, check my last post and let me know anything I got wrong. I need to research sciter a bit more: a first sight is not what I am looking for, it seems is has something like a browser rendering engine to apply what you define in a resource file, if so, I guess it will be very slow compared with any native and/or quasi-native toolkit. Give me more time and I'll keep you posted.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 09:01:04 UTC, btiffin wrote: libagar is a nice little framework. But, it's C still (and Ada, Perl, COBOL), not D yet. Will see how it goes. Thanks a lot for your info :) ! I want you to know that I am replying to myself on the first post summarizing what I already learned researching the subject starting with the tips provided by you as well as anyone else that replied to my post. Please, if you want and have the time, check my last post and let me know anything I got wrong.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 07:20:17 UTC, zjh wrote: I have download FOX.and success compile. I think it is very good.small and beauty. Thanks a lot for your info :) ! I want you to know that I am replying to myself on the first post summarizing what I already learned researching the subject starting with the tips provided by you as well as anyone else that replied to my post. Please, if you want and have the time, check my last post and let me know anything I got wrong.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 07:00:32 UTC, Imperatorn wrote: I would like to recommend DlangUI [1], but we have tried now for months to get in contact with the owner of it (to take over development) and are getting no reponse. Thanks a lot for your info :) ! I want you to know that I am replying to myself on the first post summarizing what I already learned researching the subject starting with the tips provided by you as well as anyone else that replied to my post. Please, if you want and have the time, check my last post and let me know anything I got wrong.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 02:55:14 UTC, Adam D. Ruppe wrote: http://arsdnet.net/minigui-linux.png http://arsdnet.net/minigui-sprite.png Thanks a lot for your info :) ! I want you to know that I am replying to myself on the first post summarizing what I already learned researching the subject starting with the tips provided by you as well as anyone else that replied to my post. Please, if you want and have the time, check my last post and let me know anything I got wrong.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote: Any comments are welcomed, even any comments regarding anyone experience with GUI development within D, no matter whether the answer would be relevant to my specific question seeking a choice or not. First and foremost, thanks everybody for your replies :) ! I didn't know some of the toolkits you advised me to try even existed. There was a lot of info for me to digest before starting answering you on some of the specifics and/or personal experience with them, so, I did my homework and make the following summary (mainly relevant to my requirements) to organize my thoughts so I could make a roadmap to start selecting/discarding toolkits, and please, let me know anything I got wrong and/or point me to anything that is plainly wrong in the following summary: - Microsoft [MFC](https://en.wikipedia.org/wiki/Microsoft_Foundation_Class_Library) is a Microsoft Visual C++ wrapper around the Windows API - Microsoft [Windows Forms](https://en.wikipedia.org/wiki/Windows_Forms) for the net framework (not a Windows API wrapper) - Microsoft [WPL](https://en.wikipedia.org/wiki/Windows_Presentation_Foundation) (aka Windows Presentation Foundation) for the net framework 3.0 using XAML or any CLR language - Microsoft [WinUI # 1](https://docs.microsoft.com/windows/apps/winui/) - Microsoft [WinUI # 2](https://docs.microsoft.com/windows/apps/winui/winui2/release-notes/) for UWP XAML apps - Microsoft [WinUI # 3](https://docs.microsoft.com/windows/apps/winui/winui3/release-notes/) for UWP XAML / Win32 apps (aka Project Reunion) - Gnome [GNUstep](https://en.wikipedia.org/wiki/GNUstep) for Objective-C - Apple [Cocoa](https://en.wikipedia.org/wiki/Cocoa_(API)) for Objective-C - [MOTIF](https://en.wikipedia.org/wiki/Motif_(software)) for C is a legacy UNIX toolkit - [libagar](http://libagar.org/) (aka agar) for (industry-standard ANSI X3.159-1989) C: [documentation](http://libagar.org/docs) for [1.6.0](http://libagar.org/mdoc.cgi?man=AG_Intro.3), [screenshots](http://libagar.org/screenshots.html) - supports texture and GPU acceleration wherever available - supports linux/freeBSD/dragonFlyBSD (at least) - [Fox](http://www.fox-toolkit.org/home.html) for C++: [overview](http://www.fox-toolkit.org/goals.html), plain [documentation](http://www.fox-toolkit.org/doc.html), [FAQ](http://www.fox-toolkit.org/faq.html), and [screenshots](http://www.fox-toolkit.org/screenshots.html) - relies only on core system facilities and **does not wrap** native GUI libraries or toolkits - supports linux/freeBSD (at least) - used by the xfe file manager app - [wxWidgets](https://en.wikipedia.org/wiki/WxWidgets) (former wxWindows) for C++: [overview](https://docs.wxwidgets.org/3.0/page_introduction.html), excellent plain [documentation](https://docs.wxwidgets.org/3.0/), [tutorials](https://docs.wxwidgets.org/3.0/page_topics.html); eg: [hello world app](https://docs.wxwidgets.org/3.0/overview_helloworld.html) - supports native platform controls wherever possible - supports UniCode: (https://docs.wxwidgets.org/3.0/overview_unicode.html)overview - wxMSW is the native port for Microsoft Windows - wxGTK2 port supporting GTK+ 2.# ≥ 2.6 - wxGTK3 port supporting GTK+ 3.# - first-impressions: fully-alive - [arsd](http://dpldocs.info/experimental-docs/arsd.html#desktop-gui): [simpledisplay](http://dpldocs.info/experimental-docs/arsd.simpledisplay.html) → [minigui](http://dpldocs.info/experimental-docs/arsd.minigui.html) for D: plain documentation - simpleDisplay provides basic cross-platform GUI-related functionality: creating windows, drawing on them, working with the clipboard, timers, openGL, and more; but, **does not provide** high-level GUI widgets - simpleDisplay does not have any dependencies outside the OS and color.d - simpleDisplay should support UniCode and i18n internationalization since its written in D to begin with (my assumption) - miniGUI primary goal is to be useful without being large and complicated (like GTK and/or QT) and it isn't hugely concerned with appearance - miniGUI keeps it simple on linux: some controls can be customized with CSS-inspired Widget.Style classes - miniGUI supports the native controls/themes on Windows - miniGUI supports creating widget trees at runtime from XML with arsd.minigui_xml - miniGUI requirements are arsd.simpledisplay and arsd.color dependencies on which it is built: nothing more - miniGUI had mostly additive changes or bug fixes since its inception until 05-2021 - miniGUI should support UniCode and i18n internationalization since its written in D to begin with (my assumption) - [dlangUI](https://github.com/buggins/dlangui) for D: [documentation](http://buggins.github.io/dlangui/ddox/), [tutorials](https://github.com/buggins/dlangui/wiki), and [screenshots](http://buggins.github.io/dlangui/screenshots.html) - it is a
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote:
I am learning D by writing a Windows only GUI library. It is
taking too much time for me since, I am writing some stuff and
then happen to learn some new things about it and re-writing
it.Anyhow, so far so good. This is the code now.
```d
import winglib ;
import std.stdio : log = writeln;
void main() {
auto frm = new Window() ;
frm.text = "Learning D By Writing D";
// C = Control class. Window is derived from Control
// E = EventArgs.
frm.onMouseHover = (c, e) => log("Mouse is now on ", e.x, ", ",
e.y);
frm.onMouseLeave = (c, e) => log("Mouse leaved from window") ;
frm.onKeyDown = (c, e) => log(e.keyCode, " key is pressed");
frm.create() ;
auto btn = new Button(frm) ;
btn.font.name = "Calibri" ;
btn.width = 150 ;
btn.text = "DMD Or LDC" ;
btn.font.size = 14 ;
btn.create() ;
frm.show() ;
}
```
I am slowly adding more features to this. Till now, Window &
Button are completed.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 18:57:32 UTC, Alain De Vos wrote: I think dlangui is a dead monkey. Nah, it's ok
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Friday, 28 May 2021 at 00:07:41 UTC, zjh wrote: On Friday, maybe you can try nana.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Friday, 28 May 2021 at 00:05:36 UTC, zjh wrote: If there is a binding of wxWidgets. then is good.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 17:04:07 UTC, Alain De Vos wrote: Let's +10
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
I think dlangui is a dead monkey.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
Let's also not forget other languages have problems with gui-toolkits. For instance, gtk-ada binding has memory leaks. gtk-crystal binding is broken. I would like to see a binding to wxwidgets which is a very cool toolkit.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote: Yes, I know this is a question lacking a straightforward answer. Requirements: [...] I humbly believe the most complete one is GtKD. https://gtkdcoding.com/ https://gtkd.org We all wish there was a STANDARD D GUI library out there, but that is a huge effort one or two individuals can't do by themselves (that is why all such efforts failed in the past)...
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
I very succefully used tkd and gtkd, d binding to tk and gtk. Can someone guide me to using fox or fltk ?
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote: Yes, I know this is a question lacking a straightforward answer. Requirements: [...] sciter, of course. https://sciter.com/ Or write Dlang alternative.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote: Yes, I know this is a question lacking a straightforward answer. I'm only on a third serious with D day, but I want to take a kick at wrapping libAgar now. libagar is a nice little framework. But, it's C still (and Ada, Perl, COBOL), not D yet. Will see how it goes. Very cross platform, the Uniike (unixlike, sans tm) systems, nintendo, c64, but that's microagar. Developed on a BSD system. http://libagar.org/
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote: Yes, I have download FOX.and success compile. I think it is very good.small and beauty.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 04:01:31 UTC, someone wrote: On Thursday, 27 May 2021 at 02:55:14 UTC, Adam D. Ruppe wrote: [...] Crystal clear. On Thursday, 27 May 2021 at 02:55:14 UTC, Adam D. Ruppe wrote: [...] No. It doesn't amuse me at all. X11 was/is a wonder in many respects. The problem with X11 nowadays is that it is getting abandoned. I don't recall the name right now, but I read an extensive article the past year (or the other one) in which its primary maintainer claimed it lost interest in it (or whatever) and the project lacks the resources to get well maintained and so and so. So the writing is on the wall. I think Wayland started its project seeking tear-less windows but evolved a far-cry from there. But like it or not, for the worst or the better, everything will be Wayland-centric/dependent a few years from now, relegating X11 to a niche. That's my two cents, which can be far away from reality, of course. [...] I would like to recommend DlangUI [1], but we have tried now for months to get in contact with the owner of it (to take over development) and are getting no reponse. 1. https://github.com/buggins/dlangui
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 02:55:14 UTC, Adam D. Ruppe wrote: Well, you don't strictly have to use gtkd, you can always just extern(C) define the stuff yourself (or only use them from gtkd's generated files) and call them. But if you do use gtk, I'd suggest just sticking to the gtkd wrapper. Crystal clear. On Thursday, 27 May 2021 at 02:55:14 UTC, Adam D. Ruppe wrote: But I hate gtk so I made my own thing from scratch on nothing but X which might amuse you. (I loathe that useless wayland trash and will never support it. X is so much better.) No. It doesn't amuse me at all. X11 was/is a wonder in many respects. The problem with X11 nowadays is that it is getting abandoned. I don't recall the name right now, but I read an extensive article the past year (or the other one) in which its primary maintainer claimed it lost interest in it (or whatever) and the project lacks the resources to get well maintained and so and so. So the writing is on the wall. I think Wayland started its project seeking tear-less windows but evolved a far-cry from there. But like it or not, for the worst or the better, everything will be Wayland-centric/dependent a few years from now, relegating X11 to a niche. That's my two cents, which can be far away from reality, of course. On Thursday, 27 May 2021 at 02:55:14 UTC, Adam D. Ruppe wrote: But since I also think css is bloated I'm just putting hooks in the core so it is an optional feature, just like the xml and script stuff. Turns out that was easier than fixing text bugs. And besides people love their dark modes lol. CSS was/is an excellent tech for rendering web pages while splitting data and style, at least, valid until CSS1. The latter CSS version are bloated to the bone. They were developed for the ad industry and not for viewing documents which is what the net was invented for to begin with. I think if early on the reference and commercial webs were developed separately we would end spared the XHMTL->HTML4 wars and everything related. CSS to render a desktop is overkill, no matter what. Gnome2 with all its shortcomings was snappy as hell. On Thursday, 27 May 2021 at 02:55:14 UTC, Adam D. Ruppe wrote: Anyway if you can stand gtk, gtkd really isn't bad and its text widget works. Just don't use the file dialog lololol. The file dialog is one of the worse things indeed. Let me clarify a bit: I am not against innovation and/or change, quite the opposite, I love things improving all the time; what I can't bear is change for the sake of change, change because the developer/s is/are bored and this/that is trendy and sooo cool right now, engineering has a de-facto motto: if it works, don't fixit ! That being said, I think GUI design reached a climax between the Windows 95/98 and Windows XP era, everything that came afterward was, mainly, downhill. What Windows got right on that time-frame was the GUI, furthermore, the consistency of the GUI system-wide, all programs (errr, what now are called apps) behaved and looked the same way, that was the goal, you learned one app, you learned them all, nothing deviated from the GUI development guidelines, and what deviated was considered subpar. Even the documentation (excellent Microsoft manuals on dead-tree media, what-else) on GUI development, the what and what not to do was excellent. Microsoft got that right. After Windows XP came Vista, and from then on, it was primarily Microsoft that demolished all the advise published so far by itself -those were the Steve Ballmer years (developers ! developers ! developers !) and clearly marked a point of inflection. The early 2000s brought us app skins, and with it, everything looked (and started to behave) differently, ending with monsters like Cannonical Unity GUI, and meanwhile, destroying perfectly working desktops such as gnome 2 (the epitome of user friendly design in linux in my view) with gnome 3, all justified on the basis that mobile/touch should be integrated to the same base instead of developing something specific for it. That left us with CSS rendering our desktops ala-browser-engines and everything evolved from snappy to quite-a-few-seconds-lag to open even a bare window. End of rant. Excuse me. But I think the above clarifies what I am searching for for a GUI toolkit in D. After all, I landed on D for its speed besides its cleanliness/power/features. On Thursday, 27 May 2021 at 02:55:14 UTC, Adam D. Ruppe wrote: My minigui is a thing of beauty. Behold: I'll probably check it out tomorrow since I am going to bed right now. Thanks for your detailed response and for taking your time to advise me. I really appreciate that !
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote: - like a simple classical UI: favored over any modern one: My minigui is a thing of beauty. Behold: http://arsdnet.net/minigui-linux.png http://arsdnet.net/minigui-sprite.png its docs: http://dpldocs.info/experimental-docs/arsd.minigui.html It is quick to open and quick to compile (the whole thing is contained in just three source file that build from scratch in about a quarter second). Pity is sucks. More below. - using the GTK toolkit within D requires the GTKD binding library. Well, you don't strictly have to use gtkd, you can always just extern(C) define the stuff yourself (or only use them from gtkd's generated files) and call them. But if you do use gtk, I'd suggest just sticking to the gtkd wrapper. But I hate gtk so I made my own thing from scratch on nothing but X which might amuse you. (I loathe that useless wayland trash and will never support it. X is so much better.) However my text edit widget sucks. It barely works. Really slow and buggy. I've been slowly trying to find the time to rewrite it but wow the text edit is harder than literally everything else combined and since I have so many other things to do it still sucks. I have been doing a bit of a 2.0 rewrite lately (recent blogs: http://dpldocs.info/this-week-in-d/Blog.Posted_2021_05_03.html and http://dpldocs.info/this-week-in-d/Blog.Posted_2021_05_17.html describe it, though the doc link from before has info too) So I probably wouldn't seriously recommend my thing right now on Linux. (On Windows, it is fine - it just uses the OS-provided control. But you don't care about Windows so that's irrelevant... unless you wanna wine.) Ironically the biggest thing I changed in the recent 2.0 work is a style delegate that makes it possible to do some kind of css thing. But since I also think css is bloated I'm just putting hooks in the core so it is an optional feature, just like the xml and script stuff. Turns out that was easier than fixing text bugs. And besides people love their dark modes lol. Anyway if you can stand gtk, gtkd really isn't bad and its text widget works. Just don't use the file dialog lololol.
wanting to try a GUI toolkit: needing some advice on which one to choose
Yes, I know this is a question lacking a straightforward answer. Requirements: - desktop only: forget about support for mobile tablets whatever - wide cross-platform support not needed at all: linux and/or some BSD distro like FreeBSD/DragonFlyBSD and that's all; don't care at all for the Windows platform. - Wayland support will be a plus. - HiDPI support will be a plus. What I like/dislike: - like a simple classical UI: favored over any modern one: - eg: my daily-driver workstation is running the MATE desktop configured as unobtrusive and minimal as possible and I am quite happy with it; needless to say I hate modern gnome and KDE desktops not to mention unity and family. - eg: hate the dconf-editor controls styles (GTK). - eg: like ClawsMail [https://www.claws-mail.org/] classic style. - eg: currently using the xfe file manager [http://roland65.free.fr/xfe/] (which follows the early Windows File Explorer design) which is written in C++ and is built against the minimal Fox GUI toolkit [http://fox-toolkit.org/]. - like fast native compiled fast responsive minimal apps; say, what used to be the common way back on the 90s; eg: Windows forms over COM ... fast instantly-opening windows (providing the program itself do not make them lag of course). - dislike the way modern toolkits like gnome/KDE rely on CSS to render the controls making the toolkits heavy on resources; prefer more traditional ones, but this is not a requirement, it is my preference. What I know so far: - I assume using the FOX library will be more or less a straighforward process since it is written in C++; ie: no bindings needed at all ... am I correct ? - using the GTK toolkit within D requires the GTKD binding library. Any comments are welcomed, even any comments regarding anyone experience with GUI development within D, no matter whether the answer would be relevant to my specific question seeking a choice or not.
