Skip to content

Issue/84 #86

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 9 commits into from
Dec 26, 2018
Merged

Issue/84 #86

merged 9 commits into from
Dec 26, 2018

Conversation

Sciss
Copy link
Contributor

@Sciss Sciss commented Dec 12, 2018

Ok, my attempt at the same thing. Sorry, commit is big due to clean-ups. What's mainly missing is ListView.selection.items. You can ignore the examples (they are just clean-up).

Fixes #84

- add explicit return types (e.g. Proxy's self now is Any)
- fully qualify imports, avoid wildcard imports
- remove dummy class Matrix
- introduce SetWrapper and MapWrapper, similar to @som-snytt 's shims
  (seems we can't do without)
- clean up code
- add scala.swing.Seq alias (as in @som-snytt 's version)
- TODO: ListView#selection.items is still `???`
@Sciss
Copy link
Contributor Author

Sciss commented Dec 12, 2018

Looking at https://github.com/Sciss/SwingPlus now to see how far we get with the new version. It seems that the different collection type for insertAll is very unfortunate, and thus it would be best to add a type alias to package.scala

@Sciss
Copy link
Contributor Author

Sciss commented Dec 12, 2018

package-private BufferWrapper is also not good.

- this mirrors the provisions of buffer-wrapper and is needed
  by third party swing extensions to avoid forking sources
  between Scala 2.12 and 2.13
- also provide a default `clear` implementation
@Sciss
Copy link
Contributor Author

Sciss commented Dec 16, 2018

I managed to build my entire desktop application tree now; from what I can see, all seems to be fine, so this PR is ready for review. Anyone? @SethTisue @benhutchison @som-snytt

@@ -14,6 +22,8 @@ package object swing {
type Image = java.awt.Image
type Font = java.awt.Font

type Seq[+A] = scala.collection.Seq[A] // because scala.Seq differs between Scala 2.12 and 2.13

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont understand what this line is for..

Copy link

@som-snytt som-snytt Dec 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can be removed and two spots fully qualified instead: Container.Wrapper.contents and ListView.selection.items. Also Container.contents.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the other hand, I found it quite handy in other libs to use swing.Seq. But I guess that's a bit idiosyncratic. So I remove it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the other hand, I found it quite handy in other libs to use swing.Seq. But I guess that's a bit idiosyncratic. So I remove it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@som-snytt Seq is used in more than those three places: ComboBox, Container, FileChooser, ListView, Menu, RichWindow, RootPanel, ScrollPane, SplitPane, Table. I'd say it's better and safer to have a type alias in the swing package object.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Im fine with that if you want @Sciss

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd remove it, I think it can be confusing. If you were writing the library now, for 2.13, would you create such an alias?

- remove the commented former and unused class `RefBuffer`
- add more information about architecture (events)
  to read-me; update information about versions and branches
@Sciss Sciss changed the base branch from 2.0.x to work December 17, 2018 00:38
@Sciss
Copy link
Contributor Author

Sciss commented Dec 17, 2018

created branch work from 2.0.x which can serve as basis for further development. Since versions are tagged, I don't think we need one branch per each new version. Updated README accordingly.

@benhutchison
Copy link
Contributor

Agree that we should keep minimum branches, I like that there's just one branch to worry about for the future.

@SethTisue
Copy link
Member

I probably won't be able to look until January, perhaps @lrytz could take a look

Copy link
Member

@lrytz lrytz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

@@ -14,6 +22,8 @@ package object swing {
type Image = java.awt.Image
type Font = java.awt.Font

type Seq[+A] = scala.collection.Seq[A] // because scala.Seq differs between Scala 2.12 and 2.13

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd remove it, I think it can be confusing. If you were writing the library now, for 2.13, would you create such an alias?

@benhutchison
Copy link
Contributor

All good from me

@Sciss
Copy link
Contributor Author

Sciss commented Dec 18, 2018

@lrytz ok - so I removed swing.Seq; I took the opportunity, though, to move to immutable.Seq now where possible and reasonable.

- we leave scala.collection.Seq where the API would use
  Java Arrays, so we do not get sub-par performance in 2.13
- we use the more strict type immutable.Seq where its effortless
  and actually ensures correct behaviour. Since we are in a
  binary incompatible new scala-swing version, in the worst case
  user code that used Array in Scala <2.13 would have to enforce
  toList, toVector or similar
- the previous signature `selectedFiles_=(files: File*)` does not
  make sense, because we want to write that without parentheses,
  and getter and setter should have matching arguments. Use
  s.c.Seq now in both cases.
@Sciss
Copy link
Contributor Author

Sciss commented Dec 18, 2018

If no more objection, I will merge this tonight, and then bump version to stable 2.1.0 -- who would be responsible for pushing the new artifacts to Maven Central?

@lrytz
Copy link
Member

lrytz commented Dec 18, 2018

move to immutable.Seq now where possible and reasonable.

I think that's great! This sounds like it should go in a major release though?

@Sciss
Copy link
Contributor Author

Sciss commented Dec 18, 2018

I think that's great! This sounds like it should go in a major release though?

I did this since we are already on a new major version 2.1.0 (previous is 2.0.x) due to several changes. I have compiled multiple projects now with the snapshot; it should be source compatible for almost all cases.

@lrytz
Copy link
Member

lrytz commented Dec 18, 2018

Great! I can click the buttons to release the artifacts to maven central, just ping me.

@Sciss
Copy link
Contributor Author

Sciss commented Dec 18, 2018

@lrytz ok - good to go then! the only thing missing would be to change version to "2.1.0" instead of "2.1.0-SNAPSHOT" in build.sbt, after merging the PR and before publishing.

@benhutchison
Copy link
Contributor

Lets pull the trigger on this.. @Sciss OK to merge?

@Sciss Sciss merged commit 3566a92 into scala:work Dec 26, 2018
@Sciss
Copy link
Contributor Author

Sciss commented Dec 26, 2018

@benhutchison are you familiar with https://github.com/scala/scala-swing/tree/work/admin#tag-driven-releasing - if so, could you bump to 2.1.0 stable, tag and publish?

@benhutchison
Copy link
Contributor

benhutchison commented Dec 26, 2018 via email

@Sciss
Copy link
Contributor Author

Sciss commented Dec 26, 2018

Note that the version in build.sbt that has the git-tag v2.1.0 still says "2.1.0-SNAPSHOT". So probably it needs another commit with that incremented.

@benhutchison
Copy link
Contributor

benhutchison commented Dec 26, 2018 via email

@Sciss
Copy link
Contributor Author

Sciss commented Dec 27, 2018

@lrytz Lukas, could you please check in to sonatype and release the artifacts? Double check, because since I moved the v2.1.0 tag to the new commit with the stable version in build.sbt, Travis published again, so I don't know if it just overwrites the previously staged files or not.

As far as I can tell, Ben's release didn't make it to Maven Central yet:
https://search.maven.org/search?q=g:org.scala-lang.modules%20AND%20a:scala-swing_2.12&core=gav

@SethTisue
Copy link
Member

SethTisue commented Dec 28, 2018

It's no big deal, but I don't think there was any need to move the v2.1.0 tag. The version in the published artifacts is determined by the tag, overriding the version setting, so it's fine to bump that setting after publishing.

Anyway, I don't understand exactly what happened, but somehow we ended up in a confused situation where the staging repos ended up with a mix of artifacts from the two different attempts, with different checksums.

It seems likely to me that the artifacts from either attempt are fine, but the whole thing makes me nervous. So I dropped all four staging repos (1658 through 1661), deleted the v2.1.0 tag, and then re-pushed the tag.

The new Travis job is https://travis-ci.org/scala/scala-swing/builds/473049546

@Sciss
Copy link
Contributor Author

Sciss commented Dec 28, 2018

@SethTisue ok thank you. The problem with the alignment of the tag is also that, for example, in GitHub releases you download attached sources that don't correspond with the maven sources, because version was still 2.1.0-SNAPSHOT.

I don't know what the general procedure is next time, but I think it's best to match build.sbt version with git tag. ?

@SethTisue
Copy link
Member

I don't know what the general procedure is next time, but I think it's best to match build.sbt version with git tag. ?

It certainly can't hurt!

@Sciss
Copy link
Contributor Author

Sciss commented Dec 28, 2018

I would follow roughly this: https://github.com/sbt/sbt-release#release-process

So, after release, merge to master, then push another commit to have the next SNAPSHOT in work.

@SethTisue
Copy link
Member

staging repos 1662 and 1663 closed and released, artifacts should be on their way to Maven Central

@Sciss Sciss deleted the issue/84 branch December 28, 2018 16:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants