Вы находитесь здесь    Новости nl sv pl es de fr en

PlayOnLinux 5: We want your opinion!

Tuesday 19 May 2015 at 22:17

Hi everybody!

As some of you have heard about it, we are seriously thinking about the future version of PlayOnLinux (a.k.a. PlayOnLinux 5.  The version 4 has a long history and the code contains stuff that makes it very hard to maintain. We really need to have a more stable version if we want to continue to give you the best. If we continue working on PlayOnLinux v4 we are assuming that:

  • PlayOnLinux will no longer have new features
  • PlayOnLinux may become completely broken one day

In this piece of news, I'm going to explain the option we prefer, why are we prefering it and also we are going to ask you if you agree or not.

Please read the whole article before complaining, trolling. It is a really important topic! Once you have read everything and you understand the problem, fell free to send comments and to vote.

As many of you may have heard, we are seriously thinking about switching from Python to Java. I perfectly understand some concerns and to be honest, I was the first to criticize Java even few months ago.

However there are several reasons that let us think that Java is the right choice for us:

  • Portability: We want PlayOnLinux to be accessible on Linux, FreeBSD, OpenBSD, Mac, ... and why not, being prepared to run on ARM/Android devices later.
  • Maintenability
    • Java do a lot of things to force developers to do things great
    • Java is statically typed. It is a lot easier to do simple task like refactoring, code-checking, ...
    • I have recently discovered the tools that exists Java to measure the code quality and the technical debt and to be honest, it is just impressive. You may have a look at this end of this news (SonarQube)
  • Contributions
    • We've noticed that there were hardly any contribution for PlayOnLinux v4 and we target to make some really infrastructure and guidelines so that everyone contribute. (See "infrastructure" paragraph at the end of this news)

PlayOnLinux is a lot more complex than just a GUI for wine. It is mainly a set of tools allowing you to write very powerful scripts. That is why it is a little more complicated than just a GUI for wine.

Responses to the main concerns

I don't want to install Oracle JDK or any closed program on my computer

We are going to guarantee you that PlayOnLinux v5 is compatible with OpenJDK JRE 8 (GPLv2)

PlayOnLinux will become very slow because Java is very slow

I can ensure you that this is wrong.

Java is a lot faster than Python in general (http://benchmarksgame.alioth.debian.org/u64q/python.html). Moreover, the v4 branch has a lot of non optimal code. The tests we have already done with Java is showing us than what we have developed so fare behave a lot faster that PlayOnLinux 4. To be honest, there is only one drawback: the JVM takes a little more time to start than the python interpreter.

You should have used QT! That makes more sense.

You may be right, but I'm talking about the language here, not about the graphical interface. So far, we've started to work with OpenJFX:

  • It is Open Source
  • It is customisable with some CSS
  • It supports GPU acceleration
  • We could support different skins for PlayOnLinux or imagine a Steam-Like interface. Everything is possible!
  • It is portable

Drawbacks

  • It may not be fully integrated with your Desktop theme

However, the design of PlayOnLinux v5 perfectly allows to implement several user interface and let users chose the one they want. So it is perfectly possible to implement a QT interface with QTJambi for example: http://en.wikipedia.org/wiki/Qt_Jambi. (But it is not a priority. A command line interface is more important)

Java applications are ugly, not integrated to the system.

See the last paragraph

Java is insecure, there are so many security patches

The reason for that is that Java also has a "sandbox" mod which is often used to allow browser to execute some Java code without the approval of the user. This sandbox feature has been broken in the past, and is most intended for the browser plugin. We do not want to run PlayOnLinux on your web browser, so that's fine if you do not want to install the browser extension.

 

Proposal of a new design

A image is better to start. We plan to replace bash script with python scripts.

  • Python scripts will be directly run by Java (yes it is possible thanks to Jython!).
  • We are going to get a small part of PlayOnLinux v4 code just for backward compatibility (after some cleanup of course)
  • A lot of effort are going to be made to ensure the good quality of the code.

 

So you plan to run Wine inside Bash inside python inside Java :-O.

Of course not, that is where Jython comes. Jython is not using your system python at all! In fact it is a library that compile your python code into Java class on runtime. Basically, it means than it can just run your python script directly on the Java Virtual Machine without depending on Python. In fact, there will be less layer than there are today because the scripts will be able to execute Java codes directly without needing to create any sockets or other stuff like that.

 

Tasks that have already been done so far

Infrastructure

We have set up two tools:

Programing

We have developed the following component as a proof of concept. If you agree with us, we are going to continue on that way to be able to propose you the best version of PlayOnLinux in the next few months.

  • PlayOnLinux core
    • Dependency injection
    • Unit test
  • PlayOnLinux core script management (all keywords are not yet implemented though)
    • PlayOnLinux Python script compatibility
    • PlayOnLinux Legacy (v4) script compatiblity
    • Script exemples
  • Install window (with remote downloading)
  • Other important stuff
    • GPG Script signature check
    • Complete wine registry parser (it means that you are going to be able to browse the registry with a very few line of script)
    • Wine management: Create a prefix with a progressbar, ...
    • Filesystem management (Copy with progressbar, download with progressbar)

 

Conclusion

So far, I'm pretty confident that this version can perform a lot better than v4.

  • The core we have is a lot faster
  • The scripts are smoother
  • We have a really clean code (for the moment at least)
  • We have a really clean infrastructure
  • Some external people have already shown interest in contributing to v5 code (by sending small patches)

However, I want to have your opinion about this choice. Please send the most comment as you can and talk freely. Please provide arguments with your commentary so that we can progress.

Now the time has come to comment! 

Fell free to comment here

 

Quentin PÂRIS

Комментарии

Автор Replies
Psk177 Tuesday 19 May 2015 at 23:28

Why not take a poll on what users skills can contibute first? You may discover that there are more C++ users of playonlinux that are willing to contribute instead of Java. 

 

Also would running playonlinux on docker or lxc be wise?

Quentin PÂRIS Tuesday 19 May 2015 at 23:37

Admin

@Psk177, we have excluded C++ for two main reasons:

  • Need of a scripting language easily accessible for the scripts. Jython makes it very easy for us.
  • Portability

Also, anyone that can code un C++ can code in Java, the contrary is not always true unfortunately...

Do you see any advantage of using C++?


> Also would running playonlinux on docker or lxc be wise?

That is a really good idea. I'm not sure if it is supported by wine though. We may experiment on that

Oleg Wednesday 20 May 2015 at 11:23

> Do you see any advantage of using C++?

 

+1. You can implementation all feather in C/C++ and GUI in Qt. C/C++ is faster than Python or Java. What about performance, I have good expamle http://benchmarksgame.alioth.debian.org/. 

Oleg Wednesday 20 May 2015 at 11:28

Сhange on the previous comment:

> Do you see any advantage of using C++?

Yes !!!

@Quentin PÂRIS explained the disadvantages of using C/C++. I don't see. !

 

 

Quentin PÂRIS Wednesday 20 May 2015 at 12:50

Admin

Disadvantages: maintenability, portability, integration with Python 

openfrawu Wednesday 20 May 2015 at 13:04

As long as it works better then 4.2.8. (Compatibility), I will use it. Keep up the good work!

Bar Wednesday 20 May 2015 at 14:47

This sounds like a smart move, I myself cannot say I have expireance with Java, and heard only negative commetns on the languge at large, but, it seems that you did your reserch and are aware of the issues and upsides of using it.

So the only thing to say is good luck :)

 

P.S

What about Ruby ? (Jruby, Cruby, Crystal)

Oleg Wednesday 20 May 2015 at 15:03

@Quentin PÂRIS    What are the problems about maintainability ? Yes, C/C++ isn't a simple language, but it is  a powerful language. 

What are the problems about portability ? I know several a cross-platform projects in C++ with GUI. They ary very good producs. There are a lot of libraries that provide portability, one of the most popular library Boost ( http://www.boost.org/ ).

> integration with Python 

see http://stackoverflow.com/a/1153635/4495350

Quentin PÂRIS Wednesday 20 May 2015 at 15:20

Admin

@Oleg: Have you worked on one of those project? I would be interested to have some advices on that. We also need a GUI.

About your link: I'm reading:

Interfacing Python with C/C++ is not an easy task

Have you tried one of those solution? Can I use my C++ classes in Python? What about the other way? Which solution would you recommend?

the advantage of Jython is that you donn

 

 

 

Quentin PÂRIS Wednesday 20 May 2015 at 15:26

Admin

* don't need to do anything, it is completely straightforward 

Oleg Wednesday 20 May 2015 at 15:27

@Quentin PÂRIS read http://www.boost.org/doc/libs/1_58_0/libs/python/doc/tutorial/doc/html/index.html

Quentin PÂRIS Wednesday 20 May 2015 at 15:48

Admin

Have you ever tried this personally?

Alexandru Rudi Wednesday 20 May 2015 at 22:30

Java is a very powerful language, very flexible, portable and has many language bindings.
OpenJFX is a good choice for GUI.

I have gone from C++ to Java, then C# and now I'm studying Python. All of them have strengths and weaknesses. I adore the cleanliness of the Python code. I love the portability of Java. I was spoiled by WPF bindings. I do not miss anything from C++.

I would say go ahead with the plan for PlayOnLinux 5. History has shown that trying to maintain backwards compatibility forever and keeping to decisions that were made a long time ago in completely different context can only lead to hardships and problems for all involved.

I want to see the potential this change can unleash. I say go for it. Innovation means taking chances and not being stuck in a conservatory state of mind.

Theaitetos Thursday 21 May 2015 at 1:28

It seems you've really put a lot of thought into it. Knowing your awesome work and dedication, I fully support you in this decision! smiley

Developer Thursday 21 May 2015 at 15:08

HI,

as a J2EE (Java) developer for over 10 years let me suggest you some idea:

  • Use springboot (http://projects.spring.io/spring-boot/) for the project, saves alot of time ;-)
  • Do not program in JAVA directly, use another JVM langauge like Groovy (http://www.groovy-lang.org/) (less code, faster progress, same speed, 100% compatible with all JAVA libs). You can even use JAVA and Groovy together in the same project.

 

Ronin DUSETTE Thursday 21 May 2015 at 20:01

Admin

 

As long as it works better then 4.2.8. (Compatibility), I will use it. Keep up the good work!

Compatibility (in terms of what Windows software runs in there) has more to do with Wine than POL itself.

Quentin PÂRIS Thursday 21 May 2015 at 20:40

Admin

 

HI,

as a J2EE (Java) developer for over 10 years let me suggest you some idea:

  • Use springboot (http://projects.spring.io/spring-boot/) for the project, saves alot of time ;-)
  • Do not program in JAVA directly, use another JVM langauge like Groovy (http://www.groovy-lang.org/) (less code, faster progress, same speed, 100% compatible with all JAVA libs). You can even use JAVA and Groovy together in the same project.

Yeah I've used Groovy a little. However, we are already using Jython (pretty much the same principle than Groovy, except that your are coding in Python).

We cannot really introduce a third language, it would make things really complicated. Java takes a little more time to write, but it has also many advantages compared to Groovy :)

So the idea is:

  • Use of Jython when we want to code a component that need to be done "fast" (scripts are a very good example, but other examples will show)
  • Use Java when we prefer to have something very stable with a solid and clean design

 

openfrawu Thursday 21 May 2015 at 21:51

Version 4.2.7 and 4.2.8 don't work as they should on Opensuse 13.2, doesn't refresh wine versions (no connection?). 4.2.6 works fine though. That's what I ment. 

Quentin PÂRIS Thursday 21 May 2015 at 22:32

Admin

Please go to the forum for that problem

Thomas McWork Friday 22 May 2015 at 14:27

I think it's a good choice to switch to Java. Here are my thoughts:

  • Dont'd use springboot, or spirng, or anything else that is special in any way. You should stick to the standards to keep it easy for beginners to contribute. BTW I think many things that are covered by spring and other frameworks are already offered by JavaEE which is much more common to use
  • I think you're right with the performane impact: It should not matter because Java IS fast (as soon as the JVM has started) ... and POL ist just the initialization for the native wine application
  • besides the python integration you caneven do scripting with JavaScript with the Nashorn Engine which is part of Java 8
  • SonarQube is a very good choice to measure your code quality (which would be possible with python as well, see http://docs.codehaus.org/display/SONAR/Python+Plugin)
  • You should deliver the POL package optionally with an integrated Java Runtime. Users of Ubuntu 14.04 have no ability to install OpenJDK 8 as this is not offered in the repositories so far. have a look here and vote https://bugs.launchpad.net/ubuntu/+source/openjdk-8/+bug/1341628
Quentin PÂRIS Friday 22 May 2015 at 15:05

Admin

Thank you for all your advice!

freelikegnu Friday 22 May 2015 at 22:52

I have found PoL very usefull over the years, thank you for your efforts!  On the contrary, I have never been impressed with the interface, speed, or utility of any of the Java based apps I have encountered, such as Minecraft as a recent example (minetest performance and modability beats this easily),  Please point us to a list of Java applicaitons that you think are good examples of what it can do. 

I think PoL is an example of pythons power.  I don't know much about the problems with the code underneath, but from a user experience perspective, I have never found it lacking or frustrating, which is quite a feat for a program that does so much.

Me Friday 22 May 2015 at 22:52

Java sucks, but at least you’re not switching to Gtk3… I hope. If it was my project I’d probably use Go + Qt. I only recently needed to install java to run a new RSS client after the disaster that Liferea has become.

booman Saturday 23 May 2015 at 0:59

I have loved using PlayOnLinux the last 2 years!  Its the one tool that has kept me playing games in Linux instead of Windows.  I rarely ever notice performance issues or GUI problems.  PlayOnLinux 4 has always been very reliable on my Mint computer.

I don't care what you use to develop PlayOnLinux, as long as the current tools/functionality is still there, I'm a happy gamer!

As a Windows system adminsitrator I'm always concerned about security when it comes to Java.... does the Linux Java have as many vulnerabilities as the Windows counterpart?

Keep up the hard work

Quentin PÂRIS Saturday 23 May 2015 at 1:02

Admin

 

I have found PoL very usefull over the years, thank you for your efforts!  On the contrary, I have never been impressed with the interface, speed, or utility of any of the Java based apps I have encountered, such as Minecraft as a recent example (minetest performance and modability beats this easily),  Please point us to a list of Java applicaitons that you think are good examples of what it can do. 

Well, this is mainly because:

  • Minecraft is a game. I would not use Java to write a game
  • The code must not be very well optimized

Java applications are mainly used in companies but some very powerful of Java application are:

  • Jetbrains product (IntelliJ / PyCharm / PhpStorm), which are very very strong IDE
  • JDownloader (which used to be little buggy, with memory leaks, but again it's a matter of programming, not a question of the language itself)

 

I think PoL is an example of pythons power.  I don't know much about the problems with the code underneath, but from a user experience perspective, I have never found it lacking or frustrating, which is quite a feat for a program that does so much.

You are totally right, but in the long run, there are many features that we would like to propose to the community: , like the command line interface (which will be a priority), or decentralising the program by giving the possibility to use external repositories. In fact I have a lot of more ideas but it has just became impossible to add more stuff in the current codebase.

And I mean, 8 years with such a messy code is already an exploit

Lejoni Saturday 23 May 2015 at 1:38

I do not use PlayOnLinux myself, I prefere to use Wine by itself and handle all the prefixes manually.

So I won't condone nor dismiss the use of Java for PoL5

 

But I am curious to the statement about one of the pros beeing able to port it to ARM/Android.

As fare as I know Wine dose not emulate the CPU, so it is only usable on x86/64 CPUs atm.

As fare as I know the MS Windows version made for ARM failed big time. So what would be the point?

 

 

rhaegon Saturday 23 May 2015 at 3:34

Anonymous

99% of java applications (Eclipse is the only exception for me.) that i run, GUI feels weird/slow/buggy besides RAM usage is pretty high in most cases.

 

I never used it seriously but can't be C# an option ? .NET is now opensource and it works on Linux/Mac.

https://github.com/dotnet

 

Regards.

ps: sorry for my english smiley

Hamlin Saturday 23 May 2015 at 6:09

Java is an incredible resource hog, ity consumes at least 1GB+ to run any Java program. Ontop of it being just plain sluggish and bloated it also requires downloading the Java runtime environments, I hope you at least have you sites set on OpenJDK and not OracleJava. Personally I believe you could write it in C++ just as easily and use cython for the scripting.

Quentin PÂRIS Saturday 23 May 2015 at 7:08

Admin

 

Java is an incredible resource hog, ity consumes at least 1GB+ to run any Java program. Ontop of it being just plain sluggish and bloated it also requires downloading the Java runtime environments, I hope you at least have you sites set on OpenJDK and not OracleJava. Personally

  • Current SNAPSHOT off PlayOnLinux v5 consumes 38M of Memory
  • Memory is a lot more easier to manage. Force example you can force an app not to consume more than a fixed amount of memory without touching the code source: http://stackoverflow.com/questions/417152/how-do-i-set-javas-min-and-max-heap-size-through-environment-variables
  • If you are still asking the question about OpenJDK, it means that you haven't read everything I said, so I understand why you are saying craps like that.
  • What is the difference between installing OpenJDK and installing Python 2 hum? Can you explain it to me please?

 

 

I believe you could write it in C++ just as easily and use cython for the scripting.

 

I'm starting to be sick of repeating it, but have your really developed a big C++ project? Have you tried by yourself to write an extensive cython extension for your application?
Do you have any point of comparison?

Because seriously, I've been doing development for more than ten years now (since I am 12 in fact) in many languages, C, C++, PHP, Python, Java, Javascript, etc... I am really ready to accept any suggestion but please explain clearly your state and do not state things that are really not true. 

 

 

99% of java applications (Eclipse is the only exception for me.) that i run, GUI feels weird/slow/buggy besides RAM usage is pretty high in most cases.

Eclipse (and IntelliJ also) is a good example showing that it is indeed possible ;-)

 

 

But I am curious to the statement about one of the pros beeing able to port it to ARM/Android.

This is just an extreme argument stating that once this piece of work is done, we would be ready for hardly any developement of the project we need. While wine/windows on ARM is not at the moment in a stable state, we cannot know what will happen in the future. We've seen by the past that it is totally plausible to replace one technology to another in very few time (See Apple switching from PPC to Intel for example).

 

As fare as I know Wine dose not emulate the CPU, so it is only usable on x86/64 CPUs atm.

Wine itself, nope. But for example I was able to make PPC version of Warcraft III run on a Macbook so the same thing could happen with x86/ARM in the future.

 

 

I never used it seriously but can't be C# an option ? .NET is now opensource and it works on Linux/Mac.

https://github.com/dotnet

It would not be a so bad idea I guess but unfortunately I'm not experienced enough in C# to say if we should have used it or not..

 

 

 

 

 

 

 

simion Saturday 23 May 2015 at 11:31

+1 for Java , people that want C++ should also list hte projects that they done and maintained  in c++

also I suggest to ask for license from Intellij IDEA, they offer free licenses for open source projects

Hamlin Saturday 23 May 2015 at 13:56

A big project? Haha. POL is literally just a bunch of scripts that start Wine. Don't over estimate your self worth. The fact you don't even mention Wine anywhere on this site and claim that it's your program doing the emulation/interpretation is another grievance entirely, yet it goes quite someway to show how idiotic and self inflated you bunch are.

Quentin PÂRIS Saturday 23 May 2015 at 14:01

Admin

Hey, take it easy man ;-)

  • You don't have to own a Windows® license to use PlayOnLinux.
  • PlayOnLinux is based on Wine, and so profits from all its features yet it keeps the user from having to deal with its complexity.
  • PlayOnLinux is free software.
  • PlayOnLinux uses Bash and Python.

(home page)

And....

PlayOnLinux mainly relies on WineHQ project. If you want help them and to get a professional support of wine, please consider buying codeweavers products.

(Download page)

BTW: We are always willing to listen this kind of comment. If someone involved in the wine project (or not) thinks that we should give more credits to wine, we would be very happy to do it.

Just tell me what mention to add on the website and where to add it and we are going to do it. For the time being, you are the first one to complain

If ever you have anything smart to say, feel free ;-).

Oh, and big is of course relative, but it is still quite a lot of time we are offering to the community.

Bainos Saturday 23 May 2015 at 15:05

You mention that you are ready to keep it compatible with OpenJDK, but it is also heavier that Python.

Of course, installing wine is already no small task. But once wine is installed, adding PoL was easy. I have OpenJDK installed for some few needs, but I would not be happy if I had yet another program that needs it.

On the other hand, Python is lighter and anyway necessary in many cases, so that isn't a new, necessary install.

As for the security, I don't think it's that much a problem with Java, but if it is, won't the sandbox make it even heavier / slower ? If not, and if it is really transparent to the user, just ignore this point.

 

As for the advantages of Java :

You mention portability. How is Python less portable than Java ? You could even use Jython if some platform don't have a Python interpreter.

You also cited code quality, but if you are comparing a makeshift v4 to a newly designed v5, it's really hard to have a neutral opinion.

Finally, you mention speed. Though faster is better, I don't think it's a problem for PoL, especially if you have already cleaned unefficient portions of the code.

 

I'll finish with the fact that you mention things that are already done. Just wondering, why make a poll now if you have already started working on one version ?

 

Keep up the good work. The less I have to reboot on Windows, the better for me.

Quentin PÂRIS Saturday 23 May 2015 at 15:25

Admin

 Interesting question here:

- We have estimated that we need about 50 Mo of disk space to have a full JRE. (You don't need to have the whole JDK if you are a end user). I don't know exactly how my space does Python weight (if you take into account all the dependencies), but I think it is something like 200Mo. Correct me if I am wrong.

  • For the security, it only matters if we are intending to use the browser extension, thing we are not going to do. So we do not need the sandbox feature for the moment.
  • Python is not less portable than Java, except for the GUI that can be hard to install especially on BSD and OSX. Jython is only compatible with Java interfaces so it would not help to rely on it.
  • Code quality: we have already attempted to start a POLv5 in Python. However, Python is lacking important things (too my mind)
    • Code audit tool. While pylint is great, it is not able to check some code behavior because of the dynamic aspect of the language.
    • Static typing: you save a lot of time for refactoring tasks because your IDE is aware about the whole context of your project.
    • Some abstraction concepts such as interfaces are really useful to prevent developers from making bad dependencies relationship between packages and avoid design flows.
  • Regarding the speed, I totally agree with you. That's why C++ was, in my opinion, not a good choice.
  • Finally, for the poll, I was really ready to change my mind as the beginning of the code base was more a proof of concept. however, I expected this discussion to be more challenging and answer better questions than: "You should have chosen C++, you are so dumb!"

 

Hope that makes a little more sense. What do you think? 

Bainos Saturday 23 May 2015 at 16:30

 

Hope it answers the questions. What do you think? 

I didn't think of the fact that I had JDK installed and not JRE. It changes a lot, since the JRE is much lighter. I still think that Python is often installed by default, but it no longer matters much.

I perfectly understand your arguments for the interface.

For the code quality, I think your points are valid. My personnal preference still goes to Python, and I think those problem can be avoided, but I don't expect everyone else to agree with me. Plus, I won't be the one writing the core components, so it's your call if you prefer working with Java.

Finally, for the poll, I get your points. I wasn't really following your development, so I only learned today that you were thinking of switching to Java. And I'm actually sorry that people are calling for the unneeded C++ while avoiding the discussion on Python.

 

Last thing, I hope you will do a good job with the GUI. I usually prefer the interfaces for Python applications, while Java ones are more than often ugly. And PoL is one of the few applications that look quite good with my Enlightenment DE, I'd like that to last.

Quentin PÂRIS Saturday 23 May 2015 at 16:42

Admin

 

Last thing, I hope you will do a good job with the GUI. I usually prefer the interfaces for Python applications, while Java ones are more than often ugly. And PoL is one of the few applications that look quite good with my Enlightenment DE, I'd like that to last.

It is the most challenge we have to face, indeed. The current solution is not as well integrated with the desktop environment. I have a technical solution to improve a lot this, but it requires some effort.

Also, note that the current codebase is not compatible with Python 3, and that Python 2 won't be installed by default any longer. So it is pretty much the same problem actually

Winsaucerer Sunday 24 May 2015 at 7:06

As one other poster mentioned, maybe checkout Go with Qt (https://github.com/go-qml/qml).  Go is statically typed, quite popular, easy to code in, cross platform.

Quentin PÂRIS Sunday 24 May 2015 at 11:51

Admin

 

As one other poster mentioned, maybe checkout Go with Qt (https://github.com/go-qml/qml).  Go is statically typed, quite popular, easy to code in, cross platform.

For the time being, I can't afford the risk to learn a whole new language with its best practice for this project. (The risk to create a poor quality code is too important).

But I will definitely check that out for my next projects

Yoric Sunday 24 May 2015 at 12:43

Go with whichever language makes you most confident. If you're confident in Java, use Java – as a bonus, there are many Java devs around here who can contribute.

And if you decide to switch to Rust, ping me :)

arendjr Sunday 24 May 2015 at 13:10

Anonymous

As a professional developer with experience in a wide range of languages (C, C++, Java, JavaScript, PHP, Python, Obective-C, bash scripting, assembler) and a wide range of platforms and toolkits (Windows, Mac, Linux, iOS, Android, BlackBerry, Symbian, Qt, GTK, Borland VCL), I think you have a wide range of choices which could all be suitable for this project. Java is probably the least of them.

The reason I would advise against Java is not so much about the language itself (which is fine), but more about its ecosystem. Like you mentioned, Java applications tend to not integrate well into the desktop environment. This is not just a matter of looking out-of-place due to theming, but also extends to things like respecting an environment's keyboard shortcuts or using the proper dialogs for opening and saving files. This is compounded by the fact that it is typically hard for Java code to call into native code. Sure there's JNI, but it's not pleasant to use and if you have to use it a lot you may actually wish you would've chosen a lower-level language to begin with. This creates a situation where Java applications live in their own world compared to the rest of the system.

You mentioned Eclipse and IntelliJ as good examples. I can agree with IntelliJ, but in my experience Eclipse has always been dogslow and an absolute memory hog. But neither will integrate well with the desktop environment they run in.

Also, I think you're jumping over the Java security problems too easily. Sure, you may not require the browser plugin for POL to work, but any person who installs the JRE will have that plugin enabled by default. That doesn't affect POL directly, but it is a huge part of the reason why Java has a bad name and why people prefer to leave it off their system if they can (myself included). Whether you like it or not, installing Java is a hindrance to many people and coupled with its bad security reputation it means you will drive a segment of your (potential) users away.

Having said all that, what /do/ I actually recommend? Personally I have had very good experiences with Qt. 10 years I ago when I was at university I was a volunteer in the KDE project, later in my carreer I've written a commercial cross-platform chat application with a small team of developers using a mix of Qt and web technologies and later yet I've used Qt again for writing Symbian and BlackBerry applications. Of all the platforms I've used, I have to say Qt has by far the nicest API and of course one of its great strengths is that it is relatively easy to integrate a Qt application well into various desktop environments (note it still requires some manual attention if you want to do it right). Earlier you mentioned the advantages of using OpenJFX. Well, all of those apply to Qt as well, the only difference being that Qt does not have the downside of not integrating well into other environments.

So yeah, ask me what toolkit I recommend and I will whole-heartedly recommend Qt. Some other advantages to Qt that might be relevant:

- Qt has a really good embedded JavaScript engine. If you want a hybrid model like the one you're proposing with Java/Python (one for the core functionality, the other for the more quick and dirty work), maybe you can consider C++/JavaScript instead. You will be fully able to call C++ code from JavaScript and the other way around. This is something I also do extensively in one of my hobby projects, the PlainText MUD engine: https://github.com/arendjr/PlainText

- Qt has excellent integration with Chromium, making it easy to embed web content. Want to embed some parts of your website into your application, like help documents, tutorials or even the forums? You can easily do it.

Now for the final question, what language would I recommend?

Actually I think your best bet would be to stick with Python for the most part. If you would rearchitect the core parts to clean up the code (just like you've done now with your Java POC), I think you can make it just as clean as the Java code. Also it will be easier for everyone if you're sticking to a single language. Finally, Python's Qt bindings are of good quality as well.

Also I think C++ would be a good choice. Sure, because it is so powerful it has a lot of potential to shoot yourself in the foot, but it has some real advantages too:
- Its RAII model makes it very easy to avoid memory and resource leakage. Compare this to Java, where garbage collection might have solved the problem of memory leaks, but it is very easy to leak resources.
- It is very easy to call into a wide range of system libraries (this was the main reason back when we wrote the chat application for us to chose C++ as well).
- Being Qt's native language has the advantage there are more examples and tutorials for it.
- Creating a responsive UI is much easier in C++ due to event-based programming, without having to resort to using threads all the time.

Now, in the end of course this will be your decision, as you will do the actual work. Choosing the language *you* are comfortable with is an important ingredient to success. I just hope these recommendations have given some insight into the options and choices you have.

PS.: You mentioned Qt Jambi for those who would want to write a Qt interface for your Java code, but this seems kind of a red herring as Jambi is mostly on life support and has no support for Qt 5.
PPS.: I hope I didn't sound like bragging too much, but given that some comments were explicitly calling for someone with actual experience with C++/Qt I thought it appropriate to list some of my background.

Toxic Sunday 24 May 2015 at 13:20

Anonymous

Oh boy wall of text, you mind using bullets and such to make it a bit more uncluttered?

noam.mor Sunday 24 May 2015 at 13:47

Anonymous

I believe C++ would have been possible, using something like Boost.Python as a bridge between the languages. That said, I don't see C++ as a very good language and I'd probably choose Java over it any day of the week. .NET would have been good as well.

I believe the jump from free-form spaghetti Python with no design all the way up to Java with your own dependency injection framework and continuous integration - all for what is today an application of 6000 lines of code - is a bit on the drastic side. You could have made the switch to, for example, a Python program with a reasonable design, and in my humble opinion got an easier process. 

About the Python lagnguage: Interfaces don't enable better design. The way Python works is that if two objects have the same attributes and methods, then they can be considered as if they implement the same interface. That means that if you define interfaces and concrete classes that implement them in Java, you would just define the concrete classes in Python and use them as if you had an interface. Python interfaces tend to be extremely concise compared to Java ones, because static typing the way implemented in Java neccessitates boilerplate code extremely frequently. A simple example would be the default method argument, which Java still doesn't have for some reason. 

Anyway, what I am saying is that Interfaces don't enable, they restrict. Their role is safety, not flexibility. You can do inversion of control via dependency injection in Python just as well as you can in Java. This doesn't, however, require a special framework in most cases. See here. tl;dr: Python doesn't need dependency injection frameworks that load factory classes with methods that instantiate classes loaded at runtime, because all Python classes are loaded at runtime and they can be passed around as arguments, being first-class objects. You just saved a slew of boilerplate and interfaces.

I see you're passionate about Java, and that's fine. I guess the project will benefit more from a passionate owner than from a better (in my opinion) programming language. It'll come out fine, the codebase does look very clean, and this is what matters in the end of the day. I'd still choose the language that has 1 integer type over the language that has 9 ;)

Quentin PÂRIS Sunday 24 May 2015 at 15:12

Admin

Thank your for sharing your thoughts! I'm going to try to respond to everything:

 

Like you mentioned, Java applications tend to not integrate well into the desktop environment. This is not just a matter of looking out-of-place due to theming, but also extends to things like respecting an environment's keyboard shortcuts or using the proper dialogs for opening and saving files. This is compounded by the fact that it is typically hard for Java code to call into native code. Sure there's JNI, but it's not pleasant to use and if you have to use it a lot you may actually wish you would've chosen a lower-level language to begin with. This creates a situation where Java applications live in their own world compared to the rest of the system.

 

What about the Swing native look and feel?

 

Also, I think you're jumping over the Java security problems too easily. Sure, you may not require the browser plugin for POL to work, but any person who installs the JRE will have that plugin enabled by default. That doesn't affect POL directly, but it is a huge part of the reason why Java has a bad name and why people prefer to leave it off their system if they can (myself included). Whether you like it or not, installing Java is a hindrance to many people and coupled with its bad security reputation it means you will drive a segment of your (potential) users away.

You need to install a separate package to integrate Java to your browser. This separate packet is not a dependency of PlayOnLinux.

Having said all that, what /do/ I actually recommend? Personally I have had very good experiences with Qt. [...]
Well, all of those apply to Qt as well, the only difference being that Qt does not have the downside of not integrating well into other environments.

 

Why Qt and not GTK then? I mean, it is pretty impossible to be integrated to every desktop because there are so many different toolkit on Linux. That's also a main problem for us.

 

PS.: You mentioned Qt Jambi for those who would want to write a Qt interface for your Java code, but this seems kind of a red herring as Jambi is mostly on life support and has no support for Qt 5.

Yes, you are correct. That's no longer an option.

 

PPS.: I hope I didn't sound like bragging too much, but given that some comments were explicitly calling for someone with actual experience with C++/Qt I thought it appropriate to list some of my background.

It is exactly the kind of feedbacks we need. It is definitely smarter than other comments I have seen.

 

You mentioned Eclipse and IntelliJ as good examples. I can agree with IntelliJ, but in my experience Eclipse has always been dogslow and an absolute memory hog. But neither will integrate well with the desktop environment they run in.

Just to be curious, what desktop environment are you using?

 

Anyway, what I am saying is that Interfaces don't enable, they restrict. Their role is safety, not flexibility.

You are correct. That is exactly what we are looking for. I'm really not saying that Java is better because it is easier. But what we really need is stability.
Because at the moment, if you just open PlayOnLinux bug's tracker, you will see that's it is pretty impossible to help users do to the bunch of possible different configuration that exists.

  • Version of Python
  • Version of wxpython
  • Version of wxgtk
  • Desktop environment
  • Version of wine
  • Version of wget
  • Linux / MacOS /others,
  • ...

We are trying to limitate this kind of problems.

 

I believe the jump from free-form spaghetti Python with no design all the way up to Java with your own dependency injection framework and continuous integration - all for what is today an application of 6000 lines of code - is a bit on the drastic side. You could have made the switch to, for example, a Python program with a reasonable design, and in my humble opinion got an easier process. 

Yes, that's may be true. But when you've had to maintain PlayOnLinux 4 for 8 years, you are kind of vaccinated...

I hope that this makes a little more sense, and I'm as usual really ready to discuss (here or by IM, as you prefer)

 

 

I'd still choose the language that has 1 integer type over the language that has 9 ;)

9? Really?

noam.mor Sunday 24 May 2015 at 15:25

Anonymous

My comment about interfaces referred to a specific thing you said:

> Some abstraction concepts such as interfaces are really useful to prevent developers from making bad dependencies relationship between packages and avoid design flow

And so I said that avoiding dependency, and loose coupling, are not something that interfaces add. Python having no "interface" code entity doesn't mean it can't do what you'd use interfaces for in Java.

Also, interfaces can certainly not help you with irregular wget versions and whatnot. These things should be solved by not invoking shell scripts from the application.

noam.mor Sunday 24 May 2015 at 15:27

Anonymous

Yes, 9 :-)

byte, Byte, short, Short, int, Integer, long, Long and BigInteger.

Quentin PÂRIS Sunday 24 May 2015 at 15:34

Admin

 

Also, interfaces can certainly not help you with irregular wget versions and whatnot. These things should be solved by not invoking shell scripts from the application.

wget was more a general example. I'm not talking about interface here, but more about general design. Avoiding stuff like if(operatingSystem == Linux), avoiding using external process and really controlling the version of the dependencies we are using. This is something that it is really hard to do with QT for example

 

byte, Byte, short, Short, int, Integer, long, Long and BigInteger.

That has also a good advantage in terms of memory management. I mean, try to do a for-loop in python that is just incrementing an integer and do the same in Java, you'll notice that Java can be up to 100x faster

 

noam.mor Sunday 24 May 2015 at 15:49

Anonymous

Doing direct number crunching in Python is indeed very slow, but that's not due to having only one integer type but instead due to the overhead of the language. The language being interpreted means that your machine is doing a certain operation for every operation of the application, and when the operation is as cheap as i += 1, Python will spend more time on the overhead than on the operation. This is mostly eliminated when the individual operations become expensive, e.g string operations or calling libraries. This fact can be easily demonstrated by Python being one of the 3 major languages for numeric calculation despite i+=1 being 100x faster in a compiled language.

As far as I am aware, Python code will behave the same way on all operating systems. Is that not the case?

Quentin PÂRIS Sunday 24 May 2015 at 15:55

Admin

 

The language being interpreted means that your machine is doing a certain operation for every operation of the application, and when the operation is as cheap as i += 1

In fact Java is also interpretated. The main difference is that in Python, you need to encapsulate your integer inside an object. So when you are doing something like c = a + b, you are doing ~10 operatins.

 

As far as I am aware, Python code will behave the same way on all operating systems. Is that not the case?

For the main core, I would say yes (I have seen some differences for double precision manipulation though, but it does not really matter for POL).

Also, deploying a PyQT application on MacOS X is not very easy. (It is pretty much the same as it is for wx in fact). It can break anytime when Apple releases a new version of MacOS

 

 

noam.mor Sunday 24 May 2015 at 16:06

Anonymous

Java compiles the bytecode to native at Runtime, so if you're running something in a loop, after a few cycles it will be compiled to native and what you'll end up running is compiled machine code. In fact, Python also has an implementation that does JIT compilation, and runs numeric code at around the same speed as C by eliminating the interpreter overhead. It keeps all the Python int-is-an-object semantics.

Regarding PyQt on apple systems, I can't comment. I've never done anything like that.

Quentin PÂRIS Sunday 24 May 2015 at 16:18

Admin

 

Java compiles the bytecode to native at Runtime, so if you're running something in a loop, after a few cycles it will be compiled to native and what you'll end up running is compiled machine code. In fact, Python also has an implementation that does JIT compilation, and runs numeric code at around the same speed as C by eliminating the interpreter overhead. It keeps all the Python int-is-an-object semantics.

Bytecode creation and JIT are two different things.

Python does also compile your code into bytecode for your runtime (That's why you ar seeing .pyc files sometimes). It is roughly the same principle than Java. That's also true that Java has also a JIT compiler that helps a lot.

You can also execute a

>>> int.__dict__ 

to see (roughly, because I guess there must be a lot of optimization behind that) what does a int object carry in python

arendjr Sunday 24 May 2015 at 20:07

Anonymous

 

What about the Swing native look and feel?

In my opinion it's not adequate by a long shot. It supports GTK 2.2 at best on Linux, which looks outdated on pretty much any modern distro. Of course GTK is not very nice for KDE users and Swing on Mac OS X is also subpar (I will admit OS X is impossible to get perfect without using Objective-C, but Qt at least gets very close and if you're using C++ you will have the ability to call Objective-C APIs to get some of the final details right).

 

 

You need to install a separate package to integrate Java to your browser. This separate packet is not a dependency of PlayOnLinux.

Ah, yes. It's been long since I last installed Java on Linux. On OS X at least it all comes in one package, and I suspect if you actually download the JRE for Linux from Oracle's website it will be the same.

 

Why Qt and not GTK then? I mean, it is pretty impossible to be integrated to every desktop because there are so many different toolkit on Linux. That's also a main problem for us.

 

Simply put, because GTK is terrible as a cross-platform toolkit. It looks awkward on KDE and terrible on OS X. It's nice as long as you're on GNOME or you're using Ubuntu Unity, but outside of that you will have little luck. Qt on the other hand is native to KDE, integrates properly in GNOME (it adopts the GTK event loop when available, uses GTK's own theme engine and uses the proper file dialogs, etc.) and even works decently on OS X.

Also, in my opinion the Qt API is far easier to use than GTK. It is very consistent, well documented and in many areas simply far more advanced than GTK (do I need to mention QML?).

Off topic, but you might want to consider that Ubuntu is also slowly migrating from GTK to Qt. Ubuntu Phone is entirely written in Qt, and Unity 8 will be as well. Canonical's own applications are almost all written in Qt, and it looks like they will be replacing more and more of the GNOME apps with their own in the future. In addition, LXDE is also migrating from GTK to Qt. Going forward, I think GTK will increasingly lose relevance on the Linux desktop.

 

Just to be curious, what desktop environment are you using?

My personal laptop is running Ubuntu with Unity, my work laptop runs OS X. This situation is actually kinda reversed from a few years ago at my previous job, when I was running a KDE workstation at work and had a MacBook Pro at home.

 

 

 

You are correct. That is exactly what we are looking for. I'm really not saying that Java is better because it is easier. But what we really need is stability.

You mentioned all the different versions people are using and how that is giving issues. If that's the problem you're trying to solve I recommend using static linking. Create statically linked packages and offer those on your downloads page, and tell anyone who wants to build the source themselves and/or who uses other packages, that they're doing so at their own risk.

But switching to Java to solve this problem seems like throwing out the baby with the bath water. You're throwing out a lot of old code as well as your experience with the old tools in hopes that the grass is greener elsewhere. I can imagine the current situation might sometimes frustrate you, but I have the feeling the proposed direction is actually an overreaction.

 

I believe the jump from free-form spaghetti Python with no design all the way up to Java with your own dependency injection framework and continuous integration - all for what is today an application of 6000 lines of code - is a bit on the drastic side. You could have made the switch to, for example, a Python program with a reasonable design, and in my humble opinion got an easier process.

Just quoted this to say I completely second this.

wget was more a general example. I'm not talking about interface here, but more about general design. Avoiding stuff like if(operatingSystem == Linux), avoiding using external process and really controlling the version of the dependencies we are using. This is something that it is really hard to do with QT for example

Qt will definitely help in reducing the amount of OS-specific checks and hacks you will need in your code. You may never reach 100% platform-independent code, but from my experience in this area, Qt is far ahead of the others, including Java.

 

Also, deploying a PyQT application on MacOS X is not very easy. (It is pretty much the same as it is for wx in fact). It can break anytime when Apple releases a new version of MacOS

This is true, yes. In fact, it was also one of the reasons with the chat application that we built to choose C++ over Python. Still, chosing Java is also not really solving this problem. It may be easier for you, but it's shifting the responsibility of installing a JRE to the end user. It may not be the biggest deal for many, but I think you may underestimate the wedge this drives between you and your users. In my experience, new users tend to come to your site with a mindset of, "okay, let's try to this". From that moment you better make darn sure there are as few obstacles between between your project homepage and a running application on the user's computer. People are lazy, attention spans are short, and combined with a negative connotation simply with the word "Java", asking users to install the Java Runtime Environment before they can run your application is going to cost you users.

Still, PlayOnLinux users are probably more technically adept than most users I've had experience with, so maybe I'm actually overestimating the problem. But then again, maybe more of them will actually be more stubborn about not wanting to install Java...

 

Finally, regarding the issue of interfaces and strict typing. Yes, these are nice tools for maintainability, but no, they will not by themselves drive people to write better code. If you want to improve the code quality in your project, and you want to enforce some guidelines to ensure said quality, the first thing I would advise you to do is write a document where you actually explain what your objectives are, what you expect from team members and provide pointers that will help people to write code in a way that lives up to your standards. Then, when people submit Pull Requests, review them and point anyone to this document if their PR fails to meet your expectations. It might be a little tough at first and some people might be a little grumpy when they have to change their ways, but soon you will see that people who submit repeated PRs will actually try to meet your criteria and reviews will go smoother.

The language you choose does not matter when trying to prevent your codebase from becoming a mess. When multiple people work on a project, it is a team effort to keep the quality high and you require processes to keep everyone in the team on the same page. This is something that is sometimes overlooked in an open-source project where you want to be very open and lower the barrier to participation, but it is simply not realistic to expect high quality code when everyone can do pretty much what they like unchecked. Besides, if you clearly lay out where contributors can start, and what is expected of them, it might actually be reassuring and be more inviting to them compared to a vague statement like "send us your installation script" ;)

 

That's all for now. Any way you decide to go in the future, best of luck with your project!

Cheers!

 

 

Quentin PÂRIS Sunday 24 May 2015 at 20:41

Admin

 

You need to install a separate package to integrate Java to your browser. This separate packet is not a dependency of PlayOnLinux.

Ah, yes. It's been long since I last installed Java on Linux. On OS X at least it all comes in one package, and I suspect if you actually download the JRE for Linux from Oracle's website it will be the same.

Oracle's JDK is just a standalone .zip package. You can extract it where you want and install the web browser plugin if you want. But in 2015, no ones need that.

 

You're throwing out a lot of old code as well as your experience with the old tools in hopes that the grass is greener elsewhere. I can imagine the current situation might sometimes frustrate you, but I have the feeling the proposed direction is actually an overreaction.
[...]
This is true, yes. In fact, it was also one of the reasons with the chat application that we built to choose C++ over Python.

Actually I have a little background in Python and in Java so that I can compare. I admit though that I have not enough background in C++ to be really objective. However, I've read some stuff about Python binding and it seems to be a too big amount of work for the moment.

 

Qt will definitely help in reducing the amount of OS-specific checks and hacks you will need in your code. You may never reach 100% platform-independent code, but from my experience in this area, Qt is far ahead of the others, including Java.

QT is just the GUI. We want to design our application so that the GUI implementation depends on it, not the contrary. We don't want to GUI to handle low level code.

 

Finally, regarding the issue of interfaces and strict typing. Yes, these are nice tools for maintainability, but no, they will not by themselves drive people to write better code. If you want to improve the code quality in your project, and you want to enforce some guidelines to ensure said quality, the first thing I would advise you to do is write a document where you actually explain what your objectives are, what you expect from team members and provide pointers that will help people to write code in a way that lives up to your standards.

That's what we've done so far:

  • Wiki (http://wiki.playonlinux.com). A lot of documentation has to be written
  • Github + jenkins integration. (http://www.playonlinux.org:8080) Each pull request will trigger a jenkins build, and the code is reviewed afterwards
  • SonarQube will analyse everyday the technical debt

It is really harder to implement such tools in python, mostly because of dynamic typing. Pylint is great, but there are some issues that it will not find because the language is too flexible.

 

People are lazy, attention spans are short, and combined with a negative connotation simply with the word "Java", asking users to install the Java Runtime Environment before they can run your application is going to cost you users.

For this problem, what we plan to do is:

  • Bundle OpenJDK for MacOS X (I still need to ensure that it is possible though but I think it should be fine). (~ 50Mo which is less than the space the dependencies taking at the moment) 
  • Have two standalone version for Linux
    • With OpenJDK bundled
    • Without OpenJDK bundled
  • Make Linux distribution packages depend on OpenJDK

 

For the UI, I still agree with you. What do you think about program like Steam that have their own GUIs?

 

Many thanks,


Cheers

Quentin PÂRIS Sunday 24 May 2015 at 23:18

Admin

By the way, what is the name of you chat application?

arendjr Monday 25 May 2015 at 0:31

Anonymous

 

QT is just the GUI. We want to design our application so that the GUI implementation depends on it, not the contrary. We don't want to GUI to handle low level code.

Note that while it's perfectly fine to use Qt just for the GUI, it doesn't have to be like that. Qt is also divided into modules, so you could say that the core of your application may only depend on Qt Core. This way you also leave open the possibility of adding different GUIs later on.

 

It is really harder to implement such tools in python, mostly because of dynamic typing. Pylint is great, but there are some issues that it will not find because the language is too flexible.

All the same tools work with Python as well, but you're right, you won't have static type checking then. This is something you probably have to compensate for by doing more rigid code reviews and by writing unit tests. On the upside, with Python there typically is less code to begin with, so you do have less to review in that sense.

 

For this problem, what we plan to do is:

I've never seen another application actually bundle the JRE with the installer, but I agree, if you can do it that should be the way to go.

 

What do you think about program like Steam that have their own GUIs?

I'm not against applications that are themed to have a completely custom style. In that case the style should be unique and be part of the identity of the application. It's something that works particularly well for games and media players, for example. Also, if you can pull it off, it's a nice way to sidestep the problem of having to match a bunch of different native OS themes.

Steam mostly gets away with it. Most of the application is themed in its own style and that's fine, but somehow I feel the menus just don't seem to fit in. Functionality-wise I'm just annoyed I can't quit Steam with Ctrl+Q unlike every other application.

 

By the way, what is the name of you chat application?

It was called Hyves Desktop and was actually a little suite containing a chat application, desktop notifications and a photo uploader for the Hyves website. Hyves was for many years the biggest social network of the Netherlands, until Facebook took over. At the peak we had 11 million users, though I think less than a million installed the Desktop suite. I was at the company for over 5 years, and besides Hyves Desktop, I've also worked on various features in the backend, frontend and the mobile apps.

 

UncleSteve Thursday 28 May 2015 at 3:09

IMHO if you're good at both py & Java, especially when it comes down to efficient resource usage, it's less important than getting your logic right. I'm mostly a dot net coder and have never touched Java but I know py and C++ reasonably well and the biggest quantum leaps I have managed to create are those that result from rewriting the whole wretched thing after years of maintaining it, because you learn about users' paths and your own logical processes and how they differ.

So start with the pseudo, prove it out with a good test suite, have at it in whatever language you know best and keep up the good work. I just install MS Office 2010 on elementaryOS thanks to POLv4 (I couldn't stand the crumminess of Libre, sorry...) so I'm thrilled either way.

ramon Thursday 28 May 2015 at 11:47

Hello. playonlinux is realy great. i found it and can work with some windows programs. realy good thank you.

there is only one thing that i would find interesting to have on linux. that is SILVERLIGHT.

there are some sights that only let me in when i have installed silverlight. i can not install with playonlinux. is there a way (in the future) or an alternative. Thank you.

Pseudo Monday 1 June 2015 at 21:48

This is maybe a little late, but here I go:

All in all I like the idea to make the code last long. Good thing, go for it.

A Java core hm... well okay. I'm not a big fan, but there are some okayish reasons. Did you consider go (https://golang.org/) or something like that?

A Java GUI: If you use qtjambi, it may work even on OSX. Qt is afaik the only cross platform framework that looks and feels relatively okay on OSX. So if you want it to be accepted there, this is probably your only chance (Otherwise you could ignore OSX). OSX users are demanding. Still not a big fan of java here. Java and GUIs has always been a pain from a users perspective. Maybe you can prototype something that can be tested on different systems to select a technology for this. I don't know. I'm still sceptical about this.

Anyway I really like this project, I hope whatever you do works out.

Quentin PÂRIS Monday 1 June 2015 at 23:00

Admin

Hi!

The current PlayOnLinux v5 looks like this in MacOS X (we are not using Swing but JavaFX which looks a lot better) (don't pay attention about the left panel, it is just a test. Also the java at the top will be of course changed to PlayOnMac):

What do you think? Will the users accept it?

Personnaly, I think it is not too bad (PlayOnMac 4.x did not support fully retina screens at used old Mac OS widgets)

kishan Wednesday 3 June 2015 at 10:24

it looks clean and simple, i like that maybe other users also like it

Gostei Thursday 4 June 2015 at 20:28

Gostei.

z166 Thursday 4 June 2015 at 23:45

C++ and Qt and QML(not QtQuick)/QtScript or Lua(Luajit) for scripting?? Please... you are programmers, right?

Nukem Friday 5 June 2015 at 0:00

It seems that a lot of people commenting prefer C++.

And it also seems that the only real argument against it is the lack of Python integration...

 

Has nobody heard of Cython? http://cython.org/

If I were to contribute, I'd much prefer to use C++, QT5, and Cython.

ZiglioNZ Friday 5 June 2015 at 0:14

I've had a lot of fun learning DukeScript over the past week. It's an interesting technology as it allows portability not just on desktop platforms but on mobiles too.

The layout is specified in html (but you can use FXML if you stick to the JavaFX browser).

There's two way binding between the frontend and the Java model. You can use any javascript library with it and access the underlying hardware from Java.

So far, I'm loving it!

 

Quentin PÂRIS Friday 5 June 2015 at 0:25

Admin

 

It seems that a lot of people commenting prefer C++.

Please count, because I'm not sure. Also, take into account all reddit posts.

And it also seems that the only real argument against it is the lack of Python integration...

 

Has nobody heard of Cython? http://cython.org/

Come on. Please. It is easy to give the name of a piece of technology, it is harder to really implement something.

 

Let's be clear: We have never intended to write PlayOnLinux in C++, never asked about this and I will be the last person that will write a single line in C++ for this project.

This debate was more about Python/Java stuff. It is not the same amount of effort to maintain a program written in C++. than in any other language.

 

If I were to contribute, I'd much prefer to use C++, QT5, and Cython.

Are you really willing to contribute? In this case, can you give me some links about project you've contributed?

Many thanks.

Snz Friday 5 June 2015 at 0:26

C++ is a bad language. It evolved as a bad hack on top of C and it has gone out of hand. Java is a nicely designed language. It's a bonus that people that prefer C++ don't want to contribute to the project; you don't want them to contribute either. http://harmful.cat-v.org/software/c++/linus

ssokolow Friday 5 June 2015 at 0:39

Anonymous

Eww... and I was planning to offer patches to fix various UI/UX warts this August.

Screw that. I get more than my fill of Java with my university courses.

While I agree that POL has a lot of suboptimal code slowing it down and that Python's runtime is slower and its syntax less amenable to static analysis, Java GUI toolkits like Swing and SWT seem to be much more sluggish and wasteful or system resources than something like PyGTK or PyQt and I've never found a Java app that felt as native as something based on PyQt or PyGTK. (And given that SWT wrapped GTK+ last I checked, that makes me worried about the actual performance to be had with QTJambi.)

That lack of nativeness is something OpenJFX sounds like it'll only exacerbate... plus, half the time, I'm playing Windows games because the GPU acceleration my native Linux games rely on was broken by an nVidia driver update I forgot to opt out of and a desktop session I can't afford to log out of for weeks on end.

Given how I generally don't use the scripts anyway and the only Java apps on my system are Minecraft, JDownloader, and TraNG (none of which I leave running for long), maybe I'll just write a simple Wine prefix switcher GUI in Rust, since it's even better at ensuring good code than Java and I don't mind if they're still bringing the Windows side of things up to snuff. (Or at least partly from scratch in 3.x-compatible Python with Travis-CI integration testing and Scrutinizer static analysis, given how much work it'd be to retrofit the POL codebase on my own.)

(I could always keep POL around just to generate the prefixes before my own GUI takes over responsibility on the rare occasions where the old versions called in by the scripts don't blow up when exposed to PulseAudio.)

Michael Van Niekerk Friday 5 June 2015 at 0:46

Java developer here:

Have you looked into Groovy? I understand that you're looking for a static typed and static checked language. If you use the @CompileStatic tag in a class then it is statically compiled. IntelliJ and Eclipse has excellent Groovy support. Then there is the GroovyFX library also, plus the SwissKnife library for Android.

I cannot tell you enough how much Groovy kicks Java's behind in all things. You can write Java code in Groovy and it will be perfectly compatible Groovy code, as Groovy is a superset of Java. But then you could write Groovy code and use AST transforms and significantly reduce the amount of boilerplate code. Don't forget GPars for multithreading.

Java8 is even far behind in the language games VS Groovy from two years ago. Groovy, it is Java done right.

ssokolow Friday 5 June 2015 at 0:47

Anonymous

I should clarify. I'm already planning to either write my own modular launcher or extend someone else's, so replacing POL for me would just be a matter of writing a replacement for the "Install a non-listed program" wizard and a "multi-prefix Wine" backend for the launcher itself.
 

Michael Van Niekerk Friday 5 June 2015 at 1:03

And while I'm harping on about Groovy - Netflix uses it exclusively for their systems. All the way up to the Android client.

Then there is Grails and Gryffon which uses code by convention to make database applications extremely easy. It also has reactive client libraries making async work effortlessly.

Quentin PÂRIS Friday 5 June 2015 at 1:04

Admin

@ssokolow

We know that it is a real challenge because very few user oriented application did it. But we want to take our chance. For JDownloaded and stuff, you might try to have a look at -Xmx JVM option will limitate the amount of memory it takes. In fact, Java is by default memory consumming because it considers that if you have enough memory, there is not point to waste CPU cycle to run the garbage collector. (It's a bit more complicated than that, but the idea is here)

@Michael Van Niekerk

We have chosen Jython instead of Groovy for backward compatibility. It should also be good I think

ssokolow Friday 5 June 2015 at 1:07

Anonymous

Actually, for apps like JDownloader, I'm more concerned about the small but noticeable lag in every GUI operation and the weird quirks in how the GUI looks and behaves... even after switching to the JD2 beta massively improved things.

(I have 16GiB of RAM so I can run 4 or 5 modern.ie testing VMs in parallel and I don't leave JDownloader running while I'm working, so the GUI latency and "nativeness warts" are a bigger issue.)

Quentin PÂRIS Friday 5 June 2015 at 1:09

Admin

Would you mind trying with the current PlayOnLinux 5 codebase to see if you feel the same problem? (Except for the non native look & feel, we are thinking about this issue)
(Beware, the code is at a very experimental phase atm)

Sanne Friday 5 June 2015 at 1:18

Hello,

I'm a big fan of PlayOnLinux and I'd dare say a very strong developer on the Java platform, often contributing to several open source projects (both for hobby and professionally).

No doubt Java can be a memory hog when programmed as a first year student but it's not true like some comments state that it requires a GB of memory, nor that it's easy for a C++ application to be faster (but that's possible); the good news is that when such things happen, you have great tooling to help fixing it and I might occasionally give a hand as well.

Still, I'm very surprised!

Java is perceived as slow as it starts slowly; for this reason it's avoided to use Java (or other JVM based languages) for short running command line tools.. it would be foolish to try making something like a "better grep" in Java. And while JavaFX is improving things, it's historically also not widely used for desktop integrating components.

A strong point of Java is in the very strong ecosystem of libraries to build server side services.

There is no technical reason to not build something like PlayOnLinux with Java, but I'd warn that since it's an unusual fit, you'd be pionerring some new ground and you might also have a hard time to find libraries fitting your need.

I only have very limited experience with Python, but I always thought that Python would be the perfect language for your kind of tool :-)

Seriously: why would you need cross-platform? I'd highly prefer to see it great on Linux, the other platforms have their own installers and game developers don't really need helping as they have enough financial motivation to get it done.

If you still think to go ahead, consider me on board to help with the database and search engine, I know a thing or two on making these very efficient and user friendly ;-)

Quentin PÂRIS Friday 5 June 2015 at 1:24

Admin

Hey Sanne! Many thanks

Just to answer to your question, we have people from FreeBSD that are asking for a version of PlayOnLinux. And also, a significant part of script contribution come or have come from MacOS X users. There is not reason to exclude them. Also portability is only one argument.

As always, your help is very appreciated :) Feel free to contact me if you want more details

harry Friday 5 June 2015 at 1:24

I totally understand the need for static typing. Having developed a lot of code in C++, I see why it's not an ideal language for beginners and Gui stuff (even with Qt - nowadays, I'd probably separate Gui and core and use qml for the former, but didn't try that, yet) . That's why I used Python and pyQt for post simulation data viewing. The slow parts were speeded up using cython. Nevertheless, I always preferred the okay of a compiler, that the code is correct (modulo logic, of course). That's why I'm very excited of rust and using it for new projects. The compiler is very powerful and does a lot of memory related checks. It's nearly impossible to produce bad code in this language. Also, it will work on anything that can discriminate ones from zeros. And you don't have to bundle any runtime.
Michael Van Niekerk Friday 5 June 2015 at 1:28

Groovy to supplement/replace the Java parts, not the Python parts.

Seeing as you are running the Python scripts on a JVM and providing interfaces to it and your other JVM code, then nothing will prohibit you in using other JVM languages such as Scala, Kotlin, Groovy or Javascript (Nashorn) for your plugins in a polyglot manner (as all these will be interpreted my your JVM).

 

Too bad that RoboVM hasn't made the transition to desktop yet in a significant manner. You'll put all the "Java is slow" naysayers to bed as you'll be running native binaries.

 

 

harry Friday 5 June 2015 at 1:45

Java on the desktop is quite alien and didn't really traction the last 10-20 years. One reason was the look and feel and the other Java GUIs being sluggish and startup being slow. Of course Java isn't slow at server side, where I see it's main purpose nowadays. Also, I know a few people doing numerics using Java.

By the way, the Java GUIs I know I personally find horrible : Matlab and Maple. There is even a GUI bug in Matlab which makes it render incorrectly on gnome 3 and unity. So much for code once, run everywhere.
Quentin PÂRIS Friday 5 June 2015 at 1:47

Admin

@Harry: Here is a small video of what it looks like: https://www.playonlinux.com/images/IMG_1305.MOV

It's hard to see exactly if it is sluggish or not, but it may give you an idea

ssokolow Friday 5 June 2015 at 1:51

Anonymous

I don't have time to set up a testing environment but, if you can provide simple instructions for setting it up for testing on Lubuntu 14.04 without trampling my existing PlayOnLinux setup, I can make time.
 

Quentin PÂRIS Friday 5 June 2015 at 1:53

Admin

Unfortunately, OpenJDK 8 is not part of Ubuntu 14.04.

I can come up with a standalone package this week-end if you want

ssokolow Friday 5 June 2015 at 2:09

Anonymous

Sure. Just PM me when it's ready so don't have to keep polling this thread for updates.

ssokolow Friday 5 June 2015 at 3:26

Anonymous

Oh, a couple of other questions on the whole Python vs. Java thing. I understand the appeal of being more native if you should choose to support Android in the future, but I'm curious about how you evaluated the possibility of staying on Python.

First, I'll definitely grant that static typing allows more thorough static analysis, but I'm curious about whether you've considered...

  1.  The Rope refactoring library for Python with the appropriate IDE binding.
  2. One or more Python-capable "free for open-source" continuous static analysis offerings like Scrutinizer, CodeClimate, Codacy, or Landscape (Especially Scrutinizer. They've got a very comprehensive set of checks you can turn on.)
  3. Flake8+PyLint plus an IDE static analysis harness like Syntastic for Vim.
  4. Migrating to Python 3.x and using MyPy to validate the recently accepted PEP 484 syntax for optional type annotations?

Second, last I checked, it was possible to bundle up both GTK and Qt applications for mac using py2exe and py2app and, on Linux, the bindings are already in the packaging systems.

I've personally bundled up PyGTK apps for Windows using py2exe and it was a fairly simple process while practically every RenPy visual novel I've ever received in some sort of bundle has been a "universal zip" containing a bare launch script tested to work with both Linux and OSX default Python versions, a py2exe launcher containing just the launch script, and a shared set of everything else.

I'm curious what criteria you're evaluating for portability.

My main concern, performance-wise, with Java GUI apps is that, given how I/O-bound a GUI is, I worry that something about the design or implementation of either Java or all of the major Java GUI libraries makes it difficult or impossible to avoid embarassing levels of CPU overhead, even when SWT is wrapping a library like GTK+ which runs like lightning if I access it via the Python bindings in my own creations.

(And I trust that, for any HTTP work you'd be doing in a Python app, you'd already be using the asynchronous, native-code HTTP support offered by GTK+'s libgio and Qt's QNetworkAccessManager.)

Volerig Friday 5 June 2015 at 6:45

Have you considered to use Gradle instead of Maven ? It's very easy to learn and the build files are much more easier to read (no more XML).

Ronin DUSETTE Friday 5 June 2015 at 6:53

Admin

I would like to note that POL being written in Java has absolutely nothing to do with performance of applications running through Wine. Any overhead would not get in the way of performance of the actual program running through Wine, just like with Python; even though POL does a lot more than just act as a GUI, it still, in the end, launches Wine, just like normal. POL doesn't interfere with Wine; it configures it (or rather, configures WINEPREFIXes for use with Wine, though that is a terse answer). 

PS: This comment may seem out-of-place, but for those that are not programmers, that may have been a concern if the specifics of POL's functions in relation to Wine were not known. ;)

johan Friday 5 June 2015 at 9:35

Honestly, i think this is a waste of time.

PlayOnLinux doesn't need any "speed" like all of you are mentioning. It's a gui and a script framework rather than a realtime application, so performance isn't something you should see as important.

Also, there's alot of talk about how portable Java is, but the fact is that Python is just as portable. I don't see this as an argument really. Also, static typing is in the works for Python 3.5 so this isn't really a pro either.

You are also talking about how easy it is to use JPython. Sure it's easy compared to doing it in C/C++, but it still is way harder than just handling the scripts  in python itself.

It seems more like that you are looking for a core redesign and just want to switch language for the heck of it. Do yourselves a favor and just do a redesign/overhaul of v4 and you will save yourselves hundreds, if not thousands of hours. There is so much improvement to be done in POL, and i don't see how a rewrite in Java would be worth it at all.

I don't use POL though and am only using Wine, but i'd like you to hear my 5 cents anyway because your project is still awesome.

Quentin PÂRIS Friday 5 June 2015 at 9:50

Admin

 

Honestly, i think this is a waste of time.

PlayOnLinux doesn't need any "speed" like all of you are mentioning. It's a gui and a script framework rather than a realtime application, so performance isn't something you should see as important.

Indeed we don't need more speed. We are just responding to the argument "Java is slow", which is false.

Also, there's alot of talk about how portable Java is, but the fact is that Python is just as portable. I don't see this as an argument really. Also, static typing is in the works for Python 3.5 so this isn't really a pro either.

Python itself is portable. For all the librairies, the reality is different.

Let see for POLv4

$ grep "POL_OS" ./ -r|grep -n ""

The operating system is tested not less that 174 times. (I must admit than POLv4 is not a reference, and could be optimised though.)
Type hinting != static typing. (Or I've missed something very important)

You are also talking about how easy it is to use JPython. Sure it's easy compared to doing it in C/C++, but it still is way harder than just handling the scripts  in python itself.

That's true yes

It seems more like that you are looking for a core redesign and just want to switch language for the heck of it. Do yourselves a favor and just do a redesign/overhaul of v4 and you will save yourselves hundreds, if not thousands of hours

Already tried, twice i, and evidences are that we are far faster with Java. We takes a little more time to develop basic stuff (HashMap is a pain compared to python dictionaries for example), but we save a lot of testing time

Also, the fact that Java is a bit slower to write force us to think about how the code will be designed. If you look at POL-POM-5 repository, you cannot deny the fact that the current codebase is pretty clean.

There is so much improvement to be done in POL, and i don't see how a rewrite in Java would be worth it at all.

A clean codebase would surely help.

I don't use POL though and am only using Wine, but i'd like you to hear my 5 cents anyway because your project is still awesome.

Thank you :)

 

Quentin PÂRIS Friday 5 June 2015 at 10:02

Admin

 

First, I'll definitely grant that static typing allows more thorough static analysis, but I'm curious about whether you've considered...

  1.  The Rope refactoring library for Python with the appropriate IDE binding.
  2. One or more Python-capable "free for open-source" continuous static analysis offerings like Scrutinizer, CodeClimate, Codacy, or Landscape (Especially Scrutinizer. They've got a very comprehensive set of checks you can turn on.)
  3. Flake8+PyLint plus an IDE static analysis harness like Syntastic for Vim.
  4. Migrating to Python 3.x and using MyPy to validate the recently accepted PEP 484 syntax for optional type annotations?

I must admit that I did not have a chance to look to all the thools that can help python codebase to be improved. I'm going to have a look, it could be very interesting.

 

The advantage I can see with Java is also the fact that it has a lot of coding constraints. Static typing / hinting is one thing, but forcing developers to write cleanly is also very important.

 

Second, last I checked, it was possible to bundle up both GTK and Qt applications for mac using py2exe and py2app and, on Linux, the bindings are already in the packaging systems.

Yes it is. For QT, the integration is not that bad. It is really close to wx things. The main disadvantage is that it can break when Apple release any version of new hardware (things that happened in the past for POL: Retina screen, 64bits support, drop of I-don-t-remember which version of python that forced us to bundle one). Also, a good integration with the OS means some kind of hacky code using low level cocoa librairies. (See __boot__.py file in current PlayOnMac package)

 

GTK looks very bad on OSX

 

My main concern, performance-wise, with Java GUI apps is that, given how I/O-bound a GUI is, I worry that something about the design or implementation of either Java or all of the major Java GUI libraries makes it difficult or impossible to avoid embarassing levels of CPU overhead, even when SWT is wrapping a library like GTK+ which runs like lightning if I access it via the Python bindings in my own creations.

I will make you try the current GUI this week end. You can also have a look at this video:

https://www.playonlinux.com/images/IMG_1305.MOV

 

 

(And I trust that, for any HTTP work you'd be doing in a Python app, you'd already be using the asynchronous, native-code HTTP support offered by GTK+'s libgio and Qt's QNetworkAccessManager.)

Hum no, the UI should be a dependency of the project, not the contrary. We want to be able to change the UI whenever I want without have to change a single line of code in the the core. I can see people coming that are going to explain me Oh yeah, QT is separated into packages, you can keep only the network part, etc...

I'm not sure that this kind of people would be happy if we decided to use QT for the GUI and GTK for the networking part for example.

 

Blue-Tiger Friday 5 June 2015 at 11:34

I've programmed for more than 15 years now, and have experience in both Python and Java. PoL is an awesome tool, so first of all thanks for developing it. Here are my thoughts:

 

1. Execution Speed doesn't matter

Much of the discussion here circles around performance. I honestly don't get that. PoL isn't a number cruncher and doesn't do any expensive computations. I don't get why we're even focusing on execution speed. From what I can tell (as a user) it's a GUI, so it's waiting on user input 99.99% of the time. Python isn't a very fast language, and yet current PoL versions run just fine. And both computers and Python implementations (e.g. PyPy) are only becomming faster, so by the time of PoL5, this will be even less of an issue.

So okay, maybe you're thinking about running on ARM in the future. However, current ARM CPUs are quick, and by the time "PoL on ARM" becomes a topic, they're likely on par with a desktop machine today. Honestly, a Cortex A15 machine is already a usable desktop, and is definitely quick enough to run a GUI written in Python.

 

2. Portability

You say you want to run PoL on Linux, *BSD and ARM.... well, Python runs just fine on those. But from what I gather, your main issue is a GUI library. I have no experience on how well wxPython runs on Macs, and it seems that is the main source of problems for you. So I don't know what to say.

But please keep in mind that Java has the same problems. Swing usually provides terrible user experience. Using "native mode" typically doesn't help, as there are many small incompatibilities that you don't notice at a first glance. Yes, there are alternatives to Swing, most notably JavaFX. I honestly haven't looked at them in detail and don't know too much about them to comment. But looking at AWX and Swing, Oracle/Sun don't have the best track record with getting "native" GUIs right. Eclipse's SWT does seem to be better, but I don't know anyone outside Eclipse using it, so I don't know what to think about that. But Eclipse itself is a pretty ressource hog on my machine. If that is due to SWT or not I don't know.

 

3. Java on Linux

Given the name of the Project (PlayOnLinux), I assume that Linux is still your main target audience. Now this may be just my own impression, but Java just isn't a first class citizen on Linux. Of course OpenJDK exists and is packaged in all big distros. But outside of programs that you use for Java development itself, how many programs on Linux can you name that are actually written in Linux? I can't come up with a single one! How many distros can you name that include OpenJDK in their standard distribution? I know that on Ubuntu at least I had to install it afterwards. Meanwhile Python is part of the basic install in just about every distro. I think those are good hints on how popular Java is in the Linux community.

 

4. More Contributions

For the reasons mentioned under "3", if you want to increase the number of contributions you get, Java is probably not the whisest choice. Yes, most people out of college will have learned Java at one point, but many colleges (at least in the US) have already switched (or are in the process of) switching to Python. Plus it's IMHO easier to learn. So the potential number of contributors might be the same. But in general I think the open-source community is much larger for Python than for Java. I don't have any numbers of experiences to back this up, though.

 

5. Maintainability

I agree that static typing is a big boon in large projects, and Java has a lot of great tooling. So that is definitely a plus. It's worth pointing out that starting with Python 3.5, Python will have the option to include type hints as well, which might improve the situation for Python, and that it is definitely possible to write large codebases in Python.

 

CONCLUSION

I personally think that Java is not a good choice if your main target audience is Linux. Java GUIs are often iffy, but if C/C++ is out of the window and wxPython/qtPython don't work well on Macs, then I'm out of suggestions.

In the end it is your project, and you need to pick a language that you think is good for the job. After all, as long as the end-user experience doesn't suffer, it doesn't really matter what you pick.

 

AmmarkoV Friday 5 June 2015 at 12:10

Rewritting the whole code base is a poor decision
Switching to Java is a very poor decision

This will most probably cause a fork of the project at some point imho ..

nikiiv Friday 5 June 2015 at 12:53

I looked at PoL5 code and hats down, it is very well organized.. I am not going to comment PoL4 as it will be unfair to compare something carrying several years of legacy and something started out fresh.

I do both Python and Java development (alongside Scala and Haskell)  and albeit Java is less fun to work with (well after so many years doing core Java I am just tired of it, started it 18 years ago) I completely do support their move to Java. JavaFX (or OpenJFX as PoL will use) surely can produce very slick UI and I wouldn't worry a bit about desktop integration, that is handled perfectly.

Frankly if I didn't hate Java in the guts I would join the project, but Java doesn't excite my anymore... Still Java is a great choice, rock solid and dependable for this project.. As would be Mono/C# for example.. 
I am not saying that Python is not up to the task, but the project had had issues with code quality and I've found that forcing same style in Java is far less easier than in Python

I am going to finish with something erratic.. Have you guys considered going with TypeScript and 
qooxdoo for UI?

nikiiv Friday 5 June 2015 at 12:56

Jeasus.. to correct my self..

Forcing same style in Java is far easier then doing the same in Pythin.. And I am not talkning about PEPs..

Refactoring.. I've tried all available commercial and open source IDEs and none of them is up to the taks of doing full scale refactoring..

oleid Friday 5 June 2015 at 13:30

I know this isn't a wish-list and the move to Java is already decided... but anyway:

I'd choose a typed language over an untyped any time, if the program is going to be larger than a few 100 LOC.

If there is really a problem with code quality, I'd go with something like rust(*). You'll also get rid of memory leaks at the same time, too. Coming from C++, I'm using it for new stuff and so far, I like it a lot. The compiler is very helpful and like C++, you can code for any machine out there (I've even seen examples of µc-programming using rust).

When using rust, you can create the GUI in Qt/QML. That yields a nice separation of core and GUI stuff.

For the user scripts, I'd probably investigate the usage of lua. It's quite embeddable and compiles to a few 100 kiB. So in total, I estimate the resulting binary to be around a few megs + sizeof(Qt).


(*) I know, it's still young, but it has convincing features and there is already a working version of PlayOnLinux so there is no pressure to release something *now* in case developments takes a bit longer.

oleid Friday 5 June 2015 at 13:39

Cosidering GUI seperation: You could also think about a native cocoa GUI for MacOS and something Qt-ish or GTK+-ish for Linux. There are bindings all around.

 

Treeview example in GTK+/rust

Factorial example it Qt/rust

 

Willi Burkhardt Friday 5 June 2015 at 14:32

Hi all,

I may be a bit late to join the discussion but I think you miss one important aspect of it. Besides you already seem to have taken the decision. 

The whole discussion just circled around preferences of programming languages. This misses the point. If I understand your architecture graphic correctly, you do not plan to ditch python completely, you plan to have python running on top of Java. If I understand this correctly, you will just get another programming language "on board".

In my humble opinion this just the diametral opposite to your goals of Portability and Maintainability. You'll have to add "Version of Java" to the possible configuration options in your project. Taking up the argument of speed: Do you honestly believe that running  python on top of java makes it faster?

You will not automagically get a better program just because it has JavaTM inside. It is also possible to write bad style java programs. 

If you would switch to C++ I might think about contributing.

Nick Friday 5 June 2015 at 15:18

@Willi, if you read well, it is stated that they won't run python on top.

jython just brings the python syntax to the jvm

doesn't matter Friday 5 June 2015 at 17:43

Hi,

i'm having to questions - but first thanks for all of your work! I sent you a tipp someday in past...

  • Are you having a time schedule until the first new version is availiable?
  • Is there a chance for using lts enablement stacks and PlayOnlinux/Wine? Till now it seemed not possible because not responsible depedencies...

thanks!

dsp Friday 5 June 2015 at 19:15

PlayOnLinux has enough situations a file needs to be chosen (such as .EXE for app installation, for example).
Java JFileChooser's UI is extremely cumbersome to use, especially compared to current GTK+2 chooser, which is the file chooser my entire environment uses, save for a few GTK3 applications.

Please consider using something that is not JFileChooser for choosing files.
inukaze Friday 5 June 2015 at 22:30

The unique thing i tell here , i am simple user and Java kill my pc , because a Mega Super Excevise use of Resources of my pc .

 

For Example :  JDownloader / JDownloader 2 Beta , Wakfu  , aTunes

i prefer software make it in C/C++ , because , its too much faster , and use a few resources of my system like

 

Tucan Manager , Guayadeque .

 

I can't use well , because the system take about 45 mins in reacts after i start a process using Java

 

But if you make it in Java , please make it full faster for system with 512 MB Ram , 32 MB Video , and Processors of 600 Mhz , just for make it faster for computer with more resources .

 

Because for much users if you use Java + Wine + Windows Game , this can be a mess and waster of Processor and ram memory , depending the windows game .

 

i now by own expericience , Java Linux Native , consume much than Java for Windows .

 

I prefer you use Python + Bash , in the next version , and you can include inside your package , things like python2, python3 , cython , because if simple , very util , and very faster :D

 

 

Quentin PÂRIS Saturday 6 June 2015 at 2:03

Admin

@Blue-Tiger: MANY thanks for your long comment, you made my day. This is exactly the kind of reaction we are looking for. At last we have some things to discuss about. 

 

1. Execution Speed doesn't matter

I won't come back to this point because I totally agree with you. It was just to say that performances should not be a huge problem with Java

 

 

2. Portability

If fact Python is supported everywhere. (It is a C program, you can compile it as long as you have the required libraries). However, on OSX, you still need to bundle it in your .app. So you can assume and do as if it is not included on the OS, even if it is in reality.

 

 

But please keep in mind that Java has the same problems. Swing usually provides terrible user experience. Using "native mode" typically doesn't help, as there are many small incompatibilities that you don't notice at a first glance. Yes, there are alternatives to Swing, most notably JavaFX. I honestly haven't looked at them in detail and don't know too much about them to comment. But looking at AWX and Swing, Oracle/Sun don't have the best track record with getting "native" GUIs right. Eclipse's SWT does seem to be better, but I don't know anyone outside Eclipse using it, so I don't know what to think about that. But Eclipse itself is a pretty ressource hog on my machine. If that is due to SWT or not I don't know.

Can you try JavaFX one day? The only drawback is that it does not look native. Thing that we can overcome by customising POL as Steam and many gamers apps are doing.

 

 

3. Java on Linux

Given the name of the Project (PlayOnLinux), I assume that Linux is still your main target audience.

The name of the Mac OS version is PlayOnMac. And the name of the BSD one.

 

 

Now this may be just my own impression, but Java just isn't a first class citizen on Linux. Of course OpenJDK exists and is packaged in all big distros. But outside of programs that you use for Java development itself, how many programs on Linux can you name that are actually written in Linux?

If the community is reacting like this when a Java developer try to contribute to the Linux community, I can fairly understand that there are not Java applications on Linux...

 

 

I can't come up with a single one!

IntelliJ, Eclipse, Netbeans, JDownloader, Libre office uses Java also

 

 

 

How many distros can you name that include OpenJDK in their standard distribution? I know that on Ubuntu at least I had to install it afterwards. Meanwhile Python is part of the basic install in just about every distro. I think those are good hints on how popular Java is in the Linux community.

Python 3 is, PlayOnLinux does not work with Python 3. Same for wx, and many other dependencies in fact. We cannot target to use only the packages that are directly available in every distribution. If we are doing that, we are dead. The best option is to make the number of dependencies as low as possible.

 

 

4. More Contributions

The 8 past years showed us that it is not because POL is written in Python that there will be a lot of contribution. The fact that it is easy to learn is important but how is Java harder to learn? Sure you will have to learn some good practices as soon as possible, and so much the better!

 

5. Maintainability

I agree that static typing is a big boon in large projects, and Java has a lot of great tooling. So that is definitely a plus. It's worth pointing out that starting with Python 3.5, Python will have the option to include type hints as well, which might improve the situation for Python, and that it is definitely possible to write large codebases in Python.

Any example of such project? I'm interested to see what are those best practices

 

CONCLUSION

I personally think that Java is not a good choice if your main target audience is Linux. Java GUIs are often iffy, but if C/C++ is out of the window and wxPython/qtPython don't work well on Macs, then I'm out of suggestions.

Yeah, the situation is quite tricky here. People have to understand that we need to make concessions at some point.

Anyway, thank you for your comment, I hope it makes more sense and I'm willing to discuss if you want
:-)

 

Rewritting the whole code base is a poor decision
Switching to Java is a very poor decision

This will most probably cause a fork of the project at some point imho ..

Yeah even us we are not able to fork our own project... So good luck if you want to maintain the v4 version. I will be sincerely very happy if someone manage to do it because I love this project.

For the user scripts, I'd probably investigate the usage of lua. It's quite embeddable and compiles to a few 100 kiB. So in total, I estimate the resulting binary to be around a few megs + sizeof(Qt).

The idea of keeping python syntax is to save the good things that we have in POLv4

 

I looked at PoL5 code and hats down, it is very well organized.. I am not going to comment PoL4 as it will be unfair to compare something carrying several years of legacy and something started out fresh.

Thanks :)

 

In my humble opinion this just the diametral opposite to your goals of Portability and Maintainability. You'll have to add "Version of Java" to the possible configuration options in your project. Taking up the argument of speed: Do you honestly believe that running  python on top of java makes it faster?

 

Yeah, you may read the article. Jython is not a python binary running on top of Java.

But if you make it in Java , please make it full faster for system with 512 MB Ram , 32 MB Video , and Processors of 600 Mhz , just for make it faster for computer with more resources .

 

POLv4 won't run on such a hardware...

 

The unique thing i tell here , i am simple user and Java kill my pc , because a Mega Super Excevise use of Resources of my pc .

Maybe the application you are using are poorly coded then.

 

I prefer you use Python + Bash , in the next version , and you can include inside your package , things like python2, python3 , cython , because if simple , very util , and very faster :D

Did you know that python is about 100x slower than Java? But we don't care, GUIs does not need performances.

Please consider using something that is not JFileChooser for choosing files.

JFileChooser is a Swing class. We do not intend to use Swing. I don't know if JavaFX file chooser will be better for you though. You can try we are already using it.

 

 

 

 Are you having a time schedule until the first new version is availiable?

No time schedule. We are working on our spare time so we are not going to work under pressure.

Is there a chance for using lts enablement stacks and PlayOnlinux/Wine? Till now it seemed not possible because not responsible depedencies...

 

I can't really answer you right now, but I might have a clearer idea later.

 

 

Cheers everyone!

 

 

 

 

Ronin DUSETTE Saturday 6 June 2015 at 8:00

Admin

^^^ Nice, Quentin. Very concise. :)

Thanks for the post too, @Blue-Tiger. I agree; we need good posts like this. You brought up some very valid points, and addressing them in public is part of the transparency we want to have. Hence the GitHub, Jenkins, and SonarQube repos/interfaces (respectively). :D 

This is what community development is all about (at least as a core); communication. That may just be my opinion, but I love the feedback, good or bad. As they say in the newer generations; #science

ssokolow Saturday 6 June 2015 at 9:09

Anonymous

 

Hum no, the UI should be a dependency of the project, not the contrary. We want to be able to change the UI whenever I want without have to change a single line of code in the the core. I can see people coming that are going to explain me Oh yeah, QT is separated into packages, you can keep only the network part, etc...

I'm not sure that this kind of people would be happy if we decided to use QT for the GUI and GTK for the networking part for example.

@Quentin

Point. I can understand the desire to stay isolated enough from the GUI to make it swappable. In fact, in one of my PyGTK (GTK+ 2.x) projects, I'm planning to write my own signals and slots mechanism so that I can have a strong MVC+Plugins design without tying myself to either Glib or QtCore as GTK+ 2.x becomes more and more dated.

I was operating under the assumption that, if performance was an issue, you'd do something like writing a simple interface wrapper for HTTP requests that would let a GUI plugin offer a higher-priority alternative to the default HTTP request code to transparently use the most performant option available.

 

Eclipse's SWT does seem to be better, but I don't know anyone outside Eclipse using it, so I don't know what to think about that. But Eclipse itself is a pretty ressource hog on my machine. If that is due to SWT or not I don't know.

 

@Blue-Tiger

Last I checked, Azureus (now Vuze) and JDownloader were both using SWT and both had (Azureus) or have (JDownloader 1.x and 2.x BETA) a noticeable GUI lag for things like opening menus as well as feeling "uncanny valley" not-quite-native.

 

 

Can you try JavaFX one day? The only drawback is that it does not look native. Thing that we can overcome by customising POL as Steam and many gamers apps are doing.

@Quentin

What is your planned support level for allowing PlayOnLinux 5 to be launched from a shell script with as little GUI displayed as possible?

I'm big on the native-looking apps so, given I want to write or amend a native-looking launcher GUI that's not just limited to Wine, it'd be nice if I could use PlayOnLinux in a manner similar to apt-get where I'd provide any undeferrable information up-front (eg. location of pre-downloaded installers), walk away, and come back to find all stuff that couldn't be done up-front or non-interactively waiting for me.

ssokolow Saturday 6 June 2015 at 9:17

Anonymous

Whoops. Finger slipped and posted early. Continued...

 

If the community is reacting like this when a Java developer try to contribute to the Linux community, I can fairly understand that there are not Java applications on Linux...

Same motivation as the big fuss that GNOME 3 kicked up. We have something which works Well Enough™ from our perspective, now you want to the parts visible to us in a direction that we've only had bad experiences with.

 

I'd second the suggestion to at least consider Rust. It's young, but it does already have several options for UI bindings, it's faster and has a more thorough typing system than Java, the cargo build system is cross-compile friendly, and, by default, all of the native Rust libraries you use get statically linked into your binary.

The /r/rust subreddit and the IRC channel are both very helpful if you want to ask questions.

 

IntelliJ, Eclipse, Netbeans, JDownloader, Libre office uses Java also

 

To be fair:

  1. LibreOffice uses its own non-Java GUI toolkit and they've been working to replace all of their Java dependencies since the split from Oracle.
  2. JDownloader is a "known to be sluggish and ill-fitting" application that's merely tolerated because none of the attempts to write more native competitors were able to keep up with the required pace of churn in the file hoster compatibility plugins.
  3. A lot of developers avoid Eclipse when feasible because of how heavy it is and IntelliJ and NetBeans, despite being good IDEs, are nowhere near as well known outside of the Java developer world.
veroslav Saturday 6 June 2015 at 9:32

I think this is a great initiative and I would be open to contribute by writing the code. I am an experienced Java programmer and I just recently started developing an open source version of uTorrent BitTorrent client.

 

Please have a look at my work so far (it is mostly a skeleton so far, with not much functionallity implemented) and let me know if it would be ok to join you.

 

Keep up the good work.

veroslav Saturday 6 June 2015 at 9:33

And I forgot the url (the most important thing):

https://github.com/veroslav/jfx-torrent

Quentin PÂRIS Saturday 6 June 2015 at 11:09

Admin

Hey!

 

What is your planned support level for allowing PlayOnLinux 5 to be launched from a shell script with as little GUI displayed as possible?

As said, the design allows to implements as many UI that we want. So we want to also implement a CLI and an argument driven UI :)

 

I'm big on the native-looking apps so, given I want to write or amend a native-looking launcher GUI that's not just limited to Wine, it'd be nice if I could use PlayOnLinux in a manner similar to apt-get where I'd provide any undeferrable information up-front (eg. location of pre-downloaded installers), walk away, and come back to find all stuff that couldn't be done up-front or non-interactively waiting for me.

So yeah, it will be possbile normally. You could even write a front-end for PlayOnLinux haha

 

I'd second the suggestion to at least consider Rust. I

What people tend not to realise, is that we did not make a lot of research just about the language. What we roughly need is:

  • A language
  • A way to ensure that developers will be able to work together
  • A test framework
  • An automated test platform
  • Something to audit the code
  • Some coding convention
  • A UI
  • Should work on OSX
JDownloader is a "known to be sluggish and ill-fitting" application that's merely tolerated because none of the attempts to write more native competitors were able to keep up with the required pace of churn in the file hoster compatibility plugins.

The need looks like a little PlayOnLinux scripts need doesn't it?

 

IntelliJ and NetBeans, despite being good IDEs, are nowhere near as well known outside of the Java developer world.

What about PyCharm, PHPStorm, Rubymine, etc... We were using Pycharm before and I was really impressed.

@veroslav: Your code looks good so far. If you want to join us, you are very welcome :)

 

inukaze Saturday 6 June 2015 at 12:04

a little suggestion , why you dont make it like a fork , and called "PlayOnPOSIX" ??? XD

 

I know the principal objetive its Linux Users , but i know some users are migrating for Linux to FreeBSD

and the Mac users wanna a version of program  , for make installation for POSIX system where exist wine native versions .

 

like user , for me PlayOn{Linux,Mac} , its a program simple , use a few resources , and actually its ease to make scripts compatible with PlayOnLinux and PlayOnMac

 

and leave it the current code in Python + Bash , and the another project for know really worked how you and users wait for both parts  ???

Quentin PÂRIS Saturday 6 June 2015 at 12:11

Admin

 

like user , for me PlayOn{Linux,Mac} , its a program simple , use a few resources , and actually its ease to make scripts compatible with PlayOnLinux and PlayOnMac

And it will be even better for the latter point.

 

and leave it the current code in Python + Bash , and the another project for know really worked how you and users wait for both parts  ???

And who is going to maintain this code? You?

Let's be clear, we are not going to drop the current working things until we are 100% sure that the solution we are trying to develop is better in every aspect.

ssokolow Saturday 6 June 2015 at 12:53

Anonymous

 

The need looks like a little PlayOnLinux scripts need doesn't it?

The important difference is that we like PlayOnLinux's UI, warts aside, and we want it fixed. On the other hand, JDownloader's UI is just a pain and we're more likely to wish it could be replaced entirely. (JD2 BETA's highly configurable UI definitely helps a lot there... though it's still sluggish and fails to be native in a lot of ways such as popup menus appearing in the taskbar as windows.)

It also doesn't help that, to the best of my knowledge, the Java standard library tends to pursue the lowest common denominator, rather than abstracting away the differences like the Python standard library does. (eg. I've never found an equivalent to sys.argv[0] in Java, which complicates certain types of functionality.)

 

What about PyCharm, PHPStorm, Rubymine, etc... We were using Pycharm before and I was really impressed.

I'm not a Rubyist, but it's been my experience that the Python and PHP communities seem averse to the idea of an IDE with a paid premium version. (I know I personally am because they have a financial incentive to sabotage any community attempt to bring the free version up to that level of functionality.) I'd honestly forgotten PyCharm existed until you mentioned it and this is probably the third of fourth time someone's proposed it while I was around to notice.

Quentin PÂRIS Saturday 6 June 2015 at 13:10

Admin

(Sorry I had mistakenly edited your post. I've fixed it but the paragraph may be little different. Tell me if something went wrong)

 

 

The need looks like a little PlayOnLinux scripts need doesn't it?
 
The important difference is that we like PlayOnLinux's UI, warts aside, and we want it fixed. On the other hand, JDownloader's UI is just a pain and we're more likely to wish it could be replaced entirely. (JD2 BETA's highly configurable UI definitely helps a lot there... though it's still sluggish and fails to be native in a lot of ways such as popup menus appearing in the taskbar as windows.)

 

For this particular problem (except the sluggishness of the interface), I can only agree. We are working hard on that challenge

 

It also doesn't help that, to the best of my knowledge, the Java standard library tends to pursue the lowest common denominator, rather than abstracting away the differences like the Python standard library does. (eg. I've never found an equivalent to sys.argv[0] in Java, which complicates certain types of functionality.)

Why would you need sys.argv[0]?

 

What about PyCharm, PHPStorm, Rubymine, etc... We were using Pycharm before and I was really impressed.
I'm not a Rubyist, but it's been my experience that the Python and PHP communities seem averse to the idea of an IDE with a paid premium version.


(I know I personally am because they have a financial incentive to sabotage any community attempt to bring the free version up to that level of functionality.) I'd honestly forgotten PyCharm existed until you mentioned it and this is probably the third of fourth time someone's proposed it while I was around to notice.

We are not talking about their philosophy, it is a completely different problem. We are talking about the quality of the program.

Community editions are under Apache 2 licences by the way. These editions are not so bad and can be enough for main people. Plus, they give free licences to open source project owners.

inukaze Saturday 6 June 2015 at 22:02

I am just a gamer user i and know a few of bash and i tell before i dont like java because kill my pc with their devourer resources , because of that i prefer c/c++ , QT, bash, python , ruby

And well the few practice i had with java need more lines for make the same . Anyway i need learn java xd

Well the source code can be mantained for a community or the java version works fine for all, possibly abandoned but if dont work like expected then much user prefer downgrade to the old version.

well then for the first versions of playonlinux 5 beta testing, you can make installable having playonlinux 4.2.X without replace any file for make tests ???
Quentin PÂRIS Sunday 7 June 2015 at 1:53

Admin

Read the news, and then, comment. Please

 

PlayOnLinux will become very slow because Java is very slow

[...]

Java is a lot faster than Python in general (http://benchmarksgame.alioth.debian.org/u64q/python.html). Moreover, the v4 branch has a lot of non optimal code. The tests we have already done with Java is showing us than what we have developed so fare behave a lot faster that PlayOnLinux 4. To be honest, there is only one drawback: the JVM takes a little more time to start than the python interpreter.

If you can explain me technically when Java would be slower than Python, I'm willing to listen. Until proof of the contrary, Java is faster.

 

well then for the first versions of playonlinux 5 beta testing, you can make installable having playonlinux 4.2.X without replace any file for make tests ???

It also also been responded in the comment. Please read.

ssokolow Sunday 7 June 2015 at 5:51

Anonymous

 

Why would you need sys.argv[0]?

Three features found in UNIX commands are:

  1. Having a binary which alters its default options based on the value of argv[0] (typically so you can unify several formerly separate utilities without having to have multiple copies of the code or a shared library).
  2. Using what you actually typed in the "Usage: " line that's displayed by --help or "Invalid argument syntax" responses.
  3. Easily producing "re-run self via wrapper" constructs without PATH-related corner cases as in these examples:
if not os.isatty(sys.stdin.fileno()):
    os.execvp('xterm', ['xterm', '-e'] + sys.argv)
if not os.geteuid() == 0:
    os.execvp('sudo', ['sudo'] + sys.argv)
We are not talking about their philosophy, it is a completely different problem. We are talking about the quality of the program.

I don't know what you thought I was talking about, but I was talking about why the programs you listed aren't a good example of "common Java on people's desktops".

In the case of the Java-based IDEs, I was giving reasons people tend to use something else for non-Java languages. It's very relevant if, like me, people are wary of getting caught in an "I don't have time to learn something new, so I guess I'm forced to buy the premium version to get this done on time" situation.

 

Quentin PÂRIS Sunday 7 June 2015 at 12:14

Admin

This make sense. In your case you may try a System.getProperties("java.home");

In any case, I would not use Java for the can of usage you are describing in general.

I understand your point from IntelliJ. I'm just saying that it is possible to write some nice programs in Java.

Harri Sunday 7 June 2015 at 19:02

What people tend not to realise, is that we did not make a lot of research just about the language. What we roughly need is: [...]

I know it's too late now, but maybe for next time ;)

  • Rust has an integrated testing framework (check this)
  • Currently, there are rust modes for most editors and for vim and emacs. Also, there is a plug-in for eclipse in development.
  • Considering an UI, there are bindings for Cocoa (used by Mozilla's servo), for GTK+ (dito) and QML/Qt.
  • This chapter of the rust book shows the most important concepts of rust.

I think the language can't be that bad, if Mozilla's next generation browser is developed using it ;)

Quentin PÂRIS Sunday 7 June 2015 at 20:04

Admin

I know it's too late now, but maybe for next time ;)

  • Rust has an integrated testing framework (check this)

This is cool, but this is not enough at all. We need the complete structure :

  • Managing the entiere lifecycle of the product (clean, check, compile, test, package, deploy, ...). Maven is doing that for us at the moment
  • Trigger the whole tests suit when someone sends a pull request on Github, and send the feedback on github (Jenkins is doing that at he moment)
  • Something to periodically test and audit the code

It is not a technical problem here but more a management one.

  • Currently, there are rust modes for most editors and for vim and emacs. Also, there is a plug-in for eclipse in development.

A simple text editor will not be enough for me. I''m no longer working without a complete IDE, with the integration of all the tools I need (VCS, github integration, debugger, test coverage, refactoring, checkstyle, class diagram generation, go to declaration, autocompletion, etc...)

  • Considering an UI, there are bindings for Cocoa (used by Mozilla's servo), for GTK+ (dito) and QML/Qt.

So it means that we would have to write three UI implementation. It is something that we could do, but requires a lot more effort.

  • This chapter of the rust book shows the most important concepts of rust.

I will read it, thanks :)

I think the language can't be that bad, if Mozilla's next generation browser is developed using it ;)

I'm not saying that it is bad. There are no bad languages to my point. It is just that for the moment, we have seen only one (acceptable, but this is my point of view) drawback of using Java.

By the way, we also need a scripting language and a way to run POLv4 bash scripts .

Someone who wants to propose us a solution must respond precisely to all these problems with a complete design :)

Harri Monday 8 June 2015 at 10:41

 " Managing the entiere lifecycle of the product (clean, check, compile, test, package, deploy, ...). Maven is doing that for us at the moment"

Cargo does that for rust, too. You can specify the dependencies for your program and it downloads and builds them locally and statically links them to your binary. These dependencies can even be git repositories.

It can also cross compile your program to other OS/systems and test them using the integrated testing framework.

 

"Trigger the whole tests suit when someone sends a pull request on Github, and send the feedback on github (Jenkins is doing that at he moment)"

Dunno about that, but this sounds easily scriptable. Maybe you can use jenkins for rust, too... Normally I test before commiting ;)

"Something to periodically test and audit the code"

Auditting as in "measuring the code quality", as you mentioned above? I've never had the need for such tools, so I can't comment about them. I only know that the rust compiler gives you a lot of suggestions while compiling, e.g. you should use that naming style for this function or that variable is undeclared ... It teaches you to use a good coding style so if you make sure your code compiles without any compiler output, you should be fine.

 

"A simple text editor will not be enough for me. I''m no longer working without a complete IDE, with the integration of all the tools I need (VCS, github integration, debugger, test coverage, refactoring, checkstyle, class diagram generation, go to declaration, autocompletion, etc...)"

Tools will come for rust. If you're used to emacs or vim, you have the tools you mentioned already included. The eclipse plugin I mentioned recently got a release, but eclipse is to heavy for my needs, thus I didn't test it, yet. For my C++/Python needs I use QtCreator, which is really nice!

 

"[ List of toolkits] So it means that we would have to write three UI implementation. It is something that we could do, but requires a lot more effort."

No, that means you *can* use any of these. But I'd suggest to use Qt via QML and be done ;)

 

"By the way, we also need a scripting language and a way to run POLv4 bash scripts ."

I'd suggest Lua in this case. It's simple and fast. Oh, and proven -- as it's often used in commercial games and even in industrial applications as Photoshop. It compiles to a few hundred kiB and you can statically link it to your binary. As the rust dependencies are statically linked, too, you'd only have dependencies on standard system libraries and thus, distribution is easy.

As for running bash scripts, I'd use the system's bash. You can launch it from rust (as in any language) and it will probably be used when using Lua's os.execute command.

 

Oh. this is the link I was originally looking for. It shows more than the book chapter. It might be for an older version of rust, but the spirit should be the same ;)

 

 

 

 

 

 

Harri Monday 8 June 2015 at 10:48

Oh, by the way... The main complaint I have about Java (not the language, but the runtime environment) is it's GUI part. It has a history of breaking things on Linux. At the moment, I'm fighting with Matlab to work on modern desktops, e.g. Unity or Gnome-Shell. This is the message I got from support this morning:

****

Please excuse that it longer than expected to get a reply from our developers:
"I would recommend that the customer try it on a supported version of Linux. The core of the issue is related to the interaction between Java and Window Managers, and it is unlikely to be something that we can fix from our side.

What you can ask the customer to try is the following potential workaround found here -
  http://awesome.naquadah.org/wiki/Problems_with_Java
_JAVA_AWT_WM_NONREPARENTING=1; export _JAVA_AWT_WM_NONREPARENTING

and then start MATLAB. Note once again, that we have not tested this on our side."

****

I'm not sure if Matlab uses Swing or Java-FX... but I guess this doesn't matter, as it's all AWT in the backend...

Let's try it ;)

 

 

FuzzyToothpaste Monday 8 June 2015 at 19:07

Anonymous

If you ask me, I don't think we should worry too much about speed. As long as it's not ridiculously slow, maintainability should be a priority. However, I don't understand why you want to use "portable" languages like Java and Python so much. Yes, using Python or Bash is a good idea to write the installation scripts, but PlayOnLinux itself doesn't need to be written like that. PlayOnLinux could just be compiled for each OS it will run on and that will probably work out well if you use a good build system like CMake. However, I don't know what to recommend. It seems like Java just isn't for us. Let's face it, Java is probably going to be dead in a couple of years, not to mention that there could be some JRE-related problems. People that use different JREs could have issues, and it just doesn't seem like it's suited for us. C++ is, according to other commentors, too difficult to maintain. C would be even harder to maintain. I don't know what to suggest. It seems like no matter what language is chosen, there are going to be plenty of disadvantages, so it's hard to just make a decision.

