- Inkscape Devel - Inkscape Mailman

locale madness
by Kees Cook 04 Feb '05

04 Feb '05

So, to really confuse things, I decided to go see if The Gimp under windows would blow up the way we are (were). It does not. So I then removed all the .DLL's from my inkscape directory so it would use the install GTK defaults. It worked like a charm. No utf8 errors, nothing. Very interesting. -- Kees Cook @outflux.net

1 0

Info needed from Ishmal for release notes
by Bryce Harrington 04 Feb '05

04 Feb '05

Bob, can you say a few words about the status of scripting and XSLT for us to use in the ReleaseNotes? I.e. what can users make use of, and what level of functionality will be available in this release? Thanks, Bryce

1 0

Re: [Inkscape-devel] Basic tasks ?
by Bryce Harrington 04 Feb '05

04 Feb '05

On Wed, 2 Feb 2005, Ashwin Bharambe wrote: > Hi Bryce, > > > Another area we will need a lot of help in fairly soon is with upgrading > > the UI to gtkmm. This will involve a lot of meat-and-potatos C++ class > > creation and conversion of C code into OOP style. Presently this work > > is going on in a separate cvs module but it's scheduled for integration > > within about a week. If you're interested in working on this, let me > > know and I can give more details. It should be pretty straightforward > > work, and will be seeing progress rapidly, so it could be fun. :-) > > I would be interested in more details for this. Basically, once in a > while, it feels good to do "simple" things and get something useful > done. :) Let me know if and how I could help out here. Great! This work will begin in earnest after we release 0.41, but you can get involved now easily by downloading and tinkering with the inkscape_gtkmm codebase, and/or learning Gtkmm via the www.gtkmm.org site. If you're anxious to work on something with inkscape_gtkmm, and willing to take on a more challenging effort, I posted a few tasks to this list a couple weeks ago, you could look through. For example: http://sourceforge.net/mailarchive/forum.php?thread_id=6260552&forum_id=360… http://sourceforge.net/mailarchive/forum.php?thread_id=6260551&forum_id=360… Those include directions for checking out the code, too. Also, look in the PLAN document within the codebase for some tasks and projects (esp. at the end of the file). > > * Cairo Gtk Canvas - A long term project we have talked about is to > > replace our internal renderer with Cairo, but there's a ton of R&D > > experimentation needed to get there. If you like working from a > > blank sheet of paper and just coming up with a lot of good ideas > > that others can build off of later, this would be a good > > opportunity. > > How would one start here? I briefly tried figuring out how exactly > livarot is used within inkscape at this moment - is there a > well-specified layer here? If you could get me started on a brief > outline of what the goals are, I am willing to spend considerable > amount of time performing experimentation with cairo. This would be great. I think you have already made some progress at this but I can give some additional random info: * Cairo is itself composed of several libraries that each provide different wrappers atop the core. For instance, the SVG bindings are in a library that sits atop the more underlying cairo bits. * We need to understand exactly which cairo pieces are required, how they're packaged, and how we can distribute them to users. For example, what pieces would we need to distribute to Windows users? * There is a GtkCairo lib, that you looked at the other day, but actually we need a full Canvas. What exactly does this mean? How would we go about packaging such a thing? * I believe I saw that there is a Qt Canvas for Cairo. Is there any possibility of sharing code between this and a Gtk Canvas? * What portions of the existing Inkscape codebase would get subsumed into a GtkCairoCanvas object? What would be most appropriate to keep out at a different level? In general, the idea behind creating a gtk cairo canvas would be to enable things like these: * A game developer could use it to render and manipulate the graphical components in their game. * A project aimed at creating a shared whiteboard project could tie a canvas to the Jabber message protocol stream to enable interactive drawing functionality. * A company wishing to provide their customers with an application showing attractive, dynamic graphs and diagrams could use it for drawing this information as it is broadcast to the client app. * An application for viewing/managing rack mounted computer hardware could use it for displaying a top-down view of the data center, which could be interactively clicked on to view front-views of the racks, and with further clicking to see individual hosts in the racks, usage/performance graphs, machine statistics, and wiring diagrams. Of course, in addition, the canvas would provide rich functionality for Inkscape to use it for editing SVG documents. ;-) Bryce

1 0

RE: [Inkscape-devel] Inkboard linking/dependencies
by Montgomery, Steven S 04 Feb '05

04 Feb '05

No, we don't have our code linking normally. Since it was such a brickwall for our progress, we moved the Jabber code into a file we added under dialogs(where it was being called from). Obviously this links, but we definitely would like to separate the code back out how it should be. I've seen some recent posts about automake 1.9 causing problems for some people. Perhaps that is our issue as well? It's not clear to me where our documents would be appropriate in the Inkscape Wiki. However, we do have all of our documents and sourcecode available online. The documentation is at http://inkboard.sourceforge.net and our code is in the Sourceforge CVS(/cvsroot/inkboard/). The Inkboard module is the correct one(we plan to clean up the CVS repository at some point). Steven Montgomery

2 4

RE: [Inkscape-devel] Inkboard linking/dependencies
by Montgomery, Steven S 04 Feb '05

04 Feb '05

Ok, the code DID link fine, but it was because it included the .cpp instead of .h. So, we're still having problems linking. Steven -----Original Message----- From: inkscape-devel-admin(a)lists.sourceforge.net [mailto:inkscape-devel-admin@lists.sourceforge.net] On Behalf Of Montgomery, Steven S Sent: Thursday, February 03, 2005 3:21 PM To: inkscape-devel(a)lists.sourceforge.net Subject: RE: [Inkscape-devel] Inkboard linking/dependencies Actually, I just confirmed that we're running automake 1.7. And it just linked fine a second ago. So, the latest version of code is in the CVS. Steven -----Original Message----- From: inkscape-devel-admin(a)lists.sourceforge.net [mailto:inkscape-devel-admin@lists.sourceforge.net] On Behalf Of Montgomery, Steven S Sent: Thursday, February 03, 2005 2:59 PM To: inkscape-devel(a)lists.sourceforge.net Subject: RE: [Inkscape-devel] Inkboard linking/dependencies No, we don't have our code linking normally. Since it was such a brickwall for our progress, we moved the Jabber code into a file we added under dialogs(where it was being called from). Obviously this links, but we definitely would like to separate the code back out how it should be. I've seen some recent posts about automake 1.9 causing problems for some people. Perhaps that is our issue as well? It's not clear to me where our documents would be appropriate in the Inkscape Wiki. However, we do have all of our documents and sourcecode available online. The documentation is at http://inkboard.sourceforge.net and our code is in the Sourceforge CVS(/cvsroot/inkboard/). The Inkboard module is the correct one(we plan to clean up the CVS repository at some point). Steven Montgomery ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

1 0

RE: [Inkscape-devel] Inkboard linking/dependencies
by Montgomery, Steven S 03 Feb '05

03 Feb '05

Actually, I just confirmed that we're running automake 1.7. And it just linked fine a second ago. So, the latest version of code is in the CVS. Steven -----Original Message----- From: inkscape-devel-admin(a)lists.sourceforge.net [mailto:inkscape-devel-admin@lists.sourceforge.net] On Behalf Of Montgomery, Steven S Sent: Thursday, February 03, 2005 2:59 PM To: inkscape-devel(a)lists.sourceforge.net Subject: RE: [Inkscape-devel] Inkboard linking/dependencies No, we don't have our code linking normally. Since it was such a brickwall for our progress, we moved the Jabber code into a file we added under dialogs(where it was being called from). Obviously this links, but we definitely would like to separate the code back out how it should be. I've seen some recent posts about automake 1.9 causing problems for some people. Perhaps that is our issue as well? It's not clear to me where our documents would be appropriate in the Inkscape Wiki. However, we do have all of our documents and sourcecode available online. The documentation is at http://inkboard.sourceforge.net and our code is in the Sourceforge CVS(/cvsroot/inkboard/). The Inkboard module is the correct one(we plan to clean up the CVS repository at some point). Steven Montgomery ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

1 0

Need to hunt things down
by Jon A. Cruz 03 Feb '05

03 Feb '05

I'm 'bout off to work, but I remembered something that just needs a little help from extra eyes. One of our problems with reading and writing files with names containing characters outside of the 7-bit ASCII range is with library and/or API calls that take filenames directly. Our uses of fopen have been mainly fixed, as are some of the pass-it-a-filename calls. However... there might be a few places that still pass a filename on directly. Could people take a quick peek to see if we have spots where that happens? For things to work well, we have to do one of two things 1) Convert filenames from UTF-8 to filename encoding before calling 2) open the file and pass the API an open file or a data source (depending on the needs of the API). #1 will work for Linux, but *not* Windows XP and friends, since all characters possible on the filesystem can't be respresented in the current ANSI codepage. If anyone has a chance and can find a few of the lingering places, I can go in more quickly tonight and fix them. Thanks.

1 0

node editing
by Jakub Steiner 03 Feb '05

03 Feb '05

Hi folks, I've already filed a request to be able to edit nodes of multiple objects. The reasoning behind this is that I constantly change shape of a drawing and that mostly consist of multiple overlaid objects so all of those need to be changed (currently one by one). I do, however like the way Inkscape restricts node selection within an object too. So I think the following behaviour would work best -- you could only select from the shown nodes as it is now. But apart from working on a single object, Inkscape would also allow to select multiple objects first, then change to node editing and have nodes from all selected objects selectable. Does that make sense? If we had a nice floating dock of the object tree, an object locking mechanism may be just as effective (lock uninteresting objects first, node select working on all objects). But we don't ;) -- Jakub Steiner <jimmac@...659...>

3 5

status & plans
by bulia byak 03 Feb '05

03 Feb '05

Looks like the drawing tools crash (1107922) is going to be fixed soon. The other crash bug (1113187) seems to be easy, and the svgz loading on windows is a matter of supplying a correct DLL. So, we're close. Once all these are resolved, I think we need to make one prerelease which would be tested for 2-3 days, and then do the final release if nothing critical is found. This time I'd very much like the prerelease to have a Windows binary as well (0.40 prereleases didn't). Will someone be willing to provide it?

4 3

new bugs
by bulia byak 03 Feb '05

03 Feb '05

I consider these two bugs to be MUSTFIX as well: - the one found by Kees (without pref file, objects are drawn black), see my post with more details on why this happens - the new crash on load: http://sourceforge.net/tracker/index.php?func=detail&aid=1113187&group_id=9… The first of these bugs appears mild, but they both are in the new repr code by Mental and therefore may be signs of something more sinister which we haven't found yet. And both are regressions compared to 0.40. Mental, will you please look into them? If you need my help I'll do what I can, though currently I'm swamped by work.

3 4