From experience outside GNUstep: I don't think it's necessarily a bad
practice to do code review on every commit going in (including
trivial), even among core devs. It's perhaps a shame we're not
enforcing code review for /every/ submission.
Anyway, I think each of the improvements sounds good -- I think it's
very good to upstream your changes, so thank you for doing this. They
do sound like something where it might be a good idea for a second eye
to take a quick look? (I know I wouldn't mind having someone take a
look at my changes, when I make them, as even trivial ones could break
I understand your concerns absolutely. Everybody make a mistakes. :)
Although there are some corner cases were I'll take a courage to commit directly.
For example, Ukrainian translation file. Is it OK?
How about we try with PRs for these (incl for trivial changes) and
then look at flipping the permissions switch for you?
It's good if it's make GNUstep code quality better.
I'm a GNUstep developer since 2001, if I recall correctly (including paper signing from FSF).
Moreover, I'm a perfectionist for quality in code and feel of a UI/UX.
I don't know if somebody else here is everyday user of GNUstep codebase as me (I use NEXTSPACE as production environment for a several months).
If something goes wrong I'll see it immediately. :)
Anyway, I'll agree with you and will start creating PRs.
Do I need to create branch or fork? What would your recommend?
Once again, thank you for offering these patches!
On Sat, Mar 23, 2019 at 9:52 PM Sergii Stoian <address@hidden> wrote:
> Hi Fred,
> Thank you. As I've replied to David, I tend to push trivial patches directly to HEAD. More complex I'll create as a pull request so we can discuss details before merge.
> Answering your last question: I have a set of tested changes to older GNUstep release (you may find them here https://github.com/trunkmaster/nextspace/tree/master/Libraries/gnustep).
> I want to include these changes into current release of GNUstep. The main areas are:
> - focus management and window manager interaction (hide application, minimize window), mouse click on titlebar, appicon, inside window;
> - mouse properties: configurable double-click time, line scroll multiplier, left/right menu button (some details: https://github.com/trunkmaster/nextspace/issues/8);
> - applications "-autolaunch" behaviour: do not show menus and do not steal focus;
> - mouse cursors: I've created a cursor theme which is fully compatible to Awaita (standard `de facto` I guess). You may find my thoughs here: https://github.com/trunkmaster/nextspace/wiki/Mouse-Cursors;
> Also I have several trivial patches:
> - prevent blinking of appicon on focus switch/appicon double-click. It's quite noticable with cairo backend;
> - Font panel weird look and feel on WM (no resize bar, items must be clicked higher then it drawn)
> - use title image in miniwindow
> - etc.
> In long-term I want to adopt cairo backend as default for NEXTSPACE. I want to move some functionality from ART backend.
> For example, I'd like to have an option and support of font packages (.nfont).
> I want to polish UI: some elements draw lines as gray instead of black (I know about half-pixel problem).
> I'd like to test and enhance NSBrowser behavior. I want to implement display resolution changes adoption at backend level. May high DPI some day...
> On Sat, Mar 23, 2019 at 12:05 PM Fred Kiefer <address@hidden> wrote:
>> Hi Sergii,
>> having a pull request to review and approve is always the nicer way to work with patches. But if this is too much hassle for you feel free to do a direct commit or even to send a patch file to the mailing list. Which area are you planing to work on?
>> On the road
>> Am 23.03.2019 um 01:42 schrieb Sergii Stoian <address@hidden>:
>> Hello everybody,
>> I plan to commit some changes/fixes to GUI and Back.
>> My last GNUstep commit was long time ago to SVN at gna.org. I'm familiar with git and github.
>> My question is: what is the correct way to submit patches/fixes?
>> Should it be a pull request for approval?
>> May I commit directly to the source tree on github?
>> Sergii Stoian,
>> ProjectCenter lead developer
>> NEXTSPACE owner, lead developer
>> Gnustep-dev mailing list
> Sergii Stoian,
> ProjectCenter lead developer
> NEXTSPACE owner, lead developer
> Gnustep-dev mailing list