* Thomas W [09-15-13 18:51]:

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, wrote:

Send gimp-developer-list mailing list submissions to gimp-developer-list@gnome.org

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@gnome.org

You can reach the person managing the list at gimp-developer-list-owner@gnome.org

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
To: Michael Henning
Cc: Graphical Geniuses
Subject: Re: [Gimp-developer] refactor palette loading code Message-ID:

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 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.
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
To: Jehan Pag?s
Cc: Graphical Geniuses
Subject: Re: [Gimp-developer] refactor palette loading code Message-ID:
<
CAB_jBhhSX4bFw4k-8u8PRP4-S7XcN4XJsqBhY80YfS8UvuhR2w@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1

On Tue, Sep 10, 2013 at 6:54 PM, Jehan Pag?s

wrote:

On Wed, Sep 11, 2013 at 1:10 PM, Michael Henning 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\)"
To:
Subject: [Gimp-developer] Dialog Safe text entered appears in searchbox instead filenamebox annoying Message-ID:
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
To: Warren Turkal
Cc: Graphical Geniuses
Subject: Re: [Gimp-developer] refactor palette loading code Message-ID:
<
CAFgjPJ8xEyzArftv5zijkVKaUes2kCqJ_dbrw8MXNDMriORAWg@mail.gmail.com> Content-Type: text/plain; charset=UTF-8

Hi,

On Sun, Sep 15, 2013 at 8:32 PM, Warren Turkal wrote:

On Tue, Sep 10, 2013 at 6:54 PM, Jehan Pag?s

wrote:

On Wed, Sep 11, 2013 at 1:10 PM, Michael Henning 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@gnome.org
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@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

I don't appear to have the problem on linux. Perhaps it is a problem related to windows.

(paka)Patrick Shanahan       Plainfield, Indiana, USA          @ptilopteri
http://en.opensuse.org    openSUSE Community Member    facebook/ptilopteri
http://wahoo.no-ip.org        Photo Album: http://wahoo.no-ip.org/gallery2
Registered Linux User #207535                    @ http://linuxcounter.net

Hi,

On Mon, Sep 16, 2013 at 11:07 AM, Paka wrote:

* Thomas W [09-15-13 18:51]:

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.

For the usability problem about "should we autocomplete the save dialog?", I find your saying interesting. Indeed in a "non-destructive" point of view, I don't think autocomplete is such a great idea for the save dialog, because in most cases, you don't want to overwrite an existing file, but create a new name (and in the cases you do want to overwrite, it is better to have the user write it down or select it by mouse, so that we prevent too fast "enter-enter-damn it was the wrong name!" consequences). Does it make sense to others?

Unfortunately I think we may not have a say in it. I had a fast look at GTK file chooser dialog API and did not see a function to disable autocompletion. I may have to check further in GTK code. I don't think we can add new features in gtk2, but maybe this can be added to gtk3 (then use when we get out GIMP 3, but it means it won't be available for a bit of course). Anyway if possible, I'd say there should be intermediate autocompletion types. Like "autocomplete folders, but not file names" (so we still help users to choose a folder, but don't direct them to existing file name for saving). I'd say this is an interesting feature request. Does anyone agree?

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?

I don't appear to have the problem on linux. Perhaps it is a problem related to windows.

I don't think I have this problem either on Linux. I may test on my Windows VM some day later.

Jehan

On Sun, Sep 15, 2013 at 10:38 PM, Jehan Pags wrote:

I don't appear to have the problem on linux. Perhaps it is a problem related to windows.

I don't think I have this problem either on Linux. I may test on my Windows VM some day later.

Here's how to reproduce it on Linux:

Go to File->Open (or File->Export, etc.) Navigate to any directory using the folders on the left. Double click to select any folder that looks like a good place to open/save. Type something.
Note the filename, while highlighted, never changes Note a mysterious box in the lower right collecting your keystrokes

Version: GIMP 2.8.4 as shipped by Ubuntu.

Regards, Chris

Hi,

On Mon, Sep 16, 2013 at 2:57 PM, Christopher Curtis wrote:

On Sun, Sep 15, 2013 at 10:38 PM, Jehan Pagès wrote:

I don't appear to have the problem on linux. Perhaps it is a problem related to windows.

I don't think I have this problem either on Linux. I may test on my Windows VM some day later.

Here's how to reproduce it on Linux:

