Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Programming language for rewrite? #70

Closed
TrechNex opened this issue Aug 3, 2019 · 75 comments

Comments

@TrechNex
Copy link
Member

@TrechNex TrechNex commented Aug 3, 2019

This is a community decision that is discussed periodically on Matrix channels. This issue is intended to tracks pros/cons and the criteria we intend to follow when making this decision.

(Edit by Clipsey)
It would be preferred if other language suggestions follow the formular of the D suggestion. Making the formatting the same is p good for readability.

@TrechNex TrechNex added the Question label Aug 3, 2019
@TrechNex TrechNex added this to the 2.0.0 milestone Aug 3, 2019
@TrechNex TrechNex added the Help Wanted label Aug 3, 2019
@Member1221

This comment has been minimized.

Copy link
Member

@Member1221 Member1221 commented Aug 16, 2019

D

<Website | Language Tour>

Pros

Cons

  • Multiple compilers with some lacking behind (GDC, SDC)
  • Less hype than other languages.
  • Smaller (but active via their Discord) community.
  • DLS can be harder to set up on FreeBSD.
  • D is harder to package with Meson (but possible)
  • DUB only supports linking statically with referenced libraries.
  • It's harder to make entirely new GTK widgets based off the GtkWidget class (but doable via a mixin)

Projects that use D

Points raised and answers

  • Support in IDEs tends to be through community plug-ins rather than provided out-of-the-box.
    • If built-in support is preferred there exists open source D specific IDEs like DLangIDE. Though I personally prefer a plugin inside an editor
  • .The technology is not proven with a free software project as complex as ours (it may be good to see some real world examples of D being used that people would be familiar with)
    • Check list of projects, there's some AAA games, professional audio plugins, etc. inbetween.
  • The language only recently went fully-free. GDC was only formally adopted as a GNU project in 2017
    • DMD went open source (on github) in 2017 as well, LDC2 has been open source since around 2008.
  • Some would say that the language has been around for a while and if it still hasn't gained traction by now it may never happen
    • The main reason for D's lack of traction is because no large company backing it, it has very little in terms of advertising like other languages do. It makes up for that by being a genuinely good experience to code in.
  • There is no saying what the support level from the community is likely to be in five years' time
    • The community has been active since 2006 and is starting to kick in to a higher gear as of late, even though the latest compiler revisions has mainly been deprecation of old D1 syntax and bug fixes.
  • Newer alternatives such as Rust and Go seem to have better community support and long term backing by well-known organisations (Mozilla and Google respectively)
    • Corporate backing != the usefulness of a tool. The only real benefit that having a corporation behind it is that it creates hype within companies which then spread to developers.

(TODO: More Pros/Cons will be added)

@TrechNex

This comment has been minimized.

Copy link
Member Author

@TrechNex TrechNex commented Aug 16, 2019

Additional cons to D:

  • Support in IDEs tends to be through variably-maintained community plug-ins rather than supported directly by IDE projects. (The counter-example that springs to mind is Visual Studio Code)
  • The technology is not proven with a free software project as complex as ours (it may be good to see some real world examples of D being used that people would be familiar with)
  • The language only recently went fully-free. GDC was only formally adopted as a GNU project in 2017
  • Some would say that the language has been around for a while and if it still hasn't gained traction by now it may never happen
  • There is no saying what the support level from the community is likely to be in five years' time
  • Newer alternatives such as Rust and Go seem to have better community support and long term backing by well-known organisations (Mozilla and Google respectively)

Having started experimenting with it I do like it in principle as a language. Technically it's a great technology, but it seems like it is the non-technical human aspects that potentially hinder it as a choice.

@TrechNex

This comment has been minimized.

Copy link
Member Author

@TrechNex TrechNex commented Aug 16, 2019

Additional comments made in chat since edits made to Clipsey's post:

  • The technical superiority of a language may not in and of itself make D the best choice. For example, the reason C, Java & Perl are so widely used is because it's the "lingua franca" that most people already know and a lot of existing codebases use them.
  • Almost everyone who wants to maintain the codebase would have to learn D from scratch. It may be your opinion it's a shallow barrier to entry, but it is still a barrier to entry.

Edit: Link to programming language popularity on Github https://githut.info/
D is currently ranked 39th

@TrechNex

This comment has been minimized.

Copy link
Member Author

@TrechNex TrechNex commented Aug 16, 2019

Other options that were considered in chat. These will need to be expanded in this issue.

C++: Probably not fit for purpose. GTK bindings are autogenerated and may not be well-tested
Rust: GTK support is improving. Concerns about learning curve.
Go: Mentioned as an option. Needs further discussion
C: Mentioned as an option. Needs further discussion
Vala: Potentially an option worth considering. Concerns about how well maintained it is.
C#: Main argument is may deter anti-Microsoft types. GTK bindings may be limited
Python: Popular, but could cause performance problems

@BrainBlasted

This comment has been minimized.

Copy link
Member

@BrainBlasted BrainBlasted commented Aug 16, 2019

Some disadvantages for each:

C++

  • Small development community, most apps written for GTK2/GNOME2
  • Very few bindings for libraries outside of just GTK
  • Bindings created pre-GObject-introspection, so there's more manual work to wrap libaries

Rust

  • Currently bindings to subclass objects need to be written manually until the gir tool can generate them
  • Learning the borrow checker could turn away potential contributors

Go

C

  • Less safety guarantees than other languages

Vala

  • Small developer group
  • Slow to fix issues with existing tooling

C#

  • Small development community
  • Few fully-fledged applications written with it
  • Not supported for most GNOME tooling
  • Likely will need to maintain infrastructure to support flatpaks

Python

  • Errors show up at run-time instead of compile-time

D

  • Not supported for most GNOME tooling
  • Likely will need to maintain infrastructure to support flatpaks
@meltheadorable

This comment has been minimized.

Copy link
Collaborator

@meltheadorable meltheadorable commented Aug 18, 2019

I'd just like to specify the criteria for an ideal language here, since it tends to be implied by the arguments either for or against each individual choice, but it'd be good to make them explicit:

Properties of an ideal language

Critical

  • Complete and High-Quality GTK 3 and/or 4 Bindings
  • Good C Interoperability, to allow use of existing libraries
  • Good cross-platform building and packaging (especially windows, macOS, and flatpak for linux)

Important, but not (necessarily) dealbreakers

  • Large existing developer community
  • Performant
  • Great learning resources
  • Low barrier to entry
  • Well-Maintained
  • Support for Meson

Nice to Have

  • Great IDE tooling
  • Easy to write memory-safe software
  • Other Complex GTK Software has been written in it
  • Growing language community
  • Integrates with GNOME tooling
  • Fast Compilation

Open to additions & changes to this list, but this was my attempt to synthesize & rank what's been put forward so far between here & the chat room.

@Moth-Tolias

This comment has been minimized.

Copy link

@Moth-Tolias Moth-Tolias commented Aug 18, 2019

golang is controlled by google, you should add that to the cons.

as a d learner I'd love to see a project like this use d

@BrainBlasted

This comment has been minimized.

Copy link
Member

@BrainBlasted BrainBlasted commented Aug 19, 2019

Thanks @meltheadorable. Based on that list, I would like to recommend Rust.

Rust

Critical

  • Complete GTK3 bindings and WIP GTK4 bindings
  • Can generate bindings to C libraries with specialized tooling for GObject-based libraries (with bindings for common libraries already generated)
  • Cross-platform - supports Windows, macOS, and Linux (with a flatpak SDK maintained by the freedesktop-sdk team)

Important

  • Growing development community, with companies like Mozilla and Microsoft moving to adopt it.
  • Due to difficulty of writing the same program in different languages it's hard to guage performance, but Rust performs close to C or even better in some benchmarks.
  • Great free learning resources, with the Rust Programming Language being a complete book available for free. There's also the reference which, while being less complete, helps fill in gaps from the first book.
  • The greatest barrier to entry is the borrow checker, as few languages have something like it. Due to it's strictness for safety reasons, fighting it has potential to turn away new contributors. Past that, Rust's safety guarantees and memory management system make it far easier to make safe code when starting out than C.
  • Well-maintained. Details on their governance model are here.
  • Meson supports Rust, but not the primary buildsystem Cargo. You can get them working together with a custom target and a few scripts. See here for the sort of changes needed for proper integration.

Nice to Have

To me it ticks most of the boxes, and definitely hits all the important ones. I've worked with GTK-rs extensively and think it could be a good choice in the near future. The story around GNOME and Rust also seems to only be improving as more developers take interest.

@BrainBlasted

This comment has been minimized.

Copy link
Member

@BrainBlasted BrainBlasted commented Aug 22, 2019

An addendum: Debugging Rust depends on https://gitlab.gnome.org/GNOME/gnome-builder/issues/877 getting fixed. I'll look into that soon.

@sudo-give-me-coffee

This comment has been minimized.

Copy link

@sudo-give-me-coffee sudo-give-me-coffee commented Aug 27, 2019

Why not C++ and Qt?

  • Clean code
  • Suports C programming style
  • Isn't painful migrate from a version to another
  • Binding with scripting languages is very easy
  • Works great with lua
  • Easy distribution with AppImage, Flatpaks and Snaps
  • Compiles ui file as native code
  • Supports Wayland and X11 very well
@Member1221

This comment has been minimized.

Copy link
Member

@Member1221 Member1221 commented Aug 27, 2019

There’s already Krita filling that spot. As well you’d be sacrificing looking nice on one platform to look bad on all platforms (imo)

@TrechNex

This comment has been minimized.

Copy link
Member Author

@TrechNex TrechNex commented Aug 27, 2019

I'd love it if we went the Qt and C++ route 😄
However there's a not small number of GNOME project contributors in our project, and they will probably object!

@sudo-give-me-coffee

This comment has been minimized.

Copy link

@sudo-give-me-coffee sudo-give-me-coffee commented Aug 27, 2019

@Member1221 I don't think that is a "place to fill" is a tool that solve the problem, is the best? Depends of a lot of things.

As well you’d be sacrificing looking nice on one platform to look bad on all platforms (imo)

No, Qt is the exactly oposite of it, qt is a toolkit that abstract c++, the same code teorically will run on all platforms suported without significative changes in code, your scenario applies more to GTK than Qt

Qt is easily to make a visual consistent over all platform too, is possible to set a Qt StyleSheet and/or force a a widget style hardcoded, with GTK is more complicated to do, in a simplified way GTK always follow system style, like this:

widget-factor1

This is very problematic on a multimedia creation tool like GIMP/Glimpse.

The biggest problem with Qt apparently is the large GNOME project contributors in the project, like @TrechNex said

@TrechNex

This comment has been minimized.

Copy link
Member Author

@TrechNex TrechNex commented Aug 28, 2019

Ditto what @sudo-give-me-coffee said. The other cool thing is that for people who don't like C++ (boo!) they tend to pick up the signals-and-slots and Model-View-Controller stuff pretty quickly, as it's modeled after what you'd do if you were writing a smartphone app.

I quite like working with Qt, and have used it in a number of projects. I'd highly recommend it as a choice, particularly given how good the cross-platform tooling and docs are for it.

As I mentioned earlier, the sticking point is you're basically turning a GNOME app into a KDE one, and that could be controversial. I probably shouldn't prejudge on this, as it may be I'm making an assumption about how our own community would react.

@Member1221

This comment has been minimized.

Copy link
Member

@Member1221 Member1221 commented Aug 28, 2019

The problem with Qt is that it tries too hard to look native everywhere, to the point where the application just looks boring.
GTK goes in its own direction, does work on other platforms; at once we’re at GTK 3-4 the UI will have a different flavour on Windows and macOS, not trying to be native but just being itself.

And yeah Qt would mean we’d need to migrate to C++ which would be a turnaway for many people, except already somewhat experienced C++ programmers.

@TrechNex

This comment has been minimized.

Copy link
Member Author

@TrechNex TrechNex commented Aug 28, 2019

I disagree with the notion that making your UI look native to the operating system it's running on is "boring", but taste is always a subjective thing. 🤷‍♂

Also given the code we are currently working on is mostly C, I don't think switching it up to C++ would turn away as many people as you'd think. However, as I was the only person on chat arguing in favour of that language when we last discussed language choice on Matrix I accept that arguing the point on this is probably not going to be a fruitful use of time or energy. 😅

@nirim000

This comment has been minimized.

Copy link

@nirim000 nirim000 commented Aug 30, 2019

I'm mostly experience with embedded electronic, but rust seems like a easy choice.

@Member1221

This comment has been minimized.

Copy link
Member

@Member1221 Member1221 commented Aug 30, 2019

@Member1221 I don't think that is a "place to fill" is a tool that solve the problem, is the best? Depends of a lot of things.

As well you’d be sacrificing looking nice on one platform to look bad on all platforms (imo)

No, Qt is the exactly oposite of it, qt is a toolkit that abstract c++, the same code teorically will run on all platforms suported without significative changes in code, your scenario applies more to GTK than Qt

Qt is easily to make a visual consistent over all platform too, is possible to set a Qt StyleSheet and/or force a a widget style hardcoded, with GTK is more complicated to do, in a simplified way GTK always follow system style, like this:

widget-factor1

This is very problematic on a multimedia creation tool like GIMP/Glimpse.

The biggest problem with Qt apparently is the large GNOME project contributors in the project, like @TrechNex said

That only applies for GTK2, once we port to GTK3 the style will be Adwaita on all platforms.

@dreamer

This comment has been minimized.

Copy link

@dreamer dreamer commented Aug 30, 2019

And yeah Qt would mean we’d need to migrate to C++ which would be a turnaway for many people, except already somewhat experienced C++ programmers.

It would be also a turnaway for some experienced C++ programmers ;)

As for now - I think any kind of (gradual, careful) rewrite is very long-term goal, and initial releases will stick to C for pragmatic reasons. When the time will be right for introducing the second language in the main codebase, I would vote for Rust - on the first glance (I haven't looked deeply into Glimpse source code yet), it checks many boxes (prevention of multiple classes of bugs, C-interop, great tooling), language edition 2018 is quite nice to pick up ("fighting the compiler" is not so prevalent any more), it has very welcoming, helpful and focused community and attracts a lot of attention due to recent announcements from Microsoft, Intel, Linux (kernel team) and Mozilla; Gtk-Rust interop is also steadily improving. It is also consistently voted the most loved language on StackOverflow (4 years in the row now), so it's likely to attract some much-needed developer attention.

@Member1221

This comment has been minimized.

Copy link
Member

@Member1221 Member1221 commented Aug 30, 2019

And yeah Qt would mean we’d need to migrate to C++ which would be a turnaway for many people, except already somewhat experienced C++ programmers.

It would be also a turnaway for some experienced C++ programmers ;)

As for now - I think any kind of (gradual, careful) rewrite is very long-term goal, and initial releases will stick to C for pragmatic reasons. When the time will be right for introducing the second language in the main codebase, I would vote for Rust - on the first glance (I haven't looked deeply into Glimpse source code yet), it checks many boxes (prevention of multiple classes of bugs, C-interop, great tooling), language edition 2018 is quite nice to pick up ("fighting the compiler" is not so prevalent any more), it has very welcoming, helpful and focused community and attracts a lot of attention due to recent announcements from Microsoft, Intel, Linux (kernel team) and Mozilla; Gtk-Rust interop is also steadily improving. It is also consistently voted the most loved language on StackOverflow (4 years in the row now), so it's likely to attract some much-needed developer attention.

The learning curve of rust is still like a brick wall/vertical line. (But also the fact that I mentally can't handle rust, too stressful.)
I believe we should stick to something that has some form of OOP and is c-like to stay in territory that is easier to adapt to.

@BrainBlasted

This comment has been minimized.

Copy link
Member

@BrainBlasted BrainBlasted commented Aug 30, 2019

I don't think OOP will be super important to keep working with GTK, especially if we decide to move to GTK4, which prefers composition over subclassing.

@nirim000

This comment has been minimized.

Copy link

@nirim000 nirim000 commented Aug 31, 2019

I decided to try for picking up rust, for my foray into pc dev, so i will gladly contribute if it's chosen. I'm just happy a good open source alternative to Photoshop is in development for Windows. Anyway i think picking up a new syntax bug a lot of people and rust is similar enough to c++ syntax wise, to add a pro.

Edit: tired just forgotten some word.

@Laeeth

This comment has been minimized.

Copy link

@Laeeth Laeeth commented Sep 1, 2019

"Multiple compilers with some lacking behind (GDC, SDC)"

How is the existence of an experimental compiler a disadvantage? Amaury Sechet created SDC and it is still under development but clearly he has his hands full as the technical lead of Bitcoin Cash ABC.

How is the existence of LDC in addition to DMD a disadvantage? LDC doesn't lag behind much (seems to me more like weeks). DMD is easier to hack on and compiles faster, so developing on DMD (and putting new features in there first) makes sense. LDC generates faster code but more slowly (compared to DMD).

SDC is an experiment that nobody uses because it is not yet ready. LDC, GDC and DMD use the same front-end. Obviously they use different back-ends otherwise they would be the same compilers...

Are you sure dub only supports linking statically? I'm not sure that is right.

Is there something special about complexity in a free software project? I think a file system is quite a complex endeavour - Weka.io went from zero to building the world's fastest file system in five years, without anyone having prior experience of D (other than a couple of people they had as specialist consultants part-time). Sociomantic another example.

DMD has been openly developed for a decade - front and back ends. It was a technical legal question relating to getting an agreement from Walter's old company. Nothing much has changed apart from perceptions. He just had to get people to ask him if they could redistribute and he always said yes.

D has no traction? Well I think a decade ago the only people crazy enough to use it in production for a serious project might have been Sociomantic. (And perhaps even some people now there might have thought it crazy). These days if you look at organisations using D it's quite a different picture. We're using for our analytics across the firm as well as a domain-specific functional language (quite a large domain) at a $5bn asset management company.

I think a key point is that D is a very ambitious language - a general purpose language for getting work done when many other newer languages have been more suited to a particular domain. So since use is spread out across many domains, one is much less likely to encounter people in your domain also using D - contrast with Go, for example. This has costs and benefits - a major benefit for commercial users is that you encounter people in other domains that you can learn from and have knowledge transfer.

Most code is not open-source but developed within enterprises and academe. Sociomantic only recently open-sourced some of their work, and although at Symmetry we have started open-sourcing work it's quite unusual for our industry. Same thing with Weka.io - they only open sourced their Mecca library after 4-5 years of using D to solve their problems.

I personally think it's much more anti-fragile and a positive thing that D is not under the sway of one company. We hosted dconf this year, and Atila Neves - a consultant to us - has taken over day-to-day leadership from Andrei Alexandrescu. I wouldn't want to end up being the only commercial entity involved with D because the strength of D comes from its usefulness across multiple domains and if we were to try and influence it in a direction that optimised to our niche it would be self-defeating.

@bachmeil

This comment has been minimized.

Copy link

@bachmeil bachmeil commented Sep 1, 2019

A few relevant points related to D that I didn't see mentioned above:

  • You can include C header files directly using dpp. You can reuse all existing C libraries and call all the functions the same way as you do now, or you can write your own wrappers with additional functionality, but the point is if it's available in C you get it for free in D.
  • If you want to add D to a C project incrementally, there's -betterC mode. You only get a subset of the language, but you can replace your current project piece-by-piece without going through a full rewrite. No surprises where you find out that some of the rewritten parts aren't working. Then once a big chunk of the code is written, you can make the switch to use the full D language and keep using the parts written in betterC mode. This is essentially refactoring rather than rewriting, so it's not as much fun, but refactoring has its advantages.
  • It's not a project run by a behemoth like Google or Microsoft, but it does have some support, like Symmetry Investments. Projects like eBay's TSV tools were written in D.
@Member1221

This comment has been minimized.

Copy link
Member

@Member1221 Member1221 commented Sep 1, 2019

@Laeeth The downside is that some compilers will lack features not present in DMD which might cause compilation issues (have happened to me in the past)
That's the only downside to them, SDC, LDC2 and GDC are awesome projects and I think the choice is great. It's just an important note for people so they don't get confused if something fails to compile with one compiler.

The place where that issue is the biggest is with GDC since it has a somewhat slower release cycle. (Other than SDC, but its still early WIP)

I'm the main advocate for D for this project (and it's my favourite language to use for pretty much all of my personal projects nowdays). So don't see the negatives as something I say because I dislike the language, it's because I like the language and hope those things get solved in the future :)

DUB only supports liking statically to dependencies, you can't have dynamic dependencies with dub at current time (dub will throw a warning then link statically)

@Member1221

This comment has been minimized.

Copy link
Member

@Member1221 Member1221 commented Sep 1, 2019

@bachmeil

  • DPP will probably not be used if we chose to use D, as it adds extra tool overhead.
  • The UI rewrite will happen from scratch, so we won't need betterC
  • And yeah, i see that as a pro too. (Though some see it as a con)
