Github Electron Client for Tryton


(Ali Kefia) #1

Why ?

  • The same code base for web and rich client => easier to maintain
  • Much more possibilities with Javascript / CSS => plugins? widgets?
  • Move the community focus to a single client project
  • No dependency on GTK and no more issues with multi-platform builds (py2exe, …)
  • Probably make the community more attractive to js/css developers (more contributors, more fun)

(Cédric Krier) #2

The current experience shows that our “mirroring” between tryton and sao is very easy to maintain.

I don’t see what possibilities Javascript adds compare to Python. They are both Turing complete languages. For me, the main difference is that Javascript has a very poor design with a lot of exception and weird behaviour.
About CSS, sao already has CSS and when tryton will be ported to GTK±3, it will also.
We already have plugins for both clients.
Each one are based on an ecosystem that has a lot of widgets. Of course one challenge is to find which one to use but until now we have no big issue with that. But often our specific needs are not completely supported by any existing widgets and so we have to develop it.

Both are thin clients and they represent about only 5% of the project. I don’t think there is really a focus issue. Indeed the tendency is to use tryton as main desktop application and sao for road-warriors/casual and/or mobile usage.

Personally, I don’t see the dependency on GTK+ as an issue. Indeed I see it as a great library that eases our job to write good widgets. In contrary, the web stack doesn’t provide so good widgets. I’m still waiting to see a web based desktop application being as good as those based on native library like GTK+. Also being native allows us to directly talk to the OS to consume resources like the file-system.

I don’t think it will be valuable to attract JS developers if they can not also learn and write Python. I think the argument about “more contributors” is purely speculative, Tryton is in the business application which is for many (wrongly) assumed as boring.
Also I personally don’t see where is the fun in Javascript, this is one of the more horrible language I had to work with (and I developed in COBOL :slight_smile:).

Also about Electron, I see no argument about this choice, it is just one more “web framework” that appears (and often disappear as quickly). For what I see it is mainly developed by GitHub and this scares me a lot. GitHub is not really well known to be dedicated to free software. And we have already seen in the past many similar frameworks build by large companies, being stopped abruptly just because the main company was no more interested in it. This is why we must be very careful when we add a new dependency to Tryton and we should use well established projects.

Finally, about the investment, it was already very long (≃3.5 years) to get sao financed and developed and it is not yet at the same level as tryton. I don’t see the community renew the task right now. I think it is better to focus the effort on bringing sao to the same level and porting tryton to GTK±3.


(Cédric Krier) #3

After discussing at the #TUB2016, the proposal was not correctly understood.
The idea is to use the Electron bootstrap tools to build a standalone application with the current sao code.
I think this is a good idea if it works well. This will give more choice to deploy Tryton, a desktop/sao client. I do not think we must drop the desktop/GTK client.
But I guess we will have to customize a little bit sao because the login form will need to request the URL to connect. I think it does not hurt as far as the changes are minimal and does not prevent the current usage as a web page.


(Oscar Alvarez) #4

I think that this link can to show all possibilities: