- Inkscape Devel - Inkscape Mailman

Re: "pixel preview" mode
by Jakub Steiner 11 Feb '05

11 Feb '05

On Wed, 2005-02-09 at 21:11 -0800, Jon A. Cruz wrote: > I've tossed up a screenshot mockup of what I'm thinking a "pixel > preview" mode could look like > > http://www.joncruz.org/pixel_preview.png > > Ignore the topmost part, there are some slight issues with the bounding > box detection, so the top of the point got chopped. (BTW, I used the > "Make a Bitmap Copy" to get this simulation.) > > Anyway, I was thinking it would be nice to have a mode where a the > preview would show a version of the image at some set DPI, and as you > zoom in the 'pixels' would enlarge as well. This could help when doing > small work (like with icons) and with targeting different profiles, such > as SVG Basic and SVG Tiny. We could even tie it in to some 'skin' for > specific SVG Tiny devices, where switching to a different skin would > also change the preview DPI to a proper value. > > Any thoughts? Comments? I think I'd prefer to either have the objects drawn at the display resolution or target document resolution, not both. As pixel preview would get a shortcut to toggle, it would be easy to switch between the two. Having both at the same time would only create visual noise. As for Bulia's comment. We certainly don't need it because Illustrator has it. Let me explain its usefulness. While having a "true" 1:1 view is what appears to be enough to be able pixel-position objects, not everyone has eyes of a teenager and an LCD ;) It is way easier to pixel position artwork when you see the pixels as huge blocks, instead of staring at the 16x16 artwork at 1:1 at 5cm distance from the display ;) Oh and btw I noticed the SDI makes it really hard to have a second view of the artwork since it has all the menus, all the toolbars, and need to be quite a large window. cheers -- Jakub Steiner <jimmac@...659...> Novell, Inc.

3 4

Inkscape 0.41 Release PR and Packaging Plans
by Bryce Harrington 11 Feb '05

11 Feb '05

Hi all, With the 0.41 Hard Freeze finished and the release package posted, it's time to move into the final phase of the release, where we post packages and submit PR to blogs and the news media. Kees has been kind enough to take responsibility for producing the Windows and static rpm packages. Since these are often the most frequent downloads, I'm comfortable doing the announcement sooner than usual, however I'd like to provide packagers at least a full day to create platform specific packages. If you are comfortable creating packages, you can help us greatly right now by downloading the release and creating a package for your system. For example, we need packages for old and new versions of SuSE, Fedora Core, Mandrake, Slackware, and (especially) Mac OSX. Information on creating packages is available here: http://inkscape.org/cgi-bin/wiki.pl?CreatingDists If you have access to upload to the file tracker directly, please do so. If not, feel free to send me or another admin the package and we'll ensure it gets posted. For PR, I have written the following announcement. Please review/revise. It will be released tomorrow night my time: http://inkscape.org/cgi-bin/wiki.pl?ReleaseAnnounce041 Bryce

6 7

text properties
by Jakub Steiner 11 Feb '05

11 Feb '05

I wonder what's the deal with having an apply button on the text property window? It behaves like an instant apply dialog, yet it requires the eeky button click. cheers -- Jakub Steiner <jimmac@...659...> Novell, Inc.

1 0

Re: [Inkscape-devel] Selection in text editing
by Aewyn 10 Feb '05

10 Feb '05

Thank you answers, meanwhile I found a workaround :) My text edit dialog always open, attached to the main window, so it shows the current text always. It's okay, now. But (a new request follows ;) the dialogs disappear when the main window lose the focus. Now, inkscape gets a whole virtual desktop, so it is not a problem, but it would be very kind to get an option to off this feature (in future, not too important one). Thanks, Aewyn

1 0

forward declaration header files
by MenTaLguY 10 Feb '05

10 Feb '05

Ok, it looks like we need to have a chat about these "*forward.h" files I see cropping up that keep killing my rebuild times when I try to do class-level refactoring. I realize the intent was to reduce #include dependencies, but they actually make the problem far worse: since a whole lot of unrelated stuff is grouped in one file that everyone includes, adding or removing a class requires a rebuild of fricking EVERYTHING... And, really, do you need a header file for this? -- class Foo; class Blah; No, you do not. It's wasteful. All it asserts is that the classes (or structs) Foo and Blah definitely exist somewhere, to keep the compiler happy and avoid ambiguity. You can perfectly well put that directly in files where Foo or Blah are used opaquely without losing any maintainability (if either class gets removed or renamed, you'll need to edit those files regardless). Best thing is the files that only use Foo and not Blah won't need to be recompiled if Blah is removed or renamed anymore... So, please, STOP USING THESE BLOODY FORWARD HEADERS. I am removing xml/xml-forward.h today. I don't want to see any new ones cropping up. -mental

2 1

Install problems and then bigger ones
by Jim Clark 10 Feb '05

10 Feb '05

Oh my! Well, I'm between a successful make (after finally getting configure to work) and the make install when I read this. I have installed all these rpms (I just didn't scroll far enough to see them before) and now what? Should I continue with the install? Should I remove the rpms? Next step?????? This looks like something that might be documented a bit better on the web site.... Thanks so much for the info...I have never seen such comprehensive and impressive responses on a list before. My mail box (and yours as well) is full of thoughtful replies. Here's the rpms I installed: glibmm-2.4.4-1.fc2.i386.rpm glibmm-devel-2.4.4-1.fc2.i386.rpm gtkmm-2.4.6-1.fc2.i386.rpm gtkmm-devel-2.4.6-1.fc2.i386.rpm libgc-6.4-0.i386.rpm libgc-debuginfo-6.4-0.i386.rpm libgc-devel-6.4-0.i386.rpm libsigc++-2.0.6-1.i386.rpm libsigc++-devel-2.0.6-1.i386.rpm libsigc++-examples-2.0.6-1.i386.rpm? Thanks- Jim Clark

3 4

Says this is where to go for compile problems
by Jim Clark 10 Feb '05

10 Feb '05

Howdy...just heard about Inkscape this AM. I am not a developer, would be a casual user at best, but would like to take a gander. User, repeat USER, of Fedora Core 3. Not a coder, programmer (or even artist for that matter!) However I'm having problems compiling. When I ran configure it told me configure: error: libgc (the Boehm Conservative Collector) 6.4+, is needed to compile Inkscape -- http://www.hpl.hp.com/personal/Hans_Boehm/gc Fair enough. I got it (and thanks for including the URL) and it compiled fine without me changing or doing anything--just accepted its defaults and whiz, in it went. OK, back to Inkscape and configure croaks at the same place. Same error message. What do I need to do to have Inkscape know this is in, or how do I need to compile, install, whatever to communicate that? Thanks- Jim Clark

9 9

shortcuts in localized keyboard layouts
by bulia byak 10 Feb '05

10 Feb '05

I have just committed a fix for bug 962839 where keyboard shortcuts didn't work if you switch keyboard to a non-English layout. The fix seems to work at least for Cyrillic keyboard on Linux. Please test and report your results.

1 0

svg and svgz io
by Jon A. Cruz 10 Feb '05

10 Feb '05

I got my changes committed. It now uses xmlReadIO instead of xmlParseFile, so it should handle 'tricky' AKA non-ASCII/ANSI filenames on Windows. Additionally, it now has an extension for .svgz and the saving and loading inside of repr-io.cpp handles the compression using zlib ourselves, so it should work nice on Linux *and* on Windows with not tricky futzing. To do this, I started using the stuff in Inkscape::IO / src/io/* Take a peek and see if this stuff works for you guys also.

1 0

RE: [Inkscape-devel] perspective / free-transform code in inkscape from gimp
by Joshua A. Andler 10 Feb '05

10 Feb '05

Quoting Mental: > Quoting Andy Fitzsimon <andyfitz@...400...>: > > > preserving the number of nodes is a pretty good thing in my > > opinion . > > I didnt know that could be done. > > With bezier curves, it's the easiest way to do it, but you will get > some slight perspectrive distortions. Generally you will need to > add/remove control points to get the best-looking results. On top of being the easiest way to do it, wouldn't it make implementing animation a little easier? (mainly I'm not sure how well you could store adding and removing nodes within an animation timeline... and it seems like if the number remains the same it would be easier to work with) -Josh

2 1