The MAC_AutoUpload did not get put into bintray and I understand why. Until or unless we are ready to do a new release I don’t think it is worth the time to fix it. For more detail (possibly more than you want) read this:
[Bintray Upload] Uploading file ‘./seamly2d-osx-e184e156493b5ca8e3ef8474e7f385da7ec85327.tar.gz’ to seamly2d-osx-e184e156493b5ca8e3ef8474e7f385da7ec85327.tar.gz
[Bintray Upload] Bintray response: 403 Forbidden. Version ‘0.6.0.1’ has been published for more than 365 days. Files can only be uploaded to a version within 365 days from its publish date.
[Bintray Upload] Uploading file ‘./src/app/seamly2d/bin/seamly2d-osx-e184e156493b5ca8e3ef8474e7f385da7ec85327.tar.gz’ to seamly2d-osx-e184e156493b5ca8e3ef8474e7f385da7ec85327.tar.gz
[Bintray Upload] Bintray response: 403 Forbidden. Version ‘0.6.0.1’ has been published for more than 365 days. Files can only be uploaded to a version within 365 days from its publish date.
[Bintray Upload] Publishing version ‘0.6.0.1’ of package ‘Seamly2D-mac_auto-upload’…
[Bintray Upload] Bintray response: 403 Forbidden. Files from version ‘0.6.0.1’ can’t be published. Files can only be published within 365 days from the version publish date.
Travis should trigger the launchpad build and the launchpad build should be based on code pulled directly from the GITHUB repository. I have not yet taken the time to figure out how launchpad gets triggered, but I have proven that changes to repository code get included when it does
I am fairly sure that the ubuntu (launchpad) will be automagically done based on the second of two travis job logs:
0.00s$ if [[ ("$TRAVIS_OS_NAME" == “osx”) && ("$DEPLOY" == “true” ) ]]; then
…/scripts/macfixqtdylibrpath.py TRAVIS_BUILD_DIR/build/src/app/seamly2d/bin/Seamly2D.app;
cd src/app/seamly2d/bin -R;
tar --exclude "*.DS_Store" -zcvf seamly2d-osx-{TRAVIS_COMMIT}.tar.gz Seamly2D.app;
cd …/…/…/…/
cp src/app/seamly2d/bin/seamly2d-osx-{TRAVIS_COMMIT}.tar.gz seamly2d-osx-{TRAVIS_COMMIT}.tar.gz
fi
dpl_0
1.79s$ rvm $(travis_internal_ruby) --fuzzy do ruby -S gem install dpl
Fetching dpl-1.10.7.gem
Successfully installed dpl-1.10.7
Parsing documentation for dpl-1.10.7
Installing ri documentation for dpl-1.10.7
Done installing documentation for dpl after 0 seconds
1 gem installed
2.80s
dpl.1
Installing deploy dependencies
Fetching dpl-launchpad-1.10.7.gem
Successfully installed dpl-launchpad-1.10.7
Parsing documentation for dpl-launchpad-1.10.7
Installing ri documentation for dpl-launchpad-1.10.7
Done installing documentation for dpl-launchpad after 0 seconds
1 gem installed
dpl.2
Preparing deploy
dpl.3
Deploying application
Done. Your build exited with 0.
@Calum If you care to see anything about the build pipeline, I would suggest that you take a look here: Hacking:Technical decisions - Seamly2D at the last paragraph on continuous integration and follow the link to here: Seamly2D ci - Seamly2D. I have not done a compete documentation of the pipeline, but this will give you a start
a bug –> fix –> test workflow. Not sure how to implement this with Github
I think the simple approach is to merge it into develop, unless it’s big enough to merit its own feature branch, and make it the rule that the issue can’t be closed until the agreed testing has been done, whatever that is. Ideally, the testing requirements would be identified at the beginning of the process - before anyone starts hacking.
It seems to me our build requirements are pretty “normal”, so it ought to be possible to get daily (sorry, dayly) builds going for all platforms, and helpful if we want real users to test/check specific features.
Most of this process was set up before I ever became involved. I added the slots for windows and mac versions of daily builds. The launchpad version of daily build was already set up, though it is not precisely daily.
Because I acknowledge that I do not come into this project already knowing everything and because I believe in “first do no harm” I have avoided doing anything that will make a noticable impact to new users. For those reasons I have not touched “Seamly-2D-win-release” or “Seamly-2D-mac-realease”, though @slspencer continues to work to get resources in place and I believe a new release is on the horizon.
The “Seamly2D-win_auto-upload” and “Seamly2D-mac_auto_upload” are “automagically” created when an “official” build of the development branch off github completes successfully. The ability to access and change those slots and build procedures is password protected and @slspencer controls the passwords.
I personally created the slots called "Seamly2D-win_daily-build’ and “Seamly2D-mac_daily-build” . Nobody has done anything with them yet.
Going forward, these are tasks that somebody will need to do to
so it ought to be possible to get daily (sorry, dayly) builds going for all platforms, and helpful if we want real users to test/check specific features.
update the appveyor.yml file on github to include the steps needed to create a build artifact and upload it to bintray "Seamly2D-win_daily-build’ for initial testing by someone other than the original coder for changes integrated into the windows platforms
update the travis.yml file on github to include the steps needed to create a build artifact and upload it to bintray "Seamly2D-mac_daily-build’ for initial testing by someone other than the original coder for changes integrated into the mac platforms
update the travis.yml file on github to include the steps needed to trigger the launchpad build for the linux distributions who draw from the launchpad “dayly-build” PPA
Those tasks do not represent all that needs to be done, but a bare minimum. Other things that come to mind are
define a set of operating systems and configurations that “WILL be supported” and make a policy that others “WILL NOT be supported”. This does not preclude members of the community, including myself, from attempting to give support or advice to users who have the talent and will to make the software work on some other platform.
clean up the naming to complete the changeover from valentina to seamly in many places where it still exists, e.g. the URL https://wiki.valentinaproject.org/wiki/Main_Page that points to the Seamly2D wiki
clean up the documentation to describe the actual build processes as they exist (the stuff I wrote on
@Calum If you care to see anything about the build pipeline, I would suggest that you take a look here: Hacking:Technical_decisions at the last paragraph on continuous integration and follow the link to here: Seamly2D_ci . I have not done a compete documentation of the pipeline, but this will give you a start:
is only the tip of the iceburg and more needs to be done
much more that I have not thought of and you and others are heartily welcomed if you feel willing and able to contribute.
FWIW, I have tons of other things in my life that demand my attention today and probably what I just wrote is all that I can contribute for this day. @schwowsers are you still out there and do you want to come play? We miss you
I just checked and verified that the https://launchpad.net/~susan-spencer/+archive/ubuntu/seamly2d-dayly-build was successfully updated. I have not investigated the details yet, but I believe this gets triggered by one of the two scripts that run on travis after a merge on the development branch. @Calum that means that if you want to, you may enable the PPA
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)
This did not happen because I (or anyone else) did not change the version from 0.6.0.1.
The reported error in the build log is
[Bintray Upload] Bintray response: 403 Forbidden. Files from version ‘0.6.0.1’ can’t be published. Files can only be published within 365 days from the version publish date.
I know how to fix this but do not choose to exert the effort until we are ready to prepare a new release after cleaning up the master and release branches on github.
Copy the latest code over to Launchpad which then auto-builds our Ubuntu package (which can be accessed from our website)
The Launchpad build did correctly happen and if you use apt-get from the “dayly-build” ppa, which I do, you can run it. Below is a screenshot of the version.
So I get confused when these things don’t happen."
I will summarize the several long messages (below in this thread) that I wrote.
The one you looked at which appeared broken was because of something I did, and then corrected. The build was still in progress when you looked. @Calum fixed a minor bug then created a pull request and submitted the fix. I merged the fix and that triggered the latest, successful builds and here we are.
The “fix” is not even close to controlling how the main graphics view area scrolls. Changing the QAbstractScrollArea::SizeAdjustPolicy to AdjustToContents only serves to set the size hint on how the scroll area is to adjust the layout size when the MainWindow->view widget size is changed.
enum QAbstractScrollArea::SizeAdjustPolicy
This enum specifies how the size hint of the QAbstractScrollArea should adjust when the size of the viewport changes.
Constant
Value
Description
QAbstractScrollArea::AdjustIgnored
0
The scroll area will behave like before - and not do any adjust.
QAbstractScrollArea::AdjustToContents
2
The scroll area will always adjust to the viewport
QAbstractScrollArea::AdjustToContentsOnFirstShow
1
The scroll area will adjust to its viewport the first time it is shown.
It does not change the scrolling movement. Scrolling is custom controlled in the VMainGraphicsView and GraphicsViewZoom classes and consists of a series of related zoom & scroll functions that respond to mouse, wheel, gesture, and keyboard mod events - along with the use of a few QTimeLIne classes. It’s not a minor tweak if you take into account that the scrolling / zoom speed should not be fixed, but a user preference. Which is what I did way back before the Seamly fork was useable.
In additIon to adjusting the scroll, zoom & wheel speeds, I added an option to turn the scrollbars off, and a tool to “zoom to rubberband area” - which IMO when used with the pan & wheel zoom tools renders the scrollbars that only take up screen space - useless. There’s also an option to set the scrollbar size in the case where one still wants the scrollbars, but to reduce the footprint.
