On 5/20/13, Adam Wilson <flybo...@gmail.com> wrote: > * There is a deep-seated distrust of any toolkit that does not use the OS > Native UI widgets.
That's a shame. If you go native you'll have the "look and feel", but you'll have X times the work where X is the number of platforms supported. Also, each platform has its own bugs, so you'd have to write a lot of workaround code as well (e.g. wxWidgets is full of win32 workarounds). Doing it non-native slows you down at first, but it gives you a lot more control on how you can render things. You can add a feature without having to worry on how to port the feature to other platforms. And finally, you can simulate the native windowing environment. Just to mention this, we already have native libraries (and written in D without wrapping C++ libs) such as DGUI, DFL, DWT. I hardly find them successful, they get the occasional pull request, but otherwise they seem to lack any sort of team effort or going-forward schedule. So I'd say going "native" has already been a failed experiment (take that with a huge grain of salt, it's just my personal viewpoint :) ). > * Nobody believes that we can do it, you'll hear a lot of moaning about > how much work it is. My reply to that is: And Linux is such a piece of > cake right? It's only the most widely used kernel on the planet. I think the lesson with Linux is that one person initially did a lot of heavy lifting, and then others joined in. I doubt it would work as it did if instead Linus opened a thread asking for a team of developers to create a new OS from scratch. Anyway, there's no doubt a D GUI would be a huge undertaking. There would almost certainly be a lot of rewriting involved. It's very easy to make mistakes early on and hardcode something, only later to realize it's way too brittle so it requires a rewrite. If the system is modular enough then the rewrites become less painful. And if the system is properly unit tested then regressions become less likely, and this is important. >From what I've seen when a codebase becomes large enough, what inevitably happens is people stop hacking on the codebase almost entirely. It's usually because the codebase is huge and not modular, or undocumented, or not tested, or doesn't have any sort of schedule on the work that needs to be done. I have zero doubt that we have the know-how or hacking ability to actually work and solve GUI problems in D, but I have big doubts that we would ever have leadership that would make sure we have a proper schedule and todo list, proper discussions, the guts to say "no" to features, etc. It's just not going to work if people randomly create pull requests with some code they thought would be nice to include in a GUI library. So to actually do it, I think we need: 1) A "core" for a GUI library written in D that people can start hacking on (meaning you can create windows, and draw in a pixel buffer, capture device input, all platform-independent), and 2) Solid leadership. I'd say #2 is more important than #1, because #1 is something many people can do, and #2 is the really hard bit.
