Hi Marc, list members, Yes, I encounter awkwardness with the Save dialog & autocomplete triggering. You will also note that 'autocomplete' triggering blocks Enter from actually saving.. it also blocks Alt-S (or whatever Windows shortcut) from working. I'm not a big fan of autocomplete for "Save" -- if I wanted a similar name to an existing file, I'd expect to select the existing file in the list & change the name in the edit field. Since "autocomplete" here interferes strongly with the expected/standard UI, I'd consider the best usability to remove it entirely. https://bugzilla.gnome.org/show_bug.cgi?id=698481 Failing that, "autocomplete" should be reworked so as not to block the dialog's main keybindings. (Perhaps this would be useful for the 'Open' dialog.) Marc, you'd be welcome to add you comment in Bugzilla & hopefully "vote" usability issues a little higher priority. Other people notice this issue? Thanks, Tom > once in a while, when I want to save a file, and get into the safe dialog, when I start typing, the text appears > right below in a search box instead of in the filename box. I do not know how to reproduce this yet, but it > happens ever so often and it is a bit annoying. On Mon, Sep 16, 2013 at 12:00 AM, <gimp-developer-list-request@xxxxxxxxx>wrote: > Send gimp-developer-list mailing list submissions to > gimp-developer-list@xxxxxxxxx > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > or, via email, send a message with subject or body 'help' to > gimp-developer-list-request@xxxxxxxxx > > You can reach the person managing the list at > gimp-developer-list-owner@xxxxxxxxx > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of gimp-developer-list digest..." > > > Today's Topics: > > 1. Re: refactor palette loading code (Warren Turkal) > 2. Re: refactor palette loading code (Warren Turkal) > 3. Dialog Safe text entered appears in searchbox instead > filenamebox annoying (Marc Kroeks (zonnet.nl)) > 4. Re: refactor palette loading code (Jehan Pag?s) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Sep 2013 01:17:46 -0700 > From: Warren Turkal <wt@xxxxxxxxxxxxxxxx> > To: Michael Henning <drawoc@xxxxxxxxxxxxxxxxxx> > Cc: Graphical Geniuses <gimp-developer-list@xxxxxxxxx> > Subject: Re: refactor palette loading code > Message-ID: > <CAB_jBhh6FLb-bqbJSH5H= > h_rgFEQ0GyXq8tbeYQ2iLeFzTdW6A@xxxxxxxxxxxxxx> > Content-Type: text/plain; charset=ISO-8859-1 > > Sorry for taking so long to respond. I don't have a lot of time during > normal work days to work on this. :) > > On Tue, Sep 10, 2013 at 6:10 PM, Michael Henning > <drawoc@xxxxxxxxxxxxxxxxxx>wrote: > > > I made a few minor nitpicks on your commit on github. If you would fix > > those points, I'll commit your code to master. > > > > Thanks. I think I addressed all your comments. However, I just added a > rewind at the end of gimp_palette_load_detect format instead of doing what > your comment suggested. PTAL and see if you approve. Here's the > link<https://github.com/wt/gimp/tree/refactor_palette_loader_try2>. > I have also attached a patch to this mail. > > As a side note for the future, the fastest way to get a patch reviewed > > is normally if you post it to a pastebin and bother people on irc. > > > > I am not in a huge hurry, and I haven't had much luck catching folks on IRC > when I am on. Is there really any benefit of using pastebin over pushing my > branch out so that it can be looked at and fetched? The pastebin method > seems like it'd be pretty inconvenient for bigger patches, and it doesn't > have any kind of commenting on the patch. Also, which pastebin do you > prefer? > > I will say that I was surprised there wasn't more interest in using git to > pass around these patches. I would have expected you folks to acquire the > patch from my repository (e.g. fetch my branch from my repo and look at the > branch directly). I was somewhat surprised by the request for a patch file. > > With regard to git, I don't see any merges in the history for the project. > Does this project not do git merges? > > -- drawoc > > > > P.S. I don't see the patch on that last email. Are you sure you attached > > it? > > > > It appears to be attached on my end. Does the ML block attachments? > > FWIW, I also attached the new diff to this email. It indeed does appear to > be attached at this point. > > wt > > > ------------------------------ > > Message: 2 > Date: Sun, 15 Sep 2013 01:32:27 -0700 > From: Warren Turkal <wt@xxxxxxxxxxxxxxxx> > To: Jehan Pag?s <jehan.marmottard@xxxxxxxxx> > Cc: Graphical Geniuses <gimp-developer-list@xxxxxxxxx> > Subject: Re: refactor palette loading code > Message-ID: > < > CAB_jBhhSX4bFw4k-8u8PRP4-S7XcN4XJsqBhY80YfS8UvuhR2w@xxxxxxxxxxxxxx> > Content-Type: text/plain; charset=ISO-8859-1 > > On Tue, Sep 10, 2013 at 6:54 PM, Jehan Pag?s <jehan.marmottard@xxxxxxxxx > >wrote: > > > On Wed, Sep 11, 2013 at 1:10 PM, Michael Henning > > <drawoc@xxxxxxxxxxxxxxxxxx> wrote: > > > As a side note for the future, the fastest way to get a patch reviewed > > > is normally if you post it to a pastebin and bother people on irc. > > > > For my own, I would prefer a git format-patch like this, but on a > > feature request/bug report on bugzilla. That's easy to patch a branch > > and to remove after. And also we keep track of any discussion or > > updated patch about a feature/fix. For instance go find this email > > thread in one year in the mailing history. > > > > Even for small refactorings like this one? I would certainly understand > that for a feature add or a major refactor, but it seems like a lot of > overhead for a pretty small refactor like this one. However, I am willing > to do whatever you folks want since I just wanna help the project. However, > please keep in mind that I have very little time to commit to this kind of > work. > > > P.S. I don't see the patch on that last email. Are you sure you attached > > it? > > > > I see it but I was also a direct recipient. I guess that the list > > cleans emails out from any attached file. > > Could we have conditional filters? Like any text file with a ".patch" > > or ".diff" extension should not be filtered out. > > > > You should also allow git bundle files, which are a way to pass around git > commits. I have attached one to this mail that includes the second > iteration of my change. I guess only direct receivers of the email will > receive it. > > wt > > > ------------------------------ > > Message: 3 > Date: Sun, 15 Sep 2013 10:20:26 +0200 > From: "Marc Kroeks \(zonnet.nl\)" <mkroeks@xxxxxxxxx> > To: <gimp-developer-list@xxxxxxxxx> > Subject: Dialog Safe text entered appears in > searchbox instead filenamebox annoying > Message-ID: <33D9B1E32EE54F17BBCBD88520908D3E@contextual> > Content-Type: text/plain; charset="iso-8859-1" > > Hello, > > once in a while, when I want to save a file, and get into the safe dialog, > when I start typing, the text appears right below in a search box instead > of in the filename box. > I do not know how to reproduce this yet, but it happens ever so often and > it is a bit annoying. > > Yours, > Marc. > > ------------------------------ > > Message: 4 > Date: Sun, 15 Sep 2013 21:22:14 +1200 > From: Jehan Pag?s <jehan.marmottard@xxxxxxxxx> > To: Warren Turkal <wt@xxxxxxxxxxxxxxxx> > Cc: Graphical Geniuses <gimp-developer-list@xxxxxxxxx> > Subject: Re: refactor palette loading code > Message-ID: > < > CAFgjPJ8xEyzArftv5zijkVKaUes2kCqJ_dbrw8MXNDMriORAWg@xxxxxxxxxxxxxx> > Content-Type: text/plain; charset=UTF-8 > > Hi, > > On Sun, Sep 15, 2013 at 8:32 PM, Warren Turkal <wt@xxxxxxxxxxxxxxxx> > wrote: > > On Tue, Sep 10, 2013 at 6:54 PM, Jehan Pag?s <jehan.marmottard@xxxxxxxxx > > > > wrote: > >> > >> On Wed, Sep 11, 2013 at 1:10 PM, Michael Henning > >> <drawoc@xxxxxxxxxxxxxxxxxx> wrote: > >> > As a side note for the future, the fastest way to get a patch reviewed > >> > is normally if you post it to a pastebin and bother people on irc. > >> > >> For my own, I would prefer a git format-patch like this, but on a > >> feature request/bug report on bugzilla. That's easy to patch a branch > >> and to remove after. And also we keep track of any discussion or > >> updated patch about a feature/fix. For instance go find this email > >> thread in one year in the mailing history. > > > > > > Even for small refactorings like this one? I would certainly understand > that > > for a feature add or a major refactor, but it seems like a lot of > overhead > > for a pretty small refactor like this one. However, I am willing to do > > whatever you folks want since I just wanna help the project. However, > please > > keep in mind that I have very little time to commit to this kind of work. > > Well there are no strict rules, I guess, likely because the team is > small. I guess the real "rule" is to do so that others are not annoyed > by the form your patch (so that they will actually check it, and not > delay it to forever). Which means that if the other developers are ok > with a git bundle for instance (I did not even know what it is, I had > to look it up), or by adding your repo as a remote, well that's all > good. :-) > > I am myself flexible and adapt to various team logics. But by > experience, I know some others of the core GIMP team want git > format-patch. When I made my first patches (I am myself likely the > most recent of the core developers), I also set up a public git repo > for others to fetch. Well I was told my patches would more likely be > reviewed if I provided patch files instead. And now I got used to it, > so I work also easily with these. That's not more time-consuming. > With a patch formatted with `git format-patch`, you can just "git > apply" it, and done! So easy to review (and also to commit if the > patch looks good with with git am, nothing to do). > > I believe that at the opposite, for small patches, it is much easier > to provide patch files than maintain a public repo. For huge features > which require many commits over weeks, yeah there probably a public > branch is worth it. :-) > > Jehan > > >> > P.S. I don't see the patch on that last email. Are you sure you > attached > >> > it? > >> > >> I see it but I was also a direct recipient. I guess that the list > >> cleans emails out from any attached file. > >> Could we have conditional filters? Like any text file with a ".patch" > >> or ".diff" extension should not be filtered out. > > > > > > You should also allow git bundle files, which are a way to pass around > git > > commits. I have attached one to this mail that includes the second > iteration > > of my change. I guess only direct receivers of the email will receive it. > > > > wt > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > gimp-developer-list mailing list > gimp-developer-list@xxxxxxxxx > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > > > ------------------------------ > > End of gimp-developer-list Digest, Vol 24, Issue 20 > *************************************************** > _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
