Re: [Gimp-developer] Bug: Gimp 2.10.18 strips off many Exif-data from jpg-files when processing

[Akkana Peck]

> On Thu, 2022-06-02 at 11:45 +0200, Adalbert Hanßen wrote:
> > *Suggested further improvement:* Add a new category “Gimp Processing”
> > telling about the image processing procedures applied, e.g. lighting 
> > adjustments and their parameters, color adjustment, cropping, and the
> > like in readable form.

Liam R E Quin writes:
> It's an interesting idea - how would this information be used?

Once we get to non-destructive editing using GEGL ops, I could
imagine an EXIF field listing a set of ops used for processing.
Imagine being able to save as JPEG yet still be able to load
back into GIMP and undo the last few ops. Yes, there would be some loss
of quality because of lossy compression, and it's certainly not a
substitute for saving as XCF, but I can imagine cases where it
might be useful anyway.

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Changes in GIMP 2.10 - Filters etc.

[Akkana Peck]

Gimp-Werkstatt writes:
> Whithin our tutorials, we do use the drop-shadow-filter quite a lot,
> especially within the scrap-workshops. There is still the old one there,
> but my guess is, that it will vanish sooner or later. The settings in
> the new drop-shadow are quite different but that's OK for us. I only
> wish, it would leave the shadow on an extra layer, like the old filter
> did, so that you can still work on the shadow with the transform-tools
> and change the opacity etc. Would that be a big change to the new
> drop-schaddow-filter? I have no idea of programming, but it would be
> really great to have this extra layer back.

+1. I use the new gegl ops for most things, and most of them are
big improvements over the old filters; but for drop shadows (which I
use a lot), I use the legacy version because I always want the
shadow on a separate layer.

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] GIMP build: XDG_DATA_DIRS causing "Unrecognized image file format"

[Akkana Peck]

Elle, we traded notes about a week ago about environment variables
needed for GIMP's build, and you gave this example that worked for
you on Debian Sid:

Elle Stone writes:
> PREFIX=$HOME/code-install/gimp210/install
> export SRC_DIR=/home/elle/code-build/gimp210/build
> export PATH=$PREFIX/bin:$PATH
> export ACLOCAL_FLAGS="-I $PREFIX/share/aclocal"
> export LD_LIBRARY_PATH=$PREFIX/lib:$LD_LIBRARY_PATH
> export LD_LIBRARY_PATH=$PREFIX/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH
> export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH
> export PKG_CONFIG_PATH=$PREFIX/lib/x86_64-linux-gnu:$PKG_CONFIG_PATH
> export PKG_CONFIG_PATH=$PREFIX/lib/x86_64-linux-gnu/pkgconfig:$PKG_CONFIG_PATH
> export PKG_CONFIG_PATH=$PREFIX/share/pkgconfig:$PKG_CONFIG_PATH
> export 
> XDG_DATA_DIRS="$XDG_DATA_DIRS:$PREFIX/share:/usr/local/share/:/usr/share/"

plus a similar stanza for Gentoo.

I've been struggling with my build lately because of gdk-pixbuf
problems: I kept running into problems like:

gtk-encode-symbolic-svg -o 64 scalable/dialog-warning-symbolic.svg 64x64

Can't load file: Unrecognized image file format

I finally came across a note you posted at the beginning of this year:
http://gimp.1065349.n5.nabble.com/Unable-to-build-GIMP-2-99-on-Debian-Sid-td55023.html
where you tracked this down to setting XDG_DATA_DIRS, covered in
the Hacking:Problems_and_solutions page (a wonderful page I hadn't known
about which wasn't showing up in any of my searches):
https://www.wiki.gimp.org/wiki/Hacking:Problems_and_solutions#GIMP_build_fails_with_message_.27Couldn.27t_recognize_the_image_file_format_for_file_..2Fcursor-bad.png.27

and the solution was not to set XDG_DATA_DIRS for the build.
I tried unsetting XDG_DATA_DIRS and indeed, the problem went away.

Does setting
XDG_DATA_DIRS="$XDG_DATA_DIRS:$PREFIX/share:/usr/local/share/:/usr/share/"
actually work for you, and you don't see the "Unrecognized image
file format" problem any more?

I've been updating the various wiki Hacking: pages with some issues
I've hit recently, and I changed the example for the variables I
used to omit XDG_DATA_DIRS and added a warning that it can cause
problems, but I left it in to the two examples you provided in case
they're actually needed on your system. I'm curious why this seems
to vary so much. Maybe in your case, XDG_DATA_DIRS is already set,
and since you set it to add the system version before the $PREFIX
directories, it uses that? In my case, it wasn't set before I run
the GIMP build; I had
XDG_DATA_DIRS=$GIMP_PREFIX/share:$XDG_DATA_DIRS
so it was set to "$GIMP_PREFIX/share:", and that broke the build.

I've added links to Hacking:Problems_and_solutions from the
Hacking:Building pages hoping to make it easier to find, because
there are a lot of great solutions there.

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] help compiling babl

[Akkana Peck]

Elle Stone writes:
> Thanks! for updating the wiki. In case it helps, the paths for setting up
> the prefix vary from one distribution to the next, for example are very
> different for Debian Sid compared to Gentoo.

Thanks, Elle, If the paths are distro-dependent, they're almost
certainly wrong for Win and Mac too, so I'll add a note that the paths
are just examples and need to be adjusted for each system.

On my Debian system (Testing), I didn't need the to add the
$PREFIX/lib/x86_64-linux-gnu library directories; everything was
installed in $GIMP_PREFIX/lib. But if you needed them, I'm sure 
other people will as well. I think what I'll do is change the main
build page to say the variables there are just an example, then add
a section to the Linux build page with the two variable lists you
gave for Sid and Gentoo as well as my Testing list. It's a bummer
that these vary so much and there's no easy way to predict them.

Also, I found that gegl's new meson build doesn't source the
$PREFIX/share/config.site automatically the way the old build did:
gegl complained about not being able to find babl until I sourced
$PREFIX/share/config.site in the shell before running the meson
build. So I should probably just remove the suggestion of using
config.site entirely, and tell people to export the variables in
the shell before starting the build.

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] help compiling babl

[Akkana Peck]

Marco Ciampa via gimp-developer-list writes:
> On Tue, Aug 13, 2019 at 02:26:50AM +0200, Marco Ciampa via 
> gimp-developer-list wrote:
> > On Mon, Aug 12, 2019 at 08:38:45PM +0300, Alexandre Prokoudine via 
> > gimp-developer-list wrote:
> > > Hello,
> > > 
> > > You should be using the Meson build system now.
> > 
> > Doh, I missed that!
> > It works now, thank you!
> 
> I talked too quickly... now it is GIMP that does not compile (due to babl...):

I had a lot of trouble adjusting my build scripts for babl's meson
build. So once I got it working, I ended up rewriting the GIMP wiki
build instructions to reflect what worked for me.

https://wiki.gimp.org/wiki/Hacking:Building

There are also some additions in the Hacking:Building/Linux page
(linked at the bottom) but it's mostly a discussion of why PREFIX
is important (I didn't write it, someone else did, but it seemed
worth keeping) and a discussion of how to run the GIMP you just built.

Try it out -- and if it turns out that it's still incomplete, let
me know what needs to be changed (or update it yourself, if you
prefer).

I know nothing of the Windows and Mac building pages: I don't
build on those platforms, but it would be great if someone who
does could keep them up to date.

I should mention that my build page rewrites are from shortly after
babl switched to meson, but don't reflect any meson instructions for
gegl or gimp, so eventually Hacking:Building will need to be updated again.

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] #gimp irc invitation only?

[Akkana Peck]

Elle Stone writes:
> It does seem that irc.gimp.org and freenode.org require separate
> registration. Or else there is some sort of time lag wrt something done with
> freenode reaching irc.gimp.org. In any event, now I'm registered and
> identified.
> 
> But there is still a message about "invite-only".

For what it's worth, I'm getting the same "invite-only" message Elle
is. If I /msg nickserv status from #gimp-users (which doesn't seem
to have the same restriction), it says I'm status 3, which
supposedly means I'm logged in.

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Compiling GIMP-2.9 with the new mypaint requirements

[Akkana Peck]

> > On 01/02/2018 07:38 AM, Elle Stone wrote:
> > > When configuring GIMP-2.9, it doesn't find the mypaint brushes.

Tobias Ellinghaus writes:
> You probably have to add
> 
> /home/elle/code-install/gimpdefault/install/share/pkgconfig/

I hit a bunch of snags trying to follow this, getting the right
branch and not knowing that libmypaint's autogen doesn't run
configure automatically.. Here's what worked for me on Debian:

export PKG_CONFIG_PATH=$PREFIX/share/pkgconfig/

git clone https://github.com/Jehan/mypaint-brushes.git
cd mypaint-brushes
git checkout --track -b v1.3.x origin/v1.3.x
./autogen.sh --prefix=$PREFIX
(probably didn't need the --prefix for that)
./configure --prefix=$PREFIX
make
make install

then proceed with the usual GIMP build.

Except that I also discovered that GIMP's configure is giving a
warning now about Debian's default gcc, 7.2.0. I had gcc-6 installed
already, but configure doesn't find it automatically. Here's the
solution to that:

export CC=/usr/bin/gcc-6

and make clean in gegl and babl if they've previously been built
with the default compiler.

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Get rid of the floating selection where possible?

[Akkana Peck]

Cordylus Interneter writes:
> You are probably talking about "Auto-anchoring of floating selection". I've 
> seen it and thought it is about something else - I supposed that creating a 
> new layer is not anchoring.
> 
> That's a bit strange to me that nobody prioritized it higher since this is 
> the thing that you have to deal with daily, with every paste, but it's good 
> to see it on the list anyway. Thank you for the answer.

For what it's worth, I agree with Cordylus. Floating selections are
confusing because they look like a layer but don't behave like one.
It would be much more understandable if paste just created a new
layer, without any of the special behavior that floating selections
have. Then people who want to merge that layer into the current
layer can use Merge Down where today they'd use Anchor; no more
steps than today.

I've heard people suggest that the reason it isn't designed like
that is for the case where you want to anchor the floating
selection onto a channel rather than a layer. But surely that's
far less common than pasting as a new layer? One could design
a UI that worked for that case ("Paste into channel"?) without
interfering with a much more common operation.

Fortunately, for now, you can bind Ctrl-V to "Paste as->New Layer".
So it's mostly an issue for people who teach classes, write howtos
or answer user questions and have to try to explain what floating
layers are and how to deal with them.

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Cubic Interpolation vs No Halo

[Akkana Peck]

> > On 07/05/16 15:38, Øyvind Kolås wrote:
> >> I've pushed code to GEGL master that makes the resamplers called
> >> "linear" and "cubic" do a tiny bit more than just interpolation.

> On Mon, May 9, 2016 at 12:11 PM, Karl Günter Wünsch wrote:
> > The more you change the default behavior of existing filters the more it
> > makes the use of GIMP impossible in a setup where you build up a
> > workflow... It's bad enough to outright drop the previously available
> > scaling algorithm but to tinker and thus in some cases invalidate
> > existing workflows without the user being made aware of it is ridiculous
> > for a tool like the GIMP...

Øyvind Kolås writes:
> This was a fix for the 2.9 series - any releases of 2.9 thus far have
> been development snapshots and you shouldn't be establishing
> unchangable workflows based on the behavior of development snapshots.

As someone who down-scales a lot (and who expects workflow and
defaults to change now and then when using development releases), I
want to thank Øyvind for the new code. Downscaling with Cubic looks
much better now (compared to the previous 2.9 behavior), and is much
faster than LoHalo/NoHalo. Good stuff!

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] [Gimp-web] Gitlab as a replacement for registry.gimp.org

[Akkana Peck]

Jehan Pagès writes:
[on one repo per asset vs. one repo containing many assets]
> Really I don't understand this point which Akkana is raising. Has
> anyone ever made plugins for various software? I have, for a bunch,
> many dead now, some still living. And never have I ever thought "oh
> let's put all my completely unrelated plugins into the same
> repository"! This is like the base of code organization, you just have
> separate items. I have a bunch of repositories of my own, and have a
> few dozens of repositories from various projects which I have needed
> at some point.

In the current GIMP source tree, circuit.scm,clothify.scm,
coffee.scm, line-nova.scm, old-photo.scm, spinning-globe.scm and
spyrogimp.scm (I just picked a random set) are all completely
unrelated scripts. Yet there they all are, 53 different .scm files
in the GIMP source repository in the plug-ins/script-fu/scripts/
directory, and similar unrelated collections in
plug-ins/pygimp/plug-ins/ and plug-ins/ itself.

You are arguing that it's easier/better to maintain unrelated assets
each in its own repository. But evidently the GIMP development team
agrees with me: they have and a bunch of unrelated script files
together within one directory within one big repository. That's how
I organize my GIMP plug-ins too, and it's the model used in every
other software project I've been involved with.

Maybe I'm just being old fashioned because "many files in one big
repo" is the only model I've seen in action. From what you say, I
guess I should look at Wordpress to see a project that uses "one
repo per file" successfully?

I'm still not clear what the advantage would be of one repo per
file. The disadvantages I see: many small repos are slower to check
out, are more work to maintain, have a (slightly) bigger disk
footprint, and you have to write a script to make sure you've pulled
everything you need. Plus possibly Pat's concern about gitlab not
allowing that many repos, but we don't know the answer to that yet.

But if this is just for the backend, and individual asset developers
will have some way of submitting a single file and don't ever have
to check out all those little repos, then I guess all that really
matters is what makes the most sense to the registry development
team. (And I hope I can be part of that team and help in some way,
regardless of what decision you make about the number of repos.)

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Gitlab as a replacement for registry.gimp.org

[Akkana Peck]

Just agreeing with a few of Ofnuts' points:

Ofnuts writes:
> Author:
> - communications with users: forum, etc. Mail notification necessary

+1. With the current setup, I remember going to a page I'd made for
one of my plug-ins and discovering there was a question there from
four years earlier that I'd had no idea about.

> - ability to share/transmit ownership

Good one!

> - I don't think this system should be a place to maintain/share the source
> code. We could however enforce a FOSS/CC discipline and require the source
> files to be provided (for some assets, this could mean the original XCF/SVG
> file...)

I like the experiments Pat has been doing with making links inside a
repo that link to other repos. If the GIMP plugin repository can
include files from a developer's site on github or wherever,
that solves the problem of developers who are actively improving
a plugin but forget that they also need to update the version on
GIMP's repository.

> User:
> - straightforward, no-questions-asked downloads
> - easy registration for forums
> - semi-anonymous use of forums (guest mode without registration, but with
> some more hurdles such as captchas)
> - search capabilities

- browse capabilities, by category or keyword: browsing all the
  plugins in the color category isn't the same as searching for
  everything that has the word "color" anywhere in the description,
  a major problem with the previous plug-in repository. And maybe
  also by date: browse the recently added plugins.

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] [Gimp-web] Gitlab as a replacement for registry.gimp.org

[Akkana Peck]

Andrew Toskin writes:
> > On 2016-04-01 13:32, Pat David wrote: 
> > Jehan suggested that each script/plugin/asset have it's own git repo.
> > This would be handy, particularly if script authors did this as well (as it
> > considerably eases the inclusion of external repos as submodules).
> > However, akk points out that many folks don't (won't?) organize their repos
> > in this way (it gets a little... unwieldy pretty quickly if you have many
> > scripts).
> 
> Whether or not we can get plugin developers to follow it, separating
> scripts and plugins into different repositories seems like a good
> recommendation, for a number of reasons. For plugin and script authors,
> it would make managing bugs and user feedback easier.

It would make managing repositories much harder, though.

I currently have roughly 20 GIMP scripts and plug-ins in my
gimp-plugins repository, and would want to share maybe 15 of them
(some are silly and not worth sharing). Please don't force me to
create 20 different repositories, most containing only a single
python script. It clutters my github (or, I assume, gitlab) profile,
assuming they'd even let me create that many repos; it makes it hard
to keep multiple machines current since I have to cd into each of
those repos and make sure they're in sync; and it's harder to set
up (I have to do things like edit .git/config by hand in 20 repos
instead of just one to do things like make pushurl !- url).

> For end users,
> it's also annoying to clone a large repository when you're only
> interested in a small subset of its contents.

That's true. But nobody's suggesting that end users would be
cloning git repos, are they? They'd just be running some friendly
UI to say "give me the files I need for the foo plugin", and the
backend downloads the right files and puts them in the right place.
End users will never know they're using git at all.

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP crashes at changing of theme

[Akkana Peck]

Alexander Rabtchevich writes:
> Grey icons from small theme become undistinguishable to me - they do not
> have enough contrast between background and image.

Kevin Payne writes:
> Can you be more specific about which Icon Theme you are having the low 
> contrast problem with and what your system colours are, as the Small Theme 
> will use your system colours there is no way to know which Icon Theme is 
> going to work best for you.

I have that problem with the Symbolic icons with all the Light or
Lighter themes. When I first switched my initial reaction was "Why
are all the Toolbox icons greyed out?!" Once I realized they weren't
greyed out, they looked like that all the time, I tried to work with
them, but I found that I really couldn't see the differences and had
to hover over each icon to wait for the tooltip. Fortunately there
are the Color and Legacy icon theme options.

The Dark themes seem to have much more contrast, with Symbolic
icons, than any of the Light themes. I think the dark themes would
be usable, but they don't go well with the rest of my desktop.

Another question about theme switching: every time I switch themes,
my toolbox resizes to four icons across, so small that tooltips has
to show a horizontal scrollbar for most tools. It has to be six
icons across to avoid a scrollbar, and I always have to resize it
larger after switching themes. Is this intentional, or should I file
it as a bug?

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Export instead save directly

[Akkana Peck]

Alexandre Prokoudine writes:
> >Also, if you think that changes of this sort should be officially
> >talked about in any other way than they already have been, I'm
> >listening.

A. da Mek writes:
> A warning on the download page.
> A tip of the day (if possible the first one).

The Save-Export split is described in the Release Notes for 2.8,
linked from the downloads page:
http://www.gimp.org/release-notes/gimp-2.8.html
It's always a good idea to read the release notes when upgrading
software if you want to be warned about user interface changes.

(Do I always remember to do that myself? No. But if I forget to
look, I don't complain afterward about not having been informed.)

The change was also discussed on the gimp-user list starting in
early May 2012. (It was discussed on IRC and the developer list much
earlier than that, of course, but users aren't expected to see that.)
And it has been discussed a lot since then -- my mail folder tracking
this topic is up to 1722 messages now, and that doesn't count forums.

I don't like the Save-Export split either (and said so in 2012), but
it's baffling to see people complaining about not being notified in 2016
about a change that was clearly documented and discussed back in 2012.

As for sticking with 2.6 and refusing to upgrade: really? Well, it's
your choice, of course, but there's no way I'd stick with an older
version just because of something that's so easily worked around in
a program as configurable as GIMP. You can learn to use export, you
can customize your key bindings, you can use a plug-in that does
what you want (that's what I did: google for "gimp saver").
GIMP 2.8 has some great new features and 2.10 will have even more.
You're free not to upgrade, but you're shortchanging yourself.

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP 2.9 XCF files and digiKam, gnome file browsers, etc

[Akkana Peck]

Related question: is there any chance the gdk_pixbuf_* functions
will ever support XCF, e.g. in gdk_pixbuf_new_from_file()?
Then at least some image viewers would get support for free.

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP can't find libmypaint-gegl

[Akkana Peck]

Owen Cook writes:
> I searched my history for libmypaint as well as otherthings found I did this;
> 
> a.  git clone https://github.com/mypaint/libmypaint.git
> b.  I then read the README.md
> c.  Had to install scons
> d.  The last scons command was # scons prefix=/home/owen/Gimp-GIT 
> enable_gegl=true
> (but judging by the number of other attempts, I must have had some problem)
> e.  That generated the libmypaint-gegl.pc
> f.  then I exported /home/owen/Gimp-GIT/libmypaint to the PKG_CONFIG path
> g.  Lastly I installed MyPaint from a debian package manager for the brushes
> h.  rebuilt gimp, there was an entry to load mypaint brushes, but "it didn't 
> work"

Here's what I needed on Debian sid:

git clone https://github.com/mypaint/libmypaint.git
cd libmypaint/
sudo apt-get install scons libjson-c-dev
sudo scons prefix=/usr/local/gimp-git/ enable_gegl=true install

Then configure, make, make install gimp as usual.

To use it (I had to dig around the source to figure it out):
Tools->Paint Tools->MyPaint Brush (or there's a new icon in the
Toolbox), then Windows->Dockable Dialogs->MyPaint Brushes. It shows
a selection of standard MyPaint brushes and they work fine in
monochrome. Pretty cool! I haven't figured out how to get them in
color -- maybe that's not implemented yet.

I tried importing some new brushes and that didn't work:
@Gimp_Official recently retweeted somebody's collection of
neat-looking brushes, so I downloaded them from the link in
https://twitter.com/GisselEscu/status/679981643638161408
and tried installing a few of them in ~/.mypaint/brushes but GIMP can't
load them and doesn't say why, just:
Failed to load data: Error loading [path]/feathersGE.myb

Question for somebody who knows about this new libmypaint dependency:
should we be keeping up to date on libmypaint? In other words, when
I update and build gimp master, I always update and build babl and
gegl first. Should I also update and reinstall libmypaint each time
I update GIMP? Or should we be using a particular tag or branch
of libmypaint?

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] SGO to WGO Transition

[Akkana Peck]

Elle Stone writes:
> I stand corrected. There is a header at the top of each page, with Wilber in
> the header. But the user must enable scripts to see the header.

Even with scripts, it's tough to tell that icon is actually Wilber.
It's so small that the eyes aren't identifiable as eyes, and the
"negative space" nose and mouth only make sense if you're already
very familiar with that particular Wilber variant.

> This is not good. Users shouldn't be required to enable scripts to see the
> header at the top of the page.

+1

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Status Update on Redesign

[Akkana Peck]

Pat David writes:
Pat> Downloads Page
Pat> I'm a bit conflicted about this.  I understand that we used to use jquery
Pat> to try and guess the OS the visitor was on, and present them with a
Pat> sub-section of the downloads page.
Pat>
Pat> I am almost thinking that perhaps we can simply present users with clearly
Pat> marked links at the top of the Downloads page to choose which OS they would
Pat> like a download for?  Any objections to going this route?

Andrew Pullins writes:
Andrew> Please, please, please do this. after seeing other sites do this I can't
Andrew> stand when a site shows me every single OS option out there.  
LibreOffice
Andrew> has a really nice download page
Andrew> 
.
Andrew> Not only does it give you a great big download button for your OS but it
Andrew> but it gives you the option to download it through torent, slect a 
differnt
Andrew> OS, change the version you are downloading, provides source code, [ ... 
]

Pat David writes:
Pat> Do you mean to do the auto-OS detection, or to not?

I wasn't sure either, but it's worth noting that the libreoffice
download page at
http://www.libreoffice.org/download/libreoffice-fresh/?version=5.0.1
(I'm not sure if that's the same page as the one Andrew likes --
different URL) doesn't need javascript or jquery for OS detection.
Even with noscript, it correctly shows me a download button for Linux
x86. Presumably it's doing server-side checking of the browser's User-Agent.

Personally, I'd be fine with Pat's suggestion of just having links
at the top, but server-side user agent detection is a nice touch.

Andrew> There are only two things I could suggest is that this site is not
Andrew> responsive and that is becoming a big thing right now.  don't know how 
much
Andrew> more work it would be to do that but it would be nice.

Pat> The site is actually responsive. Try looking at it on a mobile screen,

On the Downloads page, the page content is responsive but the image
at the top forces the page to 900px wide. Maybe that's what Andrew
is talking about? The rest of the site is very responsive.

One other issue: the webfonts in the toolbar at the top look awful
in either Firefox or Chromium on Debian unstable. Debian seems to
have a problem in general with rendering webfonts -- I've seen it
on other pages that use them. Screenshot:
http://shallowsky.com/tmp/gimp-news-screenshot.jpg

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Drop shadow - a question from an user - developer-version 2.9

[Akkana Peck]

Alexandre Prokoudine writes:
> Does this GEGL op do anything for you at all? Because it does
> absolutely nothing for me (duly noted in
> http://wiki.gimp.org/wiki/Hacking:Porting_filters_to_GEGL/UI_review),

Joao S. O. Bueno writes:
> Yes, I've just tested it and it is definitely working here.

I've seen it do nothing, but I've also seen it work. It might have
something to do with the scale or transparency of the active layer, but
I haven't figured out the rules for when it works vs. when it doesn't.

In truth, I haven't tried very hard since the GEGL drop shadow
doesn't work well enough to be usable, so I use the old non-GEGL
plug-in.  I agree with everyone else that the shadow needs to be on
its own layer -- especially on text layers, where GEGL drop shadow
currently does nothing except discard the layer's text information.

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] square feet & close up window

[Akkana Peck]

ws writes:
> 1 close up window
> To have a second window which tracks where the mouse is to see with pixel
> perfect accuracy where you position your curser to edit the picture in pixel
> perfection quickest. The standard way is to select where you want to edit,
> then zoom in, move the curser to edit with pixel precision, then zoom out.
> Which may seem like 3 steps but you have to also move and select the options
> which can make you loose time and your location. So anywhere the mouse goes
> the other window has at the center the mouse pointer fixed on it so that you
> see the big picture zoomed out on the main screen while the other window
> tracks close up where the mouse it.

I'm not completely sure I understand what you're asking for, but you
may want to check out View->New View. You get another window pointed
at the same file, and assuming you're not using single-window mode,
you can view both at the same time. Try using one view at 100% and
the other view at, say, 600%, so you can see each pixel as a big block.
You can see what pixel you're changing and at the same time, see what
the normal-sized image looks like. It's great for editing small icons.

> 2 square feet

When I google [[ gimp measure area ]], I get a lot of hits suggesting
that there are ways to do this already using the Histogram dialog.
If you wanted the conversion too, that would be relatively easy to
implement as a plug-in, and it looks like there are some available
already.

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Getting contributors via OpenHatch

[Akkana Peck]

Jehan Pagès writes:
> Well yes, I get that. But these people who "want to make", in the end,
> they still have to deal with us, not OpenHatch. What's the difference
> between going directly to us rather than going through a third party?
> Anyway maybe there is a point I miss. Future will tell us. Maybe that
> will be good for GIMP, who knows?

One difference: OpenHatch is explicitly oriented toward teaching and
mentoring.  If someone comes to OpenHatch and gets matched with
someone who has signed up to be a GIMP mentor, the new person
doesn't have to worry that they're pestering someone or dragging
them away from projects they'd rather be doing.

Another difference: in the discussion on #openhatch the other day,
someone asked if they might use GIMP as one of the programs in
workshops they give, where they help teach people how to contribute
to open source, then have hack sessions where groups of students get
together and work on fixing bugs in the chosen projects. So they can
both support each other, and get help from an experienced tutor.

I don't have any firsthand experience with OpenHatch workshops, but
they sure sound like they'd be helpful both to would-be contributors
and to the project.

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Search Action dialog feature

[Akkana Peck]

Alexandre Prokoudine writes:
> words heavily depends on user's background. E.g. younger and less
> experienced users don't get the way all crop-related functions in GIMP
> are translated into Russian, because typically they are not familiar
> with photography terminology and expect simpler words.

Even in English, people new to GIMP may look for "Resize" when they
actually want "Crop", especially if they're transitioning from
programs that don't use the word "Crop". I know that was a problem
for me when I first started learning GIMP, and a search tool that
told me something called "Crop" exists when I searched for "Resize"
would have helped a lot.

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Panoramas (was Gimp 2.8)

[Akkana Peck]

Partha Bagchi writes:
> Akkana Peck used to have a panorama plugin called Pandora (
> http://www.shallowsky.com/software/pandora/). I don't know if she is still
> maintaining it.

I am still maintaining it (though Pandora hasn't changed in years)
but Pavel is right that it doesn't re-project, nor does it do any
automatic stitching. All it does is lay out images with a reasonable
overlap and layer masks so you can stitch them by hand.  For
complex panoramas, I use hugin, though I find it difficult
to use and wish there was something easier.

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] how far from 2.10?

[Akkana Peck]

>On 31 December 2013 23:26, Ofnuts  wrote:
>>it looks like many plugins won't work anymore and will need
>>seroius rework...

On 01/01/2014 03:10 PM, Jon Nordby wrote:
>Which plugins do you expect not to work anymore, and why?

I'm sure this isn't what Ofnuts was talking about, but I've noticed
that with git master gimp and the xsane plug-in that's in Debian sid,
I have to dismiss a deprecation warning dialog for every page I scan,
which is rather annoying since it messes with window focus.
I don't get the warning in 2.8. (Sorry to be so nonspecific -- my
scanner is packed away right now so I can't easily regenerate the
warning, but if deprecation dialogs are unexpected I'd be happy
to chase down the details and file a bug.)

Obviously this isn't a "won't work any more" nor is it "serious
rework" -- scans still work, and it's probably just a one-line change
to xsane to make the warning go away. (I've hit some deprecation
warnings in my own plug-ins, and fixing them is always very easy.)
But it is an annoyance when using a pre-compiled plug-in, so I
switched back to 2.8 for scanning.

It is kind of a shame that GIMP shows a dialog every time for
deprecations ... might be nicer if it could show it once then be
quiet about it for the rest of the session, since it's not something
the user can do anything about.

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Quick-edit workflow

[Akkana Peck]

Jehan Pagès writes:
> Just checking master, currently when "overwrite" is shown, export-to
> is not grayed out but it is invisible.
> That means that it is active and can be run if you know the shortcut,
> but you can't export from the menu (for people who don't know
> shortcuts, new or casual users, etc.).

It's definitely useful to have it available via the shortcut (now
that I'm clear on what it does :-) -- I'd use it in preference to
Overwrite since it means I only have to remember that one shortcut
(plus Ctrl-S, of course).

And thanks, Peter, for the name change! These:

> > Export... -> Export As... (in all states)
> >
> > “Export to” -> Export (when no export target)

do seem clearer since they're more similar to Save and Save as...

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Quick-edit workflow

[Akkana Peck]

peter sikking writes:
> what we were missing was a quick succession of ctrl shortcuts
> (cmd on mac) that close unsaved images.
> 
> I worked on it with mitch and it is now in git.
> 
> so now everyone can press ctrl-W to close a document, keep
> the finger on the ctrl and press ctrl-D in the dialog to
> Discard changes.
[ ... ]
> - yes, also works for Quit and Close all
> - yes, mitch is back-porting it to 2.8, see next release

Nice! I've lost work a couple of times with the new model,
and the Quit dialog solves that problem.

It took me a few minutes to learn how to read it -- it says

[filename.png](imported)-N

if I've modified the image and never exported;

[filename.png](overwritten)-N

if I've exported in the past but not since the last change; and

[filename.png](overwritten)-N
Exported to /path/to/filename.png

if it's safe and has been exported since the last change.  So it
looks like the important thing is whether the extra "Exported to..."
line is there. It's great to have that information.

> > Sorry, I didn't notice the "File > Overwrite " menu option.
> > Perhaps a keyboard shortcut for the same would be nice.
> 
> I thought about that for a long time when I wrote the spec.
[ ... ]
> - I wanted to use the inertia of having to do the effort of
>  setting your own shortcut to make you think: if really, really
>  overwrite _is_ your primary way of working and important
>  enough to set it.

I've found that the new model makes me stop and think every time
I save or export anything. For one thing, I'm still confused about
the difference between Export... and Export to -- they seem to do
the same thing even though one has a ... and the other doesn't, they
have different shortcuts, and one of them isn't always available.
And I can never remember in any given session which images can use
Overwrite versus which ones need an Export... or Export to, so I no
longer trust any save/export shortcut to be the right one, and
almost always end up going to the menus instead.

A shortcut for Overwrite would just add the uncertainty of
"What if this image doesn't have a file associated with it yet?" --
in which case Overwrite silently does nothing, and you might think
you've exported when you really haven't, and lose your work.

Anyway, the new Quit dialog will help in guarding against data loss
from export mistakes like that. So thanks!

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Usability for icon-editing

[Akkana Peck]

Thomas W writes:
> 1) Icons open at 100% view, which is tiny in the window & far smaller than
> what I want for working at. This always requires two steps -- increase
> magnification, and then drag the window larger.

You might want to change the preference "Resize window on zoom"
in the Preferences window under "Image Windows". It will eliminate
the second step.

> 3) Not very easy to test icons. There's no quick way to get rid of the
> selection border, layer borders & background checks to view the overall
> tonality & see how it looks against a white background.

You know about the items in the View menu, right? And if you do
View->New View, you can turn off all that visual clutter in one
view while leaving it on in the other. You can also have a view
that shows you the icon at actual size, while you work on another
view with a high zoom.

> 4) Feature idea:  Especially nice would be the ability to view & test
> icons, or transparency in general, by dragging it against a white/ and
> variegated background (or over the whole desktop)  with a range of zoom
> levels from 100 - 400%.

That would be nice. I test transparent images by having a white or
colored background that I turn on or off as I edit the image, but
having a way to do that without making an extra layer would be useful.

You can test against the current desktop, even with transparency, using
Filters->Animation->Playback, then click the Detach button and drag
the image to the desktop. It would be nice if this feature wasn't so
hidden, since it's very useful for non-animated images but no one
is likely to discover it where it is without being told.

> Perhaps icon-editing is a little bit different from the "photographic
> editing" usecase, but it's quite common. Does anybody else find areas where
> GIMP could support the user/ workflow better? Suggestions welcome.

I've found GIMP to be an excellent tool for what little icon editing
I've done, mostly because of its multiple views.

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Documentation about menu hooks

[Akkana Peck]

b...@neeneenee.de writes:
> is there a documentation about menu hooks in GIMP? Is there a
> listing at the source code?
> 
> I tired to try out how to get my python plugins in the right place.
> So i'd like to do
> a visual documentation for any developer. I attached an example on this mail.

I don't think I've seen formal documentation, but if you look in the
source, in the menus/ subdirectory are all the menu definitions in XML.

For hooks I think you're talking about pseudo-submenus like
"/File/Save/", where Save/ isn't an actual menu item, just
a place in the menus where you'd want to group all the actions
related to saving. In image-menu.xml I see things like
,  and so forth.
So if you take all the "https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Export all

[Akkana Peck]

> On 07/20/2013 02:21 PM, Akkana Peck wrote:
> >That is such a good idea that I wanted to dive in right away and
> >write it.

Jason Simanek writes:
> That's fantastic!
> 
> I grabbed the code and tried it but it doesn't seem to do anything
> on Gimp 2.8.4. Then I looked at the code for a minute and realized
> that I do not understand how to write Python for Gimp.
> 
> Wish I could help!

Well, you certainly do need to know how to install a Python plug-in
in order to run it, of course. And you'd need to learn how to hack
Python plug-ins in order to modify it. So maybe this is a great
excuse to learn!

Googling finds several useful howtos and tutorials, e.g.
http://blog.meetthegimp.org/how-to-install-python-plugins-under-gimp/
http://www.exp-media.com/gimp-python-tutorial
http://www.ibm.com/developerworks/library/os-autogimp/

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] GIMP python (pythonfu) plugin: How to include the PreviewArea from gimpui

[Akkana Peck]

Bertrand Denoix writes:
> On 07/20/2013 07:22 PM, Akkana Peck wrote:
> >But Python does allow you to write any UI you want -- you have the
> >full pygtk library available. So you could make a scaled-down
> >version of the image, do your preview operations to it, and show
> >it in a drawing area.
> 
> Not too realistic...  pixel-oriented  operations in python would be
> much to slow to be usable in a preview

Anything you can do to the full image in Python, you can do a lot
faster to a thumbnail-sized preview, surely?

And pixel operations can be remarkably fast in Python (or remarkably
slow, depending on how you set them up). Following methods of GIMP
Python expert Joao Bueno, I got my arclayer Python plug-in running
nearly as fast as the C version. The write-up:
http://shallowsky.com/blog/gimp/pygimp-pixel-ops.html

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] Export all (was: Gimp Export Properties Not Preserved)

[Akkana Peck]

Jason Simanek writes:
> Another Idea! A feature that Photoshop doesn't have (outside of
> creating an Action): an "Export all open files" dialog could be
> pretty great. Allowing you to set – like DBP – the quality
> properties and destination directory all at once to export all open
> files. That would be AWESOME.

That is such a good idea that I wanted to dive in right away and
write it.

But unfortunately I have too many things on my plate right now and I
can't write the whole thing. So instead, I wrote a skeleton for it.
It brings up an ugly dialog showing all the open images with their
filenames and full pathnames, and a toggle button so you can disable
saving/exporting for that particular image. You can also edit the
filename to change the extension -- e.g. if the filename comes up
as foo.xcf, you can change it to .jpg and export it that way.
Any images that are exported will be marked clean (so you don't
get a nag screen when you exit).

Obviously this isn't the nice full-featured plug-in you had in mind,
but it implements the basics so anyone can add to it, and I'm hoping
people will. Make the dialog pretty, add proper file choosers, add
parameters like the jpeg quality, whatever you think it needs! So,
anyone who wants an "Export all" plug-in, please add the features
you want and send patches.

It's on GitHub:
https://github.com/akkana/gimp-plugins/blob/master/export-all.py

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] GIMP python (pythonfu) plugin: How to include the PreviewArea from gimpui

[Akkana Peck]

Michael Schroeder writes:
> I am writing a plugin for Gimp. It works alright via the GIMP UI and
> command line by registering it to gimp. But I would wish to offer also a
> Preview area in the UI, and apparently it is not so easy to add the
> PreviewArea from the gimpui python package to the input dialog.

Since I haven't seen any other responses:

I don't think there's a way to add a formal preview area in Python.
But Python does allow you to write any UI you want -- you have the
full pygtk library available. So you could make a scaled-down
version of the image, do your preview operations to it, and show
it in a drawing area.

I'm not sure if there are any good examples of Python scripts that
do this. It would be great if someone would try this, write an
example and contribute it as pygimp documentation. There are lots
of examples for displaying images in pygtk -- I've found that simple
to do in other programs -- so it's mostly a matter of getting the GIMP
image into a format pygtk can display, and I don't know how hard or
easy that is. If you try it, please post a followup here.

...Akkana
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] API for time of last change vs. last export

[Akkana Peck]

On the thread-which-shall-be-nameless, when folks were asking for
a way to quit GIMP without being prompted to save files that had
already been exported, Alexia wrote:
> Oh, let me throw up this idea for you -  you do not need a fork, just
> a script to override the default close... Very easy to install,
> maintain and distribute. No fork needed.

Alexia, how?  I looked into it, but couldn't figure out any way
to do it.

There's gimp-image-is-dirty to check whether an image has been
changed since the last XCF save -- is there a similar flag for
checking whether an image has been changed since the last export?
There's gimp-image-get-exported-uri, but that only tells you whether
the image has *ever* been exported, not whether it's been exported
since the last image change.

