Just a note to say I’ve created an issue on Github to fix the way the main view window scrolls - I know how to fix it, so all I need to do now is (re)learn how to work Git(!) My username on there is u38cg.
I also need to be able to create a feature branch, is that right?
@Calum, first, thank you for your willingness to fix the problem that you have identified. I have added you as the assignee on the issue you created on github
the easiest way to proceed is probably to clone the repository then create a feature branch in the cloned copy. do your testing, then you can push the changes back to the main repository. someone with privileges to merge will have to approve the change before it gets distributed, but that should not be a problem.
what configuration will you use to test your changes? I primarily use ubuntu, can run several different ubuntu configurations, and will reach out to others who test on windows or mac
When I started, I had several experiments that worked less well. I talked with the project founder (@slspencer) and started reading some of the documentation that exists and figured out enough to learn to build the software in various ways. I am really not “the expert” and not sure that “the expert” really exists. Here is what I would recommend for you as a good next step.
create a user account on github (you already have this)
Once you have your own repository (github will automagically keep track of the fact that the fashion freedom Seamly2D repository is the parent)
You will probably need to create a new local git repository on your machine (at least that is what I finally decided to do). Do this by cloning a copy of YOUR github repository. Make your changes locally. Push them all the way to the “origin” with your local git tool and I believe that will ripple all the way to the main (fashion freedom/seamly2d) repository.
I will be looking out for it, and please contact me again here on the forum when you are done.
If the response time on the forum becomes bothersome for you, lets talk about more “real time” messaging methods.
@Calum, Please also point out inconsistencies as you find them because I know that the documentation is not perfect. It is a community effort and you and I are part of the community. I will fix whatever I am able and I am delighted if you are willing and able to help
I agree on the documentation - I think the main point I’d make on that front is I see documentation for the same thing in multiple places, and I think it might perhaps be helpful if some at least were simply deleted and replaced with pointers to one single place. I’ll come up with more intelligent thoughts as they happen.
Re, multiple (sometimes consistent, sometimes not) documentation on any given subject, please see also Seamly2D. In a perfect world I can discipline myself to create a LIST of all the issues and not get off on a tangent trying to fix them. Any insights you may have regarding what should be on that list are welcome
@Calum I just noticed that your fix made it all the way to the main repository. I will test it out over the weekend and be in touch about how you can get the executable
Calum, do you have any interest in learning how to make a snap, flatpack, or appimage package? I have never done any of these, but have agreed with @slspencer that it would be nice if…
From what I have read, they are all cross platform self contained packaging methods similar to a windows “exe” file that will work on multiple linux distributions. That would address your concern about something less cumbersome than a distribution package
I managed to figure out how to get QtCreator working - my problem wasn’t the cumbersomeness, I just wanted to be able to run my testing builds without having to install them as a package, clobbering my working install that I was actually doing work on patterns with.
The problem with the appimage and friends approach is that it is “one size fits most” - the whole point of distribution package management is sharing code and libraries and managing dependencies and versions effectively. A single executable installer is attractive, but only works on major architectures and distributions; plus there’s a philosophical argument that training users to execute random files they download is generally a bad thing. That said I don’t have strong opinions either way.
At the moment what I’d like to do is some fiddling around fixing minor bugs and re-learning C++ (it’s been a while!) but my current priority list is something like everything else > sewing > pattern designing > developing…so it will be a bit slow!
The first “universal package” that entered my awareness was SNAP. I initially was really enthusiastic about it until I started using Ubuntu 18.04. That long term support version ships with SNAP packaged applications for many of the commonly used functions (like the Firefox web browser). I discovered the hard way that as I user I had to be aware of issues related to the way that SNAP creates the sandbox environment. My first issue was that I could no longer just pick one of my stored happy birthday memes from a directory to add to a greeting when our universal assistant “Facebook” nudged me that there was a birthday. I had to explicitly go to the directory because the SNAP app created its own user “home” directory and did not use mine. I figured out how to set a parameter in the application to fix this, but it was only one of the many undocumented surprises that came with SNAP. As with most things, it is a work in progress.
What I have learned to do since I want to be able to run multiple versions is create a “dual boot” actually a “multi boot” computer. I have one dedicated machine that came with windows 7. I bought a 4TB hard drive and created multiple partitions and have several ubuntu installations. I may be asking for your help soon if I decide to install MINT. I am an OLD computer geek and once worked on several different operating systems (not all at once) so I am fascinated by and not intimidated by installing different things. I tried using different builds of seamly and coexisting with valentina by uninstalling then reinstalling packages on a single ubuntu version and found it to easy to shoot myself in the foot with that approach.
Re testing (of issue #193) - there sin’t really much to test, as it’s an internal Qt setting. Open a pattern file, zoom in, scroll up and down - it should be better than it was, and certainly no worse!
OK, I’m trying to get some type of process going where we have a bug --> fix --> test workflow. Not sure how to implement this with Github other than adding an issue for testing.
I just (15 minutes ago) merged the pull request that Calum submitted re this issue. I agree that there “isn’t much to test” and I agree that this minor fix will likely not break anything. The merge went into the development branch, so the process of creating the NEXT official release is something we still need to adress
But the latest build broke because we tried to build it after the merge. I’m confused, I thought when we merge a feature branch into the develop branch then these things happen:
Build the the Windows and Mac executables and stores these at JFrog/Bintray (where they can be downloaded from our website)
Copy the latest code over to Launchpad which then auto-builds our Ubuntu package (which can be accessed from our website)
I commented and closed the pull request, then reopened it and then approved the merge. That may have been the problem. I will take a look at it. The people I need to talk to about my mom’s issues are all at the end of their eastern daylight time day
@slspencer Give it about an hour and I hope that the appveyor build will complete successfully. It is not done yet. The failed one is because of the sequence I just described