Quentin PÂRIS Monday 8 June 2015 at 20:20

Admin

Dunno about that, but this sounds easily scriptable. Maybe you can use jenkins for rust, too... Normally I test before commiting ;)

Me too, but contributors does not always do it ;) Or sometimes, a file can be missing, or anything. Believe me, it is saving an impressive amount of time and avoid many bugs and design problem. I'm not saying that it can't be done with rust though. I'm saying that it is something important to put into consideration when we chose a language.

 

Auditting as in "measuring the code quality", as you mentioned above? I've never had the need for such tools, so I can't comment about them. I only know that the rust compiler gives you a lot of suggestions while compiling, e.g. you should use that naming style for this function or that variable is undeclared ... It teaches you to use a good coding style so if you make sure your code compiles without any compiler output, you should be fine.

Here, our tools will of course give any compilation errors and warnings, but it will also advice on design problem like, the complexity of the classes, exception management, the quality of the tests, etc... It will then give an estimation of the technical debt we have on the overall project (i.e. 4 days at the moment for PlayOnLinux, which is very acceptable).

 

Tools will come for rust. If you're used to emacs or vim, you have the tools you mentioned already included. The eclipse plugin I mentioned recently got a release, but eclipse is to heavy for my needs, thus I didn't test it, yet. For my C++/Python needs I use QtCreator, which is really nice!