If you could get the time of the last image change, you could
compare it to the last modified date of the export file, but I
don't think there's a GIMP call to get that either.

Suggestions?

...Akkana
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] [Gimp-user] [Request] Do not confirm closing if unsaved image was exported/overwrited ?

[Akkana Peck]

Richard Gitschlag writes:
> However, a resize-during-export could make an interesting feature request

I wrote a simple version of that recently:
http://shallowsky.com/blog/gimp/gimp-export-scaled.html

...Akkana
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] [Gimp-user] A plug-in for those who still don't like the new Save/Export

[Akkana Peck]

maderios writes:
> The Akkana script
> https://github.com/akkana/gimp-plugins/blob/master/save-export-clean.py
> works well now.

For those who haven't used sites like Github before: be sure to
click on "Raw" before saving the plug-in to your plug-ins directory.

minhsien0330 writes:
> After testing it I found this plug-in will not export the background layer
> to save.

Interesting! Thanks for the clear steps -- I see the same thing you do.

I had wondered why the PDB call gimp-file-save required a drawable
(layer) argument. It looks like, when exporting to formats like jpeg
which can't handle multiple layers, gimp-file-save uses that
argument to decide which layer to save. That also explains why,
in GIMP 2.6 and earlier, we had to go through that extra step of
flattening the image if it had multiple layers before it could be
saved to jpeg.

To get around that, the plug-in would probably have to have some
of extra logic:

if (the image has multiple layers)
look up target file type to see if the format supports that
if not supported:
save context for undo, or make a duplicate image
flatten the image
save it
undo the flatten or delete the duplicate image

I don't know of a way using the GIMP pdb to look up whether a
particular file format needs flattening. So the plug-in might have
to maintain its own table of formats.

I had been thinking about this plug-in as something for people who
edit a png or jpg or whatever, make a simple change and re-save it.
I figured that when someone starts adding extra layers, they'd
actually prefer the "save as xcf, export a copy to jpg" model ...
at least, that's my own workflow. Do you think there are a lot of
people who use multiple layers yet save as jpg?

> Besides, how do I setup the exported  jpg quality? The defualt jpeg output
> quality of Save/Export Clean seems very low.

That's a good question, and might require more research. At first I
assumed it was following my default settings for the jpeg plug-in.
If you export to JPG and get the dialog, you can click on "Save
Settings" after adjusting the Quality slider. But GIMP doesn't
actually seem to save those settings -- I find that whatever I
adjust them to, my jpg quality settings end up at 90, whether I
actually set the default higher or lower than that.

That might be a bug -- if so, we should probably move to the
gimp-developer list to find out (CCing). I'll do more testing
before filing one, but it seems odd that quality keeps ending
up at 90 and I don't seem to be able to change it.

...Akkana
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] [Gimp-user] A plug-in for those who still don't like the new Save/Export

[Akkana Peck]

> minhsien0330 writes:
> > Besides, how do I setup the exported  jpg quality? The defualt jpeg output
> > quality of Save/Export Clean seems very low.

Akkana Peck writes:
> I find that whatever I
> adjust them to, my jpg quality settings end up at 90, whether I
> actually set the default higher or lower than that.

Turns out that's a known bug that has already been fixed in the GIMP
2.8 tree.

...Akkana
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] xcf.gz Format

[Akkana Peck]

Anke Lange writes:
> Well, I'm afraid, I built it myself, but if that is the problem, I
> will try to compile it again and hope to get all dependencies this
> time.

I hit the same problem on a recently installed Ubuntu machine.
It turned out I was missing the package libbz2-dev (thanks to Mitch
for pointing it out).

Configure had printed:
Compressor:  no
but I didn't look carefully and didn't notice it, so I ended up with
a build that couldn't open .xcf.gz. Adding libbz2-dev and
reconfiguring fixed the problem.

...Akkana
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] something's starting, it is the text tool

[Akkana Peck]

peter sikking writes:
> so please help us by replying here, with you answer what
> text means to you when working with GIMP.

My most common use case for text: adding text to a photo for
something like a greeting card or a poster, sometimes intended
for the web and sometimes for print. So I start with a photo
(anywhere from 2 to 12 megapixels) and add some kind of banner
text in a fancy font. Typical workflow:

- open a photo (fairly high resolution)
- with the text tool active, click in the image
- type some text (now the text is about 3 pixels high, since it
  defaults to 18 px).
- play around with the size, color, and font face until it looks good

That works if I use the Tool Options, but I've found that I can't
use 2.7's new on-canvas box for any of that, because it only works
on whatever text is selected. Initially I can't select anything
because the text is too small to see (if I try, I always end up
missing the first few characters). Even after I enlarge it from Tool
Options, selecting the text covers it with a yellow box so I can't
see how the text looks against the background.

I'm sure there must be a way around this (I can't be the only person
who adds text to high-res photos). I'd love to hear other people's
2.7 workflows for that.

...Akkana
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] RFE: predefined (and customizable) list of aspect ratio values in Crop tool options

[Akkana Peck]

wwp writes:
> On Thu, 27 Oct 2011 15:54:27 +0300 Alexia Death  wrote:
> > 2.7 has brand new sparkling tool presets that fill this need :) They
> > have been widely used exactly for this purpose by early testers.
> 
> Interesting! I'll give 2.7 a try and come back later if necessary.
> 
> Unsubscribing now, thanks to all!

You don't have to use 2.7 to get tool presets. I use tool presets
all the time in 2.6 for crop and rect select aspect ratios.
http://www.shallowsky.com/blog/gimp/gimp-tool-presets.html

...Akkana
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list