Re: [Gimp-developer] "X" stuck on to start of all libtool options...
Conclusion: The issue was, I had somehow managed to install a copy of the various autotools in /usr/local/ and they were being used instead of the ones in /usr/. My solution was simply to delete those binaries. GIMP is now happily compiling :) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] developer with spare time.
On Tue, Jan 11, 2011 Øyvind Kolås wrote: > http://git.gnome.org/browse/gegl/tree/operations/ (GEGL plug-in ops) > ... http://git.gnome.org/browse/gimp/tree/app/gegl (GEGL ops statically > compiled into GIMP) Note these two ways of creating GeglOperation subclasses lead to almost exactly the same compiled code, the first one uses custom C-preprocessor macros to avoid the boiler plate needed to define GObject subclasses and properties. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] developer with spare time.
On Tue, Jan 11, 2011 at 5:47 PM, andy gill wrote: > That certainly looks like something I could help with. Is there a priority > list of missing operations, or is it more a case of just going through the > gimp filters one by one? Is it the final intention that all gimp filters > will be implemented by gegl one day? Yes, the expectation is that one day all the code that directly modifies pixel values are GeglOperations, when it comes to core (non-plugin) functionality a lot of this migration has already been done and can be seen in http://git.gnome.org/browse/gimp/tree/app/gegl /Øyvind Kolås -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] developer with spare time.
That certainly looks like something I could help with. Is there a priority list of missing operations, or is it more a case of just going through the gimp filters one by one? Is it the final intention that all gimp filters will be implemented by gegl one day? Andy. On 11 January 2011 17:13, Øyvind Kolås wrote: > On Tue, Jan 11, 2011 at 4:19 PM, andy gill wrote: > > Hello, I'm a coder with some spare time, wondering how to spend it. > > Are there any jobs that could be usefully picked up by someone who isn't > one > > of the core developers? > > One thing that will prove beneficial in the future, is the porting > more of the plug-ins GIMP ships with by default to also be available > GEGL ops. (thus preparing for the time when GIMP is internally using > GeglBuffers and having >8bpc ways of processing is more important. > > Looking at various files in common/ and other subdirectories of > http://git.gnome.org/browse/gegl/tree/operations/ should provide a > guide to how such ops can be implemented. > > Such contributions would be completely self-contained and thus not > need any changes to infrastructure. > > Such ops would at first only be available through the GEGL tool with > automatically constructed property UIs. I expect at some point that > there will also be seperatly loadable plug-ins providing custom UIs > for specific GEGL ops. (This is something I believe might belong in > GIMP not GEGL; or perhaps even in a gegl-gtk-ui convenience library). > > /Øyvind K. > -- > http://pippin.gimp.org/ > ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] developer with spare time.
On Tue, Jan 11, 2011 at 4:19 PM, andy gill wrote: > Hello, I'm a coder with some spare time, wondering how to spend it. > Are there any jobs that could be usefully picked up by someone who isn't one > of the core developers? One thing that will prove beneficial in the future, is the porting more of the plug-ins GIMP ships with by default to also be available GEGL ops. (thus preparing for the time when GIMP is internally using GeglBuffers and having >8bpc ways of processing is more important. Looking at various files in common/ and other subdirectories of http://git.gnome.org/browse/gegl/tree/operations/ should provide a guide to how such ops can be implemented. Such contributions would be completely self-contained and thus not need any changes to infrastructure. Such ops would at first only be available through the GEGL tool with automatically constructed property UIs. I expect at some point that there will also be seperatly loadable plug-ins providing custom UIs for specific GEGL ops. (This is something I believe might belong in GIMP not GEGL; or perhaps even in a gegl-gtk-ui convenience library). /Øyvind K. -- http://pippin.gimp.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] developer with spare time.
Hello, I'm a coder with some spare time, wondering how to spend it. Are there any jobs that could be usefully picked up by someone who isn't one of the core developers? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] translate menu mod
On 1/11/11, Alexia Death wrote: > anything up. If you use strings that have translations in their > original location, you may even get translation working, tho Im not > sure how script-fu and localization interact specially in regard to > lables. Checboxes and suchlike in FX Foundry scripts dialogs are partly translated, because some messages ara translated in po-script-fu/*.po. Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] translate menu mod
On Tue, Jan 11, 2011 at 2:15 AM, Ek kian wrote: > i only create new "Photo" menu where consist of many photography related > functions, > to speed up our workflow on editing photo rather than jumping around on the > menu. You are maybe better off creating this menu using script-fu. That would allow for very easy deployment in vanilla gimp and woudnt mess anything up. If you use strings that have translations in their original location, you may even get translation working, tho Im not sure how script-fu and localization interact specially in regard to lables. But since the menus do contain localized script names, it should be supported. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
