On Thursday, 2 July 2020 at 03:07:06 UTC, Steven Schveighoffer wrote:
> This is pretty interesting and exciting news.
> [...]
> They are going to create their own UI toolkit.
>
> That's.... a lot of work.

Whatever the language, I suppose that would still be a lot of work.

That could be the project D needs to gain more traction! I think that's great news. I hope it goes well for their team. It will provide some valuable feedback to the D community. :)

On Thursday, 2 July 2020 at 03:07:06 UTC, Steven Schveighoffer wrote:
> On 7/1/20 10:31 PM, bachmeier wrote:
>> On Sunday, 1 September 2019 at 18:57:07 UTC, Kamran wrote:

>
> The "Glimpse NX" will be "a completely new permissively-licensed image editing program that is being written from the ground up with the D programming language and a bespoke cross-platform UI toolkit." (https://glimpse-editor.github.io/)
>
> According to this: https://github.com/glimpse-editor/Glimpse/issues/69
>
> They are going to create their own UI toolkit.
>
> That's.... a lot of work

And pretty cool to see it being D :)

On Tuesday, 3 September 2019 at 16:24:11 UTC, Russel Winder wrote:
> On Sun, 2019-09-01 at 20:23 +0000, Eugene Wissner via Digitalmars-d wrote: […]
>> 
> Vala is looking like a dead, or at least stalled for many years, project. Clearly it may revive, but at this stage it seems unlikely.

Oh how wrong your are now. Ha ha. See valadoc.org and the vala Gitlab repo.

You never know.

Not saying Glimpse should be vala, just saying vala is not going anywhere. Its all about convenience. Some people want the capabilities and stack in C just not the outdated conventions.

On Thursday, 2 July 2020 at 03:07:06 UTC, Steven Schveighoffer wrote:
> They are going to create their own UI toolkit.
>
> That's.... a lot of work.
>
> -Steve

On the other hand, since they are an open-source project, it means everyone will get a DLangUI alternative. If they make it to the end, that is.

On Thu, Jul 02, 2020 at 02:43:31AM +0000, Clarice via Digitalmars-d wrote:
> On Thursday, 2 July 2020 at 02:31:29 UTC, bachmeier wrote:
> > On Sunday, 1 September 2019 at 18:57:07 UTC, Kamran wrote:
> > > Hello everyone,
> > > People who forked GIMP, a popular open source image editor are
> > > discussing on which language to choose for their rewrite at [1]
> > > and they are considering D. Maybe some of you can help them out.
> > > 
> > > [1] https://github.com/glimpse-editor/Glimpse/issues/70
> > 
> > They have decided to go forward with a rewrite in D: https://github.com/glimpse-editor/Glimpse/issues/70#issuecomment-652644336
> 
> I hope it goes well for them, but this is a massive undertaking.

I wonder how they will approach this. Will they rewrite it from ground up, or will they rewrite it piecemeal (module-by-module or some other unit)?

I've rewritten a medium-sized C++ project of my own before (nowhere near as big as Gimp though), and I started out with the piecemeal approach, but found it quite frustrating. Eventually I opted to just dive cold turkey into rewriting it in D from ground up.  It took a while, but I'm quite pleased with the result, and have taken new directions with the code since, which has been much easier with D than C++.


T

-- 
The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- Anonymous

On Thursday, 2 July 2020 at 16:11:27 UTC, H. S. Teoh wrote:
> On Thu, Jul 02, 2020 at 02:43:31AM +0000, Clarice via Digitalmars-d wrote:
>> On Thursday, 2 July 2020 at 02:31:29 UTC, bachmeier wrote:
>> > On Sunday, 1 September 2019 at 18:57:07 UTC, Kamran wrote:
>> > > Hello everyone,
>> > > People who forked GIMP, a popular open source image editor are
>> > > discussing on which language to choose for their rewrite at [1]
>> > > and they are considering D. Maybe some of you can help them out.
>> > > 
>> > > [1] https://github.com/glimpse-editor/Glimpse/issues/70
>> > 
>> > They have decided to go forward with a rewrite in D: https://github.com/glimpse-editor/Glimpse/issues/70#issuecomment-652644336
>> 
>> I hope it goes well for them, but this is a massive undertaking.
>
> I wonder how they will approach this. Will they rewrite it from ground up, or will they rewrite it piecemeal (module-by-module or some other unit)?
>
> I've rewritten a medium-sized C++ project of my own before (nowhere near as big as Gimp though), and I started out with the piecemeal approach, but found it quite frustrating. Eventually I opted to just dive cold turkey into rewriting it in D from ground up.  It took a while, but I'm quite pleased with the result, and have taken new directions with the code since, which has been much easier with D than C++.
>
>
> T