@maxhaton

This comment has been minimized.

Copy link

@maxhaton maxhaton commented Sep 1, 2019

I don't know if it's been mentioned or not, but D's builtin C++ interop is probably the best available (e.g. ABI is matched down to vtables and templates)

@seagetch

This comment has been minimized.

Copy link

@seagetch seagetch commented Sep 18, 2019

I recommend to port GUI related codes gradually to web-based technology like html5 design and javascript (or typescript.)

Once I tried to port GimpImageWindow to WebKit-1 webview (hiring Embed widget framework that was only available in WebKit-1.) Some quality issues are remaining, but technology is well probed actually.
See https://github.com/seagetch/gimp-painter/tree/webkit for more details.
Screenshot from 2016-01-13 21-56-26
Screenshot from 2016-01-31 18-49-38

Unfortunately, Embed widget is not available in WebKit-2 and Chromium-based technology though.

Many power-user can enhance GUI easily with html5 design template and javascript (like firefox.) if we port GUI to web-based technology.

@stavpup

This comment has been minimized.

Copy link

@stavpup stavpup commented Sep 20, 2019

One of my favorite apps:

https://wiki.lazarus.freepascal.org/Overview_of_Free_Pascal_and_Lazarus

https://wiki.lazarus.freepascal.org/LazPaint

LazPaint was started to demonstrate the capabilities of the graphic library BGRABitmap. It provides advanced drawing functions in Lazarus development environment. Both provided a source of inspiration for the other and finally LazPaint became real image editor. Thanks to the help of Lazarus community, the program has been compiled on Windows, Linux and MacOS X.

@TrechNex

This comment has been minimized.

Copy link
Member Author

@TrechNex TrechNex commented Oct 15, 2019

Notes taken verbatim from Matrix discussion about GTK versus Qt:

  • Qt supports OpenGL ES, less so OpenGL (There's some major differences that impact the speed of what we want to do)

  • Qt supports Vulkan and MoltenVK (but there's major code amount overhead doing so)

  • GTK supports OpenGL, less so OpenGL ES (makes it hard to port to mobile)

  • GTK does not support Vulkan out of the box in GTK3, dunno about GTK4. (No Vulkan backend possible at current time?)

  • macOS has some issues that makes installation of Glimpse more difficult in the future without doing modifications that system admins might not want to do. (Deprecation of OpenGL and Noterization problems)

  • Qt supports macOS

  • GTK currently has a lot of problems on macOS

  • GTK applications look unique/different on non-GNOME desktops out of the box, and does support CSS as well (a positive to me)

  • Qt tries to look native on everything, but can (with work) be skinned with CSS to look unique.

  • Qt has native support for dockable windows

  • GTK doesn't, there's some projects that adds such to GTK but they tend to look off.

@Member1221

This comment has been minimized.

Copy link
Member

@Member1221 Member1221 commented Oct 15, 2019

@seagetch

I recommend to port GUI related codes gradually to web-based technology like html5 design and javascript (or typescript.)

Once I tried to port GimpImageWindow to WebKit-1 webview (hiring Embed widget framework that was only available in WebKit-1.) Some quality issues are remaining, but technology is well probed actually.
See https://github.com/seagetch/gimp-painter/tree/webkit for more details.
Screenshot from 2016-01-13 21-56-26
Screenshot from 2016-01-31 18-49-38

Unfortunately, Embed widget is not available in WebKit-2 and Chromium-based technology though.

Many power-user can enhance GUI easily with html5 design template and javascript (like firefox.) if we port GUI to web-based technology.

That is probably not going to happen; web based technology adds a whole bunch of overhead that would harm the end product. As well maintainability would be a lot worse, together with the ability to make fast (native) plugins easily would also be lost.

@Waqar144

This comment has been minimized.

Copy link

@Waqar144 Waqar144 commented Oct 28, 2019

Notes taken verbatim from Matrix discussion about GTK versus Qt:

* Qt supports OpenGL ES, less so OpenGL (There's some major differences that impact the speed of what we want to do)

* Qt supports Vulkan and MoltenVK (but there's major code amount overhead doing so)

* GTK supports OpenGL, less so OpenGL ES (makes it hard to port to mobile)

* GTK does not support Vulkan out of the box in GTK3, dunno about GTK4. (No Vulkan backend possible at current time?)

* macOS has some issues that makes installation of Glimpse more difficult in the future without doing modifications that system admins might not want to do. (Deprecation of OpenGL and Noterization problems)

* Qt supports macOS

* GTK currently has a lot of problems on macOS

* GTK applications look unique/different on non-GNOME desktops out of the box, and does support CSS as well (a positive to me)

* Qt tries to look native on everything, but can (with work) be skinned with CSS to look unique.

* Qt has native support for dockable windows

* GTK doesn't, there's some projects that adds such to GTK but they tend to look off.

Learning resources for Gtk are almost non existent.

Writing code in GTK/C or using Gobject is a huge pain and is quite complicated. Qt is much more simpler and readable and easier to maintain.

For a bigger development community to work on this project, the first thing that needs to happen is saying goodbye to Gtk.

Also, there's V Language @vlang , which looks quite interesting. Perhaps the author @medvednikov can comment.

@nordlow

This comment has been minimized.

Copy link

@nordlow nordlow commented Oct 28, 2019

I updated the compiler benchmarks above to include Zig, Java and V. Further the benchmarks now show the minimum of 10 runs for more stable metrics. The Rust compilation previously ended prematurely because of an error. This has been corrected and now the Rust semantic checking is even more incredibly slow. Currently 77x slower than the fastest D!.

Note that neither Java nor V currently supports separate semantic checking so these benchmarks produces an object file.

@medvednikov

This comment has been minimized.

Copy link

@medvednikov medvednikov commented Oct 28, 2019

@nordlow please make sure you use a production version of V: v -o v -prod v.v

@medvednikov

This comment has been minimized.

Copy link

@medvednikov medvednikov commented Oct 28, 2019

Regarding GTK vs Qt, I spent a lot of time on this topic when working on V ui. I ended up writing a new toolkit for Linux from scratch:

Qt is very complex and is hard to call from C. They use their own extended C++, which makes things even more complicated.

GTK is a mess with an unstable API and no clear vision unfortunately.

@nordlow

This comment has been minimized.

Copy link

@nordlow nordlow commented Oct 28, 2019

@nordlow please make sure you use a production version of V: v -o v -prod v.v

I assume you mean running

./v -o v -prod v.v

at the top-directory of https://github.com/vlang/v.

I reran the benchmark for V. No significant change in run-time, though. Numbers have been updated above.

@medvednikov

This comment has been minimized.

Copy link

@medvednikov medvednikov commented Oct 28, 2019

Right, I have the v binary symlinked to /usr/local/bin/v :)

@medvednikov

This comment has been minimized.

Copy link

@medvednikov medvednikov commented Oct 28, 2019

The C to V translator which covers 100% of the C standard will be out next month, it'll be interesting to test it on a big project like yours.

So far I've been focusing on SQLite and DOOM.

@seagetch

This comment has been minimized.

Copy link

@seagetch seagetch commented Nov 10, 2019

@seagetch

I recommend to port GUI related codes gradually to web-based technology like html5 design and javascript (or typescript.)
Once I tried to port GimpImageWindow to WebKit-1 webview (hiring Embed widget framework that was only available in WebKit-1.) Some quality issues are remaining, but technology is well probed actually.
See https://github.com/seagetch/gimp-painter/tree/webkit for more details.
Screenshot from 2016-01-13 21-56-26
Screenshot from 2016-01-31 18-49-38
Unfortunately, Embed widget is not available in WebKit-2 and Chromium-based technology though.
Many power-user can enhance GUI easily with html5 design template and javascript (like firefox.) if we port GUI to web-based technology.

That is probably not going to happen; web based technology adds a whole bunch of overhead that would harm the end product. As well maintainability would be a lot worse, together with the ability to make fast (native) plugins easily would also be lost.

Hi,
I've hust started new project to make graphics editor using GEGL, libmypaint,and electron (that means web-based.)
Integration with existing native code is fairly easy.
I measure the performance,and found that bottleneck sits in GEGL and libmypaint side, not in JS side for now.
As per productivity, you can see vs-code that improve productivity much using web-based technology.
Just FYI.
https://github.com/seagetch/parchment

@TrechNex

This comment has been minimized.

Copy link
Member Author

@TrechNex TrechNex commented Nov 10, 2019

@seagetch that looks very cool! If it helps, GTK supports JavaScript so that might help with your work on the front end.

@TrechNex

This comment has been minimized.

Copy link
Member Author

@TrechNex TrechNex commented Nov 10, 2019

For fair disclosure at this point, I think the working group looking into Glimpse Image Editor 2.x seem to be leaning towards the D programming language. Rust is also in the mix as a potential option.

V as a language seems to have popped up from nowhere. While it looks like an intriguing choice, it is still "alpha stage", lacks documentation and does not seem to be supported by the wider free software community yet. While it is not feasible right now, we will be keeping an eye on it.

@TrechNex

This comment has been minimized.

Copy link
Member Author

@TrechNex TrechNex commented Nov 10, 2019

I have also been arguing in favour of Qt, but I think in practise we will be using GTK because the majority of our contributors come from the GNOME project and we want to keep them interested and engaged.

@Waqar144

This comment has been minimized.

Copy link

@Waqar144 Waqar144 commented Nov 11, 2019

Problems with GTK or why it can be a bad choice

@TrechNex
@glimpse-editor community

  • Learning resources are almost non-existent. Even StackOverflow has maybe a couple of hundred questions on Gtk. This means no new comers. A lot of people look online for learning new stuff, solving questions. Gimp suffers from the same problem. Almost no new contributors because people don't know Gtk and people are often scared of writing in C and they don't want to learn Gtk. There are no Gtk jobs, there is not much benefit in learning Gtk, it isn't being used in the industry as much as Qt. A lot more people know Qt.
  • Bad documentation that doesn't tell you much
  • Gtk is difficult and complicated
  • Portability is going to be a pain, even for Linux OSes. KDE devs spend a lot of time trying to get gtk apps to run correctly in KDE and they still haven't succeeded completely. The same can't be said about Qt or even apps using KFrameworks.
  • Glimpse is an app that doesn't just need good devs. It needs people with good mathematics and image processing knowledge and so on. Glimpse won't get far without such people. Such people will definitely find Gtk very difficult and will usually not be able to find many answers to their questions online.
  • Gtk 4 is coming soon, no one knows what's gonna happen or what's happening in there except maybe the Gtk/Gnome folks. Gimp is still in Gtk 2 land. They haven't been able to complete the Gtk-3 port yet.

Is Glimpse going to run in GNOME only? Cause if you go that way, that's what it looks like. Devs should be able to focus on development rather than wasting half the time getting stuff to work on other platforms.

This post isn't in favour of Qt. Don't choose Qt(Although writing software in Qt is a much much better experience than Gtk). Choose anything else, but not Gtk.
If a rewrite is being planned, which in itself is a very ambitious quest, going down the same road as Gimp isn't ideal.

PS: I don't intend to hurt anyone's feelings, these are just my opinions and if you don't agree that's fine.

@TrechNex

This comment has been minimized.

Copy link
Member Author

@TrechNex TrechNex commented Nov 11, 2019

The intention with the rewrite is to create a new UI wrapper & plug-in framework that still uses GEGL, BABL & (possibly) MyPaint. So being able to import those subcomponents and their dependencies is a prerequisite.

I agree on portability as using GTK basically precludes ever producing a macOS version unless we port it for them. However, it is still usable for Windows and Linux and following the GNOME Human Interface Guidelines would still be a significant benefit from a user experience point of view.

The problem with criticizing both GTK and Qt means is that we are left with Electron as a cross-platform solution, which currently seems to be a non-starter with the project as people have concerns about the underlying hardware performance (this is particularly important when doing professional rather than hobbyist tasks).

The other solution is writing a different UI for each operating system (eg WPF for Windows, GTK for Linux and Cocoa for macOS), but we are deeply unlikely to ever have the resources to maintain three separate codebases.

Like most technical decisions (and life in general) we have to make trade-offs. No one technology will suit everyone, so we have to determine which tool can reasonably achieve our objectives and still bring enough people with us when we start using it.

@Waqar144

This comment has been minimized.

Copy link

@Waqar144 Waqar144 commented Nov 11, 2019

The intention with the rewrite is to create a new UI wrapper & plug-in framework that still uses GEGL, BABL & (possibly) MyPaint. So being able to import those subcomponents and their dependencies is a prerequisite.

How about we rewrite GEGL and BABL too? It's not impossible.

I agree on portability as using GTK basically precludes ever producing a macOS version unless we port it for them. However, it is still usable for Windows and Linux and following the GNOME Human Interface Guidelines would still be a significant benefit from a user experience point of view.

Yes, and there are a lot of Mac users, a lot more than Linux. Choosing Gtk while knowing that it's going to give us a lot of problems is not a good decision.

The problem with criticizing both GTK and Qt means is that we are left with Electron as a cross-platform solution, which currently seems to be a non-starter with the project as people have concerns about the underlying hardware performance (this is particularly important when doing professional rather than hobbyist tasks).

Where is some valid Qt criticism? Tries too hard to look native? What else? Qt is a good choice. It is powerful, more powerful than Gtk, well documented, with a lot of learning resources, books, articles, video tutorials and a bigger community than Gtk. Qt also tries to maintain backwards compatibility. Gtk? not so much. It's like playing catch up.

Like most technical decisions (and life in general) we have to make trade-offs. No one technology will suit everyone, so we have to determine which tool can reasonably achieve our objectives and still bring enough people with us when we start using it.

Yes that's true. Trade offs are there, but you have to think what kind of trade-offs?
Sacrificing Mac? ok.
Better Open GL support? ok
Keeping the entry barrier high? ok.
Sacrificing KDE/Qt DEs?

The makes me think.. What do we gain by sticking to Gtk? What are the advantages?

Gtk-3 branch of gimp opened in 2013/14? Not sure. They still haven't been able to make it. 6 years, maybe even more. And those guys know the code base a lot better than anyone here. I wanna ask the community, What makes you guys think you can do it?

@jacob-carlborg

This comment has been minimized.

Copy link

@jacob-carlborg jacob-carlborg commented Nov 11, 2019

The problem with criticizing both GTK and Qt means is that we are left with Electron as a cross-platform solution

If D is chosen, there's DWT [1]. But it's currently only for Windows and Linux.

[1] https://github.com/d-widget-toolkit/dwt

@jacob-carlborg

This comment has been minimized.

Copy link

@jacob-carlborg jacob-carlborg commented Nov 11, 2019

Where is some valid Qt criticism? Tries too hard to look native?

It does not look native on macOS at least. Virtual Box used to look fine on macOS, but now with version 6, which is using Qt, it looks absolutely horrible.

@Waqar144

This comment has been minimized.

Copy link

@Waqar144 Waqar144 commented Nov 11, 2019

Where is some valid Qt criticism? Tries too hard to look native?

It does not look native on macOS at least. Virtual Box used to look fine on macOS, but now with version 6, which is using Qt, it looks absolutely horrible.

So... is that better than not having a macOS version at all?

@jacob-carlborg

This comment has been minimized.

Copy link

@jacob-carlborg jacob-carlborg commented Nov 11, 2019

So... is that better than not having a macOS version at all?

GTK supports macOS. Not that I think that GTK is better than Qt.

@TrechNex

This comment has been minimized.

Copy link
Member Author

@TrechNex TrechNex commented Nov 11, 2019

@Waqar144 I'm going to avoid retreading the Qt vs GTK discussion here: #70 (comment)

My opinion is that Qt is probably the better choice, but the community relies heavily on GNOME project contributors. If we want to continue to receive their buy-in then we have to use GNOME-friendly technology. If we lose their buy-in then the rewrite won't happen, because there won't be enough people committed to doing it to make that viable.

And to answer your "question to the community", I should point out that we do not presume to be better equipped to tackle a task than a more established and better resourced project. The difference is that we are focussed purely on the UI/UX and we are going into it understanding this is a "blue sky" project that may not come to fruition. We are designing with that in mind, and our programming language/UI choice is something we can take time to consider before we finally make a decision.

We also already know it is not impossible for us to fork BABL/GEGL, but it is not going to happen imho. Forking those projects would massively increase our overhead for little or no payoff. There are only so many wheels we are willing to consider reinventing.

@Waqar144

This comment has been minimized.

Copy link

@Waqar144 Waqar144 commented Nov 11, 2019

I agree with most what you say, and yeah Qt would have been the better choice. And one big reason for choosing it could be the multi platform support.

Anyways, I fully support whatever decision gets taken and hopefully will be try to be a part of the effort in rewriting even with my little gtk knowledge.

@meltheadorable

This comment has been minimized.

Copy link
Collaborator

@meltheadorable meltheadorable commented Nov 12, 2019

It's been a while since I've looked at this thread -- I think the multiple pages of discussion about D compiler internals should be added to the list of cons for D, and would generally agree that Qt is the better choice, but that essentially collapses our language choice down to C++ because bindings for other languages with Qt, due to Qt's extensive modifications to the language, tend to require relatively fragile hacks to generate bindings that can be used via the language's FFI or are in languages we've more or less ruled out for performance reasons, and if we choose the better tech and lose all the contributors, that's not exactly an ideal outcome.

At the end of the day, short of writing our own new cross-platform language toolkit, sticking with GTK and hoping the macOS issues are possible to resolve might be the only navigable outcome. In that scenario language choice matters less as long as it has complete GTK bindings. I doubt it's possible for us to take on the responsibility of both dramatically improving the GTK bindings for a language that doesn't have them or only has toy bindings and also engaging in a GTK porting effort for macOS, and dropping macOS would be a mistake I think.

@pipboy96

This comment has been minimized.

Copy link

@pipboy96 pipboy96 commented Nov 25, 2019

@TrechNex I have a few questions:

  • Are you only discussing rewriting the frontend, or will the backend be rewritten too?
  • Is the project hard set to use GTK or are there other options?
  • What's the size of a part that's going to be rewritten (roughly) and how complex is it?
  • What are the primary motivations for rewrite? Which shortcomings of the original code should the rewrite address?

Also, can the relevant parts of conversation about the rewrite be made available to people who don't have an account on your Matrix server, if possible, to avoid duplicating effort?

@TrechNex

This comment has been minimized.

Copy link
Member Author

@TrechNex TrechNex commented Nov 25, 2019

@pipboy96 I will do my best to answer these questions, but @Member1221 is probably the best person as she is heading up that effort.

Are you only discussing rewriting the frontend, or will the backend be rewritten too?

The front-end. Things like BABL, GEGL, MyPaint and libgimp would still be used.

Is the project hard set to use GTK or are there other options?

Nothing is decided until it's decided. I believe the reason GTK is the way the project is leaning is because we have a number of GNOME contributors, and the people most likely to stick around and write the code want to use it.

What's the size of a part that's going to be rewritten (roughly) and how complex is it?

It would be the user-interface and the plug-in interpreter. The complexity of the task is high, which is why time is being given over to working through the design, analyzing the tools, etc. Our expectation is that with people just working on this in their free time it would take a year or two at least before it is ready to be a "swap in" replacement.

What are the primary motivations for rewrite? Which shortcomings of the original code should the rewrite address?

@Member1221 can better answer this question. Personally for me it's practical reasons. I was willing to sustain hundreds of unpaid hours per month to make a fork of 2.10.x happen, but I am not up for doing that again for 3.0.x. I think it makes sense for us to cultivate our own changes and differentiate what our project is offering than constantly struggling to keep up with what upstream is doing.

Also, can the relevant parts of conversation about the rewrite be made available to people who don't have an account on your Matrix server, if possible, to avoid duplicating effort?

Possibly. I think the most constructive thing that working group can do is make the decisions they have been making available on https://wiki.glimpse-editor.org. To an extent they have already started doing this, but I will encourage them to do that more. :)

@Member1221

This comment has been minimized.

Copy link
Member

@Member1221 Member1221 commented Nov 25, 2019

The main reason to me; is the large codebase cruft in upstream's codebase. Which is understandable, it's an old and large piece of software, written with psuedo classes implemented in a language without classes.

The rewrite facilitates using a language that's more suited to the structure of GTK (OOP), while also avoiding the amount of code-generating scripts that upstream uses at current time. We also will have an easier time to document the codebase, apply new features (with larger scope), etc.

@Member1221

This comment has been minimized.

Copy link
Member

@Member1221 Member1221 commented Nov 28, 2019

Closing this issue as it has grown kinda stale and we're at the point where we soon need to think about what to use.
I don't think there can be added much more useful info to this discussion.

@TrechNex feel free to reopen if you disagree.

@Member1221 Member1221 closed this Nov 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.