serge-rgb / milton

An infinite-canvas paint program
GNU General Public License v3.0
1.53k stars 133 forks source link

I'm interested in helping bring Milton to Linux #20

Open maffblaster opened 8 years ago

maffblaster commented 8 years ago

Hi @serge-rgb, as the title mentions, I'm interesting in helping bring Milton to Linux. I'm a Gentoo staffer, so I'd have to start there. Where do you need/want help? What can I do?

EDIT: I'm coming back to mention that I did a little poking around and didn't notice a dependency list. I'm not too familiar with graphical C++ projects, so perhaps you can point me in the correct direction regarding what I need to get this project compiling. :) Thanks!

serge-rgb commented 8 years ago

Hi Matthew. Thanks! It would be great to have some help porting to Linux.

Right now, you would need to have the development libraries for SDL 2. You could start with clang++ milton_unity_build.cc and see what happens.

Most of the functions that need to be implemented have the prefix platform_ and are declared in platform.h. Take a look at platform_mac.cc for some implementation stubs.

I did not do a very good job of modularizing the platform code. The OSX port (WIP) compiles platform_unix.cc as well as a platform_mac.cc, so I would put all the Linux-specific code in a new platform_linux.cc file for now. We could always do a cleanup step after things are working.

Functions like platform_open_dialog(...) need a window manager. I think GTK is the best choice but feel free to choose something else as long as things stay simple

I hope this helps! I'll edit this post later if I miss something. Please let me know of any questions you have!

Thanks again

maffblaster commented 8 years ago

Cloned and attempted to build. Seems like I'm missing a header:

milton_unity_build.cc:5:10: fatal error: 'stb_image_write.h' file not found
#include <stb_image_write.h>
        ^
1 error generated.

Any ideas where I can find this header?

serge-rgb commented 8 years ago

You need some include flags: -Ithird_party, maybe you also need -Ithird_party/imgui I don't remember exactly but I think that there was a name clashing issue after adding those flags.

ApoorvaJ commented 8 years ago

If you do decide to go the GTK route, this pull request that I received on Papaya may be of some help. It succinctly added open/save functionality, and also enabled GTK linkage.

serge-rgb commented 8 years ago

This looks like just what Milton needs. Thanks!

maffblaster commented 8 years ago

@serge-rgb, I got a bit farther...now it seems to be missing #include "shaders.gen.h"

Check this gist for full build log.

serge-rgb commented 8 years ago

The assert implementation should be using __builtin_trap() if the compiler is warning about it. On Windows it uses __debugbreak(). It seems like it's already using __builtin_trap() on MacOS. Just a matter of changing #elif defined(__MACH__) to #elif defined(__MACH__) || defined(__linux__) in the definition of mlt_assert in common.h It also looks like you need to add -Wno-c++11-compat-deprecated-writable-strings.

Come to think of it, you have to do almost the same things that the build_osx.sh script is doing. I should have thought of that before...

shaders.gen.h is generated by the program shadergen.cc It's a separate step. First build and run shadergen, then build Milton.

cmourglia commented 7 years ago

Any input on this ? Are you still working on this @maffblaster ? I could have a look at the IMPL_MISSING stuff, but it would not be that smart if it has already been done...

serge-rgb commented 7 years ago

@miotatsu did a bunch of work to get Milton compiling and running. I'm supposed to take on the rest of the work, but patches are of course welcome!

cmourglia commented 7 years ago

Ok, cause the master branch il just crashing for me because of stuff not implemented. I might at least PR for the timers stuff.

ghost commented 7 years ago

Yeah I got it to compile and run but any of the menu related stuff will crash it from IMPL_MISSING. I'm thinking I'll implement dialogues, or at least a dialogue for save, as that would be useful to me

Edit: I implemented the majority of a save dialog today on my stream. If I get save and open finished up tomorrow I'll submit a pull request, otherwise it will have to be some time after handmade con. :)

ghost commented 7 years ago

@serge-rgb today on stream we encountered some interesting behaviour while working on this. No persistent canvas (does it require some config?) and our save dialog seemed to correctly return the chosen path, but it failed to write out the file...

https://youtu.be/3xm2pdjz218?t=41m40s

Let me know if you have any insights regarding this

serge-rgb commented 7 years ago

Here's my hunch: Milton will try and save first to ~/.milton/milton_tmp.[PID].mlt. It copies the file to the final destination only after writing successfully to the tmp file. The problem might be that platform_fname_at_config is not working. I had the same problem when hacking a quick demo in OSX which I has since deleted...

I believe the line snprintf(fname, len, "~/.milton/%s", string_copy); in platform_fname_at_config in platform_linux.cc should be something like snprintf(fname, len, "%s/.milton/%s", getenv("HOME"), string_copy); Hopefully that will do the trick. Let me know if that helps

ghost commented 7 years ago

Today I implemented directory creation of the .milton folder if it does not exist, and it now writes to ~/.local/share/milton instead of ~/.milton if the env variable XDG_DATA_HOME is defined. I also fixed that segfault we left off at last stream. I'll finish up those half implemented dialogs tomorrow and submit a pull request :)

offtopic: have I been pronouncing "serge" correctly, and do you prefer that over "Sergio?" A viewer on stream today mentioned that and I was like uh, he hasn't corrected me if I'm wrong! :P

serge-rgb commented 7 years ago

I didn't correct you because I feel it's my fault for choosing a handle with ambiguous pronunciation, but it's supposed to be pronounced "search". :P I'll take a look at the archived stream to see how you solved the weird segfault.

serge-rgb commented 7 years ago

Hey @miotatsu, just made a couple of commits.

Also, looking good! Thanks for all your work :)

ghost commented 7 years ago

Hm everything seems to be working on my machine, I'm not sure why gtk_dialog_run would hang for you

serge-rgb commented 7 years ago

I am watching ep 15 of RISCy Business. I made the mistake of installing another distro and I'm not getting the gtk_dialog_run bug anymore. I'm sure the bug will pop up again sooner or later. Please send me an email for any questions you have about how the renderer works! Also, if you want me to implement lines, I will happily do it. Unless you like the challenge. I'm certainly enjoying the streams!

C0rn3j commented 7 years ago

After playing around with Milton for a small while, my entire X session froze and I had to pkill Milton from a different TTY.

Using GTX 970 with Nvidia proprietary drivers (375.26) and i7-4790K.

Cursor starts blinking very rapidly and GPU usage goes through the roof(65%+).

This seems to be caused by clicking(left/middle/ not right) on either of the brushes/layers/effects menu on any part.

The color picker does not have this problem.

Running Milton through the terminal doesn't seem to generate any errors, so if you need any other information, feel free to ask.

EDIT: Also forgot - I'm using Arch Linux. To avoid package questions, here's a list of all installed packages - http://pastebin.com/GXpT7RBK

serge-rgb commented 7 years ago

Hey C0rn3j. Is the problem fixed now? I fixed another Nvidia bug and I think it's possible it might have fixed your problem.

ghost commented 7 years ago

Hey @serge-rgb I'm updating my fork of Milton and I've encountered a few bugs - opening a canvas is broken and the X11 cursor blinks, idk if you've noticed on my streams but in my version the cursor shows as a drag cursor, with the brush circle under it (I assume the intended behaviour is for the system cursor to be hidden?)

I haven't looked into the blinking yet but I checked to make sure the code for the canvas opening hadn't changed, only difference is a comment was removed. I printed the text coming out of the open file dialog and it correctly gets the path of the canvas I want to open. So it seems like all that code is working but for some other reason the canvas does not appear...

Both of these issues happen in the vanilla version on my machine as well, so it isn't because of changes in my fork. I'll continue to investigate these issues on my own but let me know if you've got any ideas as to what might be causing them :)

