Messages

16

General / Re: Binding to C++ (Eclipse CDT - Mac os X)

« on: May 05, 2018, 02:14:25 pm »

Usually the approach with linking libraries is to point the -L flag to the library directory and then only specify the library name like -lsfml-graphics
However I'm unfamiliar with macOS and its dylib.

It applies as well to macOS and dylib/framework (with the later, use the -F and -framework flags, but it's the same).

17

Feature requests / Re: Better gamepad support

« on: April 25, 2018, 07:16:23 am »

If we (well, mostly you  ) can do this without modifying SFML, I'm wondering if it would make more sense to have this as an extension to SFML. I'm not against having this officially supported and embedded inside SFML, I'm just pondering alternatives. I'm on the train right now so it's a bit tedious to make research, but my main concern is maintainability of this DB: we have no guarantee the format will stay the same for example, do we? I guess we can assume it will be maintained (and not thrown away) for the foreseeable future if it's properly integrated into SDL, so that goes on the plus side.

I guess, having a first (draft of an) implementation would also help determining whether this is something we can maintain or not, although I have to admin that the implementation complexity is not my main concern at this point.

18

General / Re: help : SFML_2_4_2_osx_clang build error on macOS High Sierra

« on: April 24, 2018, 07:29:39 am »

I downloaded the SFML_2_4_2_osx_clang from https://www.sfml-dev.org/download/sfml/2.4.2/.

This archive contains already built binaries. If you want to build SFML either use the git version of the source code archive from the download page.

19

Feature requests / Re: Better gamepad support

« on: April 24, 2018, 07:27:02 am »

Having a unified interface would undeniably be useful to the community, I guess. I'm not familiar with SDL approach. Is this DB of runtime nature or is it embedded in its source code? Realistically, if we cannot reuse this DB, do we have enough resources to build our own?

20

Pull Requests & Testing / Re: Scancodes (Windows, Linux, Mac testing needed)

« on: April 10, 2018, 08:36:49 am »

Thanks a lot for the feedback ! I guess I have to put my hands on an external keyboard to properly test everything... but this will take time. If you/anyone wants to chip in code, please do not hesitate.

As for "buggy combinations", this is a known limitation of the wiring of most keyboard, regardless of the brand. The invalid combinations depends on the wiring so it's not consistent across keyboards but we can't do a thing about it.

PS: I've fixed SFML-Test-Events scancode branch... sorry it wasn't up to date!

21

SFML development / Re: How to have PRs merged faster without lowering quality

« on: April 09, 2018, 07:41:25 am »

My aim with the GitHub Project at the org level is to promote a bit more the tasks related to other components, such as the website or CI. But if it's deemed not accessible enough, then, of course, it would defeat its purpose...

22

SFML development / Re: How to have PRs merged faster without lowering quality

« on: April 05, 2018, 08:06:39 pm »

Me too. 

23

SFML development / Re: How to have PRs merged faster without lowering quality

« on: April 05, 2018, 07:54:28 am »

I've opened https://github.com/SFML/SFML-Buildbot/issues/15 if anyone wants to chip in! 

24

SFML development / Re: How to have PRs merged faster without lowering quality

« on: March 30, 2018, 08:55:00 am »

having CI also check the code after merging changes into master would help identify issues. I think it should be possible to configure a bot to report simple but helpful instructions for contributors (e.g. Please rebase your code).

A reminder is still an improvement but a small one. What would really help would be the automatic test with merge.

I'm not sure I follow. What I meant was that our CI would, in addition the existing tests, test the code after a local merge of the branch into master and, if any of the tests fail, the CI bot could emit a message on github with the error details.

Did you mean that the CI should automatically merge things? That'd be inadequate for the simple fact that the tests currently consist only in compiling the code. This won't indicate whether a bug was fixed or a feature correctly implemented.

I've seen it but I don't consider it to be a usable tool unless any PR author can change it, which I guess you don't want so that you can keep control. Probably a matter of trust.

It's not really a matter of trust, although if every kiddy can mess around our boards it would be a mess, obviously. But I think it absolutely makes sense to keep this board in the hands of a few. Why? Because, like a real company, not all developers are project managers and those are the only one that should organise priorities, IMO. The same applies, less critically, to tags in the end.

For curiosity, do you know if anyone is using the GitHub project apart from [eXpl0it3r]?

I do go and have a look from time to time, yes. Gives you a good overview of the progress and current status.

25

SFML development / Re: How to have PRs merged faster without lowering quality

« on: March 29, 2018, 07:11:41 pm »

If you don't want to deal with multiple PRs at once, then that's fine, but you can't just put the blame on the process. You could have contributed more or less 3 times more to SFML, if you used the waiting time to do it. An open PR didn't physically block you from contributing more.

I disagree with this statement. Sure, one is not physically blocked to do so, but you'll have to agree that basing your work on top of an open PR implies dealing with a lot of rebasing and conflict resolution. This is by far not the interesting bits! In my previous work experience I had to deal with that. It's really demotivating. If we can speed the merge process a little bit it would be a win. I mean specifically that when the code review and tests are done (not before) we try to merge more quickly.

That being said, I agree with you when you say that it takes time to properly review and test things out. But for that, I see quicker turnaround if the community is truly involved.

26

SFML development / Re: How to have PRs merged faster without lowering quality

« on: March 29, 2018, 07:51:52 am »

Regarding the promotion posts: they were in a dedicated thread, maybe it was pinned. I don't remember. But it wasn't in a dedicated sub forum section. That, we haven't tried.

I'm afraid that in the end the team would have to clean up / maintain a new subsection dedicated to that. But we haven't actually tried... So why not? In the worst case we close the subforum.

I think we can make the overall process a bit more accessible to contributor through github templates for issues and pull requests. We already have a dedicated page on this website and a pinned thread on how to help, but with those templates we can have some kind of checklists for contributors (that they cannot dismiss and therefore would also reduce the amount of questions/out of scope feature requests open on github). This checklist could include instructions on what to do for promotion on the forum.

Rebating should have been rebasing, thanks autocorrect... Anyway, having CI also check the code after merging changes into master would help identify issues. I think it should be possible to configure a bot to report simple but helpful instructions for contributors (e.g. Please rebase your code).

Of course, if we agree on such changes in the infrastructure we would need people willing to help implement those changes.

As for the tags: I haven't checked lately what options github gives us. Can we allow only tags to be set by a PR author, or everybody can modify them? I'm not 100% convinced it actually needed to let contributors change them, though. Currently we can ensure a consistent state with our github kanban. Also, what would be the added value for contributors? It's just a tag, helpful for searching, but not influencing the discussion happening in the PR.

27

SFML development / Re: How to have PRs merged faster without lowering quality

« on: March 28, 2018, 08:18:16 am »

Here is my opinion on the matter. If others team members disagree they will say it.

First of all, thanks for your ideas. I really appreciate community involvement in such matters.

We wish for more code review from the community!

Having more community feedback on code quality helps triage good and bad PRs. With more feedback we can also have a better appreciation of the need for new features and when it comes to bugs, we cannot reproduce everything and therefore NEED community reviews, in addition to testing.

Ultimately my feelings is that the whole team wants to ensure SFML keeps a high code quality standard. It's part of its 'personality'. That's why I suggest we request the final approval by a team member. My hope is that with more feedback this will go much faster as grey area in the code would already have been discussed.

Your suggestion for adding a tag and putting more light on those blocked PR is a good one, I think.

I've tried promoting a few of my PRs on the forun a while back. Sadly, it didn't work. It also adds some work. Maybe we should instead regularly advertise that people can subscribe to github issues if they want to contribute. But in any case, people can always open a thread for a specific PR and attract the attention of the community.

Regarding testing, community feedback is absolutely desirable, even required for most bugfix. When we have several people regularly accurately testing features/bugfixes we will be able to rely on them and therefore reduce the workload of the team member (so that we can focus on code review, merging stuff, design discussions, maintaining servers, ci and more).

It's true that we have relied solely on eXpl0it3r for the merging procedure, and that for quite a while. He's doing a fantastic job for sure. But maybe, eXpl0it3r, do you want other teamates to help? That goes without saying that other members should find some time for this as well.

Currently merging is done in batches to make rebating less tedious. If we merge a PR everyday or so, every other PRs need to be updated. So we have to find a tradeoff.

28

General discussions / Re: Possible Fullscreen Resolution change bug on Mac 10.13.3

« on: March 20, 2018, 07:31:01 am »

relevant information: https://en.sfml-dev.org/forums/index.php?topic=17246.msg147458#msg147458

29

General / Re: Xcode templates not working (RESOLVED)

« on: March 19, 2018, 08:19:14 pm »

I see... Well, first of all, thanks for the feedback!

With those evidences, I guess we can change the default until we have proper support for high DPI. Would you like to create a PR for that?

Side note: I don't remember what's the default when there's no plist file (e.g. command line app)...

30

General / Re: Xcode templates not working (RESOLVED)

« on: March 18, 2018, 08:37:35 am »

From the top of my head, disabling it will result in window decorations being blurry. As for the size, you always get the same number of pixels. I encourage you to test it and report issues, but the window should be properly resized when moving from a retina to a non-retina display (and vice versa).

Yet, I agree, we probably would benefit from a better API for screens. Not sure how it would look though...