Re: [Gimp-developer] Compile gimp on windows

[Petteri Soininen]

Check if you have a valid PREFIX variable. Had that problem once.

what does

echo $PREFIX

output?


On 17.5.2017 18:37, Lorena Dutra wrote:

Here is the log of my attempt

reitz@LAPTOP-N3JKVGON MSYS ~
$ git clone https://github.com/mypaint/libmypaint.git

./autogen.sh
./configure --prefix=$PREFIX
make
make install
cd ..
fatal: destination path 'libmypaint' already exists and is not an empty
director
  y.

reitz@LAPTOP-N3JKVGON MSYS ~
$ cd libmypaint

reitz@LAPTOP-N3JKVGON MSYS ~/libmypaint
$ ./autogen.sh

I am testing that you have the tools required to build
libmypaint from git. This test is not foolproof.

checking for libtool >= 1.5 ... Major version might be too new (2.4.6)
checking for autoconf >= 2.62 ... yes (version 2.69)
checking for automake >= 1.13 ... yes (version 1.13.4)
checking for intltool >= 0.40.1 ... yes (version 0.51.0)
WARNING: cannot find glib-2.0.m4 in aclocal's search path.
  You may see fatal macro warnings below.
  I looked in:  /usr/share/aclocal
  If these files are installed in /some/dir, set the
  ACLOCAL_FLAGS environment variable to "-I /some/dir",
  or append ":/some/dir" to ACLOCAL_PATH,
  or install /usr/share/aclocal/glib-2.0.m4.

WARNING: cannot find glib-gettext.m4 in aclocal's search path.
  You may see fatal macro warnings below.
  I looked in:  /usr/share/aclocal
  If these files are installed in /some/dir, set the
  ACLOCAL_FLAGS environment variable to "-I /some/dir",
  or append ":/some/dir" to ACLOCAL_PATH,
  or install /usr/share/aclocal/glib-gettext.m4.

configure.ac:267
:
warning: macro 'AM_GLIB_GNU_GETTEXT' not found in library
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4macros'.
libtoolize: linking file 'm4macros/libtool.m4'
libtoolize: linking file 'm4macros/ltoptions.m4'
libtoolize: linking file 'm4macros/ltsugar.m4'
libtoolize: linking file 'm4macros/ltversion.m4'
libtoolize: linking file 'm4macros/lt~obsolete.m4'
Checked mypaint-brush-settings-gen.h: up to date, not rewritten
Checked brushsettings-gen.h: up to date, not rewritten
configure.ac:37
:
installing './missing'
Makefile.am: installing './depcomp'
configure.ac:283
:
error: possibly undefined macro: AM_GLIB_GNU_GETTEXT
   If this token and others are legitimate, please use m4_pattern_allow.
   See the Autoconf documentation.

reitz@LAPTOP-N3JKVGON MSYS ~/libmypaint
$ ./configure --prefix=$PREFIX
configure: loading site script /etc/config.site
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... no
checking for cc... no
checking for cl.exe... no
configure: error: in `/home/reitz/libmypaint':
configure: error: no acceptable C compiler found in $PATH
See `config.log' for more details

reitz@LAPTOP-N3JKVGON MSYS ~/libmypaint
$ make
make: *** Nenhum alvo indicado e nenhum arquivo make encontrado.  Pare.

reitz@LAPTOP-N3JKVGON MSYS ~/libmypaint
$ make install
make: *** No rule to make target 'install'.  Pare.

reitz@LAPTOP-N3JKVGON MSYS ~/libmypaint
$ cd ..

reitz@LAPTOP-N3JKVGON MSYS ~
$

reitz@LAPTOP-N3JKVGON MSYS ~
$ git clone https://git.gnome.org/browse/babl

./autogen.sh --prefix=$PREFIX --disable-docs
make
make install
cd ..fatal: destination path 'babl' already exists and is not an empty
directory.

reitz@LAPTOP-N3JKVGON MSYS ~
$ cd babl

reitz@LAPTOP-N3JKVGON MSYS ~/babl
$ ./autogen.sh --prefix=$PREFIX --disable-docs
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4 ${ACLOCAL_FLAGS}
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'

