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 <wt penguintechs org>
To: Michael Henning <drawoc darkrefraction com>
Cc: Graphical Geniuses <gimp-developer-list gnome org>
Subject: Re: [Gimp-developer] refactor palette loading code
Message-ID:
<CAB_jBhh6FLb-bqbJSH5H=
h_rgFEQ0GyXq8tbeYQ2iLeFzTdW6A mail gmail com>
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 darkrefraction com>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 penguintechs org>
To: Jehan Pag?s <jehan marmottard gmail com>
Cc: Graphical Geniuses <gimp-developer-list gnome org>
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 <jehan marmottard gmail com
wrote:
On Wed, Sep 11, 2013 at 1:10 PM, Michael Henning
<drawoc darkrefraction com> 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 zonnet nl>
To: <gimp-developer-list gnome org>
Subject: [Gimp-developer] 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 gmail com>
To: Warren Turkal <wt penguintechs org>
Cc: Graphical Geniuses <gimp-developer-list gnome org>
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 <wt penguintechs org>
wrote:
On Tue, Sep 10, 2013 at 6:54 PM, Jehan Pag?s <jehan marmottard gmail com
wrote:
On Wed, Sep 11, 2013 at 1:10 PM, Michael Henning
<drawoc darkrefraction com> 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
***************************************************