Well I don't want to enter this debate, for me vim/emacs will never replace a real IDE / developement environement. Honestly it is not comparable.

 

No, that means you *can* use any of these. But I'd suggest to use Qt via QML and be done ;)

Any Qt written apps that run on OS X in mind so that I can see it?

 

As for running bash scripts, I'd use the system's bash. You can launch it from rust (as in any language) and it will probably be used when using Lua's os.execute command.

I wish it was as easy ;)

 

I'm not sure if Matlab uses Swing or Java-FX... but I guess this doesn't matter, as it's all AWT in the backend...

Hum where have you seen that? AWT != Swing != JavaFX. And even it it was true, it is not because Matlab does not work well that it is always the same. I could say the same with Mathematica 7 which was written in QT and was poorly integrated to my desktop computer.

If you are not convinced, try by yourself the current snapshot of PlayOnLinux 5. It is not fully optimized (I still need to cache some widgets), but I think it is not performing so bad

Let's face it, Java is probably going to be dead in a couple of years

 

Any reason for claiming this?
For the main reasons I have said, Java is still overall the most used language today. (Even if you do not see it a lot for desktop apps because AWT / Swing are somehow sluggish on a lot of Linux machines)

 

 

 

 

 

Harri Tuesday 9 June 2015 at 0:12

"Here, our tools will of course give any compilation errors and warnings, but it will also advice on design problem like, the complexity of the classes, exception management, the quality of the tests, etc..."

There are no exceptions or classes in rust, thus there are no tools to check them. Instead of classes, you use types and traits. It's a different concept, but IMHO interesting. Instead of exceptions, there are result types and error handling is done via pattern matching. The compiler won't accept code wich doesn't implement all code paths (c.f. this link). Things are a bit different nowadays, but you get the idea.

 

"Any Qt written apps that run on OS X in mind so that I can see it?"

There are precompiled binaries of QtCreator for any platform, e.g. this one for MacOS.

 

" [bash stuff] I wish it was as easy ;)"

Is it not? I thought *BSD and MacOS come with bash pre-installed.

 

"Hum where have you seen that? AWT != Swing != JavaFX. And even it it was true, it is not because Matlab does not work well that it is always the same."

Swing uses AWT for window and event handling internally. I'm not sure about JavaFX, but it seems to be written from scratch. As far as I can tell, Matlab's editor widget is affected, which is a standard component from some Java company. But the link the Matlab developers sent me suggests, that the JDK had several breakages in different mayor versions of the JRE due to not standard conform interactions with X11. And not only Matlab is/was affected by these bugs, but any app using certain GUI stuff.

 

"I could say the same with Mathematica 7 which was written in QT and was poorly integrated to my desktop computer."

True, I remember that version of Mathematica. But I guess the problem of that version was, that they took their Motif code including all the X11 hacks and pushed Qt ontop of it.

 

"If you are not convinced, try by yourself the current snapshot of PlayOnLinux 5. It is not fully optimized (I still need to cache some widgets), but I think it is not performing so bad"

Are there ready-made JARs somewhere? I couldn't find any at first sight.

 

 

 

Quentin PÂRIS Tuesday 9 June 2015 at 0:31

Admin

 

"Here, our tools will of course give any compilation errors and warnings, but it will also advice on design problem like, the complexity of the classes, exception management, the quality of the tests, etc..."

There are no exceptions or classes in rust, thus there are no tools to check them. Instead of classes, you use types and traits. It's a different concept, but IMHO interesting. Instead of exceptions, there are result types and error handling is done via pattern matching. The compiler won't accept code wich doesn't implement all code paths (c.f. this link). Things are a bit different nowadays, but you get the idea.

It seems interesting! The problem also is that I need time to learn new development practice. I've made a lot of mistake in Java/Python/PHP/C++/object oriented languages in the past that I won't do today for POLv5.

If we start a new technology, we start from scratch and we won't produce a clean code directly. So it's a bit more risky, I need to try it with a smaller project first. But I will definitly consider it.

 

 

"Any Qt written apps that run on OS X in mind so that I can see it?"

There are precompiled binaries of QtCreator for any platform, e.g. this one for MacOS.

Is written in Rust?

 

 

" [bash stuff] I wish it was as easy ;)"

Is it not? I thought *BSD and MacOS come with bash pre-installed.

Yeah, we are in fact at the moment running the part of POLv4 that is interpreting POL_SetupWindow* commands with Jython to bind with Java and ensure backward compatiblity :) It involves some TCP/IP mechanism, we would rather not to rewrite this part, but isolate it from the core as it is made only for backward compatibility.

Are there ready-made JARs somewhere? I couldn't find any at first sight.

Do you have OpenJDK 8.0 installed? If yes I can create you a ready made JAR

 

Anyway, many thanks for your comments, very useful and very informative

 

 

Arucard1983 Tuesday 9 June 2015 at 1:48

