"Raw notes" from the LGM2009 BOF meeting

[Simon Budig]

Hi all.

I am sorry, but I forgot about the notes I took at the LGM2009 GIMP bof.

I'll just send them around in the state I took them during the BOF in
the hope that they are useful. If you have the impression that there is
stuff missing or that I misrepresent some of the discussions then please
feel free to comment.

Sorry for letting this slip.
        Simon

Roadmap 2008?
-------------

trying to do 2.8 before SOC 2010

* Merge vector layer branch
  - might need some work, especially in the UI
  - undo is broken
  --> mitch, nomis?
  --> End of May Univ.-Project with Peter, possibly Vector Layers?
  try to get it in 2.8.

* Polish/finalize new features
  - on canvas Text editing
  must have in 2.8.

  - tagging
  no real problems at the horizon.
  Internationalization? (Jon: CREATE-Discussion)
  Support for Default-Tags?
  Multi-Select-Tagging? --> later.
 

* Default Tags for Default ressources
  - Alexia + Rore are working on it / Data Extras
  not suggesting any specific workflows, purely descriptive
  also avoid culture-specific references.

* finishing Save & Export
  how to get a unified dialog?
  (GtkPlug/Socket? Sounds evil. Supported on Windows? No.) (Review of
  current plugins, which are the most important ones? can we come away
  with widget-descriptions, similiar to script-fu?)
  (we're trying for 2.8 --> Enselic)

* unified transform tool
    (optional for 2.8)

* Cairo Drawing on Canvas --> Sven?

--> so that we can do the unified transform tool?

* Summer of Code projects, integrate them into the codebase
  - python binding improvements (2008)

FFTW3 is a GPL library, so we have a licensing problem with
Frequency-Domain GEGL operations SOC, needs to wait for out-of-
process GEGL ops.

SOC 2009 final evaluation is on Aug. 24th
  - improved brush dynamics UI    --> alexia
  - improved foreground selection

GEGL performance improvements (!)
  - API is stable
  - Gimp doesn't use GEGL in a good way.
  - second view with gegl widget?
  - nobody currently working on it
  - not relevant to the 2.8 release

Other SOC projects are basically about GEGL and don't directly affect
GIMP.




----------------------------------------
Stani: Python 3.0: any plans?
   - there will be differences
   - depends also on pygtk et al.

Stani: Buffer-protocol for Gimp?
   - also in Python 2.6
   - Joao wants to include the SOC2008-Python-Code into mainline
   - separate module to not have to depend on python 2.6


--
              simon@...              http://simon.budig.de/
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Martin Nordholts-2]

Simon Budig wrote:
> * finishing Save & Export
>   how to get a unified dialog?
>   (GtkPlug/Socket? Sounds evil. Supported on Windows? No.) (Review of
>   current plugins, which are the most important ones? can we come away
>   with widget-descriptions, similiar to script-fu?)
>   (we're trying for 2.8 --> Enselic)
>  

Just a few updates on this. There will be no need for complex IPC
communications between the plug-ins and the core with regards to the UI,
the UI will simply live in the process of the plug-in, and we will
extend libgimp with means to create this UI so that it gets a unified
look between different plug-ins. Also, we don't need to port all
plug-ins, only the frequently used ones. We need to be backwards
compatible anyway so no need in converting the obscure plug-ins to use
the new UI.

 / Martin
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Sven Neumann]

Hi,

On Thu, 2009-06-18 at 18:52 +0200, Martin Nordholts wrote:

> Just a few updates on this. There will be no need for complex IPC
> communications between the plug-ins and the core with regards to the UI,
> the UI will simply live in the process of the plug-in, and we will
> extend libgimp with means to create this UI so that it gets a unified
> look between different plug-ins. Also, we don't need to port all
> plug-ins, only the frequently used ones. We need to be backwards
> compatible anyway so no need in converting the obscure plug-ins to use
> the new UI.

Whenever we introduce new API that replaces old API, we deprecate the
old API. And of course we will also port all our plug-ins to the new
API, if only as guidance for plug-in authors. That is absolutely
necessary, but it is also not a problem. So far we have always found a
volunteer for such jobs. The hard part is getting the new API right. So
what we need at this point is an API proposal. Is anyone working on
this?


Sven


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Martin Nordholts-2]

Sven Neumann wrote:
> So
> what we need at this point is an API proposal. Is anyone working on
> this?
>  

Nope not yet, but I will do it eventually unless someone else does it.
Currently I don't have the time.

 / Martin

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer