Hi Monis, is: gimp_path_get_point_at_dist working like the old one? I have a really cool script that renders a POV-ray sweep alogn a path that uses this. It will work in 2.0, or I will have to keep 1.2 around. :-) Anyway, I cannot spare time right now to write PDB's :-( (I had done it once, and might do again), but I will see if I can send you a more detailed e-mail on the process soon. Regards, JS -><- On Thursday 20 November 2003 21:31, Simon Budig wrote: > David Neary (bolsh@xxxxxxxx) wrote: > > Simon Budig wrote: > > > Sven Neumann (sven@xxxxxxxx) wrote: > > > > - A couple of other issues with the libgimp* APIs have been > > > > resolved. The APIs should be ready for GIMP-2.0 now. Only > > > > the addition of libgimpthumb is still missing in CVS. > > > > > > With the notable exception of vectors stuff. Or did I miss > > > something? > > > > Whatr changes to the vector tool will require libgimp API changes > > before 2.0? I wasn't aware of any... > > It is not the *Tool* itself, it is the vectors infrastructure. > > The Problem is, that the new vectors infrastructure provides more > functionality than the old stuff. The compatibility API works with > the new infrastructure, but is limited to the old functionality, > in particular you cannot create a vectors object with multiple open > strokes in it (Look at gimp-path-set-points: BEZIER_MOVE not only > moves to a new location, but also closes the previous segment). > > So we need a new API that makes it possible to create that kind > of vectors via PDB. Since we internally already have functions > like bezier_stroke_new_moveto, bezier_stroke_curveto, > bezier_stroke_arcto, etc. it would be nice to have them available > for plugins too, since they make creation of bezier strokes really > easy. > > I think I failed to communicate that properly, but I always > considered this to be part of the new vector stuff - and this is > the IMHO last part that is missing. I am scared a bit, because I > have no real idea how that PDB stuff works. > > I hope this makes it clear what is wrong there. > > Oh, I forgot: > > Functionality-wise also missing is a GUI for the dashed strokes, > but a) it is probably fairly easy and b) we might be able to live > without it... > > I think I should describe what I have in mind for the UI, if > someone wants to pick that up I'd be very happy about that. > > The description of a dashed stroke is an array of doubles: > length stroke, length gap, length stroke, length gap, etc. > > the unit of these floats is the width of the stroke, this has the > nice property, that it is scaling independant. > > The Widget to define this could look like this: > > [==== =========== == ===== ] > > and you can paint with the mouse into it - either simply flip the > pixels between black and white where the mouse gets dragged over, > or stick to black/white painting when clicking on a white/black > pixel. > > The widget should be able to provide the doubles mentioned above, > maybe we need to two additional value-entries for overall > dash-pattern length and the dash-offset at the beginning of the > stroke. > > Any takers? > > Bye, > Simon -- Este e-mail é, exceto pelas partes citadas de outros e-mails, copyright(c) de João Sebastião de Oliveira Bueno. Nenhuma cópia deste e-mail ou parte do mesmo pode existir nas dependências de, ou em posse de funcionários, de associações protetoras de direitos autorais Brasileiras, dos Estados Unidos da América, ou de outros países. Em particular essa exceção do direito de leitura e posse deste e-mail se extende à ABRA, ABPI, ABES, BSA, RIAA e MPAA. Violadores estão infringindo as leis internacionais de direitos autorais e sujeitos às penalidades cabíveis. Você pode re-utilizar, emendar, acrescentar suas palavras e citar e re-enviar qualquer parte do mesmo, desde que essa nota seja preservada e se não pertencer a alguma das entidades supracitadas.
