On 2013-08-13 15:23, Paul Z. Barsan wrote:
> Hello everyone,

Oh, another one of these threads...

> These days I've been searching for a cross-platform IDE for D and I
> found out that there aren't any viable standalone options. After a few
> clicks, I've ran over this topic:
> http://forum.dlang.org/thread/astrlgbptrlvcdicqxux@forum.dlang.org and
> it wasn't a surprise to see there are other people searching for the
> very same thing.One of the reasons for the absence of such IDEs is that
> there are no widget toolkits written in D except DWT, but some people
> are complaining about DWT for being a clone of SWT and that clients will
> want DWT to be in sync with SWT since SWT is a "marketing paradigm". As
> such, I want to embark on a long journey of writing a new widget toolkit
> from scratch.
>
> Jacob Carlborg:
> * You would still need to some graphics primitives. Do you want to
> implement them yourself as well? I mean, you have to draw the line
> somewhere. There's always a layer beneath you that you rely on, if
> you're not doing embedded or similar.
> * you want a non-native toolkit.
> * primitives would be implemented on top of OpenGL or DirectX. OpenGL is
> implemented in the graphics drivers, don't know how it works with DirectX.

This is very out of context and not what I think, I just responded to a post.

> Think of this topic as writing letters to Santa, so: what say you ?

All I can say that creating a new toolkit from scratch is a huge amount of work.

-- 
/Jacob Carlborg

On Tuesday, 13 August 2013 at 13:23:07 UTC, Paul Z. Barsan wrote:
>
> Think of this topic as writing letters to Santa, so: what say you ?

Aww, you've gone and reminded me of Hybrid [1] again.  D1/Tango IIRC, but I think it had good potential.  No lazy updates, though, so probably not as useful for ordinary desktop applications.

...I wonder if Tomasz will ever come back?

-Wyatt

[1] http://h3.gd/code/hybrid/wiki/

On 2013-08-13 08:23, Paul Z. Barsan wrote:
> Now let me complete these notes:
>
> * I think that porting an anonymous toolkit to D will do more harm
> than good because if the original project was lacking some features
> then clients will think that the ported version lacks them as well.
> If we want to take this route then, besides Harmonia and FOX tk, we
> might borrow things from FLTK(Fast Light Toolkit) * If the projects
> starts from zero, with its own design and is "shiny new" then people
> will be more attracted. * Even if we don't port a toolkit we can
> still get inspired to see how they interact with the underlying
> system. For example, we can take a look over the SDL way of handling
> input. * for drawing primitives we can use Cairo(curently used by
> GTK) or libX11 on linux and Directx on windows.Bindings for cairo and
> libX11 are provided by Deimos. I'm not sure if we can use OpenGL
> because it requires a rendering window or it renders in fullscreen
> mode.That rendering window can be provided by other toolkits but I
> don't think we want to depend on them. The OS window manager(xorg on
> linux) needs to keep track of the things it draws on its root window
> or surface and must be aware what to clean-up after you close your
> program. So the layer beneath this widget toolkit on Linux would be
> X(libX11). * XAML is being developed by Microsoft and XUL by
> Mozzilla. I think XUL is a better choice for a markup language and
> more friendlier with an open source toolkit. It would be pretty nice
> if we can make the GuiParser and abstract class and provide an
> implementation for XUL because that will allow us to write an
> implementation for the QML(Qt) aswell or other flavors of layout and
> style files. * If we want the project to scale up nicely then we
> should do things by the book. That is doing some research to see what
> technologies are involved, what the client programmers want(this
> thread) and then write some specs. * After we have the specs then we
> can start designing the toolkit using UML diagrams such that we will
> end up with a clean API and avoid future re-factoring. For UML
> designs, I recommend this web app https://www.draw.io/ which saves
> its files in XML format and we can store them in the git repository.
> * Only after we have a good design we will begin the actual coding. *
> there is this 3D modelling tool called Blender which has a
> modern-looking UI. People have been wondering if that GUI can be used
> as a library and the answer is no because the gui is harcoded into
> Blender. If our default ui look resembles that one(not necessarily
> identical) then we will gain more clients.Maybe we can even get
> support from its huge community of artists. Take a look:
> http://www.blender.org/features-gallery/features/ * this toolkit can
> complement DWT because DWT will provide native look and this one will
> provide the same look on all platforms.

i like your ideas, especially the the clear top-down strategy. if the vision, i.e. design/API and roadmap is clear, and the documentation is good from the very beginning (something i want to stress particularly), then it could develop some dynamic.

to ppl shrugging it off with the arguments that it is too much work or has been tried before: well, these arguments cancel each other out. previous projects have been very promising and accomplished a lot, enough for a kickstart. in theory - as it did not happen. and why?
i think their biggest problem was that they were basically one man projects, not community projects. they did not outline design goals, open issues, roadmaps, - heck they did not even provide a sufficient documentation for using them. so they more or less died once the original maintainer lost interest. i often think what nice a D GUI package we would have by now if those 3 or 4 ppl running the previous attempts would have worked together. i played a bit with DFL some years ago and was quite impressed (it even had a GUI designer!) - but only to a certain point. i wanted multi platform and being only the occasional programmer, i need a good, detailed documentation. so back than i decided to not use D altogether as a GUI was a must for my application. (the core procedures being in C i still hope to move it to D at one point though)

