Hi Ivan, On Sun, Mar 24, 2019 at 2:34 AM Ivan Vučica <[email protected]> wrote:
> 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 > things.) > 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 <[email protected]> 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 <[email protected]> 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? > >> > >> Cheers, > >> Fred > >> > >> On the road > >> > >> Am 23.03.2019 um 01:42 schrieb Sergii Stoian <[email protected]>: > >> > >> 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 > >> [email protected] > >> https://lists.gnu.org/mailman/listinfo/gnustep-dev > > > > > > > > -- > > Sergii Stoian, > > ProjectCenter lead developer > > NEXTSPACE owner, lead developer > > _______________________________________________ > > Gnustep-dev mailing list > > [email protected] > > https://lists.gnu.org/mailman/listinfo/gnustep-dev > -- Sergii Stoian, ProjectCenter lead developer NEXTSPACE owner, lead developer
_______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