An Android version of PlayOnLinux using the Java core of future PlayOnLinux 5 would be nice, since the only way to run some Windows programs on Linux/ARM tablets is to install ExaGears, but need to pay a license to use.

 (So far ExaGear is a port of Eltech binary translator, which is proprietary, plus a custom build of Wine 1.6.2)

Harri Tuesday 9 June 2015 at 10:10

"If we start a new technology, we start from scratch and we won't produce a clean code directly. So it's a bit more risky, I need to try it with a smaller project first. But I will definitly consider it."

Yeah, sure. It doesn't make sense for you to switch to something completely different, considering the work already done. I merely wanted to inform you what language you could use for your next project. Sure, there are new languages every two weeks, but since rust is not garbage-collected and has these unique features packed together *and* is backed by Mozilla, I'm positive that it's acceptance will grow.

 

"[QtCreator] Is written in Rust?"

Nope, but it doesn't really matter what language Qt is used with. It always looks the same ;) Furthermore, the new way of using Qt is via QML. So all the boring GUI wiring is done in QML (some JavaScript dialect) and this QML code can call functions you provide in a language of your choice, e.g. rust. This is an example.

If you have no special computing needs, you can write entire apps in QML. With some tweaking (e.g. different layout for different screen sizes), that app should work on most desktops and smart phones out there. Pretty cool, huh? ;)

 

"Do you have OpenJDK 8.0 installed? If yes I can create you a ready made JAR"

I'd have assumed, that one of your services creates a nightly JAR file, ready for testing ;)

ssokolow Tuesday 9 June 2015 at 13:16

Anonymous

To address various issues being discussed...

First, Jenkins is just a unit test server. It powers one of the less flexible "free for open-source" plans on the "CI as a service" list I built for planning Python projects and there's nothing Java-specific about it. (Just like any other unit test server. For example, BuildBot is written in Python and that's what Google Chrome uses.)

However, regardless of the language, Travis-CI and Appveyor are the more well-known ones for open-source projects. (Travis-CI lets you build on Linux and, if you set the right presets, on OSX. Appveyor does Windows. Both are free for open-source projects.)

Both Travis and Appveyor can be integrated with GitHub so that pushes and pull requests trigger a test run. (In fact, they integrate with GitHub's status API so you can see a list of passes and fails right in the pull request UI)

... and, in the case of Rust, the community is especially Travis-oriented because someone built a service called Rust-CI which allows projects still using language features with unstable APIs to have their Travis-CI test suites re-triggered every time a new Rust nightly gets released.

Also, if you're looking for ways to push as much onto static checking as possible, might I suggest some of these services which also integrate with GitHub?
http://coveralls.io/
https://gitcop.com/
https://reviewable.io/
https://scrutinizer-ci.com/ (Python. Java and Scala planned.)
https://scan.coverity.com/travis_ci (Does Java but not intended for pull requests)

Aside from Scrutinizer's static analysis and Coverity Scan, those don't care about what language you use. I'd suggest something for static analysis of Java pull requests but I only track such services for languages I might consider actually using. (I know Coverity because it does C and C++)

As for Rust, since it's been mentioned, instead of a separate static analyzer, the current solution for getting stricter than the already-strict compiler warnings is to pull down a Rust nightly to get access to the currently-unstable API for compiler plugins and install a linter pack like rust-clippy.

Also, for your legacy bash scripts, might I suggest running the ShellCheck static analyzer as part of your test runs? (Just set it up as a test that can fail like any other)

Quentin PÂRIS Tuesday 9 June 2015 at 13:29

Admin

This is a good idea!

I will make the builds available to download tonight!

Quentin PÂRIS Tuesday 9 June 2015 at 20:37

Admin

You can download OpenJDK 8.0 here (not tested, not optimized, the whole JDK is included, not only JRE, but it should work)

http://www.playonlinux.org/openjdk-1.8.0-internal.tar.gz

The last nightly build is here: http://playonlinux.org:8080/job/POL-POM-5_OpenJDK/lastSuccessfulBuild/artifact/target/playonlinux-5.0-SNAPSHOT-jar-with-dependencies.jar (20M, Jython interpreter is bundled)

Remember that it is an experimental version, a lot of things has not been done yet (for example, the download of remote script).

 

Harri Tuesday 9 June 2015 at 21:25

hm, is it supposed to only work with your build of openjdk, or is ocacle-jdk also okay?

 

$ java -jar playonlinux-5.0-SNAPSHOT-jar-with-dependencies.jar
Exception in thread "main" Unable to inject class com.playonlinux.services.PlayOnLinuxBackgroundServicesManager on class com.playonlinux.services.InstalledApplicationsPlayOnLinuxImplementation. Check your config file
    at com.playonlinux.injection.Injector.injectAllBeans(Injector.java:96)
    at com.playonlinux.injection.AbstractConfigFile.load(AbstractConfigFile.java:39)
    at com.playonlinux.app.PlayOnLinuxApp.start(PlayOnLinuxApp.java:44)
    at com.playonlinux.app.PlayOnLinuxApp.main(PlayOnLinuxApp.java:52)

$ java -version
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

 

Quentin PÂRIS Tuesday 9 June 2015 at 22:35

Admin

My mistake, sorry. I've rebuilt the .jar, you can retry if you want :)

Also, PlayOnLinuxBashInterpreter is not inside this .jar file, so you will not be able to run bash scripts. I need to fix this.

However, you should be able to run python scripts

Harri Tuesday 9 June 2015 at 23:01

The only "complaint" so far is, that it looks and feels non-native, c.f. the attached screen-shot. The dialogs in the file-chooser seems to be native, though. Startup speed is okay for me (as long as your cores are idle). When compiling something in the background, it took more than 10 sec to start.

 

Quentin PÂRIS Tuesday 9 June 2015 at 23:10

Admin

Sorry your screenshot does not work.

Also, note that

  • The skin is not final
  • We are probably going to allow the end user to chose between a dark theme and a light theme

How different is it from Steam?

 

harri Wednesday 10 June 2015 at 0:56

The look part of the problem is, that you use a static skin, which doesn't pull the current colours of your desktop. The feel part is e.g., that the acceleration of the scrolling is different from desktop defaults. And probably the app doesn't work with screen readers - which is an accessibility problem. For the majority of users, these are luxury problems. It doesn't really matter if it looks out of place... And that should be treated with lowest priority. And thus, skins are IMHO enough. But please consider adding support for handicapped people, once most of the stuff is working. That is e.g.:

* the ui works with large fonts (15+) and high contrast (white text on black background)
* you can control the app with keyboard (cycle through selections with tab key, scroll using arrow keys and select using the return key)

There are too many UIs which use absolute pixels numbers and don't scale with the font size. Luckily, GTK+ stuff is often okay.
Quentin PÂRIS Wednesday 10 June 2015 at 1:19

Admin

@Harri. We are discussing it right now with the staff. We have several option for what you've said:

  • Additional settings (Skin + Fonts). It is just a set of .css files we need to provide :)
  • Allow users to set the CSS of the application and so create / submit extra themes
  • Full CLI control
  • Implementing a QtJambi UI (It would requires more work and I don't know if it is good enough or not at all. We are going to experiment that to see if it is clumsy or not)
Harri Wednesday 10 June 2015 at 11:46

  • Considering QtJambi is dead, that wouldn't make sense.
  • Full CLI control would be very useful.
  • A predefined high-contrast theme which can be activated via a command line switch would be helpful. A friend of mine is nearly blind and we often discussed that kind of stuff: A high-contrast theme is worth nothing if you've to go through menus while the low-contrast default theme is activated ;)

 

This is for example what Banshee, a GTK+ based music player looks like with a high contrast theme. And without, it looks like that. And a talk on that topic.

 

Quentin PÂRIS Wednesday 10 June 2015 at 12:25

Admin

Qt Jambi seems to be maintened :-)

What about java-gnome?

Harri Wednesday 10 June 2015 at 15:46

Well, okay, but it's using Qt4. I wouldn't start a new project using Qt4 if I was you.  The very last version of Qt4 was just released. Thus, there won't be any fixes for newer operating system releases.

Java-gnome seems not to support GTK+3, yet. Dunno if it ever will, the latest release is from 2013. But even if it was using the latest major version of GTK+, I probably wouldn't use it, since I've been told, that GTK+ on MacOS is not integrating very well. But you can test that yourself: install gimp via fink, macports or homebrew.

Harri Wednesday 10 June 2015 at 15:51

Oh, I take that back. GTK+3 is supported since java-gnome-4.1. In that case try GTK+ 3 (!) on MacOS for yourself, I've no experience here. Please note that Gimp is still using GTK+2.

Harri Wednesday 10 June 2015 at 15:53

I forgot this link.

Quentin PÂRIS Wednesday 10 June 2015 at 20:35

Admin

The reference UI implementation will be the JavaFX one then (more portable, easier, ...).

But we may seriously consider also implementing a GTK 3 UI for the native look & feel, just for Linux users

eye2view Friday 12 June 2015 at 21:16

Anonymous

I'm running Ubuntu 14.04.02 with the MATE desktop environment.

I use PlayOnLinux to run Firefox under Wine because Comcast/Xfinity won't run on the regular FF browser. This is because the the most current version of Adobe Flash Player  available for FF on Linux is too old. Xfinity states: "The minimum required version of Flash for this video is 15.0.0.152. Your current version is 11.2.202."

In addition, Comcast/Xfinity won't run on Chrome because Chrome uses HTML5, not Adobe Flash.

My concern is that PlayOnLinux 5 will not running properly on my system. Will PlayOnLinux 5 run smoothly on Ubuntu with the MATE desktop environment?

ssokolow Saturday 13 June 2015 at 7:48

Anonymous

@eye2view

sudo apt-get install pepperflashplugin-nonfree

Google made a deal with Adobe to continue providing new major versions of flash for Linux via Chrome's special PPAPI (Pepper API) rather than the NPAPI (Netscape Plugin API) that all other non-IE browsers use, but Ubuntu doesn't install it by default because it's closed-source.

You probably installed the flashplugin-installer package, which provides the NPAPI version. However, Adobe only provides security updates for the Linux NPAPI version. That's why it's stuck on 11.x.

Chrome "uses HTML5, not Adobe Flash" because Chrome dropped support for NPAPI once they finished writing their own replacement for the Adobe Reader plugin.

Installing pepperflashplugin-nonfree should give you Flash 15.x under Chrome.

ssokolow Saturday 13 June 2015 at 7:52

Anonymous

@Quentin:

Another thing that'd make a good frontend (and could allow any GUI library people want) would be a frontend which displays no GUI but uses D-Bus to expose an RPC API.

Having real remote method calls with structured, typed data that cover enough of PlayOnLinux to write a GUI frontend would go a long way toward removing any complaints I might have about choice of GUI. (And it would make it very easy to integrate POL into higher-level, multi-backend game manager GUIs.

Quentin PÂRIS Saturday 13 June 2015 at 22:17

Admin

@ssokolow: I will have a look :) Thanks

Knoppix User Nick Thursday 18 June 2015 at 14:55

While I do believe it could be faster I must admit that playonlinux has been a gift to us all and has my respect. I am excited about the new goals of the project and would love to see a new GUI interface. Keep up the good work! What I want is to see is POL joining with sunmicrosystems to create a free windows platform for linux. I want to see POL become a functional Java application that does more than any java application has ever done before and in that moment POL would become something they trully would fear. It could be an online GUI interface for gaming. They would have to turn an eye to that because the functions would then be platform independent.

Ronin DUSETTE Thursday 18 June 2015 at 17:32

Admin

https://www.reactos.org/

Kowalski Thursday 18 June 2015 at 18:30

Two gripes and two ideas:

-- if I'm not connected to the Internet, PlayOnLinux doesn't allow me to install a Windows app, even if I'm not using scripts, but just configuring everything from the scratch (I mean the "Install a non-listed program" option. I also think this feature should be more visible and easier to find in the future versions--not every app has a script!),

-- I very often see POL error messages when closing a Windows program even though everything seems to be fine with the app. There should be an easy way to turn this off.

