Compiling a gimp plugin for Windows

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Compiling a gimp plugin for Windows

flamz
Hi list,
I have a quick question concerning developing a gimp plugin for Windows.
Do I need to recompile the entire application to get the .libs necessary to
link with or is there an "SDK-only" distribution somewhere (.h + .lib)?

I couldn't find compiled libgimp etc. anywhere and am kind of hoping I don't
have to recompile everything just to write a plugin.

Also, it would be nice if my plugin could somehow be "notified" when the
image has changed in some way. I was wondering if this was possible with the
current plugin architecture and if so, what kind of plugin would be better
suited to achieve this.

tx,
Dom


_______________________________________________
Gimp-developer mailing list
[hidden email]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Compiling a gimp plugin for Windows

Tor Lillqvist
Dominic Laflamme writes:
 > is there an "SDK-only" distribution somewhere (.h + .lib)?

As I happen to have a fresh build of GIMP 2.2, I guess I could provide
a such, if Jernej doesn't want to.

Get www.gimp.org/win32/gimp-2.2.8.zip. Please tell me if there is
anything missing in it. (It contains only gcc import libraries (.a
files), but you can generate Microsoft import libraries (.lib files)
from the .def files that are included.)

(Don't worry that the name has "2.2.8" in it, that's just because the
version number i CVS already has been bumped to 2.2.8. The headers and
import libs should work fine for older GIMP 2.2.x, too.)

--tml

_______________________________________________
Gimp-developer mailing list
[hidden email]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Compiling a gimp plugin for Windows

Tor Lillqvist
Tor Lillqvist writes:
 > Get www.gimp.org/win32/gimp-2.2.8.zip.

Oops, I meant gimp-dev-2.2.8.zip.

--tml

_______________________________________________
Gimp-developer mailing list
[hidden email]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Compiling a gimp plugin for Windows

Sven Neumann
In reply to this post by Tor Lillqvist
Hi,

Tor Lillqvist <[hidden email]> writes:

> Get www.gimp.org/win32/gimp-2.2.8.zip. Please tell me if there is
> anything missing in it. (It contains only gcc import libraries (.a
> files), but you can generate Microsoft import libraries (.lib files)
> from the .def files that are included.)
>
> (Don't worry that the name has "2.2.8" in it, that's just because the
> version number i CVS already has been bumped to 2.2.8. The headers and
> import libs should work fine for older GIMP 2.2.x, too.)

Tor, could you please consider to rename that zip file? Having files
with the 2.2.8 version floating around on gimp.org is IMO a very bad
idea.


Sven
_______________________________________________
Gimp-developer mailing list
[hidden email]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Compiling a gimp plugin for Windows

Tor Lillqvist
Sven Neumann writes:
 > Tor, could you please consider to rename that zip file? Having files
 > with the 2.2.8 version floating around on gimp.org is IMO a very bad
 > idea.

OK, done. It's now gimp-dev-2.2.7.zip.

--tml

_______________________________________________
Gimp-developer mailing list
[hidden email]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Compiling a gimp plugin for Windows

Tor Lillqvist
In reply to this post by Sven Neumann
Sven Neumann writes:
 > Having files with the 2.2.8 version floating around on gimp.org is
 > IMO a very bad idea.

(Hmm, but that version number is floating around publicly in CVS ;-)

This is an excellent opportunity to bring up an idea I have tried to
suggest a few times without success:

Currently some modules in GNOME CVS bump the micro version number
right after a source release. Others bump right before a release. And
some bump at a random time between releaes. This is IMHO confusing, as
can be seen from this case.

My idea is that the official policy would be to use both pre- and
post-release bumps. Only in a release tarball would the micro version
number be odd. As soon as the release has been done, the micro version
number would be bumped. And then immediately before making the next
release it would be bumped again. Then there would be no confusion. An
odd micro number would always indicate an official source release, and
an even micro number a CVS snapshot. Stuff built from CVS snapshots
could use the version number from CVS at the time without risking
being confised with the next official version.

--tml

_______________________________________________
Gimp-developer mailing list
[hidden email]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Compiling a gimp plugin for Windows

Sven Neumann
Hi,

Tor Lillqvist <[hidden email]> writes:

> Currently some modules in GNOME CVS bump the micro version number
> right after a source release. Others bump right before a release. And
> some bump at a random time between releaes. This is IMHO confusing, as
> can be seen from this case.
>
> My idea is that the official policy would be to use both pre- and
> post-release bumps. Only in a release tarball would the micro version
> number be odd. As soon as the release has been done, the micro version
> number would be bumped. And then immediately before making the next
> release it would be bumped again. Then there would be no confusion. An
> odd micro number would always indicate an official source release, and
> an even micro number a CVS snapshot. Stuff built from CVS snapshots
> could use the version number from CVS at the time without risking
> being confised with the next official version.

in my opinion this would only make things even more confusing. A CVS
snapshot should be clearly labelled as such, not implicitely by the
micro version number being odd or even. What about using something
like gimp-2.2.8-cvs-20050523.zip for cvs snapshots?


Sven
_______________________________________________
Gimp-developer mailing list
[hidden email]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Compiling a gimp plugin for Windows

Tor Lillqvist
Sven Neumann writes:
 > in my opinion this would only make things even more confusing.

How, exactly? Because the procedure for person doing a release would
be a few steps longer? Or because people would wonder why each other
version is missing when looking at some version history or ftp server
directory list?

 > What about using something like gimp-2.2.8-cvs-20050523.zip for cvs
 > snapshots?

Well, for Win32 distributions of GIMP stuff, where such files are
handled manually, and/or people have "out-of-band" knowledge that
2.2.8 wasn't released yet at 2005-05-23, that presumably is clear
enough.

But if one considers various Unix/Linux package management software,
do they understand that for some packages "2.2.8-cvs-20050523" is
earlier than "2.2.8", but on the other hand, for some other package,
"1.2.3-cvs-20050523" would be later than "1.2.3" ?

--tml

_______________________________________________
Gimp-developer mailing list
[hidden email]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Compiling a gimp plugin for Windows

Sven Neumann
Hi,

Tor Lillqvist <[hidden email]> writes:

> How, exactly? Because the procedure for person doing a release would
> be a few steps longer? Or because people would wonder why each other
> version is missing when looking at some version history or ftp server
> directory list?

How are people supposed to know about this versioning scheme? Not all
packages will use it; so how is a user supposed to know that even is
stable, odd is some cvs snapshot?

>  > What about using something like gimp-2.2.8-cvs-20050523.zip for
>  > cvs snapshots?
>
> Well, for Win32 distributions of GIMP stuff, where such files are
> handled manually, and/or people have "out-of-band" knowledge that
> 2.2.8 wasn't released yet at 2005-05-23, that presumably is clear
> enough.
>
> But if one considers various Unix/Linux package management software,
> do they understand that for some packages "2.2.8-cvs-20050523" is
> earlier than "2.2.8", but on the other hand, for some other package,
> "1.2.3-cvs-20050523" would be later than "1.2.3" ?

Well, then don't include a version number at all. That's how CVS
snapshots are typically labelled, by nothing but the date.


Sven
_______________________________________________
Gimp-developer mailing list
[hidden email]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Loading...