serge-rgb commented 7 years ago

Hey there! Maybe it could be a corrupted file? If it's failing to load it will fail silently because the dialog code isn't implemented yet. I just fixed a couple of corrupted mlt files someone sent and it seems to be a latent off-by-one bug which I haven't found yet. If it is a corrupted file, please send the mlt file to me and I can probably recover it.

Regarding the blinking. I see it on my machine and it's kind of annoying. I will watch your stream this weekend to find out if you totally fixed it. But yeah, the expected behavior on linux is to hide the system cursor. On windows we draw a custom system cursor but SDL doesn't support that on linux yet AFAIK

ghost commented 7 years ago

I figured out the canvas opening bug today, it is because the yes no dialog isn't implemented so it skips bumping the canvas milton_binary_version to 4, if I let it take that codepath the canvas gets updated and loads fine. It's not because of corrupted mlt files.

I'll go ahead and implement that dialog this weekend

therealrobster commented 6 years ago

Hi there, just seeing if you've been successful in getting Milton running on Linux? I've got Ubuntu 18.04 and am dead keen to give Milton a try.

americapat commented 6 years ago

Hi all, I am wondering is someone has already compiled milton git on Debian (SMP Debian 4.16.16-2 (2018-06-22) x86_64 GNU/Linux) . Had to modify few trivial files, but now, it's the dynamic class factory that doesn't compile and, course it's a little tricky. Has Anyone done that already? ... Generating shader code... Shaders generated OK Scanning dependencies of target Milton [ 19%] Building CXX object CMakeFiles/Milton.dir/src/gl_helpers.cc.o In file included from /home/pat/milton/src/gl_helpers.h:9:0, from /home/pat/milton/src/gl_helpers.cc:5: /home/pat/milton/src/gl_functions.inl:5:17: error: ‘GLenum (* glGetError)()’ redeclared as different kind of symbol X(GLenum, glGetError, void)\ ^ /home/pat/milton/src/gl.h:37:80: note: in definition of macro ‘X’

define X(ret, name, ...) typedef ret name##Proc(__VA_ARGS__); name##Proc * name ;

                                                                            ^~~~

/home/pat/milton/src/gl.h:38:8: note: in expansion of macro ‘GL_FUNCTIONS’ GL_FUNCTIONS ^~~~ In file included from /home/pat/milton/src/system_includes.h:53:0, from /home/pat/milton/src/gl_helpers.h:7, from /home/pat/milton/src/gl_helpers.cc:5: /usr/include/GL/gl.h:829:25: note: previous declaration ‘GLenum glGetError()’ GLAPI GLenum GLAPIENTRY glGetError( void ); ^~~~~~ In file included from /home/pat/milton/src/gl_helpers.h:9:0, from /home/pat/milton/src/gl_helpers.cc:5: /home/pat/milton/src/gl_functions.inl:6:17: error: ‘GLint ( glGetAttribLocation)(GLuint, GLchar)’ redeclared as different kind of symbol X(GLint, glGetAttribLocation, GLuint program, GLchar* name) \ ^ /home/pat/milton/src/gl.h:37:80: note: in definition of macro ‘X’

define X(ret, name, ...) typedef ret name##Proc(__VA_ARGS__); name##Proc * name ;

                                                                            ^~~~

/home/pat/milton/src/gl.h:38:8: note: in expansion of macro ‘GL_FUNCTIONS’ GL_FUNCTIONS ^~~~ In file included from /usr/include/GL/gl.h:2055:0, from /home/pat/milton/src/system_includes.h:53, from /home/pat/milton/src/gl_helpers.h:7, from /home/pat/milton/src/gl_helpers.cc:5:

F1LT3R commented 5 years ago

I'd pay up to $500 a year to have this running and supported on Linux, especially Raspian, and especially if you can export a playback file that can be converted to MP4.