Re: [Gimp-developer] Weekly Progress Report on GIMP development
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 ([EMAIL PROTECTED]) wrote: > > Simon Budig wrote: > > > Sven Neumann ([EMAIL PROTECTED]) 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. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Weekly Progress Report on GIMP development
David Neary ([EMAIL PROTECTED]) wrote: > Simon Budig wrote: > > Sven Neumann ([EMAIL PROTECTED]) 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 -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Weekly Progress Report on GIMP development
Simon Budig wrote: > Sven Neumann ([EMAIL PROTECTED]) 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... Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Weekly Progress Report on GIMP development
Hi, Simon Budig <[EMAIL PROTECTED]> writes: > Sven Neumann ([EMAIL PROTECTED]) 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? I forgot to mention that it would be nice to add PDB APIs for text and vectors. These would of course be wrapped in libgimp so perhaps the API isn't finished yet. But these would be additions and thus not break any plug-ins. What I was refering to here mainly is that plug-in authors shouldn't expect more majpr API changes. Mitch mentioned today that he'd like to change the GimpFileSelection API. I understand the need for this and since only few plug-ins use it, it wouldn't break many. The plan is however to not do anymore changes (despite perhaps additions) to the libgimp* APIs after the next development release which is scheduled for this weekend. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Weekly Progress Report on GIMP development
Sven Neumann ([EMAIL PROTECTED]) 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? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Weekly Progress Report on GIMP development
Hi, a week has gone by since the last progress report so it's about time for a short update on what has changed in GIMP CVS. - Yosh added new functions to libgimpwidgets that provide a 64bit clean interface for option menus and radio groups. This fixes bug #125142. - 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. - Mitch went over the core and all plug-ins and unified user-visible strings, focusing on error messages. This reduces the work for translators. Also lots of newlines have been removed from these strings. We let the message dialog do the line breaks now. - Session management now handles multiples screen. If you move a dock away from the default screen, GIMP will remember this in your sessionrc and will try to reopen it there the next time. Finally you can seriously work with two or more screens. - The image window and popup windows such as menus now position and size itself by looking at the geometry of the current monitor instead of using the screen size. This makes GIMP behave a lot better on Xinerama setups where one screen goes over multiple monitors. - The small theme I talked about in my last report has landed in CVS. - Some work has been done on cleaning up the application lifecycle. The idea is that it should be possible to initialize GIMP, use it for a while, then release all resources and start all over again. This is somewhat academic but it already helped to find some possible problems. You might notice that quitting GIMP takes a little longer now. This is because we actually release all resources instead of simply calling exit(). We might add back the call to exit() for the 2.0 release. - Mitch changed how GtkFileSelector is being used. This is in preparation of a migration to the new GtkFileChooser widget from GTK+ HEAD. The idea is to provide a patch for GIMP that makes it use the new widget so that problems with the new API can be identified early and fixed before the GTK+ API is frozen for 2.4. - Hans fixed some Win32 problems and updated the MSC makefiles. - Some more progress has been made on documenting the GIMP libraries and the application itself. Quite a few bugs have been fixed. Bugzilla talks about 24 bugs closed during the last week, 17 of these were resolved by actually fixing the code. The other 7 were duplicate or invalid reports. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
