Hey all,
Anything in particular people are looking to add or refactor which they haven't discussed yet? Development has greatly slowed and I am curious if it's related to lack of interest, time, or people not wanting to hold up a possible release by adding new features. Note, a release is unfeasible at this time anyway, so we're really still game for new code currently. Related to this, Tavmjong's gradient mesh branch is pretty nice (and still has bugs) atm... if anyone is interested in helping out with it, please let him know. It would be awesome if we could see that work stabilized and available in the next release. Just checking in...
Cheers, Josh
On Sun, 2011-12-04 at 23:16 -0800, Josh Andler wrote:
Hey all,
Anything in particular people are looking to add or refactor which they haven't discussed yet? Development has greatly slowed and I am curious if it's related to lack of interest, time, or people not wanting to hold up a possible release by adding new features. Note, a release is unfeasible at this time anyway, so we're really still game for new code currently. Related to this, Tavmjong's gradient mesh branch is pretty nice (and still has bugs) atm... if anyone is interested in helping out with it, please let him know. It would be awesome if we could see that work stabilized and available in the next release. Just checking in...
I definitely could use some help! There are really two separate items that need to be tackled:
The first is the actual implementation of the gradient meshes. This includes figuring out the best way to integrate meshes with the existing linear/radial gradient implementation which uses two separate gradient elements, one for the "vector" of colors and one for the geometric positioning. It also includes work on the user interface and on exporting the mesh to PDF, etc.
The second is how Inkscape should handle items that are not yet in a published specification. This is not just a mesh gradient issue. There are a bunch of interesting things coming up in SVG 2 that would be nice for Inkscape to implement. One key one is solid colors (or named colors, borrowed from the SVG 1.2 Tiny spec). This will eliminate the need to to use one-stop gradients for custom palettes (and hopefully simplify our code). We will probably need to keep new things temporarily in the Inkscape name space and then choose an SVG "level" when saving the file: SVG1.1, SVG2_experimental, SVG2. We don't want to be burned again by the flowed text issue from the dead SVG 1.2 Full spec.
Tav
On 05-12-11 10:05, Tavmjong Bah wrote:
... The second is how Inkscape should handle items that are not yet in a published specification. This is not just a mesh gradient issue. There are a bunch of interesting things coming up in SVG 2 that would be nice for Inkscape to implement. One key one is solid colors (or named colors, borrowed from the SVG 1.2 Tiny spec). This will eliminate the need to to use one-stop gradients for custom palettes (and hopefully simplify our code). We will probably need to keep new things temporarily in the Inkscape name space and then choose an SVG "level" when saving the file: SVG1.1, SVG2_experimental, SVG2. We don't want to be burned again by the flowed text issue from the dead SVG 1.2 Full spec.
To add to this, in particular I think we want to avoid doing it one way, then seeing it done another way in SVG 2 and ending up in a kind of limbo.
Hi Josh,
I've been pretty busy at work lately, so I haven't had time to do much. I'm working on backporting some of the recent bug fixes to the downstream Ubuntu package, so hopefully this should help with 0.48.3/0.49 pre-release testing. I'll also (finally) sort out the upstream stable PPA in the near future, I hope.
From my perspective, as an inkscape-dev novice, I find it pretty
difficult to get involved with the development of new features because I'm not really familiar enough with the Inkscape source or gtk+. Although there is a nice to-do list of simple coding tasks[1] and a development roadmap,[2] it's possibly worth noting that there are currently only six blueprints and ~25 unfixed bugs actually tied to the 0.49 release. Personally, I'd find it much easier to get heavily involved in the project if (a) it's clear exactly what is required for each release and (b) there's an indication of how difficult each task is. Perhaps, therefore, it would be worth making more use of blueprints and targeting bugs/wishlist items to the forthcoming release so that we can more easily see our progress, and the light at the end of the tunnel. Also, some projects use a "bitesize" bug tag to indicate the easy items. This might be more maintainable/accessible than the current wiki page?
Best wishes,
AV
[1] http://wiki.inkscape.org/wiki/index.php/Janitorial_tasks [2] http://wiki.inkscape.org/wiki/index.php/Roadmap
On 5 December 2011 07:16, Josh Andler <scislac@...400...> wrote:
Hey all,
Anything in particular people are looking to add or refactor which they haven't discussed yet? Development has greatly slowed and I am curious if it's related to lack of interest, time, or people not wanting to hold up a possible release by adding new features. Note, a release is unfeasible at this time anyway, so we're really still game for new code currently. Related to this, Tavmjong's gradient mesh branch is pretty nice (and still has bugs) atm... if anyone is interested in helping out with it, please let him know. It would be awesome if we could see that work stabilized and available in the next release. Just checking in...
Cheers, Josh
All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2011/12/5 Alex Valavanis <valavanisalex@...400...>:
Hi Josh,
I've been pretty busy at work lately, so I haven't had time to do much. I'm working on backporting some of the recent bug fixes to the downstream Ubuntu package, so hopefully this should help with 0.48.3/0.49 pre-release testing. I'll also (finally) sort out the upstream stable PPA in the near future, I hope.
From my perspective, as an inkscape-dev novice, I find it pretty
difficult to get involved with the development of new features because I'm not really familiar enough with the Inkscape source or gtk+. Although there is a nice to-do list of simple coding tasks[1] and a development roadmap,[2] it's possibly worth noting that there are currently only six blueprints and ~25 unfixed bugs actually tied to the 0.49 release. Personally, I'd find it much easier to get heavily involved in the project if (a) it's clear exactly what is required for each release and (b) there's an indication of how difficult each task is. Perhaps, therefore, it would be worth making more use of blueprints and targeting bugs/wishlist items to the forthcoming release so that we can more easily see our progress, and the light at the end of the tunnel. Also, some projects use a "bitesize" bug tag to indicate the easy items. This might be more maintainable/accessible than the current wiki page?
Best wishes,
AV
[1] http://wiki.inkscape.org/wiki/index.php/Janitorial_tasks [2] http://wiki.inkscape.org/wiki/index.php/Roadmap
I second this (thanks for the links Alex).
Something else, I noticed a memory leak when opening the object properties window. Frequently 40-70 kB of memory seems to be consumed and not released. Steps I used: - create a rectangle and select it - repeatedly: - click on the right-mouse button and select Object Properties - close the object properties window
When I look into the code, it seems to be due to the call to sp_attribute_table_set_object via sp_attribute_table_new. I can not exactly point out where the leak occurs, though when I see the files sp-attribute-widget.cpp and sp-attribute-widget.h, I thought about refactoring these files. If possible I'd like to: - refactor SPAttributeWidget and SPAttributeTable to real cpp classes derived from gtk::widget - get rid of the double pointers **attributes and **entries (making use of std::vector) - making use of std::string as opposed to c type strings (or is Glib::ustring better?)
Anyone working on this (sp-attribute-widget.cpp, object-attributes.cpp)? Any comments? And in case of troubles anyone who can help me?
Regards K
---- Alex Valavanis <valavanisalex@...400...> wrote:
Hi Josh,
From my perspective, as an inkscape-dev novice, I find it pretty
difficult to get involved with the development of new features because I'm not really familiar enough with the Inkscape source or gtk+. Although there is a nice to-do list of simple coding tasks[1] and a development roadmap,[2] it's possibly worth noting that there are currently only six blueprints and ~25 unfixed bugs actually tied to the 0.49 release. Personally, I'd find it much easier to get heavily involved in the project if (a) it's clear exactly what is required for each release and (b) there's an indication of how difficult each task is. Perhaps, therefore, it would be worth making more use of blueprints and targeting bugs/wishlist items to the forthcoming release so that we can more easily see our progress, and the light at the end of the tunnel. Also, some projects use a "bitesize" bug tag to indicate the easy items. This might be more maintainable/accessible than the current wiki page?
For this, I recently asked ~suv to add the "easy-fix" tag to bugs she thinks are easy to fix.
Cheers, Johan
New thread coming related to a possible IRC meeting. We definitely have people who want to contribute more, but who would prefer other eyes and or brains to help with figuring out solutions. If we could get some more experienced inkscape devs together with some of our newer and/or less experienced devs it could be a big win-win.
Cheers, Josh
On 06-12-11 23:12, Josh Andler wrote:
New thread coming related to a possible IRC meeting. We definitely have people who want to contribute more, but who would prefer other eyes and or brains to help with figuring out solutions. If we could get some more experienced inkscape devs together with some of our newer and/or less experienced devs it could be a big win-win.
Excellent suggestion. Also, perhaps it's becoming time to have a face-to-face meeting with the explicit intention of mixing up old and new developers? (During a weekend or so of coding and discussing ideas?)
Issues like this also came up during the GSoC mentor summit (we're definitely not the only project with this kind of issue). Two of the ideas that came from that discussion are:
1. Make it easier to get started with coding. If you only contribute now and then it can take a while to make sure you have the latest check out and dependencies, and that the build system is up-to-date and working again. One idea that was presented is to create a small VM that contains everything you need to get started with coding, preferably including the latest source (perhaps even compiled and ready to go). I have looked into this and think that PuppyLinux might be a good starting point, but I haven't gotten around to customizing it yet. Another interesting project is Vagrant (vagrantup.com).
2. A developer-announce mailinglist. This should be a very low volume list that is used to keep people up-to-date on changes in the build system and so on. To be honest I'm not sure this is currently really needed for Inkscape, as the list is pretty low volume anyway, but it might make it easier for people who only pay casual attention to the list to pick up on important changes.
I also think it would be great if we could keep closer tabs on our unit and rendering tests. It is often relatively easy to fix failures (and especially regressions) in such tests, and it is quite important to do so. So if anyone has either the facilities to run these on a regular basis (or knows how to get them) or the time to set them up so that they are run regularly and the results presented in a sane fashion (so without the Ajax crap I put together), that would be great.
On Wed, Dec 7, 2011 at 1:06 AM, Jasper van de Gronde < th.v.d.gronde@...528...> wrote:
On 06-12-11 23:12, Josh Andler wrote:
New thread coming related to a possible IRC meeting. We definitely have people who want to contribute more, but who would prefer other eyes and or brains to help with figuring out solutions. If we could get some more experienced inkscape devs together with some of our newer and/or less experienced devs it could be a big win-win.
Excellent suggestion. Also, perhaps it's becoming time to have a face-to-face meeting with the explicit intention of mixing up old and new developers? (During a weekend or so of coding and discussing ideas?)
I think this should be discussed during the irc meeting. I keep trying to push for a f2f meeting/mini-hackfest and the board has previously stated support for sponsoring such an event. I think it's tough trying to coordinate though. If anything, I think we should plan in advance to give everyone the ability to plan for it and it wouldn't hurt to tie it to a relevant conference such as LGM or SVG Open if there's interest.
- Make it easier to get started with coding.
If you only contribute now and then it can take a while to make sure you have the latest check out and dependencies, and that the build system is up-to-date and working again. One idea that was presented is to create a small VM that contains everything you need to get started with coding, preferably including the latest source (perhaps even compiled and ready to go). I have looked into this and think that PuppyLinux might be a good starting point, but I haven't gotten around to customizing it yet. Another interesting project is Vagrant (vagrantup.com).
Very interesting idea. I think it would be interesting to explore, but I would just want to make sure all dependencies are met for "all-feature" builds.
- A developer-announce mailinglist.
This should be a very low volume list that is used to keep people up-to-date on changes in the build system and so on. To be honest I'm not sure this is currently really needed for Inkscape, as the list is pretty low volume anyway, but it might make it easier for people who only pay casual attention to the list to pick up on important changes.
I've entertained the idea in the past, primarily for around release time with people getting notification of when commits are to be restricted. However, as you mention with the volume of the current list, this is why I haven't felt the need to pursue it.
I also think it would be great if we could keep closer tabs on our unit
and rendering tests. It is often relatively easy to fix failures (and especially regressions) in such tests, and it is quite important to do so. So if anyone has either the facilities to run these on a regular basis (or knows how to get them) or the time to set them up so that they are run regularly and the results presented in a sane fashion (so without the Ajax crap I put together), that would be great.
Agreed. In addition, I think we need to semi-regularly ensure that make check passes to relieve burden on Ted at release time.
Cheers, Josh
participants (6)
-
unknown＠example.com -
Alex Valavanis -
Jasper van de Gronde -
Josh Andler -
Kris De Gussem -
Tavmjong Bah