Go to File->Open (or File->Export, etc.) Navigate to any directory using the folders on the left. Double click to select any folder that looks like a good place to open/save. Type something.
Note the filename, while highlighted, never changes Note a mysterious box in the lower right collecting your keystrokes

Version: GIMP 2.8.4 as shipped by Ubuntu.

well I have the "mysterious box collecting [my] keystroke" (also using GIMP 2.8.4 as shipped by Mint, hence Ubuntu). It just looks to me like a feature for being able to select a file without having the text field active. And it does not block Enter for saving (which was the original bug reported in the email as I understand it). So I don't see any bug there.

But I still agree that this is probably not the best behavior for the "save" dialog, and maybe even the "export" one. But for "open", it looks acceptable (though certainly there is a better way, of course. Just saying I see no obvious usability problem or bug here, as reported in the email).

Jehan

Regards,
Chris

On Sun, Sep 15, 2013 at 11:21 PM, Jehan Pags wrote:

well I have the "mysterious box collecting [my] keystroke" (also using GIMP 2.8.4 as shipped by Mint, hence Ubuntu). It just looks to me like a feature for being able to select a file without having the text field active. And it does not block Enter for saving (which was the original bug reported in the email as I understand it). So I don't see any bug there.

Well, I haven't been following the thread closely but I don't know what you expect it to mean that something would "block Enter".

When in this mode, if you type and hit enter, the box goes away and nothing appears to happen. It isn't clear that the box is even there because it's not in the visual field. It appears that nothing happens, including enter. After hitting enter and trying to type again, the box reappears. Unless you pay close attention what is happening this is both very non-obvious and frustrating.

I don't understand the bug's comment because I've never tried to use Alt-S or Alt-E in that dialog. I suspect the bug report is simply poorly phrased out of frustration, which I can completely relate to.

How is this popup search even useful when there's already search built in to the file name input? I would agree the popup should be removed/disabled. Arrow up/down work in it but Page up/down doesn't. Arrow up/down, left/right, and Page up/down all work (mostly) reasonably when used from the file name input. Worst of all, if you select a file from the multiple choice file name input and then arrow up/down, you're in the file chooser portion and typing uses the popup search instead of the file name search you just came from.

Personally, I hit this frequently and think this behavior is an extraordinarily frustrating usability disaster.

Chris

Hi,

On Mon, Sep 16, 2013 at 3:53 PM, Christopher Curtis wrote:

On Sun, Sep 15, 2013 at 11:21 PM, Jehan Pagès wrote:

well I have the "mysterious box collecting [my] keystroke" (also using GIMP 2.8.4 as shipped by Mint, hence Ubuntu). It just looks to me like a feature for being able to select a file without having the text field active. And it does not block Enter for saving (which was the original bug reported in the email as I understand it). So I don't see any bug there.

Well, I haven't been following the thread closely but I don't know what you expect it to mean that something would "block Enter".

Well... that's part of the message I am answering to, and consequently, the one you answer to as well. It says it blocks enter, and I say it does not at least on my machine.

When in this mode, if you type and hit enter, the box goes away and nothing appears to happen. It isn't clear that the box is even there because it's not in the visual field. It appears that nothing happens, including enter. After hitting enter and trying to type again, the box reappears. Unless you pay close attention what is happening this is both very non-obvious and frustrating.

I don't understand the bug's comment because I've never tried to use Alt-S or Alt-E in that dialog. I suspect the bug report is simply poorly phrased out of frustration, which I can completely relate to.

Yes for these other shortcuts, I am not even sure that these are supposed to work from the start. Maybe these are common shortcut in save dialogs in Windows program? I can't say.

How is this popup search even useful when there's already search built in to the file name input? I would agree the popup should be removed/disabled. Arrow up/down work in it but Page up/down doesn't. Arrow up/down, left/right, and Page up/down all work (mostly) reasonably when used from the file name input. Worst of all, if you select a file from the multiple choice file name input and then arrow up/down, you're in the file chooser portion and typing uses the popup search instead of the file name search you just came from.

Personally, I hit this frequently and think this behavior is an extraordinarily frustrating usability disaster.

Yes probably the file selection dialog can be improved. Do you know if this also happens in GTK+3 programs? If so, a feature request with relevant counter propositions of how to improve this for GTK+3 may be worth it (if not already existing, that's possible and should be searched first).

Because this is not a GIMP thing and there is not so much we can do about it (of course we could make a custom widget, but well, the whole point of separating GTK+ from GIMP was to share common widgets).

Jehan

Chris