-- Consider some kind of integration (I don't know if it's possible or not though) with Big Picture mode in SteamOS. Check out the SteamBridge project (https://github.com/sirnuke/steambridge).

-- It's cool that you're working on this new version, I will definitely check it out (on Linux at least) when it's out. But to be honest I'd rather prefer a much simpler tool for creating self-contained Wine WRAPPERS which one can easily, delete, move between computers, and where you wouldn't have to install Wine system-wide. On Macs, we can create such wrappers with Wineskin (which is even utilized to create Mac ports on GOG.com and Steam, it's so comfortable to use) and WineBottler, but there are no such applications for Linux. :(

Maybe it would be enough to add a Wine-specific frontend and tools to PortableLinuxApps (http://portablelinuxapps.org/) to make a wrapper-creating program for Linux? Think about developing such an app alongside PlayOnLinux/Mac, please. It could be of great use to porters as well as to users that prefer minimalism and portability.

Ronin DUSETTE Thursday 18 June 2015 at 20:42

Admin

 

-- if I'm not connected to the Internet, PlayOnLinux doesn't allow me to install a Windows app, even if I'm not using scripts, but just configuring everything from the scratch (I mean the "Install a non-listed program" option. I also think this feature should be more visible and easier to find in the future versions--not every app has a script!),

That is because of the nature of Wine itself; not POL. Wine is not Windows. If Wine worked perfectly, POL wouldn't be needed. ;)

 

-- I very often see POL error messages when closing a Windows program even though everything seems to be fine with the app. There should be an easy way to turn this off.

Do you ever report these issues to us or WineHQ in bug reports? If no one reports errors or gripes, we can't fix them. 

 

-- It's cool that you're working on this new version, I will definitely check it out (on Linux at least) when it's out. But to be honest I'd rather prefer a much simpler tool for creating self-contained Wine WRAPPERS which one can easily, delete, move between computers, and where you wouldn't have to install Wine system-wide. On Macs, we can create such wrappers with Wineskin (which is even utilized to create Mac ports on GOG.com and Steam, it's so comfortable to use) and WineBottler, but there are no such applications for Linux. :(

For the power that POL has and the Wine features it exploits, it is actually very comprehensive, in my opinion. You can move self-contained WINEPREFIX from system to system. Most it depends on the system, though (specifically because of how Wine works. Different hardware? Different drivers? Non-multiarch system? Those are all factors.). POL already does that, and calls them Virtual Drives, which are easily created, deleted, moved, or otherwise manipulated via POL's current interface. 

As for Steam integration, that would be sweet, but you have to remember that Steam running through Wine is not the same as Steam on Linux; I am not sure how there could be integration from Linux Steam to launch a Wine/Steam app, although, from what I remember, Steam has an option to run programs outside of Steam itself, so you could add a shortcut or small bash script to the Steam interface and launch a program that was previously installed via POL/Wine/Steam. I haven't tried it, but that is the first thing that pops into my head. 

allanon Friday 19 June 2015 at 3:12

What a sad news!

First, I want to thank you, from the deep of my heart, for all this years of *easy* gaming.
That said,
I really hope you do *not* switch to java; eventually I think I will stick with v4.x or some kind of replacement, since there is no space in my system for shit (no flames, it's just my opinion/choice and I respect all coders in this world) like java (and mono, and ...etc. etc.).

 

 

Quentin PÂRIS Friday 19 June 2015 at 9:18

Admin

since there is no space in my system for shit

Understood, but please tell me why do you call OpenJDK (not java) shit. It is a bit strong word isn't it? There is no argument in you comment, and you probably don't have any for telling this (or your arguments are no longer valid in 2015 as most complains raised against Java)

 

(and mono, and ...etc. etc.).

By the way, if you are using PlayOnLinux, you do have mono installed on your computer. I think it is fine isn't it?

 

 

What a sad news!

Please. Having a team that is spending hours to improve the program a lot is definitly not sad news. If you want me to find really sad news, I will find some you for, so that you can compare...

 

PlayOnLinux 5 is defnitly better than PlayonLinux 4 (still incomplete and not usable for the moment). The more the time goes by, the most we are convinced that it is a good choice to switch to Java. If you don't want to use it, too bad for you. At this point I'm pretty sure that we will make a lot of happy users

 

ray Saturday 20 June 2015 at 3:32

I think the idea of redesigning the application has its merits and might be great.

In response to the comment: "unfortunately I'm not experienced enough in C# to say if we should have used it or not.."

I'd suggest C# over Java for several reasons, but I'll boild it down to saying that C# was designed for interoperability with other languages and systems (etc.) and also that C# uses type reification instead of type erasure (i.e. C# does NOT erase/remove type information at runtime, like Java does). I've seen many problems because of this, and I've run into design limitations myself when using Generics. You can check a wiki page comparing C# and Java and see that C# is a more powerful language and no more difficult to learn/use than Java may've been. Just like anyone can go from C++ into Java, anyone can go from Java into C#. (Check the book "Effective C#")

I'd recommend familiarizing yourself with, and learning, C# so that you can make a more informed decision here.

I've used both Java and C# for years and there're many things that require ugly hacks in Java that just work out of the box in C#. As a simple example consider that, in larger projects, the use of generics tends to be common for code reuse. Consider this contrived example (pseudo-code):

// java; does not compile due to type erasure
public interface MyInterface<T1, T2> {
    T1 method(final T1 t1);
    T2 method(final T2 t2);
}

The java code above fails because the JVM "sees" the following method signature twice:

Object method(final Object);

This is still true in Java 8, unfortunately, because their decision was driven by backwards compatibility...

In fact, if you ask Java whether a list of strings (i.e. List<String>) is the same kind of list as a list of integers (i.e. List<Integer>) Java would say "yes" whereas C# would say "no" and actually know the difference between them.

This is a contrived example, but you can probably see why this would be important and it's better if you don't run into those limitations after it's already "too late" to have a "change of heart" on which language to use, etc.

Also, I tend to see the language used as not too relevant in the context of improving the codebase. Ultimately, the codebase will improve based on how much you've learned from your past mistakes, not the language you choose. It's up to you to make sure that you don't end up re-writing a codebase that's difficult to maintain and extend (as described in the original post) but in a different language.

 

Lastly, it's likely common knowledge already that the .NET Framework has been released under the MIT License in GitHub and that the Mono project exists, which has allowed me to build C#-based applications for both Windows and Linux. Again, I hope you will seriously consider familiarizing yourself with C#. Choosing one language over another (even better option, IMHO) just because you're not familiar with it might be a dis-service to yourself and maybe even the project in the long term.

I hope this helps.

-r

ray Saturday 20 June 2015 at 3:40

For completeness' sake, here's a Wikipedia page with some tables listing what each language supports and also pointing out a few additional inconsistencies with Java (e.g. boxing of primitives, arrays, etc..)

https://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java

Overall, I think there're good reasons to prefer C#. You just need to take some additional time to examine them more closely and get a better understanding of them and their implications :)

-r

Magmus Monday 22 June 2015 at 14:00

Anonymous

This is a fantastic idea! Maintainability all the way. Good idea guys!
ozky Wednesday 24 June 2015 at 17:10

Why everybody hate always something new that not even released yet ??????????????? i strongly like this project.:) Java is good platform works with several os out of box and no any big security holes only in those morons heads who complain java.

allanon Thursday 25 June 2015 at 12:16

By the way, if you are using PlayOnLinux, you do have mono installed on your computer. I think it is fine isn't it?

here is the output of apt-cache show playonlinux

Package: playonlinux
Version: 4.1.1-1
Installed-Size: 3516
Maintainer: Debian Games Team <pkg-games-devel@lists.alioth.debian.org>
Architecture: all
Depends: python (>= 2.6.6-7~), wine | wine-unstable, unzip, wget, xterm | x-terminal-emulator, python-wxgtk2.8, imagemagick, cabextract, mesa-utils, gettext-base, binutils, gnupg, icoutils, x11-utils
Suggests: ttf-mscorefonts-installer
Description-en: front-end for Wine
 PlayOnLinux is a front-end for wine. It permits you to easily install Windows
 Games  and softwares on Linux. It is advised to have a functional internet
 connection.

No mono, nor java required!

 

 

By the way, if you are using PlayOnLinux, you do have mono installed on your computer. I think it is fine isn't it?

 

here is the output of aptitude search ~imono

nothing :D

 

and here is the output of apt-get install playonlinux on a fresh SO (a mininal install of debian).

Some text is in italian. Btw, no mono, nor java required by depencies.

 

I seguenti pacchetti NUOVI saranno installati:
  cabextract icoutils libatk1.0-0 libatk1.0-data libdrm-intel1 libdrm-nouveau1a libdrm-radeon1 libdrm2 libgl1-mesa-dri
  libgl1-mesa-glx libglapi-mesa libglew1.7 libglu1-mesa libgsm1 libgtk2.0-0 libgtk2.0-bin libgtk2.0-common libmpg123-0
  libpciaccess0 libutempter0 libv4l-0 libv4lconvert0 libwine libwine-alsa libwine-bin libwine-gecko-1.4 libwine-gl
  libwxbase2.8-0 libwxgtk2.8-0 libx11-xcb1 libxcb-glx0 libxcb-shape0 libxcomposite1 libxcursor1 libxdamage1 libxfixes3
  libxinerama1 libxrandr2 libxv1 libxxf86dga1 libxxf86vm1 mesa-utils playonlinux python-wxgtk2.8 python-wxversion
  ttf-liberation wine wine-bin x11-utils xbitmaps xterm
0 aggiornati, 51 installati, 0 da rimuovere e 3 non aggiornati.
È necessario scaricare 97,5 MB di archivi.
Dopo quest'operazione, verranno occupati 310 MB di spazio su disco.

 

 

Quentin PÂRIS Thursday 25 June 2015 at 14:12

Admin

... Yes I think I'm aware of PoL dependencies. If you are so confortable with POL dev, why are you not contributing?

And please have a look in ~/.PlayOnLinux/wine/mono 

mono is required by wine ...

Ronin DUSETTE Thursday 25 June 2015 at 18:32

Admin

@allanon

Also, have you have ever even glanced at the Wine docs? It clearly states:

 

Wine 1.5.6 will install Wine Mono automatically as needed. It will search for the MSI in the following locations:

  • The Unix directory stored in the "MonoCabDir" value at HKCUSoftwareWineDotnet.

  • /usr/share/wine/mono, or possibly some substitution for /usr if Wine was installed to a different location.
  • wine_build_directory/../mono, if Wine is being run from a build tree.
  • Download from http://source.winehq.org/winemono.php

Unlike gecko, there is only one package containing the code for both x86 and x86_64, as most of the code does not depend on the architecture.

Users who want to avoid download prompts can run the script http://winezeug.googlecode.com/svn/trunk/install-addons.sh to install both gecko and mono in /usr/share/wine.

http://wiki.winehq.org/Mono

For any version of Wine 1.5.6 or newer, it will automatically download and install the wine-mono package. I don't really see what the big deal is. lol.

rubdos Sunday 28 June 2015 at 11:44

Hi,

I would be pro Rust, but for PoL I'd say C++. Reasons:

  • Easy integration into Python via SWIG. It's easy once you get the hang of it. It doesn't make a (runtime) dependency, as SWIG is a code generator, not a library.
  • Fast. Machine code.
  • Probably easy integration into Wine too.
  • Cross platform when done right.
  • If you use Qt, things will be lightweight. You can use QML to have some form of RAD, which works WAY better than in Java IMHO. I've seen both sides, I know. ;-)
  • Not too much dependancies (you will depend on Python, Qt and worst case Boost. Try to avoid the latter, it will make you happy.)

Please consider this. Java gives us a hell of extra dependancies and the "need" to have Java to run Windows applications on Linux bugs me.

Quentin PÂRIS Sunday 28 June 2015 at 16:43

Admin

Hi,

C++ is not an option for us. It would take a lot of more time to have the same feature with really few advantages.

 

  • Easy integration into Python via SWIG. It's easy once you get the hang of it. It doesn't make a (runtime) dependency, as SWIG is a code generator, not a library.

SWIG seems to be cool, but still, you cannot beat VM's integration of Python. The reason is that Java / Mono holds class informations at runtime making integration straightforward. (There are nothing to do)

 

 

  • Fast. Machine code.

Do we really need full-optimised code for PlayOnLinux? As an example, here is a comparison between POLv4 and POLv5. As no one complained before about POLv4 performances, I think a x50 performance is sufficient enough.

  • Probably easy integration into Wine too.

In this case it does not change anything. We run wine as an external binary.

 

  • Cross platform when done right.

The language itself, yes. For the librairies, I am not so sure

 

 

  • If you use Qt, things will be lightweight. You can use QML to have some form of RAD, which works WAY better than in Java IMHO. I've seen both sides, I know. ;-)

What library have you used in Java?

 

 

  • Not too much dependancies (you will depend on Python, Qt and worst case Boost. Try to avoid the latter, it will make you happy.)

QT core is about 128M dependency. Java (+ the graphical toolkit) is about 200M. Does it make a very large difference? Also, do not forget that POL's install tens of wine binaries which are a lot bigger than the Java Runtime Environement.

 

Java gives us a hell of extra dependancies and the "need" to have Java to run Windows applications on Linux bugs me.

Just one dependency*. What is the difference between installing Java and installing libwxgtk + python-wxgtk? Honestly?

 

 

 

 

ssokolow Sunday 28 June 2015 at 21:47

Anonymous

 

Just one dependency*. What is the difference between installing Java and installing libwxgtk + python-wxgtk? Honestly?

To be fair, there's a bit of an aversion to installing new garbage-collecting VMs with "reinvent the world... possibly for portability" ecosystems on Linux. That's why people complain so much about Java and Mono.

Idiomatic C++ and CPython both rely primarily on reference-counting and delegate as much as possible to the libraries you've already got on your system.

 

ssokolow Sunday 28 June 2015 at 21:49

Anonymous

Correction: Idiomatic C++ relies primarily on reference counting for multiple ownership situations. I'm not sure what you'd call the "or better" case for single ownership that Rust makes automatic.

Quentin PÂRIS Monday 29 June 2015 at 0:32

Admin

 

To be fair, there's a bit of an aversion to installing new garbage-collecting VMs with "reinvent the world... possibly for portability" ecosystems on Linux. That's why people complain so much about Java and Mono.

How creating a new garbage collector mechanism is reinventing the world? Every language (except C++ which does not have any garbage collector, and this one good reason for us not to chose it) creates its own garbadge collector. Except that reference couting is less efficient than Java mechanism (reference couting won't clean circular references for exemple).

 

Anyway, it is proven that a perfect garbage collector does not exist and can't exist (so even Rust garbage collector will lead to memory leak if you do not take care).  Once you are aware that, you can take the needed measures.

 

I'd like people to try POLv5 and to give smart feedbacks instead of just criticizing the language for very old and outdated reasons.Except if there are valid arguments of course, but for the moment, sorry but I haven't received any valid point except about the UI integration maybe.

Java is an extra dependency, and so was wxpython, or so would be QT. And we are always talking about dependencies of about 100-200M maybe? Is it a big deal for programs that will install tens of 150M+ wineversions and 2GB+ games? Wouldn't a good quality code and a well designed and maintenable program worth this very reasonable sacrifice?

There are always dependencies, and this is why apt-get / rpm was invented. Things are are managed really easy on Linux, so why complaining about this "issue"?

For the UI, I would perfectly understand if we were about trying to write a program like a browser, a mail client, or anything that is really part of the desktop. But honestly, in our case, we are writing (or trying to write at least, because I am spending more time trying to justify what we are doing to people that does not even take the time to get all the history) a gaming program that needs to have its own identity like Steam or any other gaming platform.

TLDR; We are working hard to make POL 5 nightly builds. Try them, give relevant feedbacks (when I say relevant, it's not only about you, but about the whole community.

  • Comments like I will not not install Java, so please do not use it are just egotistic narcissistic feedbacks that we really do not need.
  • Comments like when I am reading 100+ games description, POLv5 takes 1Gb of memory or please consider creating a RPC so that we can write native look & feel UI, or please consider thinking about handicapped people are really useful and I can ensure you that they are taken into consideration (and quickly).
  • Comments like You can use C++ and QT, and for the Python integration, just use Boost are pretty useless, because not to be disrespectful, I think it is pretty pretentious thinking that you can solve in ~10 seconds a problem that we have been thinking about for months. Come up with a 50+ page document explaining how to tackle every issue we're facing and I can ensure you that I will read it with a lot of respect.

Honestly, try to forget that POLv5 is written in Java, test it (for the part that is working), and give us feedback. And if you see any important problem that can't be solved because we are using Java, I think we are going to have a good and useful discussion.

ssokolow Tuesday 30 June 2015 at 1:23

Anonymous

I'm just trying to clarify the psychology behind all of these complaints so you can address them as effectively as possible.

I have 16GiB of RAM and don't leave my modern.ie testing VMs running while I game, so, personally, I'm only worried about whether the UI will feel sufficiently native.

(Hence my suggestion for a D-Bus frontend so I can integrate the POLv5 core into some kind of unified launcher written using PyQt or PyGI. It's Linux. It's my damn desktop. If an application tries to "have its own identity" in defiance of the system-specified look and feel and maintaining a patchset would be too much work, I write a minimum viable replacement like I did when the GUI update manager removed the checkbox to opt out of "restart to update your kernel" nags.)

 

How creating a new garbage collector mechanism is reinventing the world? Every language (except C++ which does not have any garbage collector, and this one good reason for us not to chose it) creates its own garbadge collector. Except that reference couting is less efficient than Java mechanism (reference couting won't clean circular references for exemple).

More mistake-proof? yes. More efficient? no.

If you use weak references properly, reference counting is more memory and CPU efficient than garbage collection because there's no "do I waste CPU collecting too frequently or waste RAM by collecting to infrequently" trade-off. When you decrement the reference counter, you check if it's zero and, if so, you free the resource.

That and the "reinvent the world for portability" approach to library ecosystems is why, accurately or not, there's a perception in the Linux user community that Java and Mono are heavy and to be avoided. (Keep in mind that the more extreme aspects of this mindset lead some people to try to have only Qt or only GTK+ apps on their system to avoid having two GUI frameworks in memory. If all your apps use one GUI toolkit, the shared library system need only keep one copy of one set of libraries in memory.)

It's a bigger problem with Java and Mono because, for many people, when neither Minecraft nor a MonoGame-based game is running, they have no Java or Mono app running at all and, thus, people worry that switching PlayOnLinux to Java would incur a heavy memory burden for non-Java games because Everyone Knows™ that the JRE has a high constant overhead and Everyone Knows™ that a garbage collector requires, on average, 50-100% of the actual memory used for slack space in order to perform well.

(That's the general perception among power users as to why Android devices need 50-100% more RAM than iOS devices (ObjC uses reference counting) to attain equivalent performance.)

 

Anyway, it is proven that a perfect garbage collector does not exist and can't exist (so even Rust garbage collector will lead to memory leak if you do not take care).  Once you are aware that, you can take the needed measures.

Rust doesn't use garbage collection. The mechanisms in the standard library use a mix of compile-time ownership tracking and runtime reference counting... basically, automatic generation and linting of the code you have to write manually in C++ if you want to "Do It Properly™".

edo Sunday 5 July 2015 at 4:58

I have to say than I'm glad about this java-based new version, now the chances of me being interested in its source code its above zero percent, and thats great. I have used java software like netbeans and it works really good, so Im sure this one will work fluently as already claimed. And being multiplatform is great, to just maintain the same codebase on linux, bsd systems, os x, etc. I personally think java is a great language for a software like this.

ikus060 Saturday 25 July 2015 at 20:02

I'm awaiting for this new upcomming PlayOnLinux in Java. It's sound exciting ! I'm also a big fan of Java when building serious application.

As for integration with Desktop environment, you may also have a look into SWT. I'm using this widget library for quite sometime. It's very powerful and portable.

pseudo Tuesday 11 August 2015 at 3:57

Just enable gallium nine support, please cool The java vs python vs Qt vs etc. doesn't really matter to me.

narcisgarcia Wednesday 12 August 2015 at 22:25

Anonymous

If Java will be loaded all the Windows application run time, then I prefer POL to not be using Java. If it only affects interface it's okay.

PlayOnLinux will be portable only to platforms where Wine is portable to. Android seems a joke here.
Quentin PÂRIS Thursday 13 August 2015 at 0:19

Admin

 

If Java will be loaded all the Windows application run time, then I prefer POL to not be using Java. If it only affects interface it's okay.

Why?

 

PlayOnLinux will be portable only to platforms where Wine is portable to. Android seems a joke here.

 

 

zomdev82 Monday 31 August 2015 at 23:14

OMG! Please dont go to Java, Python is by far the better language. Further more PlayOnLinux is the freaking only thing that keeps bringing me back to Linux!!! People are just lazy, they dont want to put a little elbow greese looking for a way to get windows games to play on linux. I dont think PlayOnLinux should change a damn thing!! I'm very pleased how this program works already, dont go and change and break my heart!!

Quentin PÂRIS Tuesday 1 September 2015 at 11:22

Admin

 

OMG! Please dont go to Java, Python is by far the better language. Further more PlayOnLinux is the freaking only thing that keeps bringing me back to Linux!!! People are just lazy, they dont want to put a little elbow greese looking for a way to get windows games to play on linux. I dont think PlayOnLinux should change a damn thing!! I'm very pleased how this program works already, dont go and change and break my heart!!

Don't want to make the effort of repeating all that have already been said and you haven't read.

 

FuzzyToothpaste Saturday 5 September 2015 at 23:36

Anonymous

All of the comments complaining about Java amazes me. If you think Java is the best, then so be it. The truth is, most end users won't care about what it's written in anyway. They just want it to work and be fast if at all possible (and from what you've shown me, PoL 5 will be pretty fast). However, I have suggestion for PoL that has nothing to do with the programming. I think we need to change how PlayOnLinux works. Let me explain a little bit with an example. Suppose someone installs a program, like iTunes, that has problems even with the newest version of Wine. What is the user to do when a new Wine version rolls around that fixes issues? I doubt most people want to delete their prefix and start over. The alternative is to simply keep an eye on PlayOnLinux.com to watch for changes to the script and recommended Wine version and apply them yourself, which I doubt the average end user wants to do After all, PoL was made so people wouldn't have to mess with Wine versions.

We need to be able to let PlayOnLinux patch and make changes to programs that have already been installed. Although I have no idea how to implement something like this, I feel that a feature like this is essential to PlayOnLinux, as end users do not want to mess with Wine versions, and for as long as this feature is not in PlayOnLinux, PoL will be (partially) redundant.

That's just my two cents, despite being lengthy.

Quentin PÂRIS Sunday 6 September 2015 at 22:28

Admin

Yeah I totally agree with this.

We are working with wine staging team to improve the way wine versions are managed. I cannot really tell you more so far, but I really agree that the current system has its limitation and need to be improved.

ack0329 Tuesday 15 September 2015 at 20:21

Anonymous

I love that you forging ahead with this (frankly I am ignorant in terms of the code options, sorry), but I can say your attitude ROCKS.  And as more of a PR person myself, I have little doubt you will make us all happy.

As the second post mentioned - I will be very happy if and when my Prefixes can grow with newer and better Wine Versions, and with less redundancy. I can't wait to see POL look like a 2020 application instead of seemingly always a little outdated (sorry to say - and by no means am I belittling all your hard work in the past)

Thanks for ALL your hard work, in the past and the future - your passion gives me such HOPE.surprise

DragonLich Wednesday 16 September 2015 at 13:50

Only from my personal curiosity. Did you take Vala in count of possible languages? It's C# syntax but it's C++ speed and it's compiled to C. If you did, why not to use it?

Please don't take me wrong, I don't think that Java is bad choice. I don't like it but for true, it's one of the best languages out there today. The only problem what I see is GUI which is in most cases really pain in Java apps but even this could be done right.

I wish you good luck with the new version and I'm looking forward to see it.

Quentin PÂRIS Thursday 17 September 2015 at 16:00

Admin

Feel free to read the latest news to get more recent update and insight ;-) https://www.playonlinux.com/en/comments-1299.html

Добавить комментарий

Ошибка

You must be logged in to post a comment