Re: [Gimp-developer] Windows 10 and Bash on Ubuntu

[Petteri Soininen]

Hi

Not gaining personally anything, but maybe making development builds 
more accessible to those who come from MS Windows backgrounds.


Now they have to setup a Msys2 environment and do builds with that, 
which isn't as easy as it sounds with instructions that are partly 
outdated, but if Win10 has an Ubuntu shell, that probably is quite same 
for everyone who uses it, so why not try to build GIMP for Windows with 
that? GIMP isn't supposed to be an elitist Linux application, but a 
serious cross platform tool for everyone. Or so I have thought this far.


- Petteri Soininen

On 4.2.2017 5:07, Partha Bagchi wrote:


On Fri, Feb 3, 2017 at 9:53 PM, Petteri Soininen <peso...@gmail.com 
<mailto:peso...@gmail.com>> wrote:


I'd probably try cross build since after 'sudo apt-get install
gimp' and trying to run it, it fails on 'cannot open display' so I
think that indicates the shell cannot run it under windows and
gimp needs to be built as a cross build. But as said, I'm just a
beginner.  :)

    - Petteri Soininen

Well, GIMP is a graphical application and X11 are not officially 
supported on WSL. So, first you'll need to install X11 and then set 
the display appropriately. If you are familiar with Linux this should 
not be a problem. I think the command is something like export display.


If you simply plan to cross build, I am not sure what you are gaining 
with WSL.


Hope that helps.


___
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] Windows 10 and Bash on Ubuntu

[Petteri Soininen]

I'd probably try cross build since after 'sudo apt-get install gimp' and 
trying to run it, it fails on 'cannot open display' so I think that 
indicates the shell cannot run it under windows and gimp needs to be 
built as a cross build. But as said, I'm just a beginner.  :)


- Petteri Soininen


On 4.2.2017 4:28, Partha Bagchi wrote:
Are you planning to cross build or a native build? I am not sure what 
you are asking.


On Fri, Feb 3, 2017 at 9:20 PM, Petteri Soininen <peso...@gmail.com 
<mailto:peso...@gmail.com>> wrote:


Hi

I was more like thinking if anyone has already done that so I
could get some pointers and try it too. If that's not the case I
probably can try building it myself and take notes to make a 'how
to' so I can give advice to others who like to try the same. If
during that I face problems, I'll probably try to ask help in IRC.
That Bash shell probably is quite standard installation in WIn10,
so making build instructions for that couldn't hurt (if that's
even possible). :)

    - Petteri Soininen

On 2.2.2017 22:13, Michael Schumacher wrote:


On 02/02/2017 08:05 PM, Petteri Soininen wrote:

Windows 10 introduced an Ubuntu Bash shell, so I'm
interested if anyone
has compiled GIMP using that environment. I tried, but I'm
just a newbie
and got into problems where gegl didn't see babl etc. so
my environment
variable settings were probably either wrong or not
effective or I just
messed up something.

Hi Petteri,

this is the point where you should explain what you did in
regard to the
environment variable - as detailed as it would be necessary
for someone
to reproduce what you did, without knowing what you did.



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




___
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] Windows 10 and Bash on Ubuntu

[Petteri Soininen]

Hi

I was more like thinking if anyone has already done that so I could get 
some pointers and try it too. If that's not the case I probably can try 
building it myself and take notes to make a 'how to' so I can give 
advice to others who like to try the same. If during that I face 
problems, I'll probably try to ask help in IRC. That Bash shell probably 
is quite standard installation in WIn10, so making build instructions 
for that couldn't hurt (if that's even possible). :)


- Petteri Soininen

On 2.2.2017 22:13, Michael Schumacher wrote:


On 02/02/2017 08:05 PM, Petteri Soininen wrote:


Windows 10 introduced an Ubuntu Bash shell, so I'm interested if anyone
has compiled GIMP using that environment. I tried, but I'm just a newbie
and got into problems where gegl didn't see babl etc. so my environment
variable settings were probably either wrong or not effective or I just
messed up something.

Hi Petteri,

this is the point where you should explain what you did in regard to the
environment variable - as detailed as it would be necessary for someone
to reproduce what you did, without knowing what you did.




___
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] Windows 10 and Bash on Ubuntu

[Petteri Soininen]

Hi,

Windows 10 introduced an Ubuntu Bash shell, so I'm interested if anyone 
has compiled GIMP using that environment. I tried, but I'm just a newbie 
and got into problems where gegl didn't see babl etc. so my environment 
variable settings were probably either wrong or not effective or I just 
messed up something. This is not important as I can still build 
everything on Msys2, but I'd like to know if anyone has already done it?


- Petteri Soininen
___
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] New functionality request

[Petteri Soininen]

Hi,

If I correctly interpreted what I read and understood what Hugin 
algorithm does, then wouldn't it be more appropriate to adapt it to GEGL 
than making it a GIMP feature?


Petteri

On 1.8.2016 13:15, Alexandre Prokoudine wrote:

On Sun, Jul 31, 2016 at 11:28 AM, Marc Mascré wrote:

Hello everybody,

I would like to have a new functionality and I would like to submit to you
this idea. I need an auto align layer tool (rotation and translation).
Photoshop have it and I miss it a lot.

In fact, I think we could use and existing algorithm. Hugin, a panorama
maker, have this function. And for example Luminance-HDR, an HDR picture
maker, have an option to use Hugin algorithm to autoalign pictures before
merge it.

Yes, Luminance HDR can use the alignment tool from Hugin. Which means
you have to have Hugin installed, if you need that feature. We cannot
demand that from our users.

A native function (or maybe a GEGL op?) would come in handy in quite a
few cases, including exposure combination (whenever someone writes UI
for that GEGL tool). Patches are welcome ;)

Alex
___
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-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] Pencil - Tool Options and Hardness

[Petteri Soininen]

To make things even more complicated, the new MyPaint brushes can have a 
pixel brush that behaves like pencil.


So if we get brush option to turn anti-aliasing off, we'll have 3 tools 
to make pixel art with..


-Petteri

On 22.6.2016 13:40, Simon Budig wrote:

C R (caj...@gmail.com) wrote:

Have you actually tried to do what I outlined above?



Have you? lol
No - I haven't. It's not currently possible to turn off anti-aliasing on
the brush tool, so it's not possible to "test" it.

Ah, sorry. I missed that we're discussing hypothetical future
characteristics of the tools here. I was just looking at the current
difference between the pencil and the paintbrush tool.


However, knowing how anti-aliasing works, your statement is incorrect...

Well, if you choose to label the behaviour I described as
"pixel-grid-snapping" (or the lack thereof) as "anti-aliasing" then it
is not me who is making the error here. I actually don't think that they
are the same.


The paintbrush tool resamples the brush when the pixel grid of the brush

is not perfectly aligned to the pixel grid of the image.

Yes, but with anti-aliasing turned off (which you can't presently), it
wouldn't.


A perfect non-antialiased 1 pixel brush typically gets spread across
four adjacent pixels in the image, assuming you're working with a high
zoom level and don't specifically align the brush to the pixel grid of
the image.

I don't know why you would assume that. :)
It's incorrect at any rate.

This is *exactly* what the current paint brush tool does. And it really
is no rocket science to test it. Just do as I explained above. I even
did just a few moments ago, even if I knew this behaviour for years.


Anti-aliasing IS what average pixels to spread over a 4-pixel block.
If you turn it off (which, again, you can't currently in the brush tool),
and a single click with a 1px brush fills more than one pixel, then that
would be incorrect behaviour.

The Pencil tool does two things (compared to the paintbrush) that are
independent of each other:

a) it thresholds the alpha channel of the brush (with a quite low
threshold)

b) it snaps the pixels of the brush to the pixels of the image, so that
no resampling occurs.

This is the *current* state of Gimp. And it has been like this for ages.

If we want to put that as an option into the paintbrush (and lose the
pencil) then describing both of these behaviours combined as
"anti-aliasing" is IMHO misleading and wrong.

Bye,
 Simon



___
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] GimpAnchorFeatureType enum

[Petteri Soininen]

What is GIMP_ANCHOR_FEATURE_ALIGNED type meant for?

If I make a guess I'd say that it's meant for same as 
GIMP_ANCHOR_FEATURE_SYMMETRIC but moving one handle doesn't change the 
distance of the opposite handle, but only it's direction from anchor point?


-

___
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] Proposal: rename Symbolic icon themes to Symbolic-Light and Symbolic-Dark

[Petteri Soininen]

Hi,

Well, there's only few 'built-in' themes that should be considered now 
and if the naming
convention fits those, I think that's enough. Other themes can be named 
freely by their
author anyways and My Little Poney theme will probably be fully 
customized to fit

existing symbols or with awesome symbols of it's own... :D

-Petteri

On 31.5.2016 12:42, Jehan Pagès wrote:

Hello,

On Tue, May 31, 2016 at 4:10 AM, Petteri Soininen <peso...@gmail.com> wrote:

Hi,

Wouldn't that confusion be resolved by naming them as they are meant to be
used:
Symbolic-for-dark and Symbolic-for-light?

Indeed it would. But Schumaml was noting on IRC later on that people
could have custom themes which are neither dark nor light (what about
a pink My Little Poney theme! :P).
Also we actually have several shades of Grey (official) themes as
well. What icon theme is for them?

Someone else was noting that in RawTherapee, they actually have an
icon theme of light icons called "Dark" (and the opposite as well)
because it is meant to be used with the dark theme. This example
really show that the worry of confusion is actually quite real.
But in the same time, these are automatically tied together, which is
not the case in GIMP. So what works there could not work for us.

Anyway apart from the detail of "how about grey or
neither-dark-nor-light themes?" your idea still makes sense.

Jehan


On 31.5.2016 0:35, Jehan Pagès wrote:

Hi,

On Mon, May 30, 2016 at 11:04 PM, Michael Schumacher <schum...@gmx.de>
wrote:

Hi,

in the development branch, we got two Symbolic icon themes, Symbolic and
Symbolic-Inverted.

This hints at their relationship, as one is the inverted version of the
other. For those who know how the build works, it also tells which one
is generated from the other (by means of a gegl:invert-gamma op).

Copy-paste from IRC:

22:59 < Jehan> schumaml: last time we had the discussion, the problem
which rised was: is "Symbolic dark" about dark icons (for light
themes) or the icon set for dark themes (thus light icons).
23:01 < Jehan> So we went with the idea that the "Symbolic" is simply
the default icon theme (hence the light ones for a dark theme).

Now I don't really mind going for dark/light instead. I agree with the
rest of the logics of Michael here. Yes, "Symbolic" and "Symbolic
Inverted" are not that clear either. It's just that with the split of
themes and icon themes, we felt that naming icon themes dark/light
were not that clear and obvious either.

Well I needed to state the current logics. Now I don't really care.
With the knowledge of why what is named how, you can decide what
should be the future name, if it needs to change. :-)

Jehan


We also got five ui themes of different lightness and darkness, and the
user is supposed to use a combination of them suited to their own
preference and needs. I dare say many may consider light icons on darker
backgrounds or dark icons on lighter backgrounds a suitable UI design.

It is not immediately obvious to the user which icon theme is the dark
one and which is the light one, by theme name alone. There are icons in
the preferences, but there might not always be the advantage of using
them, for example when providing text-only support to a "your icons are
invisible!1!!"-type support request.

Therefore, I suggest to rename the icons themes to Symbolic-Light and
Symbolic-Dark, respectively, and keep them as such for the 2.10 release.

Other names to make the difference and the icons' appearance obvious are
possible as well, of course.


--
Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD
___
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-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-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] Proposal: rename Symbolic icon themes to Symbolic-Light and Symbolic-Dark

[Petteri Soininen]

Hi,

Wouldn't that confusion be resolved by naming them as they are meant to 
be used:

Symbolic-for-dark and Symbolic-for-light?

On 31.5.2016 0:35, Jehan Pagès wrote:

Hi,

On Mon, May 30, 2016 at 11:04 PM, Michael Schumacher  wrote:

Hi,

in the development branch, we got two Symbolic icon themes, Symbolic and
Symbolic-Inverted.

This hints at their relationship, as one is the inverted version of the
other. For those who know how the build works, it also tells which one
is generated from the other (by means of a gegl:invert-gamma op).

Copy-paste from IRC:

22:59 < Jehan> schumaml: last time we had the discussion, the problem
which rised was: is "Symbolic dark" about dark icons (for light
themes) or the icon set for dark themes (thus light icons).
23:01 < Jehan> So we went with the idea that the "Symbolic" is simply
the default icon theme (hence the light ones for a dark theme).

Now I don't really mind going for dark/light instead. I agree with the
rest of the logics of Michael here. Yes, "Symbolic" and "Symbolic
Inverted" are not that clear either. It's just that with the split of
themes and icon themes, we felt that naming icon themes dark/light
were not that clear and obvious either.

Well I needed to state the current logics. Now I don't really care.
With the knowledge of why what is named how, you can decide what
should be the future name, if it needs to change. :-)

Jehan


We also got five ui themes of different lightness and darkness, and the
user is supposed to use a combination of them suited to their own
preference and needs. I dare say many may consider light icons on darker
backgrounds or dark icons on lighter backgrounds a suitable UI design.

It is not immediately obvious to the user which icon theme is the dark
one and which is the light one, by theme name alone. There are icons in
the preferences, but there might not always be the advantage of using
them, for example when providing text-only support to a "your icons are
invisible!1!!"-type support request.

Therefore, I suggest to rename the icons themes to Symbolic-Light and
Symbolic-Dark, respectively, and keep them as such for the 2.10 release.

Other names to make the difference and the icons' appearance obvious are
possible as well, of course.


--
Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD
___
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-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] Can hitting Enter/Return twice apply changes made in popup dialogs?

[Petteri Soininen]

From personal experience I'd say if using enter to commit changes 
hasn't messed a production

database of an entire factory, then this should be less critical.
Ctrl-Enter is good designwise though. It gives less chance of mistake 
keypress and is

easily accessible with just one hand.
(And the one who ever originally thought that Alt-O should be used as a 
shortcut to 'OK' should
get beaten with a mouse and keyboard combo repeatedly and mercilessly 
ridiculed ever after.)


On 19.5.2016 4:53, Christopher Curtis wrote:

On Wed, May 18, 2016 at 12:32 PM, Michael Natterer  wrote:


On Wed, 2016-05-18 at 16:47 +0100, C R wrote:

1st enter opens the combo box, 2nd enter confirms the selection.
Third enter commits.



1. open combo (space)
2. confirm entry (enter)
3. confirm dialog (enter)


Is that really a good approach? I'm concerned that it's too easy to
accidentally commit some change by using the same key. Would it be better
to leave Enter alone, and have a global Ctrl+Enter or Shift+Enter to
accept+dismiss any dialog box?

Chris
___
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-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] Windows builds using MSYS2

[Petteri Soininen]

Got python working now.
Mainly four reasons why I fumbled with it for so long..
1) I had 32Bit gimp.pyd on my path for some reason. I have tried 
building both so I

must have moved it to test something and that 32/64 conflict confused me.
2) No libpython27.dll or pythonw.exe. With MSys2 there comes 
libpython2.7.dll and

python2w.exe though..
3) lib/gimp/2.0/interpreters/pygimp.intrep gets messed every time when 
building.

(this is definitely a bug in build process)
4) I once removed everything and used a different --prefix but the 
earlier installation
path in Edit/Preferences/Folders/Interpreters stayed the same even 
though other

paths changed to reflect the new location and I didn't notice it at first.
(someone might want to look at that if it's a bug)

On 9.5.2016 14:51, Partha Bagchi wrote:

What have you tried so far to get Python working? All I see is "python is
not working".

Just as FYI, I've been providing Windows 64bit and Mac builds for almost 5
years now.

On Mon, May 9, 2016 at 7:47 AM, Petteri Soininen <peso...@gmail.com> wrote:


I have a build working from latest master with Msys2, and I'm in progress
of making notes to how to do it. Still haven't got python working ok as
running Gimp gives me "Failed to execute child process (No such file or
directory)" errors on every py script when launching, but I'll post my
notes so far..

http://pastebin.com/ZHT2A4K5

Hopefully that helps.
(and I'm using WIn10, 64bit)

On 9.5.2016 13:03, Barney Holmes wrote:


Hi,

I've also been working on building Gimp for Windows simply because for
one reason or another I have Windows on my main, faster machine, and I've
wanted to get some of the latest bug fixes. I also wanted to fix -
https://bugzilla.gnome.org/show_bug.cgi?id=757717

I tried the Linux cross compile using the wiki Mingw64 instructions. I
was trying to retrieve the prebuilt library RPM's from, I think it's
OpenSUSE, but that seems to be outdated. Now I have Code::Blocks setup to
cross compile with MinGW-w64, I’ll try building those dependencies.

I'm investigating MSYS2. It looks like a good project and a lot of other
projects seem to use it to provide releases for Windows, but its a slow to
compile even with multiple threads set.  Some of those projects may use
Python so they might be able to help with Python for Gimp.

I attach my current "autogen" and "make" outputs. I am building with most
extras disabled as I just want to iron out the build process first.

http://files.djbarney.org/autogen_output.txt
http://files.djbarney.org/make_output.txt

Are you building from the main branch ?

Do you get a successful build with Python disabled ?

Cheers.

Sent from Mail for Windows 10

___
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-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-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-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] Windows builds using MSYS2

[Petteri Soininen]

I have a build working from latest master with Msys2, and I'm in 
progress of making notes to how to do it. Still haven't got python 
working ok as running Gimp gives me "Failed to execute child process (No 
such file or directory)" errors on every py script when launching, but 
I'll post my notes so far..


http://pastebin.com/ZHT2A4K5

Hopefully that helps.
(and I'm using WIn10, 64bit)

On 9.5.2016 13:03, Barney Holmes wrote:

Hi,

I've also been working on building Gimp for Windows simply because for one 
reason or another I have Windows on my main, faster machine, and I've wanted to 
get some of the latest bug fixes. I also wanted to fix - 
https://bugzilla.gnome.org/show_bug.cgi?id=757717

I tried the Linux cross compile using the wiki Mingw64 instructions. I was 
trying to retrieve the prebuilt library RPM's from, I think it's OpenSUSE, but 
that seems to be outdated. Now I have Code::Blocks setup to cross compile with 
MinGW-w64, I’ll try building those dependencies.

I'm investigating MSYS2. It looks like a good project and a lot of other 
projects seem to use it to provide releases for Windows, but its a slow to 
compile even with multiple threads set.  Some of those projects may use Python 
so they might be able to help with Python for Gimp.

I attach my current "autogen" and "make" outputs. I am building with most 
extras disabled as I just want to iron out the build process first.

http://files.djbarney.org/autogen_output.txt
http://files.djbarney.org/make_output.txt

Are you building from the main branch ?

Do you get a successful build with Python disabled ?

Cheers.

Sent from Mail for Windows 10

___
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-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] Windows builds using MSYS2

[Petteri Soininen]

Instructions to build Gimp 64bit with Windows/MSYS2/mingw64 seem quite 
outdated when trying to build 2.9.x.
I have struggled and learned much about the build process and probably 
could make an updated document "Howto"
I still struggle with Python support and I haven't been able to 
completely make python work as it seems to be a weird combination of 
64/32bit libraries and no good documentation anywhere and 
http://wiki.gimp.org/wiki/Hacking:Building/Windows just states that 
python support should be just disabled.
That is a 'no go' in my opinion as many plugins rely heavily on python 
and I'd like to make it easier for beginners, who use Windows, to 
compile builds and possibly contribute on testing and development.
I'm quite a n00b myself, but a fast learner. So if anyone could give me 
some pointers on how to make python plugins work with newer builds, I'd 
appreciate it very much and I'll try to make updated instructions for 
others to use.

___
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