opened
ctrlcctrlv
username_0
Time has come for this; I've inadvertently broken the build on other platforms a few time already.

Trouble is, I've never written a CI recipe from scratch before. Quite embarrassing, yes.

Maybe @eliheuer @username_2 @iwsfutcmd have ideas. (Why didn't you accept invitation to join organization btw Eli? I wanted to assign you to #7.)
Add Travis CI or AppVeyor (or both)
issue
created
alerque
username_1
I might be able to help with this, but I'd suggest using GH Actions, Circle, or Cirrus instead. Travis and AppVeyor are not my favorites.

Thankfully testing builds for Rust projects across platforms is one of the easier operations out there.
comment
created
jtanx
username_2
Yeah, if you're starting afresh, you're probably better off using github actions
comment
created
ctrlcctrlv
username_0
@username_1 Do you think it's worth it to test for "we get this first frame, and the frame has these colors in it (which should be a good, albeit not infallible, proxy for proper display)?"

For example, I just added a file dialog, and it would have been nice to automatically test the four platforms that matter to me: FreeBSD, GNU/Linux, Mac OS X and Windows 10. 👍 
![image](https://user-images.githubusercontent.com/838783/93080149-16433880-f642-11ea-8632-8176d69101e1.png)

![image](https://user-images.githubusercontent.com/838783/93080083-01ff3b80-f642-11ea-9157-d39ca428e206.png)
comment
created
ctrlcctrlv
username_0
(And yes, I guess this thing is written like a video game, since I've stared at Vulkan long enough to start calling the GUI a "frame". (._.))
comment
created
alerque
username_1
Honestly I think you should start simpler. If you're using a toolkit that has file open dialogs, you should trust it to draw them. As a first step, if it compiles and runs on each platform you can assume that the toolkit has all the bindings you are using. Whether a UI framework behaves as expected is really something that needs to be tested by the UI framework itself, not by an app that uses it. There are plenty of things to test about your app without testing things that aren't really even its purview.

Start simple with a matrix that compiles on different platforms. Rust is pretty good about failing during compile if something is wrong, that itself will be a good start.

If you are interested in a PR that sets this up let me know.
comment
created
ctrlcctrlv
username_0
I would be interested in any help, yes! :)

As you can see every day I'm adding features. Today I added moving of single points and handles. I actually have a version of the glifparser library that can write but I'm afraid to release it until I am satisfied with Qglif because I don't want people to start using it for serious work in its current state.
comment
created
alerque
username_1
In my experience that only makes sense for closed source projects, in open source the sooner code is available the more useful feedback and help you're likely to get along the way. People can make their own decisions about what to play with vs. what to use in production, and a sane semantic release process can help inform their decisions.
comment
created
ctrlcctrlv
username_0
I do appreciate that way of looking at things, and I promise that I'll release it Oct 1 regardless of the state of Qglif, even if I don't meet every goal I've set here on the tracker.
comment
closed
ctrlcctrlv
username_0
issue
created
ctrlcctrlv
username_0
Closed by #29. Thanks!
comment