having a D-simple and D-safe pure D GUI is worth a try and would boost D's popularity. if it takes 2 years before it is usable, so what. it would not slow down improving D in other aspects as i think a GUI development would motivate a different set of ppl to contribute, i.e. would not withdraw current phobos and compiler devs.


just my 2c,

det  

The problem is that the scale of a project like this literally stops people from starting. Couple this with the fact that a non existent project doesn't attract any developers and you've got negative feelings from the start.

I wouldn't worry about that though!

I think the benefits of a project like this far outweigh any initial worries about scale. Personally, i would love for there to be a D GUI toolkit that is available for all D supported platforms. It would be awesome being able to create D GUI applications in a straight forward way and something which i truly think would attract many more developers to D. IMHO It's one of the two big attractors* to using any language, i.e. an easy to use GUI toolkit. I honestly think that's why C# and Python caught on as quickly as they did.

If work is started on a project like this and shows promise, i wouldn't be adverse to contributing.

Keep this quote in mind:

"Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large. If you do, you'll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision. So start small, and think about the details. Don't think about some big picture and fancy design. If it doesn't solve some fairly immediate need, it's almost certainly over-designed. And don't expect people to jump in and help you. That's not how these things work. You need to get something half-way useful first, and then others will say "hey, that almost works for me", and they'll get involved in the project."

Linus Torvalds - Linux Times (2004-10-25)
http://web.archive.org/web/20050404020308/http://www.linuxtimes.net/modules.php?name=News&file=article&sid=145

SO who will be the first to start? ;)

* The other is games programming capability but we'll leave discussing building a full opengl games programming framework for another thread. ;)

On Tuesday, 13 August 2013 at 17:40:05 UTC, Gary Willoughby wrote:
clip
>
> I think the benefits of a project like this far outweigh any initial worries about scale. Personally, i would love for there to be a D GUI toolkit that is available for all D supported platforms. It would be awesome being able to create D GUI applications in a straight forward way and something which i truly think would attract many more developers to D. IMHO It's one of the two big attractors* to using any language, i.e. an easy to use GUI toolkit. I honestly think that's why C# and Python caught on as quickly as they did.
>
clip


What is the Python GUI toolkit you speak of?

On Tue, 2013-08-13 at 19:40 +0200, Gary Willoughby wrote: […]
> truly think would attract many more developers to D. IMHO It's one of the two big attractors* to using any language, i.e. an easy to use GUI toolkit. I honestly think that's why C# and Python caught on as quickly as they did.

Python has no widget set. It wraps and ships tk by default. There are wrappers for Qt, wxWidgets, GTK, and others. So the Python message is "use other people's widget sets".

Easy graphics, both UI and data visualization, is a huge attractor. cf. SciPy (Matplotlib), PyGame, etc.

[…]
> Keep this quote in mind:
> 
> "Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large. If you do, you'll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision. So start small, and think about the details. Don't think about some big picture and fancy design. If it doesn't solve some fairly immediate need, it's almost certainly over-designed. And don't expect people to jump in and help you. That's not how these things work. You need to get something half-way useful first, and then others will say "hey, that almost works for me", and they'll get involved in the project."
> 
> Linus Torvalds - Linux Times (2004-10-25) http://web.archive.org/web/20050404020308/http://www.linuxtimes.net/modules.php?name=News&file=article&sid=145

This is basically a reaffirmation of John Gall's observation from 1975 "General systemantics, an essay on how systems work, and especially how they fail...":

        "A complex system that works is invariably found to have evolved
        from a simple system that worked. A complex system designed from
        scratch never works and cannot be patched up to make it work.
        You have to start over, beginning with a working simple system."

[…]

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tuesday, 13 August 2013 at 17:49:21 UTC, Craig Dillabaugh wrote:
> What is the Python GUI toolkit you speak of?

As Russel alluded to it was Tkinter i was referring to. It has been bundled with Python for years (since the beginning?) and it's one of the first GUI toolkits i used years ago. It's very very basic but it's ideal for fast prototypes and just for putting something on a window. I have seen people use it for simple editors to scientific work for plotting data, etc. It's not how awesome it was but how easy it was to use and get results.

http://wiki.python.org/moin/TkInter

On Tuesday, 13 August 2013 at 18:11:11 UTC, Gary Willoughby wrote:
> I have seen people use it for simple editors to scientific work for plotting data, etc. It's not how awesome it was but how easy it was to use and get results.

e.g. Here's a small open source project i created 12+ years ago to provide a UI for another small project all using Tkinter:

http://nathrach.republicofnewhome.org/mappergui.html

It was ridiculously easy to use and if it hadn't been so i probably wouldn't of even tried Python. I was into my RPG games and wanted maps! :) (btw the code is horrible so don't bother looking. he he..)

On 8/13/13, Gary Willoughby <dev@nomad.so> wrote:
> e.g. Here's a small open source project i created 12+ years ago to provide a UI for another small project all using Tkinter:
>
> http://nathrach.republicofnewhome.org/mappergui.html

Small note: I'm working on an updated D wrapper around Tk v8.6. There was a project like this called Dkinter, but it got abandoned 5 years ago (and was largely incomplete), so I've started my own wrappping effort. I think an alpha version should be ready in ~10 weeks, maybe more (I hate to guess time schedules like this, and I'm rather busy these days, but the progress is steady).

Maybe a port of Fltk library? Small and good enough.