Fix ResizableControl::DisableResizing about gwork HOT 19 CLOSED

To make a pull request here all you have to do is fork Gwork and then push your change to that repo. It's just another remote.

from gwork.

If I were actively using github that would be very convenient for everyone involved, but as it is now I'm not interested in jumping through those hoops. It would be nice for my bugfixes to be made available to others, to improve the lib for everyone, but ultimately I have nothing personally to gain from it.

Applying a diff is trivial, through git apply , far easier than for me to cajole github into accepting the pull-request. If anyone is interested in the fix and you insist that someone create a pull-request, I welcome them to create one. If not we can instead consider this a bug report.

from gwork.

That's a shame. I was hoping to build a community of regular contributors. I've spent a lot of my personal time refactoring this library so others could benefit.

from gwork.

I agree. I was surprised that github had no way of making a pull-request other than within the very rigidly defined framework of 'fork on our site then generate a pull-request only from that repository', but the cynic in me thinks this makes sense from a community-building standpoint. No point helping the competition, as it were.

from gwork.

It would've taken you less time to actual do it, than to write the above text. But hey, principles need to be followed...

PR at #42

from gwork.

This will be a recurring argument whenever I patch anything, so I guess I have to use github after all.

from gwork.

I was surprised that github had no way of making a pull-request other than within the very rigidly defined framework of 'fork on our site then generate a pull-request only from that repository',

I think this is to simplify things and avoid outside problems. What if the external site disappears or changes? Are all external sites configured the same? How can you monitor for notifications, etc. It is easier and less error prone to just push your changes to the clone on Github.

There is nothing to stop you developing in git repo anywhere and then just pushing the changes you want to contribute to your fork on Github. The thing about git is that there are multiple copies of a project repo and any of them can arbitrarily be the main one. All the others are just relative to the source (by parent lineage). It is a more flexible way of working than old client-server model, e.g. like Subversion.

You might even have multiple forks yourself, perhaps you included Gwork as a sub-repo in a larger project, so you might have multiple clones on the same machine. When you make a change you want to contribute you just push them to the remote. Since I own the original remote you need to show me a fork with your changes in so that a PR can be created and the changes discussed and tested before merging. And you could push from any of your forks to your reference version on Github.

I'll just add that having a workflow simplifies this, e.g. creating feature/bugfix branches, before changing and creating PR. This stops multiple changes being conflated. Not all your changes might make it into the original repo, for various reasons.

from gwork.

Perhaps I should try and answer your original question first.

I could not get DisableResizing to work properly for the current checkout I have of the gwork-branch. Perhaps I was doing something wrong, I am just beginning to use the lib so I'm not entirely familiar with the ins and outs.

TBH I am still learning how much of it works! There is very little documentation or useful commenting in the original code so sometimes you have to make assumptions about how things work. I'll try and add online docs at some point.

My opengl-renderer also doesn't implement scissoring yet so that could possibly be the cause, but from how the issue appears I don't think so.

There is an OpenGL sample and renderer in Gwork. You could try using that renderer with this code to see if you get the same problem, if you haven't yet implemented all the features. Perhaps just paste the code into the sample? Try this first.

from gwork.

I updated the test-executable to make it possible to easily test DisableResizing() with it. In the process I confirmed that the error exists with the built-in OpenGL-renderer. Clipping also seems to be nonfunctional in that one as well.

I have updated the pull request to include the test.

from gwork.

Clipping also seems to be nonfunctional in that one as well.

I just looked at the OpenGL sample and clipping looks fine. E.g. tree control, collapsable list, etc. What problem are you seeing?

from gwork.

So I looked into this and there was a bug with the resizer modification, as you noticed. Should be fixed now.

I also added a test for non-resizable window in the demo.

from gwork.

Wow, you just so happened to write a fix that was more or less the same as the pull-request, instead of using the pull-request. That's vaguely insulting.

from gwork.

I thought the problem was elsewhere and then ended up with a similar solution. I also tidied up some other stuff. Apologies, but there were issues with the PR that needed correcting before submission:

• m_disabled is duplicate. See m_bDisabled. Also access public.
• Extra unnecessary line spaces.
• Redundant code left commented in.
• No test in the demo.

The etiquette is to fix these in the PR before submission. I also looked at GWEN for similar issues and found a similar solution.

from gwork.

Ok, this is fixed now I believe. I'll close this issue.

You mentioned some problem with clipping the OpenGL sample. I can't see evidence of this. If you still find a problem please open a new issue.

I'm happy to accept PRs but not ones which I end up fixing/rewriting. Other PRs have made it in. Overall I'm trying to improve the code quality here (see above points).

from gwork.

No test in the demo.

What on earth are you talking about?
See 915ae99 , committed 15 hours before "you fixed it".

The other points are fair and could easily have been adjusted.

You are missing the main point. On one hand you are claiming that you want to build a community, but on the other hand when a good-faith attempt to collaborate comes along, you would rather replicate the work on your own and do your own commits, than actually collaborate.

It should not surprise you that this does not build

a community of regular contributors

from gwork.

I think this is a rather unfair stand to take, especially after your initial reluctancy to send a PR at all.

It can happen at any point in time that two people work on a solution for the same problem in parallel. It's only fair for any maintainer to prefer their own solution which they can be certain to work and don't need additional adjustments.

Besides, you didn't want to take credit for the initial patches anyways, so why are you getting work up over seeing your PR not being merged?

And finally, can I also get upset that you first refuse to utilize GitHub and once I do the "work" for you, you suddenly decide to use it after all and dismiss one of my PRs? I was not really happy about this either, yet I didn't feel the need to mention it until now...

Contributions are always welcome but one also has to accept that something might not make it in or that a very similar solution from someone else is being used in the end.

from gwork.

Thank you. I was about to say the exact same thing.

from gwork.

can I also get upset that you first refuse to utilize GitHub and once I do the "work" for you, you suddenly decide to use it after all and dismiss one of my PRs?

What are you referring to here? The one that needed to be updated, which I could not with a PR you owned, leaving me with creating another as the only option? Or the other one you created, which I have not replicated so as to not have two identical PRs? Which one did you feel was unfair and rude of me?

Ultimately, I took your point that I should create a PR. If you want to feel upset about that, I can't stop you, but I have certainly not "dismissed" your PR. I updated it the only way I possibly could.

yet I didn't feel the need to mention it until now...

You did reply with a passive-aggressive "..." when I pointed out I had to update, didn't you? Let's not pretend you're the virtuous saint after the fact.

Ultimately, I cannot force @billyquith to do anything at all, and that is not my intent. I'm just pointing out that I came here to improve the lib as best I could, but as a result of how this was handled I won't do that again. If @billyquith is truly interest in creating a community of regular contributors, as he has stated, that's something he should be interested in knowing, for future reference.

from gwork.

@ipo You've already stated the you're not interested in collaborating on Github so I think this is moot. Thanks for raising the bug. All the best.

End of discussion.

from gwork.