- Inkscape Devel - Inkscape Mailman

INKSCAPE
by Manuel Hiciano 06 Apr '14

06 Apr '14

it is possible to orient the inkspace for something specific drawing, I mean add other features that allow you to work other aspects of technical drawings. Thank you! Waiting for your answers ..

2 3

Warnings check
by Johan Engelen 04 Apr '14

04 Apr '14

Hi all, I'd like people to check what compiler errors are reported for trunk on their system (Windows I can do myself), with these flags: -Wall -Wformat -Werror=format-security -W -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Werror=switch -Werror=return-type -Werror -Wno-error=pointer-sign -Wno-error=unused-parameter -Wno-error=unused-but-set-variable -Wno-error=strict-overflow -Wno-error=write-strings -Wno-error=format -Wno-error=format-extra-args Please no comments about whether you like these flags or not, just what build *errors* you get. (don't send me the warnings please!) (On Windows, with these flags we are down to 3 errorring files, and I'm working on them) Thanks a lot, Johan

12 31

Fwd: [Branch ~inkscape.dev/inkscape/trunk] Rev 13262: XMLTree and InkscapePreferences are not dockable windows, don't treat them like one.
by su_v 04 Apr '14

04 Apr '14

I want this feature back (for both dialogs). -------- Original Message -------- Subject: [Branch ~inkscape.dev/inkscape/trunk] Rev 13262: XMLTree and InkscapePreferences are not dockable windows, don't treat them like one. Date: Fri, 04 Apr 2014 13:18:26 -0000 From: noreply@...1881... Reply-To: noreply@...1881... To: ~suv <snip> ------------------------------------------------------------ revno: 13262 committer: Martin Owens <doctormo@...400...> branch nick: trunk timestamp: Fri 2014-04-04 15:16:22 +0200 message: XMLTree and InkscapePreferences are not dockable windows, don't treat them like one. modified: src/ui/dialog/dialog-manager.cpp

2 2

Windows dev build link and msi installer
by Jared Meidal 04 Apr '14

04 Apr '14

Thanks Adib, This installer worked smooth for me and seems a great way for Windows users to peek into a dev build if these files will remain updated. I'll place a link on the website for users to locate this: http://inkscape.org/en/download/windows/ --Jared > As I don't know how we might continue with the publication of daily builds > I put the todays versions on my Google Drive. > Here is the link: > https://drive.google.com/folderview?id=0ByQpCQ-C8wR2b09fYkRTSVk5bWM&usp=sha… > There is: > - bat a bat file that gets the source, compiles and creates the installer > - 7z archived complete directory > - msi new wix based installer > > the optimum would be a "cron job" that builds and publishes the archives > etc. > > Adib.

1 0

XML duplicate document
by Martin Owens 04 Apr '14

04 Apr '14

Hey devs, In fixing bug lp:419266 I noticed that we don't have a document node duplicate function that returns a document. Running duplicate on a document node at the moment will return a normal node (and requires a document as input, which explodes if you try and do anything with it) My attempts at adding a document duplicate function have failed. I just don't know enough about C++ inheritence which is used extensively between Node, SimpleNode and Document, SimpleDocument. If you do know this, I think it should be a quick addition and it would help clear up another bug (1059244) if you could add this function to our xml code. Best Regards, Martin Owens [1] https://bugs.launchpad.net/inkscape/+bug/419266 [2] https://bugs.launchpad.net/inkscape/+bug/1059244

2 1

Re: [Inkscape-devel] Export workflow, template format proposals (discussion)
by Johan Engelen 03 Apr '14

03 Apr '14

Hi all, A quick note, the functionality of saving to a file (possibly a PDF) without setting it as document file is already there. It's called Save a Copy... in the menu. -Johan ----- Reply message ----- From: "Bernard Gray" <bernard.gray@...400...> To: "Martin Owens" <doctormo@...400...> Cc: "Inkscape Devel List" <inkscape-devel(a)lists.sourceforge.net> Subject: [Inkscape-devel] Export workflow, template format proposals (discussion) Date: Thu, Apr 3, 2014 07:39 On 3 April 2014 13:46, Martin Owens <doctormo@...400...> wrote: > On Thu, 2014-04-03 at 11:22 +1100, Bernard Gray wrote: >> My proposal is actually to support both these workflows - add the File >> -> Export to... PDF menu option, but leave the "Save As... -> PDF" >> option intact. > > Sorry I wasn't clear. This is my proposal also. > > I would not like to see a new menu item though. Exporting a specific > type should be something the export dialog takes care of, so exporting > to eps, pdf or something else. > > The big difference between export and save as, is that save as sets the > document filename to this new filename and export should not. Great, we're on the same page - I'm not fussy as to how it's implemented in the menu. Gimp currently provides two Export options in it's file menu, "Export", and "Export As...": * Export As... takes you to a file picker dialog, where you can choose the location and format of the exported file * If you haven't exported the document already, the "Export" button does the same thing * Once you have exported the document, it remembers the last file you exported to and the "Export" button title changes to reflect this, ie "Export to <file>.<extension>" This would require the addition of a new menu item though. If you want to avoid this would you prefer to just go with something similar to the Gimp "Export As..." button/functionality? > Martin, > ------------------------------------------------------------------------------ _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

2 2

Export workflow, template format proposals (discussion)
by Bernard Gray 03 Apr '14

03 Apr '14

Hi All, It's been a long time (my alias is cleary) - We're beginning to see inkscape get some traction in our company as a tool for non-designers to make small changes to templates/documents that our designers create. An example scenario: Our HR Dept does Job Vacancy releases. These job vacancy documents have fairly standard elements, and the vast majority of changes that the HR guys need to make are as simple as changing the date, or location. The workflow I'm looking to introduce is: the Designers create a template, HR can then take that template, make minor text changes, export to PDF and distribute. There are two niggles in the way inkscape handles this process, and I'd like to at least open up some discussion on resolving these niggles. 1st Niggle: Exporting to PDF is a "Save" operation, not an "Export" operation After they've made some changes, the users must remember to save as SVG first before saving as PDF in order to maintain a compatible "source" document. They also have to remember that after saving as PDF, they are no longer working on the source document. Proposal: Expand the "Export to Bitmap" File menu item to include PDF, and potentially other formats that are not suitable as a "source" document ie they can't preserve an adequate level of info - layers, objects etc By doing this, The Export action creates the PDF (or non-source suitable) document, and any subsequent modifications are still saved to the source SVG document without any further opening/closing/saving over existing docs. Gimp recently introduced this idea I believe. 2nd Niggle: The current "Templates" handling involves maintaining documents in a dir under the inkscape profile dir. This requires some bespoke SOE handling for multiple users to get access to multiple templates. Proposal: Introduce an "inkscape template" file extension in a similar fashion to popular office suites (.svgt?). The file is no different to a standard inkscape svg, the only difference would be that when you go to Save the document for the first time, it forces you to use the Save As... dialog so you don't overwrite the template. This would allow users to keep templates *anywhere*, and won't require any significant training or support to make sure there's no accidental clobbering of the template documents. I'd be keen to hear people's thoughts, and I realise this may be better as two separate discussions. My programming skills are fairly atrophied these days, but I would definitely consider having a crack at patching something. Paying for the features either in the form of a project donation or by specifically hiring resources are also possibilities. Thanks for your consideration, Bernard Gray

2 6

Export workflow, template format > proposals (discussion)
by Jelle Mulder 03 Apr '14

03 Apr '14

Hi all, My two cents on this ongoing discussion. 1.) Export of non native file formats Everything that is not native Inkscape should go to an export/import. I think Bernard's case gives a great rationale for doing it that way. Indeed it takes less brain effort to just export and import and keep the work file in InkSVG format. I'm pretty used to Inkscape, but I've had my moments of doubt. I can imagine that for people less knowledgeable will make the wrong decision here. 2.) Template directory of choice - Template extension .svgt It would be a really nice thing if you could put your templates in a directory of choice at least, so it would be easier to keep a selection of templates you'd actually use in it. Or in case you want to make changes to existing templates copy them to a new directory and edit them there without fear of messing things up. Using the export again, it would be easy to save a file as template in the directory of choice, rather than just save the file and mess up the original template. Otherwise, save the thing as a new file and force naming it with a blank name. Using an extension like .svgt feels a bit over the top. Next we'd have .svgr (resource file) etc. Whereas it is all SVG content with a few extra namespaces. Having a more logical way of organising your files seems more to the point to me. Cheers, Jelle On Thu, 03 Apr 2014 08:22:59 +0800, <inkscape-devel-request(a)lists.sourceforge.net> wrote: > Message: 8 > Date: Thu, 3 Apr 2014 11:22:51 +1100 > From: Bernard Gray <bernard.gray@...400...> > Subject: Re: [Inkscape-devel] Export workflow, template format > proposals (discussion) > To: Martin Owens <doctormo@...400...> > Cc: Inkscape Devel List <inkscape-devel(a)lists.sourceforge.net> > Message-ID: > <CA+Br8tPvQHPu3NeSeR7R1hkJL5-75rQ3FykAW0Kf4tDZDwja+A@...401...> > Content-Type: text/plain; charset=ISO-8859-1 > On 2 April 2014 21:36, Martin Owens <doctormo@...400...> wrote: >> On Wed, 2014-04-02 at 13:06 +1100, Bernard Gray wrote: >>> I'd be keen to hear people's thoughts, and I realise this may be >>> better as two separate discussions. >>> My programming skills are fairly atrophied these days, but I would >>> definitely consider having a crack at patching something. Paying for >>> the features either in the form of a project donation or by >>> specifically hiring resources are also possibilities. >> >> Hi Bernard, >> >> I think the solution might be to think of inkscape as the template >> creator and renderer. >> >> So one can run inkscape from a script or command line in order to turn >> any svg into a pdf. This is useful for keeping things in svg until the >> last part of the process and you can automate this. I've seen solutions >> that watch a directory for svg files and render pdf files automatically. > Hi Martin, > Thanks for the reply - I imagine that scripting is a common (and for > us at least) a fairly simple option to implement. > In my users case though, this goes back to limiting the locations > where they can store the files, and I'm trying to remove this > restriction on them. It'll also cause us support issues if the service > isn't running, or they move the files and it stops working etc. The > least added maintenance/support we the IT team have to do, the better. > Like it or not, you guys have done a great job of the GUI interface. > It's very accessible, and users can go from novice to functioning in a > matter of minutes. For this scenario specifically, I'd like to > leverage this feature > >> The other option is to print to pdf. Not sure if it's the same for >> inkscape's renderer or not though. > Great idea - for the HR guys, they're running windows so I'll check to > see what print dialogs/renderers we can get access to there and that > might be an adequate workaround for now. > >> For data entry. i.e. fixed fields. We could do more work there for sure. >> We don't really have a way of specifiying parts of a document which are >> configurable and parts that aren't. I don't think SVG2 is going in that >> direction either (please surprise me with a correction Tav) > Don't worry about this bit - to create this feature I've just added a > layer of non-editable elements, and locked that layer. Then all the > editable elements go on a new, unlocked layer. > >> Overall I think the work might be done with smaller scripts. Although >> we'd certainly appreciate the investment in inkscape to improve the save >> and export design. In my designs, save would be for any file. It would >> default and prioritise svg/plain svg etc, but if you selected pdf or png >> it would open the export dialog setting that file. Making it a two entry >> flow rather than two single flows. > That's an interesting take on it. I was thinking that we could > potentially leave both flows in (ie adding the file types to the > Export menu, but not removing them from the Save menu). I guess it > gets complicated here because inkscape has the ability to handle PDF > file types directly (opening and saving), so ideally you'd want to be > able to save back to that (and similar) file types directly where > applicable. > One of the reasons I proposed the Export to... option and keeping the > two flows separate was to maintain consistency with the workflows of > other similar tools. I just realised that my knowledge of other tools > (adobe cs suite for example) is fairly limited, so I just went and had > a chat to the designers next door to see what is actually done - > Illustrator: No "Export to... PDF" option, only "Save As...-> PDF". > This behaviour is the same as inkscape currently > InDesign: Has "Export to... PDF" option, but no "Save As... -> PDF" > So it's no clearer > My proposal is actually to support both these workflows - add the File > -> Export to... PDF menu option, but leave the "Save As... -> PDF" > option intact. > This gives the opportunity for a user to not have the source file > changed from underneath them via a save operation *if they choose* and > significantly reduces the risk of it happening inadvertently, but > leaves the scenario where you can change the working file to a > different format deliberately, *if you choose*. > It can also open up the opportunity for exporting to other bitmap > formats (like jpeg which I occasionally find myself having to take and > extra step to convert to from time to time) > >> There's little reason to consider pdf options and png options to be >> somehow different. > The options for exporting aren't different per se, but the concepts of > Exporting vs Saving *are* very different. That's the key issue I'm > working to resolve. > >> Best Regards, Martin Owens > Any thoughts on the svgt(emplate) file proposal? I raised the idea > with the designers, and they really liked it. Apparently they are > constantly fixing "template" files that have been accidentally > overwritten because someone forgot to take a copy first, or remember > to use Save As for the first save.

1 0

tessellation maker - Escher inspired
by Mark Schafer 02 Apr '14

02 Apr '14

Saw this great project. Would make a great plugin for inkscape. Posting for the future... http://danceswithferrets.org/geekblog/?p=154

2 3

Text Blocks as Templates
by Martin Owens 01 Apr '14

01 Apr '14

Hi devs, I noticed filedialogimpl-gtkmm.cpp has been cleaned by Johan. I was wondering if there's any way to take big blocks of template like the kind used in this file and keep them in separate files. I'm aware that there are pre-compile and compile-time macros and other interesting ways to handle these things. Or a run time loader (reducing the size of the binary, but increasing load time?) The three templates are sizable enough to be seperate, so is it C++ that prevents us or is it just messy to do so? Thanks for your answers, Best Regards, Martin Owens

2 1