: Warren Turkal w...@penguintechs.org
Date: Sat Sep 14 23:46:28 2013 -0700
app: Refactor palette loaders.
I specifically moved the file opening/closing logic to the common
code. This makes the code easier to understand for me since there
is less duplication. In fact, this commit
. Projects like Android and Libreoffice use it. As an
example, here's a link
https://gerrit.libreoffice.org/#/q/status:open,n,zto the Libreoffice
instance.
wt
On Sun, Sep 15, 2013 at 2:22 AM, Jehan Pagès jehan.marmott...@gmail.comwrote:
Hi,
On Sun, Sep 15, 2013 at 8:32 PM, Warren Turkal w
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
dra...@darkrefraction.comwrote:
I made a few minor nitpicks on your commit on github. If you would fix
those points, I'll commit your
On Tue, Sep 10, 2013 at 6:54 PM, Jehan Pagès jehan.marmott...@gmail.comwrote:
On Wed, Sep 11, 2013 at 1:10 PM, Michael Henning
dra...@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
Hi again,
Here's a
linkhttps://github.com/wt/gimp/commit/d1e8c4c8543b18c6f5d95f6ab6b3bbbf8f80778bto
a commit containing a refactor of the palette loading code. I have
moved
the file open/close logic to common code. This change actually removes more
code than it adds. Here's a interesting
to generate a proper patch from this? Otherwise, could you generate
one with git format-patch origin/master, run on your locale branch?
Thanks.
Jehan
On Mon, Sep 9, 2013 at 12:20 AM, Warren Turkal w...@penguintechs.org
wrote:
BTW, I tested this with gpl, act, aco, pal, and css palette files. I
On Fri, Sep 6, 2013 at 11:20 AM, Joao S. O. Bueno gwid...@mpc.com.brwrote:
Yes, the paramerter PF_PALETTE is passed around as a string - but that
string is teh palette name in GIMP- teh palette is them usable with
all palette -related PDB functions
I don't want to manipulate a current
On Fri, Sep 6, 2013 at 1:16 PM, Joao S. O. Bueno gwid...@mpc.com.br wrote:
Besides - you have to check what makes more sense - I't think Palette
exporting/importing plug-ins have to be on the Palletes context menu
My basic design is going to be as follows:
- Add a procedure to register
that the
current code isn't importing the palette atomically, I will just do the
same thing. I think I see how to make this work.
This has been helpful.
Thanks,
wt
On Sat, Sep 7, 2013 at 5:15 AM, Joao S. O. Bueno gwid...@mpc.com.br wrote:
On 7 September 2013 04:18, Warren Turkal w...@penguintechs.org wrote
On Fri, Sep 6, 2013 at 10:11 AM, Chris Mohler cr33...@gmail.com wrote:
On Thu, Sep 5, 2013 at 11:30 PM, Warren Turkal w...@penguintechs.org
wrote:
Just so you all know, this actually started with my wife wanting to
import
*.ase palettes in .
Same here, but I just wanted to use Kuler
Hi,
I have found a possible bug
in gimp/app/display/gimpdisplayshell-transform.c:285. The line is as
follows:
*rotated_coords = *rotated_coords
Is it possible that it should be the following?
*rotated_coords = *unrotated_coords
Also, the documentation for the function containing this line and
Hey,
First of all, a little background. I am using the master branch and am
trying to make the palette import parsers plugable. I have been
experimenting a bit as a result.
I have been trying to write a python plugin that returns a palette.
However, when I define a return type as PF_PALETTE, the
Chris,
Thanks for the suggestion. I actually already found it, and it's been
pretty helpful. Unfortunately, it doesn't seem to import some ase's that I
have come across, like the ase ones
13 matches
Mail list logo
