Skip to content
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

FileList field size now dependent on its content #1089

Merged
merged 1 commit into from
Apr 13, 2016
Merged

FileList field size now dependent on its content #1089

merged 1 commit into from
Apr 13, 2016

Conversation

chriba
Copy link
Contributor

@chriba chriba commented Apr 3, 2016

Fixes #672.
The FileList (within the EntryEditor) now automatically resizes its Columns dependent on the length of its content.

java 2016-04-03 12-13-50-65

  • Change in CHANGELOG.md described
  • Tests created for changes
  • Screenshots added (for bigger UI changes)

@boceckts boceckts changed the title fix-672 [WIP] fix-672 Apr 3, 2016
@chriba chriba changed the title [WIP] fix-672 FileList Field size now dependent on its content Apr 3, 2016
@chriba chriba changed the title FileList Field size now dependent on its content [WIP] FileList Field size now dependent on its content Apr 3, 2016
import java.util.List;
import java.util.stream.Collectors;
import java.util.stream.Stream;

Copy link
Contributor

Choose a reason for hiding this comment

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

Please change as little of the imports as possible. For example your remove the IOException and add it later again.

Copy link
Contributor

Choose a reason for hiding this comment

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

My guess is that it is some switch in the IDE that does this as the result is sorted. A bit "annoying" now, but might simplify things in the longer run.

Personally, I do not have strong opinions on what is the correct thing here, but others might... (And I know it is only for internal StuPro review so far... ;-))

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm using the standard style from IntelliJ IDEA, maybe someone should create a template for that (I thought there was one, but I can't find it right now).

Copy link
Member

Choose a reason for hiding this comment

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

Eclipse has an option to sort and manage imports (e.g. delete unused).
And one important thing: Only add the specific imports, e.g. java.util.List instead of whole packages.

@bartsch-dev Have a look at here:
http://stackoverflow.com/questions/14716283/is-it-possible-for-intellij-to-organize-imports-the-same-way-as-in-eclipse
http://stackoverflow.com/questions/11704327/intellij-idea-how-to-optimize-imports-automatically-after-each-save

Copy link
Contributor

Choose a reason for hiding this comment

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

I do not know what the "official" standpoint on * vs specific packages is.
I sort of prefer specific packages as you can see what dependencies you add
or remove, but I know that many of the other developers like (or at least
use) *.

(In this case both util.* and util.List looks a bit weird, but is required
as there is awt.List...)

Copy link
Member

Choose a reason for hiding this comment

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

I would recommend only using full qualified imports, easier to avoid conflicts, e.g. you import java.a* and google.com.b* and both contain different classes with the same name.

@tobiasdiez tobiasdiez mentioned this pull request Apr 3, 2016
@chriba
Copy link
Contributor Author

chriba commented Apr 11, 2016

I rearranged the Imports a bit (using the settings @tobiasdiez describes in #1091).

@boceckts boceckts added status: ready-for-review Pull Requests that are ready to be reviewed by the maintainers and removed stupro-ready-for-internal-review labels Apr 12, 2016
@chriba chriba changed the title [WIP] FileList Field size now dependent on its content FileList field size now dependent on its content Apr 13, 2016
@lenhard
Copy link
Member

lenhard commented Apr 13, 2016

Looks good to me me! @JabRef/developers anybody else any comments? Maybe we could integrate that in v3.3 already?

@@ -96,6 +96,8 @@ to [sourceforge feature requests](https://sourceforge.net/p/jabref/features/) by
- Fixed [#535](https://github.com/JabRef/jabref/issues/535): Add merge action to right click menu
- Fixed [#1115](https://github.com/JabRef/jabref/issues/1115): Wrong warning message when importing duplicate entries
- Fixed [#935](https://github.com/JabRef/jabref/issues/935): PDFs, which are readable, but carry a protection for editing, are treated by the XMP parser and the importer generating a BibTeX entry based on the content.
- Fixed [#672](https://github.com/JabRef/jabref/issues/672): FileList now distributes its space dependent on the width of its columns
Copy link
Member

Choose a reason for hiding this comment

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

As #672 is no bug this should be added to the "Changes" section.

@matthiasgeiger
Copy link
Member

Apart from my comment regarding the CHANGELOG this is fine and can be merged.

@matthiasgeiger matthiasgeiger added this to the v3.3 milestone Apr 13, 2016
@chriba
Copy link
Contributor Author

chriba commented Apr 13, 2016

Moved the changelog entry from fixed to changed.

@matthiasgeiger matthiasgeiger merged commit 488f74f into JabRef:master Apr 13, 2016
@chriba chriba deleted the fix-672 branch April 13, 2016 15:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: ready-for-review Pull Requests that are ready to be reviewed by the maintainers
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants