- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Intel Aqua packaging
by ~suv 09 Apr '10

09 Apr '10

On 8/4/10 13:40, Lloyd Sargent wrote: > Okay, I went back and looked at the build info and I've found two problems: > > #1. > <...> > The following build commands failed: > ScriptExec: > ProcessPCH /var/folders/D+/D+KS42xe2RWRN++1YwAjD++++TI/-Caches-/com.apple.Xcode.501/SharedPrecompiledHeaders/ScriptExec_Prefix-fufpslfnljyhqverjsxrfdvyqeus/ScriptExec_Prefix.pch.gch ScriptExec_Prefix.pch normal ppc c com.apple.compilers.gcc.4_2 > ProcessPCH /var/folders/D+/D+KS42xe2RWRN++1YwAjD++++TI/-Caches-/com.apple.Xcode.501/SharedPrecompiledHeaders/ScriptExec_Prefix-ewyzzpalxmpnnsapxxvoyqkdnuir/ScriptExec_Prefix.pch.gch ScriptExec_Prefix.pch normal i386 c com.apple.compilers.gcc.4_2 > (2 failures) See my earlier answer to Stuart: On 22/3/10 14:00, ~suv wrote: > Yes, the lack of MacOSX10.4u.sdk is obviously significant for the > available xcodeproject of the application launcher. Please be aware that > the release version 0.47 was not built on Snow Leopard, nor are the > current development snapshots built on Snow Leopard. I.e. you are trying > to do something new that seems to require part of the packaging modules > to be modified and updated to run on OS X 10.6 Snow Leopard. > > I recommend to file a bug report, detailing the SL related errors you > see when trying to package the application. Please include all relevant > information about your OS and Xcode version. I'm not familiar with Xcode projects and don't know what changes are needed to compile 'ScriptExec' on Snow Leopard. Earlier in this thread it was mentioned to use gcc 4.0 instead of gcc 4.2 when employing the MacOSX10.4u.sdk on SL, but I don't know which changes you'd have to make to which files to change the compiler for the Xcode project only (you don't want to downgrade the compiler when building MacPorts or Inkscape itself). Looking at your error messages I see two issues to be addressed: 1) carbon vs cocoa (i.e. has anyone tried to create a new application launcher - ScriptExec - based on a current version of Platypus that might build with the 10.5 or 10.6 SDK?) 2) Universal build for PPC/i386 as target? (i.e. do we need 'ScriptExec' to be built Universal on Snow Leopard, and if so, does it need to support PPC - considering that SL doesn't run on PPC arch - or should the (platypus) launcher application be built either as Universal i386/x86_64 or as x86_64 only on Snow Leopard?). > #2 > > cp: /opt/local/etc/pango/pangox.aliases: No such file or directory > > Which makes sense as I have no pangox.aliases... what package would > this be from. I've built and installed pango, so that's not the problem... Has been answered in this thread already: the file is installed by pango when compiled with support for the X font backend. AFAICT the file is not needed when using Inkscape with GTK+/Quartz and both the packaging scripts and the application launcher script put inside the application package will have to be adapted to not look for this file when building/launching Inkscape without X11: On 22/3/10 14:00, ~suv wrote: > The GTK+/Quartz (so-called "Aqua") version will also require changes to > both the build scripts and the launcher scripts - but this should be > handled in a separate bug report, similar to the one Wolf filed for > removing the code launching X11 on Tiger. ~suv

3 4

Hello Inkscape Developers
by Peter Boström 08 Apr '10

08 Apr '10

Hello! I thought I'd finally send out a word or two and introduce myself. My name is Peter, I'm a second-year computer-science student at the Royal Institute of Technology here in Sweden. I've been programming casually for a few years before school, but most things I've done have either been simple or been abandoned. Though as a last-year project for high school, I made a simple fast Guitar-Hero clone in C. I'm also currently working on a game with a friend, which is slowly coming together. I'm making a proposal with Google Summer of Code to create a new New-From-Template dialog. I think Inkscape has a good interface, and it's one that I'd definitely want to help improve. Without previous experience with the code base, it's also a project that I find feasible to finish. A template menu, I think, is a good thing, so it's a part that I'd want to keep. I just think it needs to become structured into categories as well. So if you just need a static template for a CD, you can go to New.. -> Covers -> CD. In case this proposal gets accepted, I'd want to regularly provide something for feedback, either from this list or a mentor, wherever suitable. I think the interface is important, so this needs to be something that everyone would find easy to use. Also, I'm very interested any ideas you may have. (: Best to mention: I submitted a patch that resolves the following wishlist ticket: https://bugs.launchpad.net/inkscape/+bug/43730 This patch reports export results to the main window status bar. To have it report properly, I had to change sp_export_png_file's return type, as suggested, to an enum. It now returns EXPORT_OK, for a successful export, EXPORT_ERROR=0 for an error, and EXPORT_ABORTED for a canceled overwrite. I think it's a good change, because it makes this dialog more verbose. I hope you agree. Existing code checks for a false value, if(! sp_export_png_file...), which still works, same as before. I'd be happy to answer any and all questions you might have! Best regards - Peter Boström

1 0

Re: [Inkscape-devel] Intel Aqua packaging
by ~suv 08 Apr '10

08 Apr '10

On 8/4/10 05:50, Lloyd Sargent wrote: > 1. Macports installed at /opt/local > > 2. DYLD_LIBRARY_PATH was uncommented. > > With the above I get the same error as the OP (worse I had to make sure > the 10.4 SDK was installed). > > So something else is going South. Any suggestions? I don't know what error you are referring to - it might help if you attach the crash log / console messages (but I haven't built the +quartz version myself nor am I using Snow Leopard - which I assume you do since you mention the 10.4 SDK optional install?) ~suv

1 0

Mac OS X: osx-dmg.sh - osascript: dmg_set_style.scpt
by Wolf Drechsel 08 Apr '10

08 Apr '10

Hello everybody, I tried to dmg inkscape 047 X11 - but ended up with an image, which contains a link to /Applications and a folder called "Contents" - which seems not to be a .app bundle. When running the osx-dmg.sh, I get the message: osascript: dmg_set_style.scpt: No such file or directory In fact, the dmg_set_style.scpt cannot be found on my machine, it looks as if it were contained by earlier source packages and dropped recently. Could somebody be so kind and mail me the script - or - in the case - guide me to another solution of that problem. Yours, Wolf

6 21

Document versioning (was: Coordinate system fix)
by Krzysztof Kosiński 08 Apr '10

08 Apr '10

W dniu 6 kwietnia 2010 18:31 użytkownik bulia byak <buliabyak@...400...> napisał: > 2010/4/6 Krzysztof Kosiński <tweenk.pl@...400...>: >> W dniu 6 kwietnia 2010 15:33 użytkownik bulia byak >> <buliabyak@...400...> napisał: >>> This sounds inevitable, but rather hairy. Why have both >>> inkscape:version and inkscape:document-version? Can you get what you >>> need with inkscape:version only? >> >> 1. Document version changes must be atomic, because the upgrade is >> conducted only one time for each type of defect. This means >> inkscape:document-version (or inkscape:document-format) can change >> several times between two releases. > > But why can't we just fix ALL the defects we find between 0.47 and > 0.48 and have just two states of upgrade for <=0.47 and for >=0.48? The upgrade procedure must run exactly once for any document. This means that if we introduce a change in the interpretation of XML between revision FOO and FOO+1, then FOO+1 must perform the upgrade on documents saved in FOO and earlier, but it must also be smart enough not to upgrade documents saved with FOO+1. That's true regardless of how many defects are fixed in each version or how many document formats there are. This means the version number must be accurate down to a single revision, which is a bad idea for reasons I've already mentioned. If we have only the bare version number (e.g. 0.47 or 0.48), then anything saved in FOO+1 or later cannot be opened until we make a stable release. It would be possible to have the document format version number equal to the Bazaar revision in which it was first introduced. However, this would complicate working on the backwards compatibility fixes in branches. I think a simple number increasing from 1 would be the best way to go. This is hairy, possibly tedious to implement, etc., but at the same it's the long-term solution. Regards, Krzysztof

6 18

Bug Hunt Update - 93/300
by Joshua A. Andler 07 Apr '10

07 Apr '10

Hey all, Here is the current Bug Hunt scoring. I'm starting the count as of 3/29. Following past traditions, here is how it works: Scoring: Low: 3 pts Med: 6 pts High: 9 pts Critical: 12 pts Double if over one year old. Only fixes to "true bugs" (i.e. no website/translation/docs/etc. bugs). This list contains fixes between 3/29 - 4/7 @ 2:22pm PST. Pts BugID Fixer Description ------------------------------------------------------------------------ 3 520532 Kosiński Single app for GUI and console mode on Windows 12 215020 Kosiński Win32 - DOS/Command window pops up when... 12 168557 Jon Cruz Fill & Stroke dialog randomly stops updating.. 9 544833 Jon Cruz Crash in SVG font editor on "New" 6 541956 Kosiński comandline option don't work on win xp 6 522327 Daniel_J Inkscape 0.47 fails to build with GCC 4.5 3 554109 Kosiński unwanted printout of PYTHONPATH (Win32) 12 167455 Kosiński WinXP2: Command line file names not current... 9 551433 Kosiński inkex.py not found for extensions in user's... 6 553911 Jon Cruz Inkscape hangs when selecting CJK fonts in... 6 556233 Jon Cruz 'Rows and Columns' dialog fails when used... 3 548918 Alvin Penner HPGL output scaling incorrect 6 512447 Alvin Penner save as in DXF format fails in 0.47 ------------------------------------------------------------------------

1 0

GSOC proposal - Improve GUI for transformation center
by Zhenfeng Zhao 07 Apr '10

07 Apr '10

Hello, I appreciate all suggestions and technical details from you as to the “transformation anchor” project. I have summarized them into a proposal in the following. There is plenty of information for the project goal and plan. Later discussion, confirmation on tasks, and further input may help me to keep in the right track in the implementation. So far, the project and its tasks seem clear enough to me. And, according to my experience, I can see that this project can be done. As well, if there is any time left (I guess there would be), I would like to work on adjusting origin of document coordinates, and allowing math operations for spin boxes. The beginning of April is often the busiest time for students in Canada. It will be much better in the summer (May to August). Last year, I completed a 10+ page proposal for Gimp in the last day. This year, I am slightly earlier, after talking in Inkscape mailing list for half a month. Your feedback will be welcome and important. Then, I will submit the proposal very soon, or I will revise it there. Thank you very much. Regards, Zhenfeng. GSOC proposal - Improve GUI for transformation centers >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> PROJECT SUMMARY (a longer abstract) There are some existing issues with selecting and modifying the transformation center. This project focuses on improving and modifying GUI for transformation centers to solve existing issues and enhance precision and flexibility. In the three month GSOC period, first I will discuss with Inkscape designers and decide a GUI mockup as an implementation guide. With the further analysis and detailed plan, possible refactoring will be done. A control of precision of moving the transformation center will be implemented. Center coordinates would be set numerically. There will be a 9-button-matrix widget that is used to quickly move the center to 9 positions, and a separate tab in the Transform dialog, for adding XY fields using a couple spin-buttons for X and Y. Then, the linkage between the 9-button-widget and the spin-buttons can be done. Another relevant projects will be analyzed and implemented (i) adjust origin of coordinates of document, and (ii) allow math operations (sum, substraction, multiplication, division) inside the spin boxes for Height, Width, X, Y. All implementations will be tested and ensure accuracy, flexibility, and robustness. All code produced will follow the Inkscape coding style. Documentation will be done during coding. BACKGROUND AND SKILLS I am interested in working on the "transformation-anchors" project in GSOC this year. Inkscape is one of my favorite open source software. I have similar work before, to have the default rotation center to be the geometric center of all shapes. Anchor coordinates are a part of the object (drawing) attributes. It can be adjusted, so that geometrical transformations, rotation, translation, scaling, and shearing, can be performed with the updated center. The following is a few points about my background. · Master student in Computer Science (GPA: 4.0/4.0) in Canada, thesis: medical image processing and 3D reconstruction. · Successfully completed GSOC 2009 for a Gimp project, Advanced GUI for brush dynamics. · Four years full-time work experience in programming and architecture · Played key roles in technology R&D and innovation in image processing, vector graphics, 3D modeling, and CAD I have developed vector-based graphics editors both from scratch and on existing large applications. One of them is for a leading manufacturing company in Canada. For example, a graphics editor uses customized XML formats, have OOP architecture design to deal with all shapes/primitives using object classes (e.g. rectangle, ellipse, closed-path with arcs and lines, curves), and allow SVG and DXF (Solidworks drawing file) import and export. I have used Inkscape and SVG at work for one year (e.g. for SVG work, and GUI and HCI design example). One of my contributions for this software is to replace the previous raster based image editor with vector based editor using custom XML format. Every year, hundreds of customers use it for industrial designing, including NASA, Boeing, Google, Microsoft, MIT, US Army, GE, GM, Lockheed Martin, and many more. The company can product near anything that is made using the software. Meanwhile, the R&D goal was to provide the software that reflects what products can be made. Therefore, it is high level quality software that provides flexibility and precision. A few highlights of my work: · Completed the release of version 3.1 within 1.5 months of hire, with minimal input · “accomplished tasks the first day that took half a month before; amazing” – President · “The good news is, you are on the top.” – Chairman, in a review for R&D team performance Besides this software, I have developed dozens of image and video editors. When I worked as Lead Developer with 2D-3D Video Inc. for two years, I worked on image processing, and video editing software, and 2D to 3D image/video conversion. I have led the development of 3D movie player on iPhone/iPod Touch, and LG 42-inch 3D TV. The technology is used to convert image or video and generate 3D viewing effects without 3D glasses required. Sample work: 3D face of Barrack Obama. It is converted to 3D photorealistic view using a single 2D still face photo. http://www.2d-3dvideo.com/3Dphotos/BarrackObama.wmv Other: http://www.2d-3dvideo.com/NewSite/SchoolPhoto.wmv http://www.2d-3dvideo.com/3Dphotos/Couple.wmv http://www.2d-3dvideo.com/3Dphotos/33framerotation24degree.wmv http://www.2d-3dvideo.com/IDcards/male130BG40deg.wmv In my Master thesis research, I have had two publications, and will have couple more soon. I have developed new algorithms and techniques in image segmentations, interpolations, 3D reconstruction, and missing structure generation. Since the work deals with different shapes, it has a vector graphics sense. I used XML to store and process 3D structure and wireframes. Technically, I am good in C++. I have done some work using the following. XML: I have used it for many projects, using C++, Python, C# and Java. Libraries used: .NET, DOM, JDOM, Minidom. It is used in my thesis and each of my jobs at work. SVG: I have written a SVG viewer before. GTK+: I have experience with it in the Gimp GSOC project. Git and SVN: I used it at work before. Bazaar: I tried it, and it is very similar with SVN and Git. PROBLEMS AND IMPLEMENTATION PLAN A well designed GUI and interaction of transformation anchor manipulation is very important for Inkscape. Currently, the rotation center (in an example of transformation) can be dragged freely. However, where it is dragged to cannot be precisely defined, except eye-balling roughly. There needs to be new UI facilities with an intuitive design that allows the precise adjustment of the center. This precision control is expected to be useful to many Inkscape users, such as Xfig users. In the Transform dialog, XY fields need to be added as a separate tab. A 9-button-matrix widget, which is intuitive and helpful to users, will be implemented to assist moving the center among nine locations easily with one click. To prevent errors or misleading, there should not be center of rotation and anchor as two different entities. A single tool should be used, which is marked by the cross. Then, all transformations should refer to it. Since this object exists in the code, a list of better UI facilities can be added to move it. As well, the cross can be automatically saved into SVG for each object. A simple test was done to confirm this. The center of rotation, marked as cross, can be moved to a different location. It is saved for the object, so that when closing and reopening this SVG file, the cross (center of rotation) stays where it is left. In the SVG, the fields or attributes of the path object shows: inkscape:transform-center-x="7.6874748" inkscape:transform-center-y="-3.2402241" / Another quick test was done for moving the transformation centers. - For rotate and skew, different centers will give different results. - For scale, moving the center gives the same results, with the same transform values. - Transform using handles is correct. A simple drag keeps the center as it was, and Shift+drag scales around the rotation center. Obviously, there is an issue in the consistency with scaling. It does not work correctly if scaling by numbers. Selector toolbar, or the mouse tool in the top left interface, uses the top right corner, while Transform scales around the geometric center. The correct way is to use rotation center for scaling, with X/Y in selector toolbar displaying the coordinates of the center. The above issues will be fixed. The UI needed for rotation center XY coordinates is a couple Gtk-Spin-Buttons for X and Y plus a unit selector, defaulting to the document units. Since there is already the unit selector for X, Y, Height and Width, it may be used without writing a new one. After the 9-button-widget is used to move the X/Y coordinates, the spinbuttons should be updated to reflect the selection of one of nine anchors. Hence, the linkage is required for the 9-button-widget and the spinbuttons. It was pointed out that there were two other relevant projects related to this one: - adjust origin of coordinates of document - allow math operations (sum, subtraction, multiplication, division) inside the spin boxes for Height, Width, X, Y. I believe that it would be more beneficial if I work on this two during GSOC. The main focus of the project is on transformation centers, and the above two will be analyzed and planned, when transformation center tasks are half way through. I will propose another implementation plan for them, with a reasonable class structure design/rewrite. I will work on the two after completing the transformation center project. If there is no time to finish all of these in three months, I will try to make sure on-going work is easy to do. After the three months of work, I may be interested to continue contribution. At some point later, it may become clear what can be done, when unknowns are solved. It was suggested that the math operations can be taken from GIMP 2.7.0+. It can be done easily with my previous experience in Gimp contribution. Taking code from open source is something that I have done for many times, both for Master thesis and at-work programs. Recently, I took some open source code of spline interpolations into my thesis. Translating math operations into C++ is doable too. I do porting of different languages on daily bases. TASKS AND TIME TABLE Goal: Improve GUI for transformation centers for precision and flexibility 1. Communication. May 10 – May 20. Communication with the mentor. Code review on relevant source code, class structure. 2. Studying. May 21 – May 25. Study Inkscape development workflow, coding style, committing process. Study libraries required. 3. Reaserch. May 26 – June 6 Analysis of the architecture. Discuss and decide a GUI mockup as an implementation guide. Get familiar with sample SVG files and GUI mock-up that Pajarico has. Preparing a list of implementation. Intuitive GUI design. 4. Coding and implementing. June 7 – July 17 Possible refactoring. Precision of center moving. Fix the issues for scaling around different centers. Allow setting the center coordinates numerically Add 9-button-matrix widget Add XY fields in a separate tab of the Transform dialog Implement XY coordinates UI, a couple Gtk-Spin-Buttons for X and Y. Ensure the linkage between the 9-button-widget and the spinbuttons. Display coordinates and values, take XY input from users, and allow undo and redo 5. Second stage implementation. July 18 – July 31. Further analysis of two relevant projects: 1) adjust origin of coordinates of document 2) allow math operations (sum, substraction, multiplication, division) inside the spin boxes for Height, Width, X, Y. Have another implementation plan for them, with a reasonable class structure design/rewrite. Implement them. 8. Overall debugging, code optimization and further improvements. August 1 - August 10. 9. Further optimization. August 11 - August 15. 10. Documentation and clean up. August 16 - August 20. REFERENCES AND LINKS: http://wiki.inkscape.org/wiki/index.php/Google_Summer_Of_Code https://blueprints.launchpad.net/inkscape/+spec/transformation-anchors http://socghop.appspot.com/gsoc/org/show/google/gsoc2010/inkscape https://bugs.launchpad.net/inkscape http://wiki.inkscape.org/wiki/index.php/InkscapeInvariants http://inkscape.org/bzr.php Note: I am also interested in a few other interesting projects: - Power Stroke - Modulated width stroke LPE. - xar-to-svg converter - Converter for Xara Xtreme to Inkscape - KML SVG translation - For use of Inkscape with Google Earth or Maps >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

1 0

Problem of chatting in IRC
by Zhenfeng Zhao 07 Apr '10

07 Apr '10

Hi, I have a question about chatting in IRC. In windows, it did not work for me. So, I just tried XChat in Linux. Now I can see other people chatting in the channel. But I cannot send messages there. I have changed it to utf-8. #inkscape :Cannot send to channel Charset changed to: utf-8 Still, it shows: <ZZF_> hello * #inkscape :Cannot send to channel Also, some more messages below... Can anyone told me how to fix it, in order to chatting in the channal? Thank you. <ChrisMorgan> That is probably all you need, but if you need more, you could create a rectangle the size of the whole thing and apply it as a clipping mask. <ChrisMorgan> (Then everything else would need to be in a group) <kn100> so in other words there's no way to hide overflow at the design stage without changing how i work with the tool? * troy_s has quit (Quit: Leaving.) * vlada has quit (Remote host closed the connection) * Justicejr (~Justicejr@...2337...) has joined #inkscape <ZZF_> hello * #inkscape :Cannot send to channel Regards, Zhenfeng.

2 1

Coordinate system fix
by Krzysztof Kosiński 07 Apr '10

07 Apr '10

Hello In revision 9288 I fixed the inverted coordinate system bug, starting from a patch by Thomas Holder. https://bugs.launchpad.net/inkscape/+bug/170049 While this is a rather invasive change, fixing bugs caused by removing the coordinate inversion is simple (often it boils down to tweaking a single line of code), so I think we'll manage to fix any remaining regressions before the release. Regards, Krzysztof

16 52

Re: [Inkscape-devel] GSoC: KML <-> SVG Translation
by sjatkins＠...2336... 06 Apr '10

06 Apr '10

Oh dear, I really am no good at mailing lists. I accidentally emailed this to Krzysztof instead of the mailing list. Sorry! On 06 April 2010 at 17:49 "Krzysztof Kosiński" <tweenk.pl@...400...> wrote: > 2010/4/5 sjatkins@...2336... <sjatkins@...2336...>: > > Then, develop a command-line app that will actually do the conversion. I'll > > be > > using C++. I haven't decided on an XML library yet - any suggestions? > > You should use libxml2 and libxslt - that's what Inkscape uses. > However, it might be better to write an internal extension rather than > a separate command line application. Look at src/extension/internal/. > You can also consider using XSLT. Thanks, that's really helpful - I wasn't sure where in the codebase to look. Making it an internal extension does sound much better than an external application. I'm not very familiar with XSLT, and it's probably better to stick with C++ as I know it better. > > Once the command-line program is working, I'll start on giving it a GUI. I > > can't > > seem to find anything about what UI library Inkscape itself uses - can > > anybody > > tell me? > > It uses GTK+ and gtkmm. Again, look at existing input extensions - the > extension system should satisfy your GUI needs. You just put the > parameters you need in an .inx file and the GUI is created > automatically. > > Regards, Krzysztof I think I might not need to add a GUI if I do this as a extension, but if I do I'll use the extension system like you suggest. ~Sam

1 0