What were the main issues you ran into with the piecemeal approach?

On Thu, Jul 02, 2020 at 09:02:28PM +0000, Meta via Digitalmars-d wrote:
> On Thursday, 2 July 2020 at 16:11:27 UTC, H. S. Teoh wrote:
[...]
> > I've rewritten a medium-sized C++ project of my own before (nowhere near as big as Gimp though), and I started out with the piecemeal approach, but found it quite frustrating. Eventually I opted to just dive cold turkey into rewriting it in D from ground up.  It took a while, but I'm quite pleased with the result, and have taken new directions with the code since, which has been much easier with D than C++.
[...]
> What were the main issues you ran into with the piecemeal approach?

The main frustrations were caused by having to stick to the C++ ABI between the C++/D boundary. This meant I can't use any D-specific features across this boundary, which greatly limited what the D portions of the code can do. Basically I had to write C++-style code in D in order to get it to work, which sorta defeats the purpose of rewriting it in D in the first place.

In theory, of course, once the entire codebase was in D then I could start refactoring it to be more idiomatic, but that meant a lot more effort was required: first transliterate C++ into D, then do piecemeal rewrites in D.  In contrast, rewriting the whole thing cold turkey from ground up meant I could dispense with the first step and do the second more easily (because I wouldn't have to work around old API design problems while doing the piecemeal rewrites -- I could just start fresh with a better design).

There remains, of course, what Joel Spolsky said about rewriting software from scratch: old bugfixes may be missing from the new code and therefore old bugs are reintroduced.  IME, however, getting a fully-D codebase up and running faster meant I could invest more time and effort into writing unittests until I achieved functionality on par with the old code.  The old code didn't even have unittests in the first place, so there were all sorts of latent bugs and regressions that I uncovered while reading the old code in the process of writing the new D code.  In contrast, the D code, while initially very buggy, was quickly kicked into shape thanks to a quickly-growing series of unittests, and later on, an external test suite that I threw together (with a convenient test utility -- written in D, of course, which meant I could put it together very quickly).  It also so happened that this particular project was heavily used by my website project, which used it in many non-trivial ways, so that also served as a large test case to ferret out all the obscure bugs that the unittests and test suite missed.

I'm rather pleased with the result, which has a much better design than the original C++ code. Not having to go through a transition stage where I had to pass everything through the old API meant that I could fix fundamental design issues from the get-go, instead of carrying it over into D and then doing another massive refactoring to fix them as a second step.

Of course, a lot of this is very specific to my specific codebase and use case; so YMMV, caveat emptor, et al.  DMD would serve as a counterpoint, where the translation to D was essentially a direct transliteration from C++, and even to this day is still gradually being rewritten piecemeal to take advantage of D features.


T

-- 
Marketing: the art of convincing people to pay for what they didn't need before which you fail to deliver after.

On Thursday, 2 July 2020 at 02:31:29 UTC, bachmeier wrote:
> On Sunday, 1 September 2019 at 18:57:07 UTC, Kamran wrote:
>> Hello everyone,
>> People who forked GIMP, a popular open source image editor are discussing on which language to choose for their rewrite at [1] and they are considering D. Maybe some of you can help them out.
>>
>> [1] https://github.com/glimpse-editor/Glimpse/issues/70
>
> They have decided to go forward with a rewrite in D:
> https://github.com/glimpse-editor/Glimpse/issues/70#issuecomment-652644336

Wow this is very exciting :)

If you are looking for an open source project to contribute to, I can highly recommend graphics programs. My past experience with Inkscape dev was always very rewarding (it's pretty cool to literally _see_ the result of your work and the amazing things people can craft using it).

cheers,
  Johan

On Saturday, 4 July 2020 at 13:05:42 UTC, Johan wrote:
> On Thursday, 2 July 2020 at 02:31:29 UTC, bachmeier wrote:
[...]
>> They have decided to go forward with a rewrite in D:
>> https://github.com/glimpse-editor/Glimpse/issues/70#issuecomment-652644336
>
> Wow this is very exciting :)
Yes!
I was reading to fast in this thread and missed the original post.
The process of rewrite and later the success would be a very good promotion for D.

On Sunday, 5 July 2020 at 14:22:39 UTC, Martin Tschierschke wrote:
>
> Yes!
> I was reading to fast in this thread and missed the original post.
> The process of rewrite and later the success would be a very good promotion for D.

Not only that, now that they claim that they will design their own GUI framework (which also must be cross platform) this will be a huge undertaking. That would mean that D gets another cross platform GUI framework which would benefit the D language even more. Unfortunately at least in my opinion, that license is likely to be GPL but a cross platform GUI framework none the less. Still I'm not sure if they will decide to go that route, Gtk is the obvious